为什么 AI evals 是产品构建者最热门的新技能 | Hamel Husain & Shreya Shankar

Hamel Husain & Shreya Shankar 2025-09-25

为什么 AI evals 是产品构建者最热门的新技能 | Hamel Husain & Shreya Shankar

文字记录

Lenny Rachitsky： 要打造优秀的 AI 产品，你必须擅长构建 AI评估（evals）。这是你能从事的投资回报率最高的活动。

Hamel Husain： 这个过程非常有趣。每个做过这件事的人都会立刻上瘾。在构建 AI 应用时，你会学到很多东西。

Lenny Rachitsky： 这件事很酷的地方在于，你不需要反复做很多次。对大多数产品来说，你只需要完成一次这个过程，然后在此基础上构建就行了。

Shreya Shankar： 目标不是把 evals 做得完美，而是切实改进你的产品。

Lenny Rachitsky： 我没想到 evals 周围有这么多争议和风波。很多人持有非常强烈的观点。

Shreya Shankar： 人们过去在 evals 上吃过亏。他们做过效果不好的 evals，于是不再信任它，然后就变成了”哦，我反对 evals”。

Lenny Rachitsky： 关于 evals，人们最常见的几个误区是什么？

Hamel Husain： 最主要的一个是，“我们生活在 AI 时代，难道不能让 AI 自己来做评估吗？“但这行不通。

Lenny Rachitsky： 你在文章中用过一个我很喜欢的词——“仁慈独裁者”（benevolent dictator）。

Hamel Husain： 在做开放式编码时，很多团队会陷入委员会集体决策的泥潭。在很多情况下，这完全没有必要。你不想把这个流程搞得太昂贵以至于无法执行。你可以指定一个你信任其品味的人，应该是具有领域专业知识的人。通常，这个人选是产品经理。

嘉宾介绍与 evals 的崛起

Lenny Rachitsky： 今天我的嘉宾是 Hamel Husain 和 Shreya Shankar。过去一年里，这个播客上最热门的话题之一就是 evals 的兴起。Anthropic 和 OpenAI 的首席产品官都表示，evals 正在成为产品构建者最重要的新技能。从那以后，这成为了我邀请的众多顶级 AI 构建者口中反复出现的主题。两年前，我从未听说过 evals 这个词。现在它不断出现。上一次出现产品构建者必须掌握才能成功的新技能，是什么时候的事了？

Hamel 和 Shreya 在将 evals 从一个冷门、神秘的课题转变为 AI 产品构建者最必备的技能之一方面，发挥了重要作用。他们在 Maven 上教授最权威的 evals 在线课程，恰好也是 Maven 上排名第一的课程。他们已经教过来自 500 家公司的超过 2000 名产品经理和工程师，其中包括 OpenAI 和 Anthropic 的大量团队成员，以及其他所有主要 AI 实验室的人。

在这次对话中，我们会大量展示实操而非空谈。我们将逐步演示开发有效 eval 的流程，解释 evals 到底是什么、长什么样，讨论关于 evals 的主要误区，给出你可以立即开始为你的产品构建 evals 的最初几个步骤，并分享 Hamel 和 Shreya 过去几年积累的大量最佳实践。这期节目是关于 evals 世界最深入同时也最易懂的入门指南。说实话，它甚至让我对写 evals 产生了兴趣，尽管我根本没有什么需要写 evals 的东西。我想你看完之后也会有同样的感受。

如果这次对话让你兴奋起来，一定要去看看 Hamel 和 Shreya 在 Maven 上的课程。我们会在节目备注中附上链接。购买课程时使用优惠码 LENNYSLIST，可以享受 35% 的折扣。下面，有请 Hamel Husain 和 Shreya Shankar。

[广告已跳过]

Lenny Rachitsky： Hamel、Shreya，非常感谢你们来到这里，欢迎来到播客。

Hamel Husain： 谢谢你的邀请。

Shreya Shankar： 太兴奋了。

到底什么是 evals

Lenny Rachitsky： 我比你们更兴奋。好的，几年前我从未听说过 evals 这个词。现在它基本上是我播客上最热门的话题之一——要打造优秀的 AI 产品，你必须擅长构建 evals。而且事实证明，世界上一些增长最快的公司基本上就是在为 AI 实验室构建、销售和创建 evals。我之前刚请了 Mercor 的 CEO 来上播客。所以这里确实正在发生一件大事。我想通过这次对话帮助人们深入理解这个领域，但让我们从基础开始。到底什么是 evals？对于完全不知道我们在说什么的人，给我们一个快速的理解，什么是 eval？先请 Hamel 来说。

Hamel Husain： 好的。Evals 是一种系统化衡量和改进 AI 应用的方法，它完全不需要令人畏惧或遥不可及。它的核心其实就是对你的 LLM 应用做数据分析，以一种系统化的方式审视这些数据，必要时围绕各种事物创建指标，从而衡量正在发生的情况，然后据此迭代、做实验并改进。

Lenny Rachitsky： 这是一个非常好的宏观理解方式。如果再深入一层，给人们一个更具体的想象和可视化方式——如果你能展示一个例子就更好了——关于 eval 是什么，还有没有更深入的理解方式？

Hamel Husain： 假设你有一个房地产助手应用，它没有按你想要的方式工作——它没有按你的要求给客户写邮件，或者没有调用正确的工具，或者出现了各种错误。在 evals 出现之前，你只能靠猜。你可能会修改一个提示词，然后祈祷不会因此破坏其他东西，你可能依赖”感觉检查”（vibe checks），这完全没问题。

evals 不仅仅是测试

Hamel Husain： 感觉检查是好的，初期你应该做感觉检查，但它很快就会变得非常难以管理，因为随着应用的增长，仅凭感觉检查是很困难的。你会感到无所适从。而 evals 帮助你创建可以用以衡量应用表现的指标，在某种程度上给你一种自信改进应用的方式——你拥有一个可以据此迭代的反馈信号。

Lenny Rachitsky： 为了让大家更直观地理解，我们继续想象这个房地产助手的例子——也许它帮客户预约看房或者安排开放日参观。它的场景是这个助手在和客户对话，回答问题，引导他们做各种事情。作为这个助手的构建者，你怎么知道它给出的建议好不好？回答是否正确？它有没有在说完全错误的东西？

所以 evals 的核心理念，本质上就是构建一组测试，告诉你这个助手有多经常做出你不希望它做的事情。而”错误”的定义可以有很多种方式。可能是凭空编造信息，可能是以一种非常奇怪的方式回答。我对 evals 的理解——告诉我这么说对不对——简单来说就像是代码的单元测试。你在笑。你是不是在想，“不，你这个白痴。”

Shreya Shankar： 不，我不是那个意思。

Lenny Rachitsky： 好好好，那你说说，这个比喻你觉得怎么样？

Shreya Shankar： 好的。我同意你一开始说的，我们给出了一个非常宽泛的定义。Evals 是衡量应用质量的一个很大的光谱。单元测试确实是其中一种方式。也许你的 AI 助手有一些不可妥协的功能要求，单元测试可以检查这些。但与此同时，因为这些 AI 助手执行的任务非常开放，你还需要衡量它们在模糊或含混不清的事情上表现如何——比如应对新型用户请求，或者判断是否出现了新的数据分布，比如突然有新的用户群体开始使用你的房地产助手，而这些人你甚至没想到会使用你的产品。然后你会想，“哦，我需要用一种不同的方式来适应这个新用户群体。”

所以 evals 也可以是一种定期查看数据以发现这些新用户群的方式。Evals 也可以是你想要随时间追踪的指标，比如追踪用户说”是的，点赞，我喜欢这个回答”。这些非常基础的东西不一定与 AI 相关，但可以回到改进产品的飞轮中。所以总体来说，单元测试只是这个巨大拼图里很小的一部分。

Lenny Rachitsky： 太好了。你们实际上还带来了一个 eval 的具体例子，就是想给我们展示一下我们到底在说什么。我们一直在讲这些大概念。那不如我们拉出一个例子，让大家看看，“这就是一个 eval。“

真实案例：Nurture Boss

Hamel Husain： 好的，让我先稍微铺垫一下背景。呼应 Shreya 刚才说的，非常重要的是我们不要把 evals 仅仅等同于测试。很多人会掉进一个常见的陷阱——他们直接跳到写测试，“让我来写一些测试”，但通常这不是你应该做的。你应该从某种数据分析开始，以此为依据来确定你到底应该测试什么。这和传统软件工程有点不同，在传统软件工程中你对系统行为有更多的预期。而面对 LLM，表面积大得多，随机性很强，所以这里的情况有所不同。

今天我要给你们看的例子，正好是一个房地产的例子，不过是不太一样的那种。它来自一家叫 Nurture Boss 的公司。我可以分享一下屏幕，展示一下他们的网站，帮助大家理解这个用例，让我来共享屏幕。这是一家我合作过的公司，叫 Nurture Boss，它是一个面向物业管理人员的 AI 助手，帮助管理公寓，处理各种事务，比如潜在客户线索、客户服务、预约安排等等。物业管理人员日常可能做的各种运营工作，它都能帮忙。你可以看到他们做的事情。这是一个非常好的例子，因为它包含了现代 AI 应用的很多复杂性。

它有很多不同的交互渠道，比如聊天、短信、语音，同时还有工具调用——大量的工具调用，用于预约安排、获取可用信息等等。还有 RAG 检索，获取关于客户和物业的信息之类的。所以作为一个 AI 应用来说，它是相当完整的。他们非常慷慨地允许我使用他们的数据作为教学案例。我们已经做了匿名化处理，但今天我要带大家走一遍的是，好的，我们如何开始为 Nurture Boss 构建 evals。我们为什么需要做这件事？

让我们看看最开始的阶段，我们称之为错误分析（error analysis），也就是去看看他们应用的数据，首先搞清楚出了什么问题。我来跳到下一步，打开一个可观测性工具（observability tool）。这里你可以用任何你喜欢的工具。我只是碰巧把数据加载到了一个叫 Braintrust 的工具里，但你可以加载到任何工具中。在我们和你一起写的那篇博文里，我们没有偏好某个特定工具。我们有同样的例子但用的是 Phoenix Arize，我想 Aman 在他自己的博文里也用了 Phoenix Arize。还有 LangSmith。这些就是你可以使用的各种不同工具。

现在屏幕上显示的是应用的日志，让我给你们看看它是什么样的。让我把它全屏——这是某个客户与 Nurture Boss 应用的一次具体交互，它是一份详细记录了所有发生事情的日志。这叫做 trace，就是一系列事件日志的工程术语。Trace 这个概念已经存在了很长时间，但在 AI 应用领域它尤为重要。

我们在这里能看到 AI 完成其工作所需的所有不同组件、部分和信息，所有这些都被记录下来了，我们现在看到的就是这样一个视图。你看这里有一个系统提示词（system prompt）。系统提示词写的是，“你是一名 AI 助手，在 Retreat at Acme Apartments 担任租赁团队成员。” 记住我说过这是匿名化的，所以名字是 Acme Apartments。“你的主要职责是回复来自现有住户和潜在住户的短信。你的目标是提供准确、有用的信息，” 等等等等。然后还有很多关于我们希望它如何行为的详细指引。

Lenny Rachitsky： 顺便问一下，这是这家公司实际使用的系统提示词吗？

Hamel Husain： 是的，确实是。

Lenny Rachitsky： 太棒了，太酷了。

Hamel Husain： 这是真实的系统提示词。

Lenny Rachitsky： 太厉害了，因为你很少能看到一个真实的公司产品的系统提示词。那通常被视为他们的核心机密，所以这本身就非常酷。

