Upgrade to PRO for Only $50/Year—Limited-Time Offer! 🔥

RAGに関する知見

 RAGに関する知見

Hiroki YAMAMOTO

February 06, 2024
Tweet

More Decks by Hiroki YAMAMOTO

Other Decks in Technology

Transcript

  1. LLMの問題点・RAGの目的 ユーザ 質問 誤った回答 LLM プログラム 質問 誤った回答 ユーザ 質問

    正しい回答 LLM プログラム 質問 + 関連テキスト 正しい回答 参考 ドキュメント 検索 関連テキスト 通常 RAG
  2. 提供するユーザ体験 一問一答 聞かれたこと だけに答える 補足も してくれる まずはここを作る 対話としての改善 (人間とのやりとりのように) いい感じに検索してくれる

    (検索クエリ・オプションを自動作成) 何度も聞くことができる (会話履歴を考慮する) 分からないところを先に調べる (自律的に再検索する)
  3. RAGのシステム構成 ユーザ 質問 回答 LLM プログラム 質問 + 関連テキスト 回答

    参考 ドキュメント インポート 検索 システム 検索クエリ 関連テキスト 作成者/管理者に 拡充してもらう 開発側が工夫する
  4. RAGのコアな部分 LLM 回答 指示 ・あなたはC社の質問受付ボット ・関連情報に基づいて回答して 関連情報 ・サービスAは〇〇です ・サービスBでは ・〇〇の場合:ーーです

    ・✕✕の場合:ーーです 質問 ・〇〇ってなんですか? プロンプト 入力 出力 プロンプトの全体を工夫する (方針2) いいモデルを使う (方針1) 関連情報の渡し方を工夫する (方針3) ※ 最初は方針1・方針2は固定して 方針3のエンジニアリングに注力をすると進めやすい (パラメータを減らす)
  5. 方針1:いいモデルを使う 完璧人間:100点 普通人間:85点 Gpt-3.5-turbo :50~60点 Claude V1 Instant:40~50点 GPT4 80~85点

    情報が十分にあれば 人間と同様のレベルに回答できる Claude V2 70~75点 Gemini ?点 → 基本的にGPT4がオススメ、要件的に難しければClaude V2 (2023年9月10月時点でのPalm2では、いい回答が出力されなかった) LLMの選択肢
  6. 方針3-1-2:検索システムの仕様を見直す テキストの取り出し方が違う Kendra queryメソッド 1ファイル、1箇所 Kendra retrieveメソッド 1ファイルあたり、箇所の上限なし ② ③

    ① ※ 改行あり ※ 改行なし ② ④ ① ④ ⑤ ⑥ ③ ⑤ ⑥ 見落としが少ない方を選ぶ (この場合だとretrieveの方が良い)
  7. 方針3-1-3:情報を圧縮する 目的 ・ドキュメントの数を増やしたい ただし、トークン数の制限でAPIに入らない ・圧縮する(情報抽出)処理を途中に入れる メリット・デメリット ◯:トークン数を減らせてAPIを実行できる 大量のドキュメントを読み込み対象にできる ✕:処理時間がかかる ・ストリーミング開始までが遅くなるので、

    体験としてはかなり悪くなりやすい コストが増える 使用するモデル ・Gpt3.5などの性能の低いモデルでも そこまで問題ない ・回答部分のモデルがGPT4であれば、 いい感じに察してくれる ・Fine-tuningしても良い https://dev.classmethod.jp/articles/speed-up-qa-bot-with-fine-tuning/ 備考 ・ストリーミング開始が長くなると、 ユーザの印象が結構悪くなる ・PoC・導入のツマヅキになる ※雑メモです
  8. 方針3-2-2:暗黙的な情報を追加する(前提1) 人間が利用している情報とは(社内情報に関するQAの場合) ※ 山本独自の用語です 性質 1質問に関わる量 暗黙知 明文化 (ドキュメント) 暗黙知

    明文化 (ドキュメント) 業務知識 社内知識 暗黙知 明文化 (ドキュメント) 業界の常識 間接的・普遍的 直接的・専門的 少ない 多い ドキュメント化されている割合
  9. 方針3-2-2 :暗黙的な情報を追加する(前提5) 回答に関係する情報(社内情報に関するQAの場合) 質問本文 メタデータ コンテキスト 暗黙知 明文化 (ドキュメント) 暗黙知

    明文化 (ドキュメント) 業務知識 社内知識 暗黙知 業界の常識 ドキュメント 本文 メタデータ コンテキスト 通常のQAシステムの 対象範囲 通常のQAシステムの 対象範囲 エンタープライズ検索で 検索できる(しやすい)範囲 システムが使用している情報は、人間に比べてごく一部 → できるかぎり多く、暗黙的な情報を追加する テキスト 画像 リンク 通常の検索システムの 対象範囲
  10. 補足:人間が使っている暗黙的情報 暗黙知 明文化 (ドキュメント) 暗黙知 明文化 (ドキュメント) 業務知識 社内知識 暗黙知

    業界の常識 エンタープライズ検索で 検索できる(しやすい)範囲 暗黙知 社会の常識 ある程度はLLMが対応できる
  11. 方針3-2-2 :詳細 質問本文 メタデータ コンテキスト 暗黙知 明文化 (ドキュメント) 暗黙知 明文化

    (ドキュメント) 業務知識 社内知識 暗黙知 業界の常識 ドキュメント 本文 メタデータ コンテキスト 通常のQAシステムの 対象範囲 通常のQAシステムの 対象範囲 エンタープライズ検索で 検索できる(しやすい)範囲 テキスト 画像 リンク 通常の検索システムの 対象範囲 検索システムを 変更する プログラムを 改良する プログラムを 改良する 別の検索システムを追加する(?) できる限り範囲をふやす (制約:そもそもデータがあるか・実装コスト・運用可能か) どうする? (明文化してもらう)
  12. fine-tuningの難しさ2 LLM 文法・言語・論理的思考 知識・ナレッジ 口調・スタイル 役割・立場・内容 難しい点 ・知識の学習のさせ方 ・どういうデータ形式にすればいいか? 一問一答?会話?ドキュメント?

    ・どれくらいのバリエーションが必要か? ・データ作成 ・そもそもFAQ・ドキュメントくらいしかデータがない ・大量のドキュメントの場合、データを作るだけで大変そう ・そもそもどうやってつくるか?言語モデルを使う? ・知識だけを学習させるには? ・知識だけ学習させたかったのに、 一問一答の会話調を学んでしまい、回答がおかしくなる ※雑メモです
  13. 社内知識を使った回答の難しさ1 例: ・質問 「20期の年末年始のスケジュールを教えて」 ・ドキュメント ・2023年の年末年始 ・2022年の年末年始 ポイント ・20期が何なのか把握させる ・20期が何年に対応するのか計算させる

    ・1期が何年なのか教える (こうした普遍的知識に対応させる、 こうしたケースが大量にある) ※雑メモです 暗黙知 明文化 (ドキュメント) 暗黙知 明文化 (ドキュメント) 業務知識 社内知識 暗黙知 業界の常識 エンタープライズ検索で 検索できる(しやすい)範囲 別の検索システムを追加する(?)
  14. 社内知識を使った回答の難しさ2 ※雑メモです 暗黙知 明文化 (ドキュメント) 暗黙知 明文化 (ドキュメント) 業務知識 社内知識

    暗黙知 業界の常識 エンタープライズ検索で 検索できる(しやすい)範囲 別の検索システムを追加する(?) 対策(例) ・用語集をつくる ・質問が来たら、用語っぽいところを抜き出し 用語集に検索をかけ、結果をプロンプトに追加 問題点 ・実装が結構大変そう ・FAQ検索・シノニム機能もあるが、 容量や性能が不足している感がある ・普遍的に対応できるか疑問 ・「25期」はどうなるか ・他の知識を全部網羅できるか そもそも暗黙知が多い
  15. テキストの取り出し方:Amazon Kendra ② ③ ① ② ④ ① ④ ⑤

    ⑥ ③ ⑤ ⑥ queryメソッド retrieveメソッド ・チャンク数:1ファイル1箇所 ・サイズ :中(数百文字) ・チャンク数:1ファイルあたり上限なし ・サイズ :中(数百文字) ・ランク :チャンクごと
  16. テキストの取り出し方:Azure AI Search ② ④ ① ③ ⑤ ⑥ ②

    ③ ① ④ ⑤ ⑥ query_type:simple query_type:semantic ・チャンク数:1ファイル1箇所 ・サイズ :大(数千文字) ・チャンク数:1ファイル1箇所 ・サイズ :中(数百文字) ② ③ ① ④ ⑤ ⑥ query_type:vector ・チャンク数:1ファイル上限なし ・サイズ :中(数百文字) ・ランク :チャンクごと
  17. テキストの取り出し方:Google Vertex AI Search ・チャンク数:1ファイル複数箇所 ・サイズ :中(数百文字) ・ランク :ファイルごと ※

    複数箇所:数を設定可能 パラメータ名:max_extractive_segment_count 最大10箇所 ① ③ ④ ⑤ ⑥ ②
  18. 検索の仕組み: Amazon Kendra ・全チャンクをセマンティック検索で比較 Azure AI Search ・query_type:simple ・単なる全文検索 ・query_type:semantic

    ・simpleの結果を、セマンティックに再ランク ・query_type:vector ・全チャンクをベクトル検索 Google AI Search ・全チャンクをベクトル検索 Azure Ai Search(補足) ・query_type:semantic ドキュメントと同じワードが 検索クエリに無いとヒットしない → vectorの方が良さそう Amazon Kendra(補足) ベクトルを使っていると明言されていない
  19. 最終的には ユーザ 質問 回答 LLM プログラム 質問 + 関連テキスト 回答

    参考 ドキュメント 前処理 ドキュメント 検索システム 検索クエリ 関連テキスト 前処理済み ドキュメント インポート UI 質問 回答 用語 検索システム 検索クエリ 関連テキスト インポート 他 検索システム 検索クエリ 関連テキスト 自律システム (Agent) ドキュメント 作成者・管理者 フィードバック オンボーディング 定期処理 多分これでも足りない 会話履歴