7 篇博文 含有标签「feedback-loops」

“点赞”按钮是你所能埋点的最廉价信号。它也是最危险的信号之一，因为没有任何迹象表明它正在重塑你的评估集本应代表的分布。这个按钮作为正向信号被收集——策展流水线将其解读为高质量——而六个月后，评估集就被一群不包含最可能流失的客户的用户所选择的案例占据了。

这种失败很少表现为回归。它表现为一种偏离：每周评估趋势向好，企业级用户的 NPS 下滑，而团队只有在一个流失的账户指出了其团队一直遇到错误回答的具体问题类型时，才会诊断出这种差距。评估集中根本没有这种类型的案例。你正在优化的信号是真实的。它只是测量了错误的分布。

大多数团队在反馈采集端的检测体系都非常完善。点击“踩”的操作会被记录，星级评分会流入仪表板，人工标注任务会将每一组偏好对写入表格。数据摄入过程干净、带有时间戳且可查询。

在采集到反馈与下一次模型更新之间所发生的一切，对大多数团队来说都是一个黑盒。

数据被过滤。某些标注的权重被调高。稀有类别被上采样。近重复项被删除。提示词模板的更改导致上个月的标签与本月的不一致，但合并依然在进行。当信号到达奖励模型或微调任务时，它已经通过了 6 个转换步骤，没有审计追踪，没有版本锚定，也无法将退化的模型权重溯源到流水线中特定的损坏点。

这就是反馈溯源鸿沟（Feedback Provenance Gap）：团队知道反馈从何处进入系统，但不知道它在塑造模型行为之前变成了什么。

每位产品负责人都听过这个论调：更多用户产生更多数据，更好的数据训练更好的模型，更好的模型吸引更多用户。数据飞轮是复利护城河，这正是AI巨头们能够赢得市场的原因。

这个论调并没有错。但实施几乎总是出了问题。在实践中，大多数数据飞轮都有多个泄漏点——反馈循环看似在运转，实际上却在放大偏差、强化陈旧模式，或者优化一个与真实目标背道而驰的代理指标。构建这些系统的工程师很少知道自己遇到的是哪种泄漏，因为所有泄漏从外部看起来都一样：参与度上升，模型在可测量的指标上持续改进，而系统却在难以归因的方式下变得越来越没用。

这就是数据飞轮陷阱。理解其失败模式，是构建真正有效飞轮的前提。

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

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

你的 AI 产品三个月前上线了。你有显示延迟、错误率和 token 成本的仪表盘。你已经看到用户与系统交互了数千次。然而你的模型和上线那天相比，好的地方一样好，差的地方一样差。

这不是数据问题。你拥有的数据已经多得不知该拿来做什么。这是架构问题。那些告诉你模型哪里失败的信号，就躺在应用日志、用户会话和下游结果数据里。它们与任何能改变模型行为的东西断开了连接。

大多数团队把 LLM 当作静态制品，然后在外围包裹监控和评估。最优秀的团队则把生产环境视为一条永不停歇的训练流水线。

大多数团队把点赞/踩的按钮当作AI质量循环的基础。思路很清晰：用户对回复评分，你积累评分，然后改进。但在实践中，这意味着你需要等整整一个月，才能检测到第一天就已经发生的质量回退。

数字是残酷的。生产环境中LLM应用的显式反馈率在所有交互的1%到3%之间。对于一款B2B产品在第一年的正常规模——每日活跃用户1000人——这意味着每天只有10到30个评分样本。以统计置信度检测5%的质量变化大约需要1000个样本。你要等30到100天，改进循环才有足够的有意义数据来运行。

你在六个月前为你的 AI 功能上线了“点赞/点踩”按钮。你有了数千条评分。你构建了仪表盘。你甚至针对负面案例进行了微调。然而，你的产品却在反馈数据无法解释的方面变得越来越糟。

问题不在于用户对自己不喜欢的东西判断错误。问题在于，点击反馈按钮的用户相对于你的实际用户群体来说，是一个具有系统性非代表性的样本——而你基于这些数据做出的每一个决定都会继承他们的偏差。