第 22 章：从评测结果到系统优化闭环
第 22 章：从评测结果到系统优化闭环
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 编排 | 调整规划、状态机、工具策略、异常恢复 | 轨迹级评测、长程任务回归 |
| 系统 | 修复缓存、路由、权限、超时、并发问题 | 链路压测、日志验证、稳定性监控 |
| 业务规则 | 更新规则库、同步流程、增加人工确认 | 业务回归、人工复核、上线监控 |
| 产品交互 | 增加用户确认、解释、转人工入口 | A/B、转化、满意度和投诉监控 |
映射表的作用，是防止“诊断归诊断，修复靠经验”。
22.2.1 优化优先级
不是所有问题都应立即修复。优化优先级可以由四个因素决定：
| 因素 | 判断问题 |
|---|---|
| 风险等级 | 是否涉及隐私、越权、资金、合规 |
| 影响范围 | 影响多少用户、场景和版本 |
| 复现稳定性 | 是否能稳定复现 |
| 修复成本 | 修复是否低风险、可验证、可回滚 |
优先级可以这样划分：
| 优先级 | 示例 | 动作 |
|---|---|---|
| P0 | 越权工具调用、隐私泄露 | 立即阻断或回滚 |
| P1 | 高风险退款误答、错误承诺 | 快速修复并回归 |
| P2 | 高频体验退化 | 进入迭代计划 |
| P3 | 低风险表达问题 | 批量优化或观察 |
这能避免团队被大量低风险 Bad Case 淹没，却忽略少量高损问题。
22.2.2 修复工单
归因结论进入优化闭环时，应转成修复工单。修复工单比普通缺陷单更强调证据、回归和防复发。
| 字段 | 说明 |
|---|---|
| issue_id | 修复任务标识 |
| source_bad_case | 来源 Bad Case 或问题簇 |
| root_cause | 主根因、贡献因素和置信度 |
| affected_scope | 影响场景、版本、渠道和风险等级 |
| fix_owner | 修复负责人 |
| fix_type | Prompt、RAG、Tool、Agent、系统、业务规则或产品流程 |
| regression_scope | 必跑回归范围 |
| release_path | 热修、灰度、常规发布或回滚 |
| verification_evidence | 修复通过所需证据 |
| prevention_asset | Regression Case、Gate、Watch Metric 或 Runbook |
修复工单让质量闭环可管理。它把“知道问题在哪里”推进到“谁修、怎么修、怎么证明修好了、如何防止复发”。
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 已复跑通过 |
| 同簇样本通过 | 同类问题不再集中失败 |
| 相邻场景无退化 | 修复没有破坏相关能力 |
| 防复发资产已沉淀 | Regression、Gate、Watch Metric 或 Runbook 已更新 |
| Owner 已确认 | 责任人确认关闭条件满足 |
关闭定义能避免两个问题：一个是修复动作停留在口头，另一个是原样本通过后马上关闭，导致相邻场景退化没有被发现。对于 P0 / P1 问题，关闭前还应检查线上灰度或监控信号。
22.8 防复发机制
防复发不是一句“后续注意”。它应落实为资产。
| 防复发资产 | 作用 |
|---|---|
| Regression Case | 同类问题后续自动回归 |
| Gate Rule | 高风险指标不通过时阻断发布 |
| Watch Metric | 线上监控同类信号 |
| Runbook | 记录复现、诊断、修复和验证方式 |
| Owner | 明确长期维护责任 |
对于退款误答，防复发可以包括：
- 新增“会员部分退款”回归样本。
- 在知识库更新后自动触发退款 RAG Case。
- 对金额权益场景设置工具调用门禁。
- 在线上看板增加会员退款转人工率和负反馈监控。
- 将政策同步责任绑定到业务规则 Owner。
质量闭环要让每个高价值 Bad Case 都转化为系统长期能力。前述四个核心 Bad Case——退款政策误答、知识未召回、工具参数错误、越权查询——修复后都必须进入 Regression Set 持续防复发，不能只在本次修复中验证通过就关闭。
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 约束缺失 | 正确证据存在但回答越界 | 增加边界约束和拒答策略 | Hard Case、安全样本 |
| RAG 召回失败 | 正确 Chunk 未进入 TopK | Query 改写、索引和召回优化 | 检索集、端到端 RAG |
| 工具参数错误 | Tool Call 参数不完整 | Schema、参数校验、示例补充 | Tool Case、Trace Case |
| 状态丢失 | 多轮信息缺失 | 状态管理和记忆策略修复 | 多轮 Case |
| 业务规则过期 | 人工规则与 AI 规则不一致 | 规则同步机制和 Owner | 业务回归 |
| 线上分布变化 | 新场景未覆盖 | 线上样本回流和评测集扩充 | 新场景 Regression |
这张表应成为质量评审会的标准工作台。
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["发布门禁检查"]
G --> H["灰度线上监控"]
H --> I["沉淀 Regression Case / Gate / Runbook"]
流程中的每一步都需要可审计记录。否则闭环无法复盘，也无法证明问题已经解决。
22.12 交付物三：Bad Case 回归沉淀模板
regression_case_id: reg_refund_member_partial_001
source_bad_case: bc_refund_policy_20260708_001
scenario: 会员部分退款
risk_level: P1
trigger_condition:
- 知识库退款政策更新
- Prompt 涉及退款策略修改
- Agent 工具调用策略修改
expected_behavior:
- 识别为金额权益相关问题
- 调用退款规则工具
- 引用最新会员积分扣回规则
- 不做无依据承诺
gate:
metric: refund_policy_correctness
threshold: pass
owner: ai_quality_refund
review_cycle: monthly
回归沉淀模板的价值，是把单点事故转化为长期防线。
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。
下一章，我们将闭环延伸到模型和数据层面，看看评测数据如何反哺后训练和对齐。