代码检索不只要“像”：ExecRetrieval揭示嵌入模型的功能正确性缺口

导语

代码检索系统通常被评价为“能否找到相关代码”，但对编码代理和代码RAG而言，相关只是起点。真正影响后续生成、补全与执行的，是检索结果是否能够完成目标功能。论文《ExecRetrieval: Measuring the Functional-Correctness Gap in Code-Embedding Retrieval》提出了一个更具挑战性的测试：当正确代码和只改动一处、外观几乎相同但执行结果错误的代码同时出现在候选池中，嵌入模型能否把正确实现排在前面？

核心要点

• 把“反事实代码”放进搜索池。 ExecRetrieval包含939个Python任务。每个任务都有一个经过执行验证的标准实现，并配有最多四个错误干扰项。干扰项由机械化的单点变异生成，再通过执行验证确认其确实错误。
• 评价重点从相关性转向功能区分。 这种构造避免了只依赖词汇重合、主题匹配或代码身份的测量方式，直接观察检索器能否区分功能正确与近克隆错误实现。
• 召回可以很好，首位排序却不够可靠。 研究测试了23种稠密嵌入配置以及BM25。表现最好的托管系统在exec@10上达到1.00，但exec@1仅为0.331，说明扩大候选范围后可以找到正确代码，却未必能把它放在第一位。
• 错误并非偶然的远距离误召回。 四个领先系统的首位失误中，有91.5%至99.4%来自该查询对应的近克隆错误变体；在67%至78%的任务中，标准实现的得分低于至少一个配对干扰项。

这意味着什么

结果揭示了代码嵌入检索中的“功能正确性缺口”：模型能够捕捉代码的主题、结构和表面语义，却不一定能够判断一个细微改动是否破坏了实际行为。对于代码代理而言，这种错误尤其危险，因为排序第一的结果往往会被直接放入上下文，甚至成为后续生成的主要依据。仅提高向量相似度或扩大top-k，并不能自动解决首位结果错误的问题。

ExecRetrieval的价值还在于提供了可控的评估框架。未来系统可以在检索后增加执行验证、测试驱动重排或专门的功能判别器，并使用这类近克隆反事实样本检验改进是否真正有效。与此同时，exec@1与exec@10之间的差距也提醒开发者：评测代码检索时，不能只报告“正确答案是否出现在候选集合”，还应关注它是否位于最优先的位置。

该工作已被EMNLP 2026主会接收。它并没有宣称某一种嵌入方案已经解决问题，而是把一个长期被相关性指标掩盖的工程难题明确地测量出来：代码检索的终点不是找到相似代码，而是优先找到能工作的代码。

来源：Hugging Face Daily Papers