评估AI智能体是一件很难做好的事情。以下是Rapidflare用来测试智能体、捕捉回归问题并保证发布信心的框架。

本文最初发布于Rapidflare官网，经Rapidflare授权转载。

评估智能体面临的挑战

在智能体开发早期，可以在一段时间内依赖人工测试。挑选几个具有代表性的任务，自己使用系统，修复明显的问题，然后继续推进。当涉及面较小、需要关注的行为还能靠人工检查时，这种方式是有效的。

但当智能体开始处理更多工作流和面对更多真实用户时，问题就出现了。一次改动可能让某部分变好，却在悄悄削弱另一部分，如果没有结构化的评估套件，很难判断某个报告的问题究竟是真正的回归、孤立的偶发情况、数据问题，还是单纯的噪声。

Rapidflare为电子行业的技术销售与支持构建垂直领域的AI智能体。这些智能体负责回答产品问题、比较零部件、生成推荐方案、支持提案流程，并对密集的技术文档进行推理。

评估这类系统并非易事，因为需要判断答案是否事实正确、是否基于正确的信息来源、对用户是否有用，以及在模型、提示词和底层数据不断变化的情况下是否依然可靠。

本文将介绍Rapidflare构建的系统化评估框架：如何组织评估、设计测试用例、选择评估器，以及如何将失败案例转化为可执行的改进措施。

评估的基本结构

在深入细节之前，先厘清评估的基本形态很有帮助。每个评估都包含三个部分：

数据集：问什么问题，以及什么算作成功。

目标：被测试的对象。

评估器：如何对输出打分。

Rapidflare的框架建立在这个结构之上，主要组成部分如下：

测试用例是一个具有明确输入和预期行为的场景。在数据集中，每个用例都包括用户查询、期望答案满足的断言，以及诸如特征、干扰项和用例目标等元数据。

用例规范是测试用例中经过设计的部分：答案必须满足的断言，以及描述该用例测试内容和难点的特征、干扰项和目标。这些字段将在后文详细介绍。

数据集是测试用例的集合。它还声明了应运行哪些评估器，以及可选的应针对哪些配置进行测试。

目标是被评估的系统。对Rapidflare而言，通常是运行与生产环境相同代码路径的智能体或端点。

运行器负责针对目标执行数据集。它将每个用例发送给目标，收集输出，应用评估器，并将结果传递给报告层。

评估器从不同维度对输出打分：正确性、相关性、清晰度、工具使用等。该框架内置了常见评估器，如果某个数据集需要评估特定行为，可以定义自定义评估器并接入同一流程。

轨迹是某个用例执行过程的完整记录：输入、输出、工具调用、检索到的上下文、中间步骤以及评估器结果。

报告是运行结束后呈现结果的方式。Rapidflare使用LangSmith作为报告层，因此每次运行都会在同一处呈现每个用例的分数、评估器输出和轨迹。

最后一部分是运行矩阵。它可以让同一数据集在不同配置（例如提供商、模型或思考预算）下运行，并对结果进行并排比较。

数据集是设计工作的核心

用例来源

评估数据集需要能代表实际生产流量中的数据，这一点很重要。这意味着用例要来源于生产环境，但不能只是随机抽样，还需要有意识地挑选哪些对话纳入数据集。例如，关注高信号对话：带有反馈（正面或负面）的对话、能看出用户不满情绪的对话、发生转接或升级的对话，以及用户不断深挖问题的长对话线程。

Anthropic在其智能体评估指南中也提出了同样的观点：如果已经在生产环境中运行，可以查看bug跟踪系统和支持工单队列。将用户报告的失败案例转化为测试用例，能确保测试套件反映真实使用情况；按用户影响程度排定优先级，有助于把精力投入到真正重要的地方。

除了使用生产流量构建数据集，还可以利用合成测试用例生成方式来扩大用例覆盖面。

不过，合成数据集的创建需要谨慎使用。不应为了一个从未在生产环境中真正出现过的边缘情况，而过度打磨智能体的相关行为。初期阶段，最好从真实的生产数据入手，并让人工始终参与其中。手动审查数据有助于建立对评估套件到底在衡量什么的直觉认识。

断言而非参考答案