查看真实的对话 trace

Hamel Husain： 对，真的很酷。你可以看到各种不同的功能用例，比如房源预约、处理申请、针对不同角色的沟通指引等等。你可以看到用户直接进来问：“你们有带书房的一居室吗？我在虚拟看房里看到的。“然后你可以看到 LLM 调用了一些工具——它调用了获取个人信息工具，把那个人的信息拉了出来。接着它又查询了社区的可租房源——也就是去查那个公寓楼的数据库，看有哪些房源可用。

然后 AI 回复说：“我们有几套一居室公寓可租，但没有专门标注带书房的。以下是一些选项。“接着用户说：“有一套带书房的了能通知我吗？“AI 回复说：“我目前没有关于一居室公寓带书房的具体房源信息。“用户说：“谢谢。“AI 说：“不客气，如果还有其他问题，随时联系我们。”

这是一个 trace 的例子，我们正在看的是其中一条具体的数据点。在做 LLM 应用的数据分析时，一件非常重要的事情就是——看数据。你可能会想：“这些日志量太大了，乱糟糟的，各种信息混杂在一起。到底该怎么看这些数据？难道要被数据淹没吗？怎么分析？“

错误分析（error analysis）方法

其实有一种完全可控的方法，而且这不是我们发明的，它在机器学习和数据科学领域已经存在很长时间了，叫做错误分析（error analysis）。具体怎么做呢？掌控这类数据的第一步，就是写笔记。你需要戴上产品经理的帽子——这也是为什么我们要和你聊这个话题，因为产品人员必须参与其中，亲自做这件事。通常开发人员并不适合做这件事，尤其是当这个应用不是编程类应用的时候。

Lenny Rachitsky： 我想复述一下，确认我理解了你的意思——你之所以这么说，是因为这就是你的产品的用户体验。用户和这个 agent 对话，本质上就是整个产品，所以产品经理深度参与这件事是完全合理的。

Hamel Husain： 对。那我们来审视一下这段对话。用户询问了房源可用性，AI 说：“哦，我们没有那种房型，祝您愉快。“对于一个做线索管理的产品来说，这算好吗？你觉得这是我们期望的结果吗？

Lenny Rachitsky： 不太理想。

Hamel Husain： 对，不理想，我很高兴你这么说。很多人会说：“哦，挺好的，AI 做得没错。它查了，说了没有可用的，确实没有嘛。“但如果你戴上产品经理的帽子，你就知道这样是不对的。所以你要做的就是在这里快速写一条笔记。你可能会进入这个界面，写一条备注——每个可观测性工具（observability tool）都支持写备注的功能。你不需要去判断到底是哪里出了问题——在这个案例中，它的行为确实不太对——你只需要快速写一句：“应该转交给人工处理。”

Lenny Rachitsky： 看着这个过程，就像你提到的这一点，后面还会进一步展开说明——你正在做的这件事，感觉非常手动、很难规模化，但正如你所说，这只是流程中的一步，背后有一套体系。这只是第一步。

Hamel Husain： 对，而且你不需要对所有数据都这么做。你抽样一部分数据看一看，做下来你会惊讶于自己能学到多少东西。每个这样做的人都会立刻上瘾，他们说：“这是构建 AI 应用时你能做的最有价值的事情。“你真的能学到很多，然后你会想：“嗯，这不是我想要它运行的方式，好吧。“这只是其中一个例子。

所以你写下这条笔记，然后我们可以看下一条 trace。这就是下一条 trace，我在键盘上按了个快捷键切过来的。

Lenny Rachitsky： 这些工具让你可以很方便地批量浏览并快速添加备注。

Hamel Husain： 对。这是另一条。类似的系统提示词（system prompt），我们不需要再过一遍了。直接跳到用户的问题。用户说：“我给你发了一整天短信了。“挺有意思的吧？用户说：“请……”好吧，这个案例其实是一个应用程序的错误——这是一个短信应用，准确地说是客户通过短信渠道进行沟通的，你会收到非常混乱的内容。你可以看到这里的对话基本上读不通，消息被截断了，比如”与此同时，“然后就断了，系统也不知道该怎么回复。因为大家发短信的方式就是那样，写很短的短语，一句话拆成四五条消息来发。

Lenny Rachitsky： 那遇到这种情况你怎么办？

Hamel Husain： 这是一种不同类型的错误。这更像是”我们没有正确处理这种交互”，是一个技术层面的问题，而不是”AI 没有按我们的要求去做”的问题。所以这个我们也要记下来。

Lenny Rachitsky： 能发现这种问题也真的很酷。

Hamel Husain： 对。

Lenny Rachitsky： 能在这里捕捉到这种问题太厉害了。否则你根本不知道这种情况在发生。

写笔记的原则：只记第一个错误

Hamel Husain： 对，你可能完全不知道发生了这种事。所以你就写一条备注：“由于短信渠道导致对话流程很 janky（混乱）。”

Lenny Rachitsky： 我喜欢你用了 janky 这个词。这说明这个阶段可以非常随意。

Hamel Husain： 对，就是要轻松随意，别想太多。这是有方法可循的。大家经常问的一个问题是：具体怎么做？你是要试图找出这条 trace 里所有的问题吗？到底该写什么？答案是——只写你看到的第一个问题，也就是最上游的那个错误。不要管其他所有错误，只抓住你看到的第一个问题，然后停下来，继续看下一条。你可以做得很快——前两三条可能会很痛苦，但熟练之后就能飞速处理。

幻觉问题的例子

再看这一条，系统提示词（system prompt）我们也跳过。用户问：“你好，我在找两到三居室，一到两个卫生间的，你们提供虚拟看房吗？”

然后调用了一堆工具，AI 回复说：“Hi Sarah，目前我们有一套三居室、两个半卫生间的公寓，租金 $2,175。不幸的是，目前没有两居室的选择。我们确实提供虚拟看房，您可以预约看房，“等等等等。但问题是，根本没有虚拟看房这个功能。

Lenny Rachitsky： 嗯，好。

Hamel Husain： 所以这是在编造一个不存在的东西——产生了幻觉。这时候你就需要带入你作为工程师或产品人员的上下文判断，说：“这个很奇怪。我们不应该告诉用户有虚拟看房，因为我们根本不提供这个服务。“

能用 LLM 自动做错误分析吗？

Hamel Husain： 所以你会说，“好的，推荐了虚拟看房”，然后直接写下这条笔记。你可以看到，我们发现的问题类型是多种多样的，而且我们实际上在很短的时间内就对你的应用了解了很多。

Shreya Shankar： 我们在这个阶段经常被问到的一个问题是，“好吧，我理解这是怎么回事了。能不能让 LLM 来替我做这个过程？”

Lenny Rachitsky： 嗯，好问题。

Shreya Shankar： 我很喜欢 Hamel 刚才举的最新例子，因为我们通常发现，当我们尝试让 LLM 来做这种错误分析时，它只会说这个 trace 看起来不错，因为它没有理解某个东西是否有产品层面的问题所需的上下文。比如刚才那个编造预约看房的幻觉，对吧？我敢保证，我愿意为此打赌——如果我把它放进 ChatGPT，问”有没有错误？“它会说，“没有，做得很好。”

但 Hamel 有上下文，他知道，“哦，我们其实没有虚拟看房这个功能。“所以我认为，在这种情况下，确保你自己亲手做这件事是非常重要的。我们稍后可以再谈谈在过程中何时使用 LLM，但这里的头号陷阱就是人们说，“让我用 LLM 把这个过程自动化。”

Lenny Rachitsky： 你觉得我们会不会走到这样一个阶段，一个 agent 能做这件事，具备那样的上下文？

Shreya Shankar： 哦，不会。不不不。抱歉。错误分析中确实有一些部分适合用 LLM 来做，我们稍后可以在播客中讨论。但现在这个自由形式、记笔记的阶段，不是 LLM 该介入的地方。

Lenny Rachitsky： 明白了。你把这个步骤叫做开放式编码（open coding），对吗？

Shreya Shankar： 没错，完全正确。

仁慈独裁者（Benevolent Dictator）

Lenny Rachitsky： 好的。你们在文章中用到的另一个我很喜欢的术语，也和这个步骤相关，就是”仁慈独裁者”这个概念。也许可以谈谈这是什么，Shreya 你来讲讲？

Shreya Shankar： 好的，这个词其实是 Hamel 发明的。

Lenny Rachitsky： 那还是 Hamel 来讲吧。

Hamel Husain： 没问题。而且我们实际上会在这个例子中展示 LLM 自动化，因为我们会用这个例子一路走到底。

Lenny Rachitsky： 太好了。

Hamel Husain： 所以”仁慈独裁者”只是一个比较醒目的说法，表达的是这样一个事实：在做这种开放式编码时，很多团队会被委员会式的工作方式拖慢。在很多情况下，这完全没有必要。人们会非常不安，觉得”我们需要所有人都参与进来，我们需要所有人的认可”之类的。你需要穿过这些噪音。在很多组织中，如果你深入观察，尤其是中小型公司，你可以指定一个你信任其判断力的人。你可以让很少的人来做这件事，通常一个人就够了。让这个过程可执行是非常重要的。你不能把这个过程搞得太昂贵以至于根本做不了，那样你就亏了。

这就是”仁慈独裁者”背后的理念——“嘿，你需要在尽可能多的维度上简化这件事。“我们稍后还会谈到另一个相关的事情：当你要构建一个 LLM 作为评判者时，你需要一个二元的评分。你不想去想”这是 1 分、2 分、3 分、4 分还是 5 分？“给它打个分。你做不到的，那会拖慢进度。

Lenny Rachitsky： 为了确保”仁慈独裁者”这个概念说得很清楚——基本上，这个人就是负责做笔记的，而且理想情况下他们应该是这个领域的专家。如果是法律相关的，可能是一个法务人员来负责；也可以是产品经理。给我们一些关于这个人应该是什么角色的建议？

Hamel Husain： 对，应该是具有领域专业知识的人。在这个案例中，就是了解公寓租赁业务、有上下文来判断这样做是否合理的人。就像你说的，始终是一个领域专家。如果是法律领域，就是法律专业人士。如果是心理健康领域，就是心理健康专家，可能是精神科医生或其他相关人员。

Lenny Rachitsky： 好的。

Hamel Husain： 不过很多时候，这个人是产品经理。

Lenny Rachitsky： 好的。所以建议就是：选定这个人。可能感觉不太公平——他一个人说了算，他是独裁者，但他是仁慈的。没关系的。

Hamel Husain： 对，没关系的。不需要追求完美。你只是想取得进展，快速获得信号，这样你就知道接下来该做什么，因为如果不小心的话，这件事的成本可以无限膨胀。

抽样多少条 trace 才够？

Lenny Rachitsky： 嗯，好的。我们回到你的例子。

Hamel Husain： 好的，没问题。这是另一个例子，有人说，“好吧，你们有什么优惠吗？“然后助手或 AI 回答说，“嘿，我们有 5% 的军人折扣。“用户接着回复，话题转换了，“能告诉我有多少层吗？你们有没有一居室？或者一楼有没有一居室？“AI 回答说，“好的，我们有几套一居室公寓。“用户想确认，“那些有在一楼的吗？一居室多少钱？“同时这是一个现有住户，所以还在问，“我需要提交一个维修请求。”

你可以在这里看到现实世界的混乱，而助手直接调用了一个工具说转接电话，但它什么都没说。就是突然执行了转接电话，所以我觉得这相当 janky。就是——

Lenny Rachitsky： 又一个 jank。

Hamel Husain： 另一种 jank，不同类型的 jank。所以当你写开放式笔记时，你不想只写”jank”，因为我们想要的是理解——当我们之后回顾这些笔记时，我们想要理解发生了什么。

