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

19.1 评测报告如果不能阻断发布，就不是质量防线

一个客服 Agent 候选版本上线前，评测报告已经提示两个高危问题：在某些多轮对话中，它会跳过身份校验直接查询订单；在退款工具调用中，有少量样本把退款原因参数填错。

报告发到了群里。算法同学说会继续优化，产品同学说这次需求很急，业务同学说先小流量试试。最终版本照常上线。上线后，问题在真实用户中复现，团队又回到救火状态。

问题在于评测没有进入发布流程。

企业级评测需要接入 CI/CD 和发布治理，把结果转化为明确动作：放行、阻断、灰度、人工审批、回滚、补测、豁免留痕。

19.2 什么变更触发什么评测

本节是全书“变更触发评测矩阵”的权威出处。第 10 章用于解释评测组合，第 16 章用于解释成本调度，第 18 章用于解释增量执行；若具体规则不一致，以本章发布决策口径和配套《发布门禁规则模板》为准。

不同变更影响不同风险面，不能每次都全量评测，也不能所有变更都只跑 Smoke。

变更类型	主要风险	必跑评测	条件触发
Prompt 修改	指令遵循、回答风格、拒答边界变化	Golden、Regression、Hard Case	涉及权限或拒答边界时增加 Red Team
模型替换	全局能力、成本、延迟、安全边界变化	全量 Eval Set、Red Team、成本与延迟	争议维度增加人工偏好评测
知识库更新	政策过期、召回变化、引用错误	RAG Case、相关 Regression	影响业务流程时增加端到端 Case
Embedding / Index 更新	召回排序变化	检索指标、RAG 端到端	影响核心政策时增加相关 Regression
Tool Schema 修改	工具选择、参数和权限错误	Tool Case、Trace Case	有副作用或长程依赖时增加沙箱任务
Agent 编排修改	步骤顺序、状态、异常恢复变化	Trace Case、端到端任务	多轮状态变化时增加多轮 Hard Case
安全策略修改	拒答、越权、误拒变化	Red Team、安全回归	策略收紧时增加误拒率评测
Evaluator 修改	分数口径变化	Meta-Eval、人工校准集	影响历史可比性时重评历史 Run 样本

变更触发矩阵的价值是减少拍脑袋。研发改了什么，平台就知道该跑什么。

19.2.1 变更影响声明

每次 AI 应用变更都应带一份结构化影响声明，包括：

字段	说明
change_id	变更标识
changed_objects	变更对象：Prompt、Model、Knowledge、Tool、Agent 等
affected_scenarios	可能影响的业务场景
affected_risks	可能影响的风险
required_evals	必跑评测
owner	变更负责人
rollback_plan	回滚方案

示例：

change_id: refund_prompt_v13
changed_objects:
  - app_prompt
affected_scenarios:
  - 退款政策解释
  - 会员部分退款
affected_risks:
  - 错误退款承诺
  - 过度转人工
required_evals:
  - refund_golden_set
  - refund_regression_set
  - refund_red_team_privacy
owner: refund_agent_owner
rollback_plan: revert_to_refund_prompt_v12

影响声明让 CI/CD 系统能自动选择评测任务。

19.3 门禁指标分层

门禁不是所有指标都卡发布。本章把指标分成硬门禁、软门禁和观察指标三类，并为紧急例外另设一套豁免治理。豁免不是第四类指标，也不得改变 P0 红线定义。

19.3.1 硬门禁

硬门禁一票否决。

客服 Agent 的硬门禁包括：

出现经确认的隐私泄露事件。
出现经确认的高危越权操作。
未授权调用敏感工具。
Red Team 高危样本通过攻击。
核心工具终态错误。

硬门禁只用于不可接受风险，数量宜少、含义要明确。事件型红线判断的是“本次证据中是否观察到失败”，不是用有限样本证明真实风险率绝对为零；零次观察失败仍需结合覆盖、样本量和线上防护解释剩余风险。

19.3.2 软门禁

软门禁不一定直接阻断，但需要负责人审批。

示例：

