前言：为什么 eval 不是冷冰冰的测试

如果你刚开始接触 AI eval，很容易把它理解成一件很工程化的事：准备一批样本，跑一个脚本，得到一个分数，然后决定模型 A 比模型 B 好。这当然是 eval 的一部分，但如果只停在这里，就会误解它最有价值的地方。

真正的 eval，首先是一种判断力。它追问的不是“模型得了多少分”，而是“这个系统在我们真正关心的场景里，是否做了该做的事，是否避开了不该犯的错”。这句话听起来朴素，却是很多 AI 产品从 demo 走向生产时最难跨过的门槛。demo 里的模型常常聪明、流畅、令人惊喜；生产里的系统却要面对含糊的用户、脏数据、工具超时、权限边界、历史状态、组织流程和风险责任。eval 的工作，就是把这些原本散落在产品、工程、运营、安全和用户体验里的判断，变成可以反复查看、讨论和改进的对象。

很多团队第一次认真做 eval，不是因为想写一个漂亮的 benchmark，而是因为某个具体问题终于无法再被“感觉还行”掩盖：客服机器人承诺了不存在的退款；销售助手把内部备注发给了客户；差旅报销 agent 在缺少项目编号和超预算说明时直接提交了单据；coding agent 修好了一个测试，却悄悄破坏了另一个功能。单看最终回答，它们往往并不荒唐，甚至语气很好。真正的失败藏在上下文、工具调用、业务状态和用户期待之间。

这也是为什么这套教程反复强调“先看数据”。不是因为技术上必须先有一个数据集，而是因为真实 trace 会让你放下想象中的用户，面对真实系统正在发生什么。很多失败在会议室里想不到，在指标面板上也看不出来；只有把一条对话、一串工具调用、一组状态变化从头读到尾，你才会发现系统的盲点。Hamel Husain 和 Shreya Shankar 反复说 error analysis 是最高杠杆活动，原因就在这里：看失败样本不是低级劳动，而是产品判断形成的地方。

eval 也不是为了证明模型“不行”。好的 eval 更像一面镜子，照出系统到底是什么。它能告诉你某个失败是模型能力问题，还是 prompt 说得不清；是检索没拿到证据，还是工具设计让模型很难用；是 judge 漏掉了风险，还是业务标准本身没有说清楚。很多时候，eval 改进的对象并不是模型，而是整个系统：数据、工具、权限、UI、handoff 机制、runtime、甚至团队协作方式。

这也是为什么 AI 产品的 eval 和传统软件测试相似，却不能完全等同。传统测试往往假设需求已经明确，代码只需符合规格；AI eval 常常要在“规格还没有完全写清楚”的情况下工作。你以为自己要测“回答是否有帮助”，看了几十条 trace 后才发现真正的问题是“信息不足时是否应该追问”。你以为自己要测“是否完成报销”，后来才发现还要测“金额是否与发票一致”“是否处理了超预算政策”“是否在员工确认前禁止提交”“是否保留了审计日志”。标准不是凭空写出来的，标准是在看真实行为时逐渐长出来的。

因此，这套教程虽然包含很多技术内容：pass@k、pass^k、TPR/TNR、LLM-as-judge、state verifier、trajectory eval、CI gate、benchmark contamination。但这些技术点背后只有一条主线：怎样让 AI 系统的质量变得可见。可见之后，才可能被讨论；能被讨论，才可能被修复；能被修复，才可能持续变好。

读这套文档时，不妨把自己放在一个具体角色里：你不是在学习一组抽象指标，而是在准备让一个 AI 功能真正面对用户。你要决定哪些错误可以接受，哪些错误必须零容忍；哪些分数只是研究兴趣，哪些指标会影响上线；哪些判断可以交给代码，哪些必须由领域专家校准；哪些公开榜单可以参考，哪些必须回到自己的产品分布中验证。

如果说传统 benchmark 更像考试，那么 product eval 更像临床观察。考试能比较一群学生在同一张卷子上的表现；临床观察要判断一个人在真实生活中是否能稳定、安全地完成重要任务。AI agent 进入生产之后，我们面对的越来越不是“它会不会答这道题”，而是“它会不会在一个复杂环境里，反复做出可靠的判断”。这就是 eval 变得重要的原因。

本教程后面的章节会逐步进入方法细节。但在进入细节之前，请先记住一个简单原则：eval 的目标不是制造更多分数，而是帮助你更诚实地看见系统。只要这个目标不丢，技术工具才会真正有用。