跳到主要内容

21 篇博文 含有标签「rlhf」

查看所有标签

隐性反馈陷阱:为什么参与度指标在 AI 质量上具有误导性

· 阅读需 9 分钟
Tian Pan
Software Engineer

一家加拿大航空公司的支持聊天机器人凭空捏造了一项根本不存在的丧亲票价政策。该机器人表现得非常自信、格式规范且彬彬有礼。乘客们相信了它。法院随后判定航空公司应对这一虚假政策负责。与此同时,该聊天机器人的满意度评分可能还相当不错。

这就是隐式反馈陷阱。大多数团队用来衡量 AI 质量的信号——点赞评级、点击率、满意度评分——不仅充满噪点。它们还在衡量错误目标方面存在系统性偏见。而针对这些信号进行优化,只会让你的 AI 变得更糟。

预算有限下的偏好数据:无需研究团队即可捕获 RLHF 信号

· 阅读需 12 分钟
Tian Pan
Software Engineer

大多数尝试使用 RLHF 微调语言模型的团队在开始之前就放弃了。典型案例是 OpenAI 的 InstructGPT:33,000 个偏好对、13,000 个有监督演示、一个专门的外包团队,以及一个需要数周时间才能稳定的强化学习流水线。如果这就是门槛,那么大多数产品团队根本玩不起这个游戏。

他们错了。现在的门槛已经没那么高了。2024–2025 年的研究共识已经悄然改变:数据质量胜过数据量,DPO 完全取代了 RL 基础设施,而最有价值的偏好信号其实已经流经你的产品,只是未被记录。看起来是研究团队的问题,实际上是埋点(instrumentation)问题。

你的标注流水线才是 AI 产品的真正瓶颈

· 阅读需 12 分钟
Tian Pan
Software Engineer

每个开发 AI 产品的团队最终都会发布一个反馈组件。点赞、点踩、或者星级评分,又或者是修正字段。组件上线了,数据流转了,但随后几周甚至几个月,模型却没有任何改变——而团队仍然坚信他们拥有一个有效的反馈闭环。

组件只是简单的部分。其背后的标注流水线(annotation pipeline)才是 AI 产品真正陷入停滞的地方。

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

· 阅读需 11 分钟
Tian Pan
Software Engineer

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

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

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

阿谀奉承是生产环境中的可靠性失效,而非性格缺陷

· 阅读需 12 分钟
Tian Pan
Software Engineer

大多数团队将“谄媚 (Sycophancy)”视为一种 UX 上的烦恼——即模型过于频繁地吐出“好问题!”。这种定义极其片面且危险。谄媚是训练过程中产生的一种系统性准确性故障,在智能体系统中,它会在多轮对话中默默积累,直到一个错误的中间结论毒害了每一个依赖它的下游工具调用。2025 年 4 月发生的典型事件让这一点变得具象化:OpenAI 发布了一个 GPT-4o 更新,该更新支持了用户停止精神科药物治疗的计划,并验证了一个名为“棍子上的屎 (shit on a stick)”的商业想法,直到四天后触发回滚——此时已有 1.8 亿用户接触到了该版本。其根本原因并非提示词错误,而是在短期用户认可度上调整的奖励信号,这与长期准确性几乎完全负相关。

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

· 阅读需 14 分钟
Tian Pan
Software Engineer

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

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

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

对齐税:当安全调优损害你的生产 LLM

· 阅读需 11 分钟
Tian Pan
Software Engineer

你对模型进行了安全微调。评估套件显示它以 98% 的比率拒绝有害请求。然后你将它部署到生产环境,你的医疗文档助手开始对常规临床术语含糊其辞,你的法律研究工具拒绝总结涉及暴力的判例法,你的代码生成流水线给每个 shell 命令包裹了三层警告。完成率下降了 15%。用户满意度暴跌。模型更安全了——但也更没用了。

这就是对齐税:安全训练对语言模型施加的可衡量的任务性能退化。每个交付 LLM 驱动产品的团队都在支付这笔税,但大多数团队从未量化过它——更少有人知道如何在不牺牲所需安全属性的前提下降低它。

讨好税:过度顺从的 LLM 如何悄无声息地破坏生产环境中的 AI 系统

· 阅读需 11 分钟
Tian Pan
Software Engineer

2025 年 4 月,OpenAI 对 GPT-4o 进行了一次更新,却破坏了一些微妙但后果严重的东西。模型变得极其顺从。用户报告称,它会认可糟糕的计划,在受到轻微反驳时就推翻正确的立场,并在每个回答前对提问大加赞赏。这种行为过于夸张,以至于 OpenAI 在几天内就撤回了更新,称这是短期反馈信号覆盖了模型诚实性的案例。这一事件被广泛报道,但大多数团队忽略了这一点:这种顺从的程度虽然罕见,但其方向却并不寻常。

谄媚(Sycophancy)——RLHF 训练的模型倾向于优先考虑用户认可而非准确性——几乎存在于每一个生产环境的 LLM 部署中。一项对 ChatGPT-4o、Claude-Sonnet 和 Gemini-1.5-Pro 的评估研究发现,平均在 58% 的情况下会出现谄媚行为,且无论上下文如何,其持续率接近 79%。这不仅仅是几个极端情况下的 Bug。它是这些模型训练方式的一种结构性属性,并且在生产环境中以标准评测难以捕捉的方式显现。

为什么你的“点踩”数据在误导你:生产环境 AI 反馈循环中的选择偏差

· 阅读需 11 分钟
Tian Pan
Software Engineer

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

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