Building an Evaluation Harness for Production AI Agents: A 12-Metric Framework From 100+ Deployments

面向生产 AI 代理的评估框架构建：来自 100 多个部署的 12 项指标框架

URL 来源：https://towardsdatascience.com/building-an-evaluation-harness-for-production-ai-agents-a-12-metric-framework-from-100-deployments/

发布时间：2026-05-13T12：00：00+00：00

Markdown 内容： 在一次 AI 部署中，我们的客户合规官提出了一个我们无法回答的问题。

“你怎么知道你的代理没有凭空编造患者的症状？”

我们有单元测试。我们有集成测试。我们在演示数据集上有一个表现完美的模型。但我们缺少的是一个能够测量生产环境中幻觉率、上下文忠实度或工具选择准确性的评估框架。

这个差距几乎让项目夭折。六周后，我们有了一个针对每个代理响应、每个工具调用以及每次检索操作的 12 项指标评估框架。合规团队批准了。代理上线了。

自那以后，我们已经部署了 100 多个企业 AI 代理。该框架在此过程中不断演进，形成了下面的指南。如果你正在构建生产 AI 代理，这正是我们在第一天就希望拥有的评估框架。

12 项指标框架概览

| 类别 | 指标 | 衡量什么 | 关键阈值 | | --- | --- | --- | --- | | 检索 | 上下文相关性 | 检索到的内容是否与查询相关？ | >0.85 | | 检索 | 上下文召回率 | 我们是否检索到了所有可用的相关信息？ | >0.90 | | 检索 | 上下文精确度 | 排名靠前的内容是否最相关？ | >0.80 | | 检索 | 检索延迟 | 检索完成的速度如何？ | <200ms p95 | | 生成 | 回答忠实度 | 回答是否符合检索到的上下文？ | >0.95 | | 生成 | 回答相关性 | 回答是否解决了用户的问题？ | >0.90 | | 生成 | 幻觉率 | 模型多大程度上在编造事实？ | <2% | | 代理 | 工具选择准确性 | 代理选择的工具是否正确？ | >0.92 | | 代理 | 工具执行成功率 | 工具调用是否成功？ | >0.98 | | 代理 | 多步连贯性 | 代理是否保持逻辑连贯？ | >0.85 | | 生产 | 每次查询成本 | 每次请求的代币和基础设施成本 | <$0.05 典型 | | 生产 | P99 延迟 | 端到端响应时间 | <3s |

三个类别涵盖了代理的内部操作（检索、生成和代理行为）。第四个类别则衡量生产环境关心的因素（成本和延迟）。忽略任何一个类别都会带来风险。

为什么大多数团队跳过评估（并为此付出代价）

在我们审计过的项目中，三种模式解释了为什么团队在没有适当评估基础设施的情况下就发布了 AI 代理。

模式 1：“我们会先发布 MVP，然后再添加评估。”

这是最常见的也是代价最高的模式。当 MVP 发布时，团队已经构建了 UI、API、集成，并且已经启动了客户。现在他们需要在一个已经在生产中的系统中添加评估基础设施，而用户正在发送不可预测的查询。这种改造通常需要 4 到 6 周的时间。数据收集滞后意味着他们可能要花几天才能发现回归问题。到那时，信任损害已经造成。

模式 2：“准确性足够了。”

在保留的测试集上的准确性是必要的但不够的。一个 RAG 代理可以在基准问题上达到 95% 的准确性，但在真实用户的查询中仍然会有 30% 的时间出现幻觉。生产流量总是与你的评估集不同。如果没有忠实度、幻觉率和工具选择指标，你就是在盲目飞行。

模式 3：“手动抽查就可以了。”

手动审查每天可以处理 100 个查询。但它在 10,000 个查询时就会崩溃。那些试图扩展手动审查的团队要么耗尽工程师，要么接受他们实际上并没有审查声称的数量。一旦每天的查询量超过几千条，自动化评估就不再是可选的。

下面的框架解决了这三种模式。在发货之前构建它，对每一层进行监控，并让指标告诉你手动审查无法揭示的内容。