所以你只需要写，“未与用户确认通话转接。“不需要完美，只要对发生了什么有个大概的了解就行。

Lenny Rachitsky： 好的。

Hamel Husain： 好的。假设我们做了——Shreya 和我建议至少做 100 条。大家总是问，“到底要做多少条？“这没有神奇的数字。我们说 100 条，只是因为我们知道，一旦你开始做这件事，做了 20 条之后，你会自动发现它太有用了，你会继续做下去。

所以我们说 100 条只是为了在心理上帮你解绑，让它不那么令人望而生畏。就像，“别担心，你只需要做 100 条。“这其实有一个术语，所以正确答案是，“持续查看 trace，直到你觉得自己学不到新东西了。“也许 Shreya 可以讲讲——

Shreya Shankar： 对，其实在数据分析和质性分析中有一个术语，叫做理论饱和（theoretical saturation）。它的意思是，当你做所有这些查看数据的过程时，什么时候停下来？就是当你达到了理论上的饱和——你不再发现新类型的笔记、新类型的概念，或者任何会在你流程的下一个阶段产生实质性改变的东西。

从开放式编码到轴向编码

Hamel Husain： 这种直觉需要一点时间来培养，所以通常人们并不真的知道自己什么时候达到了理论饱和。这完全没问题。当你做了两三个例子或两三轮之后，你就会逐渐培养起这种直觉。很多人会意识到，“哦，好吧，我只需要做 40 条，只需要做 60 条。其实我只需要做 15 条。“因情况而异，也取决于你对错误分析（error analysis）的熟练程度，这是肯定的。

Lenny Rachitsky： 你说的”你会想要做很多条”，我猜是因为你会觉得，“哦，我发现了这么多问题，我得看看还有什么别的。”

Shreya Shankar： 没错。

Lenny Rachitsky： 是这样吗？

Shreya Shankar： 而且我保证，到了某个点之后，你就不会再发现新类型的问题了。

Lenny Rachitsky： 好的。假设你做了 100 条，下一步是什么？

Hamel Husain： 好，你做了 100 条，现在你有了所有这些笔记。这时候你可以开始用 AI 来帮你了。正如我们讨论过的，亲自查看数据这个环节很重要，你不想把这个部分过度自动化。

Lenny Rachitsky： 人类还是会有工作的。这是关键结论。太好了。

Hamel Husain： 是的。

Lenny Rachitsky： 就是审查 trace。至少目前还剩这一份工作。很好。

基础计数——最强大的分析技术

Hamel Husain： 对。好，你现在有了所有这些笔记。要把它变成有用的东西，你可以做基础计数。基础计数是数据科学中最强大的分析技术，因为它如此简单，而且在很多情况下被低估了，所以对人们来说非常容易上手。

所以你要做的第一件事就是拿着这些笔记，用 LLM 对它们进行分类，方法有很多种。就在录这期播客之前，我试了三种不同的编程代理或 AI 工具来给这些笔记分类。一种是，我把一个包含这些笔记的 CSV 上传到了一个 Cloud 项目里，直接从这个界面导出。方法有很多，但我展示的是最简单、最笨的方式，最基础的做法。

我把 CSV 丢进去，然后说”请分析以下 CSV 文件”。我告诉它有一个元数据字段包含笔记内容，但我用的是”open codes”（开放式编码）这个词，我说”我有不同的 open codes”，这是一个专业术语。LLM 知道什么是 open codes，也知道什么是 axial codes，因为这是一个存在了很久的概念，所以这些词能帮我快速表达我想要做的事。

Lenny Rachitsky： 太好了。prompt 的末尾是让它创建 axial codes？

Hamel Husain： 对。创建 axial codes，它的作用是——

Shreya Shankar： 也许值得讲讲什么是 axial codes，目的是什么？你面对的是一堆混乱的 open codes，你并没有 100 个不同的问题。实际上很多是重复的，只是因为你的措辞不同。而且你不应该在开放式编码的时候就去创建自己的失败分类体系。你只需要把问题记下来，然后再去整理，“好，最常见的失败模式是什么？”

所以 axial code 的目的基本上就是一个失败模式。它是一个标签或类别。我们的目标是得到这些失败模式的聚类，找出哪个最普遍，这样你就可以着手去解决那个问题。

Lenny Rachitsky： 这真的很有帮助。基本上就是把所有这些——

Shreya Shankar： 完全正确。

Lenny Rachitsky： 综合成类别和主题。非常酷。我们会把这个 prompt 放在节目说明里，这样大家就不用坐在那里截图然后自己手敲了。

Hamel Husain： 好主意。然后 Claude 分析了 CSV 文件，决定如何解析，等等这些细节我们不用操心，但它给出了一堆 axial codes。正如 Shreya 所说，axial codes 基本上就是类别。比如，能力限制、错误陈述、流程和协议违规、人工交接问题、沟通质量。它创建了这些类别。

我喜不喜欢所有这些类别呢？并不完全喜欢。我喜欢其中一些。这是一个不错的初步尝试。我可能会给它改改名，因为有些太笼统了。比如”能力限制”是什么意思？有点太宽泛了，不具有可操作性。我想让它更具可操作性，这样如果我确定它是个问题，我就知道该怎么处理它。不过这个我们稍后再讨论。你可以用任何工具来做这件事，这是最笨的方法，但有时候笨方法正是一个好的起步方式。

Lenny Rachitsky： 而这正是 LLM 真正擅长的事情——把大量信息拿来并综合提炼。

Shreya Shankar： 完全同意。帮我们综合提炼，让我们能够理解，对吧？注意，它并不是自动提出修复方案或做什么，那是我们的工作，但现在我们可以更轻松地梳理这堆混乱的 open codes 了。

灵活定制轴向编码的 prompt

还有一点很有趣，在这个生成 axial codes 的 prompt 中，你可以非常详细地指定。你可以说”我希望每个 axial code 实际上是一个可操作的失败模式”，也许 LLM 会理解并据此提出建议。或者你说”我希望你按照用户故事的阶段来对这些 open codes 分组”。这就是你可以发挥创意的地方，或者作为产品经理或工程师做最适合你的事情，这将帮助你后续进行改进。

Lenny Rachitsky： 所以并没有一个终极的 prompt，“这就是唯一正确的方法”？

Shreya Shankar： 完全没有。

Lenny Rachitsky： 你是说可以迭代，看什么适合自己？

Shreya Shankar： 完全正确。

Lenny Rachitsky： 有意思的是现有工具不做这件事，还是说它们尝试了但做得不好？

Shreya Shankar： 不，我觉得它们没做这件事。我们一直在到处呼吁，“拜托，拜托——”

Lenny Rachitsky： 哦，真的吗。

Shreya Shankar： “请做这件事吧。“不过我确实觉得这有点难。Hamel 和我教的 eval 课程中的经验之一是，很多人其实不知道这些，所以也许是人们不知道，也就不知道如何为此构建工具。希望我们能揭开这层神秘面纱。

Lenny Rachitsky： 再深入聊一下这一点，这不是所有人都知道或都在做的事情。这是你们两位基于在其他公司做数据分析和数据科学的经验发展出来的？

方法论的根基

Shreya Shankar： 我想说明的是，我们没有发明错误分析（error analysis）。我们其实不想发明新东西。那是不好的信号。如果有人带着一种全新的、不是建立在数百年理论和文献基础上的方法来找你，那你应该——我不知道，稍微警惕一点。

但我们努力做的是提炼出，“好，要理解 LLM 的错误分析，你需要哪些新的工具和技术？“然后我们创建了一套课程或结构化的方法来做这件事。所以这些都是针对 LLM 的，但 open coding、axial coding 这些术语是植根于社会科学的。

Lenny Rachitsky： 太棒了。好吧，你们做这件事有意思的地方在于，我也想找个地方去做这件事。我手头没有任何 AI 产品可以拿来练手，但就是觉得，“这太有意思了。“坐在那里找出所有遇到的问题，给它们分类，然后尝试修复。

Shreya Shankar： 我太喜欢这种想法了。

Lenny Rachitsky： Hamel 打开了一个视频。你这里展示了什么？

Hamel Husain： 对。我打开了一个视频，就是为了进一步印证 Shreya 的观点。我们并没有发明任何东西。你在屏幕上看到的是 Andrew Ng，世界上最著名的机器学习研究者之一，说实话，他教会了很多人机器学习。你可以看到这是一个八年前的视频，他在讲错误分析（error analysis）。这是一种用于分析随机系统的技术，已经被使用了很长时间了。这里用的就是同样的机器学习思想和原则，只是把它们搬到了这里，因为同样，这些也是随机系统。

实操演示：工具与流程

Lenny Rachitsky： 太好了。顺便说一下，我们正在邀请 Andrew 上播客，正在沟通，到时候——

Shreya Shankar： 太好了。

Lenny Rachitsky： ……那会非常有趣。另外，我很高兴我的播客节目今天刚发布就出现在了你们的推荐流里，而且在那个流里特别显眼，我真的很开心。

Hamel Husain： 非常好。是的。推荐算法相当不错。

Lenny Rachitsky： 没错。来吧，希望你们点进去。别搞砸我的算法。好的，酷。我们已经做了一些综合整理。我知道我们不会把整个流程走一遍——你们有一整套课程，需要好几天才能学完整个过程。关于如何开展这个流程，你们还想分享什么？

Hamel Husain： 好的。你可以用任何工具来做这件事，在 ChatGPT 里用完全相同的提示词也完全可以。你可以看到它生成了轴向编码（axial coding）。我个人很喜欢用 Julius AI，这是我最喜欢的工具之一。Julius 是一种使用 notebook 的第三方工具。我个人很喜欢 Jupyter notebook，所以这更偏数据科学的风格。不过现在很多产品经理也在学用 notebook，挺酷的。它就像一个好玩的游乐场，你可以在里面写代码、看数据。但我们不需要深入讲这个。只是想提一下，你可以用很多工具。AI 在做这件事上真的很擅长。

好，让我们进入有趣的部分。来了。现在我们有了这些轴向编码（axial codes）。我拿到这些开放式编码（open codes），以及我们在 Cloud 项目或 ChatGPT 中生成的轴向编码。我做的第一件事是先收集它们，然后看看：“这些轴向编码合理吗？“我会查看不同轴向编码和开放式编码之间的对应关系，然后做一个审视，说：“嗯，我喜欢这些编码吗？能不能做得更好？能不能更精细化？能不能让它们更具体？“与其使用笼统的编码，不如把它们做得非常具体和可操作。你们看我在这里提出的编码：行程调度、重新调度问题、人工转接或移交问题、输出格式错误、对话流程——我们之前在短信那条中看到了对话流程问题、做出的跟进承诺未兑现。

基本上，我现在能做的——你能做的——就是拿到这些轴向编码，把它们收集成一个列表。这是一个 Excel 公式，把这些编码收集成一个列表，现在我们就有了一个逗号分隔的编码列表。然后你可以简单地拿你的那些笔记——那些开放式编码——告诉一个 AI——这里用的是 Gemini，只是为了简便——再说一次，我们尽量保持简单——“将以下笔记归类到以下类别之一。”

Lenny Rachitsky： 给观看的人说一下，我很喜欢你分享的这些不同的提示词和公式。这是 Google Sheets 的 AI 提示词。

Shreya Shankar： 超级粉丝。

Hamel Husain： 基本上，你可以把你的 trace（追踪日志）分类到这些类别之一，这就是我们这里做的。我们把遇到的所有问题都分类到了这些类别里。

