Name: AI 评测：构建企业级 LLM 与 Agent 质量体系
Author: 寒江雪

9.1 评测设计的第一步不是选 Benchmark

很多 AI 评测项目启动时，第一个问题是：“我们要跑哪些 Benchmark？”

这个问题并不错误，但如果它成为第一步，评测体系很容易偏离业务。公开 Benchmark 可以帮助团队理解模型的通用能力，却不能直接回答一个企业客服 Agent 能否安全处理退款、投诉、订单查询和售后升级。

另一个常见起点是写 Judge Prompt。团队会先设计一个“请你判断回答好不好”的评估器，再批量打分。但如果没有先定义业务目标、能力维度、风险场景和指标边界，Judge 只是在替一个模糊目标打分。分数看起来精确，实际不可解释。

评测设计的第一步应该是把业务目标拆成可评测对象：

图 9-1 从业务目标到指标树的推导流程图

flowchart LR
  A["业务目标"] --> B["用户任务"]
  B --> C["能力域"]
  C --> D["风险场景"]
  D --> E["指标"]
  E --> F["样本"]
  F --> G["阈值"]
  G --> H["门禁"]

这一章的任务，就是把“效果好”“体验好”“更智能”这类模糊表达，转化为可以执行、可以复现、可以比较、可以决策的指标树。

9.2 从业务目标开始

业务目标描述系统为什么存在。没有业务目标，指标就会变成数字游戏。

以客服 Agent 为例，业务目标可能是：

提升高频问题自助解决率。
降低人工客服接待量。
缩短退款、物流、售后等任务的处理时间。
保持政策解释准确、合规、可追溯。
在权限边界内完成部分自动化操作。
控制单次会话成本和响应延迟。

这些目标背后有不同的质量要求。如果目标是降低人工客服接待量，那么任务完成率、转人工率、用户追问率很重要。如果目标是保证合规，越权率、隐私泄露率、高危拒绝正确率就是硬指标。如果目标是提升效率，P95 延迟和单会话成本也要进入指标树。

业务目标不应该停留在口号层。它至少要回答四个问题：

问题	示例
系统服务谁？	售后用户、客服运营团队、质检团队
系统完成什么任务？	政策问答、订单查询、退款资格校验、投诉升级
哪些失败不可接受？	泄露隐私、越权退款、编造政策、绕过身份校验
哪些指标能反映业务价值？	自助解决率、转人工率、投诉率、处理时长、成本

9.2.1 目标澄清工作坊

在企业项目中，业务目标往往来自一句宽泛要求，例如“客服 Agent 要更好用”。评测负责人不能直接把这句话转成样本和 Judge，而应先组织一次目标澄清。

目标澄清至少需要产品、算法、工程、客服运营、安全和业务负责人参与。会议不追求一次解决所有细节，而是把目标拆成可验证假设。

可以按下面的问题推进：

讨论问题	输出
哪些用户任务最影响业务目标	核心用户任务清单
哪些失败会造成严重后果	高风险场景清单
当前线上最常见的质量投诉是什么	线上信号和 Bad Case 来源
哪些场景必须自动完成	任务完成类指标
哪些场景必须转人工或拒绝	安全和流程类指标
哪些指标能影响发布决策	门禁指标候选
哪些指标只用于观察趋势	观察指标候选

客服 Agent 的目标澄清会把“提升自助解决率”拆成更具体的判断：普通退款政策应尽量自动回答；会员部分退款需要调用工具确认；他人订单查询必须拒绝；投诉升级需要转人工；成本和延迟不能因为过度工具调用失控。

这样的输出才是指标树的起点。

9.3 从业务目标到用户任务

业务目标仍然太宽，需要拆成用户任务。用户任务是评测设计中最重要的中间层，因为它连接了业务语言和评测语言。

客服 Agent 的“提升售后自助解决率”，可以拆成多个用户任务：

用户任务	用户真实表达	系统期望
查询退款政策	“我这个还能退吗？”	根据品类、时间、状态解释政策
查询退款进度	“为什么钱还没到账？”	查询订单和支付状态，解释进度
发起退款申请	“帮我退掉这个订单”	校验身份、资格和规则后提交或拒绝
处理质量问题	“东西坏了怎么办？”	区分质量问题和无理由退货，必要时转人工
投诉升级	“我要投诉，你们太离谱了”	安抚、记录、按 SOP 升级
拒绝越权请求	“帮我查一下我朋友的订单”	拒绝并说明隐私边界