对于构建业务自动化 AI 代理的团队来说，评估框架往往决定了项目是否能进入生产阶段。

12 项指标框架

该框架将 12 项指标分为四类。每一类都回答了关于代理性能的不同问题。

类别 1：检索指标（4 项）

如果您的代理使用检索（RAG、知识库查找、文档搜索），那么检索质量是基础。上游检索不佳意味着下游无论多么巧妙的提示也无法挽救响应。

#### 1. 上下文相关性

衡量什么：检索到的内容中有多少与用户的查询相关？

为什么重要：我们在生产中看到的大多数 RAG 失败都可以追溯到检索而不是生成。模型只能使用您提供给它的内容。如果您检索了 10 个片段，但只有 3 个相关，那么您已经污染了上下文，迫使模型从噪声中筛选信号。

如何衡量：对于每个查询，一个作为裁判的大型语言模型（LLM）根据与查询的相关性对每个检索到的片段进行 0 到 1 的评分。我们对排名前 k 的检索片段取平均值。

目标阈值：前 10 个片段的平均相关性 >0.85。低于 0.7 表示存在值得调查的检索问题，而不是追逐模型改进。

生产注意事项：当我们看到生产中的上下文相关性下降到 0.75 以下时，原因几乎总是以下三者之一：索引漂移（新文档未正确切块）、查询意图变化（用户提出的问题与评估集不同）或切块策略不匹配（切块过大或过小，不适合查询类型）。

它衡量的是什么： 我们是否检索到了回答查询所需的所有信息，还是遗漏了相关的内容？

为什么重要： 召回率是检索增强生成（RAG）系统中的隐形杀手。低召回率意味着答案不完整或错误，但模型无法发出“上下文不足”的信号。它会自信地从部分信息中生成答案。

我们如何衡量它： 这需要一个带有标注的评估集，在该集合中，人类评估者已经识别出所有包含与基准查询相关的片段。然后计算这些“真实相关”片段中实际被检索到的比例。

目标阈值： 基准查询的召回率 >0.90。低于 0.80 表示系统系统性地遗漏了信息，导致自信但错误的答案。

生产注意事项： 召回率下降通常是嵌入模型不匹配（嵌入模型未能捕捉领域的语义）或片段大小问题（信息以妨碍相似度搜索的方式分布在多个片段中）的症状。解决方法通常是重新切分片段，而不是重新训练模型。

#### 3. 上下文精确度

它衡量的是什么： 在检索到的片段中，最相关的片段是否排在前面？

为什么重要： 大多数生产环境中的 RAG 系统由于令牌预算限制，仅将前 3-5 个片段传递给大语言模型（LLM）上下文窗口。如果排名第一位的片段无关紧要，而相关的片段位于第七位，那么实际上检索到的有用信息就等于零。

我们如何衡量它： 我们计算平均倒数排名（MRR）——即排名检索结果中第一个相关片段的平均位置。

目标阈值： MRR >0.80 — 第一个相关片段应该大多数情况下位于第一或第二位。

生产注意事项： 在初始向量搜索之后添加重排序器可以显著提高精确度。我们在 pgvector 检索之上添加了一个 BGE 重排序器后，看到 MRR 从 0.55 跃升至 0.92。延迟成本约为 50 毫秒；精确度的提升是值得的。

#### 4. 检索延迟

它衡量的是什么： 从接收查询到检索到的片段准备就绪的时间，以 p95 测量。

为什么重要： 在大规模应用中，端到端代理响应时间主要受检索时间的影响。如果检索耗时 800 毫秒，用户需要等待 800 毫秒才能让 LLM 开始处理。

我们如何衡量它： 对检索服务进行标准的应用性能监控。我们记录每个查询的检索时间，并报告 p50、p95 和 p99。

目标阈值： p95 检索延迟 <200 毫秒。p99 <500 毫秒。

