{"notes":[{"id":"retrieval-augmented-generation/rag-failure-points","category":"retrieval-augmented-generation","legacyPath":"","legacySlug":"","legacyPaths":[],"title":"Seven Failure Points","subtitle":"七つの大罪","author":"Z. Yuan","paperDate":"2024-01-11","publishedOn":"2026-05-28","paperTitle":"Seven Failure Points When Engineering a Retrieval Augmented Generation System","paperUrl":"https://arxiv.org/abs/2401.05856","bibliography":{"title":"Seven Failure Points When Engineering a Retrieval Augmented Generation System","authors":["Scott Barnett","Stefanus Kurniawan","Srikanth Thudumu","Zach Brannelly","Mohamed Abdelrazek"],"url":"https://arxiv.org/abs/2401.05856","pdfUrl":"https://arxiv.org/pdf/2401.05856v1","codeUrl":null,"preprint":{"id":"2401.05856","submittedOn":"2024-01-11","url":"https://arxiv.org/abs/2401.05856"},"publication":null,"citation":"@misc{retrievalaugmentedgenerationragfailurepoints2024,\n  title = {{Seven Failure Points When Engineering a Retrieval Augmented Generation System}},\n  author = {Scott Barnett and Stefanus Kurniawan and Srikanth Thudumu and Zach Brannelly and Mohamed Abdelrazek},\n  year = {2024},\n  eprint = {2401.05856},\n  archivePrefix = {arXiv},\n  url = {https://arxiv.org/abs/2401.05856}\n}\n","citationPath":"/content/papers/citations/retrieval-augmented-generation/rag-failure-points.40ca0c32c91e.bib"},"thumbnail":{"src":"/content/papers/assets/bd756f315ebe65964e8195f5120c63e86e709d677c39b319fecacd74ea197d71.png","width":1422,"height":578},"locale":"ja","path":"/content/papers/ja/retrieval-augmented-generation/rag-failure-points.55afbf7215f5.md","headings":[{"id":"問題の定義","text":"問題の定義","depth":2},{"id":"問題の解決","text":"問題の解決","depth":2},{"id":"三つの事例","text":"三つの事例","depth":3},{"id":"ragの二つの処理系","text":"RAGの二つの処理系","depth":3},{"id":"一つの質問に七つの落とし穴","text":"一つの質問に、七つの落とし穴","depth":3},{"id":"議論","text":"議論","depth":2},{"id":"三つの事例から学んだこと","text":"三つの事例から学んだこと","depth":3},{"id":"著者らが挙げる研究課題","text":"著者らが挙げる研究課題","depth":3},{"id":"読むときに押さえておきたい点","text":"読むときに押さえておきたい点","depth":3},{"id":"結論","text":"結論","depth":2}],"anchorAliases":{},"guide":null,"relatedReading":[]}],"text":"2023年、RAGのデモを作ること自体は難しくありませんでした。\n\n文書を分割し、embeddingを計算してベクトルデータベースに保存する。質問が来たら似ている断片を取り出し、質問と一緒にChatGPTへ渡す。午後の数時間で、上司に「AIが社内文書を理解しました」と見せられます。\n\n難しいのは、その後です。\n\nこの論文は、オーストラリアのディーキン大学（Deakin University）応用人工知能研究所によるものです。AIシステムのソフトウェア工学を扱うCAIN 2024で発表されました。新しいモデルも、記録を塗り替えるスコアもありません。著者らが提示するのは**経験報告**です。実際に三つのRAGシステムを作り、その途中で出会った失敗を七つに分類しています。\n\n## 問題の定義\n\n著者らはまず、RAGが解決しようとする三つの課題を挙げます。\n\n1. **ハルシネーションを減らす**：モデルが自由に話を作るのを避け、文書に基づいて回答させる。\n2. **出典を示す**：回答がどの文書から来たのか、利用者が確認できるようにする。\n3. **アノテーションを省く**：文書に一つずつメタデータを付けず、意味検索を直接使う。\n\nただし、RAGは両側の弱点も受け継ぎます。情報検索は取り違えや取りこぼしを起こし、大規模言語モデルは読み違えたり、でたらめに答えたりします。\n\nそこで著者らが答えたい問いは二つです。\n\n- **RAGシステムを作るとき、どこで失敗するのか？**\n- **エンジニアリングでは何に注意すべきか？**\n\n## 問題の解決\n\n### 三つの事例\n\n報告の材料になったのは、次の三つのシステムです。\n\n| 事例 | 分野 | 文書 | 規模 | 質問の例 |\n| --- | --- | --- | --- | --- |\n| Cognitive Reviewer | 研究 | PDF | 制限なし | この論文の要点は？ |\n| AI Tutor | 教育 | 動画、HTML、PDF | 38件 | 第6週には何を学びましたか？ |\n| BioASQ | 生物医学 | 学術論文のPDF | 4,017件 | 偽性脳腫瘍とは何か、どう治療するか？ |\n\n*原論文Table 1をもとに整理。*\n\n**Cognitive Reviewer**は研究者の文献読解を支援します。研究上の問いを書き、論文をアップロードすると、研究目的に沿って順位付けします。文書全体に対して質問することもできます。文書は実行時に利用者がアップロードするため、開発段階で品質を確かめておくことはできません。\n\n**AI Tutor**は授業のアシスタントです。学生の質問に、その授業の教材から出典付きで答えます。動画はWhisperで文字起こししてから分割します。また、過去の会話を参照し、「その概念をもう一度説明して」といった曖昧な質問を完全なクエリに直すrewriterもあります。開発期間は2023年8月から11月で、10月30日から約200人の学生がいる授業で試行されました。\n\nこの二つはディーキン大学で実際に使われましたが、機密保持のため、データとコードが公開されたのは三つ目の事例だけです。\n\n**BioASQ**は、より大きな規模を試すためのシステムです。著者らは生物医学の質問応答データセットBioASQからオープンアクセス論文4,017件をダウンロードし、GPT-4で1,000問に回答させました。OpenAIのevalsで自動採点した後、不正解とされた回答と、正解とされた回答の一部を人手で確認しています。\n\nこの分野では、自動採点のほうが人手より厳しかったそうです。一方、妥当性に関わる問題も指摘しています。確認者は生物医学の専門家ではなく、言語モデルのほうが詳しい可能性がありました。\n\n\n> [!NOTE]\n> \n> 序論と結論には15,000文書とありますが、§4.3とTable 1では4,017文書です。このノートでは後者を採用します。\n\n\n### RAGの二つの処理系\n\n失敗を見る前に、著者らのフロー図を確認しましょう。赤い枠が七つの失敗点です。\n\n[![RAGの索引作成とクエリ処理の流れ。赤い枠で七つの失敗点を示している](/content/papers/assets/bd756f315ebe65964e8195f5120c63e86e709d677c39b319fecacd74ea197d71.png)](/content/papers/assets/bd756f315ebe65964e8195f5120c63e86e709d677c39b319fecacd74ea197d71.png)\n\n*原論文Figure 1、[**v1 PDFの3ページ**](https://arxiv.org/pdf/2401.05856v1#page=3)より。CC BY 4.0。上段は索引作成、下段はクエリ処理。赤い枠が失敗点。*\n\n上段の**索引作成処理**（Index Process）は、通常は開発時に行います。Chunkerが文書を小さく分割し、それぞれをembeddingに変換してデータベースに保存します。\n\nこの時点でも判断は簡単ではありません。断片が小さすぎると答えられない質問があり、大きすぎるとノイズが混じります。embeddingモデルを変えれば、全文書の索引を作り直す必要もあります。\n\n下段の**クエリ処理**（Query Process）は実行時に動き、五つの段階を通ります。\n\n1. **Rewriter**：言語モデルで質問を一般化したクエリに書き換えます。会話履歴も使えます。\n2. **Retriever**：クエリのembeddingで、最も似ている上位$K$個の断片を取得します。\n3. **Reranker**：回答を含む断片がなるべく前に来るよう、順位を付け直します。\n4. **Consolidator**：プロンプトに入れる内容をまとめます。当時のAPIにはtoken数とレートの制限があり、全断片を入れられませんでした。そのため、選別、統合、複数プロンプトの連結が必要になります。\n5. **Reader**：プロンプト内のノイズを除き、形式の指示に従い、最終回答を生成します。\n\n### 一つの質問に、七つの落とし穴\n\nAI Tutorの例「第6週には何を学びましたか？」を使い、各段階をたどって七つの失敗点を見てみましょう。\n\n\n> [!TIP]\n> \n> 以下の状況は説明のために本ノートで考えた例です。この一問を追った失敗の実測記録は、論文には掲載されていません。各失敗点の定義は原論文§5に従います。\n\n\n**FP1：内容がない（Missing Content）。** 第6週の教材がそもそもアップロードされていません。理想的には「すみません、わかりません」と答えるべきですが、既存の内容に近い質問だと、システムが惑わされて回答を作ってしまうことがあります。\n\n**FP2：上位に入らない（Missed the Top Ranked Documents）。** スライドはデータベースにありますが、類似度では8位です。取得するのは上位5件だけ。理論上は全件を順位付けできても、後段に渡るのは上位$K$件です。\n\n**FP3：コンテキストに入らない（Not in Context）。** スライドは検索されましたが、Consolidatorがtoken上限に収めるために外してしまいました。\n\n**FP4：回答を取り出せない（Not Extracted）。** スライドは確かにプロンプトにあります。それでもモデルが回答を読み取れません。著者らによれば、ノイズや矛盾が多いときに起きやすく、たとえば旧学期と新学期の教材が同時に取得される場合です。\n\n**FP5：形式が違う（Wrong Format）。** 学生が箇条書きを求めたのに、モデルは形式の指示を無視して段落で答えます。\n\n**FP6：具体性が合わない（Incorrect Specificity）。** 回答自体は含まれていますが、大まかすぎたり詳しすぎたりします。著者らが挙げる教育の例では、教師は答えだけでなく関連教材の内容も付けてほしいと考えています。利用者が尋ね方をつかめず、質問が広すぎる場合にも起きます。\n\n**FP7：回答が足りない（Incomplete）。** 第6週には三つの話題があったのに、モデルは二つしか挙げません。三つ目もコンテキスト内にあります。著者らは「文書A、B、Cの要点は？」のような質問は、分けて尋ねるほうがよいと勧めています。\n\n最初の三つは、答えに必要な情報が**モデルに届く前**の失敗です。情報がない、検索できない、入力に入らない。後の四つは、**モデルに届いた後**の失敗です。取り出せない、形式が違う、詳しさが合わない、一部が抜ける。\n\n## 議論\n\n### 三つの事例から学んだこと\n\n著者らは経験をTable 2にまとめ、各項目を関連する失敗点に対応付けています。\n\n1. **コンテキストを広げると結果がよくなる。** AI Tutorでは4Kより8Kのほうが正確でした。著者らは、GPT-3.5を使った先行研究とは逆の結果だと明記しています。（FP4）\n2. **意味ベースのキャッシュは費用と遅延を減らせる。** 同時利用が増えるとレート制限と費用が問題になるため、よくある質問をキャッシュできます。（FP1）\n3. **脱獄攻撃はRAGを迂回する。** 微調整が安全性の訓練を弱めるという研究があり、RAGに使う微調整済みモデルも検証が必要です。（FP5–7）\n4. **メタデータは検索に役立つ。** 取得内容にファイル名や断片番号を加えると、Readerが必要な情報を取り出しやすくなります。（FP2、FP4）\n5. **短いテキストでは、オープンなembeddingモデルも商用モデルに劣らない。**（FP2、FP4–7）\n6. **RAGシステムは継続的な調整が必要。** 実行時には予想外の入力が来るため、監視を続ける必要があります。（FP2–7）\n7. **RAGを設定可能なパイプラインにする。** 断片サイズ、embedding、分割・検索・統合の戦略、コンテキスト長、プロンプトは、どれも調整の対象です。（FP1、FP2）\n8. **寄せ集めたパイプラインが最適とは限らない。** 著者らは、エンドツーエンド訓練でドメイン適応が改善する研究を引用しています。（FP2、FP4）\n9. **性能は実行時に測る必要がある。** G-Evalのようなオフライン評価は有望ですが、アノテーション済みの質問応答データが手元にあることが前提です。（FP2–7）\n\n最後の項目は、要旨にある二つの結論に直結しています。\n\n- **RAGシステムは、運用の中で初めて検証できる。**\n- **頑健性は少しずつ育つもので、最初からすべてを設計に織り込むことはできない。**\n\n理由は実務的です。RAGが扱うのは未整理の文書であり、開発時には試験用の質問応答データがそろっていないことが多いからです。どんな質問が来るかは、本当の利用者が尋ねて初めてわかります。\n\n### 著者らが挙げる研究課題\n\n1. **分割とembedding**：句読点や段落で区切るか、意味で区切るか。どちらが検索に有利か、体系的な比較が必要です。表、画像、数式のようなマルチモーダルな内容をどうembedding化するかも、未解決の課題です。\n2. **RAGと微調整**：微調整では情報をモデルに学習させ、誰が何にアクセスできるかも扱う必要があります。RAGは文書を随時追加でき、利用者に見せる断片も制御できます。精度、遅延、費用、頑健性のトレードオフを体系的に比較する必要があります。\n3. **テストと監視**：実際の分野に近いテスト用の質問応答をどう生成するかは、まだ課題です。モデルの更新ごとに遅延や性能特性も変わります。\n\n### 読むときに押さえておきたい点\n\nこれは経験報告です。七つの失敗点は三つの事例から整理した分類であり、論文は**それぞれの発生頻度を集計していません**。設計を変えると失敗がどれだけ減るかという比較もありません。実用中の二つのシステムは機密保持のためデータ非公開で、検証できるのはBioASQの事例だけです。\n\nまた、これは2024年初頭、GPT-4時代の経験です。FP3のConsolidatorは主にtoken上限への対処でした。その後コンテキスト長が大きくなり、この段階にかかる制約も変わりました。これは後の発展であり、論文そのものの結論とは分けて、時期を意識して読むとよいでしょう。\n\n## 結論\n\nこの論文がくれるのは、新手法ではなく地図です。\n\nRAGを索引作成とクエリ処理に分け、七つの失敗箇所を示します。内容がない、上位に入らない、コンテキストに入らない、回答を取り出せない、形式が違う、具体性が合わない、回答が足りない。最初の三つは「情報がモデルの前に届かない」、後の四つは「届いた情報をモデルがうまく使えない」という問題です。\n\nこの地図が役立つのは、RAGが間違えたときに、一段ずつ確認できるからです。情報はあるか。検索できたか。入力に入れたか。モデルは答えを読み取れたか。\n\nよりよいembeddingモデルに替えて解決できるのは、そのうちの一部です。\n\n残りはおそらく、運用を始めてから一つずつ出会っていくことになります。\n","imageSizes":{"/content/papers/assets/bd756f315ebe65964e8195f5120c63e86e709d677c39b319fecacd74ea197d71.png":{"width":1422,"height":578}}}