第 23 章：评测结果如何反哺后训练与数据生产
第 23 章：评测结果如何反哺后训练与数据生产
23.1 不是所有 Bad Case 都应该进入训练集
客服 Agent 团队积累了几千条线上 Bad Case。有人提出：把这些失败样本修正后全部喂给 SFT，模型应该就会变好。
短期看，这个想法很诱人。Bad Case 来自真实业务，问题明确，人工也能写出正确答案。但如果处理不当，它会带来三个风险：
- 把检索、工具、业务规则问题错误地交给模型记忆。
- 让训练数据污染评测集，导致分数虚高。
- 过度拟合高频问题簇，牺牲泛化和安全边界。
评测结果可以成为高质量数据信号，但不能直接等同于训练数据。它需要经过归因、筛选、修正、脱敏、隔离和验证。
本章不把后训练展开成训练教程，而是从评测视角说明：评测结果如何安全地反哺数据生产。
23.2 评测与训练的关系
评测不是训练的下游裁判，也不只是训练后的验收工具。它还可以为数据生产提供结构化信号。
| 评测产物 | 可反哺的数据方向 |
|---|---|
| Bad Case | SFT 候选、偏好数据候选、回归样本 |
| 人工评分与 Rubric | 偏好标注标准、质量控制规则 |
| Agent Trace | 轨迹数据、步骤级监督、异常恢复样本 |
| 归因标签 | 数据筛选、错误分层、训练目标选择 |
| 线上质量信号 | 场景采样权重、数据生产优先级 |
| 回归结果 | 后训练泛化验证和安全验证 |
关键原则是：评测结果先判断“该不该训练”，再决定“训练什么”。
例如，退款政策误答如果根因是知识库没有同步，训练模型记住某条政策并不能解决系统问题。更好的动作是修复知识同步和 RAG，再把样本加入回归集。只有当错误确实来自模型对规则表达、拒答边界、工具使用模式的稳定缺陷时，才考虑进入训练数据生产。
23.2.1 数据去向决策表
评测结果可以进入不同资产，不应默认进入训练。
| 归因结果 | 推荐去向 |
|---|---|
| 知识库缺失 | 知识治理 + RAG Case |
| 召回失败 | RAG 评测集 + 检索优化 |
| 工具参数错误 | Tool Case + Trace Case |
| Agent 规划失败 | 轨迹数据候选 + Agent Regression |
| 正确上下文下仍答错 | SFT 候选 |
| 两个答案都可行但偏好不同 | Preference 候选 |
| 安全拒答边界不稳 | Red Team + 安全偏好数据候选 |
| 用户表达多样 | 评测样本扩充或训练数据候选 |
这张表的作用，是保护模型训练不吸收系统层缺陷。
23.2.2 数据生产也是质量流程
评测反哺训练不应被当成“把样本交给训练团队”。它本身就是质量流程。
一个合格的数据生产流程至少要有四个关口：
| 关口 | 作用 |
|---|---|
| 归因关 | 判断问题是否适合模型学习 |
| 合规关 | 完成脱敏、授权、有效期和访问控制 |
| 质量关 | 检查答案、偏好理由、Trace 标注和专家复核 |
| 隔离关 | 检查是否污染 Evaluation Set、Hidden Set 和 Prompt 示例 |
这些关口可以防止两类风险：把系统问题训练进模型，以及让评测结果因为数据泄漏而失去可信度。数据生产不是训练前的辅助工作，而是评测闭环的一部分。
23.3 Bad Case 到 SFT 的筛选
Bad Case 转 SFT 的前提是：样本反映了模型需要学习的稳定行为，而不是外部系统缺陷。
适合进入 SFT 候选池的样本包括：
- 模型在正确上下文下没有忠实回答。
- 模型没有遵循业务回答格式。
- 模型在证据不足时做了确定性承诺。
- 模型没有学会某类安全拒答或转人工话术。
- 模型需要学习稳定的工具使用前后表达。
不适合直接进入 SFT 的样本包括：
- 知识库缺文档。
- 检索没有召回正确内容。
- 工具返回错误。
- 业务规则仍在频繁变化。
- 样本含有无法脱敏的敏感信息。
- 问题本身需要实时系统状态，而不是模型记忆。
Bad Case 到 SFT 的流程可以分为六步：
| 步骤 | 目标 |
|---|---|
| 归因筛选 | 排除不该由模型学习的问题 |
| 脱敏去重 | 移除隐私和重复样本 |
| 答案修正 | 写出符合业务规则和安全边界的目标答案 |
| 证据补齐 | 标明答案依据和上下文来源 |
| 质量复核 | 人工或专家复核标签和答案 |
| 数据入库 | 标注用途、版本、隔离范围和有效期 |
这里最重要的是第一步。未经归因的 Bad Case 数据越多，训练越可能把系统缺陷固化到模型里。
23.3.1 SFT 候选入库标准
进入 SFT 候选池前，样本至少满足：
| 条件 | 要求 |
|---|---|
| 归因清楚 | 确认问题适合模型学习 |
| 已脱敏 | 不含个人隐私和敏感业务字段 |
| 答案可维护 | 目标答案不依赖短期政策或实时状态 |
| 证据完整 | 有上下文、政策或工具结果支撑 |
| 不污染评测 | 未进入稳定 Evaluation Set 或 Hidden Set |
| 质量复核 | 通过人工或专家审核 |
如果样本依赖实时订单状态，通常不适合让模型记忆答案，而应训练工具使用或流程判断能力。
23.3.2 训练数据准入单
每批训练候选数据都应形成准入单。
| 字段 | 说明 |
|---|---|
| batch_id | 数据批次标识 |
| source | 来源：Bad Case、人工构造、线上抽样、专家样本等 |
| target_capability | 目标能力：忠实回答、拒答边界、工具使用、表达格式等 |
| attribution_basis | 为什么适合训练，而不是进入 RAG、Tool 或回归 |
| privacy_status | 脱敏和授权状态 |
| eval_overlap_result | 与评测集和隐藏集的重合检查 |
| quality_review | 人工或专家复核结果 |
| expiry_policy | 数据有效期和下线条件 |
| validation_plan | 训练后如何验证收益和退化 |
准入单的价值是让训练数据可审计。后续如果模型分数提升但线上无改善，团队可以回查数据批次，判断是否训练目标错误、样本污染或验证集过拟合。
23.4 SFT 样本的答案修正
SFT 样本不能只把错误答案改成正确答案。它要体现期望行为。
客服 Agent 的目标答案通常包含：
- 对用户意图的确认。
- 基于证据的结论。
- 规则引用或依据说明。
- 用户下一步动作。
- 不确定时的限制说明或转人工。
例如，用户问：“我用了优惠券并且只退一件商品，积分会扣回吗？”
一个合格的目标答案不应只是：
会扣回，具体看订单。
更好的目标答案是：
这类问题需要同时看优惠券分摊规则和会员积分规则。一般情况下，部分退款会按商品和优惠规则重新计算退款金额，相关积分也可能按实际保留金额调整。为了避免金额误差，我需要根据你的订单明细查询后确认；如果系统无法确认，应转人工处理。
这个答案表达了证据边界、业务动作和风险控制，而不是让模型记住某个固定政策。
23.5 偏好数据：Chosen / Rejected 不只是好坏答案
很多评测结果适合转成偏好数据，而不是 SFT。
偏好数据的价值，是让模型学习“在多个可行回答中，哪一个更符合业务目标和安全边界”。
一个客服场景的偏好样本可以这样设计：
| 维度 | Chosen | Rejected |
|---|---|---|
| 依据 | 引用政策并说明不确定边界 | 无证据给出确定承诺 |
| 行动 | 指导用户提供订单或转人工 | 让用户自行猜测 |
| 安全 | 不泄露、不越权、不误导 | 直接查询或承诺处理结果 |
| 体验 | 简洁清楚，步骤明确 | 冗长、模糊、重复 |
偏好数据的风险在于标注偏差。
常见偏差包括：
- 偏好更长答案，而不是更正确答案。
- 偏好更礼貌答案，而忽略业务风险。
- 偏好看似自信的回答，而忽略证据不足。
- 标注者之间对“可执行”的理解不一致。
因此，Preference 数据需要独立的质量检查表，而不是只让标注者凭感觉选择。
23.6 Agent Trace 到轨迹数据
Agent 系统不仅可以从最终答案学习，也可以从轨迹中学习。
可用于数据生产的 Trace 类型包括：
| Trace 类型 | 数据价值 |
|---|---|
| 成功轨迹 | 学习任务分解、工具选择和回答组织 |
| 失败轨迹 | 学习错误模式和异常恢复 |
| 关键步骤切片 | 学习某一步的局部决策 |
| 工具调用样本 | 学习参数构造和结果使用 |
| 转人工样本 | 学习风险识别和兜底触发 |
但不应把完整 Trace 不加筛选地用于训练。原因包括：
- Trace 中可能包含隐私和业务敏感信息。
- 失败轨迹可能包含错误步骤。
- 很长的轨迹会引入噪声。
- 某些步骤属于系统策略，不应由模型自由学习。
更稳妥的做法，是将 Trace 切成可监督的关键步骤。
例如：
- 输入：用户问题 + 当前状态。
- 目标：判断是否需要调用退款规则工具。
- 输出：调用决策、工具参数和风险说明。
这种步骤级数据比整段对话更适合训练和评测复用。
23.6.1 Trace 数据的正负样本
Trace 数据可以同时包含正样本和负样本，但用途不同。
| 类型 | 用途 |
|---|---|
| 成功 Trace | 学习合理步骤、工具选择和结果使用 |
| 失败 Trace | 学习错误识别和异常恢复，但不能直接模仿 |
| 修复后 Trace | 学习从同类问题中正确执行 |
| 对照 Trace | 比较错误路径和正确路径 |
失败 Trace 必须标注错误步骤。否则模型可能学习到错误工具调用或无效循环。
客服 Agent 的错误退款 Trace 可以转成训练样本：“在看到部分退款和会员积分时，应调用退款规则工具，而不是直接回答”。这比把整段失败对话喂给模型更安全。
23.7 Reward 与评测指标的边界
评测指标不能简单等同于 Reward 函数。
评测指标用于判断系统质量，Reward 用于引导模型偏好。如果直接把某个评测分数作为 Reward，容易出现目标偏移。
例如：
- 用回答长度作为正向信号，模型可能变得冗长。
- 用用户点赞作为正向信号，模型可能迎合用户而降低安全性。
- 用任务完成率作为唯一信号，模型可能跳过必要确认。
- 用 Judge 总分作为 Reward，模型可能学习迎合 Judge 表达。
更合理的做法是把评测指标拆成约束和偏好。
| 类型 | 示例 |
|---|---|
| 硬约束 | 不泄露隐私、不越权、不编造政策 |
| 业务偏好 | 优先解决问题、减少转人工 |
| 体验偏好 | 简洁、清楚、可执行 |
| 成本偏好 | 不做无必要工具调用 |
训练目标要尊重这些层级，不能用单一分数覆盖所有质量要求。
23.8 数据隔离
评测回流到训练时，最容易出问题的是数据污染。
至少要区分四类数据：
| 数据集 | 用途 | 是否可进入训练 |
|---|---|---|
| Training Set | 模型学习 | 是 |
| Development Set | 调参和策略选择 | 通常不直接训练 |
| Evaluation Set | 稳定评测 | 否 |
| Hidden Set | 独立验收和防过拟合 | 否 |
隔离规则必须写入数据平台，而不是依赖人工记忆。
每条数据应记录：
- 来源 Bad Case。
- 脱敏版本。
- 归因标签。
- 是否进入过评测集。
- 是否进入训练集。
- 可用范围。
- 有效期和 Owner。
如果一个线上 Bad Case 已经进入稳定评测集，它就不应再进入训练集。否则后续分数提升无法说明泛化提升。
23.8.1 数据血缘与污染审计
每条训练候选数据都应记录血缘：
| 字段 | 说明 |
|---|---|
| source_case_id | 来源 Bad Case 或线上样本 |
| attribution_result | 归因结论 |
| transform_type | SFT、Preference、Trace、回归样本 |
| anonymization_version | 脱敏版本 |
| reviewer | 复核人 |
| eval_overlap_check | 是否与评测集重合 |
| training_dataset_version | 所属训练数据版本 |
| expiry_policy | 过期策略 |
污染审计要检查训练数据与 Evaluation Set、Hidden Set、Prompt 示例和公开演示样本的重合。没有审计，训练收益无法被可信评测验证。
23.9 泛化验证
后训练完成后，要验证提升是否真实。
三层验证最基本：
| 验证层 | 目标 |
|---|---|
| 训练相邻集 | 验证目标行为是否学到 |
| 稳定评测集 | 验证核心能力没有退化 |
| 隐藏集与线上灰度 | 验证没有过拟合和安全退化 |
客服 Agent 的后训练候选版本不能只在退款 Bad Case 上提高。它还要检查：
- 物流、订单、发票等非退款场景是否退化。
- 普通政策咨询是否被过度转人工。
- 安全拒答是否出现误拒或误放。
- 成本和延迟是否发生明显变化。
- 线上灰度中的投诉率和转人工率是否稳定。
训练带来的收益必须经得起跨场景验证。
23.9.1 后训练收益报告
后训练版本的评测报告应单独说明：
- 训练数据来源和范围。
- 与评测集是否隔离。
- 目标能力是否提升。
- 非目标场景是否退化。
- 安全指标是否稳定。
- 成本和延迟是否变化。
- 线上灰度是否验证。
如果报告只写“训练后分数提升”，没有说明数据来源和隔离情况，就无法判断这是泛化提升还是数据污染。
23.10 案例：退款失败样本如何进入数据生产
退款政策误答经过归因后，团队对样本做分流。
| 样本类型 | 归因 | 去向 |
|---|---|---|
| 正确政策未召回 | RAG 召回失败 | RAG 回归，不进训练 |
| 工具未调用 | Agent 策略缺失 | Trace 训练候选 + 回归 |
| 正确上下文下仍承诺错误 | 模型忠实性不足 | SFT 候选 |
| 两个回答都可行但一个更稳妥 | 偏好边界问题 | Preference 候选 |
| 含敏感订单和身份信息 | 隐私风险 | 脱敏后再判断，不直接入库 |
最终，只有一部分样本进入训练数据生产。更多样本进入 RAG Case、Trace Case、Regression Set 和线上监控。
这正是评测回流的关键：不同问题进入不同资产。
23.11 交付物一：Bad Case 到训练数据转化流程
图 23-1 Bad Case 到训练数据转化流程图
flowchart TD
A["线上 Bad Case"] --> B["脱敏与去重"]
B --> C["分层归因"]
C --> D{"是否适合模型学习"}
D -->|否| E["进入 RAG / Tool / Agent / 业务回归"]
D -->|是| F["答案修正或偏好构造"]
F --> G["证据补齐与质量复核"]
G --> H["数据隔离检查"]
H --> I["进入 SFT / Preference / Trace 数据池"]
I --> J["训练后泛化验证"]
流程中最关键的判断点是“是否适合模型学习”。没有这个判断，数据生产会吸收大量系统缺陷。
23.12 交付物二：Preference 数据质量检查表
| 检查项 | 通过标准 |
|---|---|
| 业务正确性 | Chosen 符合业务规则，Rejected 的问题明确 |
| 证据边界 | Chosen 不做无证据承诺 |
| 安全合规 | 不包含隐私泄露、越权、违规承诺 |
| 体验质量 | Chosen 更清晰、可执行，而不只是更长 |
| 标注一致性 | 多名标注者对偏好理由一致 |
| 偏差控制 | 长度、语气、格式不会主导选择 |
| 场景标注 | 场景、风险、归因标签完整 |
| 数据隔离 | 不来自稳定评测集或隐藏集 |
Preference 数据的质量上限，取决于偏好理由是否清晰，而不是样本数量。
23.13 交付物三：训练 / 评测数据隔离规则
| 规则 | 要求 |
|---|---|
| 稳定 Evaluation Set 不进训练 | 保持评测可信度 |
| Hidden Set 不暴露给训练和调参 | 用于最终验收 |
| 训练数据记录来源 | 可追踪到 Bad Case、人工标注或合成来源 |
| 线上样本先脱敏 | 隐私字段不得进入训练 |
| 重复样本去重 | 避免高频问题过度影响模型 |
| 数据版本化 | 训练、评测和标注版本可追溯 |
| 污染检测 | 训练前检查与评测集的相似度和重合 |
| 退役机制 | 过期政策和无效规则样本要下线 |
隔离规则是评测可信度的底线。
23.14 评测反哺训练的常见误区
23.14.1 把所有 Bad Case 都转成 SFT
这会让模型学习系统缺陷，也会浪费训练预算。
23.14.2 把评测答案直接喂训练
如果评测答案来自稳定评测集，就会污染评测。即使内容正确，也不应直接进入训练。
23.14.3 只追求单一分数提升
单一分数提升可能来自过拟合、风格迎合或场景偏移。必须看泛化、安全和线上指标。
23.14.4 忽略数据有效期
客服政策、工具和流程会变化。过期数据继续训练，会让模型学到错误行为。
23.14.5 忽略 Trace 中的错误步骤
失败 Trace 不是训练金矿，未经切片和标注会把错误轨迹带入模型。
23.15 本章小结
评测结果可以反哺后训练和数据生产，但前提是经过严格筛选。
核心原则包括：
- 先归因，再决定是否训练。
- 区分 SFT、Preference、Trace、Regression 和 RAG Case 的不同去向。
- 保护训练集、开发集、评测集和隐藏集之间的隔离。
- 用跨场景评测、隐藏集和线上灰度验证后训练收益。
下一章，我们将面对所有 AI 系统都绕不开的话题——安全红队与合规证据链。