企业官网建设流程全解析

我最早对这个问题产生直觉，是在一遍遍跑数学推理微调实验的时候。同样是几万条题目，SFT 阶段把模型从 45% 教到 60% 附近就明显收敛变慢；后来改成让模型对着同一个问题多生成几个答案，再用规则校验对错，把结果送回 RL 训练循环，指标反而继续往前走。这个过程会给人一种很反直觉的感受：SFT 明明给每个 token 都提供了「标准答案」级别的监督，RL 一个完整回答只换回一个「对/错」的标量信号，信息量少得可怜，凭什么最后涨得更多？

这正是最近一篇以《How Can LLM RL Work Despite Information-Theoretic Inefficiency》为题的研究想要回答的问题：从信息论的角度，RL 的训练信号看起来明显低于 SFT 的 token 级监督，但大模型在数学、代码、Agent 任务上的大量实践又反复证明 RL 能带来 SFT 拿不到的效果。这篇文章不打算复述论文里的数学推导，而是想把这个矛盾讲透：为什么一个「信息上应该吃亏」的训练范式，在实际里却经常赢？如果你自己也在尝试 RL 微调或 Agent 策略优化，下面的解释方式和排查思路应该会比单纯跑一个库更有用。

我先给一个贯穿全文的判断：RL 能在大模型身上生效，不是因为它在每一步拿到了更多信息，而是因为它终于把优化目标换成了我们真正想要的那个目标。信息量少，不代表有效信息少。真正稀缺的从来不是数字化标注，而是一套能对「这段行为好不好」做出可靠判断的奖励信号。

1. 矛盾从哪来：RL 为什么在信息论上天生该吃亏

1.1 SFT 给的监督，看起来比 RL 多得多

先看 SFT 的监督形式。对一个输入问题，你手里有一份人类写好的回答，训练时每个位置都有一个明确的目标 token。如果问题有 500 个 token，对应的回答也有 500 个 token，那么这一条样本就提供了大约 500 维的局部监督。模型要做的比较单纯：给定前文，尽量预测下一个 token，让它和标准答案一致。

RL 的监督形式则完全不同。常见做法里，模型针对一个 prompt 生成完整回答，然后由一个外部评价机制给出分数。这个分数可以来自单元测试、数学答案比对、规则判断，也可以是训练好的奖励模型。信号密度通常就是一条回答对应一个标量，甚至只是一个 0/1 的通过标记。在 REINFORCE 这类策略梯度方法里，你还得用整条轨迹的概率和这个标量去估梯度，方差天然就大。

如果严格按信息论的视角算账，SFT 的 token 级标签显然携带了更多信息。把回答长度乘上词表对应的信息量，一次 SFT 样本能低熵地约束很多位置的预测分布；而 RL 的一条轨迹无论多长，最后通常只回传一两个字节。单看信号量，RL 确实处于明显劣势。

1.2 于是你得到一个看似必然的结论：RL 应该跑不动

顺着这个思路往下推，你会得出一个很悲观的结论：RL 需要海量交互才能学到 SFT 一部分样本学到的内容，所以它在大语言模型上要么是一种计算浪费，要么只能在极小场景里有点用。

但现实显然不是这样。过去几年，数学推理、代码生成、工具调用甚至多步 Agent 任务里，多个公开工作都展示了 RL 或类似 RL 的搜索优化流程，能够在 SFT 基础上继续产生可观的提升。这些任务里使用的奖励往往还特别朴素：数学题看最终答案是否匹配，代码题看单元测试是否全部通过。你说它信息量低，它每一步确实低；你说它没用，实验数据又不同意。

这逼着我们去重新审视一个问题：一个训练范式拿到多少信息，和它能不能优化出更好的策略，中间还隔着「这份信息里到底有多少有效信息」。SFT 的标签密度高，但标签描述的行为不一定是最优行为；RL 的奖励稀疏，但它一步直接指向你真正关心的结果。这两者一旦打上擂台，信息量的原始差距反而没有那么决定性。

1.3 信息论的结论没有错，错的是套用场景

信息论本身不会因为实验现象而失效。它真正说的是：如果你想通过有限的反馈去还原一个复杂分布，那么反馈的比特数会决定你需要的样本量下限。但大模型 RL 的目的一般不是「还原人类回答的完整分布」，而是「找到一个期望奖励更高的策略分布」。这两个目标对信息的需求完全不同。

如果你要还原 SFT 数据集背后的完整条件分布，那 RL 用一个标量奖励肯定还原不了。但如果你只需要把策略往「更容易得高分」的方向推，那一个标量其实可能足够。这就像考试：老师不告诉你每道题的完整解法，只告诉你卷子最终得了几分，你也能通过不断尝试判断哪些做题策略更可能拿高分。你获得的原始信息很少，但有效信息很集中。

这也是为什么我们不能看到标题里有 information-theoretic inefficiency，就把它理解成「RL 注定不行」。更接近实际情况的理解是：正是因为 LLM RL 的学习目标不是建模人类回答，而是优化一种可测量的结果，它才能在稀疏反馈下走出和 SFT 不一样的路。

2. 稀疏奖励能工作的核心：目标变了，机制也变了

2.1 SFT 学的是「别人怎么答」，RL 学的是「什么回答会被判高分」

SFT 的本质是模仿。数据里的一条回答即使不是最优解，只要措辞通顺、过程合理，它就会被当作正样本，模型对它的概率就会被抬高。更麻烦的是，如果数据里没有出现过某种更高效的推理模式，模型就几乎没有机会自发形成这种模式，因为 MLE 训练只会让模型贴近已有样本，而不是主动寻找一种比样本更好的回答。

RL 不是这样。策略梯度公式里，更新方向不是「让模型更像某条示范」，而是「让高奖励轨迹的概率上升，让低奖励轨迹的概率下降」。这给模型留出了一个空间：只要某条自己生成的新轨迹能拿到更高的外部分数，它就有机会被放大。

这解释了为什么 RL 经常能在 SFT 已经收敛的任务上继续提升：SFT 已经把模型带到「会做」的附近，但它不一定知道哪些解题路径更好；RL 则让模型自己去试探，凡是能通过外部验证的路径，就在策略分布里获得更高权重。

2.2 一个标量奖励，不是用来描述 token，而是用来区分轨迹

前面说了，SFT 用一整个标准回答来约束策略分布，RL 只给一个标量。这个差距如果放到「逐 token 回归」的框架里，确实是致命的。可 RL 实际上不是拿标量去预测每个 token 该是什么，而是拿它给每条完整轨迹打标签。

打个比方：如果某个问题模型生成了 8 条不同回答，校验器判其中 2 条正确、6 条错误。正确和错误轨迹之间可能存在明显的策略分布差异：有的是用到了某种中间推导，有的是因为某类错误重复出现。即使训练信号只有一个对/错，模型也能在这两类轨迹之间找到分界，并把概率质量向正确一侧移动。

关键结论是：奖励虽然稀疏，但它在「高奖励轨迹集合」和「低奖励轨迹集合」之间创造了足够的判别信息。它不需要告诉你每一条路径里每个 token 为什么对、为什么错，只需要让模型知道哪些完整路径更值得学习。

2.3 但这也意味着：RL 并不是一个免费的万灵药

如果奖励判断本身不可靠，那么 RL 从高奖励轨迹里学到的东西也会随之扭曲。试想一个场景：校验器因为代码解析 bug 把所有带某种注释格式的回答判成错误，模型会很快学会规避这类注释，即使这些注释本身对结果没有影响。你的训练 reward 一路飙升，真实评估却没有任何提升，甚至下降。

这就是从一开始就需要记住的边界。信息量低不可怕，噪声高才可怕。RL 能工作的前提，是那条看似稀疏的奖励信号，在判别好坏轨迹这件事上足够可靠。当奖励不可靠时，RL 会非常高效地学到错误行为。这一点后面会专门展开。

3. 实践中真正让 RL 跑起来的四块垫脚石

3.1 预训练模型不是从零出发，随机搜索也有先验优势

讨论信息论效率时，很多人默认模型从一个完全随机的策略开始学习。但大模型 RL 的起点是已经经过预训练和 SFT 的模型，它本身已经能生成不少正确的解题步骤。

如果把 RL 看作一种「在模型自身分布附近搜索」的过程，你会发现它的样本质量并不低。同一个难题，让模型采样 16 次，即使最终准确率不高，也往往能撞出至少一两条正确路径。RL 要做的不是从混沌中发明正确推理，而是识别出这些散落在尾部的高质量样本，并提高它们的概率。这让每条采样轨迹的有效信息远高于从零学习的假设。

这也是为什么在数学和代码任务上，RL 的效果通常比开放域对话更明显：任务有明确校验规则，模型又已经具备一定能力，搜索空间相对集中，采样和筛选的闭环很容易建立。

3.2 KL 惩罚其实是 token 级的约束，不是只有标量信号

很多人以为 RLHF 或 RL 训练里只有奖励模型给的一个分数，其他什么监督都没有。这是对训练目标的简化。真正进入训练时，目标函数里通常会包含一个和参考模型之间的 KL 惩罚项，而且它是逐 token 计算的。

参考模型通常是 SFT 阶段得到的模型。每次策略更新时，KL 惩罚会约束当前模型不要偏离参考模型太远，从而保留语言质量和稳定性。这项约束在每个 token 位置都存在，它其实给 RL 目标补充了大量 token 级的结构性信息：哪些话不能乱说、哪些表达要稳定、哪些概率分布不能剧烈改动。

所以严格说，LLM RL 并不是只用了一个序列级标量来做监督。它在整体目标里混合了一个结果级奖励信号和一组 token 级 KL 约束。这个混合设计，让它在稀疏奖励的大方向下，仍然保留了很多局部稳定性。单看 reward 那部分确实信息量低，但训练目标整体并不低。

3.3 多次采样和批量内对比，把「绝对分数」变成「相对优势」

如果你只对一个 prompt 采样一次，然后拿一个奖励值去直接更新，梯度方差会非常大，模型很难学到稳定信号。实践中通常会对同一个 prompt 采样多个回答，计算这一组回答的奖励均值和标准差，再用归一化后的优势去更新。

这类做法本质上是在批量内部做对比：同一条问题下，哪些回答相对更好，哪些相对更差。一个标量奖励单独看可能受噪声影响，但放在同一批样本里做相对比较，噪声会被抵消一部分。这也是 GRPO 等无 critic 方法能稳定工作的原因之一：奖励模型不再需要为每个状态预测一个绝对价值，只需要在一个 prompt 的多个 rollout 之间排出相对高低。

这同样解释了为什么 RL 训练时 rollout 数量、温度、prompt 分布会影响效果。它们共同决定了批量内的样本质量和对比难度。如果一个 prompt 下采样的回答全都正确或全都错误，批量内就没有可分性，策略更新接近于空转。

3.4 过程奖励模型可以补密度，但真正的瓶颈还是校验质量

当任务很长、结果奖励过于稀疏时，人们会引入 process reward model，让模型对每一步推理给出过程分数，或者用搜索算法在推理树上做前瞻验证。从信息论角度看，PRM 本质上是在把稀疏的结果标签扩展成更多中间判断，增加反馈密度。

但这个过程并不免费。训练 PRM 需要大量的过程标注或自动标记策略，而且一旦过程分数不准确，它会引入比结果分数更细微的噪声。与其说 PRM 是解决信息量不足的唯一手段，不如说它是一种在结果奖励和过程细节之间做折中的工程选择。很多团队在早期阶段先用结果奖励跑通流程，发现收益停滞以后再引入过程级信号，这个顺序是更稳妥的。

注意：如果某个任务的结果校验本身都不稳定，不建议急着训练 PRM，因为过程监督只会把结果层的噪声进一步传递到每一步。

4. 从论文标题到工程决策：什么时候才真正值得上 LLM RL

4.1 先问自己四个问题，而不是先找算法库

RL 的算力成本不低。想清楚该不该上，比选哪个算法更重要。我一般建议用四个问题做筛选，如果有一个回答是否定，就先别急着跑训练。

1. 你能不能给一个完整回答打出一个可靠分数？
2. 这个分数是否能覆盖你真正关心的业务指标？
3. 你的基线模型是否已经具备一定完成任务的能力？
4. 你是否有一个独立于训练奖励的评估集？

第一个问题最关键。分数可以是最终答案匹配、单元测试通过率、工具执行后的状态，也可以是训练好的奖励模型，但必须稳定可复现。如果打分的判断标准连你自己都容易产生分歧，模型会学到更多噪声，而不是能力。

第二个问题容易被忽略。RL 优化的是训练时使用的奖励，不是你的主观业务目标。如果你给代码模型自定义了一个「更偏向输出长注释」的分数，它就会学到写长注释，而不是让测试通过。奖励一旦没有对齐目标，RL 的效率越高，错误方向走得越远。

第三个问题决定了 RL 有没有杠杆。预训练加 SFT 后的模型如果连低难度样本都解不好，直接上 RL 会得到大量低质量 rollout，有效信息被噪声淹没。先确保模型在 pass@1 上有基本完成率，再用 RL 去提升，通常更可靠。

第四个问题是长期维护的护栏。训练 reward 会在训练集上持续上升，但独立评估集能告诉你它是否真的泛化。很多人只在训练 loss 变得难看时才去检查，很容易错过奖励过优化导致的隐性崩坏。

4.2 SFT、DPO、RLHF、Verifier RL 不是一个东西，别混用

LLM RL 这个大词下面其实藏着好几条路线。它们的信号来源不同、成本结构不同、适用边界也不同。放在一张表里会清楚很多。

我见过的不少团队在还没有可靠验证器时，就先上了 RLHF 风格的方法，结果奖励模型本身不够准，后期又在不停修 reward 模型。如果是数学、代码、结构化任务，我更建议先做可验证奖励，因为它的信号边界最清楚，信息量虽少却很少撒谎。

4.3 真正稀缺的不是标注，而是可验证的交互环境

从这篇文章标题引出的思考，其实能延伸到更远的工程选型。LLM RL 能不能发挥价值，很大程度上不取决于你有多少人力去标注数据，而取决于你能不能造出一个低成本、高可靠的外部评价环境。

比如代码任务里的单元测试、数学任务里的答案校验、数据库任务里的查询结果比对、Agent 任务里工具执行后的状态检查。这些环境一旦搭好，模型可以无限生成尝试并得到反馈，RL 的信息瓶颈就从「人类标注太贵」变成「机器采样够便宜」。反过来，如果任务只能靠人读回答打分，且打出来的分还不稳定，那 RL 就很容易变成又贵又不稳定的事。

这也是 Agent 场景最近特别热的原因之一。Agent 的任务天然有环境交互，每一步都可能触发工具反馈，最终结果也能被检查。这种环境让 RL 的稀疏奖励不再稀疏，因为每一步工具执行结果都在提供额外信号。但要注意，Agent 任务是长序列决策，同样一个问题里可能经历十几个内部步骤，过程更长意味着单次 rollout 成本更高，信号归因更难，不是简单代跑一个训练脚本就能搞定。

5. 落地最容易翻车的地方与排查链路

5.1 五个常见失败迹象，不要全怪算法

RL 训练跑崩了，很多人的第一反应是换算法，但大部分问题出在奖励、采样和评估上。常见的现象和可能的根因可以这样对应：

5.2 一套通用的排查顺序

如果 RL 训练没有按预期提升，我习惯按下面的顺序排查，而不是一上来就调学习率。

1. 先验证奖励信号本身。找一批固定的模型回答样本，人工判断每个样本该得多少分，再和验证器实际给出的分数对比。如果这里已经有一致性问题，后面所有训练都不可信。
2. 再看采样质量。把训练中采样的回答打印出来人工看几组，确认它们不是全对也不是全错，并且质量在模型正常能力范围内。
3. 然后看 KL 和策略分布。KL 惩罚如果让模型几乎贴住参考模型，那 RL 实际推进力很弱；如果 KL 很高但 reward 不升，说明奖励判别力不够。
4. 接着看优势归一化。同一个 prompt 下多条回答的奖励差异是否合理，批量大小是否足够做稳定对比。
5. 最后才动训练参数。学习率、KL 系数、 rollout 次数都只在前四步没问题的情况下才值得调。

注意：不要只盯着训练平均 reward。真正能说明问题的指标是独立评测集上的 pass@k 或任务完成率，建议每隔固定步数跑一次完整评测。

5.3 一个适合起步的最小验证流程

如果你第一次尝试 LLM RL，不要一上来就跑一个庞大的 70B 模型或超大 rollout 规模。我建议先按下面这套最小流程跑通一次：

1. 选择一个有确定性校验器的任务，比如代码单测或数学答案校验。
2. 准备 1000 到 5000 条 prompt 作为训练集，另留一个独立评测集。
3. 先算 pass@1 和 pass@8 基线：每次让模型采样多个答案，看至少一条正确的比例。pass@8 应该明显高于 pass@1，否则 RL 的搜索空间里没有足够正样本可供学习。
4. 用策略梯度方法做小规模迭代，先验证 reward 能否正常区分正确和错误回答。
5. 每轮训练后都做一次独立评测，并记录 KL 值和生成样例。

这个流程的核心价值是让你先确认「奖励可判别、采样有正样本、更新稳定」这三件事。只有这三件事同时成立，扩大训练规模和算力才是有意义的。

如果动手时缺少完整的工程代码，可以直接用一个很简化的流程来理解：

# 伪代码，仅用于表达核心训练循环 for prompt_batch in dataloader: responses = policy.sample(prompt_batch, temperature=0.7, num_samples=8) rewards = verifier.score(prompt_batch, responses) # 例如单元测试通过率 # 在同一个 prompt 的多个回答之间做相对比较 advantages = normalize(rewards - group_mean(rewards)) # 更新策略，并用 KL 惩罚限制偏离参考模型 loss = -log_prob(responses) * advantages + kl_coef * kl(policy, ref_policy) optimizer.step(loss)

这段代码不是可直接用的生产实现，但它能帮助你理解：真正推动模型变化的不是某个绝对分数，而是「同一个问题下，哪些回答比其他回答更好」。奖励信号只需要把相对好坏表达出来，策略梯度就能把它转化成概率调整。

5.4 什么时候该果断放弃 RL，只用采样和过滤

还有一种经常被忽略的情况：如果任务的校验器很可靠，但你的预算只支持有限几次 rollout，那么用 reject sampling 或 best-of-n 可能会比完整 RL 更划算。

原因是 RL 需要反复更新策略并重新采样，整个循环成本很高。如果单纯从同一个模型里采样 64 个答案，用验证器挑一条最好的，在很多任务上已经能获得显著提升。只有当你想让模型自身学会生成更好答案，而不是依赖部署时大量采样时，才需要把这个问题转成策略优化，用 RL 去更新模型。

这个边界值得在项目一开始就确认清楚：你的目标是「这一次输出更准」，还是「模型本身变强」。前者可以用推理时采样解决，后者才需要 RL。误把场景选成 RL，往往会付出很大算力成本，最后效果却和一个采样器没拉开差距。

6. 如果再把这个问题说透一点，答案是什么

回到标题里那个看似矛盾的问题：LLM RL 为什么能在这么明显的信息论劣势下工作？

我的理解是，信息论约束的是「用有限反馈还原完整分布」这一类任务。LLM RL 真正做的其实是另一件事：在一个已经有很强先验的策略分布附近，找到能带来更高奖励的方向。这个方向不需要所有 token 都得到详细标注，只需要奖励信号能把「更可能成功的轨迹」和「更可能失败的轨迹」区分开来。

在这个过程中，预训练提供了起点，KL 惩罚提供了稳定边界，多次采样提供了批量内对比，可靠验证器提供了最关键的目标信号。四个机制合在一起，让序列级标量奖励虽然稀疏，却不至于无效。这也意味着，RL 的效果上限最终取决于奖励信号能不能真实代表你想要的最终结果。奖励可靠，稀疏也可以很强；奖励失真，再密集也只会把模型带进坑里。

所以如果你正在犹豫要不要给自己手里的模型加 RL，我给你的建议不是先问「用什么算法」，而是先问另一个问题：我能不能写出一个至少在 90% 情况下判断正确、并且不会被我轻而易举绕过的奖励函数？如果答案是可以，你可以放心地把 RL 列入路线图。如果现在还没有，那先别急着调训练脚本，把奖励的边界、验证器的逻辑、评估集的建设先想清楚。这个前期工作，才是整个 LLM RL 流程里真正决定成败的一环。

当越来越多任务都能用模拟器、测试集、工具反馈来自动打分时，RL 的适用范围还会继续扩大。到那个时候，回看这篇文章讨论的「信息论劣势」，你可能会有更直接的体会：一种信号只要有足够清晰的方向感，哪怕每次只带一点点信息，也足够让一个聪明的模型走很远了。