Amazon Bedrock AgentCore Evaluations 智能体评估指南：内置、DeepEval 与 AutoEval 评估器
The agent evaluation playbook: Built-in, DeepEval, and AutoEval on Amazon Bedrock AgentCore Evaluations
Amazon Bedrock AgentCore Evaluations 提供内置、DeepEval 和 AutoEval 三类评估器，用于在生产环境中衡量智能体行为。
当你把智能体部署到生产环境时，最难回答的问题之一就是它是否真的在正常工作？衡量标准不是它能否运行，而是它能否在规模化场景下满足业务需求。许多团队会告诉你，他们其实看不清这一点。他们会抽查输出、观察延迟，并在能拿到用户反馈时收集反馈。但这些都无法告诉你，智能体是否完成了用户的任务、在长会话中是否始终紧扣主题、是否泄露了个人身份信息（PII），或者是否悄悄跳过了它本应遵循的一半步骤。
图 1：团队通常关注表面信号，但业务成果是由水面之下的智能体行为决定的
智能体评估可以解决这个问题。其难点在于，某一指标上的高分可能掩盖另一指标上的失败。一个客服智能体可以解决每一张工单，却仍然在回复中泄露个人信息。在这种情况下，尽管完成率很高，智能体实际上是在失败。要做好评估，就要针对每个智能体，以恰当的细节粒度衡量真正重要的行为。
本文介绍如何在 Amazon Bedrock AgentCore 上实现这一点。我们直接使用 AgentCore Evaluations 中的 AgentCore 内置评估器，以及 DeepEval 和 AutoEval 评估器。
从业务成果出发，而不是从指标名称出发
最常见的错误是从指标列表出发，挑选听起来正确的名称。“有用性听起来不错，那我们就用它。”结果虽然能运行并产出数字，却几乎提供不了有用的洞察。指标匹配的是它的标签，而不是智能体成功的含义。
相反，应当从三个步骤开始。
- 用业务语言定义成功。对于客服智能体，这可能是首次联系解决率。对于研究智能体，可能是产出一个完整、来源可靠且完全基于检索文档的答案。对于内容审核助手，则意味着标记出所有应当被标记的内容，且只标记应当被标记的内容。
- 将成果拆解为可观察的行为。一个实现首次联系解决率的客服智能体，通常会完成用户陈述的目标、在问题需要澄清时跨轮次保持连贯、将回复保持在合规边界内，并正确调用工单创建或订单查询等后端工具。
- 将每种行为映射到恰当层级的评估器。Trace 级指标覆盖每轮或每次工具调用的行为。Session 级指标覆盖只有纵观整个对话才有意义的成果。
图 2：将业务成果转化为可观察的行为，再转化为 trace 或 session 层级的具体评估器
这个三步流程是让评估变得有用的思维模型。本文余下部分介绍 AgentCore 为你执行这一流程提供了什么。
评估器目录
AgentCore 拥有来自三个来源的丰富评估器目录：
- 内置评估器由 AWS 编写并经过质量测试。你通过其 ID（
Builtin.GoalSuccessRate、Builtin.Helpfulness以及另外 13 个）引用它们，其余一切由服务处理。它们经过可靠性基准测试，覆盖常见维度，因此是直接上手的起点。 - 第三方托管评估器来自 DeepEval 和 AutoEval，这是两个成熟的开源评估库。在托管模式下使用它们时，AgentCore 负责托管代码、选择评判模型，并利用自身算力运行推理，与内置评估器完全一样。如果你的团队在开发中已经在使用其中一个库，就可以在生产环境中运行相同的指标，而无需单独的评估服务。
- 自定义评估器以内置或第三方评估器为基础，因此你可以换用自己的模型，并修改提示词或评分标准。
图 3：三个评估器层级以 AWS 的质量保证换取对运行推理的模型和账户的更高控制权
创建之后，自定义派生评估器的使用方式与其他评估器完全相同。
评估器全景
AgentCore 自带丰富的评估器目录，因此你很少需要从零开始。在编写自定义评判器之前，先检查是否已有评估器能衡量你关心的行为。下图展示了完整全景。
图 4：AgentCore 上内置、DeepEval、AutoEval 和自定义来源的完整评估器全景
内置 AWS 评估器分为五组：
- 响应质量涵盖答案是否准确、有依据且格式良好：
Correctness、Faithfulness、Helpfulness、ResponseRelevance、Conciseness、Coherence、InstructionFollowing和Refusal。 - 任务与目标完成包含
GoalSuccessRate，它审视整个会话并判断用户的目标是否达成。 - 工具使用包含
ToolSelectionAccuracy和ToolParameterAccuracy，用于检查智能体是否选对了工具，并向其传入了正确的参数。 - 技能包含
SkillSelectionAccuracy和SkillInstructionFollowing，适用于加载技能的智能体：是否调用了正确的技能，是否遵循了其步骤？ - 安全性包含
Harmfulness和Stereotyping。
除此之外还有三项基于标准答案的轨迹检查：TrajectoryExactOrderMatch、TrajectoryInOrderMatch 和 TrajectoryAnyOrderMatch。它们将智能体实际的工具路径与你预期的路径进行比较。当智能体如何达成目标与它产出了什么同样重要时，就使用它们。
DeepEval 提供四组托管开源指标：
- 任务与目标完成：
TaskCompletion、GoalAccuracy和ConversationCompleteness。 - 对话质量：
TurnRelevancy、KnowledgeRetention和Summarization。 - 工具使用：
ToolUse。 - 安全性：
Bias、Toxicity和PIILeakage。
这些指标对多轮智能体尤其有用。ConversationCompleteness 能发现那种回答了最新消息、却悄悄丢掉了先前请求的智能体。KnowledgeRetention 能发现那种忘记了用户三轮之前说过的话的智能体。
AutoEval 提供更专门的信号：
Security标记恶意输出，例如试图注入指令或泄露系统提示词。Possible能发现过度谨慎、错误地宣称有效任务无法完成的智能体。Humor对面向消费者的智能体很重要，因为个性是产品的一部分。
自定义评估器。当目录中没有合适的评估器时，你可以编写自定义的 LLM 作为评判器。
每个评估器的确切定义、评分量表和输入要求都在 AgentCore 文档的提示词模板库中。其中包括它使用的评判提示词、运行所在的轨迹或会话层级，以及是否需要参考答案或预期轨迹。你可以调用 ListEvaluators API，在一次响应中获取完整目录和你自己的自定义评估器。
多维度评估器
到目前为止，每个评估器对每条轨迹或会话返回一个分数。当你只衡量一种行为时，这没问题。但结果映射的第 2 步很少能让每个评估器只对应一种行为。一条客服回复必须解决问题、遵守退款和数据政策，并保持专业。一个评判器权衡这三项后只返回一个数字，你无法判断是哪个标准在起作用。
多维度评估器是一种自定义的 LLM-as-a-judge，它使用一组维度而非单一量表。每个维度都有自己的名称、指令和数值或分类量表。评判器读取一次轨迹，并在同一次调用中为每个维度打分。AgentCore 为每个维度返回一个结果。
图 5：多维度评估器在一次评判调用中为多个维度打分，并为每个维度返回一个结果，不给出综合分数
当你的成功标准可能各自独立失败时，例如答案准确但不合规，或问题已解决但态度粗鲁，就使用多维度评估器。它还需要每个标准都能从同一证据中评判，这样一次评判调用就能替代多个几乎相同、反复读取同一轨迹的评估器。当你分别对各项标准打分时，就可以对每一项单独设门禁。一次改善了语气但导致政策合规性退步的发布会被判为失败，而单一混合分数会掩盖这一点。
当已有的内置或第三方指标已经覆盖某些标准时，例如 Builtin.Correctness 或 ThirdParty.DeepEval.PIILeakage，就把这些标准保留在单独的评估器中。当它们需要不同的级别或评判模型时，也应保持分离，因为一个评估器中的各维度共享同一个级别和模型。当某些标准需要基准真值（如 {expected_response} 或 {assertions}）时，也这样做。将无需参考的标准保留在各自的评估器中，意味着它仍可在实时流量上运行。
按代理类型划分的示例栈
以下每个栈都从两到三个最匹配业务结果的评估器开始。当你发现第一组遗漏的失败模式时，再添加其他评估器。标记为“需要基准真值”的评估器仅在批量评估中运行，因为实时流量没有参考答案或预期路径。
| 客户支持 | 多步骤研究 | 领域内容（医疗、法律、金融） | |
| 业务结果 | 在一个会话中解决问题，且无下游风险 | 通过既定工作流给出完整、来源可靠的答案 | 在领域内给出正确、无偏见、安全的答案 |
| 主要风险 | 请求被丢弃、不安全或不合规的回复 | 通过错误的工具路径得到正确答案，或在长会话中丢失上下文 | 错误答案。错误答案比没有答案更糟。 |
| 从以下开始 |
|
|
|
| 按需添加 |
|
|
|
| 派生评估器 | 可选 | 如果推理必须留在你的账户内，用于轨迹和技能指标 | 几乎总是如此，以便每次评判调用都处于你的数据治理之下 |
运行评估：三种模式
AgentCore 支持三种评估模式。
按需评估是最快的反馈循环。在开发或调试期间，直接将会话传给 client.evaluate()。系统中的每个评估器，包括第三方评估器，都在此工作。
import boto3
client = boto3.client('bedrock-agentcore')
response = client.evaluate(
evaluatorId="ThirdParty.DeepEval.TaskCompletion",
evaluationInput={"sessionSpans": session_span_logs}
)
for result in response["evaluationResults"]:
print(f"Value: {result.get('value')}")
print(f"Explanation: {result.get('explanation', '')}")在线评估附加到你的实时代理运行时，并按配置的速率对真实流量采样。这是你的生产健康信号。内置和第三方评估器可以在单个在线评估配置中自由混合。
批量评估会针对一组固定的会话运行已定义的评估器栈：这就是你在发布前用于回归测试的黄金数据集。用它来确认提示词变更或模型升级在你关心的每个维度上都保持了质量。
三种模式都使用相同的评估器 ID。从按需开发测试切换到生产在线评估只是一次配置变更，而不是重写代码。
综合运用
越来越难的部分是选择哪些评估器。挑选两到三个最能体现你是否达成业务结果的行为，先测量这些。当你发现当前评估器集合遗漏的失败时，再添加一个评估器。
要查看完整目录，请调用 ListEvaluators API。它会在一次响应中返回内置评估器、DeepEval 和 AutoEval 评估器，以及你账户中的任何自定义评估器。在选择其中任何一个之前，先回答两个问题：“对这个 agent 来说，成功是什么样子？”以及“trace 中的什么行为表明它发生了？”
关于作者
Bharathi Srinivasan
Bharathi 是 AWS 可信 AI 团队的技术上市专家，帮助组织将前沿 AI 概念安全地迁移到真实生产环境。她热衷于 AI 可靠性和开发者赋能，经常发布关于 LLM 评估、可靠性和安全性的研究和代码示例。业余时间，她喜欢探索山间小径、为野外探险做准备，以及追韩剧。
Neha Thakur
Neha 是 AWS 的解决方案架构师，既是覆盖 AWS 各项服务的通才，也是 AI/ML 领域的专家。她与英国一些最大的银行和金融科技公司合作，帮助他们利用 AWS AI/ML 服务解决复杂的业务挑战。她对 AI 可解释性充满热情，并致力于让人工智能更加透明、可解释和可信。
Visakh Madathil
Visakh 是 AWS 的解决方案架构师，与客户和内部团队合作，为生产 AI 系统带来可读性、可信度和安全性。他在 AI 安全性和可靠性方面的工作已在机器学习会议上展示。工作之外，他喜欢音乐、观鸟和运动。
Manoj Selvakumar
Manoj 是 AWS 的 AI 专家解决方案架构师。他帮助初创企业和大型企业在 Amazon Bedrock 上构建和扩展 AI 应用与 agent。他的工作涵盖模型推理、agent 框架和 agent 评估，研究模型和 agent 在真实世界需求下的行为，以及如何让它们在大规模下保持可靠。他与 AWS 服务团队合作，将这些生产洞察转化为产品方向和服务改进。
来源：AWS Machine Learning Blog · aws.amazon.com