この記事はRAG（検索拡張生成）技術に関するものです。Claude Code CLIでの直接的な利用可能性を以下に評価します。

項目	適用可能性	説明
Claude Code CLIで直接利用	不可	RAGシステムの構築が必要であり、CLI単体では利用不可
プロンプトキャッシング	関連あり	Claude APIを使用するアプリケーション開発時に参考になる
チャンク分割の知識	間接的に有用	長いコードベースをClaude Codeに渡す際の参考になる
BM25 + セマンティック検索	不可	外部検索システムの構築が必要
埋め込みモデルの選択指針	参考情報	RAGシステムを構築する際の知識として有用

結論: Claude Code CLIユーザーが直接活用することはできませんが、以下の場合に知識として役立ちます：

自前のRAGシステムを構築してClaude APIと統合する場合
大規模なコードベースの検索システムを設計する場合
AIアシスタントのコンテキスト管理を最適化する場合

Contextual Retrieval（文脈検索）の紹介

元記事: Introducing Contextual Retrieval - Anthropic Engineering Blog

はじめに

AI モデルの有用性を高めるために、開発者はしばしばバックグラウンド知識を提供する必要があります。例えば、顧客サポートチャットボットは関連するFAQ記事へのアクセスが必要であり、法律アナリストアシスタントは膨大な過去の判例を参照できる必要があります。

開発者は一般的に**RAG（Retrieval-Augmented Generation / 検索拡張生成）**を使用してモデルの知識を強化します。RAGは知識ベースから関連情報を取得してユーザーのプロンプトに追加することで、モデルの応答を大幅に改善します。しかし従来のRAGソリューションでは情報をエンコードする際に文脈が失われ、関連情報の取得に失敗することがあります。

本記事では、RAGにおける検索ステップを劇的に改善するシンプルな手法「Contextual Retrieval（文脈検索）」を紹介します。

問題：チャンク分割時の文脈喪失

RAGでは、知識ベースは小さなチャンク（断片）に分割されます。これらのチャンクはエンコード（埋め込みベクトル化など）され、後で関連チャンクを取得するための検索インデックスに保存されます。

しかし、チャンク分割プロセスで文脈情報が失われることがよくあります。

たとえばSEC（米国証券取引委員会）提出書類のチャンクに「前四半期比で売上高が3%増加した」という記述があるとします。このチャンクだけでは以下の重要な情報が欠落しています：

どの企業のデータか？
どの四半期のデータか？
どの会計年度のデータか？

このような情報の欠如により、正確な情報取得が困難になります。

解決策：Contextual Retrieval

Contextual Retrievalは、以下の2つのサブ技術で構成される手法です：

Contextual Embeddings（文脈埋め込み）
Contextual BM25（文脈BM25）

これらの手法は、エンコード前に各チャンクに説明的な文脈情報を前置することで、チャンクの意味を明確化します。

文脈生成プロンプト

以下のプロンプトを使用して、Claudeに各チャンクの文脈を生成させます：

<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.

このプロンプトにより、通常50〜100トークン程度の簡潔な文脈説明が生成されます。

文脈付きチャンクの例

元のチャンク：

前四半期比で売上高が3%増加した。

文脈付きチャンク：

本ドキュメントは2024年第2四半期のAcme Corp年次SEC 10-K提出書類です。
前四半期比で売上高が3%増加した。

パフォーマンス結果

様々なデータセットでテストした結果、以下の改善が確認されました：

手法	検索失敗率	改善率
ベースライン（従来のRAG）	5.7%	-
Contextual Embeddings単独	3.7%	35%削減
Contextual Embeddings + BM25	2.9%	49%削減
Contextual Embeddings + BM25 + Reranking	1.9%	67%削減

評価指標：1 minus recall@20（上位20チャンク内での検索失敗率）

BM25とセマンティック検索の組み合わせ

RAGシステムでは通常、セマンティック検索（埋め込み類似度検索）が使用されますが、BM25（語彙ベースの検索）と組み合わせることで、さらに性能が向上します。

なぜ両方が必要か？

セマンティック検索：意味的に類似した内容を見つけるのが得意
BM25：正確なキーワードマッチ、固有名詞、技術用語の検索が得意

統合方法

TF-IDFエンコーディングと意味埋め込みの両方を作成
BM25で正確なキーワードマッチを検索
埋め込みで意味的類似性を検索
ランク融合技術で結果を統合

リランキング（Reranking）

初期検索で多くの候補を取得し、より精度の高いモデルで再順位付けを行う手法です。

推奨されるパイプライン

初期検索（150チャンク取得）
    ↓
リランキング
    ↓
上位20チャンクを最終結果として使用

テスト済みリランキングモデル

Cohere reranker：テスト済み、良好な結果
Voyage reranker：代替オプション

実装上の考慮事項

チャンク設定

以下の要素が検索性能に影響します：

パラメータ	推奨値	備考
チャンクサイズ	約800トークン	ドキュメントの性質に依存
ドキュメントサイズ	8kトークン	文脈生成時の入力サイズ
文脈説明	50〜100トークン	簡潔に保つ
チャンクオーバーラップ	調整が必要	ドメインに依存