Shreya Shankar： 而且这是自动的，非常令人兴奋。我是说，AI 在做这件事。所以这也印证了一个要点——你的开放式编码（open codes）必须是详细的，对吧？你不能只写 janky，因为如果 AI 读到 janky，它没法进行分类。即使是人也做不到，对吧？它得回去回忆你为什么说 janky。所以在开放式编码中保持一定的详细程度是很重要的。

Lenny Rachitsky： 好的。所以避免使用 janky 这个词。这是一条很好的经验法则。

Shreya Shankar： 对。或者至少配上其他十个词。

Lenny Rachitsky： 哦，好的。那——

Hamel Husain： 我当时是在开玩笑。

Lenny Rachitsky： 哈哈，好吧。人们常用的、你觉得不太好的词还有哪些？

Shreya Shankar： 我觉得不是具体的某个词的问题。我认为只是人们在开放式编码中写得不够详细，所以很难进行分类。

Lenny Rachitsky： 明白。顺便说一下，之所以需要把它们映射回去，是因为比如说 Claude 或 ChatGPT 给了你建议，你做了修改和迭代，所以你不能直接回头说”好，随便放进哪个桶里”就完了，对吧？

Hamel Husain： 对，对。

Lenny Rachitsky： 好的。

Hamel Husain： 这个问题其实问得很好。去迭代、去想一想——“我喜欢这些开放式编码吗？这些对我来说真的合理吗？“——这很重要。就像 AI 做的任何事情一样，把自己放在中间稍微把控一下总是好的。

Lenny Rachitsky： 人还在回路中。仍然有我们的用武之地。好的。

Shreya Shankar： 如果我在用 AI 来做这个标注，这步中我喜欢做的一件事是，也设一个叫做”以上都不是”的新类别。这样 AI 可以实际回答”以上都不是”作为轴向编码，这就告诉我：“好吧，我的轴向编码不完整。让我回去看看那些开放式编码，搞清楚需要哪些新类别，或者如何重新措辞其他轴向编码。”

Lenny Rachitsky： 太棒了。而且这件事很酷的地方在于你不需要重复做很多次。

Shreya Shankar： 不需要。

Lenny Rachitsky： 对于大多数产品，你做一次这个流程，然后在它的基础上构建，我猜是这样的，之后就是随着时间推移不断微调？

Shreya Shankar： 完全正确。而且速度非常快。人们每周做一次，整个过程三十分钟就能完成，突然之间你的产品就比从不了解这些问题的情况好太多了。

Lenny Rachitsky： 对。想到你竟然不知道正在发生这些事情，简直荒谬。看到这个过程，我就想，“你怎么能不对自己的产品做这件事？”

Shreya Shankar： 很多人完全不知道。

Lenny Rachitsky： 大多数人。是的。我们会聊到这个。关于这些内容有一整场争论值得讨论。好的，酷。你有了这个表格。接下来是什么？

Hamel Husain： 好的。现在是重大揭晓时刻。这就是神奇的瞬间。我们已经把所有这些我们认可的编码应用到了我们的 trace（追踪日志）上。现在，你可以做那个”当当当当”了——你可以开始计数了。

从数据透视表到 AI评估（evals）

Hamel Husain： 这里有一个数据透视表，我们可以直接对这些编码做数据透视表，统计不同类别的出现次数。那我们发现了什么？在我们已经分类的这些 trace（追踪日志）上发现了什么？我们发现了 17 个对话流程问题。我非常喜欢数据透视表，因为你可以做很多很酷的事情。你可以双击这些数字往里钻取。你可以说，“哦，好吧，让我看看这些具体情况。“不过这是关于数据透视表有多酷的题外话了。

但现在我们有了一个很好的、粗略的分类——我们的问题到底有哪些？我们从混乱走向了某种有结构的思考，“哦，你知道吗？这些是我最大的问题。我需要修复对话问题，也许是这些人工转接问题。“不一定是最多的那个计数最重要，也许某个问题数量不多但非常严重，你想先修复它，但总之，现在你有了一种审视问题的方式，然后你可以考虑是否需要为其中一些问题编写 evals。

其中有些问题可能只是低级工程错误，你不需要为此编写 eval，因为修复方式非常明显。也许是输出格式错误，也许你只是忘了告诉 LLM 你希望它以什么格式输出，甚至在 prompt 里都没提过。那就直接去修改 prompt 好了。然后我们可以决定，“好吧，你要为此写一个 eval 吗？“你可能还是想写一个 eval，因为也许你可以用纯代码来测试。你可以直接检查字符串，看它是否具有正确的格式。不需要运行 LLM。

所以 evals 是有成本收益权衡的。你不想在这方面走火入魔，但你通常要立足于你实际的错误来行动。你不想跳过这一步。我之所以在这上面花这么多时间，是因为人们往往在这里迷失方向。他们直接跳到 evals——“让我写一些测试吧”——然后事情就失控了。

如何选择问题并构建评估

好的。假设我们想解决其中一个问题。比如说，我们想解决这个人工转接的问题，我们会想，“嗯，我不太确定怎么修复这个。这是一个比较主观的判断——到底应不应该转接给人工？我不能立刻知道怎么修复。这本身不是特别明显。是的，我可以修改 prompt，但我不确定。我没有百分之百的把握。”

那么，这可能就适合用 LLM 作为评判者来处理。evals 有不同类型。一种是基于代码的，如果你能做到的话应该尽量用这种，因为成本更低。LLM 作为评判者是另一种，它相当于一种元评估。你必须对这个 eval 本身再进行评估，以确保担任评判者的 LLM 确实在做正确的事，这个我们一会儿会讲。

好的。LLM 作为评判者，这是一种方式。那你怎么构建一个 LLM 作为评判者呢？

Lenny Rachitsky： 在我们进入这个话题之前，为了确保大家完全理解你刚才描述的这两种 evals——一种是你说的基于代码的，一种是 LLM 作为评判者——也许 Shreya，你帮大家理解一下基于代码的 eval 到底是什么？本质上就是一个单元测试？这是最简单的理解方式吗？

Shreya Shankar： 对。也许”eval”这个词在这里不是最准确的，但可以把它想成自动评估器。当我们发现这些失败模式后，我们想要的是，“好吧，现在我们能不能以自动化的方式检查这个失败模式的发生率——不需要我手动打标签、做所有编码和分组工作——我想在成千上万的 trace 上运行它，我想每周都运行。“这就是说，你应该构建一个自动评估器来检测那个失败模式。

当我们说基于代码还是基于 LLM 时，我们的意思是，“好吧，也许我可以写一个 Python 函数或一段代码来检查某个 trace 中是否存在那个失败模式。“这对某些事情是可行的，比如检查输出是否为 JSON，或者是否为 markdown，或者是否足够简短。这些都是可以用代码捕获的，或者至少可以近似地用代码捕获。

当我们在这里谈论 LLM 评判者时，我们说的是这是一个复杂的失败模式，我们不知道如何以自动化方式评估。所以也许我们会尝试使用一个 LLM 来评估人工转接这个非常非常狭窄、特定的失败模式。

Lenny Rachitsky： 所以让我试着复述一下你描述的内容——你想测试你的 agent 或 AI 产品的表现。你向它提一个问题，它返回一个结果。

一种测试它是否给出正确答案的方式是：如果它持续做同一件事，你可以写一段代码来判断结果是对还是错。比如，它会不会说有虚拟看房？你可以问它。

Shreya Shankar： 是的。

Lenny Rachitsky： “你们提供虚拟看房吗？“它回答是或否，然后你可以写代码根据那个具体答案来判断是否正确。

但如果你问的是更复杂的问题，而且不是二元的——一种情况下你需要人类来告诉你这是否正确。为了避免人类每次都要手动审核所有内容的解决方案，就是让 LLM 替代人类做判断，你把它叫做 LLM 作为评判者。LLM 作为判断这个结果正确与否的评判者。

Shreya Shankar： 完全正确。你总结得很好。

Lenny Rachitsky： 太好了。

Shreya Shankar： 所以人们总是觉得，“哦，这至少和创建原始 agent 的问题一样难。“其实不是，因为你让评判者做一件事——评估一个失败模式——所以问题的范围非常小，而且这个 LLM 评判者的输出就是通过或不通过。所以这是一个非常非常紧凑的范围，LLM 评判者在这种任务上非常可靠地执行。

Lenny Rachitsky： 这里的目标就是拥有一套测试套件，在你上线发布之前运行，告诉你一切是否按照你期望的方式进行？你的 agent 的交互方式是否正确？

Shreya Shankar： LLM 评判者的美妙之处在于，你当然可以在单元测试或 CI 中使用它们，但你也可以在线上用于监控，对吧？我可以每天抽样 1000 条 trace，运行我的 LLM 评判者——真实的线上 trace——看看那边的失败率是多少。这不是单元测试，但我们现在仍然获得了一个极其具体的应用质量指标。

Lenny Rachitsky： 酷。这一点真的很棒，因为很多人只把 evals 看作这种非真实世界的东西——你在它进入真实世界之前测试的东西。而你说的是，在真实世界中实际运行的东西，你也应该对它做同样的事情？

Shreya Shankar： 对。

Lenny Rachitsky： 测试你真实运行在生产环境中的东西？而且可以是每天、每小时运行的那种？

Shreya Shankar： 完全可以。

Lenny Rachitsky： 太棒了。好的，Hamel 这里有一个实际的 LLM 作为评判者的 eval 示例，我们来看看。

LLM 作为评判者的实际示例

Hamel Husain： 我很喜欢 Shreya 帮我把铺垫都做好了，非常感谢。所以我们这里有的是一个针对某一个特定失败的 LLM 评判者 prompt。正如 Shreya 所说，你应该针对一个特定失败来做，而且你要让它变成二元的，因为我们想简化事情。我们不想说，“嘿，给它打一到五分。有多好？“在大多数情况下，那只是一种不願做决策的模棱两可做法。不，你需要做一个决定。这够好吗？是或不是？

Hamel Husain： 要具体想清楚这个标准是什么可能很痛苦，但你绝对应该去做。否则这件事会变得非常难以处理，而且当你汇报这些指标时，没人知道 3.2 和 3.7 意味着什么。

Shreya Shankar： 是的，这种情况我们也一直看到，甚至在网上那些专家精心策划的内容里也是这样，比如”哦，这是你的 LLM 评判者 eval prompt。这是一个一到七分的量表。“我总是会发消息给 Hamel 说，“哦不，我们又得去对抗错误信息了，因为我们知道肯定会有人去尝试，然后回来找我们说，‘哦，我的平均分是 4.2，‘“我们就只能，“好吧。”

Lenny Rachitsky： evals 领域的戏剧性真的太多了。我们后面会聊到这个。天哪。

（以下为广告段落，已跳过）

构建评判者 prompt 并与人工标注对齐

Hamel Husain： 好的，所以这就是你的评判者 prompt。做这件事没有唯一正确的方法。用 LLM 来帮你创建它是可以的，但同样，要让自己参与到其中。不要盲目接受 LLM 的输出。在我们展示的所有案例中，我们都是这么做的。用轴向编码的时候，我们对它进行了迭代。你可以用 LLM 来帮你创建这个 prompt，但要确保你读了它、编辑了它，该做的都做了。这不一定是完美的 prompt。这只是一个保持非常简单的示例，只是为了给你展示这个思路。就像，“好的，针对这个交接失败，“我说，“好的，我要你输出 true 或 false，“这是一个二元评判者。这就是我们推荐的。然后我就一条条列出来，“好的，什么情况下应该做交接？”

