OpenAI 负责 Evals 的 Alec Barber 闭门分享的中文记录，信息密度罕见地高：为什么通用 eval 平台注定卡在「测试用例原语」上、哪三种情况可以用平台，以及熵检测、置信度路由、测试集卫生等一批可以明天就用的实操方法。
正在纠结「买 eval 平台还是自建」的团队必读；熵检测和回归/迭代双集机制适合所有已经在跑 eval 的人立刻采用。配合 a07（搭建教程）与 a04（Grader 校准）阅读。
先合上原文在心里作答，再点开对照。全对 = 本篇真正通关。
测试用例的基础抽象无法通用：单轮、多智能体、决策树架构的测试原语互不兼容，只有深度理解自己系统的人才能定义，因此 eval 逻辑无法外包给通用平台。
同一测试用例对同一模型跑 10 次：全通过或全失败 = 低熵、信号清晰；5 过 5 挂 = 高熵，说明 grader 定义不清或用例本身有歧义。用它先校准评测标准，再去优化模型。
迭代集小而聚焦，针对当前正在修复的失败模式；问题修复后把用例迁移进回归集。回归集宽而稳、每次变更必跑，并要定期清理被新模型「满分刷穿」的老用例。
上方为本站原创导读，下方为原文完整收录，便于对照阅读。
上周，Akash Bajwa（EarlybirdVC 投资人）组织了一场关于 Evals 的小型闭门讨论，邀请了 OpenAI 的 Alec Barber 作为主讲嘉宾。Alec 在 OpenAI 负责 Evals 相关工作，这场讨论也是去年夏天跟 @wulfiebain 合作举办的上一场 eval 沙龙的延续。
我读完这篇记录之后停了一会儿。
不是因为内容有多深奥，而是因为它说得太直了——直到有点扎人。很多 AI 团队花了真金白银去买各种 eval 平台，认真地接 API、配置 dashboard、跑测试集……然后 OpenAI 专门研究这件事的人来告诉你：你们大多数情况下应该自己造。
Alec 的核心观点是：Codex 和 Claude Code 现在已经强大到你完全可以自己构建 eval 支架，让它和你的 AI 外壳紧密耦合，而不是去采购一个通用的 eval 平台。
通用 eval 平台的核心问题，在他看来不是功能不够，而是它试图解决一个不该被通用化的问题。
这个说法听起来很强硬。很容易有人反驳说"我的场景不复杂，用现成的不行吗"。Alec 的回答是：你可以用，但你大概率会遇到同一道坎——所有平台都卡在那里的那道坎。
Alec 说，他接触过的每一个 eval 平台，都在同一个地方遇到了困难：定义"测试用例"这件事本身。
一个平台要能通用，就必须有一个基础的"测试用例"抽象，让所有场景都能套进去。问题是，什么叫"测试用例"？稍微往下想一层：
对于单轮对话应用，一个测试用例可能是"一条输入 + 期望输出"。对于多智能体系统，一个测试用例可能是十几个 agent 之间的交互轨迹。对于决策树型系统（比如保险定价），一个测试用例可能是某个条件下的分支路径加上最终判断。
这三种情况对"测试用例"的定义完全不兼容。你要设计一个能同时兼容所有情况的抽象，基本是不可能的。
Alec 的前一家创业公司就在这上面翻车了。他们围绕单轮对话设计了整套 schema，逻辑清晰、代码干净。结果用户上来第一个需求就是多智能体场景，抽象完全撑不住。
这不是实现问题，是根本假设就错了。
再举一个具体的例子。一家做保险的公司，他们的 AI 系统是这样工作的：文件进去，系统做 20 次复杂调用，中间还混有正则表达式匹配和确定性逻辑，最后给出一个定价判断。整个系统才是"外壳"，而模型的推理只是其中一个实现细节。你要评测这个系统，"测试用例"到底是什么？是一次最终的定价判断？还是 20 个中间步骤里的某一个？还是整条轨迹？通用 eval 平台没有办法回答这个问题，因为答案只有做这个系统的人才知道。
「没有一个通用的基础类型能横跨所有 AI 架构。每个架构都需要自己的测试原语，而这个原语只有深度理解你的系统的人才能定义出来。」
—— Alec Barber，OpenAI
Alec 不是说所有外部工具都没价值。他说了几种他认为值得用的情况。
可观测性工具可以放心用。 Langfuse 这类工具做的是通用监控，不试图帮你定义 eval 逻辑，所以没有 primitives problem。就像他说的：不要去重新造 Grafana。
高度垂直的平台可能有价值。 比如专门服务编程 Agent 的 eval 平台——这个领域的"测试用例"边界相对清晰，primitives problem 被限定在一个小范围内，平台有机会真正做好。
能端到端闭环的系统是例外。 如果一个平台能真正把数据收集、标注、评测、反馈全打通，那值得认真考虑。但 Alec 说他还没见过真正做到这一点的产品。
通用平台的困境是结构性的：它们必须面向"大多数人"设计，但 eval 是一件极度依赖上下文的事。你的 eval 支架应该和你的 AI 外壳共享同一套数据模型、同一套测试边界——这种耦合程度，外部平台没办法给你。
Alec 反复强调的另一个点：从设计 AI 外壳的第一天起，就把可测试性作为一等目标来考虑。
很多团队的路径是这样的：先快速搭一个能跑的版本，几个月后发现问题越来越多，想引入 eval，结果发现整个系统是个黑盒——模型进、结果出，中间发生了什么根本看不到。到这个阶段再改，要拆开很多东西，代价很高。
他的建议是把 AI 外壳设计成可分解的（每个模块可以独立测试）、可检视的（每一步的中间状态可以观察到）、可做单元测试的（每个函数或 agent 的行为可以单独验证）。这不是新概念，就是软件工程里最老的那些原则，只是很多人在构建 AI 系统时忘了用。
关于用什么工具搭 eval，他有个很务实的建议：去找 Hamel Husain 写的 eval 教程和最佳实践，把这些内容作为上下文喂给 Codex 或 Claude Code，让 Agent 来帮你搭一套定制化的 eval 支架。
用写代码的工具帮你写测试框架本身。eval 的代码量不少，这是 AI 编程工具最擅长的那类重复性、结构性工作。
这是整场讨论里我觉得最立竿见影、最容易被拿去直接用的一个方法。
把同一个测试用例对同一个模型跑 10 次。
如果 10 次全通过，或者 10 次全失败——低熵，信号清晰，这个测试用例有价值。如果结果是 5 通过 5 失败——高熵，信号模糊，说明 grader 定义不清，或者测试用例本身有歧义。
代价是每个用例成本增加 10 倍。但它帮你做到的是：在你花时间优化模型之前，先确认你的评测标准本身是可信的。
很多团队在一个 eval 集上反复迭代，model 表现上上下下，但没有人问过：我们的 grader 有多稳定？如果 grader 本身有 30% 的随机性，那你在模型上做的优化，有一部分可能只是在拟合 grader 的噪声。
你不需要对所有用例都跑 10 次——重点用在那些新加的、反复产生争议的、你不确定的测试用例上。花一点额外成本来校准测试集，往往比多跑 100 次普通测试更有价值。
现场一个参与者分享了他们在垂直 AI 产品里用到的做法：利用 OpenAI Responses API 返回的 token 级别概率，来计算一个启发式置信度分数。
逻辑很直接：模型在生成每个 token 时都会输出对应的概率分布。当模型对某个输出很确定，top token 的概率会很高；当模型在几个可能性之间摇摆，概率分布会更均匀，也就是"不确定"。
置信度高的输出直接放行；置信度低的自动路由到人工标注员，让他们当场修正，修正后的数据进入训练集。这条置信度-表现曲线经过了统计验证，是真实的信号，不是噪声。
背后的哲学是：不是让人工审查所有输出，而是让机器找出"最值得人工看"的那 5%，把人类的精力集中在边界案例上。这和做软件测试的思路一样——你不需要测所有路径，你要测最容易出问题的那些。
Alec 建议维护两套测试集，分工明确：
| 测试集 | 特征 | 用途 |
|---|---|---|
| 回归集 | 稳定，覆盖面宽 | 每次变更都要跑，防止已解决问题复发 |
| 迭代集 | 小，高度聚焦 | 专门针对当前正在修复的失败模式 |
修复了一个问题，就把对应的用例从迭代集迁移到回归集。这样回归集会随时间不断丰富，覆盖越来越多的历史失败模式。
但有一点很多人会忽视：要定期清理回归集。
每当一个新的更强大的模型上线，很多测试用例会变得"太简单"——模型轻松满分，完全不产生任何诊断价值。这些用例留在集合里，只是在浪费计算资源，还会让你以为自己的测试覆盖率比实际更高。
精简测试集和精简代码同等重要。一个臃肿的测试集就像充满过时代码的代码库：表面上工程质量不错，但你不知道哪些东西还是有效的。
聊到 benchmark，Alec 提到了一个让大家都有点苦笑的困境。
SWE-bench 这类 benchmark 是二元的：解决了，或者没解决。这种设计有个结构性问题：它把"做对了 80%"和"完全没做"放在了同一个格子里。对于复杂任务，中间的部分完成度可能非常重要——它既是模型能力的体现，也是找改进方向的线索。
一种解法是把 LLM 本身当评判者（LLM-as-judge）：对执行轨迹的每一步打分，然后汇总，再和最终结果做相关性分析。你能看到"这个模型在哪个步骤掉链子"，而不只是"这道题通过了吗"。
还有一个更实际的问题：benchmark 饱和。你可能花几个月设计一套精心的评测集，结果新模型上线几周后就被满分了。背后可能是真实能力提升（好事），也可能是训练数据污染，或者模型学会了在这个 benchmark 上投机。
Alec 提到了一个经济学类比：也许 eval 未来会变成一门解读学科，需要有大量看数据经验的人来做有理有据的判断，而不只是报告一个数字。三个高质量的 benchmark 可能比跑 20000 个平庸测试用例更有意义。不是覆盖率更高就更好。
他还提到了一个有意思的观察：SWE-bench 的分数和很多其他领域的表现有很强的相关性。既然如此，为什么还要跑那么多不同的 benchmark？可能大部分时候，几个精心挑选的测试集就能抓住你真正需要知道的信号，其余的都是重复劳动。
在特定领域（法律、航空、保险）构建高质量的 eval，你需要一个同时具备三种能力的人：能搭基础设施的软件工程师、知道什么叫好输出的领域专家、以及能设计出让专家愿意用的界面的产品/设计思维者。这三种能力同时出现在一个人身上，非常少见。
更难的是，即使你找到了愿意配合的领域专家，他们往往也说不清楚自己的判断依据。现场一个做垂直法律 AI 的参与者分享了他的遭遇：律师不断说"这个不对"，但说不清楚哪里不对。你问"哪里不对"，他说"感觉就是不对"。没有结构化的反馈，就没法做数据，没法做数据就没法改模型。
他的解法是：用 vibe coding 快速搭了一个 UI，做成律师已经熟悉的样子——把界面做成看合同的格式，让律师直接在文件里高亮"对的段落"和"错的段落"，就像在 Word 里批注一样。不用学新工具，不用理解什么是 eval，只需要做他们本来就在做的事。
结果？律师真的开始认真标了。那些原本只能说"感觉不对"的人，开始能给出可用的结构化反馈。
Alec 听完直接认可：这是正确答案。专家评测界面不应该是通用工具，它应该看起来像专家每天工作用的东西。你是在降低他们参与的门槛，而不是让他们适应你的技术栈。这是一个设计问题，和工程问题同等重要。
讨论里有人提到，很多企业仍然在靠"感觉"做 eval 决策——没有系统化的流程，全凭经验和直觉。
Alec 的分析是搭建成本和收益的权衡。在低风险场景下，搭一套完整的 eval 体系需要时间和人力，而收益不够明显，靠直觉凑合在这种情况下是理性选择。但在监管严格的行业，这笔账算起来完全不同——一个保险定价判断错了是百万级赔付，一份法律文件起草有误可能是漫长诉讼。
还有一个更有意思的角度：在金融、医疗、保险这些领域，合规部门正在倒逼 eval 的落地。不是"我们认为 eval 是好习惯"，而是"监管要求我们必须有可审计的模型决策记录"。eval 记录变成了合规文件，而不只是工程工具。
在那些内部最难推动 eval 文化的地方，外部监管正在帮忙强制推行。这很反直觉，但确实在发生。
我把这场讨论的笔记又看了一遍，试图找到一个核心。
我觉得 Alec 想说的，不只是"自己造 eval 支架"这个技术建议。底下那层意思是：eval 是你对自己系统的理解的外化，而理解这件事无法外包。
你可以外包代码，可以外包测试执行，甚至可以外包打分。但"这个测试用例测的是什么、这个评分标准意味着什么、这个失败模式应该怎么分类"——这些判断是没有办法让一个不了解你业务的工具自动完成的。
这让我想起另一件事。过去几年，有很多工具试图通用化"产品分析"——给你一套 dashboard，几个预设指标，宣称能帮你理解用户。结果大家发现，最有价值的分析往往来自自己写的 SQL，因为只有你自己知道你在找什么。
eval 大概也是同一回事。
我不是说去完全忽视外部工具。Langfuse 很好，Hamel Husain 的教程很好，Claude Code 帮你搭支架也很好。但把"做 eval"这件事的核心逻辑交给外部平台，等于把你理解自己系统的那部分能力外包出去了。
这件事的账单，最终要你自己来买单。
如果说这场讨论有一个给我留下最深印象的细节，是那个律师标注的故事。不是因为它技术上多高明，而是因为它说了一件很朴素的事：人在熟悉的环境里才能给出真实的判断。你把他们放到一个陌生的框架里，他们的反馈就会失真。让他们在自己的世界里工作，反馈就会是真实的。
这不只是一个 eval 的道理。我不知道这对不对。但我觉得，凡是需要提取人类判断的地方，大概都适用这条原则。
数据来源：Akash Bajwa (@AkashBajwa96)，X Article，2026年4月27日