用户任务要贴近真实表达，不能只写内部功能名。真实用户不会说“请执行退款资格校验流程”，而会说“这个还能退吗”“你直接帮我处理一下”。评测样本需要覆盖这些说法。

9.4 从用户任务到能力域

同一个用户任务往往需要多个能力共同完成。

以“发起退款申请”为例，Agent 需要：

理解用户意图：用户是咨询、查询进度，还是明确要求发起退款。
识别必要信息：订单、商品、签收时间、退款原因、身份状态。
检索业务规则：退款政策、品类限制、优惠券规则、人工审批条件。
调用工具：订单查询、退款资格校验、退款申请提交。
遵守流程：先校验身份，再查询订单，再判断资格，再执行动作。
控制安全边界：不处理他人订单，不绕过审批，不泄露隐私。
解释结果：告诉用户能否退款、为什么、下一步是什么。
控制体验成本：轮次不要过多，响应不要过慢，必要时转人工。

这些能力可以汇总为七类能力域：

能力域	说明
意图与语义理解	识别用户目标、约束、隐含需求和多意图
知识与事实	正确使用企业知识库、政策、订单状态和证据
推理与决策	根据规则、状态和约束做出合理判断
工具与动作	正确选择工具、生成参数、处理返回和终态
流程与状态	遵守 SOP，维护多轮状态和任务进度
安全与合规	识别越权、隐私、违规和高风险请求
体验与效率	回答清晰、轮次可控、成本和延迟可接受

能力域是指标树的骨架。后续所有指标都应该挂到某个能力域下。

9.5 从能力域到风险场景

指标覆盖要同时考虑能力范围和风险优先级。

客服 Agent 中，一个低风险闲聊回答不够自然，和一个高风险越权退款，重要性完全不同。样本数量无法代替风险覆盖，高风险场景应优先进入评测。

分析风险场景时要回答两个不同的问题：失败会造成多严重的业务影响，以及团队要投入多少评测资源。P0—P3 只回答第一个问题；频率、模型不确定性和检测难度影响资源投入，但不能改变等级含义。

判断维度	回答的问题	如何使用
业务影响	是否损害用户权益、核心任务、资金、隐私、安全或合规	决定 P0—P3
发生频率	场景和失败在目标流量中是否常见	决定样本量、运行频率和监控投入
模型不确定性	系统是否容易因表达、上下文或组合条件而误判	决定 Hard Case、重复运行和人工复核投入
检测难度	失败能否由规则发现，还是需要 Trace、Judge 或专家判断	决定 Evaluator 组合和证据要求

本书项目的等级语义以术语表第 6 节为准：

等级	失败影响	常见处理
P0	造成不可接受的权益、重大财务、隐私、安全、合规或信任影响	事件级硬门禁，不可豁免
P1	核心任务失败或业务规则未正确执行，但未达到 P0	设置独立 Gate；是否硬阻断由预先批准的项目策略确定
P2	影响体验或效率，但不影响核心任务正确性和安全性	限期修复并监控趋势，默认不作为硬门禁
P3	轻微表达、格式或非关键重复	记录并随迭代优化

因此，“多轮”“政策冲突”或“长尾”本身没有固定等级。同一个多轮问题，如果只是重复追问非关键信息，可能是 P2；如果导致身份校验被绕过，则是 P0。等级要从具体失败及其业务后果得出，技术标签不能代替影响判断。

风险等级与频率、难度共同决定样本投入和评测方式；门禁动作再由等级和项目 Gate policy 共同确定。

9.5.1 风险场景登记卡

风险场景需要被结构化记录。否则团队会在评审会上反复争论“这个风险严不严重”，却无法进入样本、指标和门禁。

风险场景登记卡可以包含：

字段	说明
scenario_id	风险场景标识
user_task	对应用户任务
failure_mode	失败模式
impact	可能影响
risk_level	P0 / P1 / P2 / P3
impact_basis	定级依据和影响边界
frequency	高频 / 中频 / 低频或项目量化口径
uncertainty	高 / 中 / 低或项目量化口径
required_capability	所需能力
eval_dataset	对应数据集
Evaluator	评估方式
gate_policy	门禁策略
owner	负责人

示例：

scenario_id: refund_member_partial_risk
user_task: 会员部分退款咨询
failure_mode: 无工具结果时承诺积分不会扣回
impact: 用户权益误导和投诉
risk_level: P1
impact_basis: 错误结论会使核心退款咨询失败，但当前场景不涉及未授权执行或重大财务副作用
frequency: medium
uncertainty: high
required_capability:
  - 业务规则理解
  - RAG 忠实性
  - 工具调用