比如，明确的人类请求被忽略或循环了，某种政策要求的转接，敏感的住户问题，工具数据不可用，当天预约看房或参观的请求。这些你需要跟真人谈，诸如此类。核心思路是，既然我从数据中知道这是一个失败，我就想对它进行迭代，因为我知道这种情况实际上一直在发生。正如 Shreya 所说，如果能有一种方式，不仅能在我已有的数据上评估这个，还能在生产数据上评估，那就更好了，这样可以了解这个问题的规模有多大。让我找到更多的 trace，让我有一种方式来迭代这个。我们可以拿这个 prompt，然后我再用电子表格。第一步是，当我做这个评判的时候……我写好了 prompt。

现在，很多人到这一步就停了，他们说，“好的，我有我的评判者 prompt 了。搞定了，上线吧，“然后如果评判者说是错的，那就是错的。他们直接把它当作真理接受，“好吧，LLM 说是错的，那肯定就是错的。“不要这样做，因为这是让你的 evals 和实际情况不匹配的最快方式。当人们对你的 evals 失去信任时，他们对你也失去信任。非常重要的是你不能这样做，所以在你发布你的 LLM 作为评判者之前，你要确保它和人类判断是对齐的。怎么做呢？你有那些轴向编码，你要把你的评判者跟轴向编码对比，说，“嘿，它同意我吗？我自己的评判者，它同意我吗？“直接去测量。

我们这里展示的是，好的，我说，“评估这个 LLM trace。“同样，我这里只是在用电子表格，“根据这些规则评估这个 LM trace，“而规则就是我刚才给你看的那个 prompt。我问它，“好的，是否存在交接错误，true 还是 false？“然后这一列，让我放大一点。H 列是，“好的，这个错误发生了吗？“G 列是我认为错误是否发生了。你可以看到——

Lenny Rachitsky： 你是手动过了一遍，你做了那个工作。

Hamel Husain： 是的是的，而且我们已经做过了。我们已经手动过了一遍。这不是说我们还得重新做，因为有了轴向编码这个”作弊码”，我们已经做过了。如果你需要更多数据，你可能需要再过一遍，这里面有很多关于如何正确操作的细节。你需要拆分你的数据，做所有这些事情，这样你不是在作弊，但我只是想给你展示这个概念。基本上，你可以测量一致性。现在有一件事你应该知道，作为产品经理，很多人会直接看这个一致性。他们说，“好的，我的评判者在某个百分比的时间里和人类一致。”

这听起来很诱人，但它是一个非常危险的指标，因为很多时候，错误只发生在长尾上，不那么频繁，所以如果你的错误只有 10%，那么你的评判者只要一直说通过，就能轻松达到 90% 的一致性。这说得通吗？90% 的一致性在纸面上看起来很好，但可能会误导人。

Lenny Rachitsky： 因为错误很少见，是的。

检查评判者的一致性矩阵

Hamel Husain： 作为产品经理，或者即使你自己不做这个计算，如果有人向你汇报一致性，你应该立刻追问，“好的，给我说说更多细节。“你需要深入去看。他们给你更多直觉的方式是这样的，这里是这个特定评判者在 Google 表格中的矩阵，这同样是一个数据透视表，保持简单笨拙就好。“好的，行上是人类怎么想的？我怎么想的？有没有错误，true 还是 false？然后我的评判者有没有报错误，true 还是 false？”

Shreya Shankar： 这里的直觉和 Hamel 说的一样，你需要去看每种类型的错误。当人类说 false 但评判者说 true 的情况，或者反过来，就是那些非绿色的对角线单元格。如果它们太大了，就去迭代你的 prompt，让 LLM 评判者更清楚地理解，这样你就能减少那种不对齐。你要达到一个程度，大多数情况下……你总会有一些不对齐的，这没关系。我们在课程里也会讲如何用代码来纠正那种不对齐，但在现阶段，如果你是一个产品经理，而构建 LLM 评判者 eval 的人没有做这一步，他们说”75% 的时候一致，我们没问题”，但他们没有这个矩阵，也没有迭代来确保这两种类型的错误已经降到接近零，那就是一个不好的信号。去要求他们把它修好。

Lenny Rachitsky： 太棒了。这是一个非常好的建议，知道当别人做错这件事时该注意什么。

Shreya Shankar： 是的。

evals 就是新的 PRD

Lenny Rachitsky： 其实，能不能带我们回到那个 LLM 作为评判者的 prompt？我想特别强调其中一个非常有趣的地方。最近我播客上的一些嘉宾一直在说，“AI评估（evals）就是新的 PRD”，你看看这个，就完全是这样。产品经理、产品团队，这就是产品应该是什么样，这是所有的需求，这是它应该如何运作。他们构建了一个东西，然后去测试它，通常是手动的。而这个做法的精妙之处在于，它做的完全是同一件事，而且在持续运行。它告诉你，“这个 agent 应该这样回应”，而且是非常具体的方式——“如果是这样、这样、这样，就那样做；如果是这样、这样、那样，就那样做。“这正是我一次又一次听到的东西，你现在可以直接看到。这就是产品需求文档最纯粹的形式——这个 eval 评判者准确地告诉你产品应该是什么样，而且是自动化的、持续运行的。

Shreya Shankar： 对，完全同意。它是从我们自己的数据中推导出来的，当然就是产品经理的期望。我发现很多人忽略的一点是，他们只是把自己在看数据之前就有的期望放进去，但随着我们看数据的过程，我们会发现更多一开始根本想象不到的期望，这些最终也会加入到这个 prompt 中。

Lenny Rachitsky： 这很有意思。你的建议是不是说，在构建产品之前不要跳过 evals 和 LLM 作为评判者的 prompt，仍然要写传统的单页 PRD 来告诉团队我们在做什么、为什么做、成功的标准是什么。但到最后，你可以从中提取内容，如果你在用这个流程迭代产品，甚至可以改进原来的 PRD。

Shreya Shankar： 我会再推进一步，说你会改进……它会变的。你永远不可能提前知道失败模式会是什么，你总是会发现自己认为产品应该有的新的感觉。在这些 LLM 面前，你不知道自己想要什么，直到你亲眼看到它。所以你必须保持灵活，必须看你的数据，必须……PRD 是思考这些问题的一个很好的抽象工具。但它不是终极答案。它会变的。

Lenny Rachitsky： 我很喜欢这个观点。Hamel 正在打开一份很酷的研究报告。这是关于什么的？

Hamel Husain： 如果你想了解 evals，这是你能读到的最酷的研究报告之一。它的作者是一位叫 Shreya Shankar 的人。

Shreya Shankar： 天哪。

Hamel Husain： 还有她的合作者。题目叫”Who Validates the Validated?”

《Who Validates the Validated?》研究与评判标准漂移

Lenny Rachitsky： 这真是最适合研究者的名字。

Shreya Shankar： 谢谢，谢谢。

Hamel Husain： 我应该让 Shreya 来谈这个。我认为这篇论文中最值得关注的一点是评判标准的漂移（criteria drift），以及她的发现。

Shreya Shankar： 我们做了一个超级有趣的研究，当时我们在对一些用户做调研，这些用户正在尝试写 LLM 评判者或者只是验证自己的 LLM 输出。我觉得那时候 evals 在互联网上还没有像后来那么流行。我们大概在 2023 年底开始这个项目。但作为研究者，我脑海中一直在燃烧的一个问题是，“为什么这个问题这么难？我们搞机器学习和 AI 已经这么久了，不是什么新东西，但这一次，突然一切都变得非常困难。“我们就对一群开发者做了这个用户研究，然后我们意识到，“好吧，新的地方在于你没法提前确定你的评判标准。人们对好和坏的看法会随着他们审查更多输出而改变，他们只有在看了 10 个输出之后才会想到一些一开始完全想不到的失败模式，“而这些人是专家。这些人之前已经构建过很多 LLM 流水线，现在又构建了 agent，你根本不可能一开始就把所有东西都想全。我认为这是当今 AI 开发世界中最关键的一点。

Lenny Rachitsky： 这个观点真的很好。这完全印证了我们刚才讨论的内容，所以我把这个拿出来，就是……好的——

Shreya Shankar： 这背后的研究支撑。

Lenny Rachitsky： 对，好的，很好。你还是要用同样的方式做产品，但现在你有了一个非常强大的工具来帮你确保你构建的东西是正确的。它不会取代 PRD 流程。好的。那一般来说，你们最终会有多少个 LLM 作为评判者的 prompt？我知道这显然取决于产品的复杂度，但根据你的经验，大概是什么数字？

Shreya Shankar： 对我来说，四到七个之间。

Lenny Rachitsky： 就这些？

Shreya Shankar： 没那么多，因为正如 Hamel 早先说的，很多失败模式可以通过直接修改你的 prompt 来解决。你只是没想到把它放到你的 prompt 里，所以现在你把它放进去……你不应该对所有事情都做这样的 eval，只针对那些你已经在 agent prompt 中描述了理想行为、但它仍然出问题的顽固问题。

Lenny Rachitsky： 明白了。假设你发现了一个问题，你修复了它。在传统软件开发中，你会写一个单元测试来确保它不再发生。你这里的洞见是，“如果问题已经解决了，甚至都不用费心为它写 eval”？

Shreya Shankar： 我认为如果你想写也可以，但整个游戏的核心是关于优先级排序。你的资源和时间都是有限的，你不可能为所有事情都写 eval，所以优先处理那些更顽固的领域。

Lenny Rachitsky： 大概是那些对你的业务风险最大的情况，比如说了什么 Mecha Hitler 之类的，Grok。

Shreya Shankar： 天哪。

Lenny Rachitsky： 好的。这很让人松一口气，因为这个 prompt 要把所有这些细节想清楚确实很费功夫。

Shreya Shankar： 但这是一次性的投入。从现在起，你可以永远在你的应用上运行它。

数据分析的进阶

Hamel Husain： 好的，数据分析是非常强大的，会非常快速地推动你的应用的大量改进。我们展示了最基本的数据分析，也就是计数，这对所有人都是可用的。你可以在数据分析上做得更精细。有很多不同的方法来抽样、查看数据。我们让它看起来很简单，但实际上要做好需要很多技能。要建立一种直觉和嗅觉，知道如何筛选这些数据。比如说，我发现了对话问题，这种对话流程的问题。如果我想要进一步追踪这个问题，我会想办法找到其他我还没有编码的对话流程问题。我可能会用多种方式深挖数据，有不同的方法来做这件事。这非常类似于，甚至几乎完全类似于你在任何产品上会做的传统分析技术。

Lenny Rachitsky： 简单给我们一个接下来内容的概览，然后我们来聊聊关于 evals 的争议以及其他几件事。

LLM 评判者的后续应用

Shreya Shankar： 建好 LLM 评判者之后接下来做什么？我们发现大家会尽量把它用在所有能用的地方——把它放进单元测试里，然后构建出这样的流程：“这里有一些我们观察到的出现故障的 trace 示例，因为我们已经标注过了。现在我们要把它们纳入单元测试，确保每次推送代码变更时这些测试都能通过。“他们还会把它用于线上监控。大家基于此制作仪表盘，我觉得这非常了不起。那些正在这样做的产品团队，对自己应用的运行状况有着非常敏锐的感知。但人们不会去谈论这些，因为这是他们的护城河。人们不会去分享所有这些东西，因为这是合理的。如果你是一个邮件写作助手，你在这方面做得很好，你肯定不希望别人也去做一个邮件写作助手，然后把你挤出市场。

我真的很想强调一点：尽量把你构建的这些产物在线上尽可能多的地方使用，反复利用它们来推动产品改进。很多时候，Hamel 和我会教大家一路做到这一步，然后大家就豁然开朗了，之后就不再回来了。要么是他们——我不知道——辞职了、不再做 AI 开发了，要么是他们从这一步开始就知道该怎么做了。我觉得是后者，而且我觉得这确实非常强大。

