“难以评估”是产品异味

过去三年，AI 评估一直是我的专业重心。1

我听到的关于评估最常见的反对意见是“我们的产品很难评估”。这种反对意见是一种产品气味（product smell）。你难以验证的产物，用户往往也难以验证。在最坏的情况下，用户必须从头重做工作来验证输出。更重要的是，在设计评估之前，应该先让你的产品易于验证。在这篇文章中，我将介绍我提供过咨询的三个产品，它们都面临过这个问题。我还会展示改进前后的草图，以演示设计原则。在这些例子之后，我将讨论如何将这个通用模式应用到你的产品中。

示例 1：AI 数据代理

我合作过的几乎每家公司都在构建内部 AI 数据代理。你可以向它提出业务问题，比如上个季度产品 A 的净收入是多少，它会找到相关的数据源，运行查询，并提供答案。这个代理的目标是减少对数据分析师的依赖。

构建 AI 数据代理时一个常见的错误是让答案成为唯一的输出，如下所示。

在上面的草图中，用户除了重做工作之外，没有其他方法可以验证答案。2

更好的设计是为用户提供可检查的产物，其灵感来自于领域专家验证输出的方式。以下是我作为数据科学家用来验证指标的一些技巧：

• 将数量及任何中间计算与可信来源进行比较，例如经过验证的仪表板或报告，或者同事已经验证过的类似分析。3
• 精确定义指标。像净收入这样的数字可能包含或排除退货和折扣等项目。
• 对相关数量进行合理性检查。如果我无法直接验证这个数字，我会拉取一个应该与之同步变动的相关数字，比如销售数量或唯一客户数，并检查组合是否合理。
• 查看聚合数据之下的内容。总数可能隐藏问题，所以我按地区或时间段等维度进行分解，并对分布进行合理性检查。
• 阅读查询。对于重要的数字，我会查看 SQL 以确认它按我的预期执行，然后调整并重新运行以测试我的假设。
• 记录我无法验证的内容。如果某个步骤没有可信的参考可以对照检查，我会标记它，而不是将其作为已确定的事实呈现。

下面是一个更好的界面可能的样子。下面的两个选项卡以两种详细程度显示相同的答案。聊天回复展示了值得预先看到的细节，而 notebook 则包含了答案背后的完整分析。使用选项卡在它们之间切换。

这里有很多值得解读的地方。以下是一些显著的变化：

• 代理可以选择性地从经过验证的分析中进行检索，界面会显示使用了哪个分析以及谁编写的。
• 细节是渐进式披露的。聊天回复显示了高价值项目，如来源、假设和问题。用户可以选择打开一个交互式 notebook 来查看完整的上下文。
• AI 生成的 notebook（见上面的 notebook 选项卡）组织有序，以促进验证：它首先展示了代理所做的假设，比如指标定义及其来源，然后展示了它运行的查询以及返回的数字。它将总数分解，以便你可以对分布进行合理性检查，最后列出了它无法验证的内容，每个项目都作为一个你可以运行的 cell 保留下来。AI 代理也可以在 notebook 中用于处理后续问题。
• 最后，用户可以将 notebook 发布回知识库，未来的分析可以从中检索，从而形成一个良性循环。

这个设计草图远非完美。关键在于，产品应该像领域专家那样帮助用户验证答案。将其与之前的方法（唯一输出是一个数字）进行比较。

像这样的数据代理并非科幻小说。Hex 4 是我在这个领域最喜欢的产品；它比我见过的任何产品都更好地集成了 notebook 和聊天。以下是他们着陆页的截图：

• 聊天界面。
• Notebook 视图，允许用户查看中间步骤和数据。

但这与评估有什么关系呢？如果你为验证而设计产品，标注成本就会降低，评估也将有更好的信号可以利用。更重要的是，你将为用户提供更好的产品。

示例 2：PE 课程构建器

我提供过咨询的一位创始人正在构建一个 AI 工具，为 K-12 教师编写体育课教案。教师输入他们的约束条件，比如他们教的年级、课堂时长、是在室内还是室外上课，以及他们有什么设备。然后，该工具会为这些约束条件编写一份教案。目标是节省教师用于规划的时间，并为他们提供适合其课堂的计划。

以下是产品外观的草图：

创始人问我如何评估这些教案。我反过来问：教师关心什么？信任一个计划最快的方法是看到像他们一样的教师已经在使用它。此外，教师重视了解其他人在做什么，以便学习新方法。因此，更好的设计可能从学校中积极使用的经过验证的教案开始。当工具生成一个计划时，它会显示它从哪个经过验证的计划开始，谁在使用该计划，以及针对这位教师的约束条件所做的更改的 diff。接下来，教师可以对照他们已经信任的计划检查一小部分更改，而不是从头开始评判整个计划。

以下是更好界面可能的样子：

在这个版本中，大部分计划继承自一个经过验证的计划。教师的审查范围仅限于几个编辑，每个编辑都有解释为何进行更改的原因。这是一种更有效的审查计划的方式，因为它减少了从头判断整个计划的认知负担。为此进行设计使产品更容易构建。该工具不是将数百个示例塞进 prompt，而是捕获重要维度，检索接近的匹配项，并进行调整。自动化评估现在变得可行，因为需要测试的表面积更小了。例如，你可以验证计划检索是否选择了合理的锚点，并且每个编辑都遵守了约束条件。

示例 3：工伤赔偿医疗报告

最后一个例子来自一位创始人请我帮助的工伤赔偿工具。它读取患者的病历（入院表格、影像报告、治疗记录、既往检查），并生成一份冗长的专家意见报告，通常有五十页或更多。以下是产品草图：

问题与其他例子相同，但风险更高。唯一的输出是报告，而医生是最终对其负责的人。为了信任它，他们必须回到病历中，自己确认事实和推论。这可能和从头写报告一样耗时，这违背了该工具的目的。

你可能会反对说，一份五十页的意见很难验证。这是事实，产品不应该假装不是这样。帮助医生理解证据可以说比最终文档更有价值。因此，我建议创始人让产品像研究助手而不是报告生成器一样工作。例如，产品可以读取每条记录并提取相关事实，并附上返回页面的链接，以便医生检查每一条。当两份检查结果不一致，或者病历留下一个未解决的问题时，产品应该将其呈现出来。然后，医生可以解决任何矛盾并填补空白。最后，产品可以根据他们已经检查过的内容来组装最终报告。

以下是可能的样子：

这个研究助手版本的产品允许医生通过逐步验证事实来建立信任。与其他例子类似，这种设计更容易构建和评估。现在有了可以评分的范围化单元，例如矛盾是否真实存在，或者引用是否支持某个声明。

推广该模式

理解用户如何验证你产品的 AI 产物至关重要。有时，这可能需要组装支持性证据。在其他情况下，这可能意味着重构整个工作流程，以便用户参与其中（如工伤赔偿的例子）。以下问题可以指导你的产品为验证而设计：

• 用户实际需要检查什么？
• 他们可以将其与什么可信的东西进行比较？
• 专家是否使用某些信号或启发式方法来辅助验证？
• 他们可以接受、编辑或拒绝哪些较小的单元？

这些例子中的一个共同点是来源（provenance）。使输出可检查的最快方法是显示每个部分的来源，并附上查看更多细节的链接。此外，你可以使用渐进式披露，这样这些来源就不会让用户不知所措。随着用户信任度的增长，需要验证的内容也会发生变化。早期，数据代理应该使来源显而易见，比如指标定义来自哪里。一旦用户信任代理能正确完成，该细节可以在卡片中默认折叠。好的设计会适应用户所处的阶段，而不是展示所有内容。

即使产品看起来很容易评估，这些原则也适用。编码是一个很好的例子：它是最可验证的工作类型之一，有测试、类型和 diff。即便如此，一些编码代理也会不遗余力地使其工作可检查。Cursor 和 Devin 都会录制它们所做 UI 更改的短视频，这样你无需自己重现即可确认工作正确。5

这些都不是新东西

评估思维与良好的产品设计是一致的。收集支持数据并将工作流程分解为更小的单元使自动化评分更容易。然而，我不想假装这里的任何智慧是新的。所有这些想法都源于成熟的设计原则。例如，在构建之前观察专家的工作以了解他们检查什么，这被称为需求发现（needfinding）。6 在像医疗案例这样的研究密集型工作中，有一个设计目标叫做意义建构（sensemaking），即构建一个你可以推理的证据体的结构化理解的工作。7 还有许多其他概念，但我认为你明白了。

尽管这些想法已经很成熟，但在 AI 时代还是有必要提醒一下。在 AI 之前，验证通常是在创建工作产品的过程中偶然发生的。有了 AI，验证成了瓶颈。是时候更明确地思考它了。

感谢 Shreya Shankar 和 Isaac Flath 对本文的反馈。要了解我关于 AI 评估的最新文章，请订阅下面的 newsletter。

脚注

1. 我关于评估的更多文章和教学：Your AI Product Needs Evals, A Field Guide to Rapidly Improving AI Products, Using LLM-as-a-Judge for Evaluation, LLM Evals: Everything You Need to Know, Selecting the Right AI Evals Tool, Evals Skills for Coding Agents 和 The Revenge of the Data Scientist。我还共同教授 AI Evals for Engineers & PMs 课程，并合著了 O'Reilly 的书籍 Evals for AI Engineers。↩︎
2. Lenny Rachitsky 最近在推特上提到了这一点：一个数据科学团队的大部分工作现在是审查来自 PM 和工程师的半成品 AI 分析，其中一半是错误的。↩︎
3. 我在 Airbnb 工作时，我们有一个名为 Knowledge Repo 的内部工具，这是一个数据科学家发布他们关于分析、建模等深度研究的 notebook 的地方（他们在这里写过）。这是了解新项目背景最快的方法之一，因为你可以阅读别人已经完成的工作。我不知道它是否仍在使用，但这个范式是好的。↩︎
4. Bryan Bischof 领导了 Hex 的 AI 创建。Bryan 本人就是一名数据科学家，是该产品所服务的领域专家，我认为这是它设计良好的部分原因。↩︎
5. 查看 Cursor 录制其 UI 更改的演示，以及 Devin 关于测试和录制的文档。↩︎
6. Dev Patnaik 和 Robert Becker，“Needfinding: The Why and How of Uncovering People's Needs”，Design Management Journal。↩︎
7. Daniel M. Russell, Mark J. Stefik, Peter Pirolli, 和 Stuart K. Card，“The Cost Structure of Sensemaking”。↩︎