実務におけるRAG 〜学びと現場のノウハウ〜

実務におけるRAG 〜学びと現場のノウハウ〜 hoxo-m

目次 RAGの基礎 2. 実務におけるRAG〜学びと現場のノウハウ〜 3. RAGの性能評価 4. まとめと展望 1. 2

1. RAGの基礎 3

RAG (Retrieval-Augmented Generation)とは ● 外部データをRetrieval（検索）して ● プロンプトをAugument（拡張）し ● クエリに対する回答をGeneration（生成） ○ クエリ := ユーザからの問合せ ・・・する技術 ※本講義では「インプット＝クエリ＋プロンプト」と定義 4

RAG (Retrieval-Augmented Generation)とは 登場人物＿＿＿＿＿＿＿＿＿＿＿＿＿＿ ビジネスでの応用先はLLMが大多数＿ ❶検索アルゴリズム ● ・ベクトル検索、全文検索、及びその組合せ （Hybrid検索）がよく使用される ・…が、それに限るものではない ● ビジネスでは”言語”の基盤モデル （LLM）への応用が多い ○ 本講義も LLMに注力 一方、言語以外のモーダル （画像・音声等）も研究開発中 ❷拡張処理アルゴリズム ・LLMへのインプットを拡張 ❸基盤モデル ・OpenAI APIを叩く、Local LLMで回答させ る等の部分 ・本講義では所与として説明 5

RAGのご利益 ● 正確性が高い ○ 関連情報を外部データ（DB/資料/Web等）から検索することで、 LLMにない知識も参照できるため回答の正確性が向上 ● 適合性が高い ○ インプットに基づいた回答をするため、文脈への適合性が高い ● 拡張性がある ○ 知識ベースを拡充し、幅広い質問に拡張可能 ○ 検索手法やLLMの改良で、RAGのパフォーマンスを向上可能 結果、ユーザーエクスペリエンスや満足度の向上につながる ● 正確で文脈に即したユーザーの質問に対して的確な回答 ● より自然なインタラクションが実現し、ユーザーの満足度が向上 6

2. 実務におけるRAG〜学びと現場のノウハウ〜 7

RAGと他手法の使い分け 拡張項目＿＿＿ 手法＿＿＿＿＿＿＿＿＿＿＿ 役割・振る舞い プロンプトエンジニアリング 知識 RAG 口調・出力形式 Fine Tuning 基礎能力 継続事前学習 コスト＿ 8

RAG/Fine Tuningの使い分けは、OpenAI公式動画でも言及 Takeaway プロンプトエンジニアリングの次は Fine-tuningではなく、 RAGを検討しよう A Survey of Techniques for Maximizing LLM Performance (Youtube) 9

• https://www.youtube.com/watch?v=ahnGLM-RC1Y

LLMのコンテキスト容量の増大を受けて… ･･･書籍10冊分 ･･･書籍 1冊分 ･･･A4レポート10枚 (出典) 宮城のデスクトップリサーチ調べ 10

長コンテキストモデルの性能が向上し、RAGの性能に迫る RAG ● GeckoでEmbeddingし検索 ● Top-40の関連資料をContextに ● ● https://arxiv.org/abs/2406.13121v1 https://arxiv.org/abs/2403.20327 11

• https://arxiv.org/abs/2406.13121v1
• https://arxiv.org/abs/2403.20327

RAG不要論も出現 https://x.com/agishaun/status/1758561862764122191 12

• https://x.com/agishaun/status/1758561862764122191?s=20

一方、RAG不要論への反論も（hoxo-mも同意見） RAGが不要にならない理由（左記の要約） 関連コンテキスト ● 適切な検索とランキングがない場合、モデ ルが無関係な情報で混乱/性能劣化するリ スクがある 効果的な推論 ● 大規模なコンテキストサイズでモデルが効 果的に推論できるか不明瞭 (needle-in-a-haystack、後述) コスト ● 大規模なコンテキストを扱うことは 従量課金体系から高コスト Takeaway https://applied-llms.org/#long-context-models-wont-make-rag-obsolete （多分）RAGは不要にならない 13

• https://applied-llms.org/#long-context-models-wont-make-rag-obsolete