Lenny Rachitsky： 看你们演示这些，真的让我大开眼界，理解了这到底是怎么回事，以及整个过程有多么系统化。我之前总想象你就是坐在电脑前，“好吧，我需要确保哪些东西能正常工作？“而你现在展示给我们的是，这是一套非常简单的、循序渐进的流程，基于你产品中真实发生的事情，如何捕获问题、识别问题、排定优先级，然后在问题再次发生时捕获并修复它们。

Shreya Shankar： 是的，这不是什么魔法。任何人都可以做到。你需要像学习任何新技能一样去练习，但你是可以做到的。我觉得现在非常令人振奋的是，产品经理们也在做这件事、也能做到这件事，并且真的能凭借这套技能构建出非常赚钱的产品。

关于 evals 的争议

Lenny Rachitsky： 很好，这正好自然过渡到前几天我们在 X 上被卷入的一场辩论。我之前完全没意识到 evals 周围竟然有这么多争议和戏剧性。有很多人持有非常强烈的观点。Shreya，给我们大致讲讲围绕 evals 的重要性和价值的辩论双方立场，然后说说你自己的看法。

Shreya Shankar： 好的。我先缓和一下气氛——我觉得大家其实站在同一边。我认为误解的根源在于人们对 evals 有非常僵化的定义。比如，他们可能认为 evals 就是单元测试，或者认为 evals 只是数据分析部分，不包括线上监控，也不包括对产品特定指标的监控——比如实际参与的对话数量等等。我觉得每个人在谈论 evals 时脑子里想的定义都不一样。另外我想说的是，人们过去在 evals 上吃过亏。有些人确实把 evals 做得很差。一个具体的例子是他们尝试做了 LLM 评判者，但结果与预期不一致。他们后来才发现了这个问题，然后就不再信任它了，接着就说”我反对 evals”。

我百分之百理解这种感受，因为你也应该反对 Likert 量表式的 LLM 评判者。我完全同意，我们也反对那种做法。很多误解源于两件事：一是人们对 evals 的定义过于狭窄，二是人们没做好然后吃了亏，于是不想让别人犯同样的错误。而不幸的是，X（也就是 Twitter）这个平台，大家一直在互相误读对方的意思，于是你就看到各种强烈的观点——“不要做 evals，那东西很糟糕。我们试过了，根本没用。我们是 Claude Code”或者其他什么知名产品，“我们不做 evals。“这背后其实有非常多的细微差别，因为很多这些应用都是站在 evals 的肩膀上的。编程代理就是一个很好的例子，Claude Code。它们站在 Claude 基础模型……不对，是经过微调的 Claude 模型的肩膀上，这些模型已经在许多编程基准测试上进行了评估。这一点是无法否认的。

Lenny Rachitsky： 为了让你说的更清楚——Claude Code 的一位负责人，我想可能是主管工程师，上了一档播客，他说”我们不做 evals，我们就靠感觉。我们就看感觉”，所谓”感觉”就是他们直接使用它，凭感觉判断对不对。

Shreya Shankar： 我觉得那种做法是可行的。这里面有两点。第一，他们站在了同事为编程所做的 evals 的肩膀上。

Lenny Rachitsky： 就是 Claude 基础模型的那些。

Shreya Shankar： 当然对吧？我们知道他们会公布那些数据，因为我们能看到基准测试结果，我们知道谁在上面表现得好。第二点是他们实际上在错误分析方面很可能也是相当系统化的。我敢打赌他们在监控谁在使用 Claude、有多少人在使用、创建了多少 trace、这些对话有多长。他们内部团队可能也在监控，在做 dogfooding（吃自己的狗粮）。每当有什么不对劲的地方，他们可能有一个队列，或者把问题发给开发 Claude Code 的人，这个人就在隐式地做着 Hamel 谈到的那种手工错误分析。所有这些都是 evals，对吧？不可能存在这种情况——他们就这么说”我做了 Claude Code，我再也不看任何东西了”。而不幸的是，当你不去想这些、不去谈论这些时，我觉得社区……

社区中的大多数人都是初学者，或者是不了解 evals 但想学习的人，这给他们传递了错误的信息。当然，我不知道 Claude Code 具体在做什么，但我愿意拿钱打赌他们一定在以某种形式做 evals。

Hamel Husain： 我还想说的是，编程代理和其他 AI 产品有着根本性的不同，因为开发者本身就是领域专家，所以你可以省略很多步骤。而且开发者整天都在使用它，所以存在一种特殊的 dogfooding 和领域专业性——你可以把这些活动合并在一起，不需要那么多数据，不需要那么多反馈或探索，因为你自己就知道结果如何，所以你的 eval 流程理应看起来不一样。

Lenny Rachitsky： 因为你能看到代码，你能看到它生成的代码。你可以判断”这个很好，这个很糟糕。”

Hamel Husain： 对，对。我觉得很多人把编程代理的情况做了过度推广，因为编程代理是第一个真正发布到野外的 AI 产品，我认为把编程代理的做法推广到所有场景是一个错误。

Shreya Shankar： 另外一点就是，是的，工程师天生就有 dogfooding 的特质。而有很多应用场景，人们在某些领域尝试构建 AI，但那些领域没有 dogfooding 的条件——比如面向医生的场景，你不可能让医生整天去获取各种 AI 给出的错误建议还能保持包容和接受的态度。我觉得这些细微之处非常重要，需要牢记在心。

evals 与 A-B 测试之争

Lenny Rachitsky： 有趣的是，Shreya，我从你这里听到的是，如果团队中的人在进行非常细致的数据分析、错误分析（error analysis），疯狂地 dogfooding，本质上他们就是人工评估——你把这也归类在 evals 的范畴之内。如果你有时间和动力，可以这样做；或者你也可以把这些东西设置为自动化运行。

Shreya Shankar： 完全正确，这也涉及技能的问题。在 Anthropic 工作的人技能水平非常非常高。他们接受过数据分析、软件工程、AI 等方面的训练。当然，任何人都可以通过学习这些概念达到那个水平，但大多数人目前还不具备那种技能。

Hamel Husain： dogfooding 这件事有一个需要警惕的地方，就是很多人会说自己在 dogfooding。他们会说”对，我们 dogfood 了”，但真的是这样吗？很多人并没有真正在那种 visceral 层面上进行 dogfooding，而那是闭合反馈回路所必需的。这是我想补充的唯一一个提醒。

evals 与 A-B 测试的关系

Lenny Rachitsky： 还有一种感觉像是稻草人论证的说法，就是 evals 和 A-B 测试的对立。谈谈你们的看法吧，因为这似乎是这场争论中很重要的一部分。人们在讨论”如果你有 A-B 测试在检验生产环境的指标，还需要 evals 吗？”

Shreya Shankar： A-B 测试同样也是 evals 的另一种形式，我是这么认为的，对吧？当你做 A-B 测试时，你有两个不同的实验条件，然后你有一个量化某个成果的指标，你在比较这个指标。在我们的理解中，eval 就是对质量的系统性度量，也就是某种指标。你不可能在没有 eval 的情况下做 A-B 测试来比较，所以也许我们只是对此有一个不同的、有些奇怪的看法。

Lenny Rachitsky： 好的。我听到的是你们把 A-B 测试视为所做 evals 套件的一部分。我想人们说到 A-B 测试时，通常是指”我们在产品中改了某个东西，看看是否能改善我们关心的某个指标”。这样就够了吗？为什么还需要测试每一个小功能？如果它影响的是我们在商业上关心的某个指标，我们有大量的 A-B 测试在持续运行。

Shreya Shankar： 这一点提得非常好。我认为很多人过早地做 A-B 测试，因为他们从一开始就没有做过任何错误分析（error analysis）。他们只是凭假设提出了产品需求，然后相信”我们应该测试这些东西”，但结果表明，当你深入数据之后——正如 Hamel 所展示的——你看到的错误并不是你以为会出现的那些错误。而是一些奇怪的交接问题，或者，我不知道，短信那件事就很奇怪。我想说的是，如果你要做的 A-B 测试是建立在像我们今天展示的这种真正的错误分析（error analysis）基础之上的，那很好，去做吧。但如果你只是想做 A-B 测试——我们发现很多人确实是这样——只是基于你假设性地认为重要的东西来做，那我建议大家重新思考一下，把你的假设建立在扎实的基础上。

Statsig 被 OpenAI 收购

Lenny Rachitsky： 你对 Statsig 在 OpenAI 会做什么有什么看法吗？有没有什么有趣的东西？那可是一件大事，一次巨大的收购。一家 A-B 测试公司，人们都在说”A-B 测试就是未来”。怎么想？

Hamel Husain： 先补充一下上一个问题，为什么会有 evals 对 A-B 测试这样的争论？我认为，从根本上说，evals 是……人们在努力理解如何改进自己的应用，从根本上需要做的是——数据科学在产品中是有用的。看数据，做数据分析。有各种不同的工具套件，你不需要发明什么新东西。当然，你不需要数据科学的全部广度，而且在 LLM 场景下看起来会有些不同，但只是稍微有些不同。你的策略可能不同，所以本质上就是用分析工具来理解你的产品。现在人们说”evals”这个词，试图划分出一个新东西，说 evals 然后又是 A-B 测试，但如果你退后一步看，这和以前的数据科学是一样的。我认为造成困惑的原因就是——“我们需要数据科学思维”，AI 产品需要这种思维，就像任何产品都需要一样，这是我的看法。

Lenny Rachitsky： 这个观点非常好，我觉得就是”evals”这个词现在会触发人们的反应。

Shreya Shankar： 对。

Lenny Rachitsky： 如果你只是说”我们在做错误分析，做数据科学来了解我们的产品在哪里出了问题，然后设置测试确保我们知道——”

Shreya Shankar： 那太无聊了，听起来很无聊。不，不，不。我们需要一个神秘的术语，比如”evals”，才能真正推动起来势头。你关于 Statsig 的问题，我觉得很令人兴奋。说实话，我对这件事了解不多，因为我只是觉得他们是一家……很多人在用的一款工具的公司，也许恰好 OpenAI 收购了他们。我确定他们之前一直在使用 Statsig，我确定 OpenAI 的竞争对手也在使用 Statsig，所以也许这次收购有某种战略考量。我完全不知道，我对此没有任何内情，但我觉得这些才是更大的问题，而不是”这是否从根本上改变了 A-B 测试或让 evals 变得更重要”。我认为 evals 一直都很重要，我认为 OpenAI 一直在做某种形式的 evals，而且从历史上看，OpenAI 甚至走得更远——他们会去看所有的 Twitter 情绪，尝试做一些回顾性分析，然后将其与产品关联起来。当然，他们在发布新的基础模型之前肯定做了某种程度的 evals——

然后将其与产品关联起来。当然，他们在发布新的基础模型之前肯定做了某种程度的 evals，但他们做的远不止于此，比如”好吧，让我们找到所有抱怨的推文，所有抱怨的 Reddit 帖子，然后去搞清楚到底发生了什么。“这说明 evals 非常、非常重要。还没有人真正搞明白。人们在使用所有能获取的信号来源来改进他们的产品。

Hamel Husain： 我想说的是，我真的很希望这能在 OpenAI 内部推动或创造出一种关注点，希望如此。到目前为止，各大实验室理所当然地把重心放在像 MMLU 分数、human eval 这样的通用基准测试（benchmarks）上，这些对基础模型来说确实很重要。但这些和产品特定的 evals 关系不大——比如我们今天讨论的交接问题之类的，它们往往没有相关性。

