新博客文章：自动化评估真的有效吗？

越来越多的工具开始利用AI审查追踪记录并识别问题。我们使用真实生产数据测试了这些工具，看看它们的表现如何。

它们的亮点：

• 常能发现人工遗漏的问题
• 可融入工作流：查看追踪记录、创建LLM评判器等等

它们的短板：

• 会遗漏需要领域专业知识和品味的问题
• 缺乏从人类反馈中学习的良好机制
• 使用你的编码代理也能获得类似结果

那么该不该用？要用，但必须让人类参与迭代过程。我们在文章中描述了具体做法：https://parlance-labs.com/blog/posts/auto-evals/…

也可以尝试让你的编码代理参与进来，文章中对此做了讨论。

本文由 @doesdatmaksense 共同撰写，他主导了研究并整理结果。

自动化评估真的有效吗？ – Parlance Labs

来源：https://parlance-labs.com/blog/posts/auto-evals/

过去三年里，对于AI评估的大多数问题，我们都给出同样的建议：查看你的数据。1

实际上，查看数据意味着进行错误分析2，也就是阅读生产环境中的追踪记录（或日志），并归类产品失败的模式。回顾追踪记录也会改变你的关注点。你需要标准来评判输出，但评判输出恰恰是发现标准的过程，这种现象被称为“标准漂移”。因此，我们曾反对将评估外包给LLM。3

如今，流行的评估工具却朝着相反的方向引导用户。Braintrust、Arize 和 LangSmith 各自推出了一个智能体（Loop、Alyx 和 Engine），它们会读取你的生产追踪记录并报告失败情况。4 编码代理已足够强大，能从一个包含日志文件或追踪记录的文件夹中尝试完成同样的工作。我们相信，在任何有帮助的工作流中都应该使用AI。然而，这些工具带来的诱惑是彻底将人排除在循环之外。这就引出一个重要问题：这些系统能自行发现多少问题？它们又会遗漏什么？

Braintrust 的 Loop。 (https://parlance-labs.com/blog/posts/auto-evals/images/braintrust.png)

Braintrust 的 Loop。 Arize 的 Alyx。 (https://parlance-labs.com/blog/posts/auto-evals/images/arize.png)

Arize 的 Alyx。 LangSmith 的 Engine。 (https://parlance-labs.com/blog/posts/auto-evals/images/langsmith-clean.png)

LangSmith 的 Engine。

为了找到答案，我们进行了测试。首先，我们准备了一个包含100条追踪记录的数据集，来自一个真实公寓租赁AI系统，并在领域专家的协助下手工标记了失败案例。然后我们隐藏了这些标记，要求每个系统自行审查追踪记录并找出错误。这样我们就可以比较人工错误分析与自动化分析的差异。

自动化系统的表现令人印象深刻。表现最好的系统找出了人类标记失败的87%。此外，每个系统都发现了人工遗漏的问题。但缺点也很明显。完全自动化的方法总是无法捕捉到那些“看起来正确”但未能提供优质用户体验的交互。这些系统还标记了不少并非失败的问题，增加了噪音。

本文其余部分将介绍实验过程、结果，以及如何调整该方法才能使其有效。

在这篇文章中，我们将向你展示如何安全地按下按钮而不陷入陷阱。 (https://parlance-labs.com/blog/posts/auto-evals/images/auto-evals-cropped.jpeg)

在这篇文章中，我们将向你展示如何安全地按下按钮而不陷入陷阱。

实验

这些追踪记录来自一个真实的公寓租赁AI智能体。5潜在租户通过短信或电话咨询公寓信息，智能体负责回答问题并安排看房。某些对话应转交给人工处理。重要的是，本次实验使用的是真实客户的追踪记录，而非合成基准。6

为了准备数据集，一位领域专家按照错误分析流程7手工标记了100条追踪记录。这次审查产生了一个失败分类法，包含39个已标记的失败案例。

然后我们隐藏了所有人工标注，将追踪记录按以下提示输入每个系统：

注意：每个系统的提示完全相同

@nurtureboss\_evals\.jsonl 是一个公寓租赁AI客服（电话和短信）的生产追踪记录。每条记录包含完整对话以及所有工具调用及其输出。

分析这些追踪记录并：

1. 找出数据中反复出现的失败、风险和常见质量问题。
2. 尽可能将相关追踪记录归入问题集群（为每个集群命名）。
3. 对于每个集群或问题，列出示例追踪记录标识符（例如元数据中的 trace_id 或 session.id）。
4. 说明哪些追踪记录看起来正常或不确定，不要假设所有记录都失败。
5. 如果可能，建议候选评估指标（衡量什么以及如何衡量），无需参考任何外部评分标准。

请具体说明：尽可能引用对话轮次或工具步骤。避免泛泛而谈，除非你能提供追踪记录中的证据。

这个提示故意写得比较简略。它简要描述了产品以及如何组织发现，但丝毫没有提及我们已经知道的失败。根据我们教授评估课程的经验，这也是我们预期大多数用户开箱使用这些产品的方式。这里是数据集中一条追踪记录的匿名示例。

最后，我们想体验每个产品的工作流程，并希望这些工具在开始分析前会向我们提出后续问题或征求需求。但它们基本没有这样做。

我们对每个系统按三个维度评分：

• 召回率：发现了39个人工标记失败中的多少个。
• 精确率：标记的错误中，多少是真正的失败。若标记与人类标签匹配，或属于人工审查遗漏的真实问题，则视为有效。
• 发现：人工审查中未出现的有效标记。

在公布数字前需要说明一点：本次实验只有一个包含39个标记失败的数据集，因此系统间的差异仅由少数追踪记录决定。这并不能证明某一供应商优于另一供应商，而且排名也非本实验目的。7我们着重探讨的是这些系统的优势与不足。

工具的成功之处

当失败在追踪记录中显而易见时，每个系统都表现良好。所有系统都发现了不受支持的时间安排声明、对用户已确认的重复请求、未兑现的后续承诺，以及与工具输出相矛盾的答案。

每个系统还发现了人工审查遗漏的17到20个小问题。例如，在某条追踪记录中，智能体成功安排了看房，人工审查者标记为正常。但Braintrust和Arize都注意到，助手在用户已给出确认后，仍然要求用户短信确认。

Braintrust Loop

Braintrust在这三个平台中召回率最高，且易于使用。我们可以上传追踪记录，执行自动评估，并无缝导出结果。它也不会强迫为每条记录标记问题，会将一些对话标记为正常或不确定，使其发现更可信。

高召回率的代价是误报。其标记中有9个错误，通常是因为Loop对完整性的要求过于严格，或者将内部工具元数据视为理应告知用户的信息。这些发现听起来很有说服力，直到我们重新阅读完整的追踪记录。

Arize AX Alyx

Arize用召回率换取了精确率。Alyx遗漏的人工标记失败比Loop多，但其标记的91%是有效的，只有3个错误。8它特别擅长发现没有工具输出支撑的说法。它标记了助手将普通一居室称为“阁楼”、将最便宜的市场价单元作为经济适用房选项、在无楼层信息的情况下回答楼层问题，以及承诺回电却无任何后续行动等问题。

LangSmith

LangSmith在阅读单条追踪记录方面拥有最好的界面。对于分析本身，我们尝试了它的两个工具。Engine正是为此类任务设计的。它能发现反复出现的问题，并将每个问题链接到相关的追踪记录。但它只暴露了少量问题，远少于完整审查所能发现的，因此我们无法将其用于100条追踪记录的对比。评分实验我们使用了LangSmith的聊天代理。

当LangSmith的聊天代理标记真实失败时，它通常能引用具体的消息或工具调用，使其发现最易验证。其弱点是严重程度评级。有几个错误的发现被标记为高严重性，夸大严重性会误导团队决定优先修复什么。

编码代理

通用的编码代理，如Claude Code、Codex和Factory Droid，与专用平台不相上下。它们收到了相同的提示和相同的隐藏追踪记录。这些编码代理引用了确切的工具参数、日期、价格和矛盾值作为失败证据。它们还捕捉到了平台遗漏的细微失败，包括将实地看房链接当作虚拟看房确认。

仅从发现的质量来看，编码代理和专用平台大致相当。平台的优势在于分析周围的工作流程。它们将发现与源追踪记录保持关联，并为我们提供审查和注释的空间。当新追踪记录到来时，它们还可以重新运行分析。

所有系统遗漏的问题

遗漏并非随机。所有系统都遗漏了同一类失败。在这些案例中，追踪记录看似正确，但智能体并未达到产品的真正目标。我们的人工审查发现了几个没有系统能可靠标记的问题：

• 销售异议处理：智能体的工作是租赁公寓，但在第一次遇到反对时就放弃，而不是解决潜在租户的顾虑。
• 短信中的Markdown：智能体用Markdown格式发送短信，在手机上显示为多余的星号和井号。
• 打断对话：语音智能体在通话中打断对方，而不是让他们说完。
• 错过转交：物业规定某些对话必须转给人工，但智能体自行处理了。

仅仅查看追踪记录无法发现这些失败。一份助手礼貌接受潜在租户反对并结束对话的转录看起来像一次成功。追踪记录中没有信息表明对话是通过短信进行的，也没有显示哪些情况下业务承诺要升级处理。

显然，有人会反驳说我们故意隐瞒了这些上下文，而真实团队会提供这些信息。但团队无法提供尚未发现的上下文。例如，在处理这个产品时，我们只有在阅读了一条潜在租户放弃的追踪记录后，才发现需要异议处理。这种在见到数据之前不知道好坏的现象，被称为“标准漂移”。9

我们本应怎么做

我们能否引导这些系统捕捉到它们遗漏的问题？几乎可以。如果我们描述了该产品的好与坏是什么样子，大多数遗漏的失败都是每个测试工具力所能及的。但在首次开始评估时，这种完美的描述几乎不存在。

我们测试的所有系统都没有做最有用的一件事：与我们进行访谈。每个工具都将错误分析视为一次性任务：输入追踪记录，输出报告。

我们不会把错误分析当作一次性任务。相反，我们会自己标注追踪记录，并让AI持续从标注中学习。我们的同事Shreya Shankar10在下面的视频中演示了这个流程。她让编码代理为她的追踪记录构建一个小型审查界面，然后标注让她不满意的地方。代理实时观察她的标注（她使用了Claude的监控工具11），从中学习失败分类法，并带回新的可疑实例供她确认或驳回。每一轮迭代都将更多的产品上下文整合进评估套件。她仍然是评判者，但代理使评判变得高效。

作为AI产品构建者，你应该保持参与，而不是完全将评估外包给AI。如果一个工具能自行发现并解决所有问题，那么它也能为你的竞争对手做同样的事，你的产品将毫无差异而言。要想脱颖而出，查看你的数据。

附注：希望获得评估方面的实操帮助？请查看我们的AI评估课程12，一个包含指导练习和答疑时间的直播班。链接中有读者折扣。

脚注

1. Hamel与Shreya Shankar共同讲授《AI评估工程师与产品经理》课程13，并合著了O’Reilly书籍《AI工程师评估》14。↩︎ 1
2. 关于错误分析包含什么以及为何它应优先进行，参见我们的错误分析FAQ15。↩︎ 2
3. Hamel在《数据科学家的复仇》16中提出了这一论点。↩︎ 3
4. Braintrust Loop17、Arize Alyx18和LangSmith Engine19。↩︎ 4
5. 该公司是Nurture Boss20，一个公寓管理AI助手。Hamel在《快速改进AI产品现场指南》21中描述了他们的错误分析过程。↩︎ 5
6. 我们已获得该公司许可分析和撰写这些追踪记录，但未获准重新分发，因此无法公开发布数据集。↩︎ 6
7. 我们与本文提及的任何供应商均无关联，也未获得任何赞助。↩︎ 7
8. 工作流程存在一些问题。Alyx最初只读取每条追踪记录的前200个字符，后续运行遇到压缩和超时问题。Arize团队在我们报告后迅速解决了每个问题。Alyx也无法按我们要求的格式将分析结果写回数据集，因此我们将结果复制到电子表格中进行手动审查。↩︎ 8
9. 标准漂移在Shreya Shankar的博客《你的LLM评估可能满是漏洞》22中有所记录。↩︎ 9
10. Shreya Shankar是哈佛大学博士候选人，曾任职于Spotify、Google、Meta和Vercel。↩︎ 10
11. 查看Claude代码监控工具23。↩︎ 11
12. AI评估课程（使用优惠码parlance-c6）24。↩︎ 12