Share
Embed
RAGのサービスをリリースして1年3ヶ月が経ちました
2024年7月25日に開催されたAzure OpenAI Service Dev Day( https://azureai.connpass.com/event/319491/ )で、AOAIのChatGPTとIBM Watson Discoveryを連携させたRAGのサービスについてお話しした際の資料です。
スライドではお伝えしきれない部分もあるので、同じ内容を記事にしてます。こちらもぜひ!
https://qiita.com/segavvy/items/78a1eff4363bc765f4da
また、同じ内容を「エンジニア達の『〇〇完全に理解した』Talk #56」でもお話しさせていただきました。その時の動画(スライド画面+音声)はこちらです。
https://www.youtube.com/watch?v=IWG4yq46VCc&t=4845s
※個人で作成したものであり、内容や意見は所属企業・部門見解を代表するものではありません。
segavvy
July 24, 2024
Transcript
28 slides
-
RAGのサービスをリリースして 1年3ヶ⽉が経ちました 多くのお客様に関わって得られた知⾒ 🄫2024 segavvy 2024/07/25 Azure OpenAI Service Dev
Day @segavvy ※個⼈で作成したものであり、内容や意⾒は所属企業・部⾨⾒解を代表するものではありません。 -
サイト内検索とは︖ 🄫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で実⾏して います。お客様のデータや 要件に応じて、プロンプト、 モデル、トークン数などを 調整しています。 ③⽣成⽂や検索結果内のリンクがクリックされたら実際のページを表⽰します。 -
第1章 まとめ • サイト内検索は 設置企業のコンテンツに限定した検索 • ChatGPTと連携すれば 提供側と利⽤側の壁を越えられそう︕ • Watson+ChatGPTのRAGを2023年4⽉にリリースしてみた
その結果はいかに…… 第2章に続く 🄫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ͰษڧձͰ ධ͍͖ͨͩ·ͨ͠ɻ "*ͷΈΛཧղ͍ͨ͠ํɺ ͓٬༷ͷ"*ͷઆ໌ʹۤઓ தͷํɺͥͻʂ -
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チャットボットで 登録済みの内容を回答 低頻度・未登録の質問は 従来のサイト内検索の 結果を提⽰ 効率よく対応できると評価 ※公開情報ですが、この資料は営業⽬的では ないのでお客様名を伏せています。 -
第2章 まとめ • サイト内検索のRAGは好評 • サイト内検索だけでなく 社内のデータ資産を活⽤して業務を効率化する案件も増加中 • 意外なことに ⽣成AIを使わない従来のサイト内検索やチャットボットも好調
PoCや導⼊作業を通じて 多くの知⾒が得られました 第3章につづく 🄫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ͷओ࠵ɾӡӦɾεϙϯαʔͷΈͳ͞· ͦͯ͠ίϛϡχςΟʹࢀՃ͞Ε͍ͯΔΈͳ͞· ͋Γ͕ͱ͏͍͟͝·͢ʂ -
サイト内や企業内の情報検索がうまく実現できていない 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の精度向上・マルチモーダル化などによって変わっていくはず -
第3章 まとめ ಘΒΕͨݟ ͓٬༷ݕࡧʹࠔ͍ͬͯΔ ݕࡧͷௐखஈ͕େ σʔλͷඋҰॹʹ 4.
LLMの役割はお客様ごとに違う 5. RAGが最適とは限らない 6. 期待値を調整できるUIが必要 🄫2024 segavvy 2024/07/25 Azure OpenAI Service Dev Day 27 あくまでも私個⼈が PoC・導⼊・オンボーディングに 関わった数⼗社のお客様から 感じた内容です 懇親会にも出ますので ぜひ意⾒交換しましょう︕