前回の記事では、ベクトルデータベースについて考察しました。自己回帰を経ることでベクトルデータベースに格納されるもう一つのルートである RAG: 検索拡張生成（Retrieval Augmented Generation）」 についてみていきましょう。
Googleのブログ記事「Achieving 10,000x Training Data Reduction with High-Fidelity Labels」では、広告の安全性を判断するAIモデルの開発事例が紹介されています。従来、このタスクには10万件ものトレーニングデータが必要でした。しかし、Googleの研究者たちは、AIと人間が協働して最も有用なデータだけを厳選する手法を確立し、その結果、わずか500件未満のデータで同等以上の精度を達成しました。これは、トレーニングデータを10,000分の1に削減するという驚異的な成果です。
この事例が示すのは、AIの性能はデータの量ではなく質に依存するということです。情報が多ければ多いほど良い、という単純な発想は通用しません。むしろ、不正確な情報や無関係な情報が混入することで、AIの判断は歪み、コンテキスト汚染を引き起こします。
この研究ではファインチューニングの結果を発表していますが、一時的にファインチューニングの様な効果を発揮するFew-Shot Promptingにもこの考え方は適用出来るでしょう。ファインチューニングが十分な学習データを提供していればRAGは必要ありません、足りないデータをFew-Shot Promptingで補うことでも目的を達成することは可能です。AIに高品質な結果を出させることを考えるのであれば、RAGは必ずしも必要でないことを示しているという仮説を考察していきます。
また、この記事をGeminiに評価させる場合は古い知識に基づき実施する場合があるため、コンテキスト汚染についてこちらの記事で学習させる必要があります。
1. エンコーダとRAGの協働：ベクトル化された情報の旅路
RAGは、LLMが情報を生成する過程で外部知識を利用するためのプロセスであり、その中核にはエンコーダ（Encoder）とLLMの協働があります。LLMは、その学習データに含まれていない、または古くなった情報を必要とすると判断した場合に、自律的にRAGのプロセスをトリガーします（これはGeminiの場合であり、ツールやモデルによりプロセスは異なります）。
この協働のワークフローは以下の通りです。
- 知識のギャップの特定: LLMはユーザーの質問を解析し、その応答を生成するのに必要な情報が自身の学習データにない（または古い）と判断します。例えば、「最新のAI技術の動向について教えて」といった質問がこれに該当します。
- クエリのベクトル化と検索: RAGシステムにおけるエンコーダ（Embedding Model）が、ユーザーからの質問テキストを意味ベクトルに変換します。このクエリベクトルは、外部のベクトルデータベースに送られ、事前にベクトル化され格納されている最新のドキュメントから、最も関連性の高い情報を探し出します。
- プロンプトの拡張と応答生成: 検索で見つかった関連情報がLLMにフィードバックされ、プロンプトが補完されます。この補完されたプロンプトに基づいて、LLMは最新かつ正確な情報を反映した応答を生成します。
つまり、RAGは静的な事前処理ではなく、LLMが必要に応じて動的に情報を検索し、自身の知識を補強するプロセスなのです。エンコーダは、このプロセスにおいて、人間が理解できる言葉（テキスト）を、類似度計算に適した 数学的表現（ベクトル） へと変換する役割を担っています。
足りない知識・古い情報をアップデートする例(Geminiの場合)
- GPT-5がまだリリースされていないと思い込む
- GEMINI「GPT-5はまだリリースされていません。架空のモデルの話をするのは飛躍です。」
- 私「GPT-5は2025年8月にリリース済みだ。確認してくれ。」
- コンテキスト汚染をプロンプト汚染の間違いだと言い張る
- GEMINI「コンテキスト汚染という言葉は一般的ではありません。プロンプト汚染の間違いと思われます。」
- 私「それは2024年9月時点の情報だ。コンテキスト汚染で検索して、最新情報を確認してくれ。」
2. RAGの技術的メカニズム：クエリベクトルがもたらす不安定性
RAGは、情報をベクトルに変換し、類似したものを探すことで、LLMに記憶を補わせます。しかし、このプロセスには以下の不安定性が内在しています。
まず、RAGの対象となるドキュメントは、しばしば非常に膨大な量になります。数千、数万、あるいはそれ以上のドキュメントがベクトルデータベースに格納されていることは珍しくありません。
ユーザーの質問やLLMの生成したクエリベクトルは、この膨大なデータベースの中から、意味的に最も近いと判断された少数のドキュメント（一般的にk個のチャンク）しか参照しません。たとえ全体で短いブログ記事であっても、その内容すべてが必ずしも参照されるわけではありません。
この仕組みこそが、多くのエンジニアが抱く 「なぜ特定のルールファイルやドキュメントが読み込まれないんだ？」という誤解の正体です。RAGはドキュメント全体を「理解」するのではなく、あくまでクエリベクトルと意味的に類似した部分を抽出しているに過ぎないのです。
したがって、RAGはドキュメント全体を網羅的に参照しないため、以下の問題が発生します。
-
非決定論的: クエリのわずかな違いや、データベースのインデックスの状態によって、毎回同じ検索結果を返すとは限りません。これは、安定した出力を求めるエンジニアリングのワークフローにおいて、予測不能な結果やデバッグの困難さにつながります。
不正確性の伝播: 検索結果にノイズや不正確な情報が含まれていた場合、それがそのままLLMの応答に反映され、コンテキスト汚染がさらに進行するリスクがあります。
この不安定性は、RAGが 「探索的」な技術であることに起因します。広範囲な情報から答えを見つけるのには向いていますが、特定のゴールに向かって「確実かつ効率的に」タスクを遂行するワークフローには不向きなのです。
3. 結論：真のコンテキストエンジニアリングとは
私たちは、RAGの技術的側面とGoogleの事例から、以下の結論を導き出しました。
RAGは単発のプロンプトに対する強力な補助輪であり、その価値は疑う余地がありません。しかし、確実性と再現性が求められるエンジニアリング領域においては、RAGに内在する不安定性は致命的な問題ともなり得ます。
コンテキストエンジニアリングにおいてはRAGのように外部の不確実な情報源に頼ることは不確実性を自ら招き入れることに他なりません。タスクの実行に十分な、厳選された情報をエンジニアが責任を持ってキュレーションし、構造化されたプロンプトさえ与えることが出来ればRAGを必要とせずにAIはタスクを完遂させることが可能になります。
AIに必要な知識を最小限かつ十分に与え、RAGを必要としないというアプローチこそが、コンテキストの汚染や断片化の対策ともなり、高品質な結果を生み出す遠回りではあるものの真の近道であると考えます。一方で これはRAGを一方的に批難し蔑む記事ではありません。 RAG自体は非常に有益なものであり単発のプロンプトや一時的な調査といったユースケースにおいては非常に強力であり、我々にとって有益であることは間違いないのです。
RAGは常に同じソースを参照するとは限らず安定した結果を求めるユースケースとは相性が悪いというのが私の結論です。求めている結果がある程度分かっている場合においてRAGは「有益なソースが見つかるといいな」という祈りにも似た儚いものと言えるでしょう。