核心场景任务完成率低于基线。
Hard Case 明显退化。
成本增长超过阈值。
Judge 与人工分歧集中在高价值场景。

软门禁适合需要业务权衡的情况。

19.3.3 观察指标

观察指标不阻断发布，但进入灰度监控。

示例：

回答长度。
用户追问率。
P95 延迟。
工具重试次数。
过度拒答率。

观察指标异常时，需要分析，但不应自动阻断所有发布。

19.3.4 豁免机制

制度预先允许的非 P0 异常，在紧急发布中可能进入受控豁免；P0 不得豁免。每次豁免必须记录：

豁免原因。
受影响指标。
风险承诺人。
补测计划。
回滚条件。
事后复盘时间。

没有留痕的豁免，会让门禁逐渐失去权威。

19.3.5 风险接受记录

软门禁审批和豁免都应形成风险接受记录。

字段	说明
risk_item	被接受的风险
evidence	评测证据
reason	为什么可以接受
scope	影响范围
traffic_limit	灰度或流量限制
owner	风险承诺人
deadline	补救时间
rollback_condition	回滚条件

风险接受只有在证据充分、边界清楚、责任明确时才构成有效的业务权衡，不能成为绕过质量体系的路径。P0 风险不应通过风险接受放行。

19.4 发布门禁规则设计

门禁规则应具备五个要素：

要素	示例
指标	高危越权率
阈值	必须为 0
数据范围	Red Team Set + 高风险 Regression Set
动作	阻断发布
Owner	安全评测负责人

下面是用于说明结构的假设门禁规则。0.99 只是项目示例值，不是行业统一阈值：

gate_id: refund_agent_p0_safety_gate
scope: 客服 Agent 退款场景
metrics:
  - metric: privacy_leak_event_count
    threshold: 0
    action: block
  - metric: unauthorized_tool_call_event_count
    threshold: 0
    action: block
  - metric: refund_tool_argument_accuracy
    threshold: 0.99
    action: approval
dataset:
  - red_team_refund_v3
  - regression_refund_p0_v5
owner: ai_safety_eval

门禁规则应该放在平台中版本化管理，而不是散落在文档和聊天记录里。Gate 是版本化策略；Gate Result 是某次 Run 按某个 Gate 版本计算出的证据。两者不能共用一个对象，也不能用发布决策反向覆盖历史 Gate Result。Gate Result 只有在策略要求的指标全部计算成功且必要证据完整时才能写为 passed；任一指标缺失或计算失败时，整体结果应为 error 或 approval_required，并列出缺失项。

19.4.1 发布决策记录

门禁结果需要转成发布决策记录，明确说明“基于哪些证据做了什么发布动作”，而不是重复整份评测报告。

第 19、20、22 章的记录类资产共用一组治理字段：record_id、record_type、source_id、affected_scope、owner、status、deadline、evidence_links、created_at、updated_at。本章在通用头上增加门禁结果、发布动作、豁免和回滚条件；第 20 章增加触发信号和初步假设；第 22 章增加根因、修复、验证与防复发字段。三者是同一问题生命周期中的不同记录，不应互相替代。

字段	说明
release_id	发布标识
candidate_version	候选版本
baseline_version	对照版本
eval_run_ids	支撑决策的评测 Run
gate_policy_version	本次判断采用的 Gate 版本
gate_result_ids	各项 Gate Result 证据链接
aggregate_gate_outcome	passed、blocked、approval_required、error
risk_summary	主要风险和影响范围
decision	放行、灰度、阻断、回滚、补测
approver	决策人或审批人
conditions	放量条件、观察条件、补救条件
rollback_plan	回滚对象和触发条件

发布决策记录的价值，是让质量判断可审计、可复盘、可比较。后续如果线上出现事故，团队可以回到决策记录，判断当时证据是否充分、风险是否被接受、门禁是否需要调整。

19.5 灰度发布

离线评测通过，不代表可以直接全量。灰度阶段负责验证真实用户分布下的表现。

客服 Agent 灰度可以按阶段进行：

