AI Dev 26 x SF | Ara Khan: Evals Are Broken Use Them Anyway

评估的两大误区：唯数据论与主观感受

演讲者 Ara Khan 的核心观点是，大多数人对于 AI 评估（Evals）的理解是错误的。他指出了两种极端的错误阵营：第一种是“客观指标派”，这类人盲目相信模型实验室发布的基准测试分数，认为数字即真理。然而，分数相近的模型在实际体验中差异巨大。例如，Sonnet 4.6 得分 52，与其他模型分数接近，但实际使用中并不能证明它们同等优秀。这种对分数的迷信导致许多实验室陷入“刷榜游戏”，追求最高分而非模型真实能力，正如 Francis 所指出的，许多新模型发布后令人失望，因为实验室只是在通过评测获取流量和声望，而非提升模型质量。

主观体验派的局限与中间道路

第二种错误阵营是“品味至上派”（Taste is King），他们完全否定数字的意义，认为评估毫无价值，仅凭个人喜好（Vibes）来判断模型好坏。这类用户倾向于将 AI 拟人化，例如表示“我喜欢 Claude，因为她听起来很友好”。Ara Khan 认为这种观点同样不可靠，因为主观感受无法作为工程决策的依据。他主张真理在中间地带：评估既不是万能的，也不是无用的，关键在于正确使用评估的方法。正确的做法是学会构建、解读并在智能体工作流中应用评估，无论是简单的编码助手还是复杂的百万级用户生产工作流，评估都是关键要素。

评估应用的三个层级与启发式规则

为了帮助听众从“错误”走向“正确”，Ara Khan 提出了三个进阶层级：第一层是解读他人评估，即如何理解模型实验室或 Cursor 等公司发布的基准数据；第二层是利用评估优化自有智能体，通过评估反馈改进 Agent 流程；第三层是自建评估体系，这需要充足的时间和资金，适合高阶开发者。他建议遵循启发式规则，而非死板教条。首要规则是不要盲目相信模型实验室的评估结果。尽管这些数字可能准确，但它们只是近似值，并非绝对真理。工程师应运用自己的判断力，将基准测试视为参考而非决策的唯一依据。

"Has any engineer actually made a decision based on a benchmark result?"

这一观点强调了独立判断的重要性，提醒开发者在面对铺天盖地的评测数据时，需保持审慎态度，结合实际情况进行综合评估，而非被数字裹挟。

评估指标的时效性与“尘埃落定”策略

在AI领域，评估指标（Evals）的解读需要保持动态更新，但无需盲目追求最早采用。许多大型公司的工程师往往陷入一种误区，即试图始终掌握“最新最好”的模型。然而，AI的发展速度极快，在AI语境下，两年相当于27年，这种速度使得追逐每一个新发布的模型变得极其消耗精力。以EPO AI图表为例，Soda评分每隔几个月就会发生剧烈变化，模型排名更迭迅速。例如，几个月前Sonnet 4.6或Opus曾被视为最佳模型，但如今这一地位已不再稳固。

"如果你一直玩‘我要始终拥有最好的东西’这个游戏，你花在始终处于领先地位上的心理带宽根本不值得。"

因此，合理的策略是保持关注但不必急于求成。当新模型或新技术出现时，等待几周让“尘埃落定”，再亲自进行测试和评估，是更为明智的做法。对于大多数非全职追踪前沿的研究者而言，保持现状（Stay current）比成为最早采用者（Earliest adopter）更重要。这种策略能避免在瞬息万变的技术浪潮中浪费宝贵的工程资源，转而聚焦于自身问题的实际解决。

评估的针对性：从通用基准到特定问题

评估指标必须与具体问题场景高度相关，通用的基准测试往往缺乏实际参考价值。以Ara Khan在Client工作期间专注于的编码代理（Coding Agents）为例，这类任务需要特定的评估体系，如Terminal Bench、Frontier SWE或其他编码基准。然而，许多模型应用发布时提供的分数往往是通用的、普适性的评估结果，这些结果可能完全不适用于特定的垂直领域，如电商或基础设施公司。

"作为一个问题解决者，你应该始终寻找针对你问题的评估，或者尽可能接近你问题的评估。我认为这是一个更好的衡量标准。"

一个典型的案例是SWE-bench基准测试。该基准曾长期作为编码代理的标准评估标记，但随着模型能力的提升，该基准已被严重饱和（Saturated）。如今，新发布的模型应用甚至不再提及该基准的分数，因为分数已失去区分度。这表明，当评估指标变得过于饱和时，它们就不再适用于解决实际问题。工程师应当警惕那些看似光鲜但与实际工程场景脱节的通用分数，转而构建或采用更贴近真实业务痛点的评估体系。

编码代理评估的工程与哲学挑战

