Lennys.Newsletter · 2025-06-10

👋 每周，我会回答读者关于构建产品、驱动增长和加速职业发展的问题。年度订阅者可免费获得一年期的15+款优质产品：Lovable、Replit、Bolt、n8n、Wispr Flow、Descript、Linear、Gamma、Superhuman、Granola、Warp、Perplexity、Raycast、Magic Patterns、Mobbin 和 ChatPRD（送完即止）。

更多内容：Lennybot | Lenny's Podcast（莱尼播客） | How I AI | Lenny's Reads（莱尼荐读） | Courses（课程）**

哈梅尔·侯赛因(Hamel Husain) 和 什雷亚·尚卡尔(Shreya Shankar) 的在线课程 AI Evals for Engineers & PMs 是 Maven 平台上收入最高的课程，持续吸引着各大 AI 实验室的大量学员。原因在于他们教授的是一项至关重要的技能：如何构建真正能改进产品的评估（eval）系统，而非仅仅生成华而不实的仪表盘。

在过去两年中，哈梅尔和什雷亚在推动评估从一个晦涩难懂的课题转变为一个 AI 产品构建者必备的核心技能方面，发挥了重要作用。

在培训了超过2,000名产品经理（PM）和工程师以及500多家公司的领导者之后，他们现在分享了自己的完整行动手册——这套方法论正是他们在 OpenAI、Anthropic 及其他领先实验室中教学的内容。你将学到如何利用错误分析（Error Analysis）来理解 AI 产品在哪些地方出问题、如何构建值得信赖的稳健评估系统、以及如何创建一个持续改进的飞轮，在上线之前就捕捉到回退（regression）。

为庆祝本文发布，哈梅尔和什雷亚还独家提供课程 35% 折扣——这是他们有史以来提供的最大折扣。点击此链接注册（或结账时使用优惠码 LENNYSLIST）。还剩三天可以报名。

感谢哈梅尔和什雷亚与我们分享这些宝贵内容 🙏

P.S. 你可以通过播客形式收听本文：Spotify / Apple / YouTube。

阿曼·汗(Aman Khan) 关于评估的文章完美地说明了为什么评估正在成为产品经理的一项核心、决定性技能。本文提供了下一步：一套用于构建评估系统以推动真正产品改进的行动手册。许多团队构建的评估仪表盘看起来很有用，但最终被忽视，并未带来更好的产品——因为这些评估所报告的指标与真实的用户问题脱节。

本指南提供了一套弥合这一信任鸿沟的流程。我们将涵盖三个阶段：通过严格的错误分析发现该衡量什么、构建可靠的评估套件、以及将评估套件运营化以创建持续改进的飞轮。

第一阶段：用错误分析将评估扎根于现实

在你能改进 AI 产品之前，你必须了解它是如何失败的。你可能要评估的范围是无限的。最常见的错误是从衡量现成的、时髦的指标开始，比如"幻觉（hallucination）"或"毒性（toxicity）"。这种做法往往导致追踪的分数与用户在使用你产品时遇到的实际问题毫无关联。在你系统地发现产品在特定语境下如何失败之前，你无法知道该衡量什么。这个过程被称为"错误分析（Error Analysis）"，其结果应该是一份清晰、按优先级排序的产品最常见失败模式列表。

这个过程不是从指标开始的，而是从数据和一位人类专家开始的。对大多数中小型公司来说，最有效的方法是指定一位首席领域专家（Principal Domain Expert）作为质量的仲裁者。这个人——对心理健康聊天机器人来说是心理学家，对法律文档分析来说是律师——成为质量评判的权威声音。指定一位专家（有时被称为"仁慈的独裁者（Benevolent Dictator）"）可以提供一致且深度知情的判断信号，消除标注冲突，避免因意见过多而导致决策瘫痪。在很多情况下，产品经理本人就是首席领域专家。对于跨多个复杂领域、涉及不同文化背景的大型组织或产品，可能需要多位标注者（annotator）。在这些情况下，你必须实施更结构化的流程以确保判断的一致性，这包括衡量标注者之间的一致性。

下一步是让这位专家审阅大约 100 个具有代表性的用户交互记录。随着熟练度的提高，你可以基于数据分析，专门采样那些更有可能产生洞见的交互——例如带有负面用户反馈的追踪记录（trace）、对话长度或工具调用次数异常的记录、高延迟记录等。不过，在一开始还是应该从随机采样开始，以建立直觉。

数据集准备好后，分析从开放编码（Open Coding）开始。这本质上像写日记，但多了一些结构化。领域专家审阅每个用户交互，对任何看起来有问题或不受欢迎的地方写下自由形式的批评，同时对 AI 表现给出通过/不通过（pass/fail）的判断。

