在 Databricks 数百万行代码库上评估编码智能体

# 在Databricks百万行代码库上对编码代理进行基准测试 来源：https://www.databricks.com/blog/benchmarking-coding-agents-databricks-multi-million-line-codebase 在Databricks，随着我们大力采用AI进行工程开发，软件构建方式正在迅速改变。过去一年间，用于代码编写的模型和工具框架迅速增多，给了开发者前所未有的选择。面对更多选项，了解哪些编码代理在实际编码任务中表现最佳，以及任务性能如何随价格变化，变得愈发重要。 本文分享了Databricks内部构建的编码基准测试的方法与结果，该测试基于我们的工程师在Databricks代码库中实际执行的编码任务来评估工具。这些任务涉及对拥有数百万行代码的代码库进行编辑，涵盖多种流行语言（Python、Go、TypeScript、Scala等），并且任务和解决方案都经过仔细审查以确保准确性。这并非旨在全面覆盖，但该练习揭示的洞见已显著提升了我们工程团队使用编码代理的效率。下面展示了不同模型和工具框架在该基准测试中的总体得分： 我们的基准测试：成本 vs. 性能 **图1：我们的基准测试：成本 vs. 性能** 我们分析的主要结论如下： 1. 编码任务的帕累托前沿（即给定成本下的最佳质量）涵盖来自OpenAI、Anthropic**以及**开源模型的成果。这意味着目前只有混合使用多种工具才能达到前沿性能。 2. 开源模型，特别是GLM 5.2，现在已能处理最高难度的任务。 3. 模型的令牌价格并不能很好地反映端到端任务的实际成本。较大的模型可能具有更高的令牌效率，从而降低总体成本。 4. 模型被调用的工具框架对成本和质量影响巨大。在许多情况下，像Pi这样的简单工具框架在我们工作负载中表现最佳。 让我们深入探讨每一点。 ### 模型大致分为几个“能力层级” 具体结果相差几个百分点在实际任务中往往会相互抵消。我们更关注那些能帮助我们判断不同任务该使用哪些模型的主题模式。事实上，结果显示模型和工具框架清晰地分为三个能力层级。 模型的能力层级 **图2：我们的总体结果中出现了三个不同的能力层级，每个层级内哪些模型有效存在细微差别** 在性能的顶端，我们看到最智能的模型在解决各类问题时非常有效，但它们非常昂贵。中低智能模型在处理常见任务时仍然非常高效，而且在许多情况下成本也显著更低。 在日常工作中，工程师会做许多复杂性差异很大的事情：翻转标志或更新配置等常见运维任务不需要极其智能的模型，但更深入的设计探索则需要。然而，过去我们的默认模型总是最昂贵的那些。基于这项分析，我们决定应将更多工作推向Haiku和GPT 5.4 Mini这类模型。 ### 开源模型已可用于编码任务 GLM 5.2备受关注，我们的结果显示GLM可以成为许多开发者的日常驱动模型。它处于顶级能力层级，在质量上与Opus 4.8统计上不相上下，但每任务成本为1.28美元，而Opus为1.94美元。 GLM的质量得分与我们内部开发者的定性反馈一致，他们一直在试用GLM进行日常开发。由于GLM在日常编码任务中的出色表现，我们一直致力于以最佳性能提供GLM服务(https://x.com/Yuchenj_UW/status/2070166719839326396)，并且证据表明，是时候开始将这些模型部署为编码日常驱动了。 ### 每任务价格 vs. 每令牌价格 开发者通常通过查看令牌成本来判断一个模型在完成编码任务时的昂贵程度。然而，我们发现，由于模型之间推理效率的差异，令牌成本往往不能很好地反映总体任务成本。这突显了进行任务级别基准测试的必要性，因为任务形态和复杂性在不同上下文中可能有所不同。 例如，Sonnet 5每个令牌的成本比Opus 4.8便宜约1.7倍，但在我们的任务中，我们发现Sonnet每任务成本为2.09美元，而Opus为1.94美元，同时任务完成得分低了6个百分点（81% vs 87%）。这主要是因为Sonnet 5工作得更久、读取了更多内容才完成，消耗了1.9倍的令牌。 ### 工具框架对效率有重大影响 当我们通过两个不同的工具框架（Claude Code/Codex vs Pi）运行相同的模型并使用相同的思考力度时，我们观察到每任务成本差异显著（某些情况下超过2倍），而质量保持不变。主要区别在于每个轮次中每个工具框架向模型提供了多少上下文。 工具框架对效率的影响 Pi每个轮次发送的上下文大约少了3倍。它更好地管理了上下文，保持了更紧凑的工作集，并以更少的运行次数完成任务。每任务重新输入给模型的上下文总量 这里的教训不是某个工具框架总是更便宜，也不是原生工具框架更差。相反，模型选择只是拼图的一部分。建立这种灵活性正是我们投资Omnigent (https://omnigent.ai/)的原因，以实现模型和工具框架的无缝切换。 ## 为什么构建自己的基准测试？ 像SWE-Bench和TerminalBench这样的公共基准测试很有用，但它们无法回答我们遇到的问题。原因如下： - 任务都是公开的，因此解决方案会随时间泄露到训练数据中。 - 我们发现结果对我们的代码库没有代表性，该代码库跨越10多种语言，以及许多用Scala、Go、Rust、Java和Python、Bazel、Protobuf等编写的服务。 通过基于我们自己的PR构建基准测试，我们可以更有信心地做出这些决策，而不会因为推出优化而阻碍我们的开发者。 ## 我们如何构建基准测试 我们使用Unity AI Gateway (https://www.databricks.com/product/artificial-intelligence/unity-ai-gateway)来捕获所有编码交互的日志，这使我们能够分析工程师使用编码代理处理的任务的复杂性。任务复杂性差异很大，大约四分之一被标记为低复杂性工作，约60%为中等复杂性。 我们的工程师实际要求编码代理执行的任务 然而，昂贵的模型是工程师使用的默认模型，因此在提高效率方面显然存在巨大机会。 ### 任务构建 我们的工程师每天合并数千个代码变更，因此我们已有很好的数据集来构建。一个好的PR是一个丰富的产物，包含显示开发者迭代的提交、人类审查以及有助于验证代码变更是否符合意图的测试。然而，我们需要多项质量检查和过滤来构建高质量基准测试： - **时效性：**我们从近期历史中提取，以便任务反映我们当前构建的方式，包括当前使用的框架、模式和约定。 - **人工编写：**过滤掉了机器人提交、服务账户、完全AI生成的变更以及自动生成的变更。 - **关联的高质量测试套件：**我们筛选了包含用于验证代码变更的高质量测试的PR。 - **自包含：**变更局限于少数几个模块。 - **代表典型任务：**我们选择了分布在整个技术栈中各类任务的PR：Scala后端服务、Rust系统代码、React和TypeScript前端、protobuf和gRPC合约以及Bazel配置。 任务构建分步计划 一旦有了候选PR，我们通过以下方式专注于构建规范化的任务： 1. **获取意图并将其总结为提示。**我们阅读PR以了解它实际的目的，然后描述我们想要的结果。通常，这意味着重写PR描述，陈述问题或目标，命名任何约束，并删除解决方案的描述。例如，重要的是删除关于*为什么*某个bug修复是正确的解释，因为这会使任务过于简单。 2. **分离相关测试。**非测试文件是模型必须自行复现的变更，因此我们将测试文件放在一边，并确保可以编译它们。我们的构建系统已经能够确定哪些测试依赖于原始PR中修改过的文件，因此我们完整地运行了所有这些测试目标。 这个过程的成果就是基准测试中的一个任务。下面是一个简化示例： 虽然我们使用了脚本和AI来生成候选任务，但我们手动评估了*每个样本*。在某些情况下，我们发现原始PR中的测试需要重写以允许替代实现或使其更严格，这些工作我们是手动完成的（不使用AI）。同样，我们还发现一些情况需要改进任务描述以使其规范化。 测试套件的前后对比 **图3：我们的测试套件的前后对比：之前的测试锚定在验证精确字符串匹配上，这导致模型尝试解决任务时出现一些失败。这不是测试非确定性输出的好方法，因此被重写为对行为进行评分。** 我们使用编码代理工具框架和模型的标准开箱即用设置进行实例化，所有Databricks工程师拥有的常见工具都可用。 设置和审查过程 当代理明确表示已完成任务时，我们对该代码进行快照，应用被保留的测试，并评估测试以确定该任务对于该模型+工具框架组合是否为“通过”。我们*没有*使用LLM评判器来评估正确性，因为我们发现这奖励听起来正确而不是实际正确。 ### 额外防护措施 额外防护措施 在早期实验中，一些模型的得分好得令人难以置信，因此我们手动检查了这些代理轨迹以了解发生了什么。我们发现，由于我们最初的设置，“正确”的实现仍然可以在工作树的Git历史中恢复！每个任务都源自一个已合并的提交，因此没有什么能阻止一个拥有shell的代理沿着Git历史向前找到它。为了解决这个问题，我们封住了Git历史：在每次运行期间，我们将工作副本与仓库完全隔离。 ## 下一步是什么？ 我们从简单的问题开始：我们能否更高效地使用编码代理？答案是肯定的，而且通过数据驱动，我们可以开始构建自动选择正确模型并追踪效率的能力。 任何公司都可以做到这一点。任何拥有已合并PR积压的团队都已经拥有了一个基准测试，没有模型在其上训练过，并由你的团队编写的测试进行评分。我们正在积极添加更多任务（尤其是更困难的），并计划让每个新的代理/工具框架通过它运行，从而对我们的选择更有信心。 在Databricks，我们一直警惕锁定——不仅是对供应商的锁定，还包括那些会让团队随着时间的推移失去灵活性的假设。同样的直觉塑造了我们早期对开放格式和标准的押注 (https://www.databricks.com/blog/what-open-lakehouse-open-data-standards-explained)，也塑造了我们现在处理AI的方式：衡量在我们发布的代码上实际有效的东西，给工程师在模型之间移动 (https://www.databricks.com/blog/ai-gateway-governance-layer-agentic-ai) 和工具框架之间移动 (https://www.databricks.com/blog/introducing-omnigent-meta-harness-combine-control-and-share-your-agents) 的空间，并配备一致的防护措施，以及进行优化以有效使用AI。 在后续博客中，我们将进一步讨论如何使用Unity AI Gateway (https://www.databricks.com/product/artificial-intelligence/unity-ai-gateway) 和 Omnigent (https://omnigent.ai/) 中的智能路由功能，帮助我们的开发者在保持高效的同时使用最智能的代理。