下表流量比例仅用于展示分阶段方法。实际比例、观察窗口和样本要求应由业务风险、流量规模、统计不确定性和兜底能力共同决定。

阶段	流量	关注指标
内部灰度	0% 真实用户	人工测试、红队复核、日志完整性
小流量	1%-5%	投诉率、转人工率、高危拦截、工具失败
扩大灰度	10%-30%	业务指标、成本、延迟、Bad Case 分布
全量	100%	长期趋势、漂移、回归问题

灰度需要明确的放量条件和回滚条件，不能只做“先放一点看看”。

19.5.1 灰度实验设计

灰度要像实验一样设计。

要素	说明
实验目标	验证候选版本是否在真实流量下稳定
流量范围	哪些渠道、用户、场景进入灰度
排除范围	高风险或不适合实验的场景
观察指标	投诉、转人工、工具失败、成本、延迟
观察窗口	至少覆盖一个合理业务周期
放量条件	指标达到什么水位才能扩大流量
回滚条件	出现什么信号立即回滚

客服 Agent 的会员部分退款场景如果离线证据不足，可以在灰度中保持人工兜底，不应直接暴露给全量用户。

19.6 回滚条件

回滚条件应提前定义，而不是事故发生后临时讨论。

客服 Agent 的回滚条件包括：

出现隐私泄露或越权操作。
投诉率超过当前线上基线。
转人工率显著上升。
退款工具失败率超过阈值。
单会话成本或延迟超过预算。
同类 Bad Case 在灰度中连续出现。

回滚不一定意味着整个版本失败。它也可能只回滚某个 Prompt、工具、知识库索引或 Agent 编排配置。

19.6.1 回滚演练

回滚条件写在文档里还不够。高风险 Agent 应定期做回滚演练。

回滚演练要验证：

验证项	问题
回滚对象	能否只回滚 Prompt、模型、知识库、工具策略或 Agent 配置
回滚时效	从触发到生效需要多久
状态一致性	回滚后会话、缓存、工具状态是否一致
数据兼容	回滚前后版本生成的 Trace、日志和报告是否可解释
用户影响	回滚是否造成会话中断或重复操作
责任链路	谁有权限触发，谁确认完成

客服 Agent 的回滚尤其要注意工具副作用。如果候选版本已经创建了退款申请或投诉工单，单纯回滚 Prompt 不能撤销业务动作。回滚计划要说明哪些状态需要人工处理，哪些工具操作需要补偿或审计。

19.7 CI/CD 集成位置

图 19-1 CI/CD 门禁流程图

flowchart TD
  A["代码/配置变更(Prompt/Model/KB/Tool/Agent)"] --> B["变更影响声明"]
  B --> C["触发评测任务"]
  C --> D["Smoke/受影响Case"]
  D --> E{"PR门禁"}
  E -->|不通过| F["阻断合并"]
  E -->|通过| G0["Golden+核心Regression"]
  G0 --> G1{"合并前门禁"}
  G1 -->|不通过| F
  G1 -->|通过| G["合并到主分支"]
  G --> H["发布前全量评测+Red Team"]
  H --> I{"计算Gate Result"}
  I -->|硬门禁失败| J["阻断发布"]
  I -->|计算错误/证据缺失| J
  I -->|软门禁| K{"负责人审批/豁免"}
  I -->|通过| D0["记录发布决定"]
  K -->|批准并留痕| D0
  K -->|拒绝| J
  D0 --> L["内部灰度"]
  L --> M["小流量灰度(1-5%)"]
  M --> N["线上监控+Bad Case采样"]
  N --> O{"灰度指标正常?"}
  O -->|异常| P["回滚"]
  O -->|正常| Q["扩大灰度(10-30%)"]
  Q --> R{"持续观察"}
  R -->|异常| P
  R -->|稳定| S["全量发布"]
  S --> T["长期监控+漂移检测"]

评测可以接入多个阶段。

阶段	评测
Pull Request	Smoke、受影响 Case、格式和规则校验
合并前	Golden Set、核心 Regression Set
发布前	全量业务 Eval Set、Red Team、成本延迟
灰度中	线上指标、Bad Case 采样、人工抽检
全量后	漂移监控、周期性回归、线上回流

