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

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 闭环节点的输入、输出和责任人

闭环图、责任表和后文统一使用 12 个操作环节。每个环节都有独立的决策或交接产物。企业无须对应设置 12 个团队，但关键责任不能在合并叙述中消失。

闭环图只有在落到对象、产物和责任人后，才会从方法论变成工程流程。下面这张表可以作为企业搭建 EvalOps 流程时的最小版本。

环节	关键输入	关键输出	主要责任人
业务目标	业务指标、产品目标、成本约束	质量目标和收益假设	产品 / 业务负责人
风险识别	用户旅程、历史事故、合规要求	风险清单和风险等级	安全 / 业务 / 评测负责人
被评对象分层	系统架构、链路依赖、版本信息	模型、RAG、工具、Agent、业务层对象清单	架构 / 应用负责人
指标树	业务目标、风险清单、对象分层	指标定义、阈值、门禁候选项	评测负责人
评测数据与 Case	线上日志、专家样本、事故样本	Golden、Regression、Hard Case、Red Team	评测工程师
Evaluator 与人评	指标定义、Case Schema、Rubric	规则、脚本、Judge、人评流程	评测 / 平台负责人
自动化执行	评测数据、候选版本、环境配置	Eval Run、失败明细、成本记录	平台工程师
版本对比与发布决策	基线与候选 Run、风险覆盖、业务优先级	放行、灰度、阻断、补测或回滚建议	技术 / 产品负责人
发布门禁与灰度	发布建议、门禁规则、审批与降级策略	门禁结果、灰度范围、回滚条件	发布负责人 / 平台工程师
线上监控	真实流量、用户反馈、系统日志	看板、告警、Bad Case	运营 / 平台 / 评测团队
Bad Case 归因	Bad Case、Trace、版本血缘	根因假设、证据与责任对象	评测负责人 / 对应系统 Owner
系统与数据优化	已确认根因、修复方案、验收条件	系统修复、数据更新、回归样本	对应系统 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、权限规则、业务终态、用户体验	规则不遵循、越权操作、任务未完成、投诉上升

本节只在全景图中确定四层坐标；层级定义、Case、指标和 Evaluator 的差异以第 5 章为权威展开。

分层的价值在于：不同层的评测数据、指标、Evaluator 和修复动作都不同。如果只看最终答案，团队无法判断应该改模型、改知识库、改工具描述、改编排策略，还是改业务规则。

4.6 环节四：能力拆解与指标树

指标树把业务目标和风险清单转化为可执行的评测语言。

客服 Agent 的“退款咨询与操作”场景，可以拆成如下能力：

理解用户意图：识别用户是咨询政策、查询进度、发起退款，还是投诉升级。
检索正确证据：从知识库中找到当前有效的退款政策、订单状态和操作限制。
忠实生成回答：回答必须基于证据，不编造政策，不夸大承诺。
正确调用工具：在身份校验通过后，选择正确工具并生成正确参数。
遵守业务规则：不对不符合条件的订单承诺退款，不绕过人工审批。
控制风险边界：识别他人订单、隐私查询、诱导越权等高危请求。
保持体验效率：回答清晰、轮次可控、成本和延迟在可接受范围内。

这些能力再转成指标：

能力域	指标示例	指标类型
意图理解	意图识别准确率、多意图识别率	诊断指标
知识检索	证据召回率、证据相关性、引用准确率	诊断指标
答案质量	政策正确率、忠实度、指令遵循率	门禁 / 诊断
工具调用	工具选择准确率、参数准确率、终态校验通过率	门禁
安全合规	越权率、隐私泄露率、高危拒绝正确率	硬门禁
体验效率	转人工率、用户追问率、P95 延迟、单会话成本	观察 / 业务指标

指标数量不是目标。每个指标都要回答一个决策问题：它异常时谁需要行动，应该改哪里，是否影响上线。

4.7 环节五：评测数据与 Case

评测数据不是题库。企业级评测数据至少要回答四个问题：

样本来自哪里：线上日志、专家构造、历史事故、对抗生成，还是合成数据。
样本覆盖什么：高频场景、高风险场景、长尾场景、边界场景、安全场景。
样本如何执行：输入是什么，上下文是什么，可用工具是什么，期望行为是什么。
样本如何维护：版本如何管理，何时淘汰，如何防污染，如何从线上回流。

一条客服 Agent Case 不应只有一个用户问题。它至少应该包含：