以下是一个公寓租赁助手进行开放编码的截图。在界面中，我们可以看到 AI 编造了一个虚拟导览——而实际上该服务并不提供这项功能：

作为一条经验法则，批评应该足够详细，让公司新员工也能理解。或者从另一个角度说，足够详细到可以用于 LLM 裁判（LLM-as-a-Judge）的少样本提示（few-shot prompt）中。过于简略是一个常见错误。以下是一些开放编码的良好示例：

请注意，示例中的用户与 AI 的交互被简化以求简洁——但在实际操作中，你可能需要给领域专家更多上下文才能做出判断。这一点后面会详细说明。

这个轻度约束的过程对于发现你不知道自己存在的问题至关重要。团队也正是在这个过程中常常发现自己真正希望从 AI 系统中获得什么。研究表明，人们不太擅长在一开始就完整地说明自己对 AI 的全部要求。真正的成功标准，正是在审阅输出、并阐述什么"感觉不对"的过程中浮现出来的。

在收集了数十条追踪记录的笔记之后，下一步是轴心编码（Axial Coding），也就是模式发现。专家通读所有开放式批评，然后开始将它们归类（示例如下）。这个过程将一个混乱的观察列表转化为一个清晰、按优先级排序的具体失败模式分类法。它既是艺术也是科学：以一种对你的领域来说可管理且合理的方式对错误进行分组。以下是如何对上述失败进行轴心编码的示例：

这个分组过程通常在电子表格或专用标注工具中进行——你可以在其中为每条批评打上标签或做标记。当我在一个真实场景中处理这个公寓租赁助手时，涌现出的类别如下：

你可以使用 LLM 加速这个过程。你可以让 LLM 对批评进行第一轮分类。然而，一个常见的陷阱是过度自动化。始终让人类专家审阅并验证 LLM 的建议。LLM 可能会忽略区分"对话流程问题"和"移交失败"的细微差别。另一个陷阱是创建过多类别；目标是控制在一组可管理的 10 个以内主要失败模式，捕捉最重要的问题。目标是创建一个可供分析的有用分类法，而不是一份详尽的清单。

这个阶段的最终成果就是简单地统计各类别的数量，以便了解如何分配时间。以下是我在电子表格中使用数据透视表（pivot table）对公寓租赁助手进行统计的结果：

如你所见，最常发生的错误是对话流程、移交（转接人工）和重新预约。这些数据给了我们产品特有的具体问题，让我们在构建评估时有明确的聚焦方向。

关于现成指标的警告

虽然幻觉和毒性这类现成指标不值得直接关注，但它们可以通过创造性的方式来使用。不要在仪表盘上报告一个幻觉或毒性分数，而是对你的追踪记录计算这些分数，然后按分数高低排序。审阅得分最高和最低的示例，可以发现令人惊讶的失败模式或意想不到的成功之处，进而帮助你为发现的模式构建自定义评估器。这是现成指标的少数合理用途之一。请注意，这是一种进阶技巧，只有在掌握了基础方法之后才应尝试。

第二阶段：构建评估套件

错误分析之后，你将拥有一个按优先级排序的产品最常见失败列表。下一步是构建一套自动化评估器来追踪这些失败。目标是创建一个可靠、经济高效且被团队信任的系统。这需要为每个失败模式选择合适的工具。

工具的选择取决于对每个已排好优先级的失败模式回答一个问题：这个失败是客观且基于规则的（例如："输出是否包含用户 ID？"），还是主观且需要判断的（例如："语气是否适合该角色人设？"）？

对于客观失败，使用基于代码的评估器（Code-based Evaluator）。这些是用代码编写的简单检查，就像单元测试中的断言。它们快速、便宜且确定性强，非常适合验证诸如输出是否为有效的 JSON、是否包含必需的关键词、或代码是否无错误执行等问题。只要能用明确的规则来定义成功或失败，就应该使用它们。

对于主观失败，你需要构建一个LLM 即裁判（LLM-as-a-Judge），以可靠地评估代码难以处理的品质，如语气、相关性或推理质量。这可能是一个严谨的过程——就像训练任何 LLM 一样——但它是规模化执行细微主观评估并最终改进产品的唯一途径。好消息是，有一套科学的方法可以确保裁判与你的产品愿景和成功标准充分对齐。

LLM 即裁判行动手册