eval_dataset:
  - refund_regression_set
  - refund_hard_case_set
evaluator:
  - policy_correctness_judge
  - tool_trace_checker
gate_policy: 指定 P1 硬门禁，失败时阻断；策略变更须经发布质量负责人审批
owner: ai_quality_refund

登记卡的价值是把风险从讨论对象变成工程对象。

9.6 指标树的四类指标

到这里，读者应已经形成三项中间产物：业务目标、用户任务与能力域、带优先级的风险场景。若这三项仍然模糊，不应直接进入指标设计；否则后续阈值和 Evaluator 只是在精确度量一个未定义目标。

指标不是同一种东西。企业级评测至少要区分四类指标。

9.6.1 门禁指标

门禁指标直接影响发布决策。它们回答：“这个版本能不能上线？”

客服 Agent 的门禁指标包括：

高危越权率。
隐私泄露率。
退款工具参数准确率。
核心场景任务完成率。
关键政策正确率。
安全拒绝正确率。

门禁指标宜少而明确。如果一个团队设置了 30 个门禁指标，最后往往没有一个能有效约束发布。

9.6.2 诊断指标

诊断指标用于定位问题，不一定直接阻断发布。

示例：

意图识别准确率。
检索 Recall@K。
引用准确率。
工具选择准确率。
参数字段级准确率。
Trace 步骤合理率。
Bad Case 类型分布。

诊断指标的价值是告诉团队应该改哪里。

9.6.3 观察指标

观察指标用于长期看趋势。它们通常不直接卡发布，但异常时要触发分析。

示例：

平均回答长度。
用户追问率。
拒答率。
转人工率。
P95 延迟。
单会话 Token 成本。
工具重试次数。

观察指标适合放在质量看板中，用于监控漂移和体验变化。

9.6.4 业务指标

业务指标验证评测体系是否真的服务业务目标。

示例：

自助解决率。
投诉率。
人工客服节省量。
售后处理时长。
退款操作成功率。
用户满意度。

业务指标通常来自线上，不一定适合离线门禁，但它们是校准离线指标的最终参照。如果离线分数持续提升，业务指标却没有变化，就要重新审视评测集和指标设计。

9.7 客服退款场景的指标树示例

下面是一棵简化的客服退款场景指标树。本节及后续表格中的百分比和阈值均为结构示例，不代表真实项目结果或可直接复用的门禁标准。

业务目标：安全、高效、合规地处理退款咨询与退款操作

1. 任务完成
   1.1 退款咨询解决率
   1.2 退款进度查询完成率
   1.3 退款申请提交成功率
   1.4 必要转人工正确率

2. 政策与知识
   2.1 退款政策正确率
   2.2 证据召回率
   2.3 答案忠实度
   2.4 引用准确率

3. 工具与流程
   3.1 工具选择准确率
   3.2 工具参数准确率
   3.3 身份校验流程遵循率
   3.4 业务终态校验通过率

4. 安全与合规
   4.1 隐私泄露率
   4.2 越权操作率
   4.3 高危请求拒绝正确率
   4.4 过度拒答率

5. 体验与效率
   5.1 用户追问率
   5.2 转人工率
   5.3 P95 响应延迟
   5.4 单会话成本

这棵树首先要做到层次清楚，不必追求一次覆盖所有内容。每个指标都应该能向上追溯到业务目标，向下落到评测样本和 Evaluator。

9.7.1 指标追踪链

指标树还要进入执行系统。每个关键指标都要形成追踪链：

业务目标 → 用户任务 → 风险场景 → 指标 → 数据集 → Evaluator → 阈值 → 门禁动作 → 线上信号。

以“退款工具参数准确率”为例：

层级	内容
业务目标	安全处理退款咨询与操作
用户任务	用户申请部分退款
风险场景	商品金额、优惠券和积分参数填错
指标	refund_tool_argument_accuracy
数据集	Tool Case + Agent Trace Case
Evaluator	参数脚本校验 + 业务终态检查
阈值	示例：高风险样本达到团队评审后的目标水位
门禁动作	低于阈值需要审批，P0 参数错误阻断
线上信号	退款失败率、投诉率、人工纠错率

如果指标无法形成这条链，它就很可能只是报告装饰，而不是质量决策工具。

9.7.2 指标之间会冲突

指标树不是把所有指标都推高。很多指标天然存在冲突。

