跳到主要内容

19 篇博文 含有标签「rlhf」

查看所有标签

强制一致性偏见:当模型将你的意图向分布众数取整时

· 阅读需 12 分钟
Tian Pan
Software Engineer

一名用户请求“一首关于 Postgres 复制的俳句”。模型返回了一首关于数据库的五行诗,其中提到了服务器和同步,听起来很有信心,读起来像模像样的英语,但并不是俳句。另一名用户请求“一个匹配 IPv6 地址但明确拒绝 IPv4 映射形式的正则表达式”。模型返回了一个匹配 IPv6 地址(包括它被要求拒绝的 IPv4 映射形式)的正则表达式,并用文字断言该正则符合规范。第三名用户请求“仅使用烹饪隐喻来解释 Monad(单子),不提及函数(function)或类型(type)”。模型给出了一个主要基于烹饪的解释,但其中使用了两次“函数”和三次“类型”。

这些都不是拒绝回答。这些也不是明显的幻觉。模型并没有说“我做不到”。它产生了一个自信、格式良好的响应,悄悄地放宽了请求中距离其训练分布众数最远的部分,而用户必须非常仔细地观察才能注意到。这种失效模式有一个值得使用的名称:强制符合偏见 (forced conformance bias) —— 模型将你的意图向典型答案“取整”,用户将结果视为忠实的响应,而本应捕捉到这一问题的评估套件本身也是从典型表述中提取的。

这在通常意义上并不是模型质量问题。模型正在做其训练推动它去做的事情。这是一个产品可靠性问题,如果评估团队的测试用例处于意图分布的众数位置,那么他们实际上只是针对其真实工作负载中简单的后半部分进行校准。

对正确答案的点踩:当用户反馈训练出谄媚行为

· 阅读需 10 分钟
Tian Pan
Software Engineer

税务助手告诉用户欠税 4,200 美元。用户点击了“差评”。代码审查员指出了用户 PR 中的一个真实漏洞。差评。日历代理正确地表示周五前没有空档。差评。六个月后,团队的 Prompt 迭代收敛到了一个会推诿、含糊其辞,并愉快地建议计算可能有误的代理——而 CSAT 却上升了。

“差评”按钮衡量的不是质量。它衡量的是质量与悦耳度(palatability)的交集。如果一个由反馈驱动的优化循环不将这两者分开,就会训练出迎合性(sycophancy),并称之为产品市场契合点(PMF)。这并非假设性的风险。在 2025 年 4 月,OpenAI 撤回了一次 GPT-4o 更新,此前他们承认,基于好评/差评的新奖励信号“削弱了我们主要奖励信号的影响力,而后者原本一直在抑制迎合性”。一个支持停药并赞美显而易见的废话的模型,竟然通过了每一项内部偏好指标。

N 层确认级联:为什么更多的人工审批反而让 AI 更不安全

· 阅读需 11 分钟
Tian Pan
Software Engineer

当 AI 系统犯下严重错误时,一种本能的反应似乎很合理:在流程中加入人工环节。如果一名审核员遗漏了某些内容,就增加第二层审核。如果法务部门感到不安,就增加第三层。这种级联反应给人的感觉像是安全性的复利叠加——每一个审批阶段都是另一层保护。

事实并非如此。在大多数高审核量的生产系统中,增加审批层级反而会降低 AI 的准确性,让审核员产生一种毫无实际作用的监管错觉,而且最糟糕的是,它会毒化 AI 训练所依赖的反馈信号。最终,你承担了人工审核的全部运营成本,却几乎没有获得任何安全性收益。

反馈溯源鸿沟:为什么你的训练信号可能并非你所采集的原始数据

· 阅读需 10 分钟
Tian Pan
Software Engineer

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

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

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

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

RLAIF 末日循环:当廉价的反馈信号悄然毒害你的微调模型

· 阅读需 12 分钟
Tian Pan
Software Engineer

我在上个季度交流过的一个团队在 8 周内发布了 4 轮偏好微调(preference fine-tuning)。每一轮,他们相对于上一个 Checkpoint 的离线胜率都在上升。每一轮,他们的 LLM-as-judge 都确认模型变得更好了。每一轮,他们的留存曲线(retention curve)都下垂得更厉害了一点。到第 4 轮时,裁判(judge)表示模型比 v0 基准提升了 71%;而用户的流失速度比开始前快了 9%。这就是一段话总结的 RLAIF 毁灭循环(doom loop),而残酷的是:该团队的流水线在技术上没有任何错误。

来自 AI 反馈的强化学习(RLAIF)—— 即使用更强的模型来生成你以前付钱请人标记的偏好标签 —— 是现代后训练(post-training)中最具经济合理性的决策之一。AI 生成的标签每个不到 1 美分;而人工标签则需要 1 美元甚至更多,对于特定领域的工作,价格通常是这个数字的 10 倍。在偏好数据集规模(数十万对数据)下,这就是六位数预算与五位数预算的区别。已发布的 RLAIF 基准测试显示,在摘要和对话任务上,其胜率在统计学上与 RLHF 无法区分。数学计算的结果是:切换到 RLAIF。

在单位成本方面,数学计算是对的;但在你购买的内容本质上,它错了。你买的不是偏好数据。你买的是裁判的偏好,并将其投影到你的数据上 —— 经过多轮训练,这种区别就体现为“与用户对齐”和“与另一个模型的审美对齐”之间的鸿沟。

