数据飞轮不是"多收集点用户数据"这么简单。真正有价值的是把线上失败样本、用户反馈和专家修正，变成下一轮可训练、可评估、可复用的数据资产。

一、什么是数据飞轮#

数据飞轮可以先记成一条闭环：

1
模型上线
2
-> 收集交互数据
3
-> 挖掘 badcase
4
-> 清洗、去重、脱敏
5
-> 人工或模型辅助标注
6
-> 加入训练集和评估集
7
-> 训练新模型
8
-> 灰度上线和 A/B
9
-> 继续收集反馈

这条闭环的目标是：

让真实用户场景不断反哺模型，让模型越用越贴近业务。

注意，飞轮的核心不是数据量，而是数据质量和闭环效率。

一百万条未经处理的日志，不一定比一千条高质量 badcase 有用。

二、为什么需要数据飞轮#

训练前的数据永远无法覆盖所有线上情况。

上线之后，用户会问出很多你没想到的问题：

口语化表达。
拼写错误。
多轮追问。
业务边界问题。
新产品、新政策、新文档。
对抗性提问。
工具调用异常。
长尾需求。

如果没有数据飞轮，模型上线就是一次性工程。

如果有数据飞轮，模型每一次失败都可能变成下一次迭代的燃料。

三、数据来源有哪些#

1. 用户反馈#

包括：

点赞 / 点踩。
用户主动纠错。
重新生成。
追问。
投诉。
人工客服接管。

这些信号很有价值，但要小心解释。

点踩不一定代表事实错误，可能是回答太长、太慢、没按格式、没有解决真实需求。

2. 线上日志#

包括：

用户 prompt。
模型回答。
检索结果。
工具调用参数。
工具返回。
延迟和成本。
会话上下文。

日志要做权限控制和脱敏，不能直接拿来训练。

3. 人工审核#

专家可以对回答做：

正误判断。
风险标注。
更优答案改写。
偏好比较。
失败原因分类。

人工审核成本高，所以通常会优先审核高价值样本。

4. 自动评测#

用规则、测试、模型评审或 verifier 自动发现问题。

比如：

JSON 解析失败。
代码测试失败。
引用文档不存在。
回答包含敏感信息。
工具参数不符合 schema。

5. Agent 轨迹#

Agent 每一步都能产生数据：

调用了哪个工具。
参数是什么。
工具返回了什么。
是否重试。
最后是否成功。

这些轨迹比单条问答更复杂，但也更有价值。

四、Badcase 怎么挖#

Badcase 不是简单把点踩样本全部拿出来。

更好的做法是先分类：

类型	例子	可能优化方向
事实错误	编造政策、数字、引用	RAG、评估集、事实校验
指令不服从	要 JSON 却输出解释	SFT、格式约束
领域不懂	法律条款解释错	中训练、领域 SFT
安全问题	泄露隐私、危险指导	安全数据、拒答策略
检索失败	没找到正确文档	chunk、embedding、rerank
工具调用失败	参数错、工具选错	tool-use SFT、Agentic RL
过度拒答	正常问题也拒绝	安全策略校准
风格问题	太啰嗦、太生硬	偏好优化

先分类，才知道应该改数据、改检索、改 prompt、改工具，还是改模型。

五、清洗、去重和脱敏#

进入训练前，数据至少要过三关。

1. 清洗#

去掉：

空样本。
乱码。
无意义重复。
系统错误日志。
无法判断质量的样本。
格式损坏的对话。

2. 去重#

去重可以避免：

模型过拟合高频重复样本。
评估集污染。
数据统计失真。

重复不只是完全相同，也包括模板重复、近似重复。

3. 脱敏#

处理：

姓名、手机号、邮箱、身份证。
地址、订单号、账号。
API key、token、密码。
公司内部机密。
医疗、金融、法律敏感信息。

企业场景里，脱敏不是可选项，而是上线前提。

六、标注怎么做#

不同训练方法需要不同标注。

1. SFT 数据#

需要高质量目标回答。

适合修复：

指令跟随。
输出格式。
固定任务流程。
领域问答风格。

2. DPO 数据#

需要偏好对：

1
prompt
2
chosen
3
rejected

适合优化：

回答质量。
风格偏好。
安全边界。
多个答案之间的相对选择。

3. RL / GRPO 数据#

需要 reward 或 verifier。

适合：

数学。
代码。
工具调用。
可自动验证的任务。

4. 评估数据#

有些 badcase 不应该进入训练集，而应该进入评估集。

尤其是高风险、代表性强、历史反复出现的问题，要放进回归评估集，防止下个版本又犯。

七、数据飞轮和评估集的关系#

数据飞轮不是把所有 badcase 都塞进训练集。

更好的拆法是：

1
一部分进入训练集：让模型学会修复
2
一部分进入评估集：验证以后是否还会错
3
一部分进入安全集：专门做安全回归
4
一部分进入分析池：暂时不训练，只做问题归因

如果所有 badcase 都进入训练，评估就会被污染，后面无法判断模型是否真正泛化。

八、一个具体例子：RAG 问答飞轮#

场景：企业知识库问答。

线上 badcase：

1
用户问：报销差旅费需要哪些材料？
2
模型答：需要发票和审批单。
3
用户点踩：缺少行程单和住宿水单。

分析：

检索结果里有没有正确制度文档？
如果没有，是 chunk 问题还是 embedding 问题？
如果检索到了，模型为什么没用？
是否需要把这个问题加入回归评估？
是否需要补一条 SFT 数据，教模型按制度完整列材料？

可能处理：

把正确制度文档重新切 chunk。
加入一条标准问答到 SFT 数据。
把这个问题加入 RAG 评估集。
标记为"材料遗漏类 badcase"。

下一版上线后，再看同类问题 badcase rate 是否下降。

九、飞轮里常见坑#

1. 只收集，不闭环#

日志堆了很多，但没有分类、标注、训练和评估，等于没有飞轮。

2. 只训练，不评估#

把 badcase 塞进训练集后，没留回归集，无法判断是否真的修复。

3. 只看用户反馈，不看真实原因#

点踩只是信号，不是诊断。要继续追原因。

4. 忽视数据权限#

用户日志、企业文档、代码仓库都可能有敏感信息，不能直接进入训练。

5. 用模型标注但不抽检#

模型辅助标注能提效，但必须有人类抽检和一致性检查。

十、数据样本应该怎么落库#

数据飞轮要能长期运转，样本不能只是一段聊天记录，最好有结构化元信息。

一条问答 badcase 可以记录成：

1
{
2
  "sample_id": "case_20260527_001",
3
  "source": "online_feedback",
4
  "task_type": "rag_qa",
5
  "user_query": "报销差旅费需要哪些材料？",
6
  "model_answer": "需要发票和审批单。",
7
  "reference_answer": "需要发票、审批单、行程单和住宿水单。",
8
  "feedback": "downvote",
9
  "error_type": ["incomplete_answer", "missing_evidence"],
10
  "root_cause": "retrieved_context_incomplete",
11
  "pii_status": "desensitized",
12
  "split": "eval_regression",
13
  "created_at": "2026-05-27"
14
}

这样后续才能统计：

哪类错误最多。
哪类错误最影响用户。
哪类错误已经被修复。
哪些样本进了训练集。
哪些样本留在评估集。

没有元信息，日志很快会变成一堆难以复用的文本。

十一、样本优先级#

不是所有 badcase 都值得立刻标注和训练。可以按价值排序：

优先级	样本类型
高	高频问题、高风险场景、付费用户问题、可稳定复现问题
中	体验问题、格式问题、局部领域知识缺口
低	偶发噪声、用户输入极不完整、无法判断对错的样本

对于 Agent 任务，还要额外关注：

失败是否可复现。
是否有明确环境状态。
工具调用日志是否完整。
reward/verifier 是否能自动判断。

能自动验证的样本更容易规模化进入 GRPO/RLVR；需要专家判断的样本更适合做高质量 SFT 或 DPO 数据。

十二、模型辅助标注的使用方式#

模型可以帮助做：

错误类型初分。
PII 检测。
低质量样本过滤。
候选 reference answer 生成。
chosen/rejected 初筛。
相似样本聚类。

但模型辅助标注不能直接等于真标签。比较稳的流程是：

1
模型预标注
2
-> 人工抽检
3
-> 计算一致率
4
-> 低一致类别回炉
5
-> 高一致类别半自动放量

这样可以把人力集中在最难、最危险、最有价值的样本上。

十三、本篇小结#

数据飞轮的真正价值在于把线上不确定性变成可管理的数据资产。

它不是：

1
收集日志 -> 全塞进训练集

而是：

1
采集 -> 归因 -> 清洗 -> 脱敏 -> 标注 -> 分流
2
-> 一部分训练
3
-> 一部分评估
4
-> 一部分安全回归
5
-> 一部分继续观察

模型越复杂，飞轮越重要。尤其是 RAG 和 Agent 系统，失败往往不只来自模型本身，而来自检索、工具、环境、权限、提示词和数据质量的组合问题。