01. 为什么 AI 产品需要自己的 eval

本章回答：为什么公开 benchmark、演示 demo 和“看起来不错”都不足以判断一个 AI 产品能不能上线。

学习目标

读完本章，你应该能解释：

• eval、benchmark、product eval 的区别。
• 为什么 AI 产品的主要瓶颈正在从“能不能解题”转向“我们到底要测什么”。
• 为什么 eval 是产品规格、研发反馈回路和组织协作语言，而不只是测试脚本。
• 为什么“通用 helpfulness 分数”通常不能指导产品改进。

本章导读

很多人第一次想做 eval，是在产品已经出现一些说不清的失败之后。模型看起来很聪明，用户演示也过得去，但一上线就开始出现零散的、难以归类的问题：有时答非所问，有时过度承诺，有时忘记前文，有时调用了错误工具。团队开会讨论时，每个人都能举出几个例子，却很难说系统整体到底有没有变好。

这时 eval 的价值就出现了。它不是为了让团队拥有一个“看起来科学”的分数，而是为了把分散的直觉整理成可检验的判断。一个好的 eval 会迫使你说清楚：什么叫成功，什么叫失败，失败有多严重，哪些失败只是体验问题，哪些失败会带来真实风险。这个过程往往比写 scorer 更重要，因为它把团队从“模型感觉如何”带到“产品到底要求什么”。

因此，本章的重点不是介绍某个工具，而是先建立一个基本立场：AI 产品需要自己的 eval，是因为公开 benchmark、demo 和通用质量分都无法替你回答产品问题。你的用户、数据、工具、流程和风险边界，才决定了你应该怎么评估。

核心论点

AI eval 的核心不是“给模型打分”，而是把一个产品对智能行为的期望变成可观察、可争论、可复现、可回归的规格。公开 benchmark 能告诉你一个模型在某个公开任务分布上的表现，但不能告诉你你的 agent 在你的用户、你的工具、你的业务状态、你的风险边界里是否可靠。

Shunyu Yao 在《The Second Half》中把这个转向说得很清楚：AI 进入第二半场后，重点从“解决问题”转向“定义问题”，evaluation 变得比 training 更重要Yao2025。这不是说训练不重要，而是说当通用大模型与通用 agent recipe 能快速击穿越来越多静态 benchmark 时，真正稀缺的是：你能不能定义一个接近真实世界价值的任务，并持续测出改进。

Eval、benchmark 与 product eval

公开 benchmark 仍然有价值。它们适合筛模型、理解能力上限、观察行业趋势。但产品 eval 的单位不是“模型”，而是“系统在某个真实任务中的行为”。Agent 场景里尤其如此：同一个模型，换一个工具设计、runtime、prompt、memory、浏览器环境或错误处理策略，结果可能完全不同LeeRuntime2026。

“第二半场”：为什么定义问题变得更重要

先看一个更贴近产品的场景：公司内部上线了一个差旅报销 agent，员工可以把行程、发票和项目背景发给它，由它检查政策、整理报销单、补齐说明，并在员工确认后提交到财务系统。这个 agent 在公开问答 benchmark 上表现很好，也能解释“差旅报销政策是什么”。但上线风险并不在于它会不会背政策，而在于它能不能在真实流程里做对：发现酒店超预算时是否要求说明，缺少项目编号时是否追问，发票金额和报销金额是否一致，是否会在员工未确认时直接提交，是否会把个人消费错误归到客户项目。

这个场景说明了 Yao 所说的“第二半场”：AI 发展重心正在从单纯证明模型能解题，转向定义什么任务真正代表现实价值。在早期，很多研究工作的叙事是：提出一种新方法，然后在一组公开 benchmark 上证明它更强。这个阶段当然重要，因为它让领域有了共同参照，也让不同模型和方法能够被比较。但当预训练、推理扩展、工具使用和 RL 这些通用 recipe 越来越成熟之后，许多干净、静态、边界清楚的 benchmark 会更快被击穿。分数继续上涨，但“分数上涨”本身不再自动等于“真实世界问题被解决”。

真实产品面对的不是一张固定试卷。用户会含糊表达，会改变主意，会把业务流程说漏一半；工具会超时，会返回空结果，会有权限限制；数据会脏，政策会变，成本和延迟也会变成产品体验的一部分。一个模型能解出一道代码题，不代表它能在你的仓库里做最小修改；能在客服 benchmark 中答对规则题，不代表它会在真实订单状态里做正确变更；能写出流畅解释，也不代表它真的完成了外部系统操作。

Yao 还特别提醒两条传统评测假设在 agent 时代会失效。第一，真实任务通常不是 no-human-in-loop：客服、报销、代码修改、采购审批都需要在不确定处追问、确认、解释或升级给人。第二，真实任务也不总是 i.i.d. 的一次性样本：一个 coding agent 可能连续处理同一个 repo 的多个 issue，一个企业助手可能在多轮、多天的上下文里逐渐积累用户偏好和项目状态。如果 eval 只测“给一条完整指令，独立跑一次”，它会低估交互、记忆、长期状态和累积熟悉度这些真实 utility 的组成部分。

因此，AI 产品的关键问题从“模型有没有某种抽象能力”，逐渐变成“我们能否定义一个足够接近现实价值的任务，并持续测量系统在这个任务上的表现”。

Yao 的论证可以归纳为六个要点：

1. 第一半场中，研究常常先提出方法，再用 benchmark 证明方法有效。
2. 大规模预训练、推理、工具使用和 RL 让通用 recipe 越来越强，许多干净 benchmark 会越来越快饱和。
3. benchmark 饱和不等于真实世界 utility 被解决。真实产品还要面对人类互动、脏数据、异步流程、工具失败、权限、成本和责任。
4. no-human-in-loop 的评测假设过窄；许多真实 agent 必须在任务中持续和人交互。
5. i.i.d. 的评测假设也过窄；许多真实 agent 要在连续任务、同一环境或长期上下文中积累熟悉度。
6. 因此更重要的问题变成：哪些任务真的代表现实价值？哪些 eval 设置真正逼近真实部署？

这就是 eval 的 product-manager 属性：它要求你定义“什么算成功”，也要求你定义“什么失败不可接受”。如果你没有自己的 eval，你其实没有清楚的产品规格，只是在靠 demo、直觉和零散用户反馈推动开发。

Eval 是科学方法，不是工具按钮

回到差旅报销 agent。一次 prompt 修改让它更主动了：它不再反复问员工问题，而是尽快整理单据并提交。demo 看起来更流畅，平均满意度也可能上升。但如果这个改动同时让它在缺少项目编号时跳过追问，或者在超预算酒店费用上不再要求说明，产品实际上变危险了。你需要的不是一个更漂亮的 dashboard，而是一套能验证这类假设的流程。

Eugene Yan 的核心提醒是：再多工具也救不了一个没有过程的产品YanEvalProcess2025。很多团队第一次做 eval 时，会下意识先找平台、找 dashboard、找“自动打分”的能力；但如果团队还没有说清楚想减少哪类失败、哪些样本代表真实风险、什么阈值会影响上线决策，平台只能把混乱自动化。

一个健康的 eval 流程更像科学方法。你先提出假设：这次改动应该减少哪类失败？例如“新的工具描述应该减少错误退款调用”，或者“新的检索策略应该减少 unsupported claim”。然后定义观测：用哪些样本、哪些 scorer、哪些指标来判断这个假设是否成立。接着运行实验，并固定 prompt、模型、工具、runtime、采样参数和数据集版本。最后分析结果：不只看平均通过率，还要看失败模式是否真的减少，罕见高危样本有没有变差，成本和延迟是否被转嫁到了系统其他地方。

一个健康的 eval 流程可以保留为五个要点：

1. 提出假设：这个改动应该减少哪类失败？
2. 定义观测：用哪些样本、哪些 scorer、哪些指标判断？
3. 运行实验：固定版本、记录输入输出、成本、延迟和失败样本。
4. 分析结果：不只看平均分，还要看失败模式、分布、置信度和严重性。
5. 进入下一轮：修 prompt、工具、数据、harness、模型或产品流程。

这个过程之所以重要，是因为 AI 产品的改进很容易制造错觉。你可能修好了一个 demo case，却让另一个用户群体退步；你可能提高了 judge 分数，却只是让回答更长；你可能让 agent 更“积极”，同时降低了它在不确定场景下拒答或转人工的能力。Han-Chung Lee 的 define → evaluate → analysis → align 循环表达的也是同一个意思：eval 是设计约束，是产品不断对齐现实的方式，不是项目最后附加的一张验收表LeeSeminalPapers2026。

为什么通用指标经常没用

AI 产品团队很容易被这些数字诱惑：

• helpfulness: 4.2
• conciseness: 3.8
• answer quality: 0.76
• overall score: 81.5

这些分数的问题不是“完全没有信号”，而是经常不可行动。差旅报销 agent 可能语气友好、解释流畅，却把个人餐饮归入客户招待，把缺少项目编号的报销单提交到财务系统，或者在酒店超预算时没有要求员工补充业务说明。这些失败不是“helpfulness 下降 0.3”能解释的。Hamel Husain 与 Shreya Shankar 的 walkthrough 中，真正有价值的动作是阅读真实 trace，给第一处上游错误写自由文本笔记，然后统计失败类别HamelShreya2026。

通用指标最常见的问题，是粒度太粗。一个“overall score: 81.5”无法告诉你应该修 RAG、tool schema、prompt、UI、权限系统还是人工接管流程。分数下降可能来自检索召回不足，也可能来自工具错误信息不清，也可能只是 judge 对较短回答不友好。如果指标不能指向一个修复动作，它就很难成为产品迭代的依据。

第二个问题是边界不稳定。1 到 5 分看似细腻，实际常常没有可复现的判断边界。什么叫 3 分，什么叫 4 分？如果一个回答事实正确但语气生硬，应扣多少？如果一个回答很有礼貌但承诺了不存在的功能，又应扣多少？不同人、不同 judge model、不同提示词可能给出不同分数，团队最后讨论的不是产品问题，而是分数本身是什么意思。

第三个问题是它容易掩盖业务严重性。100 个轻微格式错误不一定比 1 个越权退款更重要；语气好不代表没有泄露信息；回答流畅不代表真的提交了正确单据。产品 eval 需要把“质量”拆成具体 failure mode：是否使用了不存在的事实？是否在缺少附件时声称已提交？是否对可疑供应商发票放行？是否真的写入了正确的业务状态？是否改变了不该改变的数据库行？只有拆到这个层次，指标才会从“评价模型”变成“指导修复”。

通用指标的典型失败可以保留为四类：

• 太粗：一个总分无法告诉你该修 RAG、tool schema、prompt、UI 还是权限。
• 太主观：1 到 5 分常常没有稳定边界，不同人、不同 judge、不同提示词会漂移。
• 不贴近业务：语气好不代表没有泄露信息；回答流畅不代表真的发了邮件或提交了正确单据。
• 掩盖严重性：100 个轻微格式错误不一定比 1 个高危越权操作更重要。

一个最小 eval 飞轮

你不需要一开始就有完整平台。最小可用 eval 可以很朴素：

1. 收集样本：抽 20 到 100 条真实 trace，包含输入、输出、工具调用和环境状态。
2. 错误分析：每条失败 trace 只记第一处最上游错误。
3. 聚类归因：把自由文本错误笔记聚成 4 到 8 个失败类别。
4. 优先级排序：按频率、严重性、商业价值排序。
5. 写 eval：每个高优失败模式写一个二元 scorer，能用代码就用代码，不能用代码再用 LLM judge。
6. 校准 scorer：用人工标签验证 TPR/TNR、precision/recall。
7. 修复并回归：修系统，把失败样本加入 regression set，接入 CI 或定期监控。

这套飞轮的意义在于，它把 eval 从一次性的评审活动变成持续学习的机制。真实 trace 让你看到问题，错误分析让你给问题命名，scorer 让问题可重复检测，regression set 让修复不会悄悄失效。哪怕一开始只有几十条样本，只要这个循环能跑起来，团队就已经从“凭感觉调模型”进入了“用证据改产品”的状态。

Eval 的三个角色

1. 产品规格

eval 让“这个 agent 应该能处理报销”变成“当报销单缺少项目编号时必须先追问；当酒店费用超过政策上限时必须要求业务说明；当员工尚未确认最终金额时不能调用 submit_expense；当发票附件缺失时不能声称已经提交成功”。这些具体句子才是可执行产品规格。

2. 工程回归保护

prompt、模型、RAG、tool schema、runtime 都会变。没有 regression eval，每次改动都可能让旧问题复活。Vercel、promptfoo、Braintrust、MLflow 等实践都把 eval 作为 PR 或发布前的 gate 来用AwesomeEvalsPatterns2026。

3. 组织协作语言

好的 eval 把 PM、工程、标注专家、领域专家和安全人员拉到同一个对象上：具体样本、具体失败、具体指标、具体阈值。它减少“我觉得还行”和“我觉得不行”的空转。

常见误区

误区 1：先买平台，再想评什么。
平台能降低记录、比较、展示和协作成本，但不能替你定义成功。先看 trace 和失败模式。

误区 2：把公开 benchmark 分数当上线依据。
公开 benchmark 可以筛模型，不能代表你的产品分布、工具环境和风险边界。

误区 3：一个 God Evaluator 解决所有问题。
通用 judge 往往不可解释、不可行动。实践上更可靠的是多个窄域 binary evaluator。

误区 4：只优化平均通过率。
罕见但高危的失败，例如信息泄露、越权操作、错误付款，应该单独设 gate。

误区 5：eval 写完就结束。
模型、用户、工具、数据源和攻击方式都会变化；eval 是活系统。

本章练习

选一个你关心的 AI 功能，写下：

1. 三个“看起来回答不错，但业务上失败”的例子。
2. 三个“必须 0 容忍”的失败。
3. 三个可以用代码直接检查的行为。
4. 三个需要人类或 LLM judge 判断的行为。
5. 一个你不会用公开 benchmark 代替 product eval 的原因。

延伸阅读

• Yao2025：为什么 evaluation 变得比 training 更重要。
• YanEvalProcess2025：为什么工具不能替代 eval 过程。
• HamelShreya2026：如何从真实 trace 开始做 eval。
• LeeSeminalPapers2026：eval 作为 define → evaluate → analysis → align 循环。