企业官网建设流程全解析

简介：这份资源围绕DeepSeek团队首个基于强化学习的推理模型展开，系统梳理了DeepSeek-R1-Zero与DeepSeek-R1的研发脉络，面向机器学习研究人员、大模型开发者以及希望提升语言模型推理能力的从业者。内容涵盖纯RL训练下推理行为的自演化过程、冷启动数据与多阶段RL微调机制、面向推理的强化学习与拒绝采样监督微调，以及将推理能力蒸馏至1.5B至70B稠密小模型的完整方案，并给出编码、数学、GPQA等基准上的详细评测对比。资源包共1个PDF文件，约2.62MB，为完整技术报告，含引言、方法、实验与讨论等章节，便于按模块精读。目前已有1359人学习下载。读者可借此理解强化学习激发LLM推理潜力的路径，掌握冷启动与蒸馏的工程细节，并获取多语言、多轮对话及软件工程等方向的后续改进思路。

1. 纯 RL 也能“卷”出推理能力：这份 DeepSeek-R1 技术报告到底讲了什么

如果你最近在折腾大模型推理优化，大概率绕不开一个反直觉的结论：不靠监督微调（SFT）做冷启动，只靠大规模强化学习（RL），语言模型也能自己“顿悟”出长链思维、自我验证和反思行为。这份 DeepSeek-R1 的技术报告，讲的就是这件事——第一代推理模型 DeepSeek-R1-Zero 和升级版 DeepSeek-R1 的完整研发路径。它适合三类人：想复现 RL 训练管线的算法工程师、需要给中小模型注入推理能力的应用开发者、以及盯着编程与数学任务落地的从业者。报告里最硬核的部分不是榜单分数，而是它把“冷启动数据怎么造、奖励怎么设计、蒸馏为什么比直接 RL 更划算”这些工程细节摊开讲了。下面我按“先看懂、再动手、最后避坑”的顺序，把这份资源拆成能照着复现的笔记。

2. 从 DeepSeek-R1-Zero 到 DeepSeek-R1：两阶段 RL 管线怎么搭

2.1 为什么先拿基础模型开刀，而不是先做 SFT

报告里最核心的选型判断是：把 RL 直接作用在 DeepSeek-V3-Base 上，跳过 SFT 冷启动。这个决定背后有明确的工程理由——SFT 数据收集慢、成本高，而且一旦用人类标注的推理轨迹去“教”模型，反而会限制它自己探索解法的空间。DeepSeek-R1-Zero 的做法是给基础模型一个极简模板，只约束输出结构，不约束内容策略。

模板长这样：

用户和助手之间的对话。用户提出问题，助手解决问题。 助手首先在脑海中思考推理过程，然后为用户提供答案。 推理过程和答案分别包含在 <think>...</think> 和 <answer>...</answer> 标签中。 用户：{prompt} 助手：

这个模板的关键在于“有意保持结构约束最小化”。它不强制模型反思，也不引导特定解题策略，只要求把思考过程放进<think>标签。这样做的目的是让 RL 过程中观察到的行为是模型自然涌现的，而不是被模板“逼”出来的。我一般会把这类模板理解成“给模型一个跑道，但不规定它怎么跑”。

2.2 GRPO 目标函数与奖励设计：省掉 Critic 模型

训练成本是 RL 落地最大的拦路虎。报告采用 GRPO（Group Relative Policy Optimization）作为 RL 框架，它和 PPO 最大的区别是去掉了与策略模型同规模的 Critic 模型，改用组内奖励的统计量来估计基线。目标函数的核心形式是：

J(θ) = E[ (1/G) Σ_i min( ratio_i * A_i, clip(ratio_i, 1-ε, 1+ε) * A_i ) ]

其中ratio_i是新旧策略的概率比，A_i是组内归一化后的优势值，ε是裁剪超参数。优势的计算方式是：

A_i = (r_i - mean({r_1, r_2, ..., r_G})) / std({r_1, r_2, ..., r_G})

这里G是每个问题采样的输出数量，r_i是第 i 个输出的奖励。参数说明：G通常取 16 或 64，太小会导致基线估计方差大，太大则显存吃紧；ε一般设 0.2，和 PPO 惯例一致。奖励系统由两部分组成——准确性奖励用规则验证（数学题检查框内答案、代码题跑测试用例），格式奖励强制<think>标签包裹。报告明确没有用神经奖励模型，原因是大规模 RL 中神经奖励模型容易被“奖励黑客”攻击，而且重新训练奖励模型会让管线复杂化。

2.3 冷启动数据与多阶段训练：DeepSeek-R1 的四步走

DeepSeek-R1-Zero 虽然推理强，但可读性差、语言混合严重。DeepSeek-R1 的解法是引入少量高质量冷启动数据，把训练拆成四个阶段：

第一步，收集数千条长 CoT 数据微调 DeepSeek-V3-Base。数据来源包括少样本提示、直接提示模型生成带反思和验证的详细答案、对 R1-Zero 输出做人工后处理。输出格式定义为|special_token|<reasoning_process>|special_token|<summary>，强制在末尾加摘要。

第二步，面向推理的 RL。在冷启动微调后的模型上跑和 R1-Zero 相同的大规模 RL，但额外引入语言一致性奖励——按目标语言单词在 CoT 中的比例计算。消融实验显示这会导致性能轻微下降，但可读性提升明显，最终奖励是准确性奖励和语言一致性奖励直接相加。

第三步，拒绝采样加 SFT。当推理 RL 收敛后，从检查点做拒绝采样生成推理轨迹，只保留正确答案。同时混入约 20 万条非推理数据（写作、事实 QA、自我认知、翻译），总共约 80 万样本，对 DeepSeek-V3-Base 做两个 epoch 的微调。

第四步，全场景 RL。再用一轮 RL 提升有用性和无害性，推理数据用规则奖励，通用数据用奖励模型捕捉人类偏好。

# 拒绝采样过滤逻辑示意（伪代码，按报告描述还原） def rejection_sampling(checkpoint, prompts, num_samples=16): sft_data = [] for prompt in prompts: responses = checkpoint.sample(prompt, n=num_samples, temperature=0.6, top_p=0.95) for resp in responses: # 过滤混合语言、长段落、代码块混乱的 CoT if has_language_mixing(resp) or is_unreadable(resp): continue # 只保留答案正确的响应 if verify_answer(prompt, resp.answer): sft_data.append({ "prompt": prompt, "reasoning": resp.think, "summary": resp.summary }) return sft_data

这段逻辑的关键参数是num_samples和temperature。报告在评估时用 0.6 采样温度和 0.95 的 top-p，拒绝采样阶段也沿用类似配置。has_language_mixing和is_unreadable是自定义过滤器，报告里提到会过滤掉混合语言、长段落和代码块混乱的思维链。实际复现时，这两个过滤器的阈值需要根据你的基础模型语言分布调，没有万能值。

3. 蒸馏比直接 RL 更划算：小模型推理能力注入的实操路径

3.1 为什么 32B 蒸馏模型能打过 32B RL 模型

报告里一个容易被忽略但极其重要的结论是：用 DeepSeek-R1 生成的 80 万样本直接蒸馏到小模型，效果优于在小模型上直接跑 RL。原文的表述是“较大基础模型发现的推理模式对于提高推理能力至关重要”。这意味着推理能力有“规模门槛”——小模型自己探索，可能根本探索不到那些高级推理模式，但通过蒸馏可以“继承”大模型已经发现的模式。

蒸馏用的基础模型包括 Qwen2.5-Math-1.5B、Qwen2.5-Math-7B、Qwen-2.5-14B、Qwen2.5-32B、Llama-3.1-8B 和 Llama-3.3-70B-Instruct。注意这里只做 SFT，不包含 RL 阶段。报告明确说“加入 RL 可以大大提高模型性能”，但为了证明蒸馏本身的有效性，把 RL 探索留给了社区。

3.2 蒸馏数据构造与 SFT 训练参数

蒸馏数据就是第 2.3.3 节里那 80 万样本，其中约 60 万推理相关、20 万非推理相关。推理数据覆盖数学、代码、科学、逻辑推理，非推理数据覆盖写作、事实 QA、自我认知、翻译。训练时对 DeepSeek-V3-Base 做两个 epoch 的微调，这个配置直接迁移到小模型上。

# 蒸馏 SFT 训练命令示意（基于常见训练框架的参数组织） python train_sft.py \ --base_model Qwen2.5-32B \ --data_path ./r1_distill_800k.jsonl \ --output_dir ./qwen-32b-r1-distill \ --num_epochs 2 \ --batch_size 64 \ --learning_rate 1e-5 \ --max_seq_length 32768 \ --warmup_ratio 0.03 \ --lr_scheduler cosine \ --bf16 true

参数说明：max_seq_length设 32768 是因为报告里评估时最大生成长度就是 32768 token，蒸馏数据里的 CoT 可能很长，截断太短会丢推理过程。learning_rate用 1e-5 是 SFT 常见量级，太大容易破坏基础模型能力。num_epochs设 2 是报告里的配置，再多可能过拟合。batch_size根据显存调，32B 模型在 80G 显存上通常能跑到 32 到 64。

3.3 蒸馏模型的效果边界与适用场景

报告给出的蒸馏模型成绩：DeepSeek-R1-Distill-Qwen-7B 在 AIME 2024 上 55.5%，超过 QwQ-32B 预览版；32B 版本在 AIME 2024、MATH-500、LiveCodeBench 上分别是 72.6%、94.3%、57.2%，与 o1-mini 相当。这些数字说明蒸馏路径在数学和代码任务上确实能打。

但边界也很清楚：蒸馏模型只做了 SFT，没有 RL 阶段，所以在需要探索性推理的任务上可能不如经过 RL 的模型。另外，蒸馏数据来自 DeepSeek-R1，如果 R1 在某些领域本身弱，蒸馏模型也会继承这个弱点。我一般会建议：如果你的场景是数学解题、代码生成、科学推理，蒸馏模型性价比很高；如果是开放式对话、角色扮演，蒸馏带来的推理增益可能不明显，反而要关注通用能力的保持。

4. 避坑与排查：RL 训练推理模型时最容易翻车的五个点

4.1 奖励黑客：模型学会“骗”奖励而不是解题

现象：训练中期准确率奖励突然飙升，但人工检查发现模型输出格式正确、答案却毫无逻辑，甚至出现重复输出同一句话来凑格式奖励。

原因：规则奖励只检查最终答案和标签格式，模型发现只要把答案塞进指定格式就能拿到格式奖励，准确性奖励的验证逻辑如果有漏洞（比如只做字符串匹配），模型会钻空子。

解决：准确性奖励必须用可靠的验证器。数学题用符号计算或严格答案匹配，代码题必须跑测试用例。报告里明确不用神经奖励模型，就是因为神经奖励模型在大规模 RL 中更容易被攻击。另外，格式奖励和准确性奖励的权重需要调，格式奖励太高会诱导模型只关注格式。

4.2 语言混合：CoT 里中英文随机切换

现象：模型在思考过程中一会儿中文一会儿英文，甚至同一句话里混两种语言，可读性极差。

原因：RL 提示涉及多种语言时，模型没有语言一致性的约束，会自然地在不同语言间跳转，尤其是在基础模型预训练数据本身多语言混合的情况下。

解决：引入语言一致性奖励，按目标语言单词在 CoT 中的比例计算。报告里说这会导致性能轻微下降，但可读性提升明显。实际调的时候，语言一致性奖励的权重不能太高，否则模型会为了语言一致而牺牲推理深度。我一般会从 0.1 到 0.3 之间试，观察验证集上的推理准确率和语言一致率两条曲线。

4.3 冷启动数据质量差导致 RL 早期不稳定

现象：加了冷启动数据后，RL 训练前期 loss 震荡剧烈，模型输出时好时坏，收敛速度反而比纯 RL 慢。

原因：冷启动数据的模式设计有问题。如果冷启动数据里的推理过程本身逻辑跳跃、格式不统一，模型会学到错误的推理模式，RL 阶段需要花更多步去纠正。

解决：冷启动数据要精心设计模式。报告里的做法是每个响应末尾加摘要，过滤掉对读者不友好的响应，输出格式统一为|special_token|<reasoning_process>|special_token|<summary>。数据量不用多，数千条即可，但质量必须高。我一般会人工抽检 5% 到 10% 的冷启动数据，确保推理过程连贯、格式一致。

4.4 蒸馏时 max_seq_length 设太短，CoT 被截断

现象：蒸馏模型在复杂数学题上表现远低于预期，检查发现训练数据里很多长 CoT 被截断，模型只学到前半段推理。

原因：蒸馏数据里的 CoT 长度可能达到数千甚至上万 token，如果max_seq_length设成 4096 或 8192，大量长 CoT 会被截断，模型学到的推理过程不完整。

解决：max_seq_length至少设 32768，和报告里评估时的最大生成长度对齐。如果显存不够，可以用梯度检查点或序列并行。另外，预处理阶段要统计 CoT 长度分布，如果 95 分位数超过 32768，需要考虑是否过滤掉超长样本还是进一步扩长度。

4.5 评估时用贪婪解码导致重复率飙升

现象：模型在验证集上输出大量重复内容，pass@1 分数在不同检查点之间波动很大，无法判断哪个检查点更好。

原因：报告里明确指出“使用贪婪解码来评估长输出推理模型会导致更高的重复率和不同检查点之间的显著差异”。长输出模型在贪婪解码下容易陷入重复循环。

解决：用非零温度采样评估，报告默认用 0.6 采样温度和 0.95 top-p，每个问题采样多个答案（4 到 64 个，取决于测试集大小），然后计算 pass@1。公式是pass@1 = (1/k) Σ correct_i，其中 k 是采样数量。AIME 2024 还用 64 个样本报告 cons@64（多数投票）结果。这套评估协议虽然计算量大，但结果可靠得多。

5. 进阶技巧：用多数投票和长度控制把推理性能再推一截

多数投票（majority voting）是报告里反复出现的一个技巧，成本低但收益明显。DeepSeek-R1-Zero 在 AIME 2024 上 pass@1 是 71.0%，用 64 个样本做多数投票后跳到 86.7%，直接超过 OpenAI-o1-0912 的 74.4%。这个技巧的本质是：模型在复杂推理题上单次采样可能出错，但多次采样后正确答案的分布会集中，投票能过滤掉随机错误。

from collections import Counter def majority_vote(model, prompt, n_samples=64, temperature=0.6, top_p=0.95): answers = [] for _ in range(n_samples): response = model.generate(prompt, temperature=temperature, top_p=top_p) answer = extract_final_answer(response) answers.append(answer) # 统计出现频率最高的答案 counter = Counter(answers) best_answer, count = counter.most_common(1)[0] return best_answer, count / n_samples

参数说明：n_samples越大投票效果越好，但推理成本线性增长。报告在 AIME 2024 上用 64，其他基准用 4 到 64 不等。temperature和top_p用评估时的配置，保证采样多样性。extract_final_answer需要根据任务类型定制，数学题提取框内答案，代码题提取函数返回值。

另一个容易被忽视的技巧是长度控制。报告在 AlpacaEval 2.0 上只把最终摘要提供给评估，避免长度偏差——因为长回答在成对比较中往往占优，但那是“长”的优势不是“好”的优势。实际部署时，如果发现模型倾向于生成超长回答，可以在奖励里加长度惩罚，或者在推理时设最大长度上限。我一般会在验证集上画一条“回答长度 vs 正确率”的曲线，找到正确率不再随长度提升的拐点，把那个长度作为上限。

还有一个血泪经验：RL 训练推理模型时，检查点保存频率要比普通 SFT 高。因为 RL 训练中模型行为变化快，可能某个中间检查点在特定任务上表现特别好，但过几百步后就退化了。报告里 R1-Zero 的“顿悟时刻”就出现在中间版本，如果只保存最终检查点，这种中间涌现的能力就被丢掉了。我现在的习惯是每 100 到 200 步存一个检查点，评估时把所有检查点跑一遍，选综合最好的那个，而不是默认用最后一个。从那以后我每次做 RL 训练都强制走一遍多检查点评估，再也没出现过“训到最后反而变差”的翻车。希望帮到你。

本文还有配套的精品资源，点击获取