(Multi) Needle in a Haystack ● ● 事実 (針) がコンテキスト (干し草の山) に挿入される ○ 事実：美味しいピザ作りのための秘密の材料 ○ コンテキスト例: Paul Graham のエッセイ 「挿入された針に関する質問に答えられるか？」を評価 https://blog.langchain.dev/multi-needle-in-a-haystack/ 14

• https://blog.langchain.dev/multi-needle-in-a-haystack/

(Multi) Needle in a Haystack 針を見つけられた割合 10個の針が見つかる割合 ・長コンテクストで性能劣化 ・(GPT-4は)最後の方に針が 配置されていると見つかりやすい Takeaway https://blog.langchain.dev/multi-needle-in-a-haystack/ モデルごとに好みの配置にクセがある 15

• https://blog.langchain.dev/multi-needle-in-a-haystack/

関連しない文章（黄色）の挿入は、 何も入れない（水色）に比べて、精度悪化 Making Retrieval-Augmented Language Models Robust to Irrelevant Context Takeaway 余計な情報は入れない 16

• https://arxiv.org/abs/2310.01558

方針: Advanced RAG(一部)まで”改善しやすい仕組み作り” まで含めて開発、改善を繰り返しModular RAGを目指す 改善しやすい仕組み ● 自動テスト ● 特定テスト実行 ● モデル/Retriever間 比較 ● モデル/Retrieverの 簡易入れ替え Retrieval-Augmented Generation for Large Language Models: A Survey 17

• https://arxiv.org/abs/2312.10997

改善項目 at a glance (1/2) Takeaway 全体感を掴んだ上で、 改善項目を考える https://github.com/langchain-ai/rag-from-scratch 18

• https://github.com/langchain-ai/rag-from-scratch

改善項目 at a glance (2/2) Takeaway 全体感を掴んだ上で、 改善項目を考える https://www.llamaindex.ai/blog/a-cheat-sheet-and-some-recipes-for-building-advanced-rag-803a9d94c41b 19

• https://www.llamaindex.ai/blog/a-cheat-sheet-and-some-recipes-for-building-advanced-rag-803a9d94c41b

初手”ベストプラクティス論文に倣う”も一案 ● 青字：ベスプラ ● 太字：オプション ● 下線：デフォルト 検索結果を ”入れる場所” https://arxiv.org/abs/2407.01219 検索結果の ”並べ替え” 20

• https://arxiv.org/abs/2407.01219

OpenAI直伝の”RAG成功ストーリー” 精度45%➔65% ● ⭕チャンキング ● ❌HyDE（このケースでは） ● ❌FT Embedding（遅い） 精度65%➔85% ● ⭕リランキング ● ⭕分類 （質問ジャンル分類結果付与） 精度85%➔98% Takeaway 何が効果的で何が効果的ではないか？の問題依存性大 https://www.youtube.com/watch?v=ahnGLM-RC1Y ● ⭕プロンプトエンジニアリング ● ⭕ツールの使用 （構造化データへの質問を変数化） ● ⭕クエリ拡張 （３つの質問を投げてMerge） 21

• https://www.youtube.com/watch?v=ahnGLM-RC1Y

流行りのベクトル検索に目を奪われることなく、 全文検索をベースラインとして用いる Takeaway 全文検索忘れない https://www.oreilly.com/radar/what-we-learned-from-a-year-of-building-with-llms-part-i/ 22

• https://www.oreilly.com/radar/what-we-learned-from-a-year-of-building-with-llms-part-i/

「回答のヒット率が上がると業務改善もされる」 という”正の循環の構築と計測 ”が応用では何より大事 日清食品: 生成AI活用の取組み＿ 解釈＿＿＿＿＿＿＿＿＿＿＿ ● ● 回答のヒット率が15％向上した 結果、KPI（作業工数の削減率）が8% 改善 "KPI ∝ 0.5 ヒット率"が成立 「ヒット率改善の工数（金額） 」と「作業工 数の削減率（金額換算） 」を天秤にかけて 投資の意思決定 ができる Takeaway https://www.nissin.com/jp/ir/library/event/pdf/20240314_2.pdf 改善がわかる・できるようアプリケーション設計・実装しよ 23 う

• https://www.nissin.com/jp/ir/library/event/pdf/20240314_2.pdf

