AI 应用的数据飞轮：从日志到评测，让你的产品越用越聪明

关键词：数据飞轮、LLM 评测、人工标注、Badcase 闭环、持续优化

1. 为什么 90% 的 AI 应用上线后就停滞了

观察过几十个团队的 AI 应用上线后状态，几乎都遵循同一条曲线：

效果 ▲
     │      ╭───────────  ← 第一周冲到 75 分，团队庆祝
  75 │    ╱
     │  ╱
     │╱
     │              ────────────  ← 然后……卡在这里再也没动
     └──────────────────────────────→ 时间
        发布

为什么？因为团队把 90% 的精力花在了"把 demo 调到能上线"，但没有任何机制让产品在用户使用中变得更好。每次想优化只能凭感觉改 Prompt，今天加一句明天删一句，反复横跳。

真正能持续打磨产品的团队，做的是同一件事——搭建数据飞轮：

让用户的每一次交互，都自动转化为下一个版本的训练资产。

本文讲清楚这个飞轮怎么搭。

---

2. 数据飞轮的全貌

        ┌──────────────────┐
        │   线上用户调用    │
        └────────┬─────────┘
                 │ 全链路日志
                 ▼
        ┌──────────────────┐
        │  Trace & 反馈采集 │   ← 用户点踩、人工抽审
        └────────┬─────────┘
                 │
                 ▼
        ┌──────────────────┐
        │   Badcase 挖掘    │   ← 自动 + 人工
        └────────┬─────────┘
                 │
                 ▼
        ┌──────────────────┐
        │ 标注 & 评测集累积 │
        └────────┬─────────┘
                 │
        ┌────────┴─────────┐
        ▼                  ▼
  ┌──────────┐       ┌──────────┐
  │ Prompt   │       │  SFT /   │
  │ / RAG    │       │  DPO     │
  │ 优化     │       │  微调    │
  └────┬─────┘       └────┬─────┘
       └────────┬─────────┘
                ▼
        ┌──────────────────┐
        │   离线回归评测    │   ← 通过才能发布
        └────────┬─────────┘
                 │
                 ▼
        ┌──────────────────┐
        │  灰度发布上线     │ ──┐
        └──────────────────┘   │
                ▲              │
                └──────────────┘
                      回到顶部，循环

每一环都不复杂，但少一环飞轮就转不起来。下面逐环展开。

---

3. 第一环：日志采集，"记什么"比"怎么记"更重要

普通后端服务记日志比较随意，AI 应用的日志却是未来的训练数据——少记一个字段，可能半年后追悔莫及。

3.1 必记字段清单

字段	说明	用途
trace_id	全链路唯一 ID	串联所有子调用
user_id / session_id	用户与会话	多轮上下文还原
model + version	模型与 Prompt 版本	A/B 对比、回归归因
input	用户原始输入	训练 / 评测样本来源
retrieved_docs	RAG 召回的文档 ID + 相关性分数	检索效果分析
tool_calls	Agent 工具调用序列	Agent 行为分析
output	模型最终输出	评测核心
latency 各阶段	TTFT、prefill、decode 各自耗时	性能优化
tokens 输入/输出	成本核算与异常检测	成本与 DoS 监控
user_feedback	点赞/点踩/重试	弱监督信号

3.2 三个原则

1. 结构化优先：JSON 字段，不要塞一坨 string。Langfuse、LangSmith、Helicone 都是现成方案。
2. PII 脱敏要在落库前完成：身份证、手机号、邮箱必须脱敏后再写入分析平台。
3. 保留原始 prompt：千万别只记"用户问题"，要记最终送给模型的完整 prompt——只有它和模型行为一一对应。

---

4. 第二环：反馈采集，把弱信号变成强信号

线上反馈通常分三层：

4.1 隐式反馈（最便宜，噪声大）

• 重试：用户重新发了相似问题 → 上次答案大概率不行。
• 点击/不点击：答案中的引用是否被点开。
• 会话长度：突然结束 vs. 持续追问。
• 复制行为：复制了答案 → 八成有用。

不要小看这些信号，量大之后是免费的"伪标注"。

4.2 显式反馈（贵一点，质量高）

• 点赞 / 点踩按钮：放在每条回答下。
• 点踩时弹出原因多选：“不准确 / 太啰嗦 / 不相关 / 不安全”。
• 关键设计：让点踩成本低于关闭页面的成本，否则没人会点。

4.3 人工抽审（最贵，最准）

• 每天随机抽 1%~3% 的会话送人工。
• 标注三个维度：正确性、有用性、安全性，各 1~5 分。
• 抽审样本要分层抽样：高频意图 + 低频长尾 + 用户点踩样本。

抽审看似贵，但它产出的标注数据是后续微调和评测的"地基"。

---

5. 第三环：Badcase 挖掘，主动找问题

光等用户点踩不够，因为：

• 大多数用户遇到差答案就走人，不会反馈。
• 隐性错误（比如自信地胡说）用户根本看不出来。

主动挖掘的常见手段：

5.1 LLM-as-a-Judge 全量打分

用更强的模型（如 GPT-4 / Claude 3.5）对线上日志抽样打分：

请基于以下维度评估答案质量（1-5 分）：
1. Faithfulness：答案是否有参考资料支撑
2. Relevance：是否回答了用户问题
3. Safety：是否有不当内容

【用户问题】{query}
【参考资料】{context}
【答案】{answer}

请输出 JSON：{"faithfulness": x, "relevance": y, "safety": z, "reason": "..."}

注意事项：

• Judge 模型也会有偏好，不要用同一个模型既生成又评判。
• 校准：人工标注 200 条作为 ground truth，对齐 Judge 与人类的相关性，相关性 < 0.7 就别用。
• 成本：可以分层——便宜模型先粗筛"疑似差答"，再用大模型精审。

5.2 异常模式聚类

把所有"低分答案"的用户问题做 embedding 聚类，往往能发现：

• 某个意图集中翻车（比如"退款流程"答错率 80%）。
• 某类输入触发越狱（参考第 5 篇 Prompt 注入）。
• 某些长尾领域知识缺失。

每个聚类就是一个"待修复 Issue"，有了它，优化从"凭感觉"变成"按工单办"。

5.3 自动一致性检测

同一个问题问 3 次，温度 0.7，看答案是否一致。不一致 = 模型不确定 = 高风险。这种样本必送人工。

---

6. 第四环：评测集，团队的"质量底盘"

没有评测集的 AI 项目，等于没有 CI 的代码项目。 每次改 Prompt / 换模型，都是在赌。

6.1 评测集的三层结构

层	来源	数量	用途
L1 黄金集	人工精标	100~300 条	发布门槛，必须通过
L2 回归集	历史 badcase 累积	1k~5k 条	防止旧 bug 复发
L3 影子集	线上日志采样	1w+ 条	整体分布评估

每次模型/Prompt 上线前必须跑 L1 + L2，分数不退化才能发布。

6.2 评测集要"会长大"

• 每个线上 badcase，定位修复后必须进 L2。这是飞轮最关键的一步。
• 每季度做一次 L1 复盘，淘汰过时样本，加入新业务样本。
• L3 持续滚动，永远反映"最近 30 天的真实流量"。

6.3 别只看一个分数

总分 80 → 总分 82，不一定是进步。要拆维度看：

              总分    准确性  相关性  安全性  风格
v1.2 baseline  80     85      78      95      72
v1.3 (new)     82     90      72      95      80
                       ↑       ↓             
                      准确性涨了，但相关性掉了——
                      可能改 Prompt 时把"严格按文档"
                      调过头了，需要平衡

分维度看才能定位问题、避免"按下葫芦浮起瓢"。

---

7. 第五环：从评测到优化，三种武器

拿到 badcase 之后，按代价从低到高优化：

7.1 Prompt 优化（首选）

• 80% 的 badcase 其实是 Prompt 没写清楚，不是模型不够强。
• 用"对比法"：拿 5 个 bad + 5 个 good 样本一起喂给 GPT-4，让它总结好答案有什么共同特征，反向写进 Prompt。
• 每次 Prompt 修改进 Git 版本控制，commit message 写清楚"修了什么 case"。

7.2 RAG / 工具层优化

• 检索召回不到 → 加同义词、改切分、加 reranker。
• 工具调用错 → 改 schema description（参考第 2 篇）。
• 这一层的优化往往比改模型更有效。

7.3 微调（最后手段）

只有当 Prompt + RAG 已经吃干榨尽，仍有系统性偏差时，才考虑微调：

• SFT：风格、格式、领域术语适配。需要 1k~10k 高质量样本。
• DPO / RLHF：偏好对齐（“答案A好于答案B”）。需要 5k+ 偏好对。
• 持续预训练：注入大量领域知识。需要 GB 级语料，团队具备相应算力。

数据来源：飞轮里累积的人工抽审 + Badcase 修复后的"正确答案"，本身就是天然的训练数据。

---

8. 第六环：灰度发布，让数据替你做决策

不要"周一上线，周二回滚"。规范的发布流程：

新版本 → 5% 流量灰度 → 24h 数据对比 →
  ├─ 关键指标无回退 → 扩到 25% → 50% → 100%
  └─ 任一关键指标回退 > 阈值 → 自动回滚 + 报警

关键指标包括：

• 业务：点踩率、平均会话长度、转化率
• 质量：Judge 打分、人工抽审分
• 性能：P50/P95 延迟、超时率
• 成本：人均 token、单次成本

工具层面：用 feature flag（LaunchDarkly / 自研）按 user_id hash 分流，确保同一用户在实验期内体验一致。

---

9. 一个真实案例：从 70 分到 88 分的 6 个月

我们一个内部知识问答系统的真实迭代曲线：

阶段	主要动作	月末分数
M1	初版上线，靠 Prompt 调教	70
M2	接入 Langfuse + 点踩按钮 + LLM-Judge	70 → 73
M3	Badcase 聚类发现 “数字/单位” 类错误高发，优化 Prompt + 加单位转换工具	73 → 79
M4	累积 800 条 L2 回归集，建立 CI 评测	79 → 81（堵住回退，不再倒退）
M5	RAG 切分策略改造 + Reranker 上线	81 → 85
M6	用前 5 个月累积的 3000 条标注做 SFT	85 → 88

关键观察：

• 头两个月最大产出不是分数，而是搭好了飞轮——之后每一步优化都有迹可循。
• 微调放在最后，前面 4 个月的优化只靠 Prompt + RAG，因为它们 ROI 最高。
• 没有 L2 回归集时，每次新优化都会带进新 bug；建好之后才进入"单调上升"区间。

---

10. 团队角色与协作

数据飞轮不是某个工程师能搞定的事，需要至少三类角色协同：

• AI 工程师：负责飞轮的"管道"——日志、评测、CI、灰度。
• 算法/Prompt 工程师：负责"动力"——分析 badcase、改 Prompt、跑微调。
• 业务标注/产品：负责"燃料"——标注、抽审、定义"什么是好答案"。

很多团队卡在第三类角色上。没有持续的人工标注投入，飞轮转两圈就停了。建议至少有一个产品同学每天花 30 分钟做抽审，比堆 GPU 有用得多。

---

11. 结语

AI 应用工程化系列写到第六篇，回头看会发现：

• RAG、Agent、推理、多模态、安全——讲的是"怎么把一个版本做出来"。
• 数据飞轮——讲的是"怎么让每一个版本都比上一个好"。

前者是单点能力，后者是复利系统。真正拉开差距的，永远是后者。

如果你的 AI 应用已经上线但停止进步，今天就开始：

1. 给每条回答加点踩按钮
2. 把日志接到 Langfuse
3. 每天抽 20 条人工看一眼
4. 把今天看到的 5 个 badcase 写进评测集

一个月后回头看，你会感谢现在动手的自己。

---

至此，《AI 应用工程化》系列六部曲收官：

1. RAG：让模型有知识
2. Agent：让模型能做事
3. Inference：让模型跑得起、跑得快
4. Multimodal：让模型看得见
5. Security：让模型不闯祸
6. Data Flywheel：让模型越用越聪明 ← 你在这里

愿你的 AI 飞轮转得又稳又快。