客服 Agent 中常见冲突包括：

冲突	典型表现	处理原则
自助解决率 vs 转人工正确率	为了降低转人工，Agent 在高风险场景也尝试自动处理	高风险场景优先安全和人工兜底
回答完整性 vs 延迟成本	回答更完整，但调用更多工具、响应更慢	按场景区分轻流程和重流程
高危拒绝率 vs 误拒率	拒绝更多后安全提升，但合法用户被误拒	同时看误放和误拒
政策正确率 vs 用户满意度	准确但表达生硬，用户继续追问	正确性优先，体验作为优化项
总通过率 vs 红线风险	平均分高，但出现少量越权或隐私失败	红线风险一票否决

指标冲突的优先级应在设计阶段约定，避免拖到发布评审时临时争论。一个实用原则是：安全合规和业务红线优先于效率指标；核心业务终态优先于表达偏好；高风险场景优先于总分。

例如，高金额退款场景中，转人工率升高不一定是坏事。如果 Agent 正确识别风险并转人工，转人工率上升可能意味着风险控制更好。反过来，转人工率下降也不一定代表质量提升，可能是 Agent 在不该自动处理的场景中冒险处理。

9.8 把指标定义写到可执行

一个指标只有名字是不够的。每个指标都要有完整定义。

以“退款政策正确率”为例：

字段	定义
指标名称	退款政策正确率
能力域	知识与事实
适用场景	退款政策咨询、退款资格判断、售后问题
计算方式	正确回答样本数 / 有效样本数
正确标准	回答与当前政策版本一致，且没有遗漏关键限制条件
Evaluator	LLM-as-Judge + 高风险样本人工抽检
数据来源	Golden Set、Regression Set、线上回流 Case
阈值	按历史基线、风险容忍度和统计证据分别设定；此处不预设通用百分比
失败归因	知识缺失、检索失败、上下文截断、模型生成错误、业务规则不清
发布影响	低于阈值进入软门禁；高风险样本错误进入硬门禁

如果一个指标无法说明计算方式、数据来源、阈值和发布影响，它就还不是工程可用指标。

9.9 阈值如何设定

阈值不能拍脑袋。常见的阈值来源有四类。

9.9.1 历史基线

例如，若当前线上版本已有稳定核心场景基线，候选版本至少不能出现超过业务容忍度的退化。对于高风险指标，即使平均质量提升，也不能用总体收益抵消红线失败。

9.9.2 人工可接受水位

对于开放式回答，可以先用人工评审建立质量水位。例如，团队可让领域专家标注“政策解释清楚且没有误导”的可接受边界，再用校准数据确定初始阈值；不能先写一个百分比再要求数据迎合。

9.9.3 业务容忍度

不同业务对错误的容忍度不同。普通闲聊可以容忍风格波动，退款操作不能容忍错误工具调用。涉及资金、隐私、法律责任的场景，阈值应更严格。

9.9.4 风险等级

同一个指标在不同风险等级下阈值可以不同。

风险等级	阈值策略
P0 高危	按事件级红线处理；样本零失败不等于风险为零
P1 核心任务或业务规则失败	单独设阈值；项目指定为硬门禁的 P1 失败应阻断，其他 P1 按预先批准的审批和补偿策略处理
P2 体验或效率影响	默认不设发布硬门禁，但要有目标水位、修复期限和趋势监控
P3 轻微问题	记录分布和典型样本，按迭代节奏优化

阈值不是一次设定后永久不变。随着数据集扩展、线上表现变化、业务规则调整，阈值需要定期校准。

9.9.5 阈值评审

阈值应定期评审，尤其是在以下场景：

业务政策发生变化。
数据集规模和难度发生明显变化。
线上分布出现新问题。
Judge 或人工 Rubric 发生调整。
候选版本长期接近门禁边缘。
门禁频繁被豁免。

阈值评审要同时看离线数据和线上结果。例如，退款政策正确率阈值设为 95%，但线上高风险退款投诉仍然集中出现，说明阈值可能太低，或样本没有覆盖真实高风险问题。反过来，如果某个低风险体验指标频繁阻断发布，却没有带来线上体验改善，说明它可能不适合作为硬门禁。

阈值服务于质量决策，需要持续接受业务结果和风险结果的校准。

9.9.6 指标 Owner 与复审周期

指标一旦进入发布流程，就需要 Owner。没有 Owner 的指标会逐渐失去业务含义。

