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

22.1 发现问题不是闭环，问题被验证修复才是闭环

以下退款修复案例及其数值均为教学用假设，不代表真实生产结果。客服 Agent 的质量团队已经完成归因：会员部分退款场景的错误回答，主根因是检索 Query 没有覆盖积分扣回规则，贡献因素是 Agent 没有强制调用退款规则工具。

归因报告写得很清楚，但两周后，同类问题又出现了。

原因在于诊断没有进入系统优化闭环。没有明确 Owner，没有修复方案，没有回归验证，没有防复发资产。Bad Case 虽然被记录，却没有改变系统。

企业级评测的价值不在报告本身，而在于它能持续驱动系统改进。一次完整闭环应包含：

问题发现。
分层归因。
修复动作。
回归验证。
发布或灰度。
线上监控。
防复发沉淀。

少任何一步，质量体系都会回到救火模式。

22.2 根因到优化动作的映射

不同根因对应不同修复动作。把所有问题都交给模型训练或 Prompt 调整，是低效且危险的。

根因层级	优化动作	验证方式
模型	更换模型、增加推理约束、后训练候选	全量能力评测、隐藏集、线上灰度
Prompt	调整任务指令、边界约束、Few-shot、输出格式	Prompt 回归、Hard Case、人工抽检
RAG	文档治理、Chunk 调整、Query 改写、召回和重排优化	检索指标、RAG 端到端、引用评测
Tool	优化工具描述、Schema、参数校验、错误处理	Tool Case、Trace Case、沙箱验证
Agent 编排	调整规划、状态机、工具策略、异常恢复	轨迹级评测、长程任务回归
系统	修复缓存、路由、权限、超时、并发问题	链路压测、日志验证、稳定性监控
业务规则	更新规则库、同步流程、增加人工确认	业务回归、人工复核、上线监控

第 21 章的七层模型是本书统一的技术归因坐标。产品交互属于跨层修复手段，不增加为第八个技术根因层：当模型、Prompt、RAG、工具、编排、系统或业务规则的风险无法仅靠后台修复消除时，可以增加用户确认、解释和转人工入口，并通过 A/B、转化、满意度与投诉监控验证效果。

映射表的作用，是防止“诊断归诊断，修复靠经验”。

22.2.1 优化优先级

不是所有问题都应立即修复。优化优先级可以由四个因素决定：

因素	判断问题
风险等级	是否涉及隐私、越权、资金、合规
影响范围	影响多少用户、场景和版本
复现稳定性	是否能稳定复现
修复成本	修复是否低风险、可验证、可回滚

P0—P3 的统一定义以术语表第 6 节为准。本章不重复定义等级，只规定修复调度：P0 立即阻断或回滚，P1 快速修复并回归，P2 进入有期限的迭代计划，P3 可批量优化或观察。

这能避免团队被大量低风险 Bad Case 淹没，却忽略少量高损问题。

22.2.2 修复工单

归因结论进入优化闭环时，应转成修复工单。修复工单比普通缺陷单更强调证据、回归和防复发。

修复工单沿用第 19.4.1 节的十个通用治理字段，并通过 source_id 关联第 20 章异常处置任务或第 21 章归因记录。它只在根因已有证据、需要进入修复执行时创建；发布决策仍由第 19 章记录，线上异常初筛仍由第 20 章记录。

字段	说明
source_bad_case_id	来源 Bad Case 或问题簇标识
root_cause	已确认的主根因
contributing_factors	贡献因素和暴露条件
evidence_level	E0—E4 归因证据成熟度
evidence_strength	高、中、低会诊治理标签及其依据
falsification_check	可能推翻当前根因的反证和尚需验证项
fix_actions	分层修复动作、动作 Owner 和预期证据
regression_scope	必跑回归范围
release_path	热修、灰度、常规发布或回滚
verification_evidence	修复通过所需证据
regression_admission	Regression Case 的 R 级复用审核、Rubric 和审批状态
prevention_assets	Regression Case、Gate、Watch Metric 和 Runbook
review_cycle	修复关闭后的复查周期