字段	示例
case_id / case_version	refund_quality_issue_001 / v1
dataset_id / dataset_version	refund_core_set / v3
scenario	退款政策咨询 / 退款操作 / 投诉升级
input	“我这个订单已经签收 10 天了，还能退吗？”
context	订单品类、签收时间、会员等级、历史对话
environment	当前生效的退款政策语料；订单查询、退款资格校验、人工转接工具可用
expected_behavior	先查询订单状态，再基于政策说明是否可退，不承诺超权限操作
rubric	政策正确性、证据忠实度、拒绝边界、体验质量
risk_level	P1
impact_basis	质量问题售后被错误拒绝会影响核心用户权益，但本案例不涉及 P0 级副作用

没有结构化 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 来说，一次可用于后续版本对比的 Run 必须明确：

使用了哪个模型版本。
Prompt 是否变化。
知识库和索引版本是否一致。
工具 Schema 是否变化。
数据集版本是否一致。
Judge 或规则评估器是否一致。
是否包含相同的高风险样本和回归样本。

缺少这些版本血缘，分数变化就无法解释。自动化执行的直接产物是可复现的 Run，而不是发布结论；Run 要进入下一环节，与基线、风险覆盖和业务收益一起判断。

4.10 环节八：版本对比与发布决策

版本对比需要回答变化发生在哪里、证据是否充分、是否值得承担发布风险；把候选版本和基线总分并排展示还不够。

发布评审至少要核对四组证据：

证据	核对问题
能力变化	核心任务、长尾任务和关键组件分别改善或退化了什么
风险变化	P0 / P1 场景是否出现新失败，已有红线是否全部通过
运行可信度	数据、Evaluator、环境和版本血缘是否可比，差异是否超出波动
工程与业务代价	延迟、成本、人工接管和预期业务收益是否支持发布

结论应明确写成放行、限定灰度、阻断、补测或回滚建议，并说明适用场景、不确定性和后续动作。数值提升本身不能代替发布决定；证据覆盖不足时，“补测”比勉强给出放行或阻断更可信。

4.11 环节九：发布门禁与灰度

评测如果不影响发布，就不是质量防线。

门禁把上一环节的发布建议转成可执行规则。下表中的数值仅用于展示规则写法，团队应使用自己的风险容忍度、历史基线和审批机制确定阈值。

门禁类型	规则示例	处理方式
硬门禁	规定评测范围内经确认的高危越权事件数为 0；隐私泄露事件数为 0	出现确认事件则禁止发布
软门禁	核心场景通过率低于基线 2%	需要负责人审批
成本门禁	单会话成本增长超过 30%	进入评审或灰度限制
观察指标	表达风格、用户满意度趋势	不阻断发布，但进入监控
灰度条件	小流量投诉率不高于上一版本	满足后逐步放量

事件数为 0 只说明本次规定范围内没有观察到经确认事件，不代表真实风险为零。报告还应给出样本范围、检测方法和人工复核覆盖。

门禁不是越多越好。门禁太少会失去约束，门禁太多会让团队绕开流程。一个实用原则是：只有影响发布决策、事故风险或业务成本的指标，才有资格成为门禁。

4.12 环节十：线上监控与数据回流

离线评测永远无法完全覆盖真实用户分布。线上监控负责发现离线体系没有覆盖的问题。

客服 Agent 的线上信号包括：

投诉率。
转人工率。
用户追问率。
点赞 / 点踩。
退款操作失败率。
工具调用错误率。
高危拒绝命中率。
单会话成本和延迟。
人工客服标记的 Bad Case。

线上监控不是简单看大盘。关键是把线上问题回流到离线评测集：

采集真实 Bad Case。
脱敏和去重。
按错误类型和风险等级标注。
归因到模型、RAG、工具、Agent 编排或业务规则。
沉淀到 Regression Set、Hard Case Set 或 Red Team Set。
在下一次版本评测和门禁中自动回归。

没有回流，线上事故只会被一次性处理；有回流，线上事故会变成长期资产。

4.13 环节十一：Bad Case 归因

评测发现 Bad Case 只是开始，后续还要把它转化为可执行的优化动作。

下面只展示全景图所需的简化诊断视图。全书统一的七层根因模型、证据成熟度和对照验证方法以第 21 章为准。

以“客服 Agent 错误承诺退款”为例，可能有多种根因：