这不仅仅关乎写一个聪明的提示词（prompt）。它关乎一个系统性的过程——将 LLM 的判断建立在你特定的质量标准之上。输出是一个能为特定错误给出二元通过/不通过指标的 LLM。更重要的是，你需要信任这个指标。建立信任的方法是用你创建的人类标注数据集来衡量裁判的表现。这涉及两个步骤。第一步是创建确定真实标准（Ground Truth）的数据集：

1. 建立真实标准

你的评估系统的好坏取决于其真相来源的质量。对大多数团队来说，最有效的方法是利用我们之前提到的首席领域专家。虽然跨多个领域运营的大型组织可能需要多位标注者以及衡量标注者间一致性的流程，但从一位专家开始可以加速整个过程。

专家的任务是为 AI 的每个用户交互（按会话分组）提供两样东西：一个二元通过/不通过判断，以及一份详细的批评。很多团队倾向于使用 1 到 5 分的李克特量表（Likert Scale），认为这样可以捕捉更多细微差别。这是一个陷阱。"3"和"4"之间的区分是主观且不一致的。二元决策迫使你做出清晰判断：输出要么达到质量标准，要么没有。细微差别并未丢失；它被捕捉在批评中，批评解释了做出该判断的原因。这些批评是构建高保真度裁判的秘密武器。例如，看回前面的这个例子：

理性的人可能会对这是否"足够好"有不同意见。然而，重要的是你努力对你的产品什么是好、什么是坏做出判断。在这个案例中，我们判定这次交互为不通过。

2. 构建并验证裁判

在收集了由领域专家标注的真实标准数据之后，你就可以开始构建并验证裁判了。不要将整个数据集都用于构建和测试裁判，这会导致过拟合（overfitting）——你在见过的示例上迭代得越来越好，但在新的、未见过的数据上却表现不佳。

相反，将真实标准数据分成三个不同的集合：

在开发集上优化裁判提示词的过程本身就是一项元评估（meta-evaluation）任务——你在评估你的评估器。这也是你发现自己质量标准中细微差别的地方。正如关于"标准漂移（criteria drift）"的研究所表明的，审阅 LLM 输出并调校裁判的过程会帮助你阐明和优化自己的标准。

以下是 LLM 即裁判对齐过程的高层可视化：

3. 衡量真正重要的：TPR/TNR而非准确率

一个常见的冲动是用单一的准确率（accuracy）分数来衡量裁判的性能，但这可能产生危险的误导。设想一个成功率 99% 的 AI 系统。一个始终预测"通过"的裁判将有 99% 的准确率，但它永远不会捕捉到任何一个失败。这是不平衡数据集（Imbalanced Dataset）的常见问题——其中一个结果远比另一个结果更频繁出现。

不要用准确率，而要用真正例率（True Positive Rate，TPR）和真负例率（True Negative Rate，TNR）来衡量，两者结合将精确地告诉你裁判在哪些方面容易犯错。通俗地讲：

一个 TPR 高但 TNR 低的裁判善于识别成功，但会让失败漏网。可接受的权衡取决于你的产品。对于提供医疗建议的 AI，假阴性（未能捕捉到有害建议）比假阳性的代价大得多。对于创意写作助手，假阳性（将好的回复标记为坏）可能更糟，因为它可能扼杀创造力。

一旦你知道了裁判的 TPR 和 TNR，你甚至可以对其原始分数进行统计校正，以得到系统真实失败率的更准确估计。例如，如果你的裁判在 1,000 个新示例上报告了 95% 的通过率，但你知道它有 10% 的概率将失败误标为通过，你可以调整这个 95% 的分数以反映裁判已知的错误率。（此校正的数学细节将在附录中提供）。

这个严格的、以人为主导的验证过程是构建团队可以信赖的评估系统的唯一途径。当你展示一个仪表盘，显示某个关键功能的失败率为 5% 时，你的利益相关者需要相信这个数字反映了现实。这就是你建立信任的过程。

特定架构的考量

在设计多轮对话、RAG 管道和智能体工作流（Agentic Workflow）的评估时，有一些特殊的考量因素和策略需要牢记。我们分别讨论如下。

多轮对话

许多 AI 产品是对话式的，这引入了在时间推进中维护上下文的挑战。在评估对话时，从最高层次开始：整个会话是否达成了用户的目标？这种会话级别的通过/不通过判断是最重要的成功衡量标准。

当对话失败时，下一步是定位根本原因。一个常见的错误是假设失败是由于对话的复杂性。在深入多轮分析之前，先尝试在单轮中复现失败。例如，如果一个购物机器人在第四轮对话中给出了错误的退货政策，先直接问它："产品 X1000 的退货政策是什么？"如果它仍然失败，问题很可能是一个简单的知识或检索问题。如果它成功了，你就确认了失败是对话性的——机器人在丢失上下文或误解了对话早期信息。这个诊断步骤通过区分简单的知识缺口和真正的对话记忆失败，节省了大量时间。