修复工单让质量闭环可管理。它把“知道问题在哪里”推进到“谁修、怎么修、怎么证明修好了、如何防止复发”。

release_path 只是计划路径，不构成发布授权。任何热修、灰度、继续放量或回滚决定都需要由第 19 章的独立发布决定记录承接，并引用当前 Gate Result 和修复验证证据。

22.3 Prompt 优化与回归

Prompt 优化适用于指令缺失、约束不清、输出格式不稳、拒答策略不明确等问题。

客服 Agent 中常见的 Prompt 优化包括：

明确高风险场景必须引用政策。
要求涉及金额、权益、身份信息时调用工具或转人工。
在证据不足时禁止确定性承诺。
增加少量高价值 Few-shot。
将回答格式拆分为结论、依据、用户下一步动作。

Prompt 优化不能以一个 Bad Case 修好为结束，还要回归三类样本：

样本	目的
原失败样本	验证目标问题是否修复
相邻场景样本	验证不会伤害同类任务
负向安全样本	验证不会导致误放或误拒

例如，新增“金额权益问题必须调用工具”的约束后，要检查普通退款咨询是否被过度工具化，也要检查用户只是询问政策时是否被频繁转人工。

Prompt 修改是高频变更，因此应版本化并接入发布门禁。

22.3.1 Prompt 修复的风险

Prompt 修复速度快，但副作用也快。

常见副作用包括：

过度拒答。
回答变长，延迟和成本上升。
普通问题被过度工具化。
Few-shot 过度贴合某些样本。
安全约束与业务任务冲突。

因此，Prompt 修复通过目标 Bad Case 后，还要回归核心 Golden Set、相邻业务场景和安全样本。

22.4 RAG 优化与回归

RAG 根因通常不能靠改回答 Prompt 解决。常见动作包括：

问题	优化动作
文档未进入知识库	补充知识源和同步机制
解析丢失表格结构	改解析策略，保留标题、表格和层级
Chunk 切分不合理	调整 Chunk 边界和重叠策略
Query 缺少关键实体	增加 Query 改写和实体扩展
召回相关性低	调整 Embedding、混合检索或召回路由
Rerank 排序错误	增加业务特征或重排训练数据
引用不稳定	强制引用片段、校验引用覆盖

客服退款政策的修复可以是：

把“优惠券分摊”“会员积分扣回”“部分退款”建立为同义和业务实体。
对退款 Query 增加权益相关扩展。
在 RAG Case 中增加会员部分退款样本。
对召回 TopK、引用正确性和端到端回答分别评测。

RAG 回归要分两层：检索层和端到端层。

层级	指标
检索层	Recall@K、MRR、正确 Chunk 排名、引用覆盖
端到端层	答案正确性、忠实性、可执行性、拒答合理性

只看端到端容易隐藏检索问题，只看检索又不能保证最终回答正确。

22.4.1 知识治理也是优化动作

很多 RAG 问题实际来自知识治理，不在检索算法本身。

需要治理的内容包括：

治理项	示例
生效时间	新退款政策何时生效
适用范围	是否适用于会员、活动商品、跨境商品
规则冲突	新政策与历史政策如何取舍
文档结构	表格、例外、脚注是否可解析
Owner	业务政策由谁维护
下线机制	过期政策是否从索引中移除

如果知识本身混乱，RAG 优化只会把混乱更快地召回给模型。

22.5 Tool 与 Agent 编排优化

工具和 Agent 编排问题需要更工程化的修复。

22.5.1 工具描述与 Schema

工具描述要让模型知道什么时候调用、输入什么、不能做什么。

退款规则工具可以增加：

