context-retrieval について
context-retrievalは、検索した根拠に基づいて回答を生成するためのエージェントスキルです。セマンティック検索やキーワード検索から、再ランキング、引用、検証までのRAGワークフローを扱います。
主な機能
- 01クエリの埋め込みとベクトル検索
- 02セマンティック・キーワード・ハイブリッド検索
- 03候補チャンクの再ランキング
- 04ソースメタデータ付きのコンテキスト構成
- 05回答の検証と引用
活用シーン
- 01ソースファイルに基づくコードベースの質問回答
- 02サポート対応向け製品ドキュメント検索
- 03RAG回答用の引用付きコンテキスト作成
インストール
コマンドをコピーしてターミナルで実行します。
npx skills add https:/ / github.com/ seb1n/ awesome-ai-agent-skills --skill context-retrievalインストール後、Claude Code で/context-retrievalを入力して読み込まれたか確認します。
詳細
コンテキスト検索
コンテキスト検索とは、ナレッジベースから最も関連性の高い情報を見つけて組み合わせ、AI エージェントの回答を最新かつ事実に基づくデータで裏付けるプロセスです。これは検索拡張生成(RAG)の基盤であり、生成された出力が幻覚ではなく、正確で検証可能なものになるようにします。
ワークフロー
-
クエリを埋め込む:OpenAI
text-embedding-3-small、Cohereembed-v3、またはbge-largeのようなオープンソースモデルなどの埋め込みモデルを使って、ユーザーの自然言語によるクエリを高密度のベクトル表現に変換します。この埋め込みはクエリの意味を捉えるため、保存済みのドキュメントと比較できます。 -
ベクトルストアを検索する:クエリの埋め込みをベクトルデータベース(Pinecone、Weaviate、Qdrant、Chroma など)に送信し、近似最近傍(ANN)検索を実行します。リランカーが処理できるだけの素材を確保するため、通常は k = 10~20 の上位 k 個の候補チャンクを取得します。
-
結果を再ランク付けする:候補チャンクをクロスエンコーダーのリランカー(Cohere Rerank、
bge-reranker-large、ColBERT モデルなど)に渡します。リランカーはクエリ全体に注意を向けて各チャンクを採点するため、コサイン類似度のみの場合よりも精度の高い関連性スコアを生成します。上位 n 件(通常 n = 3~5)を残します。 -
コンテキストウィンドウを組み立てる:選択したチャンクを関連性スコアの降順に並べ、1 つのコンテキストブロックに連結します。エージェントが出典を引用できるよう、各チャンクの前に出典メタデータ(ファイルパス、URL、ページ番号)を付けます。合計トークン数が、プロンプトのコンテキスト部分に割り当てられたモデルの上限に収まるようにします。
-
回答を生成する:組み立てたコンテキストを、元のクエリと、提示されたコンテキストのみから回答するようモデルに指示するシステム指示とともに、LLM のプロンプトに入力します。これにより、回答が検索した事実に基づくものになり、幻覚を抑えられます。
-
検証して引用する:生成後、回答が検索されたチャンクに実際に含まれる情報を参照していることを確認します。ユーザーが主張ごとに出典ドキュメントをたどれるよう、インライン引用または参考資料のセクションを付けます。
主な概念
- セマンティック検索:完全一致のキーワードではなく、意味に基づいてドキュメントを見つけるためにベクトル埋め込みを使用します。言い換えや同義語の処理に優れていますが、正確な技術用語を見落とす場合があります。
- キーワード検索(BM25):用語頻度に基づく従来の検索方式で、完全一致や出現頻度の低い用語の検索に優れています。高速で解釈しやすい一方、同義語は考慮しません。
- ハイブリッド検索:セマンティック検索とキーワード検索(BM25 とコサイン類似度スコアの加重融合など)を組み合わせ、両方の長所を活かします。多くの本番環境の RAG システムでは、ハイブリッド検索が使われています。
- チャンク化戦略:インデックス作成の前に、ドキュメントをチャンクに分割する必要があります。一般的な方法には、固定サイズのトークンウィンドウ(256~512 トークン、50 トークンのオーバーラップ)、文の境界での分割、再帰的な文字分割があります。小さなチャンクは精度を高め、大きなチャンクはより多くのコンテキストを保持します。
- 埋め込みモデル:埋め込みモデルの選択は検索品質に影響します。大規模なモデル(1024 次元以上)はより細かなニュアンスを捉えますが、保存とクエリにかかるコストが高くなります。選択する前に、必ず自身のドメインでベンチマークを実施してください。
使用方法
このスキルを使用するには、ドキュメントの埋め込みがベクトルデータベースに保存された、インデックス作成済みのナレッジベースが必要です。入力として自然言語のクエリを指定してください。このスキルは、プロンプトに組み込める状態の検索済みコンテキストブロックと、引用用の出典メタデータを返します。
例
例 1:コードに関する質問のためにコードベースのコンテキストを取得する
クエリ:「認証ミドルウェアはどのように JWT トークンを検証しますか?」
取得されたチャンク(再ランキング後):
| 順位 | ソース | スコア | スニペット |
|---|---|---|---|
| 1 | src/middleware/auth.ts:14-38 | 0.94 | export function validateToken(req, res, next) { const token = req.headers.authorization?.split(' ')[1]; if (!token) return res.status(401).json({ error: 'Missing token' }); try { const decoded = jwt.verify(token, process.env.JWT_SECRET); req.user = decoded; next(); } catch (e) { return res.status(403).json({ error: 'Invalid token' }); } } |
| 2 | docs/auth-flow.md:8-22 | 0.87 | "JWT は JWT_SECRET 環境変数を使用して HS256 で署名されます。トークンの有効期限は 24 時間です。ミドルウェアは Authorization ヘッダーからトークンを抽出し、署名を検証して、デコードされたペイロードを req.user に設定します。" |
| 3 | tests/auth.test.ts:5-19 | 0.72 | 有効なトークン、期限切れのトークン、不正な形式のトークンのシナリオを網羅するテストケースです。 |
組み立てられたプロンプト:
Answer the following question using ONLY the provided context. Cite file paths.
Context:
[1] src/middleware/auth.ts:14-38 — export function validateToken(req, res, next) { ... }
[2] docs/auth-flow.md:8-22 — The JWT is signed with HS256 using the JWT_SECRET env var...
[3] tests/auth.test.ts:5-19 — Test cases covering valid token, expired token...
Question: How does the authentication middleware validate JWT tokens?
例 2:サポートの質問のために製品ドキュメントを取得する
クエリ:「メールにアクセスできなくなった場合、パスワードをリセットするにはどうすればよいですか?」
取得されたチャンク:
help/account-recovery.md(スコア 0.91) — "登録済みのメールアドレスにアクセスできない場合は、Settings > Account > Identity Verification に移動してください。電話番号または政府発行の身分証明書を使用して、本人確認を行うよう求められます。確認が完了すると、新しいメールアドレスを設定してパスワードをリセットできます。"help/password-reset.md(スコア 0.85) — "パスワードをリセットするには、ログインページで「Forgot Password」をクリックしてください。登録済みのメールアドレスにリセットリンクが送信されます。リンクの有効期限は 1 時間です。"
生成された回答:「メールにアクセスできなくなった場合は、本人確認のフローを利用してください。Settings > Account > Identity Verification に移動し、電話番号または政府発行の身分証明書で本人確認を行い、メールアドレスを更新してから、ログインページでパスワードをリセットします。[出典:help/account-recovery.md、help/password-reset.md]」
ベストプラクティス
- 本番環境ではハイブリッド検索を使用します — BM25 キーワード検索とセマンティックなベクトル検索を組み合わせることで、どちらか一方のみを使う場合よりも一貫して高い性能が得られます。
- 常に再ランキングします — 上位 20 件の結果をクロスエンコーダーで再ランキングすると、埋め込みのコサイン類似度だけに頼る場合と比べて、適合率が大幅に向上します。
- チャンクにオーバーラップを設けます — 隣接するチャンク間でトークンを 10~20%重複させ、重要な情報がチャンクの境界で分断されるのを防ぎます。
- メタデータを含めます — 取得したコンテキストを追跡可能かつ引用可能にするため、ファイルパス、セクション見出し、タイムスタンプ、作成者を埋め込みとともに保存します。
- top-k を実測に基づいて調整します — 必要な数より多く候補を取得し(k = 15~20)、その後、再ランキングで最適な 3~5 件に絞り込みます。これにより、再現率と適合率のバランスが取れます。
- 定期的にベンチマークします — 対象分野のラベル付き評価セットを使用し、Recall@k、MRR、NDCG などの指標で検索品質を測定します。
エッジケース
- 関連する結果が見つからない場合:最上位の検索スコアが信頼度のしきい値(例:< 0.5)を下回る場合、エージェントは回答を捏造するのではなく、情報が不足していることを認める必要があります。
- 矛盾するソースがある場合:取得したチャンクに矛盾する情報が含まれている場合、一方を黙って選ぶのではなく、両方の見解を示し、相違点を指摘します。
- 古くなった、または最新でないコンテンツ:数か月前にインデックス化されたドキュメントは古くなっている可能性があります。メタデータにタイムスタンプを含め、スコアが近い場合は、より新しいチャンクを優先します。
- 極端に短いクエリや長いクエリ:単語 1 つのクエリではノイズの多い結果が返される場合があるため、クエリの拡張を検討します。非常に長いクエリでは、サブクエリに分解して結果を統合すると効果的な場合があります。
- 多言語のナレッジベース:埋め込みモデルがコーパス内の言語に対応していることを確認するか、埋め込みの前に翻訳処理を行います。