第 4 章：企业级评测闭环全景图
第 4 章：企业级评测闭环全景图
4.1 为什么需要一张闭环图
很多团队第一次建设 AI 评测体系时，会从最容易落手的地方开始：找几个公开 Benchmark，整理一批业务样本，写一个脚本批量调用模型，再把分数汇总到表格里。这个阶段很有必要，因为它让团队第一次拥有了“可量化”的质量视角。但如果评测停在这里，它很快会暴露三个问题。
第一，分数无法直接支撑发布决策。一个客服 Agent 在 500 条离线样本上平均分提升了 3 分，是否意味着可以全量上线？如果高频场景提升明显，但退款、投诉、身份校验这些高风险场景退化，平均分反而会掩盖真正的风险。
第二，评测结果无法指导优化。评测报告告诉团队“退款政策问答准确率下降”，但没有说明问题发生在知识库、检索、上下文拼接、模型生成、工具调用还是业务规则层。没有归因，评测只能制造焦虑，不能制造改进。
第三，线上问题无法回到离线体系。一个线上 Bad Case 被人工修掉了，但没有进入回归集，也没有进入门禁规则。下一次改 Prompt、换模型、更新知识库，同类问题仍然可能复发。
企业级 AI 评测要解决的不是“能不能打分”，而是“能不能持续形成质量决策和系统改进”。因此，本书首先需要一张闭环图，把评测从一次性动作变成持续运转的质量体系。
4.2 交付物一：企业级 AI 评测的完整闭环
一套完整的企业级 AI 评测体系，可以抽象为十二个环节。
图 4-1 企业级评测闭环全景图
flowchart LR
A["业务目标"] --> B["风险识别"]
B --> C["被评对象分层"]
C --> D["能力拆解与指标树"]
D --> E["评测数据与 Case"]
E --> F["Evaluator / Judge / 人评"]
F --> G["自动化执行"]
G --> H["版本对比与发布决策"]
H --> I["发布门禁与灰度"]
I --> J["线上监控"]
J --> K["Bad Case 归因"]
K --> L["系统与数据优化"]
L --> G
J --> E
这张图最重要的不是节点数量，而是它的方向：评测不是从数据集开始，也不是到报告结束。它从业务目标和风险识别开始，最终要回到系统优化、数据资产和下一轮回归。
如果一个环节没有明确输入、输出和责任人，闭环就会断。如果闭环断了，评测就会退化成报告生产。
4.2.1 闭环节点的输入、输出和责任人
闭环图只有在落到对象、产物和责任人后，才会从方法论变成工程流程。下面这张表可以作为企业搭建 EvalOps 流程时的最小版本。
| 环节 | 关键输入 | 关键输出 | 主要责任人 |
|---|---|---|---|
| 业务目标 | 业务指标、产品目标、成本约束 | 质量目标和收益假设 | 产品 / 业务负责人 |
| 风险识别 | 用户旅程、历史事故、合规要求 | 风险清单和风险等级 | 安全 / 业务 / 评测负责人 |
| 被评对象分层 | 系统架构、链路依赖、版本信息 | 模型、RAG、工具、Agent、业务层对象清单 | 架构 / 应用负责人 |
| 指标树 | 业务目标、风险清单、对象分层 | 指标定义、阈值、门禁候选项 | 评测负责人 |
| 评测数据与 Case | 线上日志、专家样本、事故样本 | Golden、Regression、Hard Case、Red Team | 评测工程师 |
| Evaluator 与人评 | 指标定义、Case Schema、Rubric | 规则、脚本、Judge、人评流程 | 评测 / 平台负责人 |
| 自动化执行 | 评测数据、候选版本、环境配置 | Eval Run、版本对比、成本记录 | 平台工程师 |
| 发布决策 | Run Report、门禁规则、业务优先级 | 放行、灰度、阻断、补测、回滚建议 | 技术 / 产品负责人 |
| 线上监控 | 真实流量、用户反馈、系统日志 | 看板、告警、Bad Case | 运营 / 平台 / 评测团队 |
| 归因与优化 | Bad Case、Trace、版本血缘 | 根因、修复动作、回归样本 | 对应系统 Owner |
这张表的用途不是增加流程负担，而是避免闭环在交接处断裂。每个节点都应能回答三个问题：输入从哪里来，输出交给谁，谁对质量结果负责。
4.3 环节一：业务目标
评测设计必须从业务目标开始。业务目标回答的是：这个 AI 系统被期望在真实业务中创造什么价值。
以企业客服 Agent 为例，业务目标可能包括：
- 降低人工客服接待压力。
- 提高用户自助解决率。
- 缩短退款、售后、物流查询等高频问题的处理时间。
- 在合规和权限边界内完成部分自动化操作。
- 保持用户体验和品牌可信度。
这些目标听起来仍然抽象，但它们决定了后续评测不应该只看“答案像不像人写的”，而要看任务完成率、政策忠实度、工具调用正确性、越权率、转人工率、投诉率、成本和延迟。
评测体系最常见的起点错误，是直接问“该用什么 Benchmark”。正确的问题应该是：业务需要系统在什么场景下可靠工作，哪些失败不可接受，哪些质量变化足以影响发布。
4.4 环节二：风险识别
业务目标说明系统要创造什么价值，风险识别说明系统在哪里可能造成损失。
企业客服 Agent 的风险不能只按“答错”来理解。不同错误的代价差别很大：
| 风险类型 | 示例 | 业务影响 |
|---|---|---|
| 事实错误 | 把 7 天无理由退货说成 15 天 | 用户投诉、信任下降 |
| 业务规则错误 | 对不符合条件的订单承诺退款 | 财务损失、履约争议 |
| 工具调用错误 | 查询错订单或错误提交退款申请 | 直接业务事故 |
| 权限越界 | 泄露他人订单、手机号或地址 | 合规风险、隐私风险 |
| 安全绕过 | 被诱导忽略身份校验流程 | 账户风险、审计风险 |
| 体验失控 | 反复循环、答非所问、过度拒答 | 转人工率上升、用户流失 |
风险识别的结果不是一份泛泛的风险清单，而是后续指标、样本、门禁和线上监控的依据。高风险场景要进入 Golden Set、Regression Set 或 Red Team Set；高危风险要进入硬门禁；中低风险可以进入观察指标或灰度监控。
4.5 环节三：被评对象分层
当系统出错时，“模型不行”通常是最粗糙也最危险的归因。企业级 AI 应用不是一个模型，而是一条链路。
客服 Agent 至少可以拆成四层：
| 层级 | 被评对象 | 典型问题 |
|---|---|---|
| 基础模型层 | LLM 的理解、推理、生成、指令遵循、安全边界 | 幻觉、格式错误、拒答异常、长上下文失效 |
| 组件能力层 | RAG、Tool Call、Memory、Skill、Workflow | 召回失败、工具参数错误、状态污染、流程漏步 |
| 编排执行层 | Planner、Executor、状态机、异常恢复、多轮决策 | 计划错误、循环调用、错误恢复失败、轨迹不可解释 |
| 应用业务层 | 客服 SOP、权限规则、业务终态、用户体验 | 规则不遵循、越权操作、任务未完成、投诉上升 |
分层的价值在于：不同层的评测数据、指标、Evaluator 和修复动作都不同。如果只看最终答案，团队无法判断应该改模型、改知识库、改工具描述、改编排策略，还是改业务规则。
4.6 环节四：能力拆解与指标树
指标树把业务目标和风险清单转化为可执行的评测语言。
客服 Agent 的“退款咨询与操作”场景，可以拆成如下能力：
- 理解用户意图：识别用户是咨询政策、查询进度、发起退款，还是投诉升级。
- 检索正确证据：从知识库中找到当前有效的退款政策、订单状态和操作限制。
- 忠实生成回答：回答必须基于证据，不编造政策，不夸大承诺。
- 正确调用工具：在身份校验通过后，选择正确工具并生成正确参数。
- 遵守业务规则：不对不符合条件的订单承诺退款，不绕过人工审批。
- 控制风险边界：识别他人订单、隐私查询、诱导越权等高危请求。
- 保持体验效率：回答清晰、轮次可控、成本和延迟在可接受范围内。
这些能力再转成指标：
| 能力域 | 指标示例 | 指标类型 |
|---|---|---|
| 意图理解 | 意图识别准确率、多意图识别率 | 诊断指标 |
| 知识检索 | 证据召回率、证据相关性、引用准确率 | 诊断指标 |
| 答案质量 | 政策正确率、忠实度、指令遵循率 | 门禁 / 诊断 |
| 工具调用 | 工具选择准确率、参数准确率、终态校验通过率 | 门禁 |
| 安全合规 | 越权率、隐私泄露率、高危拒绝正确率 | 硬门禁 |
| 体验效率 | 转人工率、用户追问率、P95 延迟、单会话成本 | 观察 / 业务指标 |
指标树的目标不是越多越好，而是让每个指标都能回答一个决策问题：这个指标异常时，谁需要行动，应该改哪里，是否影响上线。
4.7 环节五：评测数据与 Case
评测数据不是题库。企业级评测数据至少要回答四个问题：
- 样本来自哪里：线上日志、专家构造、历史事故、对抗生成，还是合成数据。
- 样本覆盖什么：高频场景、高风险场景、长尾场景、边界场景、安全场景。
- 样本如何执行：输入是什么，上下文是什么，可用工具是什么，期望行为是什么。
- 样本如何维护：版本如何管理，何时淘汰，如何防污染，如何从线上回流。
一条客服 Agent Case 不应只有一个用户问题。它至少应该包含：
| 字段 | 示例 |
|---|---|
| scenario | 退款政策咨询 / 退款操作 / 投诉升级 |
| user_input | “我这个订单已经签收 10 天了，还能退吗？” |
| context | 订单品类、签收时间、会员等级、历史对话 |
| knowledge_version | 退款政策知识库版本 |
| available_tools | 订单查询、退款资格校验、人工转接 |
| expected_behavior | 先查询订单状态，再基于政策说明是否可退，不承诺超权限操作 |
| Rubric | 政策正确性、证据忠实度、拒绝边界、体验质量 |
| risk_level | 中 / 高 |
没有结构化 Case，就无法自动化执行、无法复现、无法归因，也无法稳定回归。
4.8 环节六：Evaluator、Judge 与人工评测
Evaluator 是评测体系的度量仪器。不同质量维度需要不同仪器。
| 评估方式 | 适用场景 | 客服 Agent 示例 |
|---|---|---|
| 规则校验 | 明确红线、格式、关键词、结构化输出 | 是否泄露手机号、是否输出非法 JSON |
| 脚本校验 | 工具调用、代码执行、终态验证 | 退款工具参数是否匹配订单状态 |
| 检索指标 | RAG 召回和证据质量 | 正确政策片段是否进入 Top-K |
| LLM-as-Judge | 开放式回答质量、忠实度、表达清晰度 | 回答是否忠实于政策证据 |
| 人工复核 | 高风险、主观体验、Judge 分歧样本 | 复杂投诉、监管敏感、低置信样本 |
成熟体系不会迷信单一 Judge，也不会把所有样本都交给人工。更现实的方式是混合流水线：规则先拦红线，脚本校验确定性动作，Judge 处理开放质量，低置信和高风险样本进入人工复核。
4.9 环节七：自动化执行与版本对比
当评测对象从单个模型扩展到模型、Prompt、知识库、工具、Agent 编排和业务规则时，手工跑评测很快失效。自动化执行需要保证四件事：
- 可重复：同一版本、同一数据、同一 Evaluator 能复现同一结论。
- 可对比：不同版本之间只有目标变量变化，其他环境保持一致。
- 可追踪：每次 Run 都记录模型、Prompt、数据集、工具、知识库和 Evaluator 版本。
- 可扩展：支持并发、重试、缓存、断点续跑和成本控制。
对客服 Agent 来说，“两个版本对比后哪个更好”不是一句直觉判断，而要明确：
- 使用了哪个模型版本。
- Prompt 是否变化。
- 知识库和索引版本是否一致。
- 工具 Schema 是否变化。
- 数据集版本是否一致。
- Judge 或规则评估器是否一致。
- 是否包含相同的高风险样本和回归样本。
缺少这些版本血缘，分数变化就无法解释。
4.10 环节八：发布门禁与灰度
评测如果不影响发布，就不是质量防线。
门禁的核心是把评测指标转成发布规则：
| 门禁类型 | 规则示例 | 处理方式 |
|---|---|---|
| 硬门禁 | 高危越权率必须为 0；隐私泄露必须为 0 | 不通过则禁止发布 |
| 软门禁 | 核心场景通过率低于基线 2% | 需要负责人审批 |
| 成本门禁 | 单会话成本增长超过 30% | 进入评审或灰度限制 |
| 观察指标 | 表达风格、用户满意度趋势 | 不阻断发布，但进入监控 |
| 灰度条件 | 小流量投诉率不高于上一版本 | 满足后逐步放量 |
门禁不是越多越好。门禁太少会失去约束，门禁太多会让团队绕开流程。一个实用原则是：只有影响发布决策、事故风险或业务成本的指标，才有资格成为门禁。
4.11 环节九：线上监控与数据回流
离线评测永远无法完全覆盖真实用户分布。线上监控负责发现离线体系没有覆盖的问题。
客服 Agent 的线上信号包括：
- 投诉率。
- 转人工率。
- 用户追问率。
- 点赞 / 点踩。
- 退款操作失败率。
- 工具调用错误率。
- 高危拒绝命中率。
- 单会话成本和延迟。
- 人工客服标记的 Bad Case。
线上监控不是简单看大盘。关键是把线上问题回流到离线评测集：
- 采集真实 Bad Case。
- 脱敏和去重。
- 按错误类型和风险等级标注。
- 归因到模型、RAG、工具、Agent 编排或业务规则。
- 沉淀到 Regression Set、Hard Case Set 或 Red Team Set。
- 在下一次版本评测和门禁中自动回归。
没有回流，线上事故只会被一次性处理；有回流，线上事故会变成长期资产。
4.12 环节十：Bad Case 归因与优化回流
评测发现 Bad Case 只是开始。企业级评测真正有价值的地方，是把 Bad Case 转化为可执行的优化动作。
以“客服 Agent 错误承诺退款”为例，可能有多种根因：
| 根因层级 | 可能问题 | 优化方向 |
|---|---|---|
| 知识库 | 政策过期或缺失 | 更新知识库、补充生效时间 |
| 检索 | 正确政策未召回 | 调整 Chunk、Embedding、召回策略 |
| 上下文组装 | 正确证据被截断 | 优化上下文拼接和证据排序 |
| 模型生成 | 看到了证据仍编造 | 调整 Prompt、加强忠实度约束、补训练数据 |
| 工具调用 | 未调用退款资格校验 | 优化工具描述、强制工具前置 |
| Agent 编排 | 跳过身份校验或审批流程 | 调整状态机和业务流程约束 |
| 业务规则 | SOP 本身定义不清 | 明确规则、补充人工审批边界 |
不同根因对应完全不同的修复动作。如果归因错了，团队会在错误方向上投入。最典型的反模式是：所有问题都归因到模型，然后直接微调。结果是短期分数上升，系统性问题仍然存在。
4.13 交付物二：闭环断裂自检清单
第一类断裂是“评了不卡发布”。团队有评测报告，但发布流程不需要看评测结果。这样评测只能提供建议，不能形成防线。
第二类断裂是“线上不回流”。离线评测和线上监控是两套系统，线上 Bad Case 被临时修复，没有进入回归集。这样问题会反复出现。
第三类断裂是“归因不驱动优化”。报告列出很多 Bad Case，但没有 Owner、没有修复动作、没有回归验证。这样评测越做越多，却不能提升系统质量。
更细地看，闭环断裂通常发生在三种位置。
数据断裂，是指线上真实问题没有进入离线评测资产，或者评测样本没有版本、标签和风险分层。表现为团队每次都能发现问题，但无法防止同类问题复发。
决策断裂，是指评测结果不能进入发布、灰度、回滚和人工审批流程。表现为报告做得很完整，但版本是否上线仍然主要依赖会议判断。
优化断裂，是指 Bad Case 没有被归因到具体系统对象，也没有进入修复验证。表现为问题越来越多，修复越来越散，评测团队成为问题登记处，而不是质量改进引擎。
这三类断裂可以映射到不同修复动作：
| 断裂类型 | 典型症状 | 修复动作 |
|---|---|---|
| 数据断裂 | 线上问题重复出现，离线分数仍然很好 | 建立 Bad Case 回流、去重、标注和回归机制 |
| 决策断裂 | 高风险失败仍可发布，门禁没有约束力 | 把关键指标接入 CI/CD、灰度和审批流程 |
| 优化断裂 | 报告指出错误，但无人修复或无法验证 | 建立根因标签、Owner 分派和修复后回归规则 |
闭环断裂自检可以用下面这张表：
| 自检问题 | 如果答案是否定的，说明什么 |
|---|---|
| 每个核心业务目标是否有对应指标？ | 评测目标和业务目标脱节 |
| 每个高风险场景是否进入评测集？ | 风险识别没有转成资产 |
| 每个门禁指标是否有明确阈值？ | 评测不能支撑发布决策 |
| 每个 Bad Case 是否有归因标签？ | 结果不能指导优化 |
| 每个修复是否进入回归集？ | 问题可能复发 |
| 线上问题是否定期回流离线集？ | 离线体系会逐渐失效 |
| 每次评测 Run 是否可复现？ | 版本对比不可信 |
4.14 本章小结
企业级 AI 评测不是一个工具、一个脚本或一份报告，而是一套持续运转的质量闭环。它从业务目标和风险识别开始，经过对象分层、指标树、评测数据、Evaluator、自动化执行、发布门禁和线上监控，最终回到 Bad Case 归因、系统优化和数据回流。
本章给出的闭环图，是后续章节的总地图。后续章节会分别展开数据、Case、Evaluator、Trace、平台、门禁、看板、归因和优化闭环。
读者可以先用本章的闭环断裂自检清单检查自己的团队：如果评测结果不能影响发布，线上问题不能回流，Bad Case 不能驱动优化，那么评测体系还没有真正闭环。
从下一章开始，我们将深入闭环的第一个关键环节——搞清楚到底在评什么，建立 Agent 应用的分层评测对象模型。