生产注意事项： 延迟峰值通常与以下情况之一相关：索引大小增长但未重新调整 HNSW 参数、嵌入服务和向量数据库之间的网络跃点，或冷启动缓存缺失。在假设需要更快的向量数据库之前，先调查是哪一种情况。

类别 2：生成指标（3）

一旦检索到正确的上下文，生成的质量决定了用户是否能收到有用的回复。这里有三个重要的指标。

#### 5. 回答忠实度

它衡量的是什么： 生成的回答是否准确反映了检索到的上下文，还是存在矛盾或捏造的信息？

为什么重要： 这是对任何服务于监管行业的 AI 代理来说最重要的指标。在医疗、金融科技或法律领域，不忠实的回答会导致合规失败。即使在非监管环境下，忠实度直接影响用户的信任。

我们如何衡量它： 对于每个生成的回答，使用 LLM 作为裁判提取原子声明，然后检查每个声明是否与检索到的上下文一致。忠实度分数是支持上下文的声明比例。

目标阈值： 监管行业 >0.95 的忠实度。通用用例 >0.90。低于 0.85 需要立即调查。

生产注意事项： 忠实度下降通常表明以下三种原因之一：温度设置过高（将其降至 0.0-0.3 用于生产）、上下文窗口溢出（检索到的片段加上提示超出上下文限制，模型从训练数据中幻觉），或提示模板鼓励推测（“基于上下文，你觉得怎么样……”）。

#### 6. 回答相关性

它衡量的是什么： 生成的回答是否真正回答了用户的问题，还是偏离了主题？

为什么重要： 相关性和忠实度是不同的。一个回答可以完全忠实于上下文，但却没有回答用户的真实问题。两个指标都必须高，才能获得良好的回应。

我们如何衡量它： 使用 LLM 作为裁判生成 3-5 个该回答可以很好地回答的问题，然后计算这些生成的问题与原始用户查询之间的语义相似度。

目标阈值： >0.90 的相关性。低于 0.80，代理正在回答相关但不是用户的问题。

生产注意事项： 相关性问题通常可以追溯到代理流程中的查询重写步骤。如果代理将“我如何取消我的订阅？”重写为“取消政策是什么？”并回答重写后的查询，原始意图就会丢失。

#### 7. 幻觉率

它衡量的是什么： 模型生成的事实、名称、数字或主张中有多少是没有依据于检索到的上下文或可验证现实的？

为什么重要： 幻觉率是你首席技术官会问到的指标。忠实度衡量对上下文的忠实程度；幻觉率衡量超出上下文的捏造程度。它们有所重叠但并不完全相同——模型可以忠实于错误的上下文，或者以无害的方式不忠实。

我们如何衡量它： 我们每天对 5% 的生产查询进行抽样，并通过专门的幻觉检测管道运行这些查询，标记需要事实核查的主张，然后人工审查标记的部分。

目标阈值： 生产代理的幻觉率 <2%。监管行业的部署 <0.5%。

生产备注：按查询类型统计幻觉峰值。开放式问题比是/否问题产生更多幻觉。数值型问题比分类型问题产生更多幻觉。将查询类型分类构建到评估管道中，以便可以针对调查进行定位。

类别 3：特定代理指标（3）

如果你的 AI 系统是一个代理（多步骤、工具使用、目标导向），而不是一个简单的 RAG 管道，有三个额外的指标很重要。

#### 8. 工具选择准确性

它衡量什么：当代理可以选择工具时，它是否选择了符合用户意图的正确工具？

为什么重要：现代代理可以访问几十种工具——搜索、计算器、日历、数据库查询和 API 调用。错误的工具选择会导致级联错误——代理试图让方形的钉子适应圆形的孔，从而生成下游的错误结果。

我们如何测量：构建一个标记化的评估集，包含（查询，正确工具）对。运行代理以处理这些查询，并计算在第一个决策点上工具选择的准确性。

目标阈值：二元工具选择的准确性 >0.92。在五种以上工具中的选择 >0.85。