参考答案看起来是评分的显而易见的方式，但存在一个问题。一个好的答案往往需要涵盖多个事实、约束条件、权衡取舍和注意事项。如果参考答案和模型答案都又长又密集地包含事实，评判者就容易失去焦点。它必须判断哪些事实最重要、哪些遗漏的细节可以接受，以及答案在方向上是正确的还是实际上错了。

这正是Rapidflare选择用断言而非参考答案来评分的原因：用简短、可核查的规则，把响应中重要的部分明确列出来。

每一条断言都旨在单独考察预期行为的某一个方面。不过这仍然留有歧义空间。普通语言对不同的评判者可能意味着不同的东西。“最好有”的内容是必须的吗？如果说“推荐A或B”，只推荐B算不算满足？为避免这种混淆，Rapidflare统一了几种模式，并告诉评判者该如何解读它们。

让评判者明确了如何解读断言之后，还需要提供一个简单的评分标准：

评分（使用0.0-1.0的完整范围，不要简化为0/1）：

1.0 = 完全满足参考标准；无矛盾，无捏造

0.7 = 主要内容正确；遗漏一个次要细节

0.5 = 主要内容正确，但存在部分抵消因素

0.3 = 主要内容遗漏，但提供了一个不与参考标准矛盾的合理替代方案

0.0 = 事实矛盾、捏造或拒绝回答

关键在于要有一套锚定于断言的评分细则。这就是Rapidflare设计评判细则的方式：每个分数都必须能对应回答案满足或未满足的具体内容。评分细则留下的歧义越多，评估中引入的噪声就越多。

特征、干扰项、目标

至此，已经明确了测试用例的来源以及如何定义评估标准。但还有一个值得追问的问题：这个测试用例为什么存在，为什么它是数据集的合适候选？

可能你心里已经有答案：这个用例测试的是检索能力，或约束处理能力，或多轮记忆能力。这种直觉很有用，但如果能将其正式化为测试用例的一部分，价值会更大。

Rapidflare首先为数据集添加了元数据字段，从特征开始。

特征指的是被测试的能力。

干扰项描述了该用例的棘手之处。受Chroma生成式基准测试工作的启发，Rapidflare会标注用例中的具体陷阱，例如令人困惑的产品名称、过时的规格，或者一个看起来正确但违反用户约束条件的数字。

目标说明该用例旨在验证什么。它应描述被测试的行为，以及该用例想要捕捉的回归问题。

一个完整设计的用例

这就是Rapidflare数据集中一个完整设计的测试用例的样子。

每个维度一个评估器

不应该让一个万能的大语言模型评判者承担全部评分工作。单个评判者很容易混淆不同维度：正确性、清晰度、相关性、工具使用等所有方面都被混在一个分数里。

Rapidflare发现让评估器保持专注更有效。每个评估器只关注输出的某一个特定方面，这样分数才能真正说明哪里通过、哪里失败：

正确性：是否满足了断言？

清晰度：是否易读？

相关性：是否回答了实际提出的问题？

以及更多维度。

这种拆分在Rapidflare自己的运行中很有用。在一类用例中，智能体给出了明确的推荐，但其中一个建议产品违反了用户的硬性约束。如果只有一个总分，这个失败很难解读。而有了独立的评估器后，清晰度可以通过，正确性可以失败，这让问题更容易诊断。

除了按维度拆分评判面板外，Rapidflare还推荐以下几个评估器设计选择：

谨慎使用大语言模型评判者。如果某项内容可以通过代码确定性地检查，通常就应该这样做。格式验证、精确匹配比较、模式检查和工具执行都是很好的例子。确定性检查比大语言模型评判者更便宜、更快、也更一致。把大语言模型评判者留给那些确实涉及主观判断的场景。

对临界判断使用一致性检验。同一个答案在不同的评判调用中可能得到略有不同的分数，尤其是当它接近通过/失败边界时。例如，在评估正确性时，Rapidflare会独立运行评判者三次并取分数中位数。在实际运行中，这样做通过消除评判者的方差性失败，将测得的正确性通过率提高了约五个百分点。

设计好的用例能让你看到什么

这正是元数据发挥作用的地方。

总体通过率是有用的，但它只是一个摘要。如果测试套件的通过率从82%提升到85%，仍然需要理解具体是哪里改进了。如果从85%降到80%，也需要知道该从哪里入手排查。一旦每个用例都附带了特征、干扰项、目标、评估器分数和轨迹，汇总分数就会变得更容易解读。