Shreya Shankar： 对，它们和数学问题求解能力不相关，很遗憾。

Hamel Husain： 没错。如果你看看那些 eval 产品，比如最近之前一些大实验室所拥有的那些，它们没有错误分析（error analysis）功能。它们有一套通用工具——余弦相似度、幻觉评分之类的，但那不管用。作为第一次尝试，它是不错的。还行。至少你在做些什么，让人们去看数据。但最终，我们希望看到的是，在 eval 流程中融入更多的数据科学思维。这才是我们希望工具能达到的目标。

Shreya Shankar： 对，Pamela 和我不应该是这个星球上仅有的两个在推广面向应用特定 evals 的结构化思维方式的人。这让我百思不得其解。为什么全世界只有我们两个人在做这件事？到底怎么回事？我希望我们不是仅有的两个人，希望更多人能跟上。

关于 evals 的常见误区

Lenny Rachitsky： 你们在 Maven 上的课程是 Maven 平台上收入最高的课程，这显然说明有需求和兴趣，而且我觉得你们这边的人越来越多了。有趣的是，你一直在 Twitter 上分享的一个例子很有启发性——所有人都在说 Claude Code 根本不在乎 evals，他们完全凭感觉（vibes），然后大家就说，既然它是最好的编程智能体，那显然这种做法是对的。但最近又有各种讨论说 Codex，OpenAI 的 Codex 更好，所有人都在转向它，而他们是非常支持 evals 的。

Shreya Shankar： 我知道。

Lenny Rachitsky： 是啊。

Shreya Shankar： 每次都让我无语。互联网太不靠谱了。我最喜欢的一件事是昨天，我和几个实验室同事出去吃甜点什么的，有人问：“你更喜欢 Codex 还是 Claude？“另一个人说：“我喜欢 Claude。“然后又有人说：“但新版 Codex 更好。“第一个人接着说：“哦，但我上次看是两天前，所以我的想法可能——可能我没跟上最新动态。“我当时就想，天哪。

Lenny Rachitsky： 太真实了，太真实了。这就是我们生活的世界。天哪。好吧，我想问问关于 evals 人们最大的误解，以及成功的技巧和窍门。也许每人各分享一两个。先从误解开始，让我先问 Hamel。关于 eval，人们最常见的误解有哪些？

Hamel Husain： 排第一的是：“嘿，我买个工具，插上就能帮我做 eval 了。我为什么要操心这个？我们生活在 AI 时代，AI 不能自己 eval 吗？“这是最常见的误解。人们太想要这个了，以至于真的有人卖这种东西，但它不管用。这是第一个。

Lenny Rachitsky： 哎，很多人类依然很有用。我觉得这是个好消息。

Hamel Husain： 我经常看到的第二个是：“嘿，就是不看数据。“我做咨询的时候，人们总是带着问题来找我，我第一句话就是：“让我们去看看你的 trace（追踪日志）。“你能看到他们瞪大眼睛：“什么意思？“我就说：“对，现在就看。“他们会很惊讶，因为我要去看单条 trace（追踪日志）。而每次，100% 的情况下，都能学到很多东西，找到问题所在。我觉得人们就是不知道看数据有多么强大，就像我们在这期播客里展示的那样。

Shreya Shankar： 我同意这一点。

Lenny Rachitsky： 这就是前两个？好的。

Shreya Shankar： 是的。

Lenny Rachitsky： 还有别的吗，还是说解决这两个就够了？

Shreya Shankar： 哦，那两个确实是最重要的。那我想补充的第三个是，做 evals 没有唯一正确的方法。错误的做法有很多种，但正确的做法也有很多种。你需要考虑你的产品处于什么阶段，你有多少资源，然后找到最适合你的方案。它总是涉及某种形式的错误分析（error analysis），就像我们今天展示的那样，但你如何将这些指标落地操作化，会根据你的具体情况而变化。

实用建议

Lenny Rachitsky： 太棒了。好的。大家刚开始做 eval，或者想改进现有做法的时候，有什么技巧和窍门想留给他们的？

Shreya Shankar： 第一条建议就是，不要对看数据感到恐惧或害怕。这个过程，我们尽量让它结构化，但不可避免地会有各种问题冒出来，这完全没问题。你可能觉得自己做得不够完美，那也没关系。目标不是把 evals 做得完美，而是切实改善你的产品。我们保证，无论你做什么，只要你做了这个流程的一部分，你就会找到切实可行的改进方向，然后你会在此基础上不断迭代自己的流程。

另一条建议是，我们非常支持 AI。在整个过程中，用 LLM 来帮助你整理思路。这可以是方方面面的——从最初的产品需求开始，想清楚怎么为自己整理这些需求。想清楚怎么根据你创建的开放式编码（open coding）来改进那个产品需求文档。不要害怕用 AI 来帮你更好地呈现信息。

Lenny Rachitsky： 好的，所以不要害怕，在流程中尽量多地使用 LLM。

Shreya Shankar： 但不是用来替代你自己。

Lenny Rachitsky： 对。好的，很好。工作还在。太好了。Hamel。

打造自己的数据查看工具

Hamel Husain： 好。让我分享一下屏幕，因为我想展示点东西。在 Shreya 说的基础上补充一下——如果你在这期播客里听到了什么短语，你听到最多的可能就是”看你的数据”。这件事太重要了，以至于我们教学中会说你应该创建自己的工具，让看数据变得尽可能简单。在之前的实时演示中，我给你们展示了一些标注数据的工具。我合作的大多数人，他们意识到了这有多重要之后，就开始凭感觉（vibes）编程——我们不应该说凭感觉（vibes）编程——自己做工具，而且现在比以往任何时候都便宜，因为你有 AI 可以帮忙。

AI 非常擅长创建简单的 Web 应用，可以展示数据、写入数据库。很简单。以 Nurture Boss 的场景为例，我们想消除看数据的所有摩擦。你在这里看到的只是一些截图，展示他们创建的应用长什么样。就是这样——“好的，他们有不同的渠道，语音、邮件、短信。有不同的线程，系统提示词（system prompt）默认隐藏。“一些小的体验优化。然后他们确实有这个轴向编码（axial coding）的部分，你可以看到红色的不同错误的计数。他们把那部分自动化了，做得很好，而且几个小时就搞定了。很难有一个通用的万能方案来看你的数据。你不必一开始就走到这一步，但值得思考的是，让看数据变得尽可能简单，因为，再说一遍，这是你能从事的最强大的活动。这是 ROI 最高的活动。有了 AI，就是消除所有摩擦。

Lenny Rachitsky： 太厉害了。再说一次，我觉得 ROI 这一点太重要了。我们甚至还没有充分展开谈这一点。这里的目标是让你的产品变得更好，从而让你的业务更加成功。这不是什么抓 bug 之类的小练习。这是让 AI 产品变得更好的方法，因为用户体验就是用户与你的 AI 交互的方式。

Hamel Husain： 完全同意。甚至可以说，我们教学生的时候会说：“嘿，你在做这些 evals 的时候，如果看到有什么不对的，直接去修就好了。“重点不是拥有 evals，一套漂亮的 eval 套件，你可以指着它、编辑它然后说：“哦，看看我的 evals。“不是的，直接修复你的应用，让它变得更好。如果问题很明显，就直接干。完全同意你说的。

Lenny Rachitsky： 太棒了。我还有一个没问到的问题，但我觉得大家在想的——你在这上面花多长时间？第一次做通常需要多久？

时间投入与持续维护

Shreya Shankar： 我可以结合自己参与的应用来回答。通常我会花三到四天时间，和相关人员一起做最初几轮的错误分析（error analysis）。大量标注工作，觉得状态不错了，就建一个类似 Hamel 展示的那种表格，让大家都能认同和信服，甚至搭几个 LLM 作为评判者。但这属于一次性投入。一旦搞清楚怎么把它集成到单元测试里，或者写一个脚本自动对抽样运行，再设一个 Cron Job 每周自动执行，就好了。我发现自己可能花了不少时间看数据，因为我就是那种对数据如饥似渴的人，好奇心太强了。我从这个过程中获益匪浅，它让我在与他人的合作中远远超出预期，所以我想一直做下去。但并不是非得这样不可。之后大概每周花 30 分钟就够了。

Lenny Rachitsky： 所以基本上前期花一周左右，之后每周 30 分钟来持续改进和扩充你的 eval 套件？

Shreya Shankar： 对，真的不需要太多时间。我觉得大家只是被前期投入的时间吓到了，然后以为后面也得一直这么做。

数据驱动的产品洞察

Lenny Rachitsky： 太棒了。还有什么想和听众分享的吗？在进入非常令人期待的快问快答环节之前，还有什么想特别强调的观点吗？

Hamel Husain： 我想说，这个过程其实很有趣。你会觉得，好吧，你在看数据，听起来像是在标注东西。实际上，我昨天刚看了一个客户的数据，用的就是完全相同的流程。那是一个发送邮件的应用，发送招聘邮件来吸引候选人应聘。我们决定开始看追踪日志（trace），直接就上手了。“来，看看你的追踪日志。“我们看了一条 trace，第一眼就看到一封邮件，措辞是这样的：“鉴于您的背景，blah blah blah……”我立刻就问了对方——这就是你戴上产品帽子、用挑剔眼光去看的时候，也是有趣的部分所在。

我说：“你知道吗？我很讨厌这封邮件。你自己喜欢吗，‘鉴于您的背景’？“当我收到一条”鉴于您的背景，逗号”开头的消息时，我直接就删了。我心里想：“鉴于您在机器学习方面的背景 blah blah，这是什么？“这就是模板化的东西。我问对方：“我们能做得更好吗？这听起来就是千篇一律的招聘邮件。“他们说：“哦，确实，也许吧。“因为他们之前还挺自豪的，觉得”AI 做对了，它发送了正确信息的邮件，有正确的链接、正确的名字，一切都没问题。“有趣的地方就在这里——戴上你的产品帽子，深入思考：这真的够好吗？

Lenny Rachitsky： 在进入非常令人期待的快问快答之前，我想确保我们提到一点——这只是做好这件事所需知识的冰山一角。但我认为这是目前关于如何做好这件事最好的入门指南了。

Shreya Shankar： 太好了。

课程推荐

Lenny Rachitsky： 但我想我们已经做到了。不过你们两位教了一门课程，对那些真正想精通此事、认真对待的人会深入得多。请分享一下你们在课程里还教了哪些我们没涉及的内容，以及作为 Maven 上那门课的学生还能获得什么。

Shreya Shankar： 好，我来介绍一下教学大纲，然后 Hamel 可以谈谈各种附加权益。我们按照生命周期来讲：错误分析（error analysis），然后是自动化评估器，再是如何改进你的应用，如何为自己打造那个飞轮。我们还有一些几乎没人听过或教过的专题，这部分非常令人兴奋。其中一个专题是：如何构建自己的错误分析（error analysis）界面。我们会展示我们实际构建的界面，还会现场用新数据即时编码演示。我们展示如何使用 Claude Code、Cursor，或者当天想用的任何工具来构建这些界面。

我们还会广泛讨论成本优化。我合作过的一些人，他们的 evals 做得很好，产品也很好，但一切都非常昂贵，因为他们用的是最先进的模型。我们怎样才能在某些场景下用更便宜的 GPT-5-nano、4-mini 之类的替代最贵的 GPT-5，大幅节省成本，同时保持相同的质量？这方面我们也会给一些技巧。Hamel，到你了。我们还有很多附加权益。

Lenny Rachitsky： 好，讲讲那些权益。