检索增强生成（Retrieval-Augmented Generation，RAG）

RAG 系统是一个两部分组成的机器：检索器（retriever）找到信息，生成器（generator）利用这些信息撰写答案。这两个部分可以独立失败，而一个端到端的正确性分数不会告诉你哪个出了问题。你必须分别评估它们。

首先，评估检索器。把它当作一个搜索问题来处理。为此，你需要一个由查询及其已知正确文档配对组成的数据集。RAG 最关键的指标通常是 recall@k（召回率@k）。它衡量的是在系统检索到的前 k 个结果中，捕捉到了多少比例的所有真正相关文档。召回率至关重要，因为如果正确的信息没有被检索到，生成器就没有机会产生正确的答案。现代 LLM 在忽略上下文中的无关噪音方面出奇地擅长，但它们无法从缺失的信息中凭空创造事实。

k 的值是一个关键调优参数，取决于你的任务。对于需要单一事实的简单查询，如"123 Main St. 的房产税是多少？"，较小的 k（例如 3 到 5）通常就足够了。主要目标是确保那一个正确的文档被检索到。然而，对于需要综合多个来源信息的复杂查询，如"总结市中心三居室房屋的近期市场趋势"，你需要更大的 k（例如 10 到 20）来为生成器提供足够的上下文以构建全面答案。虽然召回率是初始检索阶段的优先指标，但在存在第二阶段——即重排序（re-ranking）阶段，用于选择最佳文档传递给 LLM 的系统中，precision@k（精确率@k）（检索到的文档中相关文档的比例）也变得重要。

一旦你的检索器在多样化的查询集上表现良好，你就可以评估生成器了。这里你主要衡量两个方面。第一是忠实度（Faithfulness）：生成的答案是否忠实于检索到的上下文中提供的事实，还是在编造（hallucinating）？第二是答案相关性（Answer Relevance）：答案是否直接回应用户的原始问题？一个答案可以完美地忠实于源文档，但仍然未能与用户的意图相关。

先修复你的检索器。只有当你确信正确的信息正在被持续地送入生成器后，才应该大力专注于改进生成环节。需要指出的是，RAG 是一个非常新兴的课题，在评估和优化方面仍有很多需要探索的地方。参见此系列了解高级 RAG 主题的探索。

智能体工作流（Agentic Workflows）

智能体（Agent）——能够执行一系列动作（如工具调用）以完成目标的系统——是最复杂的评估对象。对最终结果做一个单一的通过/不通过判断是一个好的起点，但它不具备诊断性。当智能体失败时，你需要知道推理链中的哪一步出了问题。

为此，转换失败矩阵（Transition Failure Matrix）是一个极有价值的工具。将智能体的工作流想象成一系列状态或步骤，就像一条装配线。智能体从一个状态（例如生成 SQL）移动到下一个状态（例如执行 SQL）。转换失败矩阵是一张图表，精确地显示装配线最常在哪个环节断裂。

矩阵的行代表最后一个成功的步骤，列代表发生失败的步骤。通过分析失败的智能体交互追踪记录并将其映射到这个矩阵上，你可以快速发现热点。你不再需要猜测，而是可以通过数据看到——例如，你的智能体最常在尝试执行它刚生成的 SQL 时失败，或者最常在误解工具调用输出时失败。这将调试复杂智能体的艰巨任务转化为一项聚焦的、数据驱动的调查。

有了这些针对复杂系统的针对性评估策略，你现在已经准备好将完整的评估套件运营化了。

第三阶段：将评估运营化以驱动持续改进

拥有一套值得信赖的评估器是一个重要的里程碑，但这并不是最终目标。评估器是工具，评估系统是流程。最后阶段是构建一个创建飞轮的流程，利用你的评估来驱动持续的产品改进。这个系统有两个不同的组成部分：一个防止退步的安全网和一个发现新问题的探索引擎。

安全网：持续集成（CI）中的基于代码的评估

你的首要目标是防止旧 bug 重新出现。最好的方法是将评估器集成到 CI（持续集成，Continuous Integration）管道中。AI 的 CI 基础是黄金数据集（Golden Dataset）——一个精心策划的示例集合，代表了你产品最重要的场景。这不是生产数据的随机样本，而是一个精心构建的压力测试。它应该包括涵盖核心功能的示例、在错误分析中发现的具有挑战性的边界情况（edge case），以及最重要的——为每个你修复过的重大 bug 创建的回归测试。

