技術サマリー：検索の先へ：コード検索のためのマルチタスクベンチマークとモデル

1. 問題定義

現在のコード検索評価手法は、堅牢で生産環境で利用可能なシステムの開発を阻害する 4 つの重大な限界に苦しんでいます：

1. 再ランク付けのサポート欠如: 既存のベンチマークは、生産パイプラインにおいて不可欠な再ランク付け段階を無視し、第一段階の検索のみを評価しています。実務家は、コード上で訓練されていない汎用エンコーダを再ランク付けに強制的に使用せざるを得ず、品質の低下を招く可能性があります。
2. データ汚染と過学習: CoIR などの著名なベンチマークは、多くのコード表現モデルの前訓練データとして機能してきたデータセット（CodeSearchNet など）に大きく依存しています。この訓練と評価の重複により、指標が最大 100% まで過大評価され、データセット間の漏洩が生じます。
3. ラベルノイズと自明な一致: 人間が注釈付けたデータセットには、しばしば重大なノイズが含まれています（例：CoSQA における約 51% の不一致ペア）。さらに、多くのタスクは、真の意味検索ではなく、文字列一致（例：コードとその自身のドキュメント文字列の一致）に還元されてしまいます。
4. 退化的な関連性構造: ほとんどのベンチマークは、各クエリに対して正確に 1 つの関連ドキュメントを割り当て、バイナリスコアを使用し、ハードネガティブを含みません。これにより、nDCG や MRR などのランキング指標が、重複したヒット・ミス信号に縮退し、モデルが正しい解決策と、妥当だが誤ったディストラクタ（妨害項）を区別する能力をテストすることができません。

さらに、既存のベンチマークはプログラミング言語の多様性に欠け（多くの場合 Python と SQL に限定）、短いキーワードクエリのような現実の開発者検索行動をシミュレートできていません。

2. 手法：COREB ベンチマーク

著者は、上記の欠陥に対処するために設計された 5 段階のパイプラインを通じて構築された COREB（汚染制限付きマルチタスクコード検索および再ランク付けベンチマーク）を導入します：

• ステップ 1：シード収集: 問題は、時間的フィルタリングを通じて汚染を軽減する継続的に更新されるベンチマークである LiveCodeBench (LCB) から収集されます。COREB は、重ならないコンテストウィンドウを網羅するタイムドスナップショット（例：v202602、v202603）としてリリースされます。
• ステップ 2：反事実的書き換えとコード生成: 記憶化を防ぐため、問題文とテストケースは、アルゴリズム的論理を維持しつつ、エンティティ、文脈、変数名を修正する反事実的書き換えを受けます。2 つの最先端 LLM（Gemini 3 Flash、Claude Sonnet 4.5）が、5 つの言語（Python、Java、C++、Go、Ruby）で解決候補を生成します。
• ステップ 3：クエリ生成: クエリは LLM と人間のレビューを通じて生成され、3 つの主要なタスクタイプを作成します：
  • テキストからコード (T2C): 自然言語の問題記述からコードへ。
  • コードからコード (C2C): 意味的に同等なコード（クロスリンガル）へのコードスニペット。
  • コードからテキスト (C2T): 問題記述へのコードスニペット。
  • サブタスク には、標準的/省略された記述、完全な問題文、短い「検索」スタイルのキーワードクエリが含まれます。
• ステップ 4：段階的関連性判定: バイナリラベルの代わりに、COREB は 3 レベルのスキームを使用します：
  • 関連性=2（真陽性）: 検証済みの正しい解決策または元の問題記述。
  • 関連性=1（ハードネガティブ）: 表面的には妥当だが誤った同一問題アイテム（例：失敗したコード解決策、LLM 生成のノイズ記述）。
  • 未判定（イージーネガティブ）: コーパス内のその他のすべてのアイテム。
  • 指標は relevance level=2 で計算され、ハードネガティブは nDCG に 0 の利得をもたらしますが、上位ランクを占有することでモデルを罰します。
