RAGのサービスをリリースして 1年3ヶ⽉が経ちました 多くのお客様に関わって得られた知⾒ 🄫2024 segavvy 2024/07/25 Azure OpenAI Service Dev Day @segavvy ※個⼈で作成したものであり、内容や意⾒は所属企業・部⾨⾒解を代表するものではありません。

はじめに サイト内検索とChatGPTを組み合わせたRAGのサービスを 2023年4⽉にリリースして1年3ヶ⽉が経ちました 多くのお客様のPoC・導⼊・オンボーディングに関わったので そこで感じたことなどを共有します 3章に分けてお話します 🄫2024 segavvy 2024/07/25 Azure OpenAI Service Dev Day 2

注意 発表内容や資料は個⼈で作成したものであり 内容や意⾒は所属企業・部⾨⾒解を代表するものではありません 🄫2024 segavvy 2024/07/25 Azure OpenAI Service Dev Day 3

第１章 昨年春にリリースしたサービス サイト内検索＋ChatGPTのサービスとは 🄫2024 segavvy 2024/07/25 Azure OpenAI Service Dev Day 4

サイト内検索とは︖ 🄫2024 segavvy 2024/07/25 Azure OpenAI Service Dev Day 5 • ネットの情報を検索する • 検索プロバイダーが提供 • 企業の保有情報を検索する • 企業がサイト訪問客へ提供 ネット検索 サイト内検索

ChatGPTなら 壁を越えられそう!! サイト内検索にChatGPTを組み合わせた理由 サイト利⽤側の想い • ○○について教えて • ○○のページはどこ︖ • 検索して結果を ⾒て回るのは⾯倒でイヤ 🄫2024 segavvy 2024/07/25 Azure OpenAI Service Dev Day 6 提供企業側の想い • 顧客の悩みを解決したい • 問合せ対応を削減したい • 商品を知ってもらいたい • 優秀な⼈を採⽤したい 「教えて」という 要望に対して 直接答えられる︕ 「営業マン」「相談相⼿」 「リクルーター」として 答えてくれる︕

イメージ 🄫2024 segavvy 2024/07/25 Azure OpenAI Service Dev Day 7 ① ② ③ ①検索条件の⼊⼒欄 ②ChatGPTの回答⽂ ③検索結果の⼀覧 ※公開可能な事例ですが、この資料は営業⽬的ではないのでお客様名を伏せています。

🄫2024 segavvy 2024/07/25 Azure OpenAI Service Dev Day 8 サービスの仕組み（準備） お客様の管理者 弊サービス Watson Discovery AOAI ChatGPT 対象Webサイト ①対象Webページ・ファイルの内容を取得 ②取得内容の整形、除外、分割、除去、etc. ③登録 クロール 必要に応じた調整 ①同義語登録、ランカー学習、アノテーション付与、etc. ①Webスクレイピングです。 対象サイトのリンクを芋づる 的にたどったりサイトマップ を利⽤したりすることで対象 サイトのページ・ファイルの 内容を取得します。 ②グロナビの除去、⽬ 次のようなページの除 外、PDFのページ分割、 タイトル中の定型⽂⾔ 除去、内容の重複除去 などにより整形します。 ③Watson Discoveryへ 登録します。Discovery はRAGにおける外部情 報DBの位置付けです。 調整機能はDiscoveryの機能と独⾃機能の組み合わ せです。お客様の管理者は、必要に応じて同義語 登録、セマンティックランカーの学習、アノテー ション付与などによるチューニングができます。

🄫2024 segavvy 2024/07/25 Azure OpenAI Service Dev Day 9 サービスの仕組み（検索・質問） エンドユーザー 弊サービス Watson Discovery AOAI ChatGPT 対象Webサイト 検索・質問 ①⼊⼒⽂で検索 結果情報 ②回答⽂の⽣成（結果情報、プロンプト） 回答⽂ ③必要に応じて該当ページ・ファイルを閲覧 回答⽂ ①よくあるRAGの形ですが、Discoveryの⾃然⽂検 索機能を利⽤することでLLMによるクエリー⽣成を 省き⾼速化しています。結果情報の抽出にも Discoveryの該当センテンスを抽出する機能を利⽤ することなどで、⼊⼒トークン数を削減しています。 ②回答⽂の⽣成はAzure OpenAIのLLMで実⾏して います。お客様のデータや 要件に応じて、プロンプト、 モデル、トークン数などを 調整しています。 ③⽣成⽂や検索結果内のリンクがクリックされたら実際のページを表⽰します。