适用场景：涉及退款金额、优惠券、积分、会员权益时调用。
必填参数：订单 ID、商品 ID、退款类型、用户会员状态。
禁止行为：缺少订单 ID 时不得编造退款结果。
错误处理：工具失败时必须说明无法确认并转人工。

22.5.2 参数校验

工具调用前后都要校验。

校验点	示例
调用前	订单 ID 是否存在，用户是否通过身份验证
调用中	参数类型是否正确，字段是否完整
调用后	返回结果是否为空，是否包含错误码
回答前	回答是否忠实于工具结果

22.5.3 Agent 编排策略

当问题涉及金额、权益、隐私或不可逆操作时，Agent 应进入更严格的流程：

确认用户身份和订单。
判断是否属于高风险业务。
调用对应规则或业务工具。
基于工具结果回答。
证据不足时转人工或要求补充信息。

这类流程不应完全依赖模型自由规划。关键业务路径应有状态机、策略约束和兜底机制。

22.5.4 Agent 修复的发布方式

Agent 编排修复通常比 Prompt 修复风险更高，因为它会改变工具调用和业务状态。

发布时应采用更谨慎策略：

先在沙箱中验证 Trace。
再运行端到端 Regression Set。
再进行小流量灰度。
对提交类工具启用人工确认或只读模式。
监控工具失败、重复调用、成本和延迟。

如果修复涉及退款提交、投诉工单创建或账户修改，离线文本评测不足以支持全量发布。

22.6 产品流程优化

有些问题还需要产品交互配合，无法只靠模型和后台系统修复。

例如，用户问“我现在退掉其中一件商品，优惠券怎么算？”如果业务政策复杂，Agent 即使回答正确，也可能让用户难以理解。产品可以增加：

退款前权益影响预览。
关键金额变化的结构化展示。
“我理解并继续”的确认步骤。
高风险场景转人工入口。
错误解释和申诉入口。

产品优化的目标，是降低 AI 独自承担复杂决策的压力，让系统把风险分配到更合适的位置。

22.7 修复验证流程

修复动作完成后，需要验证三件事：

验证问题	说明
目标问题是否修复	原 Bad Case 和同簇样本是否通过
是否引入退化	相邻场景和核心回归是否稳定
是否能防复发	样本、门禁、监控是否已沉淀

客服 Agent 的修复验证可以这样执行：

重跑原失败样本。
重跑会员退款同簇样本。
重跑退款全量 Regression Set。
重跑工具调用 Trace Case。
检查线上灰度指标。
将修复后的 Case 加入 Regression Set。

只有前两步通过，不代表可以发布。因为修复一个点可能破坏其他流程。

22.7.1 回归半径

每个修复动作都应定义回归半径。

修复对象	回归半径
Prompt	目标场景、相邻场景、安全样本、格式样本
RAG	目标文档、同主题文档、检索指标、端到端回答
Tool Schema	使用该工具的所有 Case、参数边界、权限流程
Agent 编排	同路径 Trace、异常恢复、长程任务、成本延迟
安全策略	Red Team、误拒样本、合法任务完成率

回归半径越清晰，修复越不容易带来隐性退化。

22.7.2 关闭定义

Bad Case 不能因为“已经改了”就关闭。关闭应满足明确条件。

条件	说明
根因达到行动证据要求	证据强度和反证检查足以支持所选修复；未知项已记录
修复已实施	对应系统、数据、Prompt、工具或流程已变更
原样本达到预期	来源 Bad Case 已按同一 Rubric 复跑并达到门禁要求
同簇样本达到标准	同类问题满足预设通过条件，剩余失败有归因和处置
相邻场景无不可接受退化	相邻场景达到预设非劣化或风险门禁条件
防复发资产已沉淀	Regression、Gate、Watch Metric 或 Runbook 已更新
Owner 已确认	责任人确认关闭条件满足

