Ara Khan：评估已失效仍然要使用它们
Ara Khan：评估已失效仍然要使用它们
核心冲突：客观指标 vs. 直觉感受
AI 开发在评估（evals）方面常常被错误地划分为两个阵营：客观指标阵营，它们把基准分数（如 ELO 或 SweetBench）视为理所当然；以及直觉/氛围阵营，它们完全抛弃数字，依赖主观感受。
这两种做法都不够。客观基准可以被实验室“刷分”，在没有提升实际效用的情况下获得高分；而仅凭“氛围”则难以实现系统性的改进。有效的路径在于两者之间的折中：把评估当作绝对真理的同时，也把它们视为迭代开发的关键启发式工具。
解读外部评估的启发式方法
在评估模型实验室或其他公司提供的基准时，开发者应采用以下三条主要启发式，以免被营销数字误导：
1. 将实验室评估视为近似值
不要把模型实验室（例如 GPT 或 Claude 发布时）的数字当作“神的旨意”。虽然它们通常是相当不错的近似，但应带有辨别性地使用，而不是作为优越性的决定性证明。
2. 稳定性优先于抢先采用
在快速变化的 AI 领域，“最佳”模型每隔几个月就会更换。试图在模型一发布就立刻切换到最前沿的模型会消耗过多的认知资源。推荐的做法是让新模型的热度平息几周后，再将其集成到生产工作流中。
3. 寻找针对特定问题的基准
通用基准往往无法反映真实世界的效用。例如，SWE‑bench 曾是编码代理的标准基准，但最终出现了“饱和”现象——模型得分过高，以至于基准已无法区分质量层次。开发者应寻找与自身问题域（如购物、基础设施或特定编码任务）高度吻合的评估。
为编码代理实现代理式评估
评估代理与评估单轮 LLM 响应根本不同。因为代理可以进行多轮交互、使用各种工具并走不同的路径，其答案空间实际上是无限的。
向真实任务的转变
早期的许多评估聚焦于琐碎的学术问题，例如实现斐波那契数列。这类评估并不能转化为专业软件工程实践。为了解决这一问题，Cline 团队采用了 Terminal Bench（由斯坦福 ALOT Institute 开发），其中包含 89 项真实的软件工程任务，涉及数据库问题、竞争条件以及前端 bug 等。
代理式评估流程
与确定性测试不同，代理式评估允许代理运行较长时间（有时 30‑45 分钟），期间可以进行网页搜索、安装库、编辑文件等操作。成功与否通过 确定性单元测试 来衡量，即检查最终输出是否能够运行并通过所需的测试。
需要跟踪的关键指标
为了在质量与成本之间取得平衡，开发者应关注：
- 回合数：代理进行的迭代次数。
- 工具调用次数：调用的工具数量。
- Token 使用量：本次运行的总成本。
- 执行时间：运行的总墙钟时间。
构建可靠的评估基础设施
要高效运行评估并避免任务之间的相互干扰，隔离是必须的。
- 容器化：每个评估任务应在独立的容器中运行，拥有各自的依赖和环境。这可以防止一个任务破坏另一个任务的环境。
- 并行化：顺序运行评估可能需要数小时。使用 Modal 等基础设施实现并行化、容器化的环境，可显著缩短反馈循环时间。
迭代改进循环
评估让开发者从哲学式的猜测转向工程实现。通过分析“失败的投资组合分配”，开发者可以将错误归类为几个大类（例如“读取文件失败”“推理错误”“安装循环”等）。
三个改进区块
- 区块 1：显而易见的缺陷。修复根本性错误，如
read_file工具损坏或检查点失效，使代理能够正常工作。 - 区块 2：爬坡优化。这是主要的优化区域。开发者通过改进提示工程、调整工具定义、优化重试逻辑等方式，提升代理解决问题的整体思路。
- 区块 3：危险区。过度拟合的风险。开发者必须避免仅为提升基准分数而加入特定 hack，这会削弱模型的通用性能。
三方对齐
成功的代理表现需要三者之间的对齐：
- 模型：底层 LLM 的能力。
- 框架：代理的脚手架和工具实现。
- 问题：实际要解决的任务。
即使模型再强大，如果框架写得糟糕也会失败。迭代评估帮助判断是模型智能不足还是代理框架存在缺陷。
摘要： Ara Khan 解释了 AI 代理开发者为何应超越“氛围感受”，即使评估本身有缺陷，也要使用结构化评估来迭代提升代理性能和工具可靠性。
标题： Ara Khan：评估已失效仍然要使用它们