LLM 和 RL 的组合在训练阶段总会遇到一个看似矛盾的现象。信息论视角认为强化学习在语言模型上的效率很差因为 token 序列组成的动作空间几乎是指数级增长而一个 episode 的最终奖励往往只有一个标量。真实项目里无论是 RLHF基于人类反馈的强化学习还是带思维链的推理 RL都能在有限的计算预算内把模型能力推进一个台阶。这篇文章只围绕一个核心问题展开在“信息论低效”的理论印象和“工程上有效”的客观事实之间到底缺了哪一块拼图又该怎么把这种认识落到训练代码、参数配置和排错流程中。1. 信息论低效到底指什么并不是“RL 没用”1.1 组合爆炸让严格随机探索几乎不可能先定义一个基本模型。语言模型在给定输入 x 时会条件生成一段文本而这段文本可以表示为一个 token 序列 a1, a2, ..., aL。如果分词表大小是 |V|序列长度是 L在不考虑任何语义约束的情况下可能的序列数量约为|V|^L即使一个分表只有 5 万词的模型只生成 50 个 token这个空间也已经远远超过任何强化学习算法可以在有限样本内遍历的范围。信息论低效最直接的表现就在这一点动作空间太大而奖励信号太少。如果策略从零开始靠采样来发现“哪些序列能获得正奖励”绝大多数采样都会落在错误区域样本复杂度会高到无法接受。但这里要区分两个概念。“信息论低效”描述的是一个最坏情况下的样本复杂度问题并不等价于“LLM RL 不可能有效”。后文会详细说明LLM RL 通常并不面对这样一个最坏情况问题因为它的初始化策略和奖励结构已经非常特殊。1.2 三条信息瓶颈探索、奖励、分布可以用一张表来概括信息论视角下 LLM RL 的三个显著瓶颈。瓶颈含义在 LLM RL 中的表现探索瓶颈最优动作在采样空间中占比极小随机生成的句子大多不是正确答案奖励瓶颈一个 episode 只返回一个标量只能看到整句对错难以定位错误 token分布瓶颈训练时希望策略不偏离参考模型KL 预算限制一次更新能注入的信息量这三条都是真实存在的约束。但注意它们的适用范围探索瓶颈只有在“起始策略完全不知道任务”时才致命。如果初始化策略已经接近正确答案遍历整个空间并不是必要条件。奖励瓶颈只有在“最终奖励无法拆解”时才严重。如果可以对中间步骤或 token 给出奖励信用分配就会被细化。分布瓶颈限制了单次更新注入的信息量但如果初始策略已经吸收了大量先验知识那么 RL 需要补足的信息量自然就少了。信息论低效描述的是理论边界它并不否定实际可行性。真正的问题应该是LLM RL 的实际样本从哪里来为什么这些样本足以支撑训练。1.3 一个容易误解的点策略梯度不是随机搜索有人会在看到组合爆炸后认为“RL 完全没有希望”。这种判断忽略了一个事实策略梯度不是在空间中随机采样后暴力筛选答案。策略梯度会沿着“让优势函数更大的方向”更新参数本质上是一种带学习率的局部搜索。局部搜索的效率和起始点高度相关。如果策略已经落在目标邻域几十条样本就能给出可信的梯度方向如果策略离目标很远需要大量样本才能找到可信方向。信息论低效描述的是后者的代价而 LLM RL 恰恰把问题转化成了前者。2. 它为什么在实际训练中可行先验、密集奖励、语言规则性2.1 先验策略把搜索范围压缩成了局部修补严格信息论分析通常假设策略一开始并不知道任务。但 LLM RL 的起手式完全不同。策略初始化自一个经过大规模预训练、甚至经过指令微调的模型它对大多数任务的分布已经有一定建模能力。RL 要做的不是从零学习一个完整动作空间而是在这个已经接近任务分布的初始化策略上修出局部梯度。可以把它理解成搜索半径问题。实际训练中很多失败不再是“完全不会”而是模型知道要写计算过程却不会在最终答案前输出“最终结果”标记模型知道要调用工具却不会正确拼接工具参数模型知道要逐步推理却中途截断没有输出最终结论。这些错误对应的是很低的错误维度。RL 只需要提高成功分支对应的条件概率不需要覆盖全部 token 序列。预训练模型在这里相当于提供了先验分布RL 只是在先验分布附近做偏好偏移。Karpathy 的 LLM wiki 等项目在整理这类经验时常提到同一个观点现代 LLM 训练中RL 的作用不是教模型一门新语言而是让模型学会把已经存在的知识在给定场景下表达出来。很多知识在预训练阶段已经进入参数只是默认解码路径不会优先选择它。RL 通过奖励信号调整这种选择优先级。2.2 把标量奖励拆成 token 级和过程级奖励最终奖励是稀疏信号如果只能拿到整段文本最后的一个对错标记那么前一时刻的行动到底应不应该被强化模型很难判断。但如果能把奖励分解到中间步骤信用分配就会变得具体得多。用一段简单的文本公式表示无过程奖励 R(τ) r_final 有过程奖励 R(τ) Σ_{t1}^{T} r_t过程奖励在数学、代码、SQL、工具调用等可自动检查的场景里尤其有效。比如代码生成任务可以通过单元测试判断每段子程序是否通过数学题任务可以检查每个中间等式是否成立。只要这种中间信号存在RL 就不是在输入整句后盲目更新所有 token 的概率而是按照时间轴逐段分配奖励。表格对比一下结果奖励和过程奖励监督类型奖励粒度信用分配能力实现成本最终结果奖励一个 episode 一个标量只能整体判断对错便宜但信号稀疏过程奖励每个中间步骤或 token 一个信号可以定位失误步骤需要验证器或专门模型成本高偏好模型奖励一条偏好比较结果介于二者之间需要 RM 训练噪声较大当奖励无法自动验证时常见做法是训练一个 reward model让它预测整段文本的得分。但 RM 的输出本身是从人类偏好数据中学习出来的存在偏差。奖励越模糊RL 的低效问题就越明显奖励越可验证、越细粒度信息论低效带来的负面影响就越小。2.3 语言结构本身承担了降维作用语言不是没有规则的高维离散点集。一个模型生成的 token 序列在语义空间中往往落在一条低维流形上。正确使用工具、正确写结尾、正确使用括号这些都是可复用的局部模式。信息论低效计算的是一句话被当成高维离散点的复杂度但语言模型的向量表示把这些离散点组织成了有结构的空间。在语义空间中移动几个 token 的偏移就可以影响一大批表达方式。这意味着 RL 的有效探索维度远低于表面上的 |V| 的 L 次方这是语言作为行动空间的隐藏优势。一个人写代码时并不是枚举所有字符组合而是遵守类型、语法、API 惯例。语言模型同样在 token 分布中吸收了这些惯例。RL 真正需要学习的通常只是少量关键分支的调整而不是整个序列的重新排列。3. 从 RLHF 到推理 RL不同信号下的实际生效机制3.1 RLHF用偏好信号替代真正的奖励要在通用对话场景中应用 RL第一个困难是没有真正的环境奖励。于是 RLHF 的做法是训练一个奖励模型来逼近人类偏好。流程大致分为四步用 SFT 模型生成多个回答人工或自动标注偏好对用偏好对训练 RM用 PPO 或 GRPO 优化策略目标函数里加入对参考模型的 KL 惩罚。RLHF 在信息论上也是一种“稀释放大”的过程人类偏好数据本身昂贵RM 只能从有限标注中学习。但它的效率来自于两点偏好数据不需要精确打分只需要两两排序标注成本得到控制RM 可以将偏好信号泛化到 SFT 模型未直接训练过的输入上。这并不意味着 RLHF 不会出问题。RM 一旦在某个区域产生幻觉性高分策略就会往这个区域集中出现奖励黑客行为。所以现实中经常要求对 RLHF 后的模型做第二轮人工评估而不是只看 RM 分数。3.2 GRPO去掉 Critic 的代价与收益PPO 在 RLHF 中是主流选择之一但它需要训练一个 Critic 网络来估计状态价值函数。这个 Critic 在语言任务上很大训练成本高而且价值估计不准时梯度噪声会很大。GRPO 的做法是不训练 Critic而是在一组采样响应内部对奖励做标准化用组内相对优势代替绝对价值。核心更新可以缩写成这样normalized_reward (r - mean(group_r)) / (std(group_r) eps) advantage normalized_reward loss -mean(log_pi * advantage) beta * kl其中r是当前样本的奖励mean(group_r)和std(group_r)是同一 batch 内所有采样响应的奖励均值与标准差log_pi是当前策略对生成序列的对数概率beta * kl用来惩罚策略偏离参考模型的程度。这段代码的作用不是真正训练网络而是表达 GRPO 的更新思路把样本奖励转化为组内相对优势再按策略梯度更新。它省去了 Critic因此显存占用更低训练更简单。但 GRPO 也付出了一部分样本效率代价。它需要同一组提示生成足够多的响应才能获得稳定的标准化估计。如果每组只有两个响应均值和方差都不可靠优势估计的噪声会显著上升。实践中num_generations经常设置成 4 到 16 不等具体要看显存和奖励稳定性。3.3 推理 RL可验证奖励和思考 token近一年推理模型训练中RL 的用法出现了一次明显变化。数学题、代码题、逻辑题这些任务存在客观正确性不需要 RM 打分而是可以使用规则校验器直接判定。于是训练目标变成两条答案正确性奖励最终答案是否与标准答案一致格式奖励是否按要求输出思考过程和最终结果。这类训练还加入了“思考 token”thinking token机制。模型被允许在最终答案前输出一大段推理过程RL 只需要对完成效果给反馈。模型会在试错中学会更长的思考链提高在难题上的正确率。这种做法的关键前提是“验证器足够可靠”。如果验证器能准确判断每一步是否正确模型收到的反馈就接近过程监督如果验证器只能判断最终答案对错模型依旧要面对稀疏奖励问题。很多公开实验里冷启动阶段会用 SFT 数据训练模型先输出基础思维链然后再用 RL 扩大搜索范围。冷启动数据的质量直接决定 RL 阶段是否能从局部邻域开始。4. 最小可运行骨架用 TRL 搭一个 GRPO 实验4.1 环境和依赖准备要快速验证 LLM RL 的效果最直接的方式是用 TRL 库里的 GRPO 训练器。下面示例用于说明思路并不代表所有环境都适用。实际项目要结合自己的包名、路径和版本调整。建议环境依赖版本建议说明Python3.10 以上现代 PyTorch 和 TRL 通常要求PyTorch2.x版本需要与 CUDA 匹配transformers4.40 以上版本影响模型加载接口trl0.14 以上需要确认是否有 GRPOTrainer 导入路径datasets2.x用于准备训练数据accelerate0.30 以上分布式训练底层学习环境不一定要大算力。一个 24GB 显存的单卡可以尝试 1.5B 或 7B 模型但如果想验证机制优先从更小的模型开始。注意原始材料没有给出固定版本落地前要先确认依赖版本与本机环境匹配。4.2 写一个最简单的奖励函数取一个非常小的任务给定一个加法表达式模型只能输出最终答案。奖励函数判断答案是否正确。def addition_reward(prompts, completions, **kwargs): rewards [] for prompt, completion in zip(prompts, completions): text completion.strip() try: answer int(text) rewards.append(1.0 if answer 7 else 0.0) except ValueError: rewards.append(0.0) return rewards这只是玩具实验用来理解 RL 数据流。工程级奖励函数还要考虑解析失败分类、部分得分、格式拆解等。另一个需要注意的点是这里使用了生成结果的整体正确性作为奖励它仍然是一个很稀疏的标量信号。如果要观察信息论低效可以先从这个最稀疏的设置开始之后再加上过程奖励做对照实验。4.3 训练脚本与关键参数GRPO 训练的核心参数如下from trl import GRPOConfig, GRPOTrainer config GRPOConfig( output_dir./outputs/grpo-addition, learning_rate1e-6, per_device_train_batch_size4, num_generations8, max_prompt_length128, max_completion_length16, beta0.04, logging_steps5, save_steps100, ) trainer GRPOTrainer( modelQwen/Qwen2.5-1.5B-Instruct, reward_funcsaddition_reward, argsconfig, train_datasetdataset, ) trainer.train()这些参数的含义需要解释清楚参数作用调大后的影响调小后的影响learning_rate策略更新的步长收敛快但容易破坏先验分布稳定但训练周期变长num_generations每个提示采样的响应数量组内奖励估计更稳显存占用高节省显存但 advantage 噪声大betaKL 惩罚系数策略更贴近参考模型KL 小更新更大胆但容易偏离先验max_completion_length生成长度上限允许更长推理计算慢防止长度膨胀但限制表达启动命令类似accelerate launch scripts/run_grpo.py训练中主要观察四类指标平均奖励是否上升、KL 是否失控、生成长度是否异常增长、训练损失是否稳定。如果平均奖励上升但 KL 已经增长到 100 以上通常说明策略偏离了参考模型不是正常表现。4.4 运行验证和预期结果训练前先用同一个提示做一次推理记录模型默认输出。训练结束后再跑一次推理对比答案。玩具任务通常几十步内就能看到奖励上升但这不说明模型“学会了数学”只能说明它在这个提示模板下调整了解码偏好。真正判断 RL 是否有效必须在专门评测集上看提升而不能只看训练集 reward。即使奖励函数定义得很简单也要同时保留三种评估训练集奖励留出验证集奖励人工抽查生成内容质量。如果训练集奖励上升而验证集奖励不变大概率是奖励函数出现了可被钻取的空子而不是模型能力提升了。5. 训练中常见陷阱和排查路径5.1 奖励黑客奖励上升但能力没提升现象训练日志中 reward 快速升高但人工抽查后发现模型输出质量下降甚至出现了没有实际意义的长篇空话。原因奖励函数存在可被利用的漏洞。比如奖励函数只判断“是否包含某个关键词”模型就会把关键词反复堆进输出而不是真正完成任务。检查方式在训练日志中随机抽样 50 条生成结果对比训练集和验证集奖励曲线检查奖励函数是否能被完全随机输出钻空子。解决建议把关键词判断改为结构化判断增加解析失败惩罚引入验证集上的定期评测。预防的关键是奖励函数要尽量贴近“最终结果是否正确”而不是“中间过程是否看起来正确”。5.2 KL 崩溃模型输出走向退化现象KL 散度从极其微小的值突然升到几十甚至一百以上生成文本出现强烈重复或模板化。原因学习率过大、KL 系数过小或者奖励优势被放大后连续多步更新同一方向策略逐步脱离参考模型。检查方式日志中追踪kl字段抽取同一 prompt 训练前后的输出做对比观察生成 token 的熵是否持续下降。解决建议调低学习率调高beta或对单次更新做更大的梯度裁剪。不要在 KL 已经失控时继续训练最稳妥的方法是回滚到最近的 checkpoint调参后重新启动。5.3 长度膨胀模型用长度换奖励现象平均生成长度持续上涨有时还会出现“奖励没变但 token 数翻倍”的情况。尤其在推理 RL 中常见模型会为了多拿步骤分而输出冗长过程。原因奖励函数对正确中间步骤给了额外分数模型发现多写一些可能正确的内容能提高期望奖励于是总长度被拉长。检查方式对比completion_length和reward的相关性。如果相关性强说明奖励在奖励“写长”而不是“写对”。解决建议对过长输出设置负奖励在奖励函数里加长度惩罚项限制max_completion_length。很多项目会在格式奖励中加入“超过 N 字扣分”的规则。5.4 奖励函数不稳定训练中途突然归零现象某个 step 之后 reward 突然大面积变成 0模型输出解析全部失败。原因策略生成格式跑偏奖励函数又没有设计“解析失败也返回低分”的兜底分支导致所有样本被判定为 0。奖励方差变大后梯度方向混乱。检查方式观察 reward 函数日志中出现ValueError或空输出的频率在本地对一条模型输出手动调用 reward 函数。解决建议奖励函数必须先对输出做规范化处理。解析失败、空字符串、超长文本都要单独返回一个可预期的分数并记录日志。生产环境里奖励函数的错误分支应该被当作一等公民对待。把这四个问题汇总成一张速查表问题现象常见原因检查方式处理建议reward 上升但能力没提升奖励函数存在可钻取的漏洞随机抽样人工评估对比验证集重写奖励函数增加结构化判断KL 快速变大学习率过高或 beta 过小追踪 kl 指标查看输出熵调低学习率调高 beta回滚 checkpoint生成长度持续增长奖励在鼓励长文本看 completion_length 与 reward 相关性加入长度惩罚限制 max_completion_lengthreward 大面积归零奖励函数缺少解析失败分支检查错误日志单条调用 reward 函数补充异常分支和兜底分数6. 实际训练中的最佳实践和扩展方向6.1 启动 RL 实验前的检查清单以下清单适合在写训练脚本前逐项确认是否已有 SFT 或指令微调模型而不是直接从基座模型起步奖励信号是否可自动验证如果不可验证是否为 RM 预留了足够的评测集奖励函数是否存在明显的空子比如只判断关键词、只判断长度是否设置了 KL 正则项且beta参数有预期范围是否预留了对照实验训练前后在同一个评测集上的指标能否对比是否记录了kl、completion_length、reward三类日志是否准备了回滚 checkpoint防止 KL 崩溃后无法恢复是否用 1B 或 7B 这类小模型先验证机制再扩展到更大模型。这个清单可以当成 RL 实验的快速门禁任何一项不满足都不建议直接启动大规模训练。6.2 学习环境与生产环境的差异学习环境里跑通一个最小 GRPO 案例只是第一步。生产环境面对的情况复杂得多维度学习/实验环境生产环境数据固定提示集动态、多轮、多语言奖励函数简单规则重可解释需要防对抗、防漂移、可审计算力单卡即可多机多卡需要 checkpoint 与容错评估手动查看样例自动化评测集、线上 A/B、人工抽检安全低风险输入输出过滤、数据脱敏、权限控制生产环境中模型输出最终会影响用户或业务系统奖励函数的错误会被放大。建议在生产环境使用可验证的真实业务结果作为主奖励比如 API 调用是否成功、订单金额计算是否准确、SQL 是否返回正确结果。不能验证的偏好类奖励要谨慎加入策略更新。6.3 扩展方向Agent、可编程验证器和知识库RL 在 LLM 训练中最有前景的方向之一是可以自动验证奖励的任务。Agent 场景非常适合做这种实验模型需要调用工具、读取返回结果、修正错误、最终完成一个可判断的目标。工具执行的返回结果本身就是天然奖励信号。另一个方向是将LLM wiki这类知识管理思路引入 RL 工程。团队的 RL 实验经验、奖励函数设计、失败案例都可以沉淀成团队知识库。每次训练后记录奖励函数的改动、生成的坏样本、KL 指标变化后续项目就能避免重复踩坑。从更远的视角看解决“信息论低效”的方法不是增加采样量而是不断减少奖励信号中的不确定性可验证奖励代替偏好模型过程监督代替结果监督先验 SFT 代替随机初始化。每一步都在降低 RL 需要从稀疏信号中提取的信息量。如果正在规划一个新的 LLM RL 实验最应该记住的不是理论上界而是实际条件。我们并不是在随机空间里做暴力搜索而是在一个高信息先验的局部区域做修复。只要奖励可验证、粒度足够细、更新步长被 KL 限制住RL 就能在小样本下产生可观察的提升。下次实验不妨从最便宜的奖励函数和最小的 batch size 开始先在小模型上确认反馈闭环成立再逐步放大。