评估编码代理不仅是工程问题，更是哲学问题，核心难点在于AI响应的高方差性和非确定性。AI的回答空间几乎是无限的，如果让代理运行10分钟，每一步都可能走向不同的分支，这使得衡量代理是否真正完成了预期任务变得极其困难。在早期，许多评估指标（如实现斐波那契数列、编写单元测试等）被广泛用于衡量编码能力，但这些大二学生水平的算法题与真实的软件工程经验毫无关联。

"评估很棒，但兄弟，这仅仅是关于‘氛围’（vibes）。"

这种脱节导致许多评估无法反映代理在真实世界中的表现。为了解决这一问题，Client团队决定构建更贴近真实世界软件问题的评估体系。他们发现斯坦福大学AI研究所发布的Terminal Bench提供了极具价值的解决方案。该基准包含89个高度适用的问题，涵盖了数据库问题、竞态条件、前端Bug等真实工程师日常面临的挑战。这些问题的优势在于易于运行、易于复现，并能与Codex、Cloud Code、Client等各种编码代理无缝集成。通过采用这一基准，团队得以在更贴近现实的场景中测试和优化代理性能，从而克服了通用基准失效的困境。

长周期智能体评估与确定性验证

在构建复杂的 AI 智能体（Agent）时，评估过程往往涉及多个步骤的串联，例如使用网络搜索工具、安装 Python 库、访问沙箱环境、读取或编辑文件等。这一完整流程可能需要 5 到 10 分钟，甚至更久。因此，有效的评估必须允许智能体充分运行，涵盖从开始到结束的整个生命周期，而不是仅测试瞬间反应。

"Let it do the whole thing. And then once it's done there are like these deterministic unit tests which check like did I make the file? Does it run? Does it pass the test?"

这种被称为 Agentic Eval 的方法，其核心在于最终的 确定性单元测试。无论智能体运行多久，最终都通过客观的标准来验证结果：文件是否创建成功？代码是否可运行？测试是否通过？以 Terminal Bench 为例，某些复杂问题可能需要智能体连续运行 30 到 45 分钟，期间不断尝试不同策略来解决问题，最终由系统对问题进行评分。这种长时间、多步骤的评估方式，能够真实反映智能体在复杂任务中的实际表现。

关键性能指标与成本效益分析

在进行智能体评估时，追踪关键性能指标至关重要。这些指标包括：回合数（Turns）、工具调用次数（Tool Calls）、Token 使用量以及总运行时间。不同模型在这些指标上表现差异巨大。有些模型虽然性能优异，但推理速度极慢，导致单次运行耗时高达 45 分钟。通过调整参数并在不同模型间对比，团队可以明确界定：什么是真正需要的性能，什么是可接受的延迟，以及愿意为特定质量支付多少成本。

"Sometimes it just makes more sense to use like Deep Seek V4 for Flash, which is like 150th the cost of another model."

现实世界中，并非所有问题都适合使用最昂贵的前沿模型。成本效益是决策的关键因素。例如，使用 DeepSeek V4 等模型可能仅为其他模型的 1/150 的成本。通过评估数据，团队可以清晰地看到哪些任务可以使用低成本模型完成，哪些必须使用高性能模型。这种基于数据的权衡，帮助团队在预算和质量之间找到最佳平衡点，避免无谓的资源浪费。

隔离环境与并行化基础设施

Terminal Bench 使用 Harbor 和 Modal 等基础设施来构建 隔离的容器化环境。每个评估任务都在独立的容器中运行，预先配置好所需的 Python、JavaScript 版本及依赖项。这种隔离机制确保了智能体在启动时拥有完全一致且干净的起点，避免了环境冲突。

"Usually back in the day the way eval would work is that they would run sequentially... problems would run sequentially and they will like interfere with each other's code."

传统的评估方式通常是 顺序执行，导致 89 个任务可能需要 6 到 7 小时才能完成，且任务间容易相互干扰。通过 Harbor 和 Modal 的支持，评估任务可以在不同的容器中 并行运行。这不仅大幅缩短了评估时间，还消除了环境冲突的风险。对于自建评估系统的团队，强烈建议采用类似的容器化隔离策略，以确保评估结果的准确性和可重复性。

错误聚合与迭代优化策略

大规模评估的价值在于揭示 失败模式。当运行 89 个任务时，如果其中 20 个任务出现失败，这些失败往往呈现出明显的聚集性。例如，模型可能在读取文件、编辑文件或安装依赖时陷入 无限循环，反复尝试相同操作却失败。通过评估，团队可以将失败归类为几个主要桶（Bucket），如文件读取失败、推理错误或工具使用不当。

"You're able to figure out like okay, what are the broad buckets in which my successes and failures could be bucketed?"

