Contextual Retrieval — AnthropicがRAGの取りこぼしを最大67%減らす前処理パターン

背景 — チャンク分割で消える「文脈」をどう取り戻すか

Anthropicのengineering blogで公開された「Introducing Contextual Retrieval」(Daniel Ford氏執筆、公開日2024-09-19)は、RAG(Retrieval-Augmented Generation)の取りこぼしを構造的に減らすための前処理手法を提案する記事です。提案手法は名前のとおり「Contextual Retrieval」と呼ばれ、検索の失敗率を単独で49%、rerankingと組み合わせて67% 削減したと報告されています。

2024年公開の手法ですが、2026年現在もエージェントの長時間運用やClaude Codeのような実用ツールにとって基礎パターンとして参照される位置付けにあります。コンテキスト窓を最適に設計する流れはAnthropicのContext Engineering論にも引き継がれており、本記事の検索前処理はその上流に位置するものとして読めます。

本稿では、まずContextual Retrievalが解こうとしている「チャンク分割で文脈が消える問題」を整理し、そこから提案手法の中身、ベンチマーク数値、運用上のコスト見積もり、そしてrerankingと重ねたときの最大効果までを順に追います。

200,000トークン未満なら、そもそもRAGはいらない

提案の前置きとして、Anthropicは「RAGを使わない方が早いケース」をまず示しています。

知識ベース全体が200,000トークン(おおよそ500ページ相当)未満なら、毎回プロンプトに丸ごと載せた方がシンプルで結果も良いという主張です。背景には数週間前にリリースされたClaudeのprompt cachingがあり、頻繁に使うプロンプトをAPI呼び出し間でキャッシュすることで「レイテンシを2倍以上短縮、コストを最大90% 削減」できるようになっています。

つまり、Contextual Retrievalは「200,000トークンに収まらないほど大規模な知識ベースを扱う場合の解」として提案されています。小規模ナレッジでRAGを実装するのは過剰投資になりやすい、という編集視点での前提条件が冒頭に置かれている点が読みやすいところです。

従来RAGの限界 — 「revenue grew by 3%」は何の話か

提案手法を理解するには、従来RAGの典型的なフローを押さえておくのが早道です。Anthropicの整理では、検索精度を上げるRAGは次の6ステップになります。

1. ドキュメントを数百トークン規模のチャンクに分割
2. 各チャンクからTF-IDFエンコーディングと意味埋め込み(vector embedding)を作成
3. BM25で完全一致ベースの上位チャンクを取得(「TS-999」のような一意な識別子に強い)
4. embeddingで意味類似度ベースの上位チャンクを取得
5. rank fusionで3と4を統合・重複排除
6. 上位Kチャンクをプロンプトに追加して回答生成

ここで問題になるのが、ステップ1のチャンク分割で文脈が抜け落ちる現象です。AnthropicはSEC filings(米国の財務報告書)の例で説明しています。「ACME Corpの2023年Q2の売上成長率は?」という質問に対し、本来回答に必要なチャンクが次のような単独の文だったとします。

"The company's revenue grew by 3% over the previous quarter."

このチャンクにはどの会社の、どの四半期の話かが書かれていません。embeddingにしてもBM25にしても、検索の手掛かりが欠けるため、関連チャンクとして拾われにくくなります。これが「context conundrum(文脈の難問)」と呼ばれている現象です。

Contextual Retrievalの中核 — チャンクに「文脈一文」を埋め込む

Contextual Retrievalの提案はシンプルです。チャンクごとに、そのチャンクが何の文脈に属するかを説明する短い文を生成し、チャンクの先頭にprepend(連結)してからembeddingとBM25インデックスを作る。

先ほどのSEC filingsの例なら、変換後はこうなります。

This chunk is from an SEC filing on ACME corp's performance in Q2 2023; 
the previous quarter's revenue was $314 million. 
The company's revenue grew by 3% over the previous quarter.

冒頭に「ACME社の2023年Q2に関するSEC filingで、前四半期の売上は $314 millionだった」という文脈一文が加わり、embeddingにもBM25にも検索手掛かりが残ります。

これをembeddingに使うのがContextual Embeddings、BM25インデックスに使うのがContextual BM25と呼ばれます。両者は同じ「文脈付きチャンク」を別のインデックス手法で扱う一対のペアになっています。

文脈生成はClaude 3 Haikuに任せる

数千〜数百万のチャンクに人手で文脈を付けるのは現実的ではありません。AnthropicはClaude 3 Haikuで自動生成する案を提示しています。使われているプロンプトは以下のシンプルな形です。

<document> 
{{WHOLE_DOCUMENT}} 
</document> 
Here is the chunk we want to situate within the whole document 
<chunk> 
{{CHUNK_CONTENT}} 
</chunk> 
Please give a short succinct context to situate this chunk within 
the overall document for the purposes of improving search retrieval 
of the chunk. Answer only with the succinct context and nothing else.

ドキュメント全体とチャンクを渡し、検索性向上を目的とした短い文脈一文を返してもらう、という設計です。Anthropicの運用では50〜100トークン程度の文脈テキストが生成され、これがチャンクの先頭に付加されます。

実装コスト — prompt cachingで「100万トークンあたり1.02ドル」に収まる

ナレッジベースに何万チャンクもある場合、Claude 3 Haikuを全チャンクに呼ぶとコストが膨らみそうに見えます。ここで効くのがprompt cachingです。

