RAG（Retrieval-Augmented Generation）を使ったシステムを構築していませんか？
そして、思うような精度が出ないと悩んでいませんか？
実は、多くの開発者が同じ壁にぶつかっています。
RedditのRAGコミュニティで話題になった投稿があります。
それによると、従来のRAGアプローチには根本的な問題があるようです。
今回は、その投稿で議論された「推論時コンテキスト生成」という新しいアプローチについて解説します。
RAGが抱える本質的な問題
RAGシステムを運用していると、こんな経験はありませんか？
「売上が3%増加しました」という文章を取得します。
でも、どの会社のいつの売上なのか分かりません。
これは、RAGが抱える典型的な問題です。
問題の根源は3つあります。
まず、セマンティック検索の限界です。
埋め込みベクトルは「似ている」文章を見つけるのは得意です。
しかし、「関連性が高い」文章を見つけるのは苦手なのです。
例えば、「収益」と「売上」は似ています。
でも、質問によっては全く違う情報が必要になることもあります。
次に、チャンキングのジレンマがあります。
文書を小さく分割すれば文脈を失います。
大きく分割すれば不要な情報まで取得してしまう。
このトレードオフに、多くの開発者が頭を悩ませているでしょう。
そして最も深刻なのが、文書全体の文脈の喪失です。
契約書の条項は、前半で定義された用語なしには理解できません。
しかし、通常のRAGでは各チャンクを独立して扱います。
そのため、この重要な関連性が失われてしまうのです。
リランキングでは解決できない理由
「リランキングを使えばいいのでは？」と思うかもしれません。
確かに、検索後に結果を再評価することで精度は向上します。
しかし、リランキングには決定的な限界があります。
失われた文脈を再構築することはできないのです。
また、ドメイン特有の知識や英語以外の言語では問題が生じます。
既存のリランキングモデルがうまく機能しないケースも多いようです。
従来のコンテキスト追加手法
この問題に対して、いくつかのアプローチが試されてきました。
主な手法：
- スライディングウィンドウ方式：隣接するチャンクと一部を重複させる
- 階層的チャンキング：文、段落、セクションといった複数のレベルでチャンクを作成
- メタデータの追加：タイトルやセクション名を各チャンクに付与
これらの手法は一定の効果があります。
しかし、真のグローバルな文脈理解には至りません。
また、余計な情報が混入してノイズになることもあります。
入力サイズが増えてコストが上昇する問題もあります。
Contextual Retrievalの登場
Anthropicが提案したContextual Retrievalは興味深いアプローチです。
各チャンクに説明的なコンテキストを事前に付与します。
例えば、こんな感じです。
元のチャンク：「売上が3%増加しました」
コンテキスト付きチャンク：「これはACME社の2023年第2四半期のSEC提出書類からの抜粋で、第1四半期の売上は3億1400万ドルでした。売上が3%増加しました」
これにより、チャンクが独立して検索されても必要な背景情報が保持されます。
しかし、このアプローチにも課題があります。
異なるクエリに対して、同じチャンクでも必要なコンテキストが変わるのです。
財務実績を聞かれたときと、競合比較を聞かれたときでは違います。
付与すべきコンテキストが異なるのです。
また、インデックス作成時のコストと時間も無視できません。
推論時コンテキスト生成という革新
そこで登場したのが、推論時にコンテキストを動的に生成するアプローチです。
具体例で説明しましょう。
あなたが「ACME社の2023年の業績は？」と質問したとします。
従来のRAGの動作：
- 「業績」「2023年」などのキーワードで検索
- 「売上が3%増加」というチャンクを発見
- そのまま回答に使用（どの会社か分からない！）
推論時コンテキスト生成の動作：
ステップ1：インデックス作成（事前準備）
チャンク1: 「売上が3%増加しました」 チャンク2: 「営業利益は前年比10%改善」 チャンク3: 「ACME社の2023年第2四半期報告書」
これらを個別に保存します。
特別な処理はしません。
ステップ2：検索時の動作
「ACME社の2023年の業績は？」という質問を受けると：
- 関連しそうなチャンクを広めに取得
- 同じ文書（第2四半期報告書）のチャンクをグループ化
ステップ3：賢いところ！コンテキスト生成
軽量なLLMが登場します。このLLMに以下を渡します：
- ユーザーの質問：「ACME社の2023年の業績は？」
- 取得したチャンク群：チャンク1、2、3
LLMが生成するコンテキスト：
「これらのチャンクはACME社の2023年第2四半期報告書からの抜粋です。売上と営業利益の改善について述べています。」
ステップ4：最終回答の生成
メインのLLMに以下を渡します：
- 生成されたコンテキスト
- 元のチャンク
- ユーザーの質問
これにより、「ACME社の2023年第2四半期は、売上が3%増加し、営業利益は10%改善しました」という正確な回答が生成されます。
なぜこれが画期的なのか？
従来は「売上が3%増加」という情報だけでした。
でも今は、それがACME社の2023年のデータだと分かります。
しかも、質問によってコンテキストが変わります。
「競合他社との比較は？」と聞かれたら、別の観点からコンテキストを生成してくれるのです。
実装時の考慮点
実際に実装する際は、いくつかのトレードオフを考慮する必要があります。
レイテンシーについては、並列処理を活用します。
これにより、影響を最小限に抑えられます。
軽量なLLMを使用すれば、追加の処理時間は許容範囲内に収まるでしょう。
コストは、取得する文書数に比例して増加します。
しかし、小規模なLLMを使用することで削減できます。
フルスケールのLLMを使う場合と比べて、大幅にコストを削減できるのです。
Redditコミュニティの反応
この投稿に対して、コミュニティからは様々な反応がありました。
ある開発者は「RAG初心者にとって素晴らしいリファレンスだ」とコメントしています。
一方で、「これは基本的にエージェント型RAGではないか」という指摘もありました。
特に興味深いのは、次のような鋭い観察です。
ステップ3はステップ2で取得されたチャンクにしか働かない。 だから、最初から関連性の高いチャンクを取得することには役立たない
これに対して投稿者は回答しています。
「文書内に回答に必要な情報が含まれているという前提で動作する」と。
まとめ
推論時コンテキスト生成は、RAGの精度向上に大きな可能性を秘めています。
従来のアプローチが抱える問題を解決します。
そして、柔軟性と効率性を両立させる優れた手法と言えるでしょう。
ただし、万能ではありません。
レイテンシーとコストのトレードオフを慎重に検討してください。
そして、アプリケーションの要件に合わせて実装することが重要です。
RAGシステムの改善に取り組んでいる方は、ぜひこのアプローチを検討してみてください。
今まで解決できなかった問題に対する新しい視点が得られるはずです。