“検索・拡張”時の改善手法一覧 分類 改善手法 概要 (❶データ整備) メタデータ 最終更新日、ジャンル等のメタデータを付与し、フィルタリング・Rerankingに利用 非テキストデータ 画像をアノテーションしてテキスト化したり、表をJSON/Markdown化 同義語辞書 チャンキング フィードバック ベクトル/グラフ化 独特の表現や略語に対する同義語辞書 を整備、フルテキスト検索の精度改善（例：四方山・とくぽん） RAGで用いる検索対象のChunkサイズをチューニング 回答の良し悪しのユーザ評価結果(good, bad)を集めて、リランキング等に反映し活用 元のデータをベクトル化したり、直近（2024年前半)ではグラフ化して精度を上げる流れも タイポ修正、抽象化・分解、変換（検索対象と近しい文言へ） Query Rewriting for Retrieval-Augmented Large Language Models 等 複数の検索を実行し、得られた回答を最終回答としてまとめる 問いへの”仮説（仮の答え）”を生成し、生成された仮説に基づいて検索しRAGを実行 クエリの内容によって問合せ先（社内DB、Web等）使い分ける （狭義には）ベクトル検索と全文検索を組合せ 、より関連性の高い情報を取得 検索結果を（重めの）AIモデル等で再評価し、クエリとの関連性に基づいて順位を並べ替え 検索結果を要約し、その結果を検索に用いる等活用 RECOMP: Improving Retrieval-Augmented LMs with Compression and Selective Augmentation RAPTOR: Recursive Abstractive Processing for Tree-Organized Retrieval 等 検索や生成を反復（再帰）する Enhancing Retrieval-Augmented Large Language Models with Iterative Retrieval-Generation Synergy Corrective Retrieval Augmented Generation Self-RAG: Learning to Retrieve, Generate, and Critique through Self-Reflection 等 (❷クエリ最適化) ❸検索 ❹拡張 Rewrite RAG-Fusion HyDE Routing Hybrid検索 Reranking 要約 反復 資料内 解説 ⭕ ⭕ ⭕ ⭕ ⭕ ⭕ ⭕ ⭕ 24

• https://arxiv.org/abs/2305.14283
• https://arxiv.org/abs/2310.04408
• https://arxiv.org/abs/2401.18059
• https://arxiv.org/abs/2305.15294
• https://arxiv.org/abs/2401.15884
• https://arxiv.org/abs/2310.11511

❶データ整備 RAGアプリケーション開発で”自組織ならでは”を出すには、「データ整 備・クエリ変換・検索」で差別化検討 前提 差別化項目（前P分類） LLM自体の改善はしない ● 自組織ではLLMを開発しない ● やるとしてFine Tuning 低Latencyは許容しない ● 良いサービスが増え、ユーザの 舌が肥えている（UX観点） ● 重たい計算を多用する手法が 使えない（将来的には改善？） 開発物は自組織で利用 or サービス化 ● サービス化の場合”差別化項目を 調整できる機能が実装済”と定義 データ整備 Takeaway ● メタデータ 泥臭い地道な 作業が効果的 ● 非テキストデータ ● 同義語辞書 ● フィードバック ● グラフ化（？） クエリ変換 ● Rewrite（タイポ修正、変換） 検索 Takeaway ● Reranking Rerankingは独自要素 入れやすい ※クエリ最適化やHybrid検索は、 ライブラリ・クラウドベンダー謹製が存在し、 ”当たり前品質”想定（Not 魅力的品質） 25

❶データ整備 メタデータを作成し、検索対象を絞り込む 左図解説＿＿＿＿＿＿＿ ● セクション・ページ番号等を メタデータ化 ● LLM-based Triageが回答に 必要な部分を抽出し回答 これ以外にも ● ● PDFTriage: Question Answering over Long, Structured Documents 更新日付、ジャンル、作成者 等でフィルタリング 入力のジャンルを軽量MLで 予測、リランキングのスコア 化 26

• https://arxiv.org/abs/2309.08872