第一个有用的视角是按特征切片。除了只问测试套件是否通过，还可以查看哪些能力较强、哪些能力需要改进。例如，如果规格查找表现良好，但约束满足表现较弱，说明智能体可能找到了正确的事实，但没有正确应用用户的所有要求。这需要与检索失败不同的修复方式。

在查看汇总结果后，Rapidflare会进一步仔细检查失败的用例。这可以由人工审查者完成，也可以借助另一个评估器完成，但关键是要看得比最终答案更深入。对于智能体系统而言，路径很重要：智能体检索了什么、调用了哪些工具、依赖了哪些数值，以及评估器在哪里出现了分歧。

为此，Rapidflare使用LangSmith作为可观测性层。它将失败用例的完整轨迹集中存放在一处，包括输入、检索到的上下文、工具调用、中间步骤、最终答案和评估器反馈。

从最高层面看，大多数失败可归为三类之一：

智能体问题：提示词、工具使用、推理路径或最终验证需要改进。

数据问题：源数据缺失、过时、解析错误或本身有误。

测试问题：断言、评分细则或评判者评估的内容有误。

在对失败进行分类后，如果有助于解释失败模式，Rapidflare会添加更具体的标签：检索遗漏、幻觉性主张、硬性约束违反等等。

一旦失败被分类和标注，就可以在整个测试套件中寻找模式。例如，在热力图中，许多推荐匹配度失败源自检索遗漏。这很有价值，因为它说明智能体可能一开始就没有看到正确的产品，因此修复方向更可能是检索环节，而非回答撰写环节。

整合起来

评估的价值在于它能让你多快地迭代。前期确实需要投入真实的工作量：收集合适的用例、编写断言、定义特征、选择评估器，并让报告变得有用。但一旦这个基础搭建好，每一次新的实验都会变得更容易解读。

对Rapidflare团队而言，这项投入很快得到了回报。有了这套框架，团队在大约一个月内评估并向3个客户上线了一个新智能体。它还让团队有信心用一个成本更低的模型替换掉成本约为其三倍的前沿模型，因为评估结果表明，这个更便宜的模型不仅更快，而且给出的答案质量更高、更易读。如果没有这套测试套件，这种替换将是一次盲目的冒险；而有了它，这就成为了一个由数据支撑的常规决策。

还有一个不那么显眼的好处。客户会注意到Rapidflare评估的严谨程度，在改动上线前向客户展示测试内容，本身就成为建立信任的一种方式。

这一点很重要，因为评估不仅仅是事后衡量质量的手段，它还能帮助团队更快地做出改动、理解改动带来的影响，并向依赖该智能体的人清楚地说明这些工作。

本文介绍的是基础内容：即拥有一个查询和一组基准事实、据此对答案进行评分的评估方式。这是一个有用的起点，但随着智能体变得更加复杂，它还不是你需要的完整体系。

随着智能体开始执行更多步骤、调用更多工具、做出更多判断，评估工具也必须随之成长。这包括审视智能体所走路径的轨迹评估、检查是否正确使用了合适工具的工具调用评估、针对判断密集型场景的校准评估，以及针对没有清晰基准事实或断言可供评分的场景的评估方式。

Rapidflare将在后续文章中介绍更多此类模式，包括如何在每次改动中高效地将这些测试套件作为回归测试来运行。AI智能体评估领域仍在快速演变，团队会持续分享学习到的经验。

Ashikka Gupta，Rapidflare创始工程师

Sathvik Murthy，Rapidflare创始工程师

Q&A

Q1：为什么评估AI智能体很难做好？

A：因为随着智能体处理更多工作流和真实用户，一次改动可能让某部分变好却悄悄削弱另一部分。没有结构化的评估套件，很难判断问题是真正的回归、偶发情况、数据问题还是噪声。

Q2：为什么用断言而不是参考答案来评分？

A：因为参考答案往往包含多个事实和细节，如果答案很长很密集，评判者容易失去焦点，难以判断方向是否正确。而断言是简短、可核查的规则，能明确列出重要部分，让评分更清晰准确。

Q3：Rapidflare的评估框架带来了哪些实际效果？

A：借助该框架，Rapidflare在约一个月内评估并向3个客户上线了新智能体，还有信心用成本更低的模型替换掉价格约三倍的前沿模型，因为评估结果证明更便宜的模型表现更好。