技术摘要：Agent Retrieval Bench
问题定义
现代编程智能体（Coding Agents）通常根据是否生成了正确的补丁来进行端到端的评估。然而，补丁生成依赖于上游的上下文获取阶段：智能体必须首先识别并检索出用于推理任务所需的特定仓库文件。作者认为，当前的评估掩盖了这一关键层级。与传统的语义代码搜索（其中相关性由查询-文档相似度定义）不同，**智能体相关性（Agentic Relevance）**是由软件工作流中的“下一步有用步骤”定义的。这种相关性通常是间接的、结构性的或依赖于工作流的（例如，描述实现变更的拉取请求可能需要的是回归测试文件，而非实现文件本身）。
交互式探索允许智能体通过额外的工具调用来补偿初始上下文的不足，但这增加了成本和延迟。此外，日志轨迹显示，即使是交互式智能体，在 27–35% 的案例中也未能触及任何“金标”（Gold/必要）文件。本文提出需要 Agent Retrieval Bench 来隔离并评估这一上游检索问题，并在现实约束下将其与最终的补丁生成结果区分开来。
方法论
基准构建
Agent Retrieval Bench 是一个从 427 个样本中构建的文件级代码检索基准，涵盖 25 个仓库（涉及 Python、Go、Rust、TypeScript、Java 和 JavaScript）。
- 冻结语料库： 所有样本均针对处于基础提交（Base Commit，即解决前状态）时的仓库状态进行评估，以防止来自修复提交或最终补丁的信息泄露。
- 查询来源： 查询源自真实的工作流信号：PR 标题/正文、评审评论、重现的失败追踪以及锚定编辑（Anchored Edits）。
- 泄露控制： 数据集严格剔除了致命的捷径，包括精确的金标路径、原始差异（Raw Diffs）、修复提交哈希以及模型生成的评审产物。
任务定义
该基准定义了五种不同的检索场景：
- code2test (106 个样本)： 给定一个 PR 或实现变更，检索相关的测试文件。
- comment2context (80 个样本)： 给定一个评审评论及被评审的文件，检索满足该评论所需的额外上下文文件。
- trace2code (101 个样本)： 给定一个重现的失败命令及其输出，检索根因源文件（测试文件仅为辅助，而非金标）。
- edit2ripple (58 个样本)： 给定一个锚定编辑及变更意图，检索受该变更影响的其他文件（涟漪文件）。
- 选择性检索 (Selective Retrieval) (82 个样本)：
- 自然无金标 (Natural No-Gold) (50)： 问题的解决位于仓库之外（例如，上游依赖项）。
- 反事实控制 (Counterfactual Controls) (32)： 查询配对了一个不包含答案的仓库。
评估指标
- 排序指标： Recall@k (5, 10, 20)，平均倒数排名 (MRR)。
- 上下文预算指标： 预算上下文收益 (BCY@B)，衡量在经过排序和贪婪打包后，固定 Token 预算（如 8k tokens）内能容纳多少标记的金标上下文。
- 选择性指标： 用于弃权任务的平衡准确率和选择性成功率。
- 轨迹分析： 分析记录的智能体轨迹中的“触达金标率”（Gold-touch rates）、首次命中步骤以及潜在探索节省 (PES)。
- 种子干预 (Seed Intervention)： 一个受控试点实验（45 个样本），其中智能体被赋予不同的初始上下文（随机、词法、嵌入、混合、Oracle），以衡量上下文获取效率的影响。
核心贡献
- 形式化智能体相关性： 本文将智能体相关性定义为“下一个所需的仓库上下文”，而非语义相似度，并通过四个正向任务和选择性弃权进行了操作化定义。
- 受控泄露的数据集： 一个经过验证的、包含 427 个样本的集合，具有严格的模式检查、零致命捷径泄露，以及基于工作流产物的证据支撑的金标标签。
- 面向智能体的评估套件： 一个综合套件，包括排序文件指标、Token 预算 BCY 曲线、选择性弃权以及受控输入种子干预试点。
- 关于检索家族的实证发现： 证明了没有任何单一的检索家族能在所有工作流信号或上下文预算下占据主导地位。
结果
基线性能
基准评估了词法（BM25、路径感知词法）、无向量结构化（RepoMap）以及基于嵌入的方法（Qwen3-4B, Qwen3-8B, Jina, Nomic, pplx）。
- 整体领先者： Qwen3-Embedding-4B 实现了最佳的样本加权 MRR (0.2379)，而 Qwen3-Embedding-8B 实现了最佳的 Recall@20 (0.7029)。RepoMap 在 BCY@8k 方面领先 (0.3788)。
- 任务特定胜出者： 性能随任务变化剧烈。
- trace2code： RepoMap 显著优于嵌入方法（MRR 为 0.2742，而 Qwen3-4B 为 0.0827），表明对于从失败追踪进行根因定位，结构邻近性至关重要。
- edit2ripple： 观察到了随预算变化的逆转现象；Qwen3-4B 在 4k tokens 时领先，而 Qwen3-8B 在 8k tokens 时领先。
- 混合方法： 对 Qwen3-8B 和 RepoMap 进行简单的倒数排名融合 (RRF) 后，整体 MRR 提升至 0.2713，Recall@20 提升至 0.7331，证实了语义信号与结构信号的互补性。
选择性检索与弃权
- 校准差距： 虽然原始检索分数可以区分反事实的错误仓库控制，但它们无法提高自然无金标案例的选择性成功率。使平衡准确率最大化的阈值往往会拒绝过多的正样本，这表明当前的评分不足以区分合理的局部问题与真正的外部解决问题。
智能体轨迹与种子干预
- 缺失率： 即使在交互式探索下，记录的智能体在 OpenAI 样本中未能触及任何金标文件的比例为 35.2%，在 Codex 样本中为 27–29%。
- 种子效率： 在闭环工具种子干预中，基于检索生成的种子（词法、RRF）与随机非金标种子相比，实现了更高的 File F1 以及更早的金标接触，且使用了更少的后续工具调用和 Token。
- Oracle 上限： Oracle 金标上下文比无种子基线提高了 0.3115 的 File F1，这表明即使提供了正确的代码文件，定位能力仍有巨大的提升空间。
粒度敏感性
- 文件 vs. 跨度 (Span)： 虽然文件级检索是主要指标，但论文指出金标文件很大（中位数 515 行），且标记的证据通常仅占文件的 ~4.7%。文件级命中并不保证精确的文件内定位，且所有方法的行级 F1 分数仍然较低。
重要性与主张
论文声称 Agent Retrieval Bench 为编程智能体的上下文获取层提供了一套统一的评估语义和卫生标准。其主要意义在于：
- 隔离上游失败： 它证明了可以在检索阶段诊断补丁失败，从而将其与推理或编辑能力区分开来。
- 挑战“一刀切”： 结果表明，语义嵌入、词法匹配和结构图是互补的，而非可互换的。单一检索器无法在所有工作流信号下都占据主导。
- 混合必要性： 本文得出结论，有效的编程智能体检索必须是混合型且任务感知的，需结合语义向量、词法/路径信号以及仓库图谱。
- 诊断效用： 该基准作为一个诊断工具，用于衡量上下文获取效率 (CAE) 并识别选择性检索中的校准差距，而非直接声称预测端到端的补丁成功。
作者明确表示，他们并不声称检索是导致补丁失败的唯一原因，也不认为 File F1 可以替代通过测试的修复。相反，该基准确立了上下文获取是一个可衡量的、独特的失败面及成本中心，存在于智能体工作流之中。