第 9 章：从业务目标到风险场景和指标树
第 9 章：从业务目标到风险场景和指标树
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 | 高损或高合规，错误不可接受 | 进入硬门禁和红队集 |
| P1 | 高频且影响用户体验或业务成本 | 进入 Golden Set 和主回归 |
| P2 | 低频但能暴露能力边界 | 进入 Hard Case Set |
| P3 | 低频低损，主要用于观察 | 抽样监控或线上观察 |
客服退款场景中，P0 场景包括他人订单查询、绕过身份校验、错误提交退款、泄露隐私。P1 场景包括政策解释、退款进度查询、常见售后咨询。P2 场景包括多订单混合、政策冲突、用户表达含糊、长多轮上下文。
风险优先级决定样本投入、评估方式和门禁强度。
9.5.1 风险场景登记卡
风险场景需要被结构化记录。否则团队会在评审会上反复争论“这个风险严不严重”，却无法进入样本、指标和门禁。
风险场景登记卡可以包含：
| 字段 | 说明 |
|---|---|
| scenario_id | 风险场景标识 |
| user_task | 对应用户任务 |
| failure_mode | 失败模式 |
| impact | 可能影响 |
| risk_level | P0 / P1 / P2 / P3 |
| required_capability | 所需能力 |
| eval_dataset | 对应数据集 |
| Evaluator | 评估方式 |
| gate_policy | 门禁策略 |
| owner | 负责人 |
示例：
scenario_id: refund_member_partial_risk
user_task: 会员部分退款咨询
failure_mode: 无工具结果时承诺积分不会扣回
impact: 用户权益误导和投诉
risk_level: P1
required_capability:
- 业务规则理解
- RAG 忠实性
- 工具调用
eval_dataset:
- refund_regression_set
- refund_hard_case_set
evaluator:
- policy_correctness_judge
- tool_trace_checker
gate_policy: 高风险误答阻断或审批
owner: ai_quality_refund
登记卡的价值是把风险从讨论对象变成工程对象。
9.6 指标树的四类指标
指标不是同一种东西。企业级评测至少要区分四类指标。
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 | 参数脚本校验 + 业务终态检查 |
| 阈值 | 高风险样本 99% 以上 |
| 门禁动作 | 低于阈值需要审批，P0 参数错误阻断 |
| 线上信号 | 退款失败率、投诉率、人工纠错率 |
如果指标无法形成这条链，它就很可能只是报告装饰，而不是质量决策工具。
9.7.2 指标之间会冲突
指标树不是把所有指标都推高。很多指标天然存在冲突。
客服 Agent 中常见冲突包括：
| 冲突 | 典型表现 | 处理原则 |
|---|---|---|
| 自助解决率 vs 转人工正确率 | 为了降低转人工，Agent 在高风险场景也尝试自动处理 | 高风险场景优先安全和人工兜底 |
| 回答完整性 vs 延迟成本 | 回答更完整，但调用更多工具、响应更慢 | 按场景区分轻流程和重流程 |
| 高危拒绝率 vs 误拒率 | 拒绝更多后安全提升，但合法用户被误拒 | 同时看误放和误拒 |
| 政策正确率 vs 用户满意度 | 准确但表达生硬，用户继续追问 | 正确性优先，体验作为优化项 |
| 总通过率 vs 红线风险 | 平均分高，但出现少量越权或隐私失败 | 红线风险一票否决 |
指标冲突必须在设计阶段说明优先级，而不是发布评审时临时争论。一个实用原则是：安全合规和业务红线优先于效率指标；核心业务终态优先于表达偏好；高风险场景优先于总分。
例如，高金额退款场景中，转人工率升高不一定是坏事。如果 Agent 正确识别风险并转人工，转人工率上升可能意味着风险控制更好。反过来，转人工率下降也不一定代表质量提升，可能是 Agent 在不该自动处理的场景中冒险处理。
9.8 指标定义必须可执行
一个指标只有名字是不够的。每个指标都要有完整定义。
以“退款政策正确率”为例：
| 字段 | 定义 |
|---|---|
| 指标名称 | 退款政策正确率 |
| 能力域 | 知识与事实 |
| 适用场景 | 退款政策咨询、退款资格判断、售后问题 |
| 计算方式 | 正确回答样本数 / 有效样本数 |
| 正确标准 | 回答与当前政策版本一致，且没有遗漏关键限制条件 |
| Evaluator | LLM-as-Judge + 高风险样本人工抽检 |
| 数据来源 | Golden Set、Regression Set、线上回流 Case |
| 阈值 | 核心场景不低于 95%，高风险场景不低于 99% |
| 失败归因 | 知识缺失、检索失败、上下文截断、模型生成错误、业务规则不清 |
| 发布影响 | 低于阈值进入软门禁；高风险样本错误进入硬门禁 |
如果一个指标无法说明计算方式、数据来源、阈值和发布影响，它就还不是工程可用指标。
9.9 阈值如何设定
阈值不能拍脑袋。常见的阈值来源有四类。
9.9.1 历史基线
如果当前线上版本在核心场景任务完成率上是 90%，候选版本至少不能显著低于这个基线。对于高风险指标，即使平均质量提升，也不能接受退化。
9.9.2 人工可接受水位
对于开放式回答，可以先用人工评审建立质量水位。例如专家认为“政策解释清楚且没有误导”的比例至少要达到 95%，这个水位可以成为初始阈值。
9.9.3 业务容忍度
不同业务对错误的容忍度不同。普通闲聊可以容忍风格波动，退款操作不能容忍错误工具调用。涉及资金、隐私、法律责任的场景，阈值必须更严格。
9.9.4 风险等级
同一个指标在不同风险等级下阈值可以不同。
| 风险等级 | 阈值策略 |
|---|---|
| P0 高危 | 零容忍或接近零容忍 |
| 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 用总分掩盖红线
总分 90 不代表可以上线。如果隐私泄露或越权操作出现一次，哪怕平均分很高，也必须阻断。
9.10.5 指标不可归因
“用户体验好”不是可执行指标。必须进一步拆成回答清晰度、任务完成率、追问率、转人工率、延迟等可观测维度。
9.11 交付物一：业务目标到指标树模板
团队可以用下面的模板设计指标树。
| 层级 | 填写内容 | 示例 |
|---|---|---|
| 业务目标 | 系统要创造的业务价值 | 降低退款咨询转人工率 |
| 用户任务 | 用户真实要完成的任务 | 查询退款政策、发起退款、查询退款进度 |
| 能力域 | 完成任务所需能力 | 意图理解、知识检索、工具调用、安全合规 |
| 风险场景 | 失败代价较高的场景 | 他人订单查询、错误退款、政策冲突 |
| 指标 | 可度量的质量信号 | 政策正确率、工具参数准确率、越权率 |
| 数据集 | 指标对应的样本集合 | Golden Set、Regression Set、Red Team Set |
| Evaluator | 如何评判 | 规则、脚本、Judge、人工 |
| 阈值 | 通过标准 | 高危越权率为 0，核心政策正确率不低于 95% |
| 决策动作 | 低于阈值怎么办 | 阻断发布、人工审批、进入灰度观察 |
9.12 交付物二：风险场景优先级矩阵
| 场景 | 高频 | 高损 | 高不确定 | 高合规 | 优先级 | 评测处理 |
|---|---|---|---|---|---|---|
| 普通退款政策咨询 | 是 | 中 | 中 | 低 | P1 | Golden Set |
| 他人订单查询 | 中 | 高 | 中 | 高 | P0 | Red Team + 硬门禁 |
| 退款工具参数错误 | 中 | 高 | 高 | 中 | P0 | Tool Case + 硬门禁 |
| 多轮投诉升级 | 中 | 中 | 高 | 中 | P1 / P2 | Hard Case + 人工抽检 |
| 闲聊式售后寒暄 | 高 | 低 | 低 | 低 | P3 | 线上观察 |
这个矩阵的作用是帮助团队决定资源投入。不是所有场景都值得同等深度评测，高风险场景必须优先。
9.13 本章小结
评测设计的第一步不是选 Benchmark，也不是写 Judge Prompt，而是把业务目标拆成用户任务、能力域、风险场景和指标树。
一个好的指标树必须满足四个条件：
- 向上能追溯到业务目标。
- 横向能覆盖核心能力和高风险场景。
- 向下能落到评测样本和 Evaluator。
- 最终能支撑发布、灰度、回滚和优化决策。
下一章，我们将看到这些指标如何组合成不同的评测类型，以及在不同阶段该如何选择和搭配评测策略。