根因层级	可能问题	优化方向
知识库	政策过期或缺失	更新知识库、补充生效时间
检索	正确政策未召回	调整 Chunk、Embedding、召回策略
上下文组装	正确证据被截断	优化上下文拼接和证据排序
模型生成	看到了证据仍编造	调整 Prompt、加强忠实度约束、补训练数据
工具调用	未调用退款资格校验	优化工具描述、强制工具前置
Agent 编排	跳过身份校验或审批流程	调整状态机和业务流程约束
业务规则	SOP 本身定义不清	明确规则、补充人工审批边界

归因产物应包含可证伪的根因假设、支持证据和责任对象，不能停在方便统计的错误标签。团队需要用 Trace、对照实验或最小复现确认根因，再把已确认问题交给下一环节；否则“归因”仍然只是猜测。

4.14 环节十二：系统与数据优化

不同根因对应不同修复动作。知识库过期要修内容治理，检索失败要修召回链路，工具参数错误要修 Schema 与校验，编排漏步要修状态机，业务规则含混则要先澄清 SOP。把所有问题都归因到模型并直接微调，只会把系统性缺陷藏进新的输出分布。

修复完成后，闭环要完成四项动作。前两项更新系统和评测资产，后两项验证修复并重新进入发布决策：

更新系统：提交修复，记录影响范围、Owner、版本和回滚方案。
更新评测资产：把原始 Bad Case、邻近边界样本和修复验收条件沉淀为 Regression Case。
重新执行：用同一证据链验证原问题已关闭，同时检查相邻能力没有退化。
回到决策：新的 Run 再进入版本对比、门禁和灰度，而不是因为“已经修过”就直接发布。

优化环节只有在修复通过回归并进入下一轮发布证据后才算关闭。这样，线上事故才能转化为长期质量资产。

4.15 交付物二：闭环断裂自检清单

第一类断裂是“评了不卡发布”。团队有评测报告，但发布流程不需要看评测结果。这样评测只能提供建议，不能形成防线。

第二类断裂是“线上不回流”。离线评测和线上监控是两套系统，线上 Bad Case 被临时修复，没有进入回归集。这样问题会反复出现。

第三类断裂是“归因不驱动优化”。报告列出很多 Bad Case，但没有 Owner、没有修复动作、没有回归验证。这样评测越做越多，却不能提升系统质量。

更细地看，闭环断裂通常发生在三种位置。

数据断裂，是指线上真实问题没有进入离线评测资产，或者评测样本没有版本、标签和风险分层。表现为团队每次都能发现问题，但无法防止同类问题复发。

决策断裂，是指评测结果不能进入发布、灰度、回滚和人工审批流程。表现为报告做得很完整，但版本是否上线仍然主要依赖会议判断。

优化断裂，是指 Bad Case 没有被归因到具体系统对象，也没有进入修复验证。表现为问题越来越多，修复越来越散，评测团队成为问题登记处，而不是质量改进引擎。

这三类断裂可以映射到不同修复动作：

断裂类型	典型症状	修复动作
数据断裂	线上问题重复出现，离线分数仍然很好	建立 Bad Case 回流、去重、标注和回归机制
决策断裂	高风险失败仍可发布，门禁没有约束力	把关键指标接入 CI/CD、灰度和审批流程
优化断裂	报告指出错误，但无人修复或无法验证	建立根因标签、Owner 分派和修复后回归规则

闭环断裂自检可以用下面这张表：

自检问题	如果答案是否定的，说明什么
每个核心业务目标是否有对应指标？	评测目标和业务目标脱节
每个高风险场景是否进入评测集？	风险识别没有转成资产
每个门禁指标是否有明确阈值？	评测不能支撑发布决策
每个 Bad Case 是否有归因标签？	结果不能指导优化
每个修复是否进入回归集？	问题可能复发
线上问题是否定期回流离线集？	离线体系会逐渐失效
每次评测 Run 是否可复现？	版本对比不可信

4.16 本章小结

企业级 AI 评测是一套持续运转的质量闭环。它从业务目标和风险识别开始，经过对象分层、指标树、评测数据、Evaluator、自动化执行、版本决策、发布门禁和线上监控，最终回到 Bad Case 归因、系统与数据优化。

本章给出的闭环图，是后续章节的总地图。后续章节会分别展开数据、Case、Evaluator、Trace、平台、门禁、看板、归因和优化闭环。

读者可以先用本章的闭环断裂自检清单检查自己的团队：如果评测结果不能影响发布，线上问题不能回流，Bad Case 不能驱动优化，那么闭环仍有明显断点。

从下一章开始，我们将深入闭环的第一个关键环节——搞清楚到底在评什么，建立 Agent 应用的分层评测对象模型。

第 4 章：企业级评测闭环全景图