不是所有评测都适合放在 PR 阶段。Judge 大规模评测、Agent 沙箱长程任务、人工复核成本较高，更适合发布前或夜间批量运行。

19.7.1 CI/CD 中的质量记录

每次发布都应形成质量记录。

质量记录至少包含：

变更影响声明。
触发的评测任务。
Run ID 和报告链接。
Gate policy 版本和 Gate Result ID。
发布决定及其审批人、条件和时间。
豁免或审批记录。
灰度计划。
回滚条件。
发布负责人。

这份记录让事后复盘有证据，也让不同版本之间的质量决策可追溯。

19.8 门禁反模式

19.8.1 门禁太松

所有指标都只是“建议关注”，没有任何阻断动作。结果是评测报告被阅读，但不能改变发布。

19.8.2 门禁太多

几十个指标都要求提升，导致正常迭代无法发布，团队最终绕开门禁。

19.8.3 只看总分

总分通过但高危样本失败，这类门禁设计无效。高风险指标需要独立判断。

19.8.4 没有豁免治理

制度预先允许的非 P0 异常可以进入紧急豁免，但必须记录风险和补救动作；P0 仍不得豁免。缺少这条边界，豁免会变成绕过质量体系的常规通道。

19.8.5 门禁不随业务更新

业务规则变了，门禁仍按旧样本和旧阈值判断，会导致错误阻断或错误放行。

19.9 交付物一：变更触发评测矩阵

19.2 是唯一的规则矩阵，本节不再复制一张需要人工同步的表。交付时应把 19.2 的内容保存为版本化配置，至少包含以下字段：

字段	说明
matrix_version	当前触发矩阵版本
change_type	Prompt、Model、Knowledge、Index、Tool、Agent、Safety、Evaluator
impact_tags	权限、知识、成本、延迟、流程、状态等影响标签
required_eval_suites	必跑评测集和执行层级
conditional_eval_suites	条件满足时追加的评测
trigger_condition	条件评测的可计算触发规则
owner	规则维护人
reviewed_at	最近复审时间

CI/CD 根据这份配置生成实际任务，章节表格和平台配置不得分别维护两套取值。

19.10 交付物二：发布门禁规则模板

字段	说明
gate_id	门禁标识
scope	适用业务和系统
metric	指标
dataset	评测数据范围
threshold	阈值
action	block / approval / observe
owner	负责人
exemption_policy	豁免规则
rollback_condition	回滚条件
audit_log	审计记录

19.11 交付物三：灰度放量与回滚条件表

阶段	放量条件	回滚条件
内部灰度	红队和核心回归通过	高危样本失败
小流量	投诉率、转人工率不高于基线	隐私、越权、工具事故
扩大灰度	业务指标稳定，成本可接受	同类 Bad Case 聚集
全量	连续观察周期稳定	核心指标明显退化

19.12 方法依据与适用边界

本章把软件交付中的质量门禁和灰度发布方法应用到 AI 系统，但触发矩阵、P0—P3 和 Gate Result 对象仍是本书项目框架，不是通用行业标准。

Google SRE Workbook：Canarying Releases讨论如何用部分流量、指标和自动判定降低发布风险，为本章的分阶段灰度和回滚思路提供工程参照。
NIST AI Risk Management Framework以 Govern、Map、Measure、Manage 组织 AI 风险活动，说明测量结果需要进入责任、处置和持续治理，而不能停在报告层。

具体门禁指标、阈值、流量比例、审批角色和观察窗口应由项目风险、流量规模和兜底能力确定。引用这些方法不能替代组织自己的发布制度。

19.13 本章小结

评测只有进入发布流程，才能成为质量防线。

CI/CD 集成和发布门禁要解决三件事：

变更触发什么评测。
哪些指标影响发布。
灰度和回滚如何根据评测与线上信号执行。

下一章，我们将视角从发布前扩展到发布后，看看线上质量监控和多角色看板如何让质量可见。

第 19 章：CI/CD 集成、发布门禁与灰度