RAGに関する知見

Transcript

1. 注意点 山本の感覚を多分に含みます ざっくり書いています （現状の頭の中をdumpしたものです）
2. 前提
3. LLMの問題点・RAGの目的 ユーザ 質問 誤った回答 LLM プログラム 質問 誤った回答 ユーザ 質問 正しい回答 LLM プログラム 質問 + 関連テキスト 正しい回答 参考 ドキュメント 検索 関連テキスト 通常 RAG
4. LLM 他手法との使い分け（fine-tuningとの違い） 文法・言語・論理的思考 知識・ナレッジ 口調・スタイル 簡単なfine-tuning RAG 大規模な再学習 深い 役割・立場・内容 プロンプト ※fine-tuningについては後述
5. 体験の目標レベル そのドキュメントを初めて渡された人が 色々検索しながら回答する そこそこ背景・状況をわかっている 優秀な人間が回答してくれる なんでもわかってる 気の回る完璧人間が対応してくれる 多分無理 でも目指したい できればここ 現実的にはここ 難易度が高い
6. 提供するユーザ体験 一問一答 聞かれたこと だけに答える 補足も してくれる まずはここを作る 対話としての改善 （人間とのやりとりのように） いい感じに検索してくれる （検索クエリ・オプションを自動作成） 何度も聞くことができる （会話履歴を考慮する） 分からないところを先に調べる （自律的に再検索する）
7. 基礎編
8. RAGのシステム構成 ユーザ 質問 回答 LLM プログラム 質問 + 関連テキスト 回答 参考 ドキュメント インポート 検索 システム 検索クエリ 関連テキスト 作成者/管理者に 拡充してもらう 開発側が工夫する
9. RAGのコアな部分 LLM 回答 指示 ・あなたはC社の質問受付ボット ・関連情報に基づいて回答して 関連情報 ・サービスAは〇〇です ・サービスBでは ・〇〇の場合：ーーです ・✕✕の場合：ーーです 質問 ・〇〇ってなんですか？ プロンプト 入力 出力 プロンプトの全体を工夫する （方針２） いいモデルを使う （方針１） 関連情報の渡し方を工夫する （方針３） ※ 最初は方針１・方針２は固定して 方針３のエンジニアリングに注力をすると進めやすい （パラメータを減らす）
10. 補足：失敗ケース https://dev.classmethod.jp/articles/improve-work-efficiency-with-generateive-ai-chatbot-using-rag/#toc-9
11. 方針１：いいモデルを使う 完璧人間：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の選択肢
12. 方針２：プロンプトの全体を工夫する 社員からの質問を受け付ける窓口です。 ユーザからの質問と、その回答で利用できる情報があります。 ドキュメントの情報をもとに、ユーザの質問に対する回答を生成してください。 ドキュメントはデータベースに保存されており、そのファイルパスが与えられるので考慮にいれてください。 矛盾している内容がある場合は、その旨を回答してください。 使用したドキュメントは、その番号を引用の形式で示してください 例：[0],[2] # 制約 - 質問に関係のありそうな情報にのみ基づいて回答してください。 # ドキュメントのファイルパスと内容 {available_info} # ユーザからの質問 {user_question} # 回答 → 構成・要素・形式を、必要に応じて改良する （プロンプトエンジニアリング） プロンプトの内容（現状）
13. 方針３：関連情報の渡し方を工夫する 量 質 制約が許す限り多く入れる （抜けが無いようにする・カバー率をあげる） 暗黙的な情報を入れる 観点
14. 方針３－１：関連情報の「量」を増やす プログラム 検索 システム 検索クエリ 関連テキスト 取り出す件数を できる限り増やす 検索システムの 仕様を見直す 圧縮処理を加える 方針 コスト 処理時間 （Latency） 最大トークン数 ただし制約
15. 補足：処理時間 OpenAIのChatCompletion APIの処理時間は出力トークン数に比例してそうだった https://dev.classmethod.jp/articles/measure-gpt-process-time/ 処理時間：出力トークン数に比例
16. 方針３－１－１：検索件数を増やす まずは10件が目安 可能なら20件程度入れても良いかも Helpme-botの場合 9番目・10番目のドキュメントが使われることも そこそこ有った（2・3割？） https://dev.classmethod.jp/articles/improve-work-efficiency-with-generateive-ai-chatbot-using-rag/#toc-8 ※雑メモです
17. 方針３－１－２：検索システムの仕様を見直す テキストの取り出し方が違う Kendra queryメソッド １ファイル、１箇所 Kendra retrieveメソッド １ファイルあたり、箇所の上限なし ② ③ ① ※ 改行あり ※ 改行なし ② ④ ① ④ ⑤ ⑥ ③ ⑤ ⑥ 見落としが少ない方を選ぶ （この場合だとretrieveの方が良い）
18. 方針３－１－２：検索システムの仕様を見直す ファイルを分割するのも手 ② ③ ① ③ ① ② （取り出す範囲に対して、ドキュメントサイズが大きい場合） ファイルを分割して見落としが少なくなるようにする ②
19. 方針３－１－３：情報を圧縮する https://dev.classmethod.jp/articles/qa-with-google-cloud-enterprise-search-and-retrieve-read-compose-rag/ ユーザ プログラム インデックス （ドキュメント） 質問 回答 LLM 質問 ドキュメント ✕ n件 ドキュメント + 質問 抽出した情報 抽出した情報 + 質問 回答 LLM ✕ n回 Retrieve Read Compose 追加する
20. 方針３－１－３：情報を圧縮する 目的 ・ドキュメントの数を増やしたい ただし、トークン数の制限でAPIに入らない ・圧縮する（情報抽出）処理を途中に入れる メリット・デメリット ◯：トークン数を減らせてAPIを実行できる 大量のドキュメントを読み込み対象にできる ✕：処理時間がかかる ・ストリーミング開始までが遅くなるので、 体験としてはかなり悪くなりやすい コストが増える 使用するモデル ・Gpt3.5などの性能の低いモデルでも そこまで問題ない ・回答部分のモデルがGPT4であれば、 いい感じに察してくれる ・Fine-tuningしても良い https://dev.classmethod.jp/articles/speed-up-qa-bot-with-fine-tuning/ 備考 ・ストリーミング開始が長くなると、 ユーザの印象が結構悪くなる ・PoC・導入のツマヅキになる ※雑メモです
21. 方針３－１－３：情報を圧縮する Read処理を今まで使った感想 ・ちょっと微妙かも 回答開始が遅くなるのは、 体験としてけっこう印象が良くない ・ある案件ではRead処理はなくした → そのまま後続にわたすようにした オススメは（可能なら） ・入力できるトークン数が多いモデルを使う ・関連テキストをそのまま渡す ※雑メモです 適宜使い分けるが良さそう ・どちらも試してみる ・結果が良い方を使う
22. 方針３－２：ドキュメントの「質」をあげる ※雑メモです テキストの 取り出し方を 改良する 暗黙的な情報を 追加する 検索サービスの仕様に合わせて ドキュメントを前処理する 人間は利用しているが、 システムが利用していない情報を 追加する
23. 方針３－２－１：テキストの取り出し方を改良する クエリしてみて、読み込まれ方を確認する 可能な限りMarkdownを用意する（難しければそのままでもまあOK） 結構、データごとの個別対応が必要なので頑張る もしくはお客様と合意する（対応範囲、用意するデータ） 検索サービスのさまざまな問題点（意図しない読み込み方） ・PDFがページ数・フッターなどが、 本文テキストに割り込む形で入る ・表がうまく読み込まれない ・CSVが読み込まれるときに、チャンクではヘッダ情報が抜ける → 行ごと分割して、個別にヘッダをつけて出力する JSON形式にするのもありかも ・ファイル形式としては、Markdownが一番無難 ※雑メモです 統一的な前処理方法は現状ないと思う
24. 方針３－２－２：暗黙的な情報を追加する（前提１） 人間が利用している情報とは（社内情報に関するQAの場合） ※ 山本独自の用語です 性質 １質問に関わる量 暗黙知 明文化 (ドキュメント) 暗黙知 明文化 (ドキュメント) 業務知識 社内知識 暗黙知 明文化 (ドキュメント) 業界の常識 間接的・普遍的 直接的・専門的 少ない 多い ドキュメント化されている割合
25. 方針３－２－２：暗黙的な情報を追加する（前提２） ドキュメントに付随する情報（社内情報に関するQAの場合） ドキュメント本文 メタデータ コンテキスト 「〇〇の手続き方法は」 ファイルの場所（パス・URL） 作成日時・作成者 更新日 社内状況 今までの経緯 ※ 他にもあるはず
26. 方針３－２－２：暗黙的な情報を追加する（前提３） ドキュメント本文に含まれる情報 本文テキスト 画像 リンク 「〇〇の手続き方法は」 png （リンク先情報） ※ 他にもあるはず
27. 方針３－２－２ ：暗黙的な情報を追加する（前提４） 質問に付随する情報（社内情報に関するQAの場合） 質問の本文 メタデータ コンテキスト 「〇〇はどうやったら良いですか？」 質問してきた人の名前・属性 日時 質問者と回答者の関係性 会話内容（スレッド内） 回答者が今まで質問した内容（別スレッド） 今までの経緯 ※ 他にもあるはず
28. 方針３－２－２ ：暗黙的な情報を追加する（前提５） 回答に関係する情報（社内情報に関するQAの場合） 質問本文 メタデータ コンテキスト 暗黙知 明文化 (ドキュメント) 暗黙知 明文化 (ドキュメント) 業務知識 社内知識 暗黙知 業界の常識 ドキュメント 本文 メタデータ コンテキスト 通常のQAシステムの 対象範囲 通常のQAシステムの 対象範囲 エンタープライズ検索で 検索できる（しやすい）範囲 システムが使用している情報は、人間に比べてごく一部 → できるかぎり多く、暗黙的な情報を追加する テキスト 画像 リンク 通常の検索システムの 対象範囲
29. 補足：人間が使っている暗黙的情報 暗黙知 明文化 (ドキュメント) 暗黙知 明文化 (ドキュメント) 業務知識 社内知識 暗黙知 業界の常識 エンタープライズ検索で 検索できる（しやすい）範囲 暗黙知 社会の常識 ある程度はLLMが対応できる
30. 方針３－２－２ ：補足 システムが使用している情報は、人間に比べてごく一部 だから80点くらいが限界 （現状の世の中の技術要素で、PoCレベルの実装する場合） このあたりをユーザに理解してもらう プロジェクトの前提としてお客様と合意する 評価項目を考えるときには、この点を考慮する この辺が期待値と合わない、ユースケースとそぐわない、技術的に難しい、場合 → 検索部分のみを提供する、という形もありだと思う （RAGのGは不要論） 人間の認知プロセスはかなり高度 高度な部分は人間にまかせて、自動化し易い＆煩雑な箇所をシステム化する １種の諦めも大事 ※雑メモです
31. 方針３－２－２ ：詳細 質問本文 メタデータ コンテキスト 暗黙知 明文化 (ドキュメント) 暗黙知 明文化 (ドキュメント) 業務知識 社内知識 暗黙知 業界の常識 ドキュメント 本文 メタデータ コンテキスト 通常のQAシステムの 対象範囲 通常のQAシステムの 対象範囲 エンタープライズ検索で 検索できる（しやすい）範囲 テキスト 画像 リンク 通常の検索システムの 対象範囲 検索システムを 変更する プログラムを 改良する プログラムを 改良する 別の検索システムを追加する（？） できる限り範囲をふやす （制約：そもそもデータがあるか・実装コスト・運用可能か） どうする？ (明文化してもらう)
32. 方針３－２－２－１：メタデータを付ける（ファイルパス） ※雑メモです ファイルパスを付ける ・実装しやすい ・そもそもドキュメントが階層化されている ・効果が高い ・GPTがパスをもとに情報の必要性を 判断できるようになる ・副次的な効果もある ・参考文献を出力させられる ・ユーザが内容を確認できる（安全） これくらいまでは実装したい （世の中のサービスも実装している）
33. 方針３－２－２－１：メタデータを付ける（章タイトル） ※雑メモです 章ごとにファイルを分割する （ファイル解析が必要） ファイル名_章タイトル.txtのように名前を付ける これを渡す
34. 方針３－２－２－２：ドキュメントの解析対象を広げる ※雑メモです ローダを作成して追加する ここまでくると、エンタープライズ検索のメリットが薄い → 自作した方が調整しやすい・制御しやすい
35. 方針３－２－２：他 頑張る 良いツールがあれば使う
36. まとめ RAGでいい回答が得られなかったら ・LLMを良いものに変更する ・プロンプトを少し改良する ・情報を十分・誤解なくプロンプトに書く ・ドキュメント数を増やす、検索の仕組みを考慮にいれてドキュメントを前処理する ・メタデータ・コンテキストや暗黙知になっているものが何か考え、 それをプロンプトに含めるように仕組みを改良する 難しいところ ・社内知識が必要な質問 ・暗黙知が関わっている質問 （どう読み込ませよう？そもそもどれだけあるんだろう？）
37. 補足
38. fine-tuningの難しさ１ API ・形式 ・入力テキスト ・（理想とする）出力テキスト ・学習される範囲 ・右の全部（のハズ） ・上のレイヤーの方が影響が強い（っぽい） ※雑メモです LLM 文法・言語・論理的思考 知識・ナレッジ 口調・スタイル 役割・立場・内容
39. fine-tuningの難しさ２ LLM 文法・言語・論理的思考 知識・ナレッジ 口調・スタイル 役割・立場・内容 難しい点 ・知識の学習のさせ方 ・どういうデータ形式にすればいいか？ 一問一答？会話？ドキュメント？ ・どれくらいのバリエーションが必要か？ ・データ作成 ・そもそもFAQ・ドキュメントくらいしかデータがない ・大量のドキュメントの場合、データを作るだけで大変そう ・そもそもどうやってつくるか？言語モデルを使う？ ・知識だけを学習させるには？ ・知識だけ学習させたかったのに、 一問一答の会話調を学んでしまい、回答がおかしくなる ※雑メモです
40. fine-tuningの難しさ３ プロジェクトとして ・評価をどうすればいいか？ ・汎用性が不透明 ・機械学習の根本的なところ ・うまく行かなったときに、どう分析・対処するか RAGの方が ・分析がし易い、検証しやすい ・参考文献も出せるので、ユーザで確認ができる （少し言い方を変えると、ユーザ責任にできる） → 汎用性が高く、色々なプロジェクトで使いやすい ※雑メモです LLM 文法・言語・論理的思考 知識・ナレッジ 口調・スタイル 役割・立場・内容
41. 社内知識を使った回答の難しさ１ 例： ・質問 「20期の年末年始のスケジュールを教えて」 ・ドキュメント ・2023年の年末年始 ・2022年の年末年始 ポイント ・20期が何なのか把握させる ・20期が何年に対応するのか計算させる ・1期が何年なのか教える （こうした普遍的知識に対応させる、 こうしたケースが大量にある） ※雑メモです 暗黙知 明文化 (ドキュメント) 暗黙知 明文化 (ドキュメント) 業務知識 社内知識 暗黙知 業界の常識 エンタープライズ検索で 検索できる（しやすい）範囲 別の検索システムを追加する（？）
42. 社内知識を使った回答の難しさ２ ※雑メモです 暗黙知 明文化 (ドキュメント) 暗黙知 明文化 (ドキュメント) 業務知識 社内知識 暗黙知 業界の常識 エンタープライズ検索で 検索できる（しやすい）範囲 別の検索システムを追加する（？） 対策（例） ・用語集をつくる ・質問が来たら、用語っぽいところを抜き出し 用語集に検索をかけ、結果をプロンプトに追加 問題点 ・実装が結構大変そう ・FAQ検索・シノニム機能もあるが、 容量や性能が不足している感がある ・普遍的に対応できるか疑問 ・「25期」はどうなるか ・他の知識を全部網羅できるか そもそも暗黙知が多い
43. ベクトル検索の難しい点 https://dev.classmethod.jp/articles/problem-and-improve-methods-of-vector-search/ 特に方針３ https://dev.classmethod.jp/articles/problem-and-improve-methods-of-vector-search/#toc-11
44. ズレがちなところ（単語） 「精度」 「学習」 「生成AI」「ChatGPT」
45. 体験の話（ドキュメントを使ってないケースを検出） https://dev.classmethod.jp/articles/improve-work-efficiency-with-generateive-ai-chatbot-using-rag/#toc-18
46. テキストの取り出し方：Amazon Kendra ② ③ ① ② ④ ① ④ ⑤ ⑥ ③ ⑤ ⑥ queryメソッド retrieveメソッド ・チャンク数：１ファイル１箇所 ・サイズ ：中（数百文字） ・チャンク数：１ファイルあたり上限なし ・サイズ ：中（数百文字） ・ランク ：チャンクごと
47. テキストの取り出し方：Azure AI Search ② ④ ① ③ ⑤ ⑥ ② ③ ① ④ ⑤ ⑥ query_type：simple query_type：semantic ・チャンク数：１ファイル１箇所 ・サイズ ：大（数千文字） ・チャンク数：１ファイル１箇所 ・サイズ ：中（数百文字） ② ③ ① ④ ⑤ ⑥ query_type：vector ・チャンク数：１ファイル上限なし ・サイズ ：中（数百文字） ・ランク ：チャンクごと
48. テキストの取り出し方：Google Vertex AI Search ・チャンク数：１ファイル複数箇所 ・サイズ ：中（数百文字） ・ランク ：ファイルごと ※ 複数箇所：数を設定可能 パラメータ名：max_extractive_segment_count 最大10箇所 ① ③ ④ ⑤ ⑥ ②
49. 検索の仕組み： 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（補足） ベクトルを使っていると明言されていない
50. 評価 目標 ・良い回答を出力する ・いい体験ができる ・役に立ったと感じる？ 回答が悪い・体験が悪い原因 ・ユーザの質問・使い方 ・システム ・検索 ・回答生成
51. アクセス制御（Kendraの場合） 権限設定（データソースによって異なる） ・S3の場合 ・ACL.jsonというファイルで設定する ・Webの場合 ・権限設定が無い ・そもそも誰でもアクセスできる情報、という考え方 ・他のコネクタの場合 ・試せてない ・正直使いにくい ・各サービスへのAdmin権限が必要
52. アクセス制御（Kendraの場合） 認証方法 ・トークンベース（Kendraが検証する） ・パラメータ（アプリが検証する）
53. コンテンツフィルタ https://dev.classmethod.jp/articles/methods-to-select-target-document-in-kendra-search/
54. 発展編
55. 工夫できるポイント https://dev.classmethod.jp/articles/improve-work-efficiency-with-generateive-ai-chatbot-using-rag/ まだまだたくさんある
56. 最終的には ユーザ 質問 回答 LLM プログラム 質問 + 関連テキスト 回答 参考 ドキュメント 前処理 ドキュメント 検索システム 検索クエリ 関連テキスト 前処理済み ドキュメント インポート UI 質問 回答 用語 検索システム 検索クエリ 関連テキスト インポート 他 検索システム 検索クエリ 関連テキスト 自律システム （Agent） ドキュメント 作成者・管理者 フィードバック オンボーディング 定期処理 多分これでも足りない 会話履歴
57. 体験の目標レベル そのドキュメントを初めて渡された人が 色々検索しながら回答する そこそこ背景・状況をわかっている 優秀な人間が回答してくれる なんでもわかってる 気の回る完璧人間が対応してくれる 多分無理 でも目指したい できればここ 現実的にはここ 難易度が高い
58. 提供するユーザ体験 一問一答 聞かれたこと だけに答える 補足も してくれる 対話としての改善 （人間とのやりとりのように） いい感じに検索してくれる （検索クエリ・オプションを自動作成） 何度も聞くことができる （会話履歴を考慮する） 分からないところを先に調べる （自律的に再検索する）
59. QAにおける対話とは https://dev.classmethod.jp/articles/discussion-on-needs-for-g-of-rag/ https://dev.classmethod.jp/articles/estimate-user-intention-in-genai-bot-with-rag/
60. どうモデルに良い回答をさせるか（方針） 優秀なモデルに、できる限り多くの情報を、誤解が無いように渡す 誤解しないように 工夫する おかしな回答の原因 ・紛らわしい書き方 ・メタデータが無い 十分な情報を モデルにわたす 役に立たない回答の原因 ・ドキュメントにない ・読み込めてない ・検索でヒットしない ・コンテキストがない 優秀なモデルを 使う モデルを変えると いい回答を得られることが よくある