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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

加载中…