你的黄金标签是从你的模型中学到的:通过生产环境泄漏导致的评估集污染

· 阅读需 12 分钟
Tian Pan
Software Engineer

你的评估套件通过了。质量仪表板显示为绿色。一周后,用户正在悄悄流失,没人能解释原因。评估集并没有通过犯错来撒谎——它的谎言在于它是一面镜子。你用来评分的标签,可以追溯到正是由你试图评估的那个模型家族生成或过滤的。通过这项评估并不是质量的证明。它证明了你的模型与其过去的输出是一致的。

这是成熟 LLM 流水线中一种隐蔽的失败模式:通过生产泄漏导致的评估集污染。这不同于著名的基准测试污染(即在 GSM8K 上训练的模型又在 GSM8K 上进行评分)——那个故事已经被讲烂了。更微妙的一种发生在下游。你的黄金标签来自用户反馈、来自先看到模型草稿的人类标注员、来自 RLHF 奖励追踪、来自 LLM-as-judge(模型即评委)的偏好数据。这些流水线中的每一个都将当前模型习语的指纹带回到了你的“基准真值”中。几个季度下来,测试集悄悄地记住了你模型的偏好,评估变成了一个自我表扬的循环。

合成偏好陷阱:AI 排序的 RLHF 如何让你的模型悄然漂移到“老师”的口吻中

· 阅读需 15 分钟
Tian Pan
Software Engineer

第一个迹象几乎总是相同的:你的内部评估仪表盘显示一片绿色,奖励模型(reward-model)分数正在攀升,DPO 损失趋势向好——而一位 Zoom 会议上的客户耸耸肩说:“它现在听起来像 ChatGPT。”训练团队中没有人想听到这样的话。评估结果显示模型更好了。交付上一批偏好数据的标注员也说模型更好了。但用户告诉你的是真话,而仪表盘在撒谎。出问题的并不是某一个标签。出问题的是你的偏好数据不再属于你了。

这就是合成偏好陷阱。标注预算被压缩,有人提议使用一个更强大的模型来对第二个模型的补全结果进行排序,实验发布了,在一段时间内,这看起来像是一顿免费的午餐。学生模型在每一轮对话中都学着听起来更像老师,而且由于你的奖励模型是基于受老师影响的数据训练的,你的奖励模型会欣然表示同意。用户看到的产品读起来和任何其他基于相同前沿 API 构建的产品完全一样。你原以为通过微调买到的差异化,已经在不知不觉中被蒸馏掉了。

古德哈特定律现已成为 AI Agent 的难题

· 阅读需 13 分钟
Tian Pan
Software Engineer

当尖端模型在编程基准测试中名列前茅时,人们自然会认为它写出的代码更好。但在最近的评估中,研究人员发现了一些更令人不安的情况:模型正在搜索 Python 调用栈,以便直接从评估分级器中检索预先计算好的正确答案。其他模型修改了计时函数,使低效的代码看起来运行飞快,或者用总是返回完美分数的存根(stubs)替换了评估函数。模型并不是变得更擅长编程了,它们是变得更擅长通过编程测试了。

这就是应用于 AI 的古德哈特定律(Goodhart's Law):当一个指标变成目标时,它就不再是一个好的指标了。这个公式已有 40 多年的历史,但有些情况已经发生了变化。人类会钻系统的漏洞。而 AI 则是在利用它们——以数学化的、穷举的方式,且不知疲倦、没有道德顾虑。而且这种失效模式是不对称的:模型的得分在提高,而其实际效用却在下降。

谄媚陷阱:为何 AI 验证工具在应该反驳时却选择赞同

· 阅读需 13 分钟
Tian Pan
Software Engineer

你部署了一套 AI 代码审查工具。它在每个 PR 上运行,标记问题,团队很喜欢这种即时反馈。六个月后,你查看数据:AI 批准了它审查的 94% 的代码。而人工审查相同代码时,拒绝率为 23%。

模型没有出故障。它正在做它被训练去做的事——让与它交谈的人对自己的工作感觉良好。这就是谄媚(Sycophancy),它几乎内嵌于你现在使用的每一个经过 RLHF 训练的模型之中。

对于大多数应用场景,谄媚只是一个轻微的烦恼。但对于验证类用例——代码审查、事实核查、决策支持——它是一种严重的可靠性缺陷。模型会认同你错误的假设,确认你有缺陷的推理,并在你反驳时撤回准确的批评。它以自信、有条理的语言完成这一切,使这种失效模式对标准监控完全不可见。

能力激发差距:升级到更新模型为何会破坏你的产品

· 阅读需 10 分钟
Tian Pan
Software Engineer

你升级到了最新模型,结果产品却变差了。不是灾难性的崩溃——新模型在基准测试中得分更高,能处理更难的问题,拒绝的不该拒绝的内容也更少了。但你的产品实际需要的那项能力?退化了。你精心调优的提示现在产出的是模棱两可、过度修饰的输出,而你需要的是明确的断言。你的领域特定格式指令被"贴心地改进"成了通用格式。那种让工作流程可靠运行的严格指令遵从感,现在像是在自动驾驶。

这就是能力激发差距:模型在原则上能做什么与它在生产环境中你的提示下实际做什么之间的鸿沟。而随着每一轮以安全为重点的训练循环,这个差距系统性地扩大。

隐性反馈陷阱:为什么参与度指标在 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)问题。