❶データ整備 同義語辞書を作成し、検索精度を高める 同義語辞書を用いる意義＿ ● “独特”な略語はベクトル検索と致 命的に相性が悪い ○ 埋込空間上でズレる （仕組み上当たり前） ● 同義語辞書を作成し、全文検索 で活用、検索精度を高める ○ Azure AI Seachの例＿＿＿＿＿＿ 例: “第4期, 令和6年 =>2024年\n ACCT, 客, 顧客 => アカウント“ https://learn.microsoft.com/ja-jp/azure/search/search-synonyms 27

• https://learn.microsoft.com/ja-jp/azure/search/search-synonyms

❶データ整備 フィードバックを収集し、 データ品質改善や検索に活かす 回答に対するフィードバック収集＿＿ 徳島の名物は？ 徳島の名物といえばカツオ 🐟 ”質問・回答・参照資料・ フィードバック”を保存 データベース 活用方法＿＿＿＿＿＿＿＿＿＿＿＿ ● データ分析を行い、低品質部分を 見つけて元データ改善 ● “検索のスコア”にフィードバックを 反映 ○ 良/悪評価を上/下位へ ● ”回答の良し悪し”を判定する 二値分類器を学習させ、 リランキングのスコアとする Takeaway フィードバックは改善の源！ 28

❷クエリ最適化 RAG-Fusionは、元のクエリから複数の関連クエリを 生成・並列検索し、結果をFusionし頑健性と精度を向上 https://blog.langchain.dev/query-transformations/ 29

• https://blog.langchain.dev/query-transformations/

❷クエリ最適化 HyDE（Hypothetical Document Embeddings）は、 クエリに対する仮説（仮の答え）生成し、 クエリではなく仮説を元に検索することで精度向上 仮説 生成器 Precise Zero-Shot Dense Retrieval without Relevance Labels 文書 検索器 30

• https://arxiv.org/abs/2212.10496

❷クエリ最適化 Routingでクエリに応じた処理を選択 例：本文 or 要約を選択＿＿ 例：RDB or Vector DBを選択＿ https://twitter.com/llama_index/status/1688340114014105600 31

• https://twitter.com/llama_index/status/1688340114014105600

❸検索 Azureではベクトル検索と全文検索を組合せたHybrid検索が強い Hybrid検索の概要＿＿＿＿＿ ベクトル検索 検索手法の性能比較[1]＿＿＿＿ 全文検索 ベクトル・全文検索の 両方を実行 結果をRRF (Reciprocal Rank Fusion)で結合 結合 （Fusion） Semantic Rankerで Reranking Rerank ※Semantic RankerはBing由来の”Transformerベー ス”なAIモデルを使用した Rerak手法[2] [1] Azure AI Search: Outperforming vector search with hybrid retrieval and ranking capabilities [2] The science behind semantic search: How AI from Bing is powering Azure Cognitive Search 32

• https://techcommunity.microsoft.com/t5/ai-azure-ai-services-blog/azure-ai-search-outperforming-vector-search-with-hybrid/ba-p/3929167
• https://www.microsoft.com/en-us/research/blog/the-science-behind-semantic-search-how-ai-from-bing-is-powering-azure-cognitive-search/

