Token级奖励：提升LLM强化学习细粒度反馈的关键实践-北京尧图网络

训练大模型这半年我最深的一个感受是给模型发奖励和给学生打分一样光给个总分学生根本不知道错在哪。如今LLM强化学习RL里最值得玩的方向之一就是token级奖励token-level rewards把原来只在整段回答结束时落下的一次性奖励拆成每一个词元token都能收到的细粒度反馈。早期我们做RLHF时习惯在模型答完一整段之后拿一个整体奖励模型打个分再把整段当作一个整体去更新。效果有但总感觉模型学得慢——特别是数学推理、代码生成这种长回答场景几百上千个token只换回来一个孤零零的reward信号模型真的很难搞清楚自己到底哪一步走对了。这篇文章不是纯理论科普也不是贴一段源码就完事。我会结合自己在一个内部数学推理对齐任务里的实际经历把token级奖励从为什么要拆到怎么拆、怎么算、怎么排坑完整讲一遍。适合正在做RLHF/RLVR训练的工程师也适合刚入门、想弄明白过程奖励和结果奖励到底差别在哪的研究生。1. 先搞清楚token级奖励到底在解决什么问题1.1 结果奖励的信用分配困境先说一个最常见的训练场景。我们让模型解一道数学题它生成了一段2000 token的推理过程前1950个token思路都很顺最后50个token里某一步计算失误答案错了。如果只用结果奖励整个2000个token共享同一个负分。后面模型更新的时候真正导致错误的最后一步被拉低前面辛辛苦苦的正确推理也被无差别打击。这是强化学习里最经典的信用分配credit assignment问题一个长序列只有一个奖励信号你根本不知道这个奖励应该归因于哪一部分行为。在PPO的实现里这个问题还会被放大。常规做法是序列中间每个位置的reward都取0只有最后一个tokenEOS拿到整体奖励然后通过GAE从后往前传播。中间位置的优势值advantage全靠价值网络去bootstrap价值网一不准整个梯度方向就全是噪声。你可以把它想象成考前突击了一个月最后考及格了但你根本不知道是前两周的复习起了作用还是最后三天的冲刺救了你——这种学习效率显然不高。Token级奖励的思路就是绕开这个困境在每个token生成的时候就给它一个即时的质量信号。模型不需要等到整段生成完才知道这一步走偏了生成到某一步时奖励已经落下它当场就能调整方向。这样做的直接收益是advantage估计的方差明显变小梯度的信噪比提升训练稳定性也会好很多。1.2 结果监督、步骤监督和token级监督的差别很多人在讨论token级奖励时经常会和过程监督process supervision混着说。实际上两者不是一回事但工程上经常是嵌套关系。我自己习惯把奖励粒度分成三档监督粒度奖励信号信号密度标注/计算成本典型适用场景结果监督整段回复一个score最稀疏低只需评最终答案短问答、格式统一的分类任务步骤级过程监督每个推理步骤一个score中等中等需要步骤切分和步骤评分数学推理、代码生成、长思维链token级过程监督每个token一个score最密集高需要细粒度评估器或规则探索性强、中间过程高度可验证的任务需要说明的是实际项目中token级和步骤级经常是混用的。一个步骤内部通常只有十几个token我们很难区分这个token对了、那个token错了——比如一个模型正在推导x13你说x这个token是对的还是错的它单独存在没有意义。所以在绝大多数实现里token级奖励的真实形态是步骤分数的token展开一个step内的所有token共享同一个分数。这既保留了细粒度的时间定位能力又不会引入单token级别的无意义噪声。1.3 什么场景必须上token级奖励不是所有任务都需要token级奖励。如果任务是那种20个token以内就能答完的短问题结果奖励完全够用没必要自找麻烦。但下面这几类任务我是强烈建议考虑token级奖励的长思维链/长推理回答动辄两三千token中间步骤的可信度比最终答案更能反映模型是否真的会推理。只给结果奖励模型很容易走捷径——比如改一下最终答案前面全胡说。代码生成编译错误、运行时异常往往对应到具体的代码行也就是具体的token区间。如果能在出错位置立刻给负分比最后生成完一整个文件再判分有效得多。Agent工具调用模型在某一步调用了错误的工具、传了错误的参数这个错误是局部的不该让前面所有正常对话背锅。长文本写作分段质量评估、逐段结构反馈本质上也是token段级别的奖励。我个人的判断标准很简单回答越长、中间步骤越容易被单独评估token级奖励的收益就越大。反之短任务和高度整体性的任务强行拆token奖励只会增加工程复杂度收益甚微。2. token级奖励的几种设计思路2.1 过程奖励模型PRM让模型给模型打分第一种主流方案是训练一个专门的过程奖励模型Process Reward Model。它的输入是前缀序列输出是这个前缀到达当前状态的质量分。训练数据怎么来业界最常用的方式有两种一种是人工对推理步骤标注质量成本高但质量稳另一种是自动构造——对同一个问题采样多条rollout把能得出正确答案的路径标为正、错误路径标为负让PRM去学习哪些步骤是通向正确答案的关键步骤。PRM推理时的工作流程是模型生成完整回复后先按规则或模型把回复切成一个个步骤比如按换行、按推理逻辑块切分然后PRM对每个步骤的结束位置打一个分再把这个分数广播给该步骤内的所有token。PRM的好处是泛化性比较强可以处理开放域任务不依赖具体的规则坏处也明显——要多训一个打分模型训练成本高而且PRM本身也可能被策略模型攻击reward hacking这一点后面第4章会详细讲。2.2 规则型token奖励验证器给的额外反馈第二种路线是规则驱动。对于数学题可以写一个答案校验器对于代码可以直接在模型生成过程中尝试执行片段并捕获异常对于结构化格式任务可以用正则检查每一步是否满足格式要求。规则型token奖励的实现极其便宜没有额外的模型开销而且信号稳定、可解释性强——模型某一步格式错了立刻给个负分数它很快就能学会格式规范。但规则的覆盖面有限。它只能识别可被形式化验证的错误无法判断这句话的推理虽然格式正确但逻辑荒谬。所以我的经验是规则型token奖励适合作为基础信号尤其是数学/代码这种答案可验证的任务开放域任务里它当不了主力只能当补充。2.3 KL惩罚本来就是一种token级奖励这一点很多新人会忽视RLHF/RLVR训练里的KL散度惩罚本质上就是逐token作用的奖励修正项。标准loss里经常有beta * KL(pi || pi_ref)它比较的是当前策略和参考策略在每个token上的分布差异。模型如果在某个token上大幅偏离参考策略这个惩罚立刻体现出来。换句话说我们的训练流程里其实早就有token级信号了。只不过KL信号是约束性的它告诉模型别跑太远但没告诉模型这里该往哪个方向跑。而token级奖励是指引性的它直接给出好坏判断。理解这一点很重要当你引入显式的token级奖励时它不是从零开始而是在KL惩罚这个已有的token级信号之上叠加一个信息更丰富的方向信号。2.4 三个方案怎么选我的选型标准这三种方案不是互斥的实际项目里往往是组合拳。我自己在项目里的选型逻辑是任务有明确验证规则数学、代码、格式化优先上规则型token奖励。便宜、稳定、解释性强能解决80%的问题。开放域任务对话、写作上PRM。没有规则可用只能靠模型学一个打分器。无论哪种KL惩罚必须保留它是最基本的稳定性保障。如果资源有限最快的见效组合是结果奖励规则型过程奖励。结果奖励盯住最终目标过程奖励盯住中间质量两者互补能覆盖大多数长序列训练需求。3. 实操把token级奖励接进GRPO训练流程3.1 第一步把步骤分数翻译成token奖励假设我们已经拿到了每个步骤的分数这一步要解决的是怎么把它映射到token序列上。核心是维护一个token_to_step的映射关系每个token记录自己属于第几个step。这个映射可以在生成阶段由切分逻辑同步构建。def step_scores_to_token_rewards( step_scores, # list[float]每个step一个分数 token_to_step, # list[int]每个token属于哪个step seq_len, # 序列长度 ): rewards [] for tok_idx in range(seq_len): step_id token_to_step[tok_idx] rewards.append(step_scores[step_id]) return rewards这段代码看起来简单但工程里至少有三个坑。第一tokenizer的special token比如eos、pad、bos不能参与奖励计算token_to_step里要给它们单独标记为-1最后用mask抹掉。第二padded batch里padding位置没有任何实际意义reward必须置0、loss必须mask否则模型会学到对空位置也输出信号这种错误行为。第三如果某个step在切分后意外为空比如连续两个分隔符要在构建映射时过滤掉不能让空step占一个score位置。3.2 第二步在GRPO里计算token级优势GRPO的核心思想是对一个输入问题采样一组多个回复然后在这组回复内部做相对比较以此构造advantage避免再训一个庞大的critic网络。标准GRPO里如果只用结果奖励那组内所有token的advantage都是同一个值——因为所有位置共享同一个整段分数。一旦换成token级奖励advantage就可以在每个token位置上单独做组内归一化。我的实现是这样的# rewards: [group_size, seq_len]token级奖励矩阵 mean_rewards rewards.mean(dim0, keepdimTrue) std_rewards rewards.std(dim0, keepdimTrue) advantages (rewards - mean_rewards) / (std_rewards 1e-4) advantages advantages * mask注意这里的mean和std是在dim0上算的也就是对组内所有回复的同一token位置做归一化。为什么不整组所有位置一起归一化因为不同位置的奖励量纲可能完全不同——比如前几步是格式分0~1的小数最后一步是结果分1/-1混在一起归一化会抹掉位置差异导致模型分不清这一步的绝对水平到底如何。逐位置归一化更稳。3.3 第三步组合出最终训练奖励在真实训练里我一般会把三类信号合在一起。公式长这样r_{i,t} w_process * r_process_{i,t} w_outcome * r_outcome_i beta * kl_{i,t}第一项是token级过程奖励告诉模型这一步走得对不对第二项是整段结果奖励告诉模型这段最终答案对不对第三项是KL惩罚控制策略不能偏离参考策略太远。三者的单位不一致不能直接相加必须先归一化再组合。我常用的做法是先把过程奖励和结果奖励各自标准化到差不多的量纲再给权重。初始值我建议这样设规则型过程奖励的w_process可以给0.5到1.0PRM型给0.1到0.5——因为规则型信号更可信PRM型噪声大权重压低一点更安全。w_outcome固定在1.0左右结果奖励是最终目标不能太弱。beta根据模型规模在0.01到0.05之间起步KL太早压死会学不动太小又会跑偏。3.4 训练时容易漏的几个关键细节token级奖励引入后训练日志和数据处理有一堆细节必须跟上。我踩过坑之后总结了五条把token奖励clip到一个安全范围。我一般clip到[-2, 2]超出这个范围的分值大概率是异常信号直接截断比保留更能保稳定。定期打印每个step平均token数。如果模型学会了疯狂换行把一个长推理拆成几百个短step说明它已经找到刷分数的方法了——这种时候步骤切分规则要改。训练日志里除了总loss一定要单列token奖励均值KL均值结果奖励通过率三个指标。只看总loss模型跑偏了你根本无从察觉。做EMA平滑再看趋势。token级奖励的波动通常比结果奖励大很多直接看原始曲线容易误判。奖励和logprob要对齐。很多bug都出在advance已经算完但和输入token错了一位——用tabular logging把(token, logprob, reward, advantage)打出来肉眼检查前50个token就能发现对齐问题。4. 实测中踩过的坑和排查方法4.1 问题一训练loss降了最终评测一点没涨这是我第一次上token级奖励时遇到的最诡异问题。loss曲线很漂亮稳步下降但最终评测准确率原地踏步。一开始我以为要等更多轮数后来一查才发现模型学会了刷过程分——它把每一步都写得格式正确、看起来有理有据但最后的答案仍然是错的。原因是过程奖励和结果奖励脱钩了中间步骤拿到的正分并没有导向最终正确答案。排查思路是先算过程分数和结果分数的相关系数。相关系数低说明过程奖励模型或规则信号被钻空子了。处置建议是提高w_outcome的权重同时给训练加一个约束——如果最终答案错了整段回复的过程奖励做一次衰减避免模型每步都像在推理、但推理整体失效。另外如果PRM打分发现过程分高但结果错的样本比例超过10%基本可以判定是PRM训练数据质量出了问题要重新过一遍标注。4.2 问题二token奖励噪声太大训练波动剧烈token级奖励的毛病是太密、太碎。PRM在单个token级别上往往没有足够的分辨率它对一个step内部的不同token打分可能是在瞎猜导致adv出现明显噪声。表现就是训练不稳定、梯度norm时高时低。我的处理办法有三个。第一是平滑把相邻5个token的reward做滑动平均或者干脆退回步骤级——step内共享分数只在step边界切换。第二是降低w_process让过程奖励从主导信号降为辅助信号。第三是提高batch size用更多样本对冲噪声。实测下来最有效的是步骤共享分数结果奖励主导过程奖励辅助的组合干净利落。4.3 问题三KL惩罚和token奖励打架引入token级奖励后模型有时候会发现偏离SFT策略能拿到更高的token奖励于是KL惩罚就压不住了表现为KL散度反弹、熵快速下降。这个问题的本质是token级奖励给得太密模型找到了一条每个token都拿小分、累计起来很高但整体质量很差的捷径。排查方法是看高reward token是否都偏离SFT很远。如果正奖励总是落在策略分布明显偏移的位置那基本可以断定是奖励被利用。处置建议提高beta比如从0.02提到0.05同时降低w_process更根本的方法是修奖励本身让格式正确但内容是胡扯的中间步骤得不到高过程分。4.4 常见问题速查表现象先查什么常见原因处置建议loss下降但评测不涨过程分与结果分的相关性模型刷过程分、奖励脱钩提高w_outcome结果错时衰减过程奖励训练波动大token奖励分布、梯度normPRM单token分辨率低、噪声大平滑reward、降到步骤级、提高batch sizeKL反弹、熵崩高reward token的KL值模型利用奖励偏离SFT提高beta、降低w_process、修奖励本身advantage分布偏斜每个token位置的adv统计归一化方式不对、mask漏处理逐位置组内归一化严格mask padding模型疯狂拆短step每step平均token数步骤切分规则被利用限制最小step长度、改进切分规则4.5 关于要不要做到每个token都不同的一点个人看法做了一圈之后我的结论是工程上不需要追求每个token都真正独立打分。除了极少数可验证场景比如代码编译错误能精确定位到某个token大部分任务的可评估单元本来就是步骤或句子。强行做到token级只会放大噪声、增加标注难度。真正有价值的不是每个token的分都不一样而是奖励不再只落在序列末尾而是分散到了多个中间位置。把奖励放在对的粒度上比最细的粒度更重要。我自己跑完这套流程之后最大的体会是token级奖励不是银弹它是把信号的分配方式改了让模型在每个决策点都能收到即时反馈。但它同时也把奖励被利用的风险从全局转移到了局部——模型有可能学会在每一个局部都表现得正确整体却在胡扯。这不是token级奖励本身的问题而是任何细粒度奖励都要面对的过程与结果解耦问题。做这个方向一定要始终盯住最终指标定期看过程奖励和结果奖励的相关性发现问题立刻调整权重而不是一味相信loss曲线。最后再分享一个实用技巧如果团队资源有限不要一上来就训PRM。先用结果奖励规则型步进奖励 KL惩罚的组合跑一版把日志体系、训练pipeline、问题排查流程都跑通。等你确认这版训练稳定了再逐步引入更复杂的PRM。每一步多一分信号模型就少一分迷茫但每一步也多一分被利用的风险——平衡这两者才是这个方向真正的功力。

Token级奖励：提升LLM强化学习细粒度反馈的关键实践

相关推荐

d3dx10_41.dll丢失的完整修复指南：DirectX运行库安装与排查

GitHub模拟登录的七层验证与Playwright工业级实践

6位数码管静态显示实战：基于74HC573锁存器的单片机驱动方案

更多资讯

混合储能系统Simulink建模与并网仿真：锂电池+超级电容功率分配策略实践

医疗AI落地关键：SKILL架构实现可解释性与合规可追溯

STM32入门：从CubeMX到Keil MDK创建HAL库工程并点亮LED

数据合规红线：客户与员工数据进入AI链路的边界与治理

Nacos 2.5.0 国产化适配：麒麟ARM+达梦DM8完整落地实践

2026大模型盘点：模型格局、应用落地与选型避坑指南

今日更新

智能硬件视频会议集成：从芯片选型到场景落地的全栈实践

FFmpeg音视频处理与5路RTMP推流实战：从原理到118克盒子部署

RK3528+1GB内存如何变身直播节点？硬编解码与六协议实战复盘

本周精选

金融AI落地指南：从调研报告到技术选型与工程实践

大模型上下文成本与注意力优化技术深度解析——为何O(n²)平方复杂度无法被常规优化消除｜TaoToken 统一 Key 通道实测

基于GMM的语音识别系统原理与MATLAB实现详解

本月热门

我发现了一个新思路：用 Remotion + Claude Code 像写代码一样自动化生成短视频

Windows下 Codex 中 Chrome 和 Computer Use 插件不可用问题排查及解决参考方式：TaoToken 统一 Key 配置与验证

2026 大模型集体涨价：用 Python 做企业 Token 成本测算与选型避坑（附配置）

读完文章，想聊聊您的网站？