从分布对齐说起:拒绝采样在训练里到底做了什么
拒绝采样本身是个很老的蒙特卡洛方法:目标分布 p(x) 不好直接采,就找一个容易采的提议分布 q(x),再用接受率把样本筛到符合 p(x) 的形状。放到微调场景里,流程变成:拿一个已经 SFT 过或者更早版本的模型,对同一条 prompt 采 K 个输出,再用一个接受函数(奖励模型或启发式规则)挑出分数够高的,把这些输出当作新的训练数据回炉做监督微调。这条路径通常叫 RFT(Rejection Sampling Fine-Tuning)。
它和 PPO 的区别不只是“一个 on-policy、一个 off-policy”。Llama 2 的论文里写得很直白:对每条 prompt,拒绝采样会采样 K 个候选,取出奖励最高的那个作为新的 gold standard,再做梯度更新;PPO 只有一条生成。这个描述里已经埋下了工程账的关键——Breadth 换深度。你用了 K 倍的推理算力,换来一次离线、稳定的更新,不需要在这一步维持新旧策略的分布约束。
K 越大越好这句话,只说对了一半
火山引擎那篇整理里有一句结论:样本 K 越大越好。从统计上看,这没错,K 越大,最高奖励那一条的质量越可能贴着理想分布。但真正上线时,K 的成本曲线比较陡峭。
K=4、16、64 是几个常见的档位。WebGPT 在推理阶段就试过 4、16、64 这几个值,用的是从 BC 模型或 RL 模型里采的答案,再用奖励模型挑一条。它明确是把更多推理时算力换效果,并谈到了拒绝采样和 RL 在同样奖励模型下的比较——一个被认可的理由,是拒绝采样不需要调那么多强化学习的超参,行为更稳。Baichuan/HH 那类工作里更常用的 K 是 16。
工程上的困惑在于:如果接受率低,理论上的“最高分”其实可能是评分的虚高。奖励模型和生成模型在同一条候选集上做最优挑选,挑得越多,越会薅奖励模型的边角。K 从 16 涨到 64,数据量的推理成本变成 4 倍,但你拿到的事情要么是接受率仍然不够、要么是分数上去了语义多样性下来了。后者更隐蔽:推理模型在同一个 prompt 下多采几条,长思维链路径往往是最短的那条最容易拿高分,但如果以后训练数据全变成相似的推理捷径,就有点得不偿失。
采得多是一种结果,能接受多少是另一个账本。真正要监控的是接受率随 K 变化的曲线,而非单独的 K 值。
接受函数用什么来判断“值得留”
接受函数这里有两个方向。一是奖励模型打分:Llama 2 论文就是用 RM 分数从候选里选最高,并顺带把被选中的样本拿去在旧 checkpoint 上重新训练 RM,强化奖励模型的效果。二是有明确 ground truth 的任务——数学、代跑得过的代码——可以跳过 RM,直接在验证器上判对错,留通过的样本回炉。这两种在推理模型上的取舍不同:奖励模型省事,代价是奖励砍伐;验证器覆盖率有限但信号更干净。
给出理由的话,前提选择更偏向可达、低误差的信号。只要你先有一个稳定的验证器,就不要急着先训测试。即使用推理路径作为任务类型主信号的粗验证器,也比一件尚未闭环经过检验的 RM 轻易用于大规模数据筛选要好。把不清的 acceptance 原样用到下游,会打坏全线上量数据的一致性。
COT 路径:RFT 和普通 SFT 最大的差别
普通 SFT 的监督信号就是最终答案那一串 token。拒绝采样在推理模型里多了一件事:保留一条被通过的推理路径。对同一条 prompt 采样时,能出对的路径可能不止一条,打分后保留下来的候选在被用作训练数据时,模型学到的不只是分布,还包含若干种通过理由的变形。火山引擎文章引用的判断,就是拒绝采样能为模型提供更多推理路径供学习。
不过这背后有个与数据标注有关的问题:思维链最后一步对了,不完全等于过程可信。长推理链上局部推错的步骤会被答案最终算对这件事掩盖。若接受函数只看答案,就很可能让一个中间并无实质性可靠的样本通过。只根据最终答案粗略参考打干净了 COT 会是什么效果,目前其实很难给出统一回答。我自己的规程是:保存推理结果前,先单独构建过程审计和结果打分两条通道;过程审计可以粗,但漏掉的部分要把引用改成只保留自洽链。
和强化学习的实际分工
线上复杂问题大部分不在“用不用”这一层,而在哪一步用它。一种较多见的做法是迭代式,不复只做一次 RFT:先以 SFT 模型采样一批做拒绝采样,微调出新 checkpoint;再用新 checkpoint 采一批,再接新一轮 SFT 或者进入 PPO。这跟强化学基础中的判断基本一致——靠精确说明不会形成鲜明优势,不发挥深入实现所表现的那些差别,在此条件下拒绝采样是合理而稳定的预训练步骤的竞争者。
需要提醒成本的几个代价:第一,奖励模型本身会漂移,旧 RM 对新模型的输出给分可能越发失真;第二,对推理模型来说,采样出的 COT 很长,做 RFT 时如果原样拼回上下文窗口,一条样本可能吃掉很多 token,批处理吞吐也跟着掉;还有评测集里的全量样出 OOM、超长文档路径被截断,这些数据侧的问题会先于训练时被真正注意到。对采样路径做长度采样、按固定档保留,未必是因为预算少得没法接受,更像是为了保证推理链不长度都覆盖到而做的有意裁剪。
转载请注明出处: 皮哈皮阿
本文的链接地址: https://blog.phpat.com/ai-dev/652.html
微信或手机浏览器扫一扫,随时随地随心阅读与分享
-
上下文工程:从 Prompt 到 Context 的工程化实践
客服 Agent 答错时,团队第一反应是换模型。把那次请求的上下文打印出来才发现,模型看到的是一份过期政策、两份互相矛盾的条款,还有一长串无关日志。上下文工程要解决的,就是这类问题。
2026/10/06
-
RAG 的下一站:Agentic Retrieval
用户问“我们去年买的套餐现在还能退吗”,经典 RAG 检索出一段通用退款政策就结束了。可这个问题至少要拆成订单时间、地区、套餐版本三件事。Agentic Retrieval 要解决的,就是这种“一次检索不够用”的场景。
2026/10/12
-
约束解码让 JSON 不再崩,但它会改坏推理
约束解码让 JSON 解析失败率归零,工程师可以删掉一堆重试和修复代码。但它会挤占模型的推理预算:强制格式在部分任务上带来10%以上的准确率下降。文章梳理 OpenAI、Anthropic、Gemini 和其他自托管引擎的现状,以及 schema 设计、两阶段模式与编译缓存几个实操要点。
2026/10/22
-
Agent 上下文压缩:四层策略与失败代价
把 Claude Code 的四段分层与 Hermes Agent 的双阈值压缩系统并排看重:200K 窗口下的 50%/85%、legacy 与 lean 尾部的实测差池、未处理到的摘要模型窗口溢出,以及工具对配对边界为什么是能不能跑的问题。
2026/10/23
-
推理模型输出被截断后怎么接回去
推理模型遇到输出截断,重试整条请求代价高;续写也有隐藏门槛。从识别边界、提示回灌到 prefill 与成本判断,聊聊工程上怎么做才不算亏。
2026/10/25
-
推理模型的并行思维链采样怎么用才不亏
并行思维链采样的成本不是白花的。结合推理模型测试时计算的几条实证结论,梳理best-of-N、束搜索、自洽性投票和自我修订在什么场景下划算、什么场景下只是在烧钱。
2026/10/26
京公网安备11011402053654 
@muffin:链接已更新,分类图像功能...
AI网址导航模版图标库更换指南
作者大大,图标库邀请链接失效了,麻烦更新...
AI网址导航模版图标库更换指南
太好看了,快点更新!
友情链接
@戴墨镜的刘备:哈喽,路过点赞。
vue.js组件之手写签名板vue-signature-simple
太好看了,快点更新!太棒了!👍真的很赞!
vue.js组件之手写签名板vue-signature-simple
你写得非常清晰明了,让我很容易理解你的观...
Emlog插件RSS订阅器发布