强化学习（RL）为何是 LLM 绕不开的关键：从 RLHF 到 PPO 与 DPO

为什么说 RL 是 LLM 无法绕过的一道坎很多同学接触大语言模型LLM已经有一段时间了会写 Prompt、会做 RAG、会用 LangChain 搭 Agent甚至自己微调过模型。但一提到 RL强化学习第一反应往往都是“那是算法工程师的事”“我只需要调用现成的模型接口”。这个判断在一年前还基本成立但放到今天已经越来越站不住脚。为什么因为 LLM 从“会说话”走向“会做事”中间最关键的临门一脚就是 RL。当前大模型对齐技术中最具代表性的 RLHF基于人类反馈的强化学习其底层就是一套完整的强化学习流程。SFT 之后的模型如果没有经过 RL 阶段表现出来的能力可能只是“学会了句式”而不是“真的理解了用户的意图”。你如果用 SFT 模型做过真实产品大概率遇到过这样的问题模型回答很流畅但不按指令执行、不会拒绝、不知道什么时候该说“不知道”这其实就是对齐不充分的表现。这篇文章是“RL for LLMs”系列的第一篇目标是把强化学习在 LLM 领域最基础、最核心的概念讲透。我会从传统强化学习的基本要素讲起再一步步拆解 RLHF 的完整流程解释为什么 LLM 的强化学习和我们熟悉的游戏 AI 强化学习不一样最后给出一个可以亲自跑通的最小示例思路以及一套适用于生产环境的工程建议。读完这篇文章你至少能搞清楚三件事第一RL 到底在 LLM 训练中解决什么问题第二RLHF 的四个核心组件之间是怎么配合的第三如果自己要去实践 RL第一步应该做什么、最容易在哪里翻车。1. 这篇文章真正要解决的问题先说一个容易被忽视的事实预训练 SFT 已经让模型变得很聪明但还没有让模型变得“可控”。预训练阶段模型的目标函数是最大似然——给定上文预测下一个 token。这个目标决定了模型学会的是“这段文本接什么最自然”而不是“这个回答是否满足了用户的需求”。SFT监督微调阶段稍微好一些模型开始学习模仿人类写出的标准答案但它依然存在一个本质问题SFT 的损失函数鼓励模型输出“像标准答案”的内容却无法直接优化“用户满意度”这类不可微分的指标。这里就出现了一个非常现实的问题产品上线时我们要评价模型回答好不好用的是准确率、相关性、安全性、有用性这类标准。但这些标准要么是离散的要么是高度主观的根本没法对神经网络直接求导。如果不用 RL你会发现模型训练和产品指标之间隔着一堵墙——训练时优化的是交叉熵上线时考核的是人类偏好。RL 就是用来拆掉这堵墙的。它允许我们把“用户会不会给这个回答点赞”“这个回答是否安全”“这个回答有没有完成任务”这类抽象目标编码成一个奖励信号Reward然后用策略优化的方式直接去最大化这个奖励。换句话说RL 让 LLM 的训练目标从“模仿文本”变成了“达成目标”。所以这篇文章真正要解决的问题不是“什么是强化学习”这种百科问题而是为什么 SFT 做完了还不够RL 在 LLM 训练管线的哪个位置介入RLHF 的每一步到底在做什么你自己要实践时从哪里开始上手如果你是以下几类读者这篇内容会特别有用正在做 LLM 微调但只在 SFT 层面操作想搞清楚 RL 层级的同学。准备在生产环境部署对齐后模型的工程师需要理解模型能力和奖励模型的关系。研究 Agent 方向的开发者因为 Agent 的规划与反思机制本质上也是策略优化问题。2. 强化学习的基础概念与核心原理2.1 强化学习的基本要素传统的强化学习可以抽象成这样一个过程一个Agent智能体在Environment环境中不断做出 Action动作环境根据动作的结果反馈一个 Reward奖励Agent 根据奖励调整自己的行为策略。这个循环不断重复Agent 最终学会“在什么状态下做什么动作能获得最大累计奖励”。四个核心要素要素含义LLM 场景下的对应物Agent决策主体大语言模型本身Environment与 Agent 交互的外部系统用户对话环境、下游工具调用环境、评测环境State状态当前环境提供给 Agent 的信息当前对话历史 系统提示词Action动作Agent 做出的决策生成的下一个 token 或完整回复Reward对动作好坏的反馈信号人工评分、奖励模型打分、规则性奖励有一个很容易误解的地方很多人会把 LLM 的强化学习想成“模型自己玩游戏自己发现规律”其实 LLM 场景下最像“环境”的不是某个模拟器而是人类偏好本身。奖励信号也不是环境自动给的而是需要专门设计甚至训练一个模型来模拟人类打分。2.2 强化学习与监督学习的关键区别传统监督学习的训练流程是给定输入 x希望模型输出尽量接近标注 y损失函数通常是交叉熵或均方误差。整个过程可以看作“教会模型看标准答案”。强化学习的训练流程不一样。它没有一个“标准答案”只有动作产生之后才有结果反馈。网络需要通过尝试、获得奖励、改进策略不断逼近最优行为。这个过程用术语说就是策略优化Policy Optimization。对于 LLM 来说这两者的差异会产生一个直接影响SFT 训练时模型看到的是人工写好的对话样本学到的是“标准答案的分布”。但这会导致模型倾向于生成安全、平庸、常见的回答而不是最有用、最新颖、最符合用户真实需求的回答。RL 训练时模型会根据奖励模型给出的分数不断调整生成策略。因为奖励是可以连续量化的模型有机会学会“在哪些情况下应该多说一点在哪些情况下应该简洁回答什么内容会得分高什么内容会被惩罚”。2.3 为什么 LLM 场景下的 RL 和 AlphaGo 式 RL 不一样这里需要特别强调一个会劝退很多初学者的认知差异。很多人尝试学习 RL 时先去看了 Atari 游戏、AlphaGo 的资料发现要理解 Q-Learning、DQN、蒙特卡洛树搜索等等然后就直接放弃了。这些知识对做 LLM 的人来说绝大多数是不需要的。原因很简单文字生成是一个序列决策问题动作空间极大每一个 token 都是动作游戏 AI 里那套基于价值函数Value Function的经典算法在这里并不直接适用。LLM 的 RL 实践几乎全部集中在策略梯度类方法上最典型的就是 PPOProximal Policy Optimization近端策略优化以及它的变体。你可以把 PPO 理解为“在每一次更新时不让策略变化太剧烈”的策略优化算法。至于 Q-Learning 那套LLM 领域基本不谈。这就好比学开车目标是日常通勤而不是去跑拉力赛。你可以跳过赛车专用的漂移技术把精力集中在起步、换挡、踩刹车和看后视镜上。日常通勤版 RL 需要优先掌握的就是“策略模型 奖励模型 策略优化”这条主线。3. RL 在 LLM 训练管线中的位置3.1 一张图理解 LLM 的训练管线大模型的训练流程从宏观上可以分为四个阶段预训练Pre-training最大化下一个 token 的预测概率目标是让模型掌握语言知识和世界知识。监督微调SFT用人工标注的高质量对话数据让模型学会对话格式学会听从指令。奖励建模Reward Modeling训练一个奖励模型给模型的输出打分模拟人类偏好。强化学习RL用奖励模型作为反馈信号通过 PPO 等算法进一步优化策略模型。这里有一个非常关键的点RL 并不是替代 SFT而是建立在 SFT 之上的一层优化。SFT 先把模型从“预训练状态”拉到一个“会说人话并且大概率符合人类基本期望”的起点RL 再在这个起点上做进一步的策略优化。如果你跳过 SFT 直接做 RL模型连基本的话术格式都没有学好策略优化就会在一个很差的搜索空间里徘徊结果往往非常差。3.2 RL 究竟改变了什么如果用一句话来总结 RL 阶段对模型的影响那就是它把模型的优化目标从“模仿”换成了“拿分”。SFT 训练时模型输出一个回答 A如果答案 A 和人工标注的答案 B 不一样就算 A 写得也一样好交叉熵损失依然会告诉模型“你错了”。这就导致 SFT 模型倾向于产生“最保守、最标准”的回答因为这样它在训练集上的损失最小。这也是不少人觉得 SFT 模型“聪明但机械”的原因。RL 阶段就不一样了。模型输出 A 之后奖励模型会给 A 一个分数比如 1.5 分模型输出 B 之后奖励模型会给 B 打 3.8 分。模型不需要一定模仿某个固定答案它只需要不断调整策略让自己输出的内容得分越来越高。这个机制给了模型比 SFT 更大的自由空间它可以在人类偏好的约束下探索出超越标注数据的更优回答。3.3 冷启动问题为什么不能直接从零开始 RL在相关热搜词里有“RL 冷启动”这个词这确实是实践中的一个核心问题。冷启动指的是模型一开始什么都不会直接丢到强化学习环境里它只有通过大量随机尝试才能偶尔获得一点奖励学习效率低到无法接受。LLM 的 RL 冷启动问题体现在两个层面第一层是模型层面。预训练模型直接做 RL生成的内容乱七八糟奖励模型给出的分数几乎没有区分度算法很难学到有效信号。必须先经过 SFT让模型的输出分布进入“有点接近好答案”的区域RL 才有优化空间。第二层是奖励信号层面。早期 RLHF 依赖人类直接对模型的每次输出打分成本极高。实践中会用 SFT 模型先产出一批回答人工对这批回答做排序标注训练出一个奖励模型然后用奖励模型替代大部分人工打分。这样就把“冷启动”阶段的人力成本压缩到了“只做一次标注”的量级。4. RLHF 的完整流程拆解4.1 从人类偏好到奖励信号RLHF 的核心思路是把“什么回答更好”这个主观判断转化为一个可以自动打分的奖励模型。整个流程可以拆成四步用 SFT 模型生成一批候选回答。人工对回答进行偏好标注通常是排序而不是打分。用排序数据训练一个奖励模型 RM让它学会预测“哪个回答更符合人类偏好”。在 RL 阶段用 RM 的分数作为奖励信号优化策略模型。有人可能会问为什么不直接用人工打分作为奖励还要多训练一个奖励模型原因有两点。第一人工打分太慢太贵如果每次策略迭代都要人工给上万条回答打分成本不可接受。第二人工打分本身有噪声同样的回答不同标注员可能给出不同分数。而奖励模型一旦训练好就可以对任意新的回答给出稳定的分数既可以加速训练循环又可以在一定程度上平滑标注噪声。4.2 奖励模型与策略模型的关系RLHF 阶段同时存在两个模型策略模型Policy Model和奖励模型Reward Model。策略模型就是我们要优化的目标模型在 PPO 流程里通常被称为 Actor。模型参数会在训练过程中不断更新希望自己的输出能在奖励模型那里拿到更高的分数。奖励模型是一个辅助模型它不参与最终的产品推理。它的输入是“提示 模型回复”输出是一个标量分数。这个分数越高说明回复越符合人类偏好。还有一个很容易被忽略的角色参考模型Reference Model。参考模型是 SFT 阶段的模型权重的一个冻结副本。它的作用是在 RL 训练中计算 KL 惩罚防止策略模型在追逐奖励的过程中偏离原始分布太远输出变得不自然或丢失通用能力。可以这样理解奖励模型鼓励模型“走偏去拿分”参考模型牵制它“别走太远”两者平衡的结果就是模型既对齐了人类偏好又保持了语言质量。4.3 完整的数据流RLHF 的一次典型训练迭代可以这样描述从提示集中采样一批 Prompt提示词。策略模型根据 Prompt 生成回复。奖励模型对回复打分。算法计算 KL 惩罚项策略模型当前输出与参考模型输出之间的距离。综合奖励和 KL 惩罚用 PPO 更新策略模型参数。这里需要留意第 3 步和第 4 步的分数共同构成最终的优化目标。如果只最大化奖励模型分数模型很快会学会利用奖励模型的漏洞比如输出冗长但空洞的内容、过度使用“好的我很高兴为您解答”这类话术来刷分。KL 惩罚的存在就是为了抑制这种奖励黑客行为。5. 从零理解 PPOLLM 强化学习的主力算法5.1 为什么需要 PPO传统策略梯度方法的核心问题是每次更新策略之后训练数据就过期了。你用完一批样本去更新模型更新后的模型生成分布已经变了再用旧样本来估计当前策略的好坏偏差会很大。如果为了收集足够多的新样本而不停重新生成数据训练成本又会爆炸。PPO 的解法非常工程化限制每次参数更新的幅度。它通过一个裁剪Clip机制确保新策略和旧策略的比率不会偏离 1 太多。这样即使使用旧策略采样的数据来更新新策略误差也被控制在一个可控范围内。论文里那句“让每一步更新都安全”说的就是这个意思。5.2 PPO 在 LLM 场景下的目标函数LLM 场景下PPO 的优化目标通常由三部分组成奖励最大化让模型生成的回复在奖励模型上得分更高。KL 惩罚让模型不要偏离参考模型太远保持输出自然度和稳定性。熵正则保持一定的随机性防止模型过早收敛到确定性策略。伪代码的表达如下loss -E[ reward - beta * KL(policy || reference) entropy_coeff * entropy ]其中 beta 控制 KL 惩罚的强度。beta 太大模型学不到新东西beta 太小模型可能输出退化。这里要特别提醒一个误区很多人以为 PPO 只适用于连续控制或游戏场景其实 PPO 在 NLP 中的实践已经非常成熟。HuggingFace 的 TRL 库、微软的 DeepSpeed-Chat、NVIDIA 的 NeMo-Aligner这些主流 LLM 对齐工具内部用的都是 PPO 或其变体。5.3 PPO 的四个模型角色在标准的 RLHF 训练中需要同时维护四个模型模型角色是否训练Actor策略模型实际的生成模型训练Critic价值模型预测状态价值帮助计算优势函数训练Reward Model奖励模型给回复打分冻结Reference Model参考模型计算 KL 惩罚冻结Critic价值模型是很多人初学 RLHF 时最困惑的角色。简单说PPO 更新策略时需要知道“这次回答到底比平均水平好多少”。Critic 模型就是为了估计这个“平均水平”而存在的它输出的是一个价值估计值用来和实际奖励做差得到优势函数。这个优势函数指导 Actor 的参数往哪个方向更新。6. 更高效的替代方案从 RLHF 到 DPO6.1 为什么会出现 DPOPPO 方案虽然效果不错但工程复杂度和资源消耗都非常高。你需要同时加载四个模型做推理和训练调参困难训练不稳定。很多中小团队在尝试 RLHF 时第一步就被这个系统复杂度劝退了。DPODirect Preference Optimization直接偏好优化是 2023 年提出的一种简化方案。它的核心洞察是奖励模型的训练和策略模型的优化其实可以合并成一步。DPO 不需要显式训练一个奖励模型而是直接从偏好数据中推导出一个隐式奖励函数并用来优化策略模型。6.2 DPO 与 PPO 的对比对比维度PPODPO训练组件Actor、Critic、RM、Reference 四个模型Policy Reference 两个模型奖励模型需要单独训练不需要隐式奖励训练稳定性不稳定需要大量调参相对稳定实现复杂度高低数据需求提示 偏好对即可提示 偏好对即可效果上限高但依赖调参接近 PPO且更稳健从实际项目角度看DPO 对于大多数应用场景已经足够。尤其是数据规模在万级左右的场景DPO 的成本优势非常明显。但如果你追求极致对齐效果且团队有精力去调 PPOPPO 的上限通常更高。这里给一个稳妥的建议从 DPO 起步验证数据质量再根据效果决定是否升级到 PPO。7. 适合入门的 RL 最小实践方案7.1 使用 TRL 库快速体验 RL对于想要实践 RL 的同学我最推荐的方式是使用 HuggingFace 的 TRL 库它提供了完整的 SFT、DPO、PPO 训练流程API 设计比较友好。下面演示一个 DPO 训练的最小代码框架。# 文件路径dpo_example.py from datasets import load_dataset from transformers import AutoModelForCausalLM, AutoTokenizer from trl import DPOConfig, DPOTrainer model_name Qwen/Qwen2.5-1.5B-Instruct model AutoModelForCausalLM.from_pretrained(model_name) tokenizer AutoTokenizer.from_pretrained(model_name) tokenizer.pad_token tokenizer.eos_token # 数据集格式每一条包含 prompt, chosen, rejected dataset load_dataset(json, data_filespreference_data.jsonl)[train] training_args DPOConfig( output_dir./dpo_qwen, per_device_train_batch_size2, learning_rate5e-6, max_length2048, max_prompt_length1024, num_train_epochs1, logging_steps10, save_steps100, remove_unused_columnsFalse, ) trainer DPOTrainer( modelmodel, ref_modelNone, argstraining_args, train_datasetdataset, tokenizertokenizer, beta0.1, ) trainer.train()这段代码里需要特别说明几个关键点ref_modelNone时TRL 会自动把当前模型深拷贝一份作为参考模型。beta参数控制 KL 惩罚强度数值越大对原模型的约束越强。数据格式必须是偏好对chosen是更符合人类偏好的回答rejected是较差的回答。7.2 偏好数据示例偏好数据是 RL 训练的核心资产。下面是一个 JSONL 格式的示例{prompt: 解释一下什么是回调函数, chosen: 回调函数是一种通过函数指针或函数引用将一段可执行代码作为参数传递给另一段代码的机制。当特定事件发生时接收方会调用这段代码。它在异步编程、事件处理和扩展框架中非常常见。优点是解耦和灵活缺点是容易导致回调地狱。, rejected: 回调函数就是函数里面传函数具体怎么用你自己查文档吧。}训练数据的质量直接决定模型对齐效果。建议收集真实业务场景中的用户问题并确保 chosen 和 rejected 之间有明显的质量差异这样奖励信号才有足够的区分度。7.3 使用 PPO 的代码框架如果团队条件允许可以尝试用 TRL 的 PPOTrainer 跑一个更完整的 RLHF 管线。下面是一个简化的结构示意# 文件路径ppo_example.py from transformers import AutoModelForCausalLM, AutoTokenizer from trl import PPOConfig, PPOTrainer, AutoModelForCausalLMWithValueHead model_name Qwen/Qwen2.5-1.5B-Instruct # PPO 训练需要在普通语言模型上额外添加一个 value head model AutoModelForCausalLMWithValueHead.from_pretrained(model_name) tokenizer AutoTokenizer.from_pretrained(model_name) tokenizer.pad_token tokenizer.eos_token config PPOConfig( model_namemodel_name, learning_rate1.41e-5, batch_size64, mini_batch_size8, gradient_accumulation_steps1, ppo_epochs4, ) # 假设已经训练好一个 reward_model能对文本输出打分 ppo_trainer PPOTrainer(config, model, tokenizer) inputs tokenizer([请写一篇 200 字的科技新闻摘要], return_tensorspt) for step in range(100): response_tensors ppo_trainer.generate(inputs[input_ids], max_new_tokens128, return_promptFalse) response_texts tokenizer.batch_decode(response_tensors, skip_special_tokensTrue) rewards [reward_model(text) for text in response_texts] stats ppo_trainer.step(inputs[input_ids], response_tensors, rewards)关于这个 PPO 示例有两个重要提醒第一AutoModelForCausalLMWithValueHead与普通模型的区别在于它会在 transformer 之上额外加一个 Value Head用于输出状态价值估计。这是 PPO 算法能计算优势函数的前提。第二PPO 训练非常不稳定learning_rate一般建议设置得比 SFT 低很多同时训练步数也不需要太长。如果发现 KL 惩罚值迅速飙升优先检查学习率是否过大以及奖励模型的分数分布是否合理。8. 运行效果与验证方式8.1 训练前中后对比RL 训练是否有效不能只看训练 loss还要看真实场景下的效果变化。建议至少从三个维度验证奖励分数变化在固定评测集上对比 SFT 模型和 RL 模型的平均奖励分数。如果奖励分数显著上升说明模型在偏好方向上确实有改进。人类评测准备一组业务相关的测试 Prompt让标注人员盲测比较 SFT 和 RL 模型的输出记录偏好比例。这是最直接的对齐效果验证。能力回退检测检查模型在通用能力基准如常识问答、数学推理、指令遵循上是否下降。RL 训练经常出现“为了对齐牺牲能力”的情况这种现象需要及时识别。8.2 如何判断训练是否成功训练过程中的日志指标非常重要。重点关注三个指标指标健康范围参考说明reward持续上升后趋于平稳如果剧烈震荡说明奖励模型或学习率有问题kl缓慢上升数值不大如果快速飙升说明模型偏离原始分布太远entropy缓慢下降如果骤降说明模型过早变得过于确定如果你用的是 TRL 库训练日志里会自动记录这些指标。建议每训练几百步就手动生成几条样本文本用肉眼判断回答质量。因为自动化指标再好最终产品体验还是由真实输出决定的。8.3 常见失败模式RL 训练最常见的失败模式有三种第一种是奖励模型被黑客攻击Reward Hacking。模型学到了奖励模型的漏洞比如输出超长、大量重复、使用特定模板虽然分数很高但用户体验很差。对策是加强 KL 约束、检查奖励模型在评测集上的准确率、定期人工抽样。第二种是模式坍塌Mode Collapse。模型生成内容的多样性急剧下降永远输出几乎一样的回答。对策是降低学习率、提高熵正则系数、增加训练数据多样性。第三种是对齐税过重Alignment Tax。模型对偏好数据的拟合很好但在通用任务上的能力大幅下降。对策是混合训练通用数据或者调整偏好数据的比例。9. 常见问题与排查思路以下表格整理了从事 RL 对齐实践时最常遇到的问题基本覆盖了从数据准备到训练稳定的完整路径。问题现象可能原因排查方式解决方案训练 loss 不下降偏好数据质量差chosen/rejected 区分度不足人工抽样检查数据统计 chosen-rejected 文本相似度筛选高质量偏好对确保明显的质量差距reward 分数上升但输出质量变差奖励模型过拟合特定风格分析 reward 高分样本检查是否出现重复或超长增加 KL 惩罚强度检查奖励模型评测准确率KL 散度快速飙升学习率过大或 beta 值过小查看训练日志中 kl 指标降低学习率增大 beta训练显存不足多模型同时加载检查显存占用尝试降低 batch size使用模型卸载、LoRA、梯度检查点生成内容多样性骤降熵正则过弱查看 entropy 指标变化提高熵系数训练过程崩溃数值不稳定检查 reward 是否存在极端值对 reward 做归一化或裁剪PPO 效率远低于 DPO 且不稳定组件过多调参空间大检查四个模型的工作状态先用 DPO 跑通确认数据有效后再上 PPO对齐后通用能力下降明显对齐税过重对比训练前后通用 benchmark在训练数据中混合通用 SFT 数据10. 最佳实践与工程建议10.1 数据先行模型后行很多团队在 RL 上踩坑问题往往不是算法本身而是数据。偏好数据的质量、覆盖度和区分度决定了 RL 效果的上限。这里给出三个建议第一偏好数据要来自真实业务场景不要使用开放域的通用问答数据做垂直领域对齐。第二chosen 和 rejected 的质量差距要大如果两者的差异过于细微奖励模型很难学到有效信号。第三控制数据规模的优先级高于盲目增加数据量5000 条高质量偏好对的效果通常优于 50000 条自动构造的低质量数据。10.2 从 DPO 入手验证数据有效性如果你所在的团队还没有成熟的 RL 工程能力我强烈建议先用 DPO 做一轮快速验证。DPO 的训练流程更简单、更稳定能帮你快速确认“手头的偏好数据是否有效”。如果 DPO 的效果提升有限先不要直接跳到 PPO而是回头优化数据。等 DPO 在评测集上取得了明显收益再考虑用 PPO 冲击更高的效果上限。10.3 奖励模型需要持续维护奖励模型不是训练一次就能永久使用的。随着业务数据的更新、用户偏好的变化奖励模型也需要定期迭代。把奖励模型的训练和维护当成一个独立的工程模块来运营而不是某次 RL 训练的临时组件这是一个值得写在团队规划里的长期判断。10.4 关于部署与推理RL 训练的产物仍然是常规的 causal LM 模型部署方面和普通微调模型没有区别。但要注意RL 训练后的模型对 Prompt 风格和历史对话的敏感度可能发生变化。上线前务必用真实用户 Prompt 做回归测试并且在小流量范围灰度一段时间时刻关注生成内容的长度分布、拒绝率、安全率等指标。10.5 安全边界提醒在 RLHF 实践中涉及人工标注偏好数据时务必对标注规范做严格管理。标注数据中不能包含任何违法违规、涉及隐私泄露或不符合公序良俗的内容。同时奖励模型的训练目标中应该包含安全约束否则模型可能为了迎合部分用户的恶意请求而输出不当内容。RLHF 的最终目标是让模型更安全、更有用而不是“更会讨好任何人”。11. 总结与后续学习方向这篇文章作为 RL for LLMs 系列的第一篇重点讲清楚了四个问题SFT 为什么不够、RL 解决了什么、RLHF 的四步流程是什么、PPO 和 DPO 分别适合什么场景。同时也给出了一条从零开始的实践路径先用 SFT 模型热身再构造高质量偏好数据用 DPO 验证数据有效性最后再考虑上 PPO 追求极致效果。如果你觉得自己的基础还不够扎实下一步优先补齐两方面的知识一是 Transformer 和语言模型的基本原理特别是自回归生成的过程二是策略梯度的数学推导至少理解“最大化期望奖励”和“限制策略偏移”这两个核心思想。有了这两块基础之后再去看 PPO、DPO 的论文或者源码会顺畅很多。从工程视角看我的判断是未来 LLM 应用层竞争的核心很大一部分会落在“用 RL 把模型决策优化到什么程度”上。SFT 只是入门RL 才是那个真正决定模型能力上限和业务适配度的关键环节。建议收藏这篇作为入门地图认真跑通一个 DPO 实验再顺着这篇的逻辑深入单点技术。后面我会继续写策略优化细节、奖励模型训练、多轮对话场景下的 RL 应用以及 Agent 与 RL 交叉的实践内容。