生产备注：随着可用工具数量的增长，工具选择准确性下降。我们见过在三种工具时达到 95% 的准确性，在十二种工具时降至 70%。解决方法通常是更清晰的工具描述、每个代理使用的工具更少（分解为专门的子代理），或在生产环境中基于工具使用痕迹进行微调。

#### 9. 工具执行成功率

它衡量什么：代理发出的工具调用中，有多少比例成功执行（正确的参数、有效的响应、无错误）？

为什么重要：代理可以选择正确的工具，但仍可能错误地调用它——错误的参数格式、缺少必需字段、输入格式不正确。工具执行成功率隔离了这种失败模式。

我们如何测量：在生产环境中跟踪每个工具调用的成功/失败状态、错误分类和重试尝试。按工具、查询类型和时间窗口计算成功率。

目标阈值：工具执行成功率 >0.98。低于 0.95 表示系统性参数构造问题。

生产备注：最常见的失败模式是代理自信地构造与工具实际架构不匹配的参数格式（例如，API 需要 ISO 8601 格式的日期字符串，而代理传递的是日期字符串）。解决方法是在工具边界强制结构化输出（函数调用、JSON Schema 验证）。

#### 10. 多步骤连贯性

它衡量什么：当代理执行一个多步骤计划时，逻辑流程在各步骤间是否保持连贯？

为什么重要：单步准确性对于代理行为来说是必要的但还不够。一个代理在第一步中选择了正确的工具，得到了好的结果，但在第四步时忘记了这个结果，即使每个单独的步骤都成功了，它也已经失败了。

我们如何测量：跟踪级别评估。对于每个多步骤轨迹，LLM 作为裁判评估器评分，判断每个步骤是否连贯地建立在前一步的基础上，最终输出是否反映了完整的推理链。

目标阈值：四步以上的轨迹连贯性 >0.85。低于 0.75，你的代理基本上是在做多个不相关的单步查询。

生产备注：连贯性随轨迹长度下降。我们看到两步轨迹的连贯性超过 95%，但在六步轨迹中下降到 60%。解决方法要么是分解（将六步任务分成两个独立的三步任务，明确交接），要么是记忆架构（跨步骤持久状态，而不是每次重新提示完整的历史记录）。

类别 4：生产指标（2）

前十个指标衡量代理的行为。这两个指标衡量生产环境关心的内容。

#### 11. 每次查询成本

它衡量什么：每用户查询的总成本（令牌成本 + 基础设施成本 + 工具调用成本），按生产流量平均计算。

为什么重要：AI 代理具有独特的成本结构——单个用户查询可能会触发 5-15 次 LLM 调用（重写、检索评分、工具选择、生成、验证）。令牌泛滥会将原本 0.02 美元的查询变成 0.30 美元的查询，直到月度账单到达时才会有人注意到。

我们如何测量：为每个 LLM 调用配备令牌使用日志，为每个工具调用配备相关 API 成本，为每个基础设施依赖项配备按比例分摊的成本。按查询聚合，然后按查询类型聚合，最后按时间窗口聚合。

目标阈值：因用例而异。内部员工工具：每次查询 <0.10 美元是可以接受的。面向客户的的产品：每次查询 <0.05 美元以实现可持续经济。在受监管行业中，成本不如其他指标重要。

生产备注：成本激增通常归因于以下之一：提示长度增长（系统提示随时间增长）、重试风暴（失败触发重新执行循环）或上下文窗口膨胀（检索块随着知识库的增长而变长）。这三项都易于监控和修复。

对于看到查询成本趋势不可持续的团队，构建 vs 购买决策往往转向具有固定成本的自定义基础设施，而不是按令牌计费的 API 价格。

#### 12. P99 延迟

它衡量什么：从用户查询到最终响应的端到端时间，按第 99 百分位数测量。

为什么重要：平均延迟隐藏了让用户沮丧的失败模式。一个系统平均延迟为 1 秒，但第 99 百分位延迟为 15 秒，用户会在收到 4-5 次慢响应后放弃会话。P99 是用户记住的时间。

我们如何测量：标准应用程序性能监控。我们记录每个查询的端到端延迟并报告 p50、p95、p99 和最大值。我们按查询类型跟踪这些数据，因为对话查询应该比分析查询快得多。

