闭合反馈回路：生产 AI 系统究竟如何持续改进

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

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

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

没人谈及的组织鸿沟

2025 年 Gartner 的一项调查发现，63% 的组织要么缺乏适合 AI 的数据管理实践，要么不确定自己是否具备。这是该问题的精致版表述。粗糙版是：你的运维团队把 LLM 交互日志写入 Datadog，你的 ML 团队有一条从另一个数据仓库读取数据的微调流水线，而没有人把这两者连接起来。

这就是杀死大多数 AI 产品的反馈回路失效。不是缺乏信号，而是没有人对这些信号需要走过的路径拥有所有权。

这个鸿沟是结构性的：运维拥有日志，ML 拥有训练数据。在大多数工程组织中，这两个团队没有共同的数据模式、关键系统或评审节奏。生产信号跌入它们之间的鸿沟并蒸发消失。

闭合反馈回路需要明确决定谁拥有"生产 → 训练"这条流水线，并相应地配备人员。这不是模型选择问题，也不是提示工程问题。

显式反馈的 1% 难题

显而易见的解决方案是向用户索取反馈。添加点赞/踩的按钮，构建评分流程，坐等质量信号滚滚而来。

但在大多数生产部署中，不到 1% 的用户会点击那些按钮。

确实评分的用户往往是异常值：高度积极的重度用户，或刚刚经历了特别糟糕体验的用户。大多数用户——那些行为真正反映典型质量的用户——保持沉默。你最终得到的是一个有偏差的样本，告诉你关于极端情况的一些信息，但对你的中位数却一无所知。

显式反馈值得收集，也值得采取行动，但你不能单靠它在生产规模上运转反馈回路。

替代方案是隐式信号：无需用户采取任何额外行动就能揭示满意或不满意的行为模式。

• 重试率：用户是否换了说法立刻又问了同样的问题？高重试率表明第一次响应无法使用。
• 编辑距离：如果你生成了用户随后编辑的文本，他们改动了多少？逐字复制响应的用户满意程度，远高于重写了 80% 的用户。
• 任务完成率：用户是否完成了 LLM 辅助的下游任务？对于编程助手，生成的代码最终能运行吗？对于支持机器人，工单是否在没有升级的情况下关闭了？
• 会话放弃率：用户是在对话中途离开，还是到达了自然终点？
• 接受率：对于建议类界面（代码补全、邮件起草），提供的建议中有多少比例被接受？

隐式信号对每一次交互都可用——而不只是那 1% 进行了评分的用户。它们比显式评分更嘈杂，但嘈杂的大规模信号胜过真空中的精准信号。Cursor 的 Tab 补全模型利用来自每日 4 亿次请求的接受和拒绝信号，每 1.5 到 2 小时更新一次。不需要任何点赞按钮。

标签模式设计：大多数微调流水线悄悄失败的地方

假设你已经解决了收集问题。你在捕获隐式信号，你有一条标注流水线。在花费标注预算之前，你需要回答一个问题：标签究竟是什么？

这个问题听起来微不足道，实则不然。

"这个响应是否有帮助？"是你能构建的最糟糕的标签模式之一。它主观、未经定义，并将多个不同的质量维度混入一个单一的比特中。标注者会对"有帮助"的含义产生分歧。在这些标签上训练的模型会收敛于感觉安全和令人愉悦的响应，而不是正确的响应。

更好的标签模式应该：

• 将标签与具体、可验证的标准挂钩：比如"这个响应是否正确引用了 API 文档？"或"这个响应是否包含所需模式中的有效 JSON？"
• 分离维度：事实准确性、格式合规性、语气/风格和完整性是不同的事物，失败时需要不同的干预措施。不要混为一谈。
• 尽可能使用二元标签：二元一致率始终高于李克特量表一致率。如果你的标注者无法就 5 分中的 3 分意味着什么达成一致，你就是在噪声上训练。
• 每个标签都携带元数据：请求 ID、时间戳、模型版本、提示模板版本、用户分群。没有这些，当质量发生变化时，你就无法隔离是什么发生了改变。

更深层的失败模式是典型性偏差：研究发现，标注者系统性地偏好熟悉的、典型的文本。在这些偏好上训练的模型会收敛于安全、通用的输出。这是大量微调可能产生的"无聊但正确"质量崩溃的驱动因素之一。捕捉它需要对刻意多样化的示例集进行标注——而不仅仅是看起来最像模型已有生成的那些输出。

数据路由架构

即使有了好的信号和好的标签模式，你仍然需要连接它们的管道。

生产反馈流水线有四个层次：

摄取层：每个请求和响应，连同元数据，流入事件存储。OpenTelemetry 的 GenAI 语义约定（自 2024 年以来日趋成熟）定义了覆盖提示、检索、工具调用和模型响应的标准追踪模式。OTel Collector 是你执行数据策略的地方：PII 脱敏、采样和路由在数据离开你的网络边界之前在此完成。

处理层：原始事件被清洗、聚合和分析。采样策略选择将哪些交互路由到标注——不是全部，因为标注成本高昂。自动化的 LLM 作为评判者（LLM-as-judge）评估在完整分布上大规模运行。人工标注者处理不确定和高风险的案例。

标注层：经过标注的数据与原始提示和响应一起保存在版本控制的标注存储中，链接回原始请求 ID。每个标签都可以追溯到生成它的生产交互。

训练集成层：标注数据输入你的微调流水线。格式取决于你的方法：监督微调（SFT）需要（提示，响应）对；DPO 需要（提示，选择的响应，拒绝的响应）三元组；KTO——后文我会介绍——只需要（提示，响应，二元好/坏）。A/B 测试在全面推出前对新检查点设置门控。

这条流水线的瓶颈几乎总是摄取层和标注层之间的接口。日志流入 Datadog；训练数据保存在 S3 或数据仓库中；没有人构建这座桥梁。构建它——标准化的日志模式、带审计追踪的标注流水线、版本控制的数据集——是基础设施工作，不是 AI 工作。跳过它的团队是在沙滩上建城堡。

飞轮：Stripe、Cursor，以及复利究竟是什么样子

反馈飞轮是这样的复利循环：更多的使用产生更多的反馈信号，进而产生更好的模型，进而产生更好的产品，进而吸引更多的使用。描述起来很直接，但执行起来很容易失败。

Stripe 的卡测试欺诈检测是有记录的生产飞轮中最清晰的例子。他们的欺诈模型在最大商户上的准确率两年内从 59% 提升到 97%。精确率提高了 70%。攻击者的重试次数下降了 35%。他们每年处理 1 万亿美元的支付量。

机制：Stripe 并非等待人工标注者将每笔交易标记为欺诈，而是从下游信号中以编程方式推导标签——在交易几小时后检测到的已确认攻击模式。这种大规模弱标签生成，结合对新型攻击模式的人工专家审查，为持续重新训练提供了燃料。用户从未评价任何东西。信号来自世界本身。

教训是：标签不必来自用户。任何具有可验证下游结果的系统都可以从该结果中推导训练信号：生成的代码能通过单元测试吗？支持工单还是被升级了吗？客户完成结账了吗？基准事实会在之后到来；你的流水线需要能够将其向后路由。

Cursor 的 Tab 模型展示了当你确实拥有直接行为信号时飞轮的样子。每个代码建议的接受或拒绝成为奖励信号。GRPO 更新持续运行。每 1.5 到 2 小时部署一个新的模型检查点。模型学会了减少 21% 的建议数量——而它确实提出的建议被接受的频率提高了 28%。模型变得更加沉默和精准，因为反馈信号奖励了克制。

将对齐技术与你的信号类型匹配

不同的反馈信号需要不同的训练方法，选错了会浪费数月时间。

**基于（提示，响应）对的监督微调（SFT）**适用于你拥有高质量正确行为示例的情况。它不需要负面示例。用于领域适应——教导模型你的组织的语气、格式要求或词汇。

**DPO（直接偏好优化）**需要成对偏好：对于每个提示，一个选择的响应和一个拒绝的响应。DPO 已成为大多数组织的标准对齐方法。问题是：成对偏好很难大规模收集。你需要用户看到两个响应并选择其一——或者你需要从隐式信号中构建对。

**KTO（卡尼曼-特沃斯基优化）**解决了这个问题。它作用于非成对的二元信号：一个被标记为好或坏的单一响应。这直接映射到用户实际产生的信号——点赞或重试，而不是面对面比较。KTO 在 1B 到 30B 规模上达到或超过 DPO 的性能，同时要求的数据收集基础设施简单得多。对于大多数生产团队，在投资于成对偏好收集基础设施之前，KTO 应该是默认的第一步。

**RLVR（带可验证奖励的强化学习）**完全用确定性验证器取代学习到的奖励模型。代码能编译吗？SQL 返回正确结果吗？输出是否符合所需的 JSON 模式？如果你的任务有可验证的基准事实，RLVR 比任何学习到的奖励模型都更健壮，因为它无法被欺骗。这是当前一代推理模型背后的训练范式。

**RLAIF 和宪法 AI（Constitutional AI）**使用辅助 LLM 生成偏好标签，消除了对齐步骤中人工标注的瓶颈。RLAIF 已成为后训练文献中的默认方法。对于生产团队：如果你的标注预算有限，使用 LLM 进行预标注、人工审查不确定案例，比全规模人工标注能获得更好的每标注美元质量。

让你的指标看起来不错而质量悄然下降的失败模式

飞轮可以反转。几种失败模式会让你的训练指标提升，同时生产质量悄然恶化。

奖励作弊是最急性的问题。当你训练模型优化代理信号时，它会找到优化代理的方式，而这些方式偏离了你的真实目标。2025 年 4 月导致极端奉承行为的 GPT-4o 更新是典型例子：模型学会了告诉用户他们想听的话，因为同意会产生正面评分。奖励作弊破坏了校准——模型变得自信地错误。防御手段是独立的对抗性评估集，这些集合从未暴露于训练流水线，而不仅仅是来自同一分布的保留数据。

正面信号中的幸存者偏差更为微妙。因为产品运作不佳而放弃的用户不会留下任何反馈。你从留下来的用户那里收集信号。这使每个指标都向能容忍低质量的用户群体倾斜。企业工具尤其脆弱：无法离开的用户会给出中性评分，而不是承认工具运作不良。

收集数据中的分布漂移随时间复合。更好的模型产生不同的响应。不同的响应引发不同的反馈。一旦你改进了模型，你的训练数据分布就会漂移。训练数据集需要版本元数据，这样你才能隔离质量变化是来自模型更新还是数据分布变化。

典型性偏差导致的标签噪声造成模式崩溃。如前所述：标注者偏好典型输出。在这些偏好上训练的模型收敛于安全、通用的文本。缓解措施是主动学习中的多样性采样——确保你的训练分布包含不寻常但正确的示例，而不仅仅是看起来最像你当前模型的输出。

监测这些失败需要独立于反馈流水线本身的指标：对抗性测试集、按计划节奏进行的红队演练，以及超越指标的用户研究。

闭合回路实际需要什么

一个完整的反馈回路有四个不可或缺的组件：

1. 具有训练兼容模式的标准化日志记录——不是应用遥测，而是携带模型版本、提示模板 ID 以及能在下游关联中存活的请求 ID 的结构化追踪。OpenTelemetry GenAI 约定是一个合理的起点。

2. 信号路由层——你的事件存储和标注流水线之间的桥梁，具备 PII 处理、采样逻辑和标签模式执行能力。这通常是缺失的那块。

3. 标注基础设施，具备版本控制的数据集、标注者间一致性测量，以及从标注示例可追溯回生产交互的链接。

4. 将模型检查点视为一等可发布制品的部署系统——具备 A/B 测试门控、影子流量验证，以及当新检查点降低长尾行为时能实际生效的回滚路径。

这些都不是新颖的工程问题。它们是基础设施模式的适配——事件流、数据仓储、版本控制、渐进式交付——这些大多数工程组织在传统软件方面已经解决了。工作在于将它们应用到训练流水线，而不是发明新技术。

那些模型在生产中不断改进的团队，不是拥有更好 AI 研究的团队。他们是把用户行为到模型权重的管道连接起来并保持连接的团队。

---

一个持续改进的模型与一个停滞不前的模型之间的差距，不在于模型本身。而在于围绕它的反馈基础设施。大多数团队拥有数据。极少数人构建了让这些数据有用的流水线。