リファレンスとなる「ドキュメント全体」は同じものを使い回せるため、キャッシュに1回だけロードして残りはキャッシュ参照で済ませる構成にできます。Anthropicが示している前提と試算は次のとおりです。

100万ドキュメントトークンで約1ドルというのは「RAG構築の前処理にかかる一度きりのコスト」として、運用設計上は織り込みやすい水準です。

このコストモデルはClaudeのprompt cachingを前提にしている点に注意が要ります。キャッシュなしで素朴に実装すると、ドキュメント全体を毎チャンクごとに送り直すため、コストはドキュメント数 × チャンク数のスケールで膨らみます。

ベンチマーク — Recall@20の失敗率がどこまで下がるか

Anthropicはcodebases、fiction、ArXiv papers、Science Papersの4ドメインで複数のembeddingモデル、検索戦略、評価指標を組み合わせて検証しています。評価指標は1 minus recall@20、つまり「上位20チャンクのうち、本来取るべきチャンクを取り損ねた割合」です。低いほど良い、という見方になります。

主要な数値は以下の通りです。

文脈一文を加えるだけで取りこぼし率が約1/3改善し、BM25側にも同じ文脈を反映させると約半減、さらにrerankingを載せると元の1/3まで落ちる、という構図です。3つの手法の効果が加算的に積み上がる(stackする)とAnthropicが結論で強調している通り、それぞれを単独で導入しても効くのが扱いやすい点です。

ベンチマークの裏側で使われていたembeddingモデルはGemini Text 004がトップ性能で、VoyageもGeminiと並ぶ高性能枠だったと報告されています。Anthropic自身のClaude系embeddingではなく外部モデルで検証している点は、再現性の意味でフラットな比較になっていると読めます。

実装で気を付けるべき4観点

提案を自分のプロジェクトに落とし込むときに、Anthropicが明示している実装上の観点は4つあります。

特に「top-20を渡すのがtop-10やtop-5より効く」という結果は、コンテキスト窓に余裕のあるモデルを前提にした近年の運用感覚と一致します。Claude Sonnet / Opus系の長コンテキスト運用が前提に置けるなら、20チャンクをまとめて渡す構成は十分現実的です。

Rerankingとの重ね合わせ — 最後に「不要なチャンクを落とす」工程

Contextual Retrievalは前処理側(インデックス側)で効くテクニックですが、Anthropicは検索後の後処理としてrerankingを重ねることでさらに精度が伸びると報告しています。

Rerankingのフローは以下の4ステップです。

1. 初回検索で多めのチャンク(本記事の実験ではtop-150)を取得
2. ユーザークエリとtop-Nチャンクをまとめてrerankingモデルに渡す
3. rerankingモデルが各チャンクに関連度スコアを付け、上位K(本記事ではtop-20)を選ぶ
4. 残ったtop-Kだけを生成モデルにコンテキストとして渡す

実験で使われたのはCohere rerankerです。Voyageのrerankerも存在するが今回は未検証、と注記されています。

rerankingにはレイテンシ・コストとのトレードオフがあります。top-150を並列に評価しても多少のオーバーヘッドは避けられないため、「精度を取るか応答時間を取るか」を自社のユースケースで実験して決める、というのがAnthropicの推奨です。100ミリ秒オーダーの応答が求められるリアルタイム検索ならtop-150 → top-20は重いかもしれませんが、エージェント駆動の長時間タスクのように1ターンの遅延が許容される文脈なら積極的に採用する価値があります。

編集視点 — 2024年の提案が2026年でも基礎手法として残るのはなぜか

Contextual Retrievalは2024年9月の提案ですが、2026年現在のAnthropicの発信物を見ると、関連する技術領域はその後さらに広がっています。長時間動くエージェントが知識ベースを参照しながら走るユースケースは、Claude Codeをはじめとした実用ツールで日常になり、ナレッジベース側の精度がそのままエージェント全体のアウトプット品質に効く、という構図がより鮮明になりました。

文脈付きチャンクという発想自体は地味ですが、次の3点で長く効く基礎手法として残っています。

1. embeddingモデルが入れ替わっても効く — Gemini Text 004、Voyage、その他何を選んでも改善方向が変わらない。提案がモデル非依存
2. rerankとstackできる — 後段のrerankingと独立に効くため、片方ずつ段階的に導入できる
3. コストモデルが明示されている — prompt cachingを前提にした $1.02/100万トークンという数字が事前に見えるため、PoCの起案がしやすい

マルチエージェントリサーチシステムの設計や、ツール設計のガイドラインで語られているように、エージェントが扱う情報量はこれからも増える方向です。Contextual Retrievalは「増えた情報をうまく検索可能にする前処理」として、検索ステップを構造化する出発点になります。Claudeを活用したRAGパイプライン全体を組む時には、Claude完全ガイド2026で扱っているモデル選定・料金プランと合わせて、前処理コストと検索精度のバランスを設計するのが現実的です。

まとめ — 誰がいつContextual Retrievalを採用するか

最後に、本手法の採用判断に効きそうな観点を表にまとめます。

提案のcoreは「チャンク化で消える文脈を、Claude 3 Haikuに生成させた短い文で復元する」というシンプルな一手です。実装の重さよりも、自社ナレッジでの効果検証コストの方が支配的になるはずなので、PoC単位で小さく始めてRecall@Kの指標で効きを確認するのが扱いやすい進め方になります。Anthropic公式のcookbookがGitHubで公開されており、最初の実装はそこから写経していくのが最短経路です。