关闭定义能避免两个问题：一个是修复动作停留在口头，另一个是原样本通过后马上关闭，导致相邻场景退化没有被发现。对于 P0 / P1 问题，关闭前还应检查线上灰度或监控信号。

22.8 防复发机制

防复发不是一句“后续注意”。它应落实为资产。

Regression Case、Gate Rule、Watch Metric 和 Runbook 在前文分别出现过。本节沿用这些定义，规定一个高价值 Bad Case 关闭前至少应更新哪一种防复发资产，并明确长期 Owner。

防复发资产	作用
Regression Case	同类问题后续自动回归
Gate Rule	高风险指标不通过时阻断发布
Watch Metric	线上监控同类信号
Runbook	记录复现、诊断、修复和验证方式
Owner	明确长期维护责任

对于退款误答，防复发可以包括：

新增“会员部分退款”回归样本。
在知识库更新后自动触发退款 RAG Case。
对金额权益场景设置工具调用门禁。
在线上看板增加会员退款转人工率和负反馈监控。
将政策同步责任绑定到业务规则 Owner。

质量闭环要让每个高价值 Bad Case 都转化为系统长期能力。《案例设定：企业客服 Agent》中定义的四个核心 Bad Case——退款政策误答、知识未召回、工具参数错误、越权查询——修复后都要进入适当的长期资产：普通已知缺陷进入 Regression Set，安全攻击路径进入 Red Team Set，必要时同时更新 Gate、Watch Metric 或 Runbook。只验证当前样本通过，还不满足关闭条件。

22.8.1 Runbook

高价值问题应形成 Runbook。Runbook 用于让同类问题后续可以快速诊断和处理。

Runbook 至少包括：

字段	说明
触发信号	哪些指标或 Bad Case 触发
快速排查	先看哪些日志、Trace 和版本
常见根因	过去出现过哪些根因
修复路径	Prompt、RAG、Tool、Agent 或业务规则
回归要求	必跑数据集和门禁
回滚条件	何时停止灰度或回滚
Owner	长期维护负责人

这类 Runbook 有助于缩短同类问题的复现、分派和验证路径；实际效果仍需通过响应时长和复发率等线上记录检验。

22.9 案例：退款误答的优化闭环

归因结论：

主根因：检索 Query 没有覆盖会员积分扣回规则。
贡献因素：Agent 没有在金额权益问题上调用退款规则工具。

修复动作：

动作	Owner	验证
增加 Query 实体扩展	RAG 工程	Recall@5 提升
调整退款政策 Chunk	知识库工程	正确 Chunk 排名前移
增加工具调用策略	Agent 工程	Trace Case 通过
补充 Prompt 风险约束	Prompt Owner	Hard Case 回归
增加会员退款 Regression Case	质量负责人	CI 回归通过
增加线上监控切片	数据平台	灰度指标稳定

验证结果：

原失败 Case 通过。
同簇 27 条线上样本中 25 条通过，2 条进入人工复核。
退款 Regression Set 无退化。
小流量灰度 48 小时内转人工率回到基线范围。

这才是一个可接受的优化闭环。

22.10 交付物一：根因到优化动作映射表

根因	具体信号	优化动作	必要回归
模型	同样上下文下仍不稳定或不忠实	更换模型、增加推理约束或进入后训练候选	全量能力、隐藏集和高风险回归
Prompt	正确证据存在但回答越界	增加边界约束、示例和拒答策略	Prompt Regression、Hard Case 和安全样本
RAG	正确 Chunk 未进入 TopK 或上下文	Query 改写、索引、召回、重排或知识治理	检索集、引用和端到端 RAG
Tool	Tool Call 选择、参数或结果处理错误	Schema、参数校验、错误处理和权限约束	Tool Case、Trace Case 和沙箱验证
Agent 编排	规划、状态、循环或异常恢复失败	状态机、工具策略、恢复和兜底机制	轨迹级、长程任务和相邻路径回归
系统	缓存、路由、权限、超时或并发异常	修复基础设施和配置	链路压测、日志验证和稳定性监控
业务规则	人工规则与 AI 规则不一致或过期	规则同步、冲突处理和长期 Owner	业务回归、人工复核和线上监控