Hamel Husain： 好，附加权益。我最喜欢的权益是一本 160 页的书，写得非常细致，我们精心打造的，完整走过了整个 eval 流程的详细步骤，作为课程的补充资料。你不必坐在那里辛苦记笔记，我们已经替你做了所有苦活，把一切详细记录并整理好了，非常实用。另一个很有趣的东西——这个灵感其实来自你，Lenny——就是，这是一门 AI 课程，教育不应该只是看讲座和做作业，学生也应该有一个 AI 来帮助他们。我们的做法是，就像你有 LennyBot 一样。

Lenny Rachitsky： dot com。

Hamel Husain： 对，lennybot.com，我们用同样的软件做了同样的东西，把我们所有关于 evals 说过的内容都放进去了。每一节课、每一次答疑、每一条 Discord 聊天、任何博客、论文，我们在公开场合和课程中说过的所有内容，全都放进去了。我们让一批学生测试过，他们说很有帮助。我们给所有学生 10 个月免费、无限制使用的权限，随课程一起提供。

Lenny Rachitsky： 太厉害了。那之后会收费吗？

Hamel Husain： 我也不知道。我走一步看一步，不知道后面会怎样。

Lenny Rachitsky： 八个月后再想办法。我刚才在想，这整场访谈其实可以让我们的两个 bot 互相对话。

Shreya Shankar： 那太搞笑了。我会看的，但只看 10 分钟，之后我就不知道它们在说什么了。

Lenny Rachitsky： 哈，也许 30 秒就够了。顺便问一下，你们有基于语音模式来训练它吗？那是 Delphi 产品里我最喜欢的功能。如果没有的话，你们应该试试。

Hamel Husain： 哦，我想想……我记不清了，我得去看看。

Lenny Rachitsky： 你确实应该试试。现在我们有了这期播客，你可以用这些内容来训练它。是 11Labs 驱动的，效果特别好。好，那他们怎么获取……我觉得这样就行，报名你们的课程之后就能用上了。

Shreya Shankar： 对，报名课程后会收到一堆邮件，一切都会说清楚，希望如此。

Lenny Rachitsky： 太好了。

Shreya Shankar： 我们还有一个 Discord，所有上过课的学生都在里面。那个 Discord 非常活跃，我度假时在飞机上都会收到通知。

Lenny Rachitsky： 甜蜜的烦恼。太棒了。好，我们现在进入非常令人期待的快问快答环节。我准备了五个问题。准备好了吗？

Shreya Shankar： 准备好了，开始吧。

快问快答

Lenny Rachitsky： 来吧。好的，我会在你们两位之间轮流提问。想分享就分享，不想答也可以跳过。第一个问题，Shreya，你最常向别人推荐的两三本书是什么？

Shreya Shankar： 我喜欢推荐一本小说，因为生活不只有 evals。最近我读了 Min Jin Lee 的《Pachinko》，非常棒的一本书。另外我还在读《Apple in China》，作者名字一时想不起来了，但这本书更像是一篇纪实报道，由一位记者撰写，讲述 Apple 过去几十年在亚洲如何开展大量制造流程，非常开眼界。

Lenny Rachitsky： 太棒了。Hamel？

Hamel Husain： 好的，我书就在手边。我是个书呆子。好吧，我没有 Shreya 那么酷。我推荐的都是教科书，这也是我最喜欢的。这本是非常经典的一本，Mitchell 的《Machine Learning》。它是偏理论的，但我喜欢的一点是，它真正让你深刻理解奥卡姆剃刀不仅适用于科学，也适用于机器学习和 AI。很多时候，最简单的方法——工程上也一样——泛化效果反而更好。这是我从那本书中深刻内化的东西。我还很喜欢这本，也是教科书。我说过我是个书呆子吧。这本也很老了，是 Norvig 的《算法》。我喜欢它是因为它展现了人类的智慧，里面有很多在计算领域巧妙而实用的东西。

Shreya Shankar： 他和 Berkeley 就在一条街上。

Lenny Rachitsky： 做那个研究的人？

Shreya Shankar： 对，教科书的作者。

Lenny Rachitsky： 太酷了。天哪，书呆子们，我爱了。好，下一个问题。最近最喜欢的电影或电视剧？我先问 Hamel。

Hamel Husain： 好吧，我是两个孩子的爸爸，没什么时间看电视或电影，所以我就看孩子们看的东西。上周我看了三遍《Frozen》。

Lenny Rachitsky： 才三遍？哦，是一周之内。好吧。

Hamel Husain： 这就是我的生活。

Lenny Rachitsky： 很好，Hamel。《Frozen》，我喜欢。好，Shreya。

Shreya Shankar： 我没有孩子，所以能给出精彩的答案。实际上，我丈夫和我最近在看《The Wire》。我们小时候都没看过，所以开始看了，真的很棒。

Lenny Rachitsky： 我感觉每个人生命中都会经历这个阶段——终于有一天决定”我要看《The Wire》”。

Shreya Shankar： 对，我们现在就处于那个阶段。

Lenny Rachitsky： 就像要花掉你一年时间。但确实很棒，太好看的剧了。不过集数太多了，每集还都是一小时。

Shreya Shankar： 我知道，我知道。

Lenny Rachitsky： 真的是一个巨大的 commitment。

Shreya Shankar： 我们一周只看两三集，进度很慢。

Lenny Rachitsky： 值得。好，下一个问题。你最近有没有发现一个特别喜欢的产品？先从 Shreya 开始。

Shreya Shankar： 说实话我真的很喜欢用 Cursor。还有 Claude Code。我解释一下为什么。我本质上更偏向研究者。我写论文、写代码、构建系统，什么都做。我发现一个工具……我对 AI 辅助编程非常看好，因为我总是要同时扮演很多角色。现在，我可以对我构建和撰写论文的东西更有雄心了，所以我对此非常兴奋。Cursor 是我进入这个领域的入口，但我现在发现自己一直在追赶各种 AI 辅助编程工具。

Lenny Rachitsky： Hamel？

Hamel Husain： 我也很喜欢 Claude Code，喜欢的原因是我觉得它的用户体验非常出色，能看出里面倾注了很多心血。作为一个终端应用能做到这个程度，真的令人印象深刻。

Lenny Rachitsky： 你俩都这么喜欢 Claude Code，而它偏偏就是靠凭感觉（vibes）构建的，真是讽刺。

Shreya Shankar： 我觉得这个说法不对，它不只是靠凭感觉（vibes）构建的。

Lenny Rachitsky： 这就对了。好，还有两个问题。Hamel，你有没有最喜欢的人生格言，在工作或生活中常常回想起来的？

Hamel Husain： 持续学习。像初学者一样思考。

Lenny Rachitsky： 很美。Shreya？

Shreya Shankar： 我喜欢这个。对我来说，是始终试着站在对方的角度思考。我有时会在网上看到各种争论，比如关于 eval 竞赛的辩论，我会真的去想：“好吧，把自己放在他们的位置上。可能存在一个善意的解读。“我认为我们团结在一起远比互相争斗更强大。我对 evals 的愿景不是让 Hamel 和我成为亿万富翁，而是让每个人都能构建 AI 产品，大家达成共识。

Lenny Rachitsky： 以及每个人都成为亿万富翁。

Shreya Shankar： 没错。

Lenny Rachitsky： 太棒了。最后一个问题。当我同时有两位嘉宾时，我总喜欢问这个问题，先从 Hamel 开始。你最喜欢 Shreya 的什么品质？我问她同样的问题，反过来。

Hamel Husain： Shreya 是我认识的最有智慧的人之一，尤其是考虑到她比我年轻那么多。说实话我觉得她比我智慧得多。她非常踏实，对事物有着非常平和的视角。这一点总是让我印象深刻。

Lenny Rachitsky： Shreya？

Shreya Shankar： 我最喜欢 Hamel 的是他的能量。我不认识任何人能像 Hamel 一样始终保持着那样的势头和能量。我经常想，如果不是因为 Hamel，我可能早就不再那么关注 evals 了。每个人生活中都需要一个 Hamel，真的。

Lenny Rachitsky： 好了，我们现在每个人都有一个 Hamel 了。这次对话太精彩了，完全是我期望的样子。我觉得这是我见过的最有趣、最深入、最容易消化的 evals 入门指南。非常感谢你们两位抽出时间。最后两个问题。大家在哪里可以找到你们？在哪里可以找到这门课程？听众怎样能帮到你们？先从 Shreya 开始。

Shreya Shankar： 你可以通过电子邮件联系我，地址在我的网站上。Google 我的名字，这是找到我网站最简单的方式。如果你 Google “AI Evals for engineers and product managers”，或者直接搜 “AI Evals course”，就能找到这门课程。之后我们会分享一些链接，方便大家找到。如何能帮到我们？对我来说永远有两件事。一是有问题时就来问我，我会尽快回复。另一件是告诉我们你们的成功案例。让我们持续走下去的动力之一，就是有人告诉我们他们实施了什么、做了什么，一个真实的案例研究。Hamel 和我看到这些会非常兴奋，这真的让我们坚持下去，所以请多多分享。

Hamel Husain： 找到我很简单。我的网站是 Hamel.dev，我可以把链接发给你。你也可以在社交媒体上找到我，LinkedIn、Twitter 都有。最有帮助的，是呼应 Shreya 说的——我们非常希望不是只有我们在教 evals。我们很乐意看到其他人也来教 evals。任何形式的博客文章、写作，尤其是你在这个过程中学到了东西想分享的，我们都非常乐意帮忙转发和推广。

Lenny Rachitsky： 太棒了，非常慷慨。非常感谢你们两位来到这里。我真的很感激，你们两位手头都有很多事情，谢谢。

Shreya Shankar： 谢谢 Lenny 邀请我们，也谢谢你的所有夸奖。

Lenny Rachitsky： 这是我的荣幸。大家再见。

非常感谢大家的收听。如果你觉得这期节目有价值，可以在 Apple Podcasts、Spotify 或你喜欢的播客应用上订阅。也请考虑给我们评分或留下评论，这真的能帮助更多听众找到这个播客。你可以在 Lennyspodcast.com 找到所有往期节目或了解更多关于节目的信息。下期再见。

术语表

原文中文
agreement一致性（指人类标注与 LLM 评判者之间的一致程度）
axial codes/axial coding轴向编码（axial coding）
benchmarks基准测试
benevolent dictator仁慈独裁者（benevolent dictator）
bullish看好
commitmentcommitment（时间/精力上的投入承诺）
cosine similarity余弦相似度
criteria drift评判标准漂移（criteria drift）
dogfoodingdogfooding（吃自己的狗粮，即团队内部使用自己的产品）
entry point入口
error analysis错误分析（error analysis）
evalsAI评估（evals）
failure mode失败模式
foundation model基础模型
hallucinating产生幻觉（hallucination）
hallucination score幻觉评分
human evalhuman eval
jankyjanky（混乱/粗糙）
lead management线索管理（lead management）
Lenny RachitskyLenny Rachitsky（播客主持人）
Likert scaleLikert 量表
LLM as a judgeLLM 作为评判者
MMLUMMLU
moat护城河
Nurture BossNurture Boss（产品名称）
observability tool可观测性工具（observability tool）
Occam’s razor奥卡姆剃刀
open coding开放式编码（open coding）
PamelaPamela
pivot table数据透视表
RAG retrievalRAG 检索
retrospective回顾性分析
sample抽样
straw man argument稻草人论证
system prompt系统提示词（system prompt）
theoretical saturation理论饱和（theoretical saturation）
tool calls工具调用
tracetrace（追踪日志）
vibe凭感觉（vibes）
visceralvisceral（切身/ visceral 层面的）
weasel way模棱两可的做法

此文档由 AI 分片翻译（translate_long_document）