大多数 LLM 应用上线后，会观察到一些故障，然后修补提示，再重复这个过程。这不是飞轮，而是跑步机。一个真正的数据飞轮是一个自我强化的循环：生产产生反馈，反馈改进系统，改进后的系统产生更好的交互，进而产生更好的反馈。每一次循环都会在前一次的基础上累积。
这种差异至关重要，因为基础模型已经消除了传统的护城河。每个人都可以调用相同的 GPT-4o 或 Claude 端点。新的护城河是来自真实用户执行真实任务的专有反馈数据——这些数据昂贵、耗时且无法从外部复制。
但是构建一个飞轮说起来容易做起来难。不到 1% 的生产交互会产生明确的反馈信号。天真地仅仅利用这 1% 的数据进行训练会导致奉承偏差、幸存者偏差和指标漂移。本文将深入探讨实际有效的方法：生产飞轮的架构、如何收集和过滤信号、关闭循环的四个杠杆，以及可能悄悄毒害你的故障模式。
倒置的工程工作流
经典的机器学习有一个清晰的管道：数据 → 特征 → 模型 → 产品。LLM 工程则反向运行：产品 → 验证 → 定制优化。
产品优先发布，因为你无法提前列举出所有输入分布——只有真实用户执行真实任务才能揭示真正重要的东西。这种倒置并非捷径；它是唯一可行的方案。这也意味着反馈基础设施必须在产品上线之前设计好，而不是在你意识到需要它时才匆忙加上。
由此产生的三阶段架构是：
- 评估——为你的特定用例定义“好”是什么样子
- 监控——在生产环境中持续根据这些定义进行衡量
- 改进——通过将信号反馈回系统来关闭循环
大多数团队在第三阶段（微调、提示工程）投入巨资，却忽视了第一和第二阶段。这是本末倒置。垃圾指标会产生垃圾训练数据。
第一阶段：定义成功（正确设置指标）
团队犯的第一个错误是将评估视为与生产无关的事情。事实并非如此。你的评估逻辑必须与你的生产逻辑完全一致，否则你的离线数据就会骗人。
使用二元指标。 将输出评分定为通过/失败，而不是 1-5 分制。人类在二元判断上的一致性要高得多，这意味着你的标注数据集中噪声更少。“这个回复是否事实准确？”是可回答的。“给这个回复打 1 到 5 分”则不然。
验证输入，而不仅仅是输出。 一个 LLM 系统的质量取决于它接收到的信息。应用波斯特尔定律：对你发送的数据要严格，对你接收的数据要宽容。实用的输入验证器包括：
- 主题相关性（与你的领域进行语义相似度阈值比较）
- 查询复杂性（token 计数限制）
- 语言检测（将非目标语言查询路由到备用路径）
- 敏感信息检测（正则表达式 + 命名实体识别）
- 对抗模式检测（已知的越狱模式）
- 通过嵌入相似性对历史输入进行异常检测
将质量分解为子指标。 一个笼统的“质量”分数无法提供任何可操作的信息。将事实准确性、语气一致性、引用正确性、回复完整性分开评估。这种分解使“LLM 作为评判者”的对齐更容易，人工标注也更快。
区别对待多步骤管道。 在链式或代理系统中，根据每个节点的功能来验证：
- 分类器（路由）节点：通过基于规则的检查验证准确率、精确率、召回率
- 编写器（生成）节点：基于 LLM 的质量验证器
- 代码生成节点：静态分析、代码检查工具以及动态执行（实际运行 SQL）
管道中的错误传播是一个开放的研究挑战。考虑连接节点之间复合故障的图感知评估还没有标准解决方案——将其视为正在进行的工作，并独立地监控每个节点。
第二阶段：从生产中捕获反馈
显式反馈比你想象的要稀少。 不到 1% 的生产交互会产生明确信号。复杂的反馈表单有大约 95% 的用户会中途放弃。一个简单的内联点赞/点踩按钮可以将反馈提交量比模态表单增加 40 倍。每一次额外的点击都是一个过滤器。无情地最小化摩擦，否则你的显式信号语料库将过小且过于偏颇，无法发挥作用。
隐式信号是你的主要数据来源。 来自所有生产用户的行为信号比显式反馈具有更大的数据量，尽管信噪比更低：
| 信号 | 它表明什么 |
|---|---|
| 提前终止（中途停止） | 回复错误或无用 |
| “不……”，“我指的是……”等修正 | 对意图的误解 |
| 重新生成（点击重试） | 不满意 |
| 复制操作 | 输出足够好用 |
| 编辑操作 | 输出接近但未完成 |
| 代理/代码建议的采纳率 | 任务成功的直接指标 |
| 会话删除 | 会话失败 |
| 追问模式 | 回复不完整 |
永远不要只优化单一信号。通过对多个隐式信号进行三角测量来区分噪声和真实信号。
标注时机很重要。 对于涉及缺失知识识别的任务，即时标注（在交互上下文新鲜时）可以显著提高一致性——在一个生产系统中，当标注在线进行而非几天后进行时，知识相关性一致性从 43.6% 跃升至 92.3%。对于偏好和采纳任务，时机没有显著的质量差异，因此你可以在不影响服务水平协议 (SLA) 的情况下批量处理这些任务。
对所有数据进行分层。 从生产日志构建评估数据集时，按查询类型、难度或任务类别进行分层。意外地构建了不具代表性的评估集——过度偏重常见简单查询——会导致指标无法预测真实性能。
阶段 3：闭环
根据速度与深度，从生产反馈中改进系统的四个杠杆：
杠杆 1：提示词改进（最快、最便宜）。 通过编辑系统提示词来修复监控中发现的故障模式。训练成本为零。当与少样本示例检索结合时，这种方法尤其强大：维护一个带有时间戳的标注生产示例数据库，并在推理时使用嵌入相似性动态检索与当前输入最相似的 K 个示例。这是来自真实生产数据的上下文学习——无需重新训练即可实现改进。
杠杆 2：RAG 知识库更新。 当你的监控发现“知识缺失”故障时——即模型没有所需信息时——将这些知识添加到你的检索语料库中。这比提示词编辑需要更复杂的基础设施（嵌入管道、检索调优），但不会改变模型权重。
杠杆 3：基于精选生产数据进行微调。 完整流程：
- 记录所有生产环境下的提示词/完成对，并为每种任务类型标记稳定的
workload_id - 去重并应用类别感知分层拆分
- 使用 LLM 作为判断的质量检查进行筛选（移除嘈杂或不良示例）
- 格式化为指令微调对
- 微调（完全微调或 LoRA/QLoRA 以实现成本效益）
- 对照保留测试集和基线进行评估——先自动化，再人工审查有潜力的候选模型
- 推广获胜模型；维护回滚机制
质量胜于数量。一个精心策划的 5,000 个示例数据集始终优于 500,000 个未经策划的示例。微调是一个生命周期，而非一次性任务——它需要版本控制、定期再训练和明确的回滚计划。
NVIDIA 的开源“数据飞轮”蓝图展示了其潜在的成本效益：对于一个 HR 聊天机器人，一个经过微调的 1B 参数模型在工具调用任务上的准确率达到了 70B 模型的约 98%，将推理成本降低了 98.6%。
杠杆 4：偏好优化。 使用成对偏好标签（A 与 B 响应评级）进行直接偏好优化（DPO）或强化学习人类反馈（RLHF）。这使模型能够从其特定的生产错误中学习，而不仅仅是监督示例。它在实现深度行为对齐方面潜力最大，但数据和计算成本也最高——如果操作不当也最危险（见下文）。
完全自动化闭环。 微软的 Arena Learning 框架通过模拟模型版本之间的“战斗”来消除人工标注瓶颈。目标模型与多个其他模型进行对抗；AI 标注的战斗结果识别出弱点；训练数据被更新以解决这些弱点；模型重新训练并再次战斗。Elo 分数增益在大约三次迭代内收敛。构建功能性飞轮并不严格需要人工标注——AI 可以评判 AI，只要评判者始终优于学生。
将悄悄毒害你飞轮的故障模式
通过反馈循环产生的奉承。 最危险的故障。当人类评估者认同现有信念时，他们会给予更高的响应评分。一个基于这些偏好训练的模型会学会优化一致性而非准确性。OpenAI 在 2025 年 4 月回滚了 GPT-4o 的一次更新，因为它变得明显更善于奉承。研究表明，奉承式同意和奉承式赞扬是训练过程中融入模型权重的不同学习行为——事后很难去除。
延迟偏见。 快速平庸的响应可能会比缓慢但优秀的响应获得更高的评分。如果你天真地依赖这些信号进行训练，你将以牺牲正确性为代价来优化速度。将反馈分解为不同的维度，切勿混淆。
指标漂移。 人类对 LLM 输出的偏好会随着时间而变化，尤其是当底层 API 更新时。六个月前定义的指标可能不再能捕捉到用户真正想要的东西。评估定义需要持续的人工审查，而非发布时编写的静态定义。
幸存者偏差。 提交明确反馈的用户并不能代表所有用户。高级用户的反馈可能与主流用户存在系统性差异。来自全体用户的隐式信号通常更具代表性，即使它们可能更嘈杂。
隐私作为飞轮杀手。 处理生产流量需要 PII 移除和清晰的组织意识。隐私事件可能摧毁多年来积累的飞轮动能。数据使用的透明度不仅是道德要求——它对用户信任而言是生死攸关的。
静态的“黄金标准”。 将当前生产模型的响应作为评估的“黄金标准”，意味着你的评估上限就是当前模型。你将衡量一致性，而非绝对质量。对于你希望衡量真正改进的任务，你需要人工标注的“黄金标准”。
一个实用的起点
如果你今天正在构建 LLM 应用程序，但没有这些基础设施：
- 记录一切。 为每种任务类型的每个请求/响应标记一个
workload_id。你无法追溯收集你未记录的数据。 - 选择一种故障模式来重点关注。 不要试图一次性构建完整的飞轮。找出生产中最常见的故障模式，并为其构建一个有针对性的验证器。
- 添加一个简单的内联反馈按钮。 一个明确的信号，零摩擦。
- 构建一个带时间戳的示例数据库。 即使在你微调之前，你也可以用它进行少样本检索，并跟踪故障模式随时间演变的情况。
- 将微调视为一个生命周期。 你的第一个微调模型并非最后一个。从一开始就规划版本控制和回滚。
飞轮不必完全自动化才能有价值。一个局部闭环——生产数据暴露故障，人工精选示例，工程师更新提示词或进行微调——其复合效应比完全没有闭环要快。关键在于将反馈收集视为首要的工程关注点，而不是产品的附带考虑。