• ステップ 5：データセット形式: クエリ、コーパス、関連性判定は JSONL ファイルとして配布されます。

3. 主な貢献

1. 汚染制限付きベンチマーク: COREB は書き換えられた LCB 問題に基づいて構築されており、モデルが記憶された表面形式に依存できないようにしています。これは 5 つのプログラミング言語と 3 つの検索方向を網羅しています。
2. 2 段階パイプライン評価: 以前の研究とは異なり、COREB は検索と再ランク付けの両方の段階を評価し、すぐに使用可能なパイプラインを提供します。
3. ハードネガティブを含む段階的関連性: このベンチマークは、モデルの識別能力をテストするために、明示的にハードネガティブ（失敗した解決策、ノイズ記述）を含み、バイナリのヒット・ミス評価を超えて進歩します。
4. COREB-RERANKER: COREB、CodeSearchNet、APPS、CosQA を含む混合コーパスで訓練された微調整済み再ランク付けモデル（Qwen3-Reranker-4B ベース）です。これは、3 つのタスクすべてで一貫した改善を達成した最初のモデルとして示されています。

4. 実験結果

著者は、3 つのタスク全体で 11 の埋め込みモデルと 5 つの再ランク付けモデルを評価しました。主な知見は以下の通りです：

• タスク非対称性: 単一のモデルが 3 つのタスクすべてを支配することはありません。ランキングは検索方向（T2C、C2C、C2T）によって大きく変化します。
• 特化対規模: モデルの規模よりも、コード特化型の訓練の方が重要です。0.5B のコード特化モデル（C2LLM-0.5B）は、全体的に 12 ポイント以上、汎用 8B エンコーダを上回ります。コード特化モデルは、コードからコードの検索において約 2 倍の優位性を示します。
• 「短いクエリ」の崩壊: すべてのモデルが、現実の開発者行動に最も近い短いキーワードクエリ（「検索」サブタスク）において、nDCG@10 がほぼゼロに崩壊します。これは未解決のギャップのままです。
• 言語バイアス: 訓練データの分布を追跡し、Python や Java に比べて低リソース言語（Ruby、Go）のパフォーマンスが大幅に低下します。
• 再ランク付けの影響: 市販の再ランク付けモデルは高度にタスク非対称です。いくつかはコードからテキストの性能を 20 ポイント以上低下させます。微調整済みの COREB-RERANKER のみが、3 つのタスクすべてで正味のプラスの利益を達成します。
• ハードネガティブの識別: モデルは頻繁に、真陽性よりもハードネガティブ（失敗した解決策）を上位にランク付けします。「ハードネガティブ侵入率」はテキストからコードで 55% を超え、バイナリベンチマークでは見えない失敗モードです。

5. 意義と主張

この論文は、COREB が設計によって既存のコード検索ベンチマークの構造的欠陥に対処すると主張しています。その意義は以下の点にあります：

• 現実性: 段階的関連性とハードネガティブを使用することで、正しいコードと妥当だが誤ったコードを区別することが重要な、生産システムの課題をよりよく反映しています。
• 汚染耐性: 反事実的書き換えと時間的フィルタリングにより、ベンチマークスコアが記憶化ではなく、真のコーディングおよび検索能力を反映することを保証します。
• パイプラインの完全性: これは、検索と再ランク付けの完全な評価済み 2 段階パイプラインを提供する最初のベンチマークであり、汎用再ランク付けモデルでは不十分であり、一貫した改善にはドメイン固有の微調整が必要であることを実証しています。
• 診断的価値: このベンチマークは、短いクエリに対するクエリ拡張技術の必要性など、将来の研究の方向性を導く特定の失敗モード（短いクエリの崩壊、言語バイアスなど）を明らかにします。

著者は、コード特化型の埋め込みが汎用エンコーダよりも優れている一方で、分野は「短いクエリ」の問題と、真に効果的なコード検索システムを構築するための堅牢な再ランク付け戦略の欠如に対処しなければならないと結論付けています。この進歩を促進するため、データと微調整済みの COREB-RERANKER が公開されます。