第１章 まとめ • サイト内検索は 設置企業のコンテンツに限定した検索 • ChatGPTと連携すれば 提供側と利⽤側の壁を越えられそう︕ • Watson＋ChatGPTのRAGを2023年4⽉にリリースしてみた その結果はいかに…… 第２章に続く 🄫2024 segavvy 2024/07/25 Azure OpenAI Service Dev Day 10

ʢٳܜʣࣗݾ঺հ 🄫2024 segavvy 2024/07/25 Azure OpenAI Service Dev Day 11 ͕͑͠Β ͔ͨ͠ ߐ಄ و࢙ !TFHBWWZʢηΨϏʣ גࣜձࣾΞΠΞΫτ ਓ޻஌ೳɾίάχςΟϒιϦϡʔγϣϯ෦ ΧελϚʔαΫηε՝ ՝௕ 1."*σΟϨΫλʔ ʙΤϯδχΞืूதʙ ͝ڵຯͷ͋Δํ͸!TFHBWWZ ·Ͱʂ ·ͣ͸ΏΔʙ͓͘࿩͠͠·͠ΐ͏ʂ https://qiita.com/segavvy/items/9e7e4ab4b253599ac58a "*ೖ໳ͷ͝঺հͰ͢ɻ ࡢ೥4UVEZ$PͰษڧձͰ ޷ධ͍͖ͨͩ·ͨ͠ɻ "*ͷ࢓૊ΈΛཧղ͍ͨ͠ํɺ ͓٬༷΁ͷ"*ͷઆ໌ʹۤઓ தͷํɺͥͻʂ

第２章 リリース１周年を過ぎた今 狙いどおりだったこと・予想外だったこと 🄫2024 segavvy 2024/07/25 Azure OpenAI Service Dev Day 12

RAGのサイト内検索は好評 🄫2024 segavvy 2024/07/25 Azure OpenAI Service Dev Day 13 ⽬論みどおりになってくれて⼀安⼼ ※公開情報ですが、この資料は営業⽬的では ないのでお客様名を伏せています。 サイト内検索の利⽤率 1.8倍 条件不⾜時の聞き返しで 適切な条件追加を促し 再検索後のページ到達率 2.8倍 例︓”税⾦”で検索→ ”住⺠税や固定 資産税のお問い合わせですか︖”

社内データの活⽤に使う案件も増加中 🄫2024 segavvy 2024/07/25 Azure OpenAI Service Dev Day 14 RAGブームで 社内データの活⽤にも注⽬が集まっている 製品サポート業務において マニュアル、FAQ、対応 メール履歴を対象にして 対応窓⼝の⽀援可否をPoC 業務が効率化できると 評価いただき導⼊ ※公開情報ですが、この資料は営業⽬的では ないのでお客様名を伏せています。

⽣成AIを使わない従来サービスも好調に 🄫2024 segavvy 2024/07/25 Azure OpenAI Service Dev Day 15 ⽣成AIを使わない従来のチャットボットや検索やも好調 ⾼頻度の質問は 従来のAIチャットボットで 登録済みの内容を回答 低頻度・未登録の質問は 従来のサイト内検索の 結果を提⽰ 効率よく対応できると評価 ※公開情報ですが、この資料は営業⽬的では ないのでお客様名を伏せています。

第２章 まとめ • サイト内検索のRAGは好評 • サイト内検索だけでなく 社内のデータ資産を活⽤して業務を効率化する案件も増加中 • 意外なことに ⽣成AIを使わない従来のサイト内検索やチャットボットも好調 PoCや導⼊作業を通じて 多くの知⾒が得られました 第３章につづく 🄫2024 segavvy 2024/07/25 Azure OpenAI Service Dev Day 16