目标阈值：对话代理的 p99 <3 秒。多步骤推理的分析代理的 p99 <10 秒。超过 10 秒，用户就会失去兴趣。

生产注意事项：P99 延迟几乎总是由以下三种情况之一主导：检索（向量数据库冷缓存）、工具调用（外部 API 超时）或长输出的生成（遇到逐令牌流传输瓶颈）。在优化之前，请先确定主导原因。

决策树：优先考虑哪些指标

同时实现十二个指标是一项艰巨的任务。以下是我们在项目各个阶段如何逐步实施的方法。

第一阶段（上线前 - 第 0 至 2 周）： 实现检索指标（上下文相关性、召回率、精确度）以及答案忠实度。这四个指标可以捕捉最常见的上线前失败模式。

第二阶段（软上线 - 第 3 至 6 周）： 添加幻觉率、答案相关性和工具选择准确性。这些指标可以捕捉只有在真实用户流量下才会出现的问题。

第三阶段（生产稳定 - 第 7 周及以上）： 添加每次查询成本、P99 延迟、工具执行成功率、多步一致性以及检索延迟。这些指标优化运行系统，而不是捕捉阻碍上线的失败。

使用场景调整：

• 受监管行业（医疗保健、金融科技、法律）： 优先考虑忠实度和幻觉率。目标是第一天就达到大于 0.97 的忠实度和小于 0.5% 的幻觉率。
• 高流量消费产品： 优先考虑每次查询成本和 P99 延迟。忠实度很重要，但不应以牺牲单位经济为代价。
• 内部员工工具： 优先考虑工具执行成功率和多步一致性。员工可以原谅缓慢的响应，但不能忍受中断的工作流程。

本框架与其他现有工具的比较

您不需要从头开始构建所有 12 个指标。一些开源和商业工具涵盖了该框架的部分内容。

Ragas很好地覆盖了上下文相关性、召回率、精确度、忠实度和答案相关性。它是针对 RAG 特定指标的最强开源起点。不涵盖代理特定指标或生产健康状况。

TruLens提供了类似的 RAG 指标，并且具有更强的可观测性工具。与 LangChain 和 LlamaIndex 集成更好。需要比 Ragas 更多的设置。

DeepEval提供了一个更广泛的指标库，具有良好的代理特定支持（工具选择、忠实度）。比 Ragas 更新，社区较小。

LangSmith为基于 LangChain 的代理提供生产监控和评估。在跟踪和可观测性方面表现强劲，在离线基准评估方面较弱。

为什么我们在此基础上构建了自己的框架：现有的工具没有一个能涵盖所有 12 个指标，特别是代理特定指标（工具选择准确性、多步一致性）尤其不足。我们使用 Ragas 进行 RAG 指标，自定义评估器进行代理指标，并使用标准 APM 工具（Datadog、OpenTelemetry）进行生产健康指标。上述框架是这三个方面的统一视图。

实施现实：构建这一框架的实际成本

假设您已经配置了 LLM 判别评估器，建立完整的 12 指标框架需要 2-3 周的集中工程努力。

时间分解：

• 评估集构建（标记查询 + 真实数据）：4-6 天
• 指标实现（Ragas 或自定义）：3-5 天
• CI/CD 集成（对每个 PR 运行评估）：2-3 天
• 生产监控仪器化：3-5 天
• 仪表板和警报：2-3 天

跨部署使用的工具：

• 评估编排： Ragas + 自定义评估器（Python）
• LLM 作为判别器： GPT-4 用于高风险评估，Claude Sonnet 用于成本敏感评估，Llama 3 70B 用于完全自我托管合规环境
• 存储： PostgreSQL 用于评估结果，S3 用于原始跟踪
• 仪表板： Grafana 用于生产指标，Streamlit 用于离线评估报告
• 警报： PagerDuty 集成用于阈值违规

我们观察到团队常见的陷阱：