在每次代码或提示词变更时，你的 CI 管道会用这个黄金数据集运行系统，并使用快速、确定性的基于代码的评估器检查输出。如果任何检查失败，构建就会中断，回归性变更就会被阻止推向生产环境。

关键在于理解这个安全网能做到什么、不能做到什么。一次通过的 CI 构建意味着你没有重新引入已知的失败。它是稳定性的信号，而不是整体生产质量的信号。

探索引擎：生产环境中的 LLM 即裁判与护栏评估

CI 保护你不受"已知的未知（known unknowns）"的影响，而生产环境是发现"未知的未知（unknown unknowns）"的地方。你的生产监控系统是发现新失败模式的探索引擎。这个过程从全面的日志记录开始。你应该记录交互的完整追踪：用户输入、所有中间步骤和工具调用、以及最终输出。

然后，你对这些追踪记录的一个样本运行已验证的评估器。由于许多最重要的评估器——尤其是 LLM 裁判——可能太慢或太昂贵而无法实时运行，这通常是以异步（asynchronous）方式完成的。结果汇入监控仪表盘，你可以在其中追踪关键质量指标随时间的变化。利用你为裁判计算出的 TPR 和 TNR，你甚至可以统计校正其原始输出，以得到系统真实成功率的更准确估计。

对于关键的高影响失败，你可以使用一种称为护栏（Guardrail）的特殊同步评估器。这些评估器在请求路径中运行，可以在用户看到之前阻止、编辑或重新生成回复。大多数护栏是快速、确定性的检查——如正则表达式、关键词屏蔽列表或模式验证器——因为它们必须增加最小的延迟。至关重要的是，它们必须有非常低的假阳性率；阻止一个有效的回复本身就是一次生产 bug。虽然不太常见，但 LLM 即裁判可以被用作护栏，不过只有在应用的延迟预算允许的情况下才行。这个决定涉及一个直接的权衡：在医疗建议等高风险领域，假阴性（让有害建议通过）的代价可能足以证明使用更慢但更强大的内联裁判是合理的；而在创意类应用中，假阳性（阻止有效回复）的代价可能太高了。

闭环：改进飞轮

你的 CI 安全网和生产探索引擎共同运作，创造了一个强大的改进循环。当生产监控标记出一个新的或正在偏离的失败模式时，它会触发新一轮的错误分析。例如，你可能在推出新功能后注意到"位置模糊"失败的激增。对标记追踪记录的手动审查发现，模型正在混淆"West Berkeley（西伯克利）"和（不存在的）"Berkeley West（伯克利西）"。

这一发现以两种方式反馈到开发流程中。首先，你改进产品本身——也许通过优化提示词来更好地处理方向性修饰语。其次，同样重要的是，你改进你的评估工件。你将 West Berkeley 的示例添加到 CI 黄金数据集中。现在，任何重新引入这一特定混淆的未来变更都会被自动捕捉。

这个飞轮——监控、分析、改进、部署——是 AI 产品质量的引擎。它确保每一个被发现的失败，都能让你的系统永久性地变得更聪明、更稳健。

有效的评估系统是一个流程，而非一个仪表盘

构建一个真正能改进 AI 产品的评估系统需要思维方式的转变：从对工具和通用分数的关注，转向一个严格的、以人为中心的流程——识别并解决那些真正重要的问题。

这个流程从错误分析开始，寻找你产品中的真实问题，而非采用通用指标。它依赖一位领域专家和清晰的二元标签来建立一致的质量标准。这个流程要求为每项任务选择正确的工具——对客观规则采用廉价、快速的基于代码的检查，对主观细微之处采用经过严格验证的 LLM 即裁判。最后，它将这些评估器在 CI/CD 飞轮中运营化，创建一个可以帮助你更快发现 bug 的系统。

提示工程（prompting）只是构建优秀 AI 产品的一小部分。真正的竞争优势来自通过一个稳健的评估生命周期来深度理解你系统的失败。这才是让你的团队有信心快速迭代并交付一个持续创造价值的 AI 产品的关键。

常见问题

一篇文章不可能解释关于评估的所有内容。哈梅尔和什雷亚将人们对评估最常问到的问题整理在了这里（PDF 版本在此）。

感谢 哈梅尔(Hamel) 和 什雷亚(Shreya)！更多内容请查看他们的课程——使用优惠码 LENNYSLIST 享受 35% 折扣（他们有史以来提供的最大折扣）。

祝你度过充实而高效的一周 🙏

如果你觉得这份通讯有价值，请分享给朋友，如果还没订阅的话，也请考虑订阅。有团体折扣、礼品选项和推荐奖励可用。

此致，

Lenny（莱尼）👋