ʢٳܜʣίϛϡχςΟʹײँʂ 🄫2024 segavvy 2024/07/25 Azure OpenAI Service Dev Day 17 ຊ೔͓࿩͍ͯ͠ΔฐαʔϏε΋౰ॳ͸ϫΫϫΫ͠ͳ͕ΒऔΓ૊ΜͰ͍·͕ͨ͠ Ϗδωεల։͕ܾ·͔ͬͯΒ͸େมͰͨ͠ ͓٬༷ͷ͝ཁ๬΍σʔλ͸ڭՊॻ௨Γʹ͸͍͖·ͤΜ --.͸ؤݻͰݴ͏͜ͱΛฉ͍ͯ͘ΕͣࢼߦࡨޡͰ༹͕͚͍࣌ؒͯ͘த ೔ʑ৽͍͠Կ͔͕ൃද͞Ε ΩϟονΞοϓͷ࣌ؒ΋औΕͣʹযΓ͚͕ͩͭͷΓ·͢ ͦΜͳத $IBU(15$PNNVOJUZ +1 ͸ޮ཰తʹΩϟονΞοϓͰ͖ ॴଐاۀΛ௒͑ͨଟ͘ͷಉࢤͱ஌Γ߹͍ܹ͕ࢗ΋Β͑ͯҙݟަ׵΋Ͱ͖Δ େมوॏͳ৔ʹͳΓ·ͨ͠ $IBU(15$PNNVOJUZ +1 ͱ"0"*%FW%BZͷओ࠵ɾӡӦɾεϙϯαʔͷΈͳ͞· ͦͯ͠ίϛϡχςΟʹࢀՃ͞Ε͍ͯΔΈͳ͞· ͋Γ͕ͱ͏͍͟͝·͢ʂ

第３章 この1年3ヶ⽉で得られた知⾒ いろいろあった中から６項⽬をご紹介 🄫2024 segavvy 2024/07/25 Azure OpenAI Service Dev Day 18

サイト内や企業内の情報検索がうまく実現できていない RAGの前に きちんとした情報検索の環境をつくることが⼤切 ͓٬༷͸ݕࡧʹࠔ͍ͬͯΔ 🄫2024 segavvy 2024/07/25 Azure OpenAI Service Dev Day 19 対象データ 該当データ 検索 LLM ・・・ 回答⽂ 検索に失敗すると LLMがよくても精度は出せない

ݕࡧͷௐ੔खஈ͕େ੾ ⾼精度の検索アルゴリズムが お客様のデータや⼊⼒される条件で 必ずしも⾼精度とは限らない 専⾨⽤語、社内⽤語、略語、コード名 前提が省略された質問 ⽂章ではなく単語を列挙した質問 テキスト抽出できないデータ… お客様のデータや使い⽅に合わせて 検索精度を改善できる必要がある 🄫2024 segavvy 2024/07/25 Azure OpenAI Service Dev Day 20 弊サービスの調整機能の⼀例︓セマンティックランカー 検索結果に対して「関連あり」や「関連なし」のボタンを押す ことでランカーの教師データを作成し、条件⽂とデータ内容 の関連度合いを機械学習させて結果の並びを改善できる機能 他にも同義語登録、アノテーション付与、条件⽂のサジェスト、特定 ⽂⾔に対して指定データをトップに出す機能などがある。 弊サービスはお客様の⾃⾛を理想としており、お客様⾃⾝が管理画⾯ で各種調整を実施できるようにしている。

σʔλͷ੔උ΋Ұॹʹ 企業内データの利活⽤は⼤昔からの課題 • データが散在している • ⽂書がメンテされておらず古いまま • 分類されておらず探せない • どれが最新版かわからない • 管轄が違うので簡単に修正できない • 基幹システムの⽇本語検索機能が弱い • 実はまだ紙 etc. 🄫2024 segavvy 2024/07/25 Azure OpenAI Service Dev Day 21

🄫2024 segavvy 2024/07/25 Azure OpenAI Service Dev Day 22 お客様にデータ整備の重要性を理解してもらい RAGの導⼊・運⽤と共にデータ整備を進めることが⼤切 • 社内規程や業務要綱などは簡単に修正できないが それを補うFAQやガイドラインの追加は⽐較的実施しやすく RAGの精度を⼤きく上げられる • データを⼤まかにでも分類できれば 検索時に⽬的ごとに絞り込むことで RAGの精度を⼤きく上げられる • LLMが誤読するデータは⼈間にとってもわかりにくいので サイト内検索でご利⽤いただいているある先進的なお客様は LLMが理解しやすいページをページ制作の指標に取り⼊れている σʔλͷ੔උ΋Ұॹʹ

4. LLMの役割はお客様ごとに違う RAGにおけるLLMの役割は 「検索結果に基づく回答⽂⽣成」だけではない 役割を意識したモデルの選択やプロンプトの調整が必要 • 検索結果の複数のデータから必要なものを取捨選択する • 検索結果の複数のデータを横断的に解釈する • 複雑な内容を簡潔にまとめる • 無理にまとめず 図表などによる⼀⽬瞭然の資料へ誘導する • 質問に対して不⾜情報を聞き返す etc. 🄫2024 segavvy 2024/07/25 Azure OpenAI Service Dev Day 23

5. RAGが最適とは限らない お客様の「RAGがやりたい」は要注意 • そもそもRAGはまだ万能ではない • RAGはバズワード化し始めており本来の要求・要件ではないことも RAGは⽬的ではなく⼿段の候補の1つ • 従来のチャットボット（事前登録した回答⽂を答える）の⽅が 利⽤者が誤答に気付きやすく適している場⾯も多い • 検索に困っているお客様は 検索だけで⼗分なことも多い • 従来のチャットボットで前捌きをしつつ そこで回答できなかったものを検索やRAGで補う形もおすすめ 🄫2024 segavvy 2024/07/25 Azure OpenAI Service Dev Day 24

6. 期待値を調整できるUIが必要 🄫2024 segavvy 2024/07/25 Azure OpenAI Service Dev Day 25 vs 世の中のRAGは チャットUIが 当たり前 サイト内検索と 共存するために 検索UIを選択 検索UIでリリースしたところ新たなメリットを確認 チャットボットのUIにすべきか 検索のUIにすべきか

6. 期待値を調整できるUIが必要 🄫2024 segavvy 2024/07/25 Azure OpenAI Service Dev Day 26 観点 チャットボットのUI 検索のUI ①UIの狙い 対話で要件を引き出して答える 条件に合致する情報を提⽰する ②利⽤者の期待 対話による回答を期待 検索結果の⼀覧がすぐ得られることを期待 ③誤答の影響 期待に反するので体験を損ないがち 検索結果にノイズが混ざるのは許容範囲 ④情報の 適合率 吹き出しで端的な回答をするために 検索段階での⾼い適合率が必要 検索結果にノイズの混ざることがある程度 許容されており適合率の要求が低め ⑤情報の 再現率 吹き出しでは⼤量の候補は列挙 できないので再現率が上げにくい 検索結果として情報を列挙するのは 当たり前なので再現率が上げやすい ⑥⼊⼒条件の 傾向 解決したいこと（Q）を⼊⼒する傾向 QでAを探すには⼯夫が必要 回答（A）を探す⼿掛かりを⼊⼒する傾向 そのまま検索クエリーに活⽤できる 検索UIの⽅が 利⽤者の期待値を調整しやすい※ ※あくまでも情報検索を主⽬的にRAGを使う場合の現時点の話 ⽬的・今後のAIの精度向上・マルチモーダル化などによって変わっていくはず

第３章 まとめ ಘΒΕͨ஌ݟ ͓٬༷͸ݕࡧʹࠔ͍ͬͯΔ ݕࡧͷௐ੔खஈ͕େ੾ σʔλͷ੔උ΋Ұॹʹ 4. LLMの役割はお客様ごとに違う 5. RAGが最適とは限らない 6. 期待値を調整できるUIが必要 🄫2024 segavvy 2024/07/25 Azure OpenAI Service Dev Day 27 あくまでも私個⼈が PoC・導⼊・オンボーディングに 関わった数⼗社のお客様から 感じた内容です 懇親会にも出ますので ぜひ意⾒交換しましょう︕

おわりに RAGのサービスを実際にリリースして 感じたことの共有でした 何か⼀つでも参考になることがあれば幸いです 貴重なお時間をいただき ありがとうございました︕ 🄫2024 segavvy 2024/07/25 Azure OpenAI Service Dev Day 28