❸検索 Rerankingは検索結果を”別な計算手法”で、 再評価し並べ替える手法の総称 Rerankingの概念図＿ クエリ “別な計算手法”の例＿＿＿＿＿＿＿ あくまで手法の“総称”なので、やり方は自由 ● 検索 検索結果 文章 ● ● ● Rerank Transformerのような重めのモデルで、 クエリと検索結果を再評価 ・並べ替える ○ CohereやAzureの方法 メタデータに基づき、軽めのモデルでクエリの内容を ”タ グ付け (分類)”させ、タグに応じて検索結果をフィルタリン グ/重付けして並び替え クエリに基づき、 軽めのモデルでフィードバック結果が良 いになるだろう 資料順に並べ替え その他、多様性あるように並べ替え (DiversityRanker)、ラ ンキング上位から Contextの最初と最後交互に配置 (LostInTheMiddleRanker）等も[1] [1] Enhancing RAG Pipelines in Haystack: Introducing DiversityRanker and LostInTheMiddleRanker 33

• https://towardsdatascience.com/enhancing-rag-pipelines-in-haystack-45f14e2bc9f5

3. RAGの性能評価 34

RAGの性能評価は以下の4観点で評価 観点＿＿＿ 内容＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿ ❶検索 ❸E2E ❷生成 クエリに対する関連性の高い文書の取得可否 検索結果を基に生成されたテキストの質 RAGシステム全体として見たときの回答の質 ❹非機能 システムの実用性や効率性 35

RAGの❶検索・❷生成の評価指標一覧 RAGASで取り扱われる評価指標 Takeaway 絶対視するのではなく、” 健康診断”と割切り、改 善の方向性確認程度に 使う 分類 評価指標 計測内容（方法） ❶検索 Context Precision 検索結果（コンテキスト）の内容がどれだけ正解（ Ground Truth）に含まれるか？ Context Recall 正解の文単位で、その内容がどれだけ検索結果に含まれるか？ Context Entity Recall Entity（≒名詞）単位で Recallを計測 Faithfulness（忠実性） 回答に含まれる主張が、どれだけ検索結果に基づいているか？ Answer Relevance (回答関連性 ) 回答が与えられた質問（プロンプト）関連しているのか？ （回答から逆生成された質問と元の質問の Embeddingのcos類似度） Answer Correctness (回答正確性 ) 回答が正解と比較して、どれだけ意味・事実観点で正確か？ （LLMがTP/TN等を判断し、 F1-Score出力） Answer Semantic Similarity （回答類似性） 回答が正解と比較して、どれだけ類似度しているか？ （回答と正解の Embeddingとcos類似度） Aspect Critique（側面評価） アスペクト（例：有害性、悪意等）を持つ回答か？ （同一のアスペクトに対し異なる角度から複数回質問し、その結果の多数決） 要約がコンテキストから重要な情報をどれだけ適切に捉えているか？ ❷生成 Summarization Score（要約スコア） ※各評価は人ではなく、 LLMで実施され（ LLM as a Judge）、Precision/Recall/Faithfulness等はLLMがよしなに判定 https://docs.ragas.io/en/latest/concepts/metrics/index.html 36

• https://docs.ragas.io/en/latest/concepts/metrics/index.html

（参考）RAG評価用Tool/Benchmark一覧 一覧 ToolとBenchmarkの違い ＿ Tool ● ● RAGアプリケーションの構築も可 柔軟なフレームワーク Benchmark ● ● RAG評価に焦点 構造化された評価フレームワーク ○ 評価指標、データセットが事前定義 Evaluation of Retrieval-Augmented Generation: A Survey 37

• https://arxiv.org/abs/2405.07437v2

❸E2Eや❹非機能で”RAGアプリケーション”として評価 分類 評価指標 計測内容 ❸E2E 多様性 検索結果や生成された回答に多様性はあるか？ 頑健性 回答不可や倫理的判断を要するクエリに、頑健に応答できるか？ タスク完了率 ユーザーが、求める情報や解決策を得られたかどうか？ 会話の長さ どれくらいのやりとり数で問題が解決されたか？ エスカレーション率 どのくらいRAGで解決できず人のオペレータに引継がれるか？ 人による総合評価 回答の正確性、関連性、最新性、会話の自然さ、総合的な満足度等 ❹非機能 レイテンシ UX 応答時間（〜検索＋ LLMでの回答生成時間＋システム表示） 使いやすさを中心としたユーザ体験 Evaluation of Retrieval-Augmented Generation: A Survey 等を元に記載 38

• https://arxiv.org/abs/2405.07437v2

4. まとめと展望 39

まとめと展望 まとめ/Takeaways ● ● ● Fine-Tuningの前に（不要にはならない！）RAGを検討しよう ○ プロンプトエンジニアリングの次はFine-tuningではなく、RAGを検討しよう 全体感を掴んだ上で、改善項目を考える 手法に関し「何が効果的で何が効果的でないか？」はケースバイベース ○ 改善がわかる/簡単にできるような設計と実装 にしよう 目新しい技術（ベクトル検索）に踊らされても、全文検索を忘れない 今まで同様、 ”泥臭い作業”が差別化の主戦場 ● ● 展望 ● ● （検索はさておき、生成/LLMは）「低価格化」「高速化」「多様化」 ○ 「小型化」と「RAG特化LLM」の動きもあり 性能検証系のツールはもっといいのが出てくる気がする 40