数据飞轮并非免费：构建真正提升 AI 产品的工程反馈闭环

几乎在每一个 AI 产品团队中都会出现这样一种模式：团队发布了初始模型，用户开始与之交互，接着有人在回复底部添加了一个“点赞/点踩”小部件。他们称之为反馈闭环。三个月后，模型并没有任何改进。团队纳闷为什么飞轮没有转起来。

问题不在于执行，而在于显式评分并不是反馈闭环——它们只是调查问卷。只有不到 1% 的生产环境交互会产生显式用户反馈。而那 99% 从未点击任何按钮的用户正在向你发送远为丰富的信号；你只是没有收集它们。构建真正的反馈闭环意味着通过系统埋点来捕获行为轨迹，在大规模场景下高效地标注它们，并将其导回训练和评估流程中，从而实现随时间推移的复利增长。

这是大多数团队都会跳过的基础设施建设。它需要真正的工程投入，且回报并非立竿见影。但这就是能够随使用而不断进化的模型，与一个停滞不前、产生偏移、最终悄然变成累赘的模型之间的区别。

为什么显式反馈在生产规模下会失效

评分组件存在根本性的采纳问题。它们位于交互结束时，要求用户在已经得到（或放弃得到）所需内容后进行额外的工作。最可能点击“点踩”的人是那些在意到会去投诉的资深用户。而那些悄无声息地放弃你的产品、重新组织了五次问题，或者将你的输出复制粘贴到另一个工具中手动修复的用户——你永远听不到他们的声音。

即便用户真的给出了评分，信号也是粗糙的。对代码建议的“点踩”并不能告诉你代码是错的、运行慢、语言选错了，还是仅仅不符合用户那一刻的想法。你收集到的是标签，而不是原因，而“原因”恰恰是你改进模型所需要的。

最后，大规模的显式反馈需要人工处理。即使是一个高流量产品中 1% 的数据，每天也会产生数千个评分。手动审查并根据这些标签采取行动需要一个你可能并不拥有的团队。如果没有底层的自动化支持，这种模式在数学上是行不通的。

隐式信号：真正可扩展的行为轨迹

用户在与你的产品交互时产生的行为数据蕴含着密集的隐式质量信号。问题在于你是否设计了相应的遥测系统（Telemetry）来捕获它。

对于代码生成工具，信号丰富的事件包括：

• 用户是否接受、拒绝或部分修改了建议
• 他们在采取行动前看了多久建议
• 他们是否立即使用修改后的提示词重新请求
• 接受的代码是否在几分钟内被删除或回滚

对于聊天或搜索界面，有用的隐式信号包括：

• 重新表述原始问题的后续查询（表明第一条回复没对上）
• 复制粘贴行为（高价值内容会被复制）
• 回复后的会话放弃（一个强烈的失败信号）
• 几小时后针对同一话题的再次查询（持久的信息需求，可能未被满足）

这些信号在数量上比显式评分高出几个数量级，并且它们反映了用户的实际意图而非宣称的观点。一个接受了建议并将其上线的用户，比起一个在分心时点击“点赞”的用户，向你提供了更强有力的正向标签。一个立即重新组织查询的用户是在告诉你回复是错误的，即使他从未点击过任何按钮。

实现上的要求是结构化的事件流：每一个用户动作都对应一个带有时间戳的事件，并包含足够的上下文，以便重建模型产生了什么以及用户如何响应。这不是一个数据科学项目——这是一个软件工程项目，应该像对待核心产品的埋点一样慎重对待。

大规模标注：用弱监督取代人工标注员

一旦拥有了行为信号，你就会面临标注问题。你有数百万个交互轨迹。你需要训练标签。你付不起人工标注所有数据的费用，即使能付起，标注速度也会限制你的迭代频率。

弱监督（Weak supervision）是务实的解决方案。你不再标注单个样本，而是编写标注函数（Labeling Functions）——即根据模式对样本进行分类的启发式规则。一个代码生成的标注函数可能会写道：“如果用户接受了建议且在 10 分钟内没有回滚，则标记为正向。”另一个可能写道：“如果用户显式改写了超过 50% 的建议代码，则标记为负向。”没有一个函数是百分之百准确的，但当你拥有几十个这样的函数时，去噪步骤（在 Snorkel 等框架中实现）会将它们的输出组合成足以用于训练的概率标签。

这种方法的实证案例非常有力。使用编程化标注构建模型的领域专家，其工作速度比手动标注快约 2.8 倍，且比小规模人工精选数据集的平均性能提升了 45%。这背后的洞察是反直觉的：100,000 个不完美的标签通常优于 100 个完美的标签。在大规模数据集上训练时，数量和覆盖范围在标签层面优于精确度，因为模型会自动抵消掉噪声。

2024 年这一工具链的演进加入了基础模型（Foundation Models）作为标注引擎。你不再是用代码编写启发式规则，而是将标注规则定义为提示词（Prompts），然后使用大模型（GPT-4、Llama 3.1）进行大规模应用。去噪步骤依然运行，以协调不同标注源之间的冲突。这极大地降低了编写有效标注函数所需的专业门槛，让没有专门 ML 基础设施工程师的团队也能触及弱监督技术。

主动学习：把标注预算花在刀刃上

即使弱监督处理了大大部分标注工作，某些样本仍然需要人工标注 —— 可能是因为它们对于自动标注来说过于模糊，或者是因为它们代表了模型表现最差的罕见边缘情况。主动学习就是你决定哪些样本属于这类情况的方法。

核心思想很简单：与其标注随机样本，不如选择模型最不确定或最容易出错的样本。在这些样本上进行人工标注，对提升模型效果的影响最大。2024 年的研究表明，使用基于不确定性的选择方法标注数据集的 20–25%，就能达到标注全部数据所能获得性能的 95%。在多个生产环境中，团队报告称在保持下游模型质量不变的情况下，标注量减少了 30–70%。

在实践中，这意味着要建立一个由模型置信度得分驱动的优先级队列。低置信度的输出会比高置信度的输出更优先进入人工审核环节。监控发现的罕见失败类别会被提升优先级。新的分布偏移 —— 即模型遇到了以前未见过的输入类型 —— 会被标记为加急标注。

运行要求是这个队列必须是可执行的：标注团队或自动标注流水线处理它的速度需要快于新样本积累的速度，否则队列就会变成瓶颈。这就是为什么队列的设计比筛选算法的复杂程度更重要。一个简单的、将 5% 的流量路由到审核的不确定性阈值，比一个需要一周工程时间才能修改的复杂多因子算法更有用。

闭环：将信号路由回评估与训练

大规模捕捉信号并进行标注只解决了问题的一半。另一半是“管道工程”，即如何将这些已标注的样本路由回决定模型质量的系统中：你的评估套件和训练数据。

评估端往往被忽视。大多数团队在发布时都会建立一个固定的评估基准，并且很少更新。但随着时间的推移，用户查询的分布会发生变化，如果基准不能反映当前的使用模式，它就会在生产环境表现上给你误导信号。闭环要求生产追踪（production traces）—— 及其隐式标签 —— 持续向基准注入新样本，以便评估分数能追踪用户的真实体验。

训练端是产生复利的地方。来自生产环境的新标注数据被合并到训练语料库中，微调运行会更新模型，然后部署更新后的模型。循环往复。这个循环的频率既是工程决策也是产品决策：对于许多团队来说，每周进行一次微调是可行的，但这需要自动质量门控，以防止低质量的训练数据导致已部署的模型性能下降。

时点特征存储（Point-in-time feature stores）在这里至关重要。如果你的模型使用了源自用户上下文（账户历史、近期互动、产品状态）的特征，这些特征需要在推理时进行记录，以便与稍后到达的结果标签配对。如果没有这一点，你会遇到标签延迟问题：预测的真值（ground truth）往往在预测做出几小时或几天后才会显现，而事后追溯重构预测时的特征值通常是不可能的。

会悄悄摧毁你飞轮的陷阱

三种失败模式比基础设施问题更能摧毁数据飞轮。

偏差放大 (Bias amplification) 是最隐蔽的。如果你的模型存在系统性的盲区 —— 例如处理某些查询类型效果很差 —— 隐式信号将反映这一盲区。那些停止重新表述查询直接离开的用户不会产生后续信号。模型从那些坚持下来的用户那里学习，这使得训练分布向它已经表现良好的用例倾斜。与此同时，失败案例的性能并没有提高，因为那些用户已经放弃并停止产生数据。随着时间的推移，模型在它擅长的领域变得更好，而在它挣扎的领域变得更差。

循环预测标签 (Recycled prediction labels) 会导致模型崩溃。当模型自身的输出被用作训练标签时 —— 无论是人工标注员对模型建议进行机械确认（rubber-stamping），还是下游模型的输出被用于训练上游模型 —— 错误都会累加。模型学会了复制自己的错误。研究表明，这种退化遵循一个可预测的轨迹：在合成或自生成数据上训练的模型链最终会收敛到一个由模型最常见错误主导的狭窄分布中。明确的人工纠错循环是防御手段，这意味着标注流水线需要对相当比例的样本进行真实的人工审核，而不仅仅是模型标记为不确定的案例。

标签泄漏 (Label leakage) 是一个更微妙的问题。当只有在评估时才能获得的信息（或者隐式携带了结果的信息）进入了训练特征时，就会发生这种情况。一个特征量化了“用户发现此回答很有用”，它不可能出现在推理时，但在从日志组装的训练数据集中很容易意外包含它。结果是模型在离线指标上看起来非常出色，但在生产环境中表现平庸。缓解措施是严格的时间校验：训练数据必须仅包含在预测时刻可用的特征和上下文，且这些内容应从时点日志中重构。

实际成本

建立这种基础设施需要实实在在的工程能力。单个组件并不昂贵——事件日志记录、标注流水线、微调任务——但将它们整合进一个可靠的闭环需要持续的投入。标注是生产环境 AI 技术栈中增长最快的成本中心之一，即使有弱监督（weak supervision）减轻了人工标注负担，仍需考虑标注负责人、质量审计员和流水线工程师的成本。

好消息是，这项投入是前置的。一旦闭环流水线运行起来，边际改进成本就会下降。在经过筛选的生产信号上微调较小的模型，其表现始终优于从头开始重新训练大模型，且计算成本通常只有一小部分。完善了这一体系的团队报告称，随着他们针对自己的用例微调专用模型，而不是在查询时依赖大型通用模型，推理成本显著下降。

组织成本更难量化，但不应被忽视。一个能产生复利效应的反馈循环，需要定义“好”的团队（产品）、捕获数据的团队（数据工程）、标注数据的团队（标注）以及进行训练的团队（ML 工程）之间保持一致。在大多数组织中，这些是拥有独立路线图的独立团队。只有当他们都以相同的节奏朝着同一个方向前进时，循环才能闭合。

真正的飞轮指标

如果你想知道你的反馈循环是否真的发挥了作用，不要再盯着原始基准测试（benchmark）中的模型性能，而是开始衡量两件事：你的评估套件追踪当前生产分布的速度，以及表现最差的查询类别与表现最好的查询类别之间的差距缩小的速度。

一个转动起来的飞轮，意味着上个月的边缘案例（edge cases）会出现在这个月的训练数据中。基准测试随着产品同步演进。标注能力随流量规模化，而不是滞后于流量。这个循环不会自动建立。但一旦它运行起来，它就会承担大部分工作。