超越检索：面向代码搜索的多任务基准与模型 Beyond Retrieval: A Multitask Benchmark and Model for Code Search
提出 COREB 多任务代码检索与重排序基准，并发布首个全任务正向增益的重排序器
前置知识
Dense Retrieval（稠密检索）
用预训练编码器将查询和文档各自编码为连续向量，通过 cosine 相似度在向量空间内做最近邻搜索，从而定位相关文档。代码搜索中通常先用 embedding 模型做第一阶段检索，再用 reranker 做精排。
本文核心实验就是稠密检索，且 11 个 embedding 模型横跨 0.5B-8B 参数，先理解两阶段管线才能看懂 COREB 为什么同时评估 retriever 和 reranker。
Cross-Encoder Reranker（交叉编码重排序器）
把 query 和 document 在输入层拼接后联合编码，由 Transformer 输出一个相关性分数。相比双塔 embedding，cross-encoder 能捕捉二者细粒度交互，但计算量随候选数线性增长，所以只对 top-k 重排。
COREB-RERANKER 就是一个 cross-encoder reranker；它必须用梯度反向传播同时看到 (q,d) 对才能学到把代码方案排在正确位置的能力。
LiveCodeBench（LCB）
一个持续更新的竞赛编程评测基准，通过时间窗口筛选避免训练-测试污染。每个问题配套测试用例，可直接对生成代码做执行级 Pass@1 验证，是当前衡量代码 LLM 的主流工具。
COREB 的全部种子题都来自 LCB，作者对题目做反事实改写并重新执行生成方案，文章核心可信度都建立在 LCB 的时间隔离机制上。
Data Contamination（数据污染）
训练语料意外混入测试样本，导致模型凭记忆而非真实能力答题。代码检索场景下 CodeSearchNet 类数据既被预训练又被评测，能让指标被人为抬高 100%。
D2 问题是 COREB 的核心动机；只有理解污染能造成多大偏差，才能体会为什么作者坚持重新改写题目而非沿用公开数据集。
研究动机
现有代码检索基准存在四类系统性问题。D1 缺乏重排序评估：CoIR 等基准只评估 embedding 阶段，但生产环境几乎都是 retrieve-then-rerank 双阶段管线，没有重排序基准导致只能用通用 reranker 拼凑。D2 污染严重：CoIR 语料 85% 来自 CodeSearchNet 及其衍生集，而这些又恰好是 CodeBERT、CodeT5、CodeRetriever 等模型的预训练数据，Allamanis 报告污染可让指标虚高 100%，CoSQA 经功能验证有约 51% 的对子是错标的。D3 标签噪声与任务退化：作者人工检查 80 个测试对有约 60% 有问题，CodeSearchNet 用自带 docstring 当查询被原作者称为 overly simplistic，且 CoIR 的 10 个数据集中有 3 个根本不算代码检索。D4 退化相关性结构：所有 10 个数据集都只有二元标签、单正例、无显式难负例，导致 $nDCG@k$ 与 $Recall@k$ 在数学上退化成命中/未命中的二元信号，且覆盖面只到 Python、SQL 或 C++，Go、Ruby 完全空缺。
本文的目标是构建一个污染受限、覆盖完整两阶段代码搜索管线的多任务基准 COREB，并配套发布一个在所有检索方向上都能稳定增益的 fine-tuned 重排序器。具体目标包括：覆盖 text-to-code、code-to-text、code-to-code 三种检索方向与 Python、C++、Java、Go、Ruby 五种语言；通过反事实改写种子题加执行级验证，从源头消除标签噪声；引入显式 hard negative 与多级相关度，让 nDCG 真正反映模型对难负例的辨识能力；以定期发布（v202602、v202603）的形式持续抵抗时间维度上的污染。
与已有工作不同的是，已有工作要么只评估 embedding（CoIR、CPRet），要么只针对单一任务或语言；要么继续沿用 CodeSearchNet 等污染严重的旧语料。COREB 的独特切入点是「以反事实改写 + 重新执行」的方式主动控制污染，把 LCB 这种执行可验证的竞赛题改造成带分级标签的检索实例，从数据生成源头解决 D2-D4，并首次让 reranker 评估获得干净 ground truth。同时通过自己训练 COREB-RERANKER 证明：在这种干净基准上确实可以学到一个全任务正向的 reranker，而现有通用 reranker 都做不到。
核心方法
COREB 的整体思路可以分成两个层面。第一层是构造一个受控、可执行验证的检索基准：直接复用 LiveCodeBench（LCB）的竞赛编程题和测试用例，但通过反事实改写消除模型对题目表面形式的记忆，并在五种语言上让两个前沿 LLM（Gemini 3 Flash、Claude Sonnet 4.5）重新生成方案，最后用测试用例的真实通过/失败当作 ground truth 相关度。第二层是在此基准上同时评测 11 个 embedding 模型与 5 个 reranker，并基于 C2LLM-7B 检索结果微调出一个新的 COREB-RERANKER。直觉上，先用执行结果作为「硬证据」压制标签噪声，再用分级 qrels 让重排序任务真正变成「区分几乎对但其实错的代码」，最后用 model soup 把两个不同 seed 训出的 LoRA 加权平均，缓解小样本过拟合。
与已有方法最本质的区别有两点。其一，相关度标签完全由程序执行结果定义（pass/fail），而不是人工标注或字符串匹配，从而将 CoSQA 类 51% 的标注噪声降到零。其二，引入 relevance=1 的「同题难负例」——即同一道题下生成的、看起来很像但实际跑不过测例的失败方案，以及 LLM 生成的噪声描述——并在 nDCG 中让 hard negative 占据排名但不贡献增益，因而「排错一个近乎正确的方案」会被显式惩罚。这是 CoIR 这类二元标签基准无法暴露的细粒度能力差异。
方法步骤详情
完整构造管线分五步。Step 1（种子题）：从 LCB 的 V5、V6 两个时间隔离快照中各取 167 与 175 道题，按 2024-09 到 2025-04 的时间窗口筛选。Step 2（反事实改写与代码生成）：用 GPT-o1 对题目描述、变量名、命名实体、IO 例子做反事实重写，人工核对语义等价后再让原测试用例重跑确认通过，然后让 Gemini 3 Flash 与 Claude Sonnet 4.5 在 Python、C++、Java、Go、Ruby 五种语言上各生成一份方案，记录执行结果，总计 3414 个方案，其中 1065 个通过全部测例。Step 3（查询生成）：对每个种子题生成 T2C 的 Canonical Retro（120 token）、Full Retro（431 token）、Search（19 token 关键词）三种查询，以及 C2C 的 Cross-Lingual 锚点代码片段和 C2T 的代码方案，所有 LLM 起草后人工核对是否泄露答案。Step 4（检索实例与分级标签）：每个 $(q, d)$ 对打上 $rel=2$（真正例）/$rel=1$（同题难负例）/$rel=0$（易负例）的三级标签，nDCG 只对 $rel=2$ 计数 +1，对 $rel=1$ 计 0 但仍占据 ranking position。Step 5（数据集格式）：发布 JSONL 的 queries、corpora、qrels，开源在 HuggingFace 与项目页。COREB-RERANKER 的训练则把 Qwen3-Reranker-4B 作为基座，用 LoRA 在 3.1M 样本（含 COREB v202602 + CodeSearchNet + APPS + CoSQA + CodeFeedback）上微调，正样本翻倍且每个正样本配 1 易 + 1 难负例，最后对两个不同 seed 的 LoRA 做 uniform soup，确保与 v202603 测试集在题目级别完全不相交。
技术新颖性
技术新颖性集中在三个层面。第一，把可执行验证从代码生成评测移植到检索评测，用程序化 ground truth 取代人工标注，从源头消除 51% 一类的标注错误，这在 CoIR 时代是不可想象的。第二，引入同题反事实难负例并设计分级的 nDCG 评估协议：hard negative 既要「出现」也要「被错误地排在真正例之上时」才扣分，从而能区分「识别到这道题」与「真的答对这道题」。第三，在如此干净的基准上首次证明：通过 Qwen3-Reranker-4B 的 LoRA 微调 + uniform model soup，可以获得一个在 T2C、C2C、C2T 三个方向上同时净增益的重排序器，而 4 个开源 baseline 在三个方向上没有一个是净正向的，这从经验上闭合了「为什么要做 COREB」的回路。
实验结果
实验在 v202603 上评估 11 个 embedding（参数 $0.5B-8B$）与 5 个 reranker，前 10 检索 + 上文提到的三个任务统一协议。核心发现如下。第一，没有任何模型在三任务上同时第一：GemEmb-2 以 $0.637$ 的总体 $nDCG@10$ 居首，但在 T2C 上输给 C2LLM-7B；C2LLM-7B、0.5B 在 T2C 拿到 $0.443$ / $0.430$ $nDCG@10$，验证了代码专用训练优先于规模。第二，规模与质量并非单调：Qwen3-Emb-8B 整体 $0.481$，反被 Qwen3-Emb-0.6B 的 $0.477$ 接近，且 C2C 上 $0.320$ vs $0.384$ 大幅下滑；F2LLM-1.7B 也比 F2LLM-4B 差。第三，代码专用优于通用同规模甚至跨规模：Jina-code-0.5B 在 C2C 上 $0.677$ $nDCG@10$，与 GemEmb-2 并列前二，远超 8B 的 Qwen3；C2LLM-0.5B 在总体上比 Qwen3-Emb-8B 高出 12 点以上，0.5B 代码专用模型每 B 参数的 nDCG 大约是 8B 通用模型的 $13\times$。第四，Task 难度差距极大：模型平均 C2T $nDCG@10 = 0.73$，T2C $= 0.39$，C2C $= 0.52$，但 C2C 的跨模型离散度最大，几乎是 C2T 的两倍。第五，短关键词查询全军覆没：在 Search 子任务（约 19 token）上，所有模型 $nDCG@10$ 都跌到 $0.000 - 0.015$，比 Canonical 子任务低两个数量级。第六，Hard negative 入侵率（图 7）显示 T2C 上 $55\%+ $ 的查询至少有一个失败方案被排在真正例之上，GemEmb-2 高达 $64\%$；C2C 介于 $43\% - 59\%$；C2T $6\% - 30\%$，最佳与最差模型差 $5\times$。第七，重排序高方差：图 8 显示同一 T2C 任务上 Jina v2 重排后 $\Delta nDCG@10$ 为 $-8.3\%$，Qwen3-4B 仅 $-0.1\%$，C2T 上 Jina v2 退化 $-22.4\%$，最大跨 baseline 差距达 12 点，且没有任何 baseline 是三任务全正的；COREB-RERANKER 是唯一在三任务上都 $\Delta > 0$ 的。
查看结构化数据
| 任务 | 指标 | 本文 | 基线 | 提升 |
|---|---|---|---|---|
| Text-to-Code (T2C) 总体第一阶段检索 | nDCG@10 (v202603) | GemEmb-2 (闭源) 0.434，C2LLM-7B (开源最佳) 0.443 | Qwen3-Emb-4B 0.390，Qwen3-Emb-8B 0.328 | C2LLM-7B 比同规模通用 Qwen3-4B 高约 0.05 个 nDCG 点（约 14% 相对提升），证明代码专用训练在 7B 量级已稳定胜出 |
| Code-to-Code (C2C) 跨语言检索 | nDCG@10 (v202603) | GemEmb-2 0.698，Jina-code-0.5B 0.677 (开源最强) | Qwen3-Emb-8B 0.320，F2LLM-0.6B 0.334 | 代码专用 0.5B 模型约为通用 8B 模型的 2×（0.677 vs 0.320），是任务间差距最大的方向 |
| Code-to-Text (C2T) 文档检索 | nDCG@10 (v202603) | GemEmb-2 0.813，C2LLM-7B 0.795 | Qwen3-Emb-8B 0.660 | C2T 是最容易的任务，前 4 名 nDCG 都 ≥ 0.75，模型间差距明显小于 C2C |
| T2C 重排序（top-128, 基于 C2LLM-7B） | ∆ nDCG@10 (%) | COREB-RERANKER 在 T2C 上净正向（是唯一三任务净正向的） | Jina v2 -8.3%，Jina v3 接近 0，Qwen3-0.6B 接近 -2%，Qwen3-4B -0.1% | 所有 4 个开源 baseline 在 T2C 上都退化；COREB-RERANKER 终结了「reranking always helps」的旧假设 |
| C2T 重排序（top-128, 基于 C2LLM-7B） | ∆ nDCG@10 (%) | COREB-RERANKER 净正向 | Jina v2 -22.4%，Qwen3-4B -3.2%（退化最小的 baseline） | C2T 重排序最敏感，单 baseline 退化幅度比 T2C 大近 3×，最大差距达 12 点以上 |
| C2C 重排序（top-128, 基于 C2LLM-7B） | ∆ nDCG@10 (%) | COREB-RERANKER 净正向 | Qwen3-4B +3.3%（唯一正向 baseline），其他三个仍退化 | C2C 是唯一让 baseline 正向的任务，但跨 baseline 仍有 12 点差距 |
| 参数效率（Overall nDCG@10 / B 参数） | 相对值 | C2LLM-0.5B 达开源最佳 95.9% 的 nDCG@10，仅用 7% 参数 | Qwen3-Emb-8B 用 16× 参数量但得分低于 C2LLM-0.5B | 0.5B 代码专用模型的每 B 参数 nDCG 约为 8B 通用模型的 13×（图 10） |
局限与改进
作者明确承认两点局限。其一，Search 子任务（19 token 关键词）几乎所有模型 nDCG@10 跌到 0.000-0.015，提示开发者真实搜索的最常见形态在当前 embedding + reranker 范式下仍未解决，作者只是建议用 HyDE / Query2doc 类查询扩展去做，自身并未在论文里实验。其二，C2C 的平均锚点长度是 207 token 的代码片段，对于超长文件（如 2k token 以上的整文件级检索）覆盖不足；并且 v202602 与 v202603 只覆盖五种主流语言，Rust / TypeScript / Kotlin 等热门语言缺位。从外部观察看，COREB-RERANKER 的训练集虽然含 3.1M 样本并做了正样本翻倍 + 1:1 易/难负例，但只是 LoRA + uniform soup，并未给出绝对分值上的全任务 ablation；GitHub Code Search 等工业级实时检索系统所要求的延迟-精度权衡也未被纳入考虑。
独立分析的弱点
独立观察到的弱点有四处。第一，重排序实验只用 C2LLM-7B 作为 top-128 候选供应者，缺少用不同 retriever 喂候选时 reranker 排名是否稳定的 ablation，可能存在 retriever-reranker 的隐性耦合。第二，COREB-RERANKER 只在 v202603 上整体报数，没有给出 Search 子任务、Ruby/Go 子语言消融，无法判断它到底是所有方向都更好还是只在 C2C 等高难度任务上拉分。第三，反事实改写只保证语义等价 + 测试集仍然判 pass，但无法完全排除新题目恰好落入某个模型预训练语料的另一种表述（作者用 Gemini/Claude Pass@1 下降做了部分验证，但样本量有限）。第四，评测语言仅五种，且都是函数级 + 单文件，与真实代码搜索中整模块、跨文件、长上下文的情境距离仍较大，迁移到 Cursor / Copilot 这类工业级工具时存在分布外风险。改进方向：增加 retriever $\times$ reranker 交叉验证；补 Search / Ruby / Go 子任务消融；引入 LLM-as-a-judge 或更大规模对比实验验证改写纯净度；扩展到 multi-file 与长上下文任务形态。
未来方向
作者给出的方向是查询扩展（HyDE、Query2doc）解决 Search 子任务的近零表现，以及更多语言和更长上下文。从延伸视角看，还有几条路值得探索。其一，把执行验证作为在线自我对弈机制：让重排序器在生产环境中主动运行候选，把运行时行为反馈灌回训练循环，可能比 human/llm 标注更鲁棒。其二，把 COREB 作为 RLHF-style 的偏好对来源：在 T2C 上把通过测例的方案作为 chosen、跑失败的同题方案作为 rejected，让模型直接学到执行级偏序，可能比 LoRA 拟合更稳定。其三，与代码生成模型做联合训练，让 embedding 同时为生成与检索服务，避免今天 retriever 与 generator 各管一摊的工程割裂。其四，把硬负例入侵率作为在线监控信号，在生产系统的 retriever 上做 drift 检测。
复现评估
复现评估整体偏积极。基准部分完全开源：COREB v202602 与 v202603 以 JSONL 形式发布在 HuggingFace（livecodebench/code_generation_lite/test5.jsonl、test6.jsonl），corpus、queries、qrels 都对外开放；构建流水线在论文图 2 中逐步骤描述，反事实改写与人工核对协议写在 Appendix A.1 与 A.5。模型部分，C2LLM、F2LLM、Jina-code、Qwen3-Reranker 等基座全是公开权重，GemEmb-2 是闭源 API 但评测协议公开；COREB-RERANKER 作为 LoRA 微调 + uniform model soup 的产物，应可基于相同代码在 $4\times - 8\times$ A100 上复现（3.1M 样本）。算力风险点：11 个 embedding + 4 个 reranker 全跑 top-128 重排成本不低，Go、Ruby 这类长尾语言易反复超时。难度中等偏上：搭好框架就能跑，但要复现 Search 子任务近零现象，最好接上 HyDE / Query2doc 等查询扩展。
论文图表
三张饼图分别为 (a) 按主任务分布（T2C 49%、C2C 45%、C2T 7%）、(b) 按语言约束分布（Any 45%、Python 16%、Java 16%、C++ 14%、Ruby 13%、Go 16%）、(c) 按子任务变体分布（Search 34%、Canonical Retro 34%、Pair Match 26%、Cross-Lingual 10%）
总览性图表，让人一眼看出 COREB 以 T2C 和 C2C 为主、Search 子任务占比最大，这正好对应后面 Search 子任务表现崩坏的核心结论