Why AI Evals 是 AI 产品构建者最热门的新技能

5 分钟阅读

背景与引子

两年前，如果你在产品经理大会上提到”evals”这个词，大多数人会一脸茫然。如今，这个词已经成为顶级 AI 播客节目中最热门的话题之一。Anthropic 和 OpenAI 的 CPO 都在不同场合公开表示：构建出色的 AI 产品，你需要精通 evals。这不仅是一个技术术语，更是一种思维方式的转变。

问题的根源在于：传统软件测试的逻辑在 AI 时代已经完全不够用了。当你的产品是一个会”思考”、会”发挥创造力”的语言模型时，你如何知道它什么时候做对了，什么时候在胡说八道？当用户与 AI 的每一次对话就是这个产品的全部体验时，你怎么能确保它始终如你所愿地工作？

这正是 Hamill Hussein 和 Shrea Shankar 在过去几年里一直在回答的问题。他们曾经是 AI 公司的数据科学家和产品负责人，如今是 Maven 平台上排名第一的 AI evals 课程导师。他们的学生遍布 500 多家公司，包括 OpenAI、Anthropic 以及其他所有主要 AI 实验室的团队。

这不是一门教你如何使用现成工具的课程。这是一门教授你如何建立系统性方法去理解、测量和改进 AI 产品的方法论。而这种方法论，正在成为 AI 时代产品构建者的核心竞争力。

嘉宾是谁

Hamill Hussein 是一位经验丰富的 AI 产品构建者，曾在多家 AI 公司担任数据科学和产品相关角色。他最引人注目的特点是他极强的行动力和执行力——他不是那种只会谈理论的人。在这次访谈中，他直接在屏幕上展示真实的 trace 数据，一步一步演示如何做 error analysis，这种”show don’t tell”的能力让他成为这个领域最受欢迎的教育者之一。

Shrea Shankar 是一位研究背景深厚的产品人，曾在 OpenAI 等公司从事研究和产品工作。她的学术训练让她对方法论有极高的要求——她坚持认为 evals 的方法必须建立在几十年社会科学研究的基础上，而不是凭空发明。她也是”谁来验证验证者”这篇重要研究论文的作者之一。

两人合作教授的 AI Evals 课程是 Maven 平台上最受欢迎的课程，已经帮助超过 2000 名 PM 和工程师掌握了这项技能。他们的方法论正在被越来越多的 AI 公司采纳。

核心观点 TOP10

  1. Evals 是系统化测量和提升 AI 应用的方式，本质上是对你的 LLM 应用进行数据分析，建立指标来衡量正在发生的事情。

  2. 别把 evals 等同于单元测试。单元测试只是 evals 这个大图谱里的一小部分。你还需要数据采样、错误分析、在线监控、业务指标追踪等多种手段。

  3. 从 error analysis 开始，而不是直接写测试。大多数团队一听到”evals”就跳到”让我写一些测试”，这是最常见的错误。

  4. 人类不会被 AI 完全取代。在 error analysis 的自由笔记阶段，必须由人来完成。AI 可以帮助组织、分类、计数，但最初的”感受”需要人类来给出。

  5. 设立一位”仁慈的独裁者”。在做 open coding 时，不要搞委员会制度——让一个你信任其品味、拥有领域专业知识的人来做这件事，通常是产品经理。

  6. 不需要追求完美的评估体系。目标是可操作地改进你的产品，而不是建立一个完美的测试框架。

  7. 大多数产品只需要 4-7 个 LLM as judge 评估。因为很多问题实际上可以通过修改 prompt 直接解决，不需要额外的评估框架。

  8. LLM as judge 必须与人类判断对齐。不要盲目相信 AI 的评估结果，你需要测量 judge 与人类判断的一致性。

  9. AB 测试是 evals 的一种形式，但前提是你已经通过 error analysis 了解了真正的错误在哪里，而不是凭空假设。

  10. 一次性投入，长期受益。第一次做 error analysis 可能需要 3-4 天，但之后每周只需要 30 分钟来维护和改进。

关键洞察

洞察一：数据是你最好的老师，但需要方法才能读懂它

