context-ranking について
検索拡張生成のコンテキストを作るため、取得したテキストチャンクを関連性と多様性に基づいて順位付けするスキルです。初段のスコアリング、クロスエンコーダーによる再ランキング、多様性選択を組み合わせ、スコアと信頼度も付与します。
主な機能
- 01BM25と意味的類似度の統合
- 02クロスエンコーダーによる再ランキング
- 03MMRによる重複の抑制
- 04関連性とドメイン別加点の統合
- 05出典、スコア、信頼度の付与
活用シーン
- 01デバッグ用コード検索結果の絞り込み
- 02文書Q&A向けチャンクの選択
- 03複合的な質問に向けた多様なコンテキストの作成
インストール
コマンドをコピーしてターミナルで実行します。
npx skills add https:/ / github.com/ seb1n/ awesome-ai-agent-skills --skill context-rankingインストール後、Claude Code で/context-rankingを入力して読み込まれたか確認します。
詳細
コンテキストランキング
コンテキストランキングとは、取得したテキストチャンクを並べ替え、最も関連性が高く、多様で有用な情報を上位に表示するプロセスです。どの検索パイプラインでも、初期検索では幅広い候補が返され、その多くはクエリとわずかにしか関連していません。ランキングによって、この順不同の候補群が優先順位付きのリストに変換され、後続のステップ(コンテキストの組み立て、プロンプトの構築)で最適な情報を選び、それ以外を除外できるようになります。効果的なランキングは、根拠に基づく的確な回答と、曖昧で的外れな回答を分ける要素です。
ワークフロー
-
候補チャンクを収集する:検索レイヤーから初期取得したチャンク群を集めます。通常は、ベクトル検索、キーワード検索、またはハイブリッド検索の上位 k 件(k = 15-30)です。各チャンクには、暫定スコア(例:コサイン類似度または BM25 スコア)とソースのメタデータが付いています。
-
第 1 段階のスコアリングを適用する:高速で軽量なアルゴリズムを使って、各候補をスコアリングします。キーワードとの関連性には BM25、意味的な関連性にはクエリの埋め込みとチャンクの埋め込みのコサイン類似度が標準的な選択肢です。ハイブリッドパイプラインでは、両方のスコアを計算し、Reciprocal Rank Fusion(RRF)または重み付き線形結合を使って組み合わせます。この段階は高速で、すべての候補に対して実行できることを想定しています。
-
クロスエンコーダーで再ランキングする:第 1 段階の上位候補(通常 15-25 件)をクロスエンコーダーの再ランカーに渡します。クエリと文書を個別にスコアリングするバイエンコーダーの埋め込みとは異なり、クロスエンコーダーはクエリとチャンクを完全なアテンションで一緒に処理するため、関連性スコアの精度が大幅に高まります。Cohere Rerank、
bge-reranker-v2-m3、ColBERTv2 などのモデルが一般的に使われます。このステップは低速ですが、適合率を大幅に向上させます。 -
多様性に基づいて選択する:再ランキング後の上位結果は、1 つのサブトピックに集中し、クエリのほかの側面がカバーされないことがあります。Maximal Marginal Relevance(MMR)または同様の多様性アルゴリズムを適用し、すでに選択されたチャンクと類似しすぎるチャンクにペナルティを与えます。これにより、最終的なランキングリストが最も明白な解釈だけでなく、クエリの幅広い内容をカバーできるようになります。
-
最終スコアを付与して順位付けする:再ランカーの関連性スコアを、多様性ペナルティやドメイン固有のブーストシグナル(例:新しさによるブースト、ソースの信頼性の重み)と組み合わせ、最終的な複合スコアを算出します。この複合スコアの降順でチャンクを並べます。上位 n 件(n = 3-7)が、プロンプトに挿入する最終的なランク付け済みコンテキストになります。
-
メタデータと信頼度を付与する:ランク付けされた各チャンクに、最終スコア、ソースパス、信頼度の段階(高/中/低)を付記します。このメタデータは、後続のプロンプト組み立てステップでコンテキストの提示方法を判断するのに役立ち、ソースを引用する際にモデルが信頼度を調整できるようにします。
主要な概念
- BM25:単語頻度、逆文書頻度、文書長の正規化に基づく確率的なキーワードマッチングアルゴリズムです。完全一致する用語や希少なキーワードのマッチングに優れています。高速で解釈しやすい一方、同義語や言い換えには対応できません。キーワード検索における標準的な第1段階のランキング手法です。
- コサイン類似度:2つの埋め込みベクトル間の角度を測定します。値の範囲は -1 から 1 で、値が高いほど意味的な類似性が高いことを示します。セマンティック検索における標準的な第1段階のランキング手法です。品質は使用する埋め込みモデルに大きく左右されます。
- クロスエンコーダーによる再ランキング:クエリと文書を連結したものを入力として受け取り、関連度スコアを出力するトランスフォーマーモデルです。クエリと文書のトークン間に完全なクロスアテンションを適用するため、バイエンコーダーでは捉えられない細かな関連性を捉えられます。通常、コサイン類似度より 5~20 倍遅くなりますが、ランキングの精度は大幅に向上します。
- 最大限界関連性(MMR):クエリとの関連性と、すでに選択されたチャンクとの冗長性のバランスを取りながら、チャンクを反復的に選択するアルゴリズムです。lambda パラメーターで制御します。lambda = 1.0 では関連性のみを基準に選択し、lambda = 0.0 では多様性のみを基準に選択します。0.5~0.7 程度の値では、両者のバランスを取ります。多面的なクエリには欠かせません。
- 逆順位融合(RRF):ハイブリッド検索で使用されるスコア統合手法です。各チャンクについて、それぞれのランキング元ごとに 1/(k + rank) を計算し、その値を合計します。これにより、BM25 とコサイン類似度のスコア尺度の違いに左右されにくい統合ランキングが得られます。
使い方
クエリと候補となるテキストチャンクのリスト(任意で予備スコアやメタデータも含められます)を指定してください。このスキルはチャンクのスコア付け、再ランキング、多様化を行い、最終スコアと信頼度区分を付けたランキング済みリストを返します。出力するチャンク数(top-n)と、任意の多様性パラメーター(MMR lambda)を指定してください。
例
例1:デバッグに関するクエリでのコード検索結果のランキング
クエリ:「WebSocket 接続が、60 秒間操作がないと切断されるのはなぜですか?」
候補チャンク(ハイブリッド検索の上位8件):
| # | ソース | BM25 | コサイン類似度 | 内容の概要 |
|---|---|---|---|---|
| 1 | src/ws/server.ts:40-65 | 12.4 | 0.88 | pingInterval: 30000 と pingTimeout: 60000 を設定した WebSocket サーバーの構成 |
| 2 | src/ws/server.ts:80-95 | 8.1 | 0.82 | 「connection timed out」と記録する接続クリーンアップハンドラー |
| 3 | docs/websocket.md:15-30 | 6.3 | 0.79 | ドキュメント:「ping/pong によって接続を維持します。デフォルトのタイムアウトは60秒です。」 |
| 4 | src/ws/client.ts:10-35 | 5.7 | 0.84 | クライアント側の WebSocket ラッパー — pong 応答ハンドラーを実装していません |
| 5 | nginx.conf:22-28 | 9.8 | 0.71 | Nginx のプロキシ構成:WebSocket のアップストリームに proxy_read_timeout 60s を設定 |
| 6 | CHANGELOG.md:44-50 | 3.2 | 0.55 | 「v2.1:WebSocket の再接続ロジックを修正」— タイムアウトに関する詳細はありません |
| 7 | src/ws/server.ts:100-120 | 4.5 | 0.76 | WebSocket メッセージ用のレート制限ミドルウェア |
| 8 | package.json:15-20 | 2.1 | 0.45 | "ws": "^8.14.0" の依存関係エントリー |
クロスエンコーダーで再ランキングした後:
| 順位 | # | 再ランキングスコア | 理由 |
|---|---|---|---|
| 1 | 1 | 0.96 | 60秒のタイムアウト設定が直接示されています |
| 2 | 5 | 0.93 | Nginx のプロキシタイムアウト — 60秒後に切断されるもう一つの原因です |
| 3 | 4 | 0.89 | クライアントに pong ハンドラーがないため、ping が失敗する理由を説明しています |
| 4 | 2 | 0.85 | クリーンアップハンドラーがタイムアウトの挙動を裏付けています |
| 5 | 3 | 0.78 | ドキュメントがデフォルトの60秒という値を裏付けています |
| 6 | 7 | 0.42 | レート制限 — 関連性はわずかです |
| 7 | 6 | 0.30 | 変更履歴 — 役立つ詳細はありません |
| 8 | 8 | 0.15 | Package.json — 無関係です |
MMR による多様性選択後(上位5件、lambda=0.6):
src/ws/server.ts:40-65(スコア 0.96)— サーバー側の60秒タイムアウト設定nginx.conf:22-28(スコア 0.93)— Nginx プロキシの60秒読み取りタイムアウト(問題の別の原因)src/ws/client.ts:10-35(スコア 0.89)— クライアントに pong ハンドラーがない(クライアント側の根本原因)src/ws/server.ts:80-95(スコア 0.85)— クリーンアップハンドラーがタイムアウトの挙動を裏付けていますdocs/websocket.md:15-30(スコア 0.78)— デフォルトが60秒であることを確認するドキュメント
ランキングされたリストには、クリーンアップハンドラーとドキュメントによる確認に加え、異なる3つの原因(サーバー構成、nginx プロキシ、クライアントの pong ハンドラー)が含まれています。
例2:Q&A タスクにおけるドキュメントチャンクのランキング
クエリ:「組織で SAML を使った SSO を設定するにはどうすればよいですか?」
候補チャンク(ベクトル検索の上位6件):
| # | ソース | コサイン類似度 | 内容の概要 |
|---|---|---|---|
| 1 | docs/sso/saml-setup.md | 0.91 | SAML 設定の手順:メタデータ URL、証明書のアップロード、属性のマッピング |
| 2 | docs/sso/overview.md | 0.85 | SSO オプション(SAML、OIDC、LDAP)の概要。大まかな比較。 |
| 3 | docs/sso/saml-setup.md | 0.83 | SAML エラーのトラブルシューティング:署名の無効、時刻のずれ、NameID の欠落 |
| 4 | docs/sso/oidc-setup.md | 0.80 | OIDC 設定ガイド — SAML ではありません |
| 5 | docs/admin/org-settings.md | 0.77 | 組織設定ページ:SSO 設定パネルの場所 |
| 6 | blog/sso-announcement.md | 0.72 | SSO 機能の提供開始を告知するブログ記事 — マーケティング文であり、設定の詳細はありません |
クロスエンコーダーによる再ランキングと MMR の適用後(上位4件、lambda=0.7):
docs/sso/saml-setup.md(設定ガイド、スコア 0.95)— 直接的な回答:SAML の設定手順docs/admin/org-settings.md(スコア 0.82)— SSO 設定へのアクセス方法(別のドキュメントで、#1を補完します)docs/sso/saml-setup.md(トラブルシューティング、スコア 0.79)— ユーザーが遭遇する可能性のある一般的なエラーを予測していますdocs/sso/overview.md(スコア 0.71)— SSO オプションのより広範な背景情報を提供します
チャンク4(OIDC ガイド)は、SAML と無関係なため除外されました。チャンク6(ブログ記事)は、情報密度が低いため除外されました。
ベストプラクティス
- 必ず再ランキングする — 最終的なランキングを、埋め込みのコサイン類似度やBM25だけに頼ってはいけません。上位15〜25件にクロスエンコーダーの再ランキングを適用すると、ベンチマークで適合率が一貫して15〜30%向上します。
- 第1段階のスコアリングではハイブリッド方式を使う — BM25とコサイン類似度をRRFで組み合わせると、どちらか一方だけを使う場合よりも高い性能を得られます。特に、具体的な用語と一般的な意図が混在するクエリで効果的です。
- 複数の側面を持つクエリにはMMRを適用する — 「Xの原因は何で、どうすれば解決できますか?」のようなクエリには、2つの下位意図があります。多様性を考慮して選択しないと、上位の検索結果がすべて原因についてのものになり、解決策についての結果が含まれないことがあります。
- MMRのlambdaパラメーターを調整する — まずはlambda = 0.6(多様性より関連性をやや優先)から始め、ユースケースに応じて調整してください。事実に関する質疑応答では高めのlambda(0.7〜0.8)が効果的で、探索的なリサーチでは低めのlambda(0.4〜0.5)が適しています。
- 再ランキングの結果をキャッシュする — クロスエンコーダーの推論にはコストがかかります。同じクエリとチャンクの組み合わせが繰り返し現れる場合(複数ターンの会話でよくあります)は、再ランキングのスコアをキャッシュし、計算の重複を避けてください。
- NDCGとMRRで評価する — ラベル付きのテストセットで正規化割引累積利得と平均逆順位を使い、ランキング品質を測定してください。ランキングの評価には、単純なRecall@kよりもこれらの指標のほうが有益です。
エッジケース
- スコアの同点:複数のチャンクが同一またはほぼ同一の再ランキングスコアを得た場合は、より信頼性の高い情報源のチャンク、より新しい文書のチャンク、または情報密度の高いチャンクを優先して、同点を解消してください。
- 結果が1件だけのクエリ:コーパス内に関連するチャンクがちょうど1件だけのクエリもあります。この場合でもランキングのパイプラインは正しく動作する必要があります。再ランキングではそのチャンクに高いスコアを付け、MMRでは多様性がないことを理由に不利に扱わないようにしてください。
- 敵対的なチャンクやノイズを含むチャンク:ウェブからスクレイピングしたコンテンツやユーザー生成コンテンツには、BM25のスコアを不当に引き上げるSEOスパムや無関係なキーワードの詰め込みが含まれることがあります。通常、クロスエンコーダーの再ランキングで対処できますが、前処理の段階で品質フィルターを追加することも検討してください。
- 言語をまたぐクエリ:クエリの言語とコーパスの言語が異なる場合は、埋め込みモデルと再ランキングモデルが言語をまたぐマッチングに対応していることを確認するか、ランキングの前に翻訳の手順を追加してください。
- 候補数が非常に多い場合(100件以上):初期検索で数百件の候補が返される場合は、再ランキングのレイテンシーを管理しやすくするため、クロスエンコーダーの適用前にスコアのしきい値による絞り込みなど、中間のフィルタリング手順を追加してください。