Anthropic Contextual Retrieval を読んだまとめ

1. この記事は何を説明しているのか

Anthropic は、従来型 RAG の根本的な弱点を指摘しました。chunk が原文から切り離されると意味が失われる という問題です。

代表的な例は、"The company's revenue grew by 3% over the previous quarter." という chunk です。どの会社で、どの四半期なのかが分かりません。分割時にその情報が失われるため、検索時のベクトル類似度も有効に働かなくなります。

解決策は非常に簡潔です。embedding の前に、LLM を使って各 chunk に短い context の接頭辞を付けます。 文書全体と現在の chunk を Claude に渡し、その chunk を説明する 50〜100 token の context を生成させます。それを chunk の先頭へ追加してから embedding を作成します。

2. Appendix II の実験データから分かること

PDF には、コードベース、小説、学術論文、ArXiv 論文にまたがる評価例が掲載されています。重要な観察は次のとおりです。

1. 評価データセットの設計が本質である

各例は Query → Golden Answer → Golden Chunk → Context の四つ組を持ちます。これは偶然ではありません。RAG の評価には、正解がどの chunk から得られるべきかを示す ground truth が必要です。それがなければ、評価指標は根拠のない数値になります。

2. 選ばれた分野には代表性がある

コードベースでは正確な一致が重要です。小説では段落をまたいだ人物関係の理解が必要です。学術論文には専門用語と引用の連鎖があります。三つの分野は、それぞれ RAG の異なる弱点を検証しています。実践的なプロジェクトでも、一種類だけでなく少なくとも二種類の文書を評価すべきです。

3. Context フィールドが Contextual Retrieval の中核出力である

PDF の各例にある Context フィールドを見ると、chunk が文書全体のどこに位置し、どんな役割を持つかを自然言語で説明しています。コードベースの例では、「このコードは Log4cxx ロギングライブラリに属する BasicConfigurator クラスの実装である」と説明しています。これを chunk の先頭へ付けることで、embedding は単なる関数シグネチャの集まりではなく、「ログ設定に関するコード」という意味を捉えられます。

3. 定量的な結果

手法Top-20 検索失敗率baseline からの低減
従来の embedding（baseline）5.7%—
+ Contextual Embeddings3.7%-35%
+ Contextual Embeddings + Contextual BM252.9%-49%
+ Contextual Embeddings + Contextual BM25 + Reranking1.9%-67%

この数値は、RAG 実装の評価に使える重要な benchmark です。

4. 私が考える RAG のベストプラクティス

Contextual Retrieval と 2026 年までの本番経験を踏まえると、次のような RAG アーキテクチャを推奨します。

原則1：本当に RAG が必要かを最初に判断する

Anthropic は明確に述べています。ナレッジベースが 200K tokens、目安として約 500 ページ未満なら、全文を prompt に入れて prompt caching を使う方が、RAG より簡単で正確な場合があります。2026 年の context window はすでに大きく、多くの場面では RAG が不要です。

「いつ RAG を使うべきか」と聞かれた場合の答えは次のようになります。 小規模なナレッジベースには long context と prompt caching、大規模または頻繁に更新されるデータには RAG、モデルの振る舞い自体を変える必要がある場合には fine-tuning を使います。本番システムでは通常、これらを組み合わせます。

原則2：検索品質がすべてを決める

Anthropic のデータは、検索層の改善には一つひとつ定量的な効果がある ことを示しています。生成がどれほど優れていても、無関係な検索結果は救えません。prompt 調整よりも検索最適化へ多くの労力を配分すべきです。

推奨する検索 pipeline：

Layer 1: Contextual Chunking（必須）
  LLM で各 chunk に context の接頭辞を追加する
  → 単独で検索失敗率を 35% 低減

Layer 2: Hybrid Search（必須）
  ベクトル検索（意味一致）+ BM25（正確な keyword）+ RRF fusion
  → 意味は拾えても keyword を落とすベクトル検索の弱点を補う

Layer 3: Reranking（強く推奨）
  cross-encoder または Cohere Reranker で top-k を並べ替える
  → 総検索失敗率を 2.9% から 1.9% へ低減

Layer 4: Query Transformation（状況に応じて）
  query rewriting / HyDE / Multi-query
  → 曖昧な query や不明瞭な表現を処理する

原則3：Contextual Retrieval のコストを制御する

各 chunk の context を LLM で生成すると高額に見えます。Anthropic の解決策は prompt caching です。文書全体を一度 cache し、その後の chunk ごとの生成では増分 token だけを使います。800-token の chunk と 8K-token の文書を仮定した計算では、文書 100 万 token あたり $1.02 です。実行時ではなく一度きりの indexing cost なので、本番でも十分に現実的です。

実装方針：

# 擬似コード：Contextual Retrieval の中核ロジック
CONTEXT_PROMPT = """
<document>
{whole_document}
</document>
<chunk>
{chunk_content}
</chunk>
この chunk が文書全体のどこに位置し、どんな役割を持つかを簡潔に説明してください。
context の説明だけを出力し、それ以外は出力しないでください。
"""

# 1. 文書ごとに、文書全体を prompt caching で一度 cache する。
# 2. 文書内の各 chunk について LLM で context を生成する（cache hit）。
# 3. contextualized_chunk = context + "\n\n" + original_chunk
# 4. contextualized_chunk から embedding と BM25 index を作る。

原則4：評価には ground truth が必要である

PDF の評価方法から、評価データセットには次の要素が必要だと分かります。

  • Query — ユーザーが尋ねる可能性のある質問
  • Golden Chunk — 正解が含まれるべき chunk
  • Golden Answer — 期待する回答

これがなければ、Ragas や DeepEval の指標には確かな土台がありません。少なくとも 50〜100 件の例を用意すべきです。

原則5：分割戦略は一律ではない

PDF がコード、小説、論文を扱うのは、種類ごとに最適な戦略が違うからです。

  • コード — 関数やクラス単位で分け、論理的なまとまりを保つ
  • 構造化文書 — 章や段落単位で分け、文書構造を尊重する
  • 非構造化の長文 — 類似度のしきい値に基づく semantic chunking を使う

原則6：Top-K を意図的に選ぶ

Anthropic は top-5、top-10、top-20 を試し、top-20 と reranking の組み合わせが最も優れている と報告しました。まず広い Top-K で候補を集め、reranker で最良の証拠を選びます。

私の推奨： 最初に top-20 を取得し、reranking 後の top-5 を LLM へ渡します。recall を確保しながら、context 長とコストを制御できます。