1. 使用相同的模型进行生成和判断。 这会产生膨胀分数。使用不同的模型族作为判别器和生成器。
2. 跳过标记评估集。 没有真实数据标签，您无法计算召回率或测量回归。标注成本是真实的，但在第一个月内就会得到回报。
3. 仅在成功案例上运行评估。 您需要在评估集中包含失败案例，否则永远无法发现回归。积极采样生产失败。
4. 将评估分数视为绝对值。 跟踪趋势和变化，而不是绝对分数。一个从 0.85 下降到 0.78 的分数在一个星期内更有意义，而不仅仅是绝对数字。

常见问题

新 AI 代理项目的最小评估设置是什么？

对于新项目，实现上下文相关性、答案忠实度和工具选择准确性。这三个指标可以在最少的设置开销下捕获 70% 的上线前失败。在实际生产流量出现之前，可以跳过生产指标。

我们应该多久运行一次完整的评估套件？

在每次影响检索、提示或代理逻辑的代码更改后，对标记基准集进行离线评估。持续运行在线评估（采样生产流量），并每天生成汇总报告。重新运行完整基准测试很昂贵，但至少每周进行一次以捕获回归。

我们应该使用 LLM 作为判别器还是人工评估？

两者都需要。使用 LLM 作为判别器进行大规模评估（以低成本评估 100% 的生产流量），使用人工评估进行校准（评估 1-2% 的样本以验证 LLM 判别器是否与人类共识一致）。当 LLM 判别器和人工评估结果不一致时，重新训练判别器提示。

离线评估和在线评估有什么区别？

离线评估针对的是带有已知正确答案的标注基准数据集。在线评估则针对真实的生产流量，在这种情况下，您无法提前得知真实答案，因此需要测量代理信号（忠实度、相关性、幻觉）而不是准确性。两者都是必要的。离线评估可以在问题上线前捕获回归问题。在线评估可以捕获由真实用户行为引发的问题。

我们如何处理非确定性代理的评估？

对每个评估查询运行3到5次，并报告分数的均值和方差。高方差表明代理的行为不稳定，这也是一个值得调查的信号。对于生产流量，需充分采样以克服方差带来的噪声。

对于检索增强生成（RAG）系统和代理系统，哪些指标最重要？

纯RAG系统：优先考虑四个检索指标加上忠实度。代理系统：在此基础上增加工具选择准确性、工具执行成功率以及多步一致性。生产指标（成本、延迟）对两者同样重要。

我们如何衡量评估中的用户满意度？

用户满意度位于上述12个指标之后。如果您的忠实度、相关性和延迟指标都在目标范围内，满意度会随之提升。直接的满意度信号（点赞/点踩、后续问题、会话放弃）作为生产健康指标很有用，但它们滞后于导致这些信号的指标。

评估的成本是多少？值得吗？

使用大语言模型（LLM）作为裁判的评估成本大约占推理成本的30%-50%（每个生产查询也会被一个LLM评估）。对于每月4000美元的推理预算，预计每月的评估成本为1200-2000美元。投资回报率在于预防单次生产事故，这样的事故可能会花费数周工程师时间来调试或损害信任。在第一次避免事故发生后，评估成本将在无限期内得到回报。

结语

2026年成功部署AI代理的团队不是拥有最佳模型的团队，而是拥有最佳评估基础设施的团队。模型是商品。评估是差异化因素。

如果您正在构建生产AI代理，并希望获得基于100多次部署经验的评估框架的第二意见，Intuz团队很乐意为您提供帮助。

资源

• Ragas——开源RAG评估框架
• TruLens——LLM应用的评估和跟踪
• DeepEval——开源LLM评估框架
• LangSmith——LangChain的可观测性和评估平台
• OpenTelemetry——生产观测标准
• HumanEval基准——Github
• Ragas论文——自动评估RAG

• * *

Pratik K Rupareliya是Intuz的联合创始人兼战略负责人，在该公司领导企业AI战略，涉及100多个部署项目，涵盖医疗保健、金融科技、制造业和零售业等领域。您可以通过领英与他联系。