一旦识别出这些主要失败类别，团队就可以进行 针对性优化。例如，如果发现模型在编辑特定文件时表现不佳，可以改进文件编辑工具；如果浏览器使用效果差，则优化浏览器工具。这种从宏观错误聚合到微观具体问题的迭代过程，使得评估不仅仅是打分，更是 改进智能体和工具链 的核心驱动力。通过持续追踪这些指标，团队能够逐步提升智能体的稳定性和实用性。

评估的三重维度：模型、框架与问题

在构建 AI 代理（Agent）时，评估（Evals）的核心价值在于模拟用户体验，从而精准定位失败原因。Ara Khan 指出，有效的评估必须同时测试三个相互关联的维度：模型本身的能力、代理框架（Harness）的适配性，以及评估问题（Problem）的相关性。仅仅关注模型是不够的，因为即使拥有最先进的模型，如果代理的脚手架编写不当，性能依然会大打折扣。

"You're testing the model... you're testing the harness as well... and then the last thing you're testing is the problem."

以 Anthropic 的新模型为例，它在 Cloud Code 中的表现往往优于 Droid 或 Cursor。这并非因为模型本身在不同环境中发生了本质变化，而是因为不同的代理框架对同一模型的挖掘能力存在差异。如果框架设计不佳，就无法充分发挥模型的潜力。因此，评估的目的不仅是验证模型好坏，更是为了发现框架是否未能公正地展现模型能力，以及所选问题是否真正贴合实际应用场景。只有当模型、框架和问题三者对齐，且开发者保持诚实的自我审视时，评估才具有指导意义。

迭代优化与三大改进阶段

通过迭代式评估，团队能够显著提升代理性能。以 Client 团队为例，他们通过调整 CPU 内存层、增加超时时间以及优化思维链行为，逐步提高了评估分数，最终在 Opus 4.5 等基准测试中超越了 Cloud Code。这一过程揭示了评估优化的三个关键阶段，即“三大改进区域”。

第一阶段是修复明显缺陷。这包括纠正错误的文件读取工具、修复断裂的代理回合（turns）或损坏的检查点机制。这些基础层面的错误会导致代理在根本层面上无法运行。一旦修复这些显而易见的漏洞，代理便能展现出基本功能，这是优化的起点。

第二阶段是哲学层面的深度优化。这是“真正的爬山”过程，涉及提示词工程、工具调用定义、重试逻辑等细微之处。开发者需要反思是否使用了过多或过少的工具，或者工具选择是否错误。通过将代理置于真实问题中解决，开发者可以获得比主观臆断更细腻的 judgment（判断），从而精准定位代理在逻辑和策略上的不足。

第三阶段是危险的“过拟合区”。一旦引入具体指标，开发者容易陷入唯数字论，为了刷高分而过度优化特定任务，添加奇怪的技能或修改提示词以仅通过特定测试。这种做法虽然能提升分数，但会导致代理在实际应用中失效。因此，必须警惕为了指标而牺牲通用性的陷阱。

基准测试与实战案例：超越竞争对手

在实战中，评估不仅是内部优化的工具，更是超越竞争对手的战略手段。Client 团队通过构建定制化的评估体系，不仅优化了自身代理，还深入挖掘了开源模型的潜力。他们发现，通过微调一些竞争对手未优化的“微小旋钮（tiny knobs）”，可以在多个基准测试中取得优势。

虽然字幕中未提供具体的跑分数值表格，但明确提到了以下关键对比和成果：

这一案例证明，建立有效的评估体系是发现开源模型细微优势的关键。如果没有进行严格的评估，团队可能会完全忽略这些极具性价比的开源模型，而仅仅依赖闭源模型。通过持续的评估迭代，团队不仅提升了代理性能，还掌握了开源模型中那些“美丽的细微差别”，从而在成本和性能之间找到了最佳平衡点。

最终建议：指标与直觉的双重验证

Ara Khan 给出的最终建议是：找到适合你的基准，构建评估体系，并进行持续的“爬山”式优化。然而，高分并不等同于成功。在追求评估分数提升的同时，必须始终进行“氛围检查（Vibe Check）”。

"Even if you get a good score you always need to make sure you're passing the vibe check... Is this a sensible agent? Is it making sense?"

这意味着，开发者需要在情感和本能层面确认代理的行为是否合理、是否真正解决了问题。评估是一种必要的纪律，它迫使团队不断测试新模型、改进新体验。Client 团队花费数月时间构建评估体系，并持续应用于新模型和开源模型中。这种以评估为导向的开发流程，不仅帮助他们超越了竞争对手，更让他们深入理解了模型的内在机制，避免了盲目依赖单一模型或框架的风险。评估不是终点，而是确保代理始终“有意义”的持续过程。