这张表与第 21 章七层根因模型使用同一组坐标。线上分布变化属于暴露条件或评测覆盖缺口，应触发样本回流和数据扩充，但不作为第八个技术根因层。

22.11 交付物二：修复验证与防复发流程

图 22-1 修复闭环流程图

flowchart TD
  A["Bad Case 发现"] --> B["分层归因"]
  B --> C["确定 Owner 和修复动作"]
  C --> D["实施 Prompt / RAG / Tool / Agent / 产品修复"]
  D --> E["原失败样本验证"]
  E --> F["同簇和相邻场景回归"]
  F --> G{"Gate Result满足放行条件?"}
  G -->|否| C
  G -->|是| R["记录发布决定"]
  R --> H["限定范围灰度"]
  H --> J{"线上信号满足继续条件?"}
  J -->|否| K["暂停灰度或回滚"]
  K --> C
  J -->|是| I["沉淀 Regression Case / Gate / Watch Metric / Runbook"]
  I --> L["按关闭定义更新修复记录"]

流程中的每一步都需要可审计记录。否则闭环无法复盘，也无法证明问题已经解决。

22.12 交付物三：Bad Case 回归沉淀模板

本节只定义 Bad Case 转为长期 Regression 资产时新增的准入和触发信息，不是第二份 Eval Case Schema。完整 Case 仍须满足第 12 章通用契约和项目工作表 02，并通过第 20 章 R0—R4 复用审核。

case_id: reg_refund_member_partial_001
case_version: v1
dataset_id: refund_regression_set
dataset_version: v8
source_bad_case_id: bc_refund_policy_20260708_001
reuse_readiness: R4
metadata:
  dataset_role: regression
  review_status: approved
  owner: ai_quality_refund
  review_cycle: monthly
scenario: 会员部分退款
risk_level: P1
trigger_condition:
  - 知识库退款政策更新
  - Prompt 涉及退款策略修改
  - Agent 工具调用策略修改
expected_behavior:
  - 识别为金额权益相关问题
  - 调用退款规则工具
  - 引用最新会员积分扣回规则
  - 不做无依据承诺
gate_reference:
  gate_id: refund_policy_high_risk_gate
  gate_version: v3
  required_outcome: passed

回归沉淀模板的价值，是把单点事故转化为长期防线。

22.13 优化闭环常见误区

22.13.1 修复只验证原样本

原样本通过可能只是补丁式修复，还要验证同簇样本和相邻场景。

22.13.2 只做 Prompt Patch

Prompt Patch 快，但不一定是根因修复。RAG、工具、状态和业务规则问题需要对应工程动作。

22.13.3 没有 Owner

没有 Owner 的问题不会自然消失。每个高价值 Bad Case 都要有明确负责人和截止时间。

22.13.4 不沉淀回归

如果问题没有进入 Regression Set、门禁或监控，它很可能在后续变更中再次出现。

22.13.5 忽略产品兜底

AI 系统不是所有风险的唯一承担者。复杂业务场景要通过产品流程、确认机制和人工兜底共同降低风险。

22.14 本章小结

评测结果进入系统优化闭环后，才会产生持续价值。

有效闭环需要：

将根因映射到正确的优化动作。
对 Prompt、RAG、Tool、Agent、系统、业务规则和产品流程分别设计修复方式。
用原失败样本、同簇样本、相邻场景和线上灰度验证修复效果。
将高价值问题沉淀为 Regression Case、Gate Rule、Watch Metric 和 Runbook。

下一章，我们将闭环延伸到模型和数据层面，看看评测数据如何反哺后训练和对齐。

第 22 章：从评测结果到系统优化闭环