指标类型	推荐 Owner	复审重点
门禁指标	技术负责人 / 安全负责人 / 业务负责人	是否仍能阻断真实风险
诊断指标	评测负责人 / 对应系统 Owner	是否能指导归因和修复
观察指标	运营 / 产品 / 质量负责人	是否能发现线上漂移
业务指标	业务负责人 / 产品负责人	是否能反映真实业务价值

复审用于确认指标是否仍然有效，而非为发布方便调松阈值。若指标长期被触发但没有对应线上问题，可能说明指标过严或样本失真；若线上问题持续发生但指标稳定，说明指标漏掉了关键风险。

指标治理至少要记录四类信息：为什么设这个指标，谁负责解释它，低于阈值时谁决策，什么时候复审。没有这些信息，指标树会变成静态文档，而不是质量系统的一部分。

9.10 指标反模式

9.10.1 指标太多

指标太多会让团队失去重点。门禁指标宜少，诊断和观察指标可以多，但要分层管理。

9.10.2 指标和业务体验脱节

如果 Benchmark 分数上涨，但用户追问率、投诉率、转人工率没有改善，说明指标没有抓住业务关键问题。

9.10.3 只评质量，不评成本和延迟

一个版本回答更好，但调用轮数翻倍、P95 延迟翻倍、单会话成本翻倍，在企业场景中可能仍然是失败版本。

9.10.4 用总分掩盖红线

总分高不代表可以上线。如果隐私泄露或越权操作触发团队定义的事件级红线，就应按门禁策略阻断或升级审批，不能用平均分抵消。

9.10.5 指标不可归因

“用户体验好”还不是可执行指标，需要继续拆成回答清晰度、任务完成率、追问率、转人工率、延迟等可观测维度。

9.11 交付物一：业务目标到指标树模板

团队可以用下面的模板设计指标树。

9.8 负责定义单个指标的口径，本模板负责把业务目标、风险、数据、Evaluator、阈值和决策动作串成可评审链路；两者不是两份指标定义表。

层级	填写内容	示例
业务目标	系统要创造的业务价值	降低退款咨询转人工率
用户任务	用户真实要完成的任务	查询退款政策、发起退款、查询退款进度
能力域	完成任务所需能力	意图理解、知识检索、工具调用、安全合规
风险场景	失败代价较高的场景	他人订单查询、错误退款、政策冲突
指标	可度量的质量信号	政策正确率、工具参数准确率、越权率
数据集	指标对应的样本集合	Golden Set、Regression Set、Red Team Set
Evaluator	如何评判	规则、脚本、Judge、人工
阈值	通过标准	示例：高危事件按红线处理，核心政策指标不低于经评审的目标水位
决策动作	低于阈值怎么办	阻断发布、人工审批、进入灰度观察

9.12 交付物二：风险场景优先级矩阵

9.5 用四个维度讲判断方法，9.5.1 用登记卡保存单个风险场景，本表用于多个场景之间的资源排序。实际使用时只维护登记卡数据，由平台或工作表生成矩阵，避免三处手工同步。

具体失败场景	频率	业务影响	不确定性	risk_level	评测处理
退款政策答错，导致核心咨询任务失败	高	核心业务规则未正确执行	中	P1	Golden + Regression；按项目 Gate 独立判断
未核验身份便查询他人订单	中	隐私和越权影响不可接受	中	P0	Red Team + 事件级硬门禁
订单号参数错误，导致本人订单查询失败	中	核心查询任务失败，无越权或资金副作用	高	P1	Tool Case + Trace Case
已满足投诉升级条件但未转人工	中	核心处置流程失败	高	P1	多轮 Hard Case + 人工复核
售后寒暄格式不统一	高	不影响任务和体验核心	低	P3	线上抽样观察

这个矩阵同时保留影响等级和投入因素。两个场景即使同为 P1，也可能因为频率或不确定性不同而采用不同样本量和复核方式；资源排序不能反过来改写风险等级。

9.13 本章小结

评测设计先把业务目标拆成用户任务、能力域、风险场景和指标树，再选择 Benchmark 或编写 Judge Prompt。

一个可用的指标树应满足四个条件：

向上能追溯到业务目标。
横向能覆盖核心能力和高风险场景。
向下能落到评测样本和 Evaluator。
最终能支撑发布、灰度、回滚和优化决策。

下一章，我们将看到这些指标如何组合成不同的评测类型，以及在不同阶段该如何选择和搭配评测策略。

第 9 章：从业务目标到风险场景和指标树