访谈中展示了一个完整的 error analysis 流程：从 Nurture Boss（一个物业管理 AI 助手）的真实 trace 数据开始，逐条查看对话记录，手动写下问题笔记。Hamill 特别强调：这个过程会让每个人都上瘾。因为当你真正看到数据时，你会发现产品的问题完全不是你想象的那样——可能是对话流程不流畅、可能是文本消息格式混乱、可能是 AI 在告诉你某个不存在的功能。这些细节只有通过亲自查看数据才能发现。

洞察二：模糊的正确不如清晰的错误

访谈中反复强调：给你的 LLM judge 的指令必须给出二元判断（true 或 false），而不是 1-5 分的评分。如果你用模糊的多分制，你的团队最终会困惑于”3.2 分和 3.7 分到底有什么区别”。清晰的是非判断才能带来可操作的改进。

洞察三：你的假设在数据面前往往站不住脚

Shrea 在论文”Who Validates the Validator”中有一个关键发现：即使是构建过多个 LLM 系统的专家，也只有在他们看到 10 个以上的输出后，才能真正识别出失败模式。在看到数据之前，没有人能真正预测到所有可能的问题。这彻底改变了传统的产品开发思维——PRD 可以给你方向，但不能给你答案。

洞察四：狗粮测试是 eval 的最低配版本

访谈中提到 Claude Code 的团队可能”只是在用 vibes”，但 Shrea 的反驳一针见血：他们很可能是通过极其严格的内部测试和 dog fooding 来发现问题。这本质上就是人工版的 eval——只是不够系统、不够自动化。狗粮测试适用于高度技术化的产品（开发者天天用）和高度专业化的领域（医生自己会用 AI 辅助诊断），但对大多数产品来说，你需要更结构化的方法。

洞察五：工具不能替代方法论

市面上有越来越多的”AI eval 工具”，但这些工具往往效果不佳。核心问题在于：每个产品都有自己独特的失败模式，别人的工具无法理解你的业务逻辑和用户场景。你需要建立自己的方法论，而不仅仅是购买一个工具然后插入数据。

精彩金句

“Evals 是你能做的最高投资回报率的活动。”

“我们正处于 AI 时代，AI 不能自己评估自己——它做不到。这个误解太常见了。”

“不要被吓到。目标不是完美地做 eval，而是可操作地改进你的产品。”

“当你在做 open coding 时，你是在培养自己对产品的直觉。每个人一旦开始做这个，就会立即上瘾。”

“LLM as judge 的魔力在于它极度聚焦——你让 judge 只做一件事，评估一个失败模式。输出就是通过或失败。这是 LLM 非常擅长的事情。”

“PRD 是一个很好的抽象思维，但它不是最终答案。它会随着你看到真实数据而改变。“

实战案例

访谈中用 Nurture Boss 作为完整案例展示了 eval 的全过程。这是一家为公寓管理公司提供 AI 助手的企业，AI 帮助处理潜在租户咨询、预约看房等操作。

第一步：Error Analysis（错误分析）

Hamill 在屏幕上展示了真实的 trace 数据——每一段用户与 AI 的对话日志。他逐条浏览，停下来写下简短的问题笔记。比如：AI 说”We don’t have specific information on the availability”，但对产品来说，这个回复不够好——应该引导用户联系真人。Hamill 在旁边写下一句话：“should have handed off to a human”。

第二步：从混乱到秩序

看了 100 条 trace 后，他们用 LLM 来帮助分类这些笔记——这叫”axial coding”（轴心编码）。LLM 把这些凌乱的开放编码归类为几个主题：对话流程问题、工具调用错误、人工交接问题等。然后用 Excel 透视表统计每类错误出现的次数。结果发现：对话流程问题出现了 17 次，是最高频的问题。

第三步：构建 LLM as Judge

针对最需要解决的问题（人工交接问题），他们写了专门的 judge prompt。这个 prompt 明确列出什么时候应该转人工：用户明确要求人工、循环超过一定次数、涉及政策规定的转接、需要讨论敏感问题等。然后他们测量 judge 与人类判断的一致性（通过混淆矩阵），确保 judge 是可靠的。

第四步：自动化和持续监控

一旦建立了可靠的评估框架，就可以把它放进 CI/CD 流程，确保每次代码变更都不会引入新的问题。同时也可以在生产环境中每天采样运行，监控真实用户的体验质量。

行动建议

建议一：现在就开始看你的 trace 数据

为什么做：你的产品每天产生的数据正在告诉你它哪里出了问题，但如果你不主动去看，你永远不会知道。

如何开始：找一个 observability 工具（LangSmith、 Phoenix Arize、Braintrust 等），导出最近的 100 条 trace，逐条浏览，写下第一个让你觉得”不对”的问题。不要试图找出所有问题——只记录最上游的那个。给自己设定一个”仁慈的独裁者”角色。

得到什么：你会发现产品的问题完全不是你想象的那样。可能是某个功能从未被正确调用，可能是 AI 在特定用户群体面前表现异常。发现本身就是价值。

建议二：用 LLM 帮助你分类，但不要让它替代你思考

为什么做：当你有 100 条笔记后，逐条手工分类是不可扩展的。LLM 非常擅长信息综合。

如何开始：用这个 prompt：“Here are my open codes from error analysis. Create axial codes by grouping them into failure modes. Each axial code should be a clear, actionable failure mode.” 然后审查 LLM 给出的分类，调整到你觉得更具体、更可操作的程度。给自己保留一个”none of the above”选项，如果有很多笔记落在这个类别，说明你的分类体系不完整。

得到什么：你会得到一个清晰的错误优先级列表，知道哪个问题出现频率最高、需要最先解决。

建议三：写二元判断的 LLM judge

为什么做：多分级评分让你无法做出清晰的决定，而且容易产生”分数游戏”——人们为了高分数而优化，而不是为了真实的质量。

如何开始：选择你最想解决的一个失败模式，用这个格式写 prompt：“Evaluate this LLM trace. Output only TRUE or FALSE. TRUE if [具体的失败条件], FALSE otherwise.” 列出所有你希望模型转人工的场景作为判断标准。然后用你已有的标注数据测量 judge 准确率——特别关注假阳性和假阴性率。

得到什么：一个可以自动化运行的测试套件，可以在每次代码变更时运行，确保核心功能没有被破坏。

建议四：降低你 eval 工具的使用门槛

为什么做：如果查看数据和运行评估太费事，你最终会放弃。

如何开始：用 AI 辅助工具快速构建一个简单的内部界面——只要能方便地浏览 trace、写笔记、统计错误分布就可以。Hamill 展示的案例就是 Nurture Boss 在几个小时内构建的内部工具，包含了不同渠道的对话列表和错误统计面板。你不需要一开始就做得很完美，关键是减少摩擦。

得到什么：让 error analysis 变成一种习惯性的、低成本的活动，而不是需要”特意安排时间”才能做的任务。

建议五：把 eval 框架放进你的开发流程

为什么做：eval 的价值不只是发现问题，更是防止问题再次出现。

如何开始：在你的 CI/CD 流程中加入 LLM judge 测试——每次代码变更时，自动运行针对核心失败模式的评估。把 eval 结果变成团队可见的指标，比如每周生成一次报告，展示各失败模式的发生率变化。

得到什么：当 eval 成为日常工作流程的一部分时，你会发现在它影响用户之前就能捕获和修复问题。产品质量的提升是可衡量、可追溯的。

我的总结

这次访谈是迄今为止关于 AI evals 最深入、最实用的入门指南。Hamill 和 Shrea 不仅仅是在教授一项技术技能，更是在传递一种思维方式：与其猜测你的 AI 产品是否正常工作，不如用系统化的方法去测量它；与其相信 AI 可以自我评估，不如让人类站在循环的中心。

他们的方法论有几个核心原则值得记住：先看数据，再写测试；先找问题，再想解决方案；用一个你信任的人来保持判断的一致性；用清晰的是非判断而不是模糊的评分；让评估框架自动化运行，但始终保持人类在回路中。

对于任何正在构建 AI 产品的人来说，这不仅仅是一门课程或者一个技能——这是一种让你的产品在竞争中脱颖而出的方式。当大多数人还在凭感觉做产品时，你已经有了一套科学的方法来确保每一次迭代都在正确的方向上。

📺 播客信息

  • 发布时间：2025-09-25
  • 时长：1小时46分钟33秒
  • 播放量：108811 次观看
  • 原版视频：『YouTube』