AI产品的评估困境正在成为行业痛点。当Agent获得多轮对话、工具调用等高级能力时，传统的黑箱测试方法已完全失效。本文深度拆解Anthropic提出的评估体系框架，从代码评分器到人类质检的黄金标准，剖析如何用结构化Trace和分层评估打破'盲飞'状态，为AI产品经理提供可落地的质量提升方案。

担任 AI 产品经理以后，我最大的痛苦，不是把东西做出来，而是把它做好。

现在做一个60分的Agent真的越来越容易了，扣子、Dify的可视化编排，或者更轻量的知识库产品，把文件丢进去，最简单的Agent就做出来了。

但真正难的是：怎么样从60分达到90分？

之前我花了很长的时间调提示词、换切片、加召回、上重排。每一个单点的优化，似乎都能提升质量，但上线后数据却没有什么变化。

我陷入了一个黑盒，我不知道这次改动是让模型在A问题上变好了，但会不会在B问题表现得更差，甚至还有引发了C和D的问题。

你没有证据证明它变好，也没有证据证明它变差。

Anthropic 把这种状态形容为”flying blind”，看不见仪表盘、飞机外完全没有能见度，只能凭直觉赌概率。

所以，我们才需要对AI产品建设评估体系。

让Agent变强的那些能力，恰恰让它更难评估

多轮对话、工具调用、状态修改、临场发挥，这些赋予Agent自主性的能力，也让Agent的不确定性变得更高。

而应对不确定性事物的办法，只有一个：对它进行工程型的拆解。

一次评估，本质上是一次结构化的测试，给系统输入，再用评分逻辑判断是否成功。让评估告别感性的还不错，让它变成更理性、可重复运行的机制。

每一条测试用例，都可以理解为是上图的Task，它拥有输入和期望的输出，作用是在后续再次运行这条输入的时候，用实际输出和期望输出去进行比对。

而比对的结果，用评分器（Garder）来判定。

它基于用例的表现，对它设置的1个或者多个评估指标。大多数情况下，这些评估指标锚定在AI产品的输入、期望输出、实际输出。

最重要的部分，在我看来是博客中所说的Trace，也就是轨迹。

Trace可以理解为一次请求，用户的一次输入和模型一次输出，以及这个过程中发生的所有事情。

一次AI产品的端到端请求，过程会经过无数的节点，例如意图识别、知识库召回、切片重排等等。

Trace的目标是让我们看见过程中到底发生了什么，让我们在出现问题的时候至少死个明白。

不要用一种方式衡量所有的Agent：代码、模型、人类

评分器，是Anthropic在博客中评估体系的核心组件：它决定了你如何衡量Agent的表现。

代码评分器

代码评分器最快、最便宜、也最客观，它擅长判断”有没有”、”对不对”、格式对不对、字段齐不齐。但一旦遇到开放问题”哪个回答更好”、”这个答案有没有温度”，它就彻底失效了。

模型评分器

所以也会引入模型评分器，也就是LLM As Judge。

大模型的突破在于能够理解自然语言，所以它能够评估开放式任务的答案质量。

这是Regas关于正确性的指标描述，方便朋友们更直观的理解。

它的局限性是什么呢？大模型本身的输出就不是确定性的，我们用不确定性评估另一种不确定性，本来就是在走钢丝。

这就像让一个醉汉去判断另一个醉汉走没走直线，当涉及到到上下文相关性分析的指标时，上下文变长、Token会暴增，随之而来注意力机制下降，导致出现幻觉。

人类评分器

这一个部分是最贵的，也是最真实的。传统的AB实验依旧有效，人工质检依然是黄金标准。但我们很难天天请业务专家为我们 Agent打分，用户也很少愿意认真反馈。

目前来看比较折中的办法还是代码+质检64开，确定性的部分尽量用代码搞定，剩下的再用人或模型兜底去解决。

不要幻想一上来就做完美的评估系统

Anthropic也这么说：尽早开始！！！Start now，start early！！！

从第一天就要开始沉淀你的评测集，去维护你的输入和期望输出，然后把Bad Case，无论是自己测试出来的还是用户反馈的都沉淀下来。

当有了评测集后，再逐渐考虑均衡性的问题，这个节点的用例会不会太多，每个节点是否平衡，不断地提升自己的覆盖范围。

第二个部分，就是建设自己的评估指标，作为AI产品，到底怎么评估自己的AI产品好和坏呢，尽可能采取确定性的评分。

例如在信息提取的Agent，可能是字段的完整性、准确性。在咨询类的Agent，可能是意图分类的准确性，在答案质量环节才基于LLM做相关性、相似性的评估。

追踪让你死得明白，评测保障看见未来。

Anthropic官方博客-Demystifying evals for AI agents

https://www.anthropic.com/engineering/demystifying-evals-for-ai-agents