背景#
Madhu Guru 现任 Meta AI 高级总监（Sr Director, AI），此前在 Google 负责 Gemini、Veo、Nano Banana。这个系列的可信度来自亲历——Part 5 里「把复杂 eval 套件压成一个分数」的反面教训，就发生在他所在的 Gemini 早期团队。
系列从 2026-08-18 开始日更，Part 9（08-26）后停了两周，Part 10 于 09-10 补上。十讲围绕一个问题：怎么给自己的 AI 产品建一套真正能驱动改进的 Eval 体系。注意全程谈的是自有产品的私有 eval，没有一个字提公共 benchmark。
顺带说一句考证：用户给我的清单里 Part 2、3 共用一条链接，实际核对后发现 Part 3 是 8 月 20 日单独的一条推文；8 月 19 日那条（成本哲学）原文未标注编号，按时间序列是事实上的 Part 2。文末链接已按真实顺序修正。
全景：一条逻辑链#
把十讲按逻辑重排，是一条完整的 Eval 建设路径：
- 从哪开始：挑一个你足够熟悉的工作流，研究真实 traces（Part 1）
- v1 落地后第一件事：从生产 traces 聚类出失败模式分类法（Part 3）
- 花多少钱：先建立质量上限，再沿成本曲线下行（Part 2）
- 要建几个：四种 eval 组成梯队，各司其职（Part 4）
- 怎么读结果：拒绝把套件压成单一分数（Part 5）
- 怎么用结果：Hill Climbing，选定维度持续优化（Part 6）
- 单个 eval 怎么设计：粒度（Part 7）、区分度（Part 8）、过程测量（Part 10）
- 怎么活下去：eval 需要跟随用户行为演化的路线图（Part 9）
下面逐块展开。
起点：从真实 traces 出发（Part 1）#
精通 eval 的最好方式：拿一个你非常了解的工作流，弄清楚怎么让它的质量可测量。
具体动作：
- 研究真实 traces ——典型用户的 prompt 序列、每一步的好响应长什么样、端到端的好结果长什么样
- 研究产品的失败现场 ——把失败 case 做成 traces：混乱的工具调用返回、缺失的上下文等等
- 有了好 eval 之后，解决可重复、自动化运行
- 再解决持续镜像线上流量，跟随用户行为演化
最后两条当时只是一句话带过，到 Part 9 才展开，首尾呼应。
v1 之后立刻做：失败模式分类法（Part 3）#
Eval v1 落地后的第一件事不是改模型，而是建 failure modes taxonomy（失败模式分类法） ：
- 拉最近 500–1000 条生产交互，专看失败 case
- 聚类，并给每个簇起具体的名字
「回答得不好」不是合格的簇名。合格的粒度是：
- 检索到了错误的文档
- 文档对了但相关段落没取到
- 没能 ground 到上下文，产生幻觉
- 该拒答时没拒答，反而编造
- 问题本身有歧义，没有追问澄清就做了糟糕的假设
这些是完全不同的问题，解法也不同。能精确命名失败，才能设计专门捕捉它的 eval 测试 ——这是从 eval 通向改进飞轮的桥。
成本哲学：先质量，后成本（Part 2）#
像对待前沿模型一样对待 eval：先建立质量上限（quality frontier），再沿成本曲线下行。
顺序是：
- 先定义「好」 ——写出 rubric（评分量规）
- 再找最好的测量方式 ——人工 / LLM judge / 自动化校验
- 这个阶段要舍得花钱 ——用最贵的 judge 模型、付费人工（或投入自己的时间），跑出你真正信任的信号
- 当 eval 能稳定区分好坏、且确实反映你在意的东西之后 ——才转向降本：更多自动化、更小的 judge 模型、采样、能确定性校验的地方用代码
Quality first. Cost next. 反着做（先图便宜）会得到一个便宜但不可信的 eval，后面所有决策都被带偏。
Eval 梯队：四种 eval 各司其职（Part 4）#
企业做不好 AI 系统，核心原因是缺 eval 策略。需要的是阶梯式（laddered）组合 ，在成本/真实性光谱上排开：
| 类型 | 回答的问题 | 特点 |
|---|---|---|
| Hill-climb 长 eval | 产品的前沿能推到哪 | 推动质量上限、扩展功能面，需要持续刷新 |
| Regression eval | 爬坡时把今天的产品弄坏了吗 | 守住存量能力 |
| Smoke test eval | 安全和基本面没出岔子吧 | 题不难但绝不能错，比如产品身份 |
| Launch eval | 真实流量下表现如何 | 接近在线测试，控制少但最真实 |
读结果：警惕「平均数的暴政」（Part 5）#
别把你那套漂亮而复杂的 eval 套件，压成一个分数。
这种压缩的动机通常是某位高管想要一个简化数字来做决策——Gemini 早期就这么干过。问题在于 AI 系统的质量不是单维度的 。假设一次改版后：
- 简单摘要：85% → 89%
- 基础事实问答：80% → 85%
- 复杂金融分析：70% → 63%
单一总分会说「变好了」，却掩盖了在你的前沿用例上退步了这个事实。
加权平均也不是解法——那只是围绕一个判断，制造了一层虚假的数学精确性（false mathematical precision around a judgment call）。
正确的做法：
- 按 Part 4 的梯队维护一份有优先级的 eval 清单
- 让看得进细节的人来看，别找抽象的简化
- 深入理解每个关键 eval 的结果 ——哪里失败、哪里出色，再基于对用户的整体影响下判断
用结果：Hill Climbing 飞轮（Part 6）#
Hill climbing 说人话就是：选一个要紧的维度，冲着它优化。维度可以是：基于最新生产数据改进高价值用户旅程的质量、向相邻用例扩展、降成本、降延迟。
手段无非那几样：prompt eng、context eng、memory、post training、确定性老派代码——本质是更好的 harness 加模型选择。
指南针是 Part 3 的失败模式分类法。举例：工具调用失败是最高频问题，深挖发现上下文里塞了 20 个工具，而每个任务实际只需要 3–5 个——这里的爬坡就是做 context eng，在对的阶段给对的工具，迭代到好为止。
降本同理：先用最好的模型发布，把质量拉满；确认用户爱这个体验之后，再爬坡换到更小、更便宜、更快的模型，保持质量不掉。
前提只有一个：手里得有能告诉你「是否在朝正确方向移动」的 eval 。
单个 eval 的三个设计要点#
粒度：Goldilocks 原则（Part 7）#
Eval 应该建在「jobs to be done」的层级上，而不只是最终答案。
反例：金融分析 agent 最终输出股票推荐，最常见的错误是做一个「标准答案集」，检查 agent 是否推荐了「对的」股票。但推荐之前发生了一连串有独立意义的 jobs：
- 理解客户：持仓、风险承受度、投资期限、目标、约束
- 收集证据：个股、板块、宏观环境、美联储政策、近期与将来的新闻事件
- 分析数据：营收增长、估值指引、增长预测，收敛出候选名单
- 给出推荐：代码、买卖价、时间框架
每个阶段都有中间产物，都可以（也许都应该）有自己的 eval。这样当最终推荐错了，一套设计良好的 eval 能直接告诉你：客户理解 92%、证据提取 92%、数据分析 70%、推荐生成 75%——该去哪挖，一目了然。觉得数据分析还太复杂，就继续往下拆成更小的 jobs。
不太细，不太粗，刚刚好 ：粒度以「足以诊断并行动」为准。
区分度（Part 8）#
一个 hill-climbing eval 有用的前提是：能把真正有差异的系统区分开 。
五个系统跑同一个 eval：A=94，B=93，C=95，D=94，E=92。如果你已知 A、C 明显强于 D、E，那这个 eval 是坏的——它没有区分度。就像给一群博士做五年级数学测验：人人满分，你什么信息都没得到。
但也不能反过来把 eval 做得任意难——人人零分同样没有信息量，而且偏离了系统本来的用途。
甜蜜点是：真实 + 有难度 + 对能力差异敏感 。
随之而来的是饱和问题：随着 harness 和底层模型进步，好 eval 终将被刷满。Madhu 在 Part 8 末尾把「饱和后怎么办」留给读者猜，Part 9 给出了半个答案（见下）。
过程测量：步骤不只是结果（Part 10）#
像高中数学一样，光答案对不够，怎么算出来的同样关键。
两条 agent 轨迹可能产出同一个答案（42）：一条搜对了来源、检索对文档、4 次干净的工具调用算出结果；另一条调了 17 次、同一个东西搜了 3 遍、从 2 个错误里爬回来才到终点。哪个更好，显而易见。
落地步骤：
- 清晰定义整个工作流
- 定义每一步的任务
- 想清楚每一步怎么测——独立的 eval，还是大 eval 的一个切面
- 定义中位任务和困难任务，并在 eval 中体现
看 eval 结果时：先看步骤，再看最终结果 。
活下去：Eval 路线图（Part 9）#
大多数 eval 死于被当成静态制品，而用户的期望和行为一直在演化。
以金融研究 agent 为例，用例的自然演化路径：
- 早期：总结这份 5 页的财报
- 三周后：回顾最近 5 份财报，讲清它的增长故事
- 两个月后：这是 15 份材料——财报、电话会记录、研报，给我建一个投资论点
- 最终：监控我的持仓，有实质性变化时主动提醒我
每个阶段要求的能力不同，eval 也必须跟着变：短上下文 → 长上下文、单轮问答 → 多轮、段落引用 → 文档级和行级引用、简单问答 → 复杂综合、被动聊天 → 主动 agent。
如果你的 eval 停在第一周，而用户已经到了第三周，落差迟早体现在产品和流失指标上 。
实操路线：
- 画出用法会沿哪些维度演化（轮数、文档规模、工具使用、自主性、旅程覆盖）
- 排优先级：对产品最重要的用例和维度先行
- 和用户聊、挖生产 traces，寻找行为漂移
- 为下一阶段的用法建 P0 eval
- 跑 eval、找失败模式（回到 Part 3）、爬坡（回到 Part 6）
目标是跑在用法演化前面 ——本质上是 PM 基本功（他自己也这么说）。
我的几点思考#
与 Anthropic「对结果而非路径」的张力#
本博客之前译过 Anthropic 的 《解析 AI Agent 评估》 ，其核心建议是考核最终状态、「对结果而非路径」。Madhu 的 Part 10 却说「measure the steps, not just the result」。表面矛盾，实则互补：
- Anthropic 防的是过拟合路径 ：agent 的优势恰恰在于能走出人类没预设的路径，对步骤打分会惩罚合理的非常规解法
- Madhu 解决的是诊断与成本 ：最终答案错了不知道坏在哪、答案对了却花了 4 倍调用成本，都得靠过程信号
合起来读：评分看结果，诊断看过程 。一个是 grader 设计原则，一个是可观测性要求，不在同一层级。
整个系列的隐含立场#
- Eval 是 PM 工具，不只是 ML 工具 ：rubric、失败分类、roadmap、和用户聊——更像产品基本功而非模型工程
- 只谈私有 eval，不碰公共 benchmark ：立场很直白——benchmark 是模型方的营销素材，自有 eval 才是产品方的方向盘
- 质量上限思维贯穿始终 ：eval 先买最贵的信号（Part 2）、发布先用最好的模型（Part 6）、eval 先于功能演化（Part 9）——都是同一个「先把上限打出来，再优化成本」的打法
没讲透的地方#
- 统计显著性 ：区分度（Part 8）直觉上是对的，但「94 vs 95 是真差异还是噪声」需要样本量和置信区间的讨论，系列没碰
- LLM judge 的校准 ：Part 2 一句「人工 / LLM judge / 自动化校验」带过；judge 本身怎么评、怎么和人对齐是另一个大坑——Anthropic 那篇讲了人机校准，可以互补着看
- 过程分谁来打 ：Part 10 说了「要看步骤」，但步骤分怎么打、用代码还是 judge，没有展开