「RAGはもう古い？」AIエージェントのコンテキスト問題を徹底解説！

ジェフ・フーバー氏（Chroma共同創設者）による「RAG（Retrieval Augmented Generation）に関する知っておくべきこと」と題された講演の要点をご紹介します。彼は「RAGは死んだ」と語り、その理由と、AIエージェントにおけるコンテキストエンジニアリングの重要性について深く掘り下げています。

RAGは死んだ？ AIエージェントの真の課題

フーバー氏は、「RAGという用語はもはや意味をなさないため、使用をやめるべきだ」と強く主張します。25人にRAGの定義を尋ねても、それぞれが異なる定義をするほど曖昧になっているとのことです。同様に、「ベクトルデータベース」という用語も推奨されていません。

現在、AIエージェントの失敗の大部分は、推論の失敗ではなく、「コンテキストの失敗」に起因すると指摘されています。これは、AI開発者にとっては既知の事実であり、日々の開発で直面する課題です。

コンテキストの「ダムゾーン」問題

コンテキストに関する問題は多岐にわたります。

• コンテキストが多すぎる場合: モデルが「ダムゾーン」に入り、情報過多による「コンテキスト腐敗（context rot）」が発生します。重要な情報を見落としたり、注意力が散漫になったりします。
• コンテキストが少なすぎる場合: 推論に必要な重要な情報が欠落し、人間でも判断できない状況に陥ります。
• コンテキストが混乱している場合: 言語モデルは、矛盾する情報の処理や優先順位の理解がまだ苦手です。

Chromaが昨年発表した技術レポート「context rot」では、言語モデルのパフォーマンスがコンテキストウィンドウ内のトークン数に大きく依存し、トークン数が増えるにつれて推論能力や注意力が著しく低下することが実証されています。これは、一部の言語モデルラボが主張する「1000万トークンでも完璧」という見解とは大きく異なります。多くの開発者は、自身のユースケースにおける「ダムゾーン」の開始地点について独自の感覚を持っていますが、数百万トークンを信頼できると感じる人はほとんどいないでしょう。

このような状況から、「コンテキストエンジニアリング」が再び重要になっています。AIエージェントに適切なタイミングで適切なレベルのコンテキストを提供することが、成功の鍵を握ると言えるでしょう。

コンテキストエンジニアリングの未来：手動からモデル主導へ

フーバー氏は、手動によるコンテキストエンジニアリングを避け、「苦い教訓（Bitter Lesson）」を受け入れるべきだと提言します。これは、エージェントに優れたツールとその使い方、使用するタイミングに関する適切なガイダンスを与え、あとはエージェント自身に解決させるという考え方です。

将来的には、コンテキストエンジニアリング自体がモデルの内部に組み込まれると予測されています。実際、Chromaが最近リリースしたモデルは、自身のコンテキストを編集し、軽量なコンテキストエンジニアリングを行うように学習されています。この傾向は今後さらに加速し、モデル自身がコンテキスト管理を行うようになるでしょう。

従来のコンテキスト提供方法とその課題

1. ファイルシステムを利用する方法の限界

現在、多くの開発者がエージェントにサンドボックス、ローカルファイルシステム、およびBashツールへのアクセスを提供しています。これはCodexやClaude Codeなどで効果的に機能するアプローチです。しかし、フーバー氏はこれを「ファイルシステムは悪いデータベースである」と批判しています。

その理由は以下の通りです。

• 並行処理能力の低さ: 複数のエージェントや人間が同じファイルを編集すると、最後に書き込んだ内容が優先される「後勝ち」になります。
• 破損の可能性: 特定の状況下でファイルが簡単に破損する可能性があります。
• インデックスの欠如: データに対するインデックスがないため、効率的な検索が困難です。
• 限定的な検索機能: grepなどの基本的な検索機能しかありません。
• サンドボックスの重さ: ファイルの読み書きのみが目的の場合、サンドボックスは過剰なリソースを消費する重いツールとなることがあります。

この問題については、Swyx氏の記事「Oops, You Wrote a Database」で詳しく解説されています。エージェントにファイルシステムを使わせることは、実質的に独自のデータベースを構築しているようなものだと指摘されています。

2. 仮想化されたBashとファイルシステムへのアクセス

もう一つのアプローチとして、エージェントに仮想化されたBashと仮想ファイルシステムへのアクセスを提供する方法があります。これは、実際のBash実行環境やファイルシステムではないものの、エージェントには同じように見えます。Bashコマンド（glob、grep、cat、lsなど）が機能し、エージェントはこれらを使ってファイルにアクセスできます。

Mintlify社は、彼らのアシスタントのために仮想ファイルシステムを構築し、このアプローチを広めました。彼らはChromaをバックエンドデータベースとして使用し、その上に仮想ファイルシステムを置くことで、重いサンドボックスなしに軽量なコンテキスト提供を実現しました。彼らのユースケースでは、実際のコード実行は不要で、ファイルの読み取り（read-only）が主でした。

このアプローチはさらに進化する可能性を秘めています。例えば、エージェントがgrepを使用する際に、単なるリテラルな正規表現マッチングだけでなく、結果を自由にパディングできるような柔軟性が考えられます。

「エージェントはファイルシステムAPIに慣れているからファイルシステムを使うべきだ」という考え方は、一時的な流行に過ぎないとフーバー氏は考えています。エージェントは時間とともに、与えられたどんなツールでも非常にうまく使いこなせるようになるでしょう。

まとめ

本記事では、RAGという用語の限界と、AIエージェントの性能向上におけるコンテキストエンジニアリングの重要性について解説しました。AIエージェントの失敗の多くがコンテキストの問題に起因すること、そして、手動でのコンテキスト調整からモデル自身による賢いコンテキスト管理へと移行していく未来が示唆されました。また、ファイルシステムをデータベースとして利用するアプローチの課題と、仮想化された環境を通じた軽量なコンテキスト提供方法が注目されています。

AIエージェント開発においては、いかにしてエージェントに「適切なコンテキストを、適切なタイミングで」提供するかが、引き続き重要なテーマとなるでしょう。

参考動画: YouTube