RAGに関する知見 - Speaker Deck

RAGに関する知見

by Hiroki YAMAMOTO

Slide 1

Slide 1 text

注意点山本の感覚を多分に含みますざっくり書いています（現状の頭の中をdumpしたものです）

Slide 2

Slide 2 text

前提

Slide 3

Slide 3 text

LLMの問題点・RAGの目的ユーザ質問誤った回答 LLM プログラム質問誤った回答ユーザ質問正しい回答 LLM プログラム質問 + 関連テキスト正しい回答参考ドキュメント検索関連テキスト通常 RAG

Slide 4

Slide 4 text

LLM 他手法との使い分け（fine-tuningとの違い）文法・言語・論理的思考知識・ナレッジ口調・スタイル簡単なfine-tuning RAG 大規模な再学習深い役割・立場・内容プロンプト ※fine-tuningについては後述

Slide 5

Slide 5 text

体験の目標レベルそのドキュメントを初めて渡された人が色々検索しながら回答するそこそこ背景・状況をわかっている優秀な人間が回答してくれるなんでもわかってる気の回る完璧人間が対応してくれる多分無理でも目指したいできればここ現実的にはここ難易度が高い

Slide 6

Slide 6 text

提供するユーザ体験一問一答聞かれたことだけに答える補足もしてくれるまずはここを作る対話としての改善（人間とのやりとりのように）いい感じに検索してくれる（検索クエリ・オプションを自動作成）何度も聞くことができる（会話履歴を考慮する）分からないところを先に調べる（自律的に再検索する）

Slide 7

Slide 7 text

基礎編

Slide 8

Slide 8 text

RAGのシステム構成ユーザ質問回答 LLM プログラム質問 + 関連テキスト回答参考ドキュメントインポート検索システム検索クエリ関連テキスト作成者/管理者に拡充してもらう開発側が工夫する

Slide 9

Slide 9 text

RAGのコアな部分 LLM 回答指示・あなたはC社の質問受付ボット・関連情報に基づいて回答して関連情報・サービスAは〇〇です・サービスBでは・〇〇の場合：ーーです・✕✕の場合：ーーです質問・〇〇ってなんですか？プロンプト入力出力プロンプトの全体を工夫する（方針２）いいモデルを使う（方針１）関連情報の渡し方を工夫する（方針３） ※ 最初は方針１・方針２は固定して方針３のエンジニアリングに注力をすると進めやすい（パラメータを減らす）

Slide 10

Slide 10 text

補足：失敗ケース https://dev.classmethod.jp/articles/improve-work-efficiency-with-generateive-ai-chatbot-using-rag/#toc-9

Slide 11

Slide 11 text

方針１：いいモデルを使う完璧人間：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の選択肢

Slide 12

Slide 12 text

方針２：プロンプトの全体を工夫する社員からの質問を受け付ける窓口です。ユーザからの質問と、その回答で利用できる情報があります。ドキュメントの情報をもとに、ユーザの質問に対する回答を生成してください。ドキュメントはデータベースに保存されており、そのファイルパスが与えられるので考慮にいれてください。矛盾している内容がある場合は、その旨を回答してください。使用したドキュメントは、その番号を引用の形式で示してください例：[0],[2] # 制約 - 質問に関係のありそうな情報にのみ基づいて回答してください。 # ドキュメントのファイルパスと内容 {available_info} # ユーザからの質問 {user_question} # 回答 → 構成・要素・形式を、必要に応じて改良する（プロンプトエンジニアリング）プロンプトの内容（現状）

Slide 13

Slide 13 text

方針３：関連情報の渡し方を工夫する量質制約が許す限り多く入れる（抜けが無いようにする・カバー率をあげる）暗黙的な情報を入れる観点

Slide 14

Slide 14 text

方針３－１：関連情報の「量」を増やすプログラム検索システム検索クエリ関連テキスト取り出す件数をできる限り増やす検索システムの仕様を見直す圧縮処理を加える方針コスト処理時間（Latency）最大トークン数ただし制約

Slide 15

Slide 15 text

補足：処理時間 OpenAIのChatCompletion APIの処理時間は出力トークン数に比例してそうだった https://dev.classmethod.jp/articles/measure-gpt-process-time/ 処理時間：出力トークン数に比例

Slide 16

Slide 16 text

方針３－１－１：検索件数を増やすまずは10件が目安可能なら20件程度入れても良いかも Helpme-botの場合 9番目・10番目のドキュメントが使われることもそこそこ有った（2・3割？） https://dev.classmethod.jp/articles/improve-work-efficiency-with-generateive-ai-chatbot-using-rag/#toc-8 ※雑メモです

Slide 17

Slide 17 text

方針３－１－２：検索システムの仕様を見直すテキストの取り出し方が違う Kendra queryメソッド１ファイル、１箇所 Kendra retrieveメソッド１ファイルあたり、箇所の上限なし ② ③ ① ※ 改行あり ※ 改行なし ② ④ ① ④ ⑤ ⑥ ③ ⑤ ⑥ 見落としが少ない方を選ぶ（この場合だとretrieveの方が良い）

Slide 18

Slide 18 text

方針３－１－２：検索システムの仕様を見直すファイルを分割するのも手 ② ③ ① ③ ① ② （取り出す範囲に対して、ドキュメントサイズが大きい場合）ファイルを分割して見落としが少なくなるようにする ②

Slide 19

Slide 19 text

方針３－１－３：情報を圧縮する https://dev.classmethod.jp/articles/qa-with-google-cloud-enterprise-search-and-retrieve-read-compose-rag/ ユーザプログラムインデックス（ドキュメント）質問回答 LLM 質問ドキュメント ✕ n件ドキュメント + 質問抽出した情報抽出した情報 + 質問回答 LLM ✕ n回 Retrieve Read Compose 追加する

Slide 20

Slide 20 text

方針３－１－３：情報を圧縮する目的・ドキュメントの数を増やしたいただし、トークン数の制限でAPIに入らない・圧縮する（情報抽出）処理を途中に入れるメリット・デメリット ◯：トークン数を減らせてAPIを実行できる大量のドキュメントを読み込み対象にできる ✕：処理時間がかかる・ストリーミング開始までが遅くなるので、体験としてはかなり悪くなりやすいコストが増える使用するモデル・Gpt3.5などの性能の低いモデルでもそこまで問題ない・回答部分のモデルがGPT4であれば、いい感じに察してくれる・Fine-tuningしても良い https://dev.classmethod.jp/articles/speed-up-qa-bot-with-fine-tuning/ 備考・ストリーミング開始が長くなると、ユーザの印象が結構悪くなる・PoC・導入のツマヅキになる ※雑メモです

Slide 21

Slide 21 text

方針３－１－３：情報を圧縮する Read処理を今まで使った感想・ちょっと微妙かも回答開始が遅くなるのは、体験としてけっこう印象が良くない・ある案件ではRead処理はなくした → そのまま後続にわたすようにしたオススメは（可能なら）・入力できるトークン数が多いモデルを使う・関連テキストをそのまま渡す ※雑メモです適宜使い分けるが良さそう・どちらも試してみる・結果が良い方を使う

Slide 22

Slide 22 text

方針３－２：ドキュメントの「質」をあげる ※雑メモですテキストの取り出し方を改良する暗黙的な情報を追加する検索サービスの仕様に合わせてドキュメントを前処理する人間は利用しているが、システムが利用していない情報を追加する

Slide 23

Slide 23 text

方針３－２－１：テキストの取り出し方を改良するクエリしてみて、読み込まれ方を確認する可能な限りMarkdownを用意する（難しければそのままでもまあOK）結構、データごとの個別対応が必要なので頑張るもしくはお客様と合意する（対応範囲、用意するデータ）検索サービスのさまざまな問題点（意図しない読み込み方）・PDFがページ数・フッターなどが、本文テキストに割り込む形で入る・表がうまく読み込まれない・CSVが読み込まれるときに、チャンクではヘッダ情報が抜ける → 行ごと分割して、個別にヘッダをつけて出力する JSON形式にするのもありかも・ファイル形式としては、Markdownが一番無難 ※雑メモです統一的な前処理方法は現状ないと思う

Slide 24

Slide 24 text

方針３－２－２：暗黙的な情報を追加する（前提１）人間が利用している情報とは（社内情報に関するQAの場合） ※ 山本独自の用語です性質１質問に関わる量暗黙知明文化 (ドキュメント) 暗黙知明文化 (ドキュメント) 業務知識社内知識暗黙知明文化 (ドキュメント) 業界の常識間接的・普遍的直接的・専門的少ない多いドキュメント化されている割合

Slide 25

Slide 25 text

方針３－２－２：暗黙的な情報を追加する（前提２）ドキュメントに付随する情報（社内情報に関するQAの場合）ドキュメント本文メタデータコンテキスト「〇〇の手続き方法は」ファイルの場所（パス・URL）作成日時・作成者更新日社内状況今までの経緯 ※ 他にもあるはず

Slide 26

Slide 26 text

方針３－２－２：暗黙的な情報を追加する（前提３）ドキュメント本文に含まれる情報本文テキスト画像リンク「〇〇の手続き方法は」 png （リンク先情報） ※ 他にもあるはず

Slide 27

Slide 27 text

方針３－２－２：暗黙的な情報を追加する（前提４）質問に付随する情報（社内情報に関するQAの場合）質問の本文メタデータコンテキスト「〇〇はどうやったら良いですか？」質問してきた人の名前・属性日時質問者と回答者の関係性会話内容（スレッド内）回答者が今まで質問した内容（別スレッド）今までの経緯 ※ 他にもあるはず

Slide 28

Slide 28 text

方針３－２－２：暗黙的な情報を追加する（前提５）回答に関係する情報（社内情報に関するQAの場合）質問本文メタデータコンテキスト暗黙知明文化 (ドキュメント) 暗黙知明文化 (ドキュメント) 業務知識社内知識暗黙知業界の常識ドキュメント本文メタデータコンテキスト通常のQAシステムの対象範囲通常のQAシステムの対象範囲エンタープライズ検索で検索できる（しやすい）範囲システムが使用している情報は、人間に比べてごく一部 → できるかぎり多く、暗黙的な情報を追加するテキスト画像リンク通常の検索システムの対象範囲

Slide 29

Slide 29 text

補足：人間が使っている暗黙的情報暗黙知明文化 (ドキュメント) 暗黙知明文化 (ドキュメント) 業務知識社内知識暗黙知業界の常識エンタープライズ検索で検索できる（しやすい）範囲暗黙知社会の常識ある程度はLLMが対応できる

Slide 30

Slide 30 text

方針３－２－２：補足システムが使用している情報は、人間に比べてごく一部だから80点くらいが限界（現状の世の中の技術要素で、PoCレベルの実装する場合）このあたりをユーザに理解してもらうプロジェクトの前提としてお客様と合意する評価項目を考えるときには、この点を考慮するこの辺が期待値と合わない、ユースケースとそぐわない、技術的に難しい、場合 → 検索部分のみを提供する、という形もありだと思う（RAGのGは不要論）人間の認知プロセスはかなり高度高度な部分は人間にまかせて、自動化し易い＆煩雑な箇所をシステム化する１種の諦めも大事 ※雑メモです

Slide 31

Slide 31 text

方針３－２－２：詳細質問本文メタデータコンテキスト暗黙知明文化 (ドキュメント) 暗黙知明文化 (ドキュメント) 業務知識社内知識暗黙知業界の常識ドキュメント本文メタデータコンテキスト通常のQAシステムの対象範囲通常のQAシステムの対象範囲エンタープライズ検索で検索できる（しやすい）範囲テキスト画像リンク通常の検索システムの対象範囲検索システムを変更するプログラムを改良するプログラムを改良する別の検索システムを追加する（？）できる限り範囲をふやす（制約：そもそもデータがあるか・実装コスト・運用可能か）どうする？ (明文化してもらう)

Slide 32

Slide 32 text

方針３－２－２－１：メタデータを付ける（ファイルパス） ※雑メモですファイルパスを付ける・実装しやすい・そもそもドキュメントが階層化されている・効果が高い・GPTがパスをもとに情報の必要性を判断できるようになる・副次的な効果もある・参考文献を出力させられる・ユーザが内容を確認できる（安全）これくらいまでは実装したい（世の中のサービスも実装している）

Slide 33

Slide 33 text

方針３－２－２－１：メタデータを付ける（章タイトル） ※雑メモです章ごとにファイルを分割する（ファイル解析が必要）ファイル名_章タイトル.txtのように名前を付けるこれを渡す

Slide 34

Slide 34 text

方針３－２－２－２：ドキュメントの解析対象を広げる ※雑メモですローダを作成して追加するここまでくると、エンタープライズ検索のメリットが薄い → 自作した方が調整しやすい・制御しやすい

Slide 35

Slide 35 text

方針３－２－２：他頑張る良いツールがあれば使う

Slide 36

Slide 36 text

まとめ RAGでいい回答が得られなかったら・LLMを良いものに変更する・プロンプトを少し改良する・情報を十分・誤解なくプロンプトに書く・ドキュメント数を増やす、検索の仕組みを考慮にいれてドキュメントを前処理する・メタデータ・コンテキストや暗黙知になっているものが何か考え、それをプロンプトに含めるように仕組みを改良する難しいところ・社内知識が必要な質問・暗黙知が関わっている質問（どう読み込ませよう？そもそもどれだけあるんだろう？）

Slide 37

Slide 37 text

補足

Slide 38

Slide 38 text

fine-tuningの難しさ１ API ・形式・入力テキスト・（理想とする）出力テキスト・学習される範囲・右の全部（のハズ）・上のレイヤーの方が影響が強い（っぽい） ※雑メモです LLM 文法・言語・論理的思考知識・ナレッジ口調・スタイル役割・立場・内容

Slide 39

Slide 39 text

fine-tuningの難しさ２ LLM 文法・言語・論理的思考知識・ナレッジ口調・スタイル役割・立場・内容難しい点・知識の学習のさせ方・どういうデータ形式にすればいいか？一問一答？会話？ドキュメント？・どれくらいのバリエーションが必要か？・データ作成・そもそもFAQ・ドキュメントくらいしかデータがない・大量のドキュメントの場合、データを作るだけで大変そう・そもそもどうやってつくるか？言語モデルを使う？・知識だけを学習させるには？・知識だけ学習させたかったのに、一問一答の会話調を学んでしまい、回答がおかしくなる ※雑メモです

Slide 40

Slide 40 text

fine-tuningの難しさ３プロジェクトとして・評価をどうすればいいか？・汎用性が不透明・機械学習の根本的なところ・うまく行かなったときに、どう分析・対処するか RAGの方が・分析がし易い、検証しやすい・参考文献も出せるので、ユーザで確認ができる（少し言い方を変えると、ユーザ責任にできる） → 汎用性が高く、色々なプロジェクトで使いやすい ※雑メモです LLM 文法・言語・論理的思考知識・ナレッジ口調・スタイル役割・立場・内容

Slide 41

Slide 41 text

社内知識を使った回答の難しさ１例：・質問「20期の年末年始のスケジュールを教えて」・ドキュメント・2023年の年末年始・2022年の年末年始ポイント・20期が何なのか把握させる・20期が何年に対応するのか計算させる・1期が何年なのか教える（こうした普遍的知識に対応させる、こうしたケースが大量にある） ※雑メモです暗黙知明文化 (ドキュメント) 暗黙知明文化 (ドキュメント) 業務知識社内知識暗黙知業界の常識エンタープライズ検索で検索できる（しやすい）範囲別の検索システムを追加する（？）

Slide 42

Slide 42 text

社内知識を使った回答の難しさ２ ※雑メモです暗黙知明文化 (ドキュメント) 暗黙知明文化 (ドキュメント) 業務知識社内知識暗黙知業界の常識エンタープライズ検索で検索できる（しやすい）範囲別の検索システムを追加する（？）対策（例）・用語集をつくる・質問が来たら、用語っぽいところを抜き出し用語集に検索をかけ、結果をプロンプトに追加問題点・実装が結構大変そう・FAQ検索・シノニム機能もあるが、容量や性能が不足している感がある・普遍的に対応できるか疑問・「25期」はどうなるか・他の知識を全部網羅できるかそもそも暗黙知が多い

Slide 43

Slide 43 text

ベクトル検索の難しい点 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

Slide 44

Slide 44 text

ズレがちなところ（単語）「精度」「学習」「生成AI」「ChatGPT」

Slide 45

Slide 45 text

体験の話（ドキュメントを使ってないケースを検出） https://dev.classmethod.jp/articles/improve-work-efficiency-with-generateive-ai-chatbot-using-rag/#toc-18

Slide 46

Slide 46 text

テキストの取り出し方：Amazon Kendra ② ③ ① ② ④ ① ④ ⑤ ⑥ ③ ⑤ ⑥ queryメソッド retrieveメソッド・チャンク数：１ファイル１箇所・サイズ：中（数百文字）・チャンク数：１ファイルあたり上限なし・サイズ：中（数百文字）・ランク：チャンクごと

Slide 47

Slide 47 text

テキストの取り出し方：Azure AI Search ② ④ ① ③ ⑤ ⑥ ② ③ ① ④ ⑤ ⑥ query_type：simple query_type：semantic ・チャンク数：１ファイル１箇所・サイズ：大（数千文字）・チャンク数：１ファイル１箇所・サイズ：中（数百文字） ② ③ ① ④ ⑤ ⑥ query_type：vector ・チャンク数：１ファイル上限なし・サイズ：中（数百文字）・ランク：チャンクごと

Slide 48

Slide 48 text

テキストの取り出し方：Google Vertex AI Search ・チャンク数：１ファイル複数箇所・サイズ：中（数百文字）・ランク：ファイルごと ※ 複数箇所：数を設定可能パラメータ名：max_extractive_segment_count 最大10箇所 ① ③ ④ ⑤ ⑥ ②

Slide 49

Slide 49 text

検索の仕組み： 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（補足）ベクトルを使っていると明言されていない

Slide 50

Slide 50 text

評価目標・良い回答を出力する・いい体験ができる・役に立ったと感じる？回答が悪い・体験が悪い原因・ユーザの質問・使い方・システム・検索・回答生成

Slide 51

Slide 51 text

アクセス制御（Kendraの場合）権限設定（データソースによって異なる）・S3の場合・ACL.jsonというファイルで設定する・Webの場合・権限設定が無い・そもそも誰でもアクセスできる情報、という考え方・他のコネクタの場合・試せてない・正直使いにくい・各サービスへのAdmin権限が必要

Slide 52

Slide 52 text

アクセス制御（Kendraの場合）認証方法・トークンベース（Kendraが検証する）・パラメータ（アプリが検証する）

Slide 53

Slide 53 text

コンテンツフィルタ https://dev.classmethod.jp/articles/methods-to-select-target-document-in-kendra-search/

Slide 54

Slide 54 text

発展編

Slide 55

Slide 55 text

工夫できるポイント https://dev.classmethod.jp/articles/improve-work-efficiency-with-generateive-ai-chatbot-using-rag/ まだまだたくさんある

Slide 56

Slide 56 text

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

Slide 57

Slide 57 text

Slide 58

Slide 58 text

提供するユーザ体験一問一答聞かれたことだけに答える補足もしてくれる対話としての改善（人間とのやりとりのように）いい感じに検索してくれる（検索クエリ・オプションを自動作成）何度も聞くことができる（会話履歴を考慮する）分からないところを先に調べる（自律的に再検索する）

Slide 59

Slide 59 text

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/

Slide 60

Slide 60 text

どうモデルに良い回答をさせるか（方針）優秀なモデルに、できる限り多くの情報を、誤解が無いように渡す誤解しないように工夫するおかしな回答の原因・紛らわしい書き方・メタデータが無い十分な情報をモデルにわたす役に立たない回答の原因・ドキュメントにない・読み込めてない・検索でヒットしない・コンテキストがない優秀なモデルを使うモデルを変えるといい回答を得られることがよくある