真正能训练模型的反馈界面

大多数 AI 产品上线时都带着一个点赞/踩组件，并将其称为反馈基础设施。但它并不是。实际上，它是一份调查问卷——只有不满意或格外认真的用户才会去填。而且这份问卷无法告诉你正确的输出应该是什么样的。

其结果是：数据集的形状不由用户想要什么决定，而是由哪些用户愿意点按钮决定。这种选择偏差会渗透到微调、奖励模型和 DPO 流水线中，悄悄地将模型导向极少数且缺乏代表性的少数人的偏好。而隐式信号——编辑率、重试率、会话放弃——则覆盖了所有接触产品的用户，无需任何点击，只是使用软件这一行为本身就能产生这些信号。

以下是如何设计反馈界面，将高保真训练信号作为产品使用的自然副产品生成，以及如何将这些信号接入训练流水线。

糟糕反馈的解剖

在修复反馈收集之前，有必要准确命名传统方式究竟在哪里出了问题。

捕获时的选择偏差。 踩按钮是由那些沮丧到愿意点击、却又没沮丧到直接离开的用户按下的。那个典型用户——安静地接受了不完美的回复然后继续前行的人——是隐形的。那个用户的行为才是你最常见的情况，而你对此毫无信号。

没有参考的模糊性。 踩只告诉你用户不满意，却没有说满意应该是什么样的。他们想要更短的回复？不同的语气？准确的信息而不是自信的幻觉？没有参考输出，这个信号对监督微调几乎没用，对偏好学习也只是略有价值。

领域专家的代表性不足。 反馈人群偏向频繁的普通用户。如果你的产品是编程助手，那些点"有用"的用户往往不是最能判断生成代码是否正确的人——他们是那些不懂得去判断的用户。

变相的奖励作弊。 随着模型越来越善于生成能获得点赞的输出，它们在优化参与度而非正确性。冗长、听起来自信的回复往往比准确、有所保留的回复在二元反馈中表现更好。模型学会的是什么能让用户点击，而不是什么能让用户成功。

成对比较（"这两个回复哪个更好？"）常被作为改进方案提出。确实有所改善，但很有限。2025 年关于 LLM 评估的研究显示，成对偏好在约 35% 的情况下会翻转，而绝对评分评估只有约 9%。成对协议也更容易受到位置偏差和冗长效应的影响。比二元评分好，但不是结构性解决方案。

产生高保真信号的三种模式

内联纠正

当用户直接编辑模型的输出——重写一段话、修复一段代码、调整生成的摘要——他们就明确告诉了你他们想要什么。这是一个完整的训练对：一边是模型的生成，另一边是用户纠正后的版本。你不需要让他们评分任何东西。

当编辑是产品的自然交互时，内联纠正效果最好。写作工具、代码编辑器和文档助手都有这个特性。用户不是在"提供反馈"——他们只是在做自己的工作，而编辑事件被捕获了。实施挑战在于将哪个模型生成对应哪次编辑关联起来，尤其是当编辑发生在生成几分钟后或跨多个会话时。

实现要求：跟踪生成物件与用户后续修改之间的血缘关系。存储模型输入、模型输出，以及每个后续编辑状态和时间戳。从这份日志中，你可以重建偏好对——模型的原始输出是"被拒绝"的回复，用户最终编辑后的版本是"被选择"的回复——可直接用于 DPO 训练。

选择性重新生成

当用户点击"重新生成"而非编辑输出时，他们做出了一个判断：回复错得足以丢弃，但他们仍然需要模型的帮助。这是一个强烈的负面信号。

训练价值比看起来更高。一个被拒绝的生成与一个被接受的第二次生成，无需任何显式反馈 UI 就能创建偏好对。用户接受了第二个输出，拒绝了第一个，你知道两者的确切内容。即使他们后来又编辑了第二个输出，你也有更清晰的信号：模型的第一次尝试以某种方式失败了，用户觉得值得完全重试。

这里的实施很直接：为每个生成记录唯一 ID，并记录用户是否在采取任何下游行动之前请求了重新生成。下游行动——接受、编辑、复制、分享——形成闭环，确认第二次生成是否真的更好。

会话结果标注

与其评价单个回复，会话结果标注询问用户是否在会话中完成了目标。这将评估从"这个回复好吗？"——一个没有基准答案的判断——转移到"这个产品有效吗？"——一个答案更清晰的问题。

会话完成信号因产品类型而异。编程助手衡量用户的测试套件是否通过、是否提交了代码、是否关闭了任务。写作助手衡量文档是否被发布或分享。客户支持工具衡量工单是否被无需升级地关闭解决。

相对于回复级别反馈，会话结果标注的优势在于它锚定于具体结果而非主观质量印象。用户不必说清楚回复哪里出了问题——他们在会话结束时的行为已经编码了那些信息。一个在几轮重新生成后以任务完成告终的会话，讲述的故事与一个以放弃告终的会话截然不同。

挑战在于当任务是开放式的时候，如何将"任务完成"具体化。先从识别你的产品自然产生的两三个最清晰的完成信号开始——分享事件、保存事件、下游行动——在尝试推断任何更微妙的东西之前，用这些来标注会话。

作为基础设施的隐式行为信号

上述三种模式需要用户做一些有意识的事情——编辑、重新生成、完成任务。但即使是被动行为也包含信号。这些隐式信号不需要任何 UI 变更，覆盖你的全部用户群，能产生比显式反馈机制多一个数量级的数据。

编辑率衡量用户在使用前修改了模型输出的多大比例。被逐字复制的回复表示接受。用户在粘贴到文档前重写了 60% 的 token 的回复，即使用户从未点过踩，也更接近拒绝的信号。大规模来看，按回复类型划分的编辑率告诉你模型行为的哪些部分最需要改进。

重试率跟踪用户在接受回复之前请求重新生成的频率。持续的重试行为——在接受或放弃之前进行三次或更多次重新生成——标志着系统性失败模式。如果某个特定的查询模式持续产生高重试率，那么该模式在训练数据中代表性不足，或者根本超出了模型当前的能力。

会话放弃是最难误读的信号。当用户在没有完成任务的情况下中途停止交互，说明出了什么问题。问题是什么。放弃可能意味着模型失败、任务太复杂，或者用户被打断了。将放弃与最后一个模型回复的内容——长度、主题、置信度标记——相关联，有助于区分模型失败和外部干扰。

停留时间——用户在采取行动之前花多长时间阅读回复——与困惑程度相关。在编辑或重新生成之前的长停留时间通常表明用户在试图解析哪里出了问题。在接受之前的短停留时间表明回复立即符合预期。

复制和分享事件是强烈的接受信号。复制代码片段或分享生成段落的用户已经判断输出足够好，可以在产品外使用。这些事件值得在训练流水线中上调权重，相对于被动接受——在那种情况下，用户可能只是出于惰性接受了一个平庸的回复。

将这些信号接入训练流水线

收集信号是容易的部分。更难的工程问题是将行为日志转换为不引入新噪声的训练数据。

标签转换：原始信号在有用之前需要转换为训练标签。编辑事件变成偏好对。会话完成事件变成前序回复序列的正向标签。高重试率模式将序列标记为需要人工审核。在行为事件和训练标签之间建立明确的映射逻辑，而不是将其隐含在数据科学笔记本中。

置信度路由：并非所有隐式信号都同样可靠。单次编辑可能反映用户偏好漂移，而不是模型失败。消防演习期间的会话放弃对模型没有任何意义。将低置信度信号——孤立事件、模糊上下文——路由到人工审核队列，在将其纳入训练运行之前。将你的 GPU 预算留给干净的数据。

近期性加权：用户行为和任务分布持续变化。对所有时间段均等加权的训练数据集会低估当前行为，过度强调已经改变的模式。对训练数据权重应用指数衰减，更加强调近期信号。这对用户基础快速增长且新用户行为与早期采用者不同的产品尤为重要。

避免标签折叠：当隐式信号在多次训练迭代中累积——模型在由用户行为生成的数据上训练，而用户行为又被上一个版本的模型塑造——你就有产生误差放大反馈循环的风险。维护一组人工标注的保留示例，锚定每次训练运行。不要纯粹在当前模型输出生成的信号上训练；在组合中保持人工基准。

人工审核的评审者间验证：当模糊信号路由到人工审核时，测量评审者在相同示例上的一致性。低一致性并不总是评审者困惑的信号——它通常意味着该示例本身就存在歧义，根本不应该进入训练集。在将人工审核示例纳入训练数据之前，按一致性阈值过滤。

实践中的样子

一个最小化实现——能产生比点赞按钮明显更好的训练数据，同时不需要大型行为数据基础设施——看起来是这样的：

• 记录所有编辑事件，从模型生成到用户行动之间。存储（输入，模型输出，用户最终版本）三元组。
• 记录重新生成事件及前序生成内容。在用户接受第二次生成的情况下，存储（输入，被拒绝输出，被接受输出）三元组。
• 定义两三个会话完成信号，这些信号是你的产品自然产生的。与前序对话上下文一起记录。
• 跟踪复制/分享事件作为强接受标签。
• 标记高重试会话进行人工审核，而不是将其视为干净的训练数据。

有了这套基础设施，你在每次编辑时收集偏好对，在每次重新生成时收集拒绝信号，并从自然用户行为中获得会话级标签。点赞/踩组件变成了一个小补充——对想要给出明确反馈的用户有用——而不是主要信号。

底层原则

最好的反馈界面是隐形的。它从那些在思考自己工作而不是在评价你产品的用户身上捕获信号。每次用户编辑 AI 生成的输出时，他们都在提供一个示范，说明他们想要什么。每次他们重新生成时，他们都在拒绝你给他们的东西。每次他们在最少迭代后成功完成任务时，他们都在确认你的模型在那个情境下的行为是有效的。

实施挑战在于建立日志基础设施，可靠地捕获这些事件，以及将其转换为可用训练对的流水线。但信号本身已经在那里了，由每个与你产品交互的用户持续生成。问题是你的工程是否捕获了它，还是让它消失了。