这次我们来看一个很有意思的大模型推理训练方法ReflectRL。项目全称是 Learning from Golden Negative Trajectories via Reflective-to-Direct Reasoning翻译过来就是“通过反思式到直接式推理从黄金负轨迹中学习”。一句话概括不浪费那些有代表性的错误推理轨迹而是先让模型学会反思“我为什么错”再把它训练成不显式反思也能直接做对。这个思路和常规的监督微调差别很大。常规 SFT 会保留正确答案的推理链错误样本直接被丢掉但 ReflectRL 关注的是那些“整体错误但很有代表性”的轨迹论文里叫 Golden Negative Trajectories也就是黄金负轨迹。模型必须先能定位错误、解释错误、修正错误最后把这种能力内化到直接推理里。对数学推理、逻辑推理、代码生成这类多步任务这个方向的价值非常明显训练阶段愿意花 token 分析错误推理阶段却不额外消耗 token适合对延迟和成本敏感的落地场景。本文会结合论文标题、公开研究趋势和常见 LLM 训练实践把 ReflectRL 涉及的核心模块拆开讲清楚黄金负轨迹怎么定义、训练数据怎么构造、反思训练和直接训练怎么衔接、评估方案怎么设计、训练完的模型怎么部署成推理服务。需要注意论文具体实验设置、benchmark 数值和开源仓库状态要以原文为准本文方法的解读部分我会尽量做到严谨。适合的读者做大模型 SFT、RLHF、推理优化的算法工程师以及想把 o1 式反思能力内化到自研模型里的技术同学。如果你只是来找一个能双击启动的本地推理工具这个项目不太一样它是方法研究型项目需要跟着实验流程走。1. 核心能力速览先给一张速览表快速判断 ReflectRL 适不适合你。能力项说明项目类型LLM 推理能力训练方法偏研究型不是最终应用工具核心机制从 Golden Negative Trajectories 学习实现 Reflective-to-Direct Reasoning训练思路先训练反思能力再训练直接推理能力推理阶段不显式输出反思直接生成结果降低 token 消耗和延迟适用任务数学推理、逻辑推理、代码生成、多跳问答等多步推理任务输入数据问题 黄金负轨迹 反思信号 正确推理轨迹训练硬件取决于底座模型规模小模型可单卡起步完整实验建议多卡是否支持 CPU训练基本需要 GPUCPU 只能做轻量推理测试接口 API需要自行部署推理服务常见用 vLLM FastAPI批量任务支持需要结合推理服务并发队列开源状态需以论文公开页面或代码仓库为准本文不假设已开源表格里的具体显存数字我没有写死因为底座模型、上下文长度、batch size、是否用 LoRA 都会影响占用后面单独讲性能观察。2. 方法动机与核心思想为什么只学正样本不够这是理解 ReflectRL 的起点。2.1 正负样本在推理训练里的角色差异标准 SFT 里我们用“问题-正确推理链”训练模型。模型学到的是一段正确的作答路径但它并不知道“哪里容易出错”。这就像一个人只背过标准答案但没看过错题集遇到变形题时容易在同一个坑里反复摔。错误轨迹之所以有价值是因为它模型真实错误分布。真正有效的不是随便一条错题而是那些错误类型稳定、错误节点清晰、修正后能变成正确路径的样本。这类样本就是 Golden Negative Trajectories。具体来说一条黄金负轨迹通常具备以下特征最终结果是错的但推理过程是完整的不是胡言乱语错误节点可以定位能指出从哪一步开始不对错误具有代表性同类问题中模型容易重复犯修正成本可控错误节点之后存在清晰的修复路径能写成自然语言的反思反馈供模型学习。如果一条错误轨迹是无意义的乱写或者错误随机性太强它就不具备学习价值甚至会把模型带偏。2.2 Reflective-to-Direct 的核心逻辑先看一条我们熟悉的路线模型在推理时先生成一段自我反思发现错误再修正最后给出答案。这种 inference-time reflection 能提升准确率但代价是生成 token 大幅增加。对线上服务来说延迟和成本都不可接受。ReflectRL 的设计目标是把这个反思能力“训练进模型”。整体可以拆成两个阶段Reflective stage输入问题和黄金负轨迹让模型输出反思分析定位错误节点、解释错误原因、给出修正方向Direct stage只输入问题让模型跳过显式反思直接输出正确的推理链。第二个阶段的训练依赖第一阶段获得的反思能力。也就是说反思不是推理时的一个附加步骤而是被压缩进了参数里。这个做法和“先学带辅助轮再拆辅助轮”的训练逻辑类似。先让模型在错误轨迹上做诊断理解推理断点在哪里再通过正确轨迹和奖励信号把诊断能力转化为一步到位的正确推理。2.3 和已有工作相比的差异点你在相关热搜词里会看到 Reflective-to-Direct Reasoning 和 Golden Negative Trajectories这实际上是把两个已有概念组合成了一个新的训练范式Self-Refine 类方法关注推理时反思但一般用正向样例拒绝采样微调也用过错误轨迹但通常直接丢掉或简单当作负例ReflectRL 的差异在于“黄金负轨迹”的质量要求以及“反思训练后做直接化”的两阶段路径。这个设计从学术角度看是合理的不过具体实现细节还是建议回到论文原文验证。3. 黄金负轨迹数据体系构建对 ReflectRL 来说数据质量直接决定上限。这一节讲数据字段设计、筛选标准和构造流程。3.1 训练数据需要哪些字段从标题反向推导一份典型的 ReflectRL 训练数据至少需要这几类字段字段作用question原始问题或任务描述golden_negative_trajectory模型产生的错误推理链要求结构完整wrong_answer该错误轨迹对应的最终错误结果correct_answer标准答案或验证器给出的正确结果reflective_feedback对错误节点的定位、原因分析和修正方向direct_trajectory不包含反思解析的正确推理链metadata难度、错误类型、抽样配置等信息这里给出一份 JSONL 格式的训练数据示例注意这是“一种可行的组织方式”实际以论文数据设计为准{ id: sample-0001, task: math, question: 一个水池有两个进水管单开甲管6小时注满单开乙管8小时注满两管同时开放需要多少小时注满, golden_negative_trajectory: 设工程量为1。甲管效率是1/6乙管效率是1/8。两管同时开的效率是1/6 1/8 7/24所以时间是24/7小时。但这里忽略了两个管同时开放时可能存在的相互干扰于是答案写成3小时。, wrong_answer: 3小时, correct_answer: 24/7小时, reflective_feedback: 错误出现在最后一步混淆了分式计算结果与整数近似。1/6 1/8 7/24倒数为24/7约等于3.43小时不能直接写成3小时。修正方向合并效率后取倒数保留分数形式不要提前取整。, direct_trajectory: 设工程总量为1。甲管效率1/6乙管效率1/8合并效率1/6 1/8 7/24。所需时间为1 / (7/24) 24/7小时。, metadata: { difficulty: easy, error_type: computation_error, source: sampled_from_base_model } }这份数据的要点是golden_negative_trajectory和direct_trajectory描述的是同一个问题错误轨迹在结构上接近正确轨迹只是在某个推理节点出了偏差。这种“对比差”是最强的学习信号。3.2 黄金负轨迹从哪里来一个通用生成流程是用基座模型在训练集上采样多次推理链设置温度 0.7 到 1.0增加路径多样性用验证器或标准答案判断结果正误保留最终结果错误的轨迹对错误轨迹做结构解析按步骤切分定位错误节点可以用规则判断比如计算步骤前后不一致、公式使用错误、条件代入错误也可以用一个较强的模型来做错误标注过滤低质量样本删除推理过程不完整、存在重复循环、与问题无关的轨迹对剩余的轨迹打分排序筛选出“修正成本低、错误原因清晰”的样本作为黄金负轨迹。这里要特别注意负样本不是越多越好。如果数据里塞满了低质量噪声模型学到的是“乱输出也可以”反而伤害推理质量。3.3 错误类型的归类和去重为了训练稳定建议在 metadata 里记录 error_type例如computation_error计算错误formula_error公式用错condition_error条件代入错误logic_error推理逻辑断裂missing_step关键步骤缺失approximation_error过早近似导致答案偏差。去重逻辑不要只看问题文本还要看错误轨迹的相似度。两个问题不同但错误模式相同是有价值的扩充同一个问题采样出大量几乎一致的错误轨迹则要抽样控制数量。4. 复现实验环境准备ReflectRL 不是开箱即用的 WebUI而是一套训练流程。环境准备分三块硬件、软件、数据。4.1 硬件要求训练阶段对硬件要求较高。具体的显存取决于底座模型参数量、上下文长度、batch size 和是否使用 LoRA。一个稳妥的建议是先用 7B 或更小的模型跑通整个两阶段流程起步阶段用 LoRA / QLoRA 降低显存压力完整复现论文效果通常需要多卡环境例如多张 24GB 以上显存的 GPUCPU 基本不用考虑训练推理阶段如果模型量化足够小可以试。不要凭一张卡硬跑 70B 级别模型这样会浪费大量时间在 OOM 排查上。4.2 软件依赖建议使用 Python 3.10 或更高版本并给项目单独建一个虚拟环境。通用依赖如下# 先确认显卡驱动和 CUDA nvidia-smi nvcc --version # 创建虚拟环境 python -m venv venv source venv/bin/activate # 安装 torch具体 cuda 版本号以机器驱动为准 pip install torch --index-url https://download.pytorch.org/whl/cu121 # 训练常用库 pip install transformers datasets accelerate peft deepspeed # RL / SFT 相关库可以根据自己的框架选择 pip install trl # 推理部署 pip install vllm fastapi uvicorn这里没有指定死版本号因为不同显卡驱动适配的 PyTorch 版本不同。装之前建议先看官方文档。4.3 数据目录规划建议按以下结构管理项目reflectrl/ ├── checkpoints/ │ ├── reflector/ # 阶段一反思模型 │ └── reasoner/ # 阶段二直接推理模型 ├── data/ │ ├── raw/ # 原始问题集 │ ├── negative/ # 采样出的错误轨迹 │ ├── refined/ # 筛选后的黄金负轨迹 │ ├── reflective_train.jsonl │ ├── direct_train.jsonl │ └── test.jsonl ├── scripts/ │ ├── build_data.py │ ├── train_stage1.py │ ├── train_stage2.py │ └── evaluate.py └── logs/分目录管理的好处是训练数据、过滤脚本、模型权重互不干扰出问题时容易回滚。5. 训练流程与实现思路这一节是核心。我会给出整体流水线和两阶段训练的伪代码你可以按自己选择的框架调整。5.1 整体训练流水线原始数据集 └─ 基座模型多路采样 └─ 结果校验 错误轨迹筛选 └─ 黄金负轨迹 反思标注 └─ 阶段一反思能力训练 └─ 阶段二直接推理训练 └─ 评估与部署阶段一产出的反思模型有两个用途一是作为后续直接推理训练的初始化二是可以用来生成反思数据扩充阶段二的数据。部分实现可能还会把反思模型当作奖励信号来源判断直接推理是否满足了修正方向。5.2 阶段一反思能力训练这个阶段的训练目标是给定问题与黄金负轨迹模型输出反思分析。输入模板可以设计为请分析以下错误推理过程中最关键的错误步骤并说明修正方向。 问题{question} 错误推理{golden_negative_trajectory} 反思结果目标输出是reflective_feedback字段。你可以用 SFT 来训练也可以把它设计成 RL 任务用“错误定位是否准确”作为奖励信号。先用 SFT 跑通是最省事的做法。5.3 阶段二直接推理训练这个阶段的输入只包含问题不再输入错误轨迹也不要求模型输出反思内容。目标输出是direct_trajectory。直接训练可以继续用 SFT但如果你想更贴近 ReflectRL 里的“RL”属性可以在 SFT 之后加一个偏好优化或策略优化阶段奖励来源包括最终答案正确率推理过程步骤是否完整是否避免了黄金负轨迹中出现过的错误节点输出长度是否控制在合理范围。这里给出一份两阶段训练过程的大小写清晰的 Python 伪代码。需要注意这是示意实现不是某个开源仓库的复制代码 ReflectRL 两阶段训练示意代码 依赖transformers / peft / trl具体模型名需要替换 import json from datasets import Dataset from transformers import AutoModelForCausalLM, AutoTokenizer, TrainingArguments from trl import SFTTrainer def load_jsonl(path): items [] with open(path, r, encodingutf-8) as f: for line in f: line line.strip() if line: items.append(json.loads(line)) return items # 阶段一数据问题 负轨迹 - 反思 def build_reflective_prompt(item): return ( 请分析以下错误推理过程中最关键的错误步骤并说明修正方向。\n f问题{item[question]}\n f错误推理{item[golden_negative_trajectory]}\n 反思结果 ) reflective_data load_jsonl(data/reflective_train.jsonl) reflective_dataset Dataset.from_list( [ {text: build_reflective_prompt(item) item[reflective_feedback]} for item in reflective_data ] ) # 阶段一训练输出目录checkpoints/reflector trainer_stage1 SFTTrainer( modelAutoModelForCausalLM.from_pretrained(your_base_model), tokenizerAutoTokenizer.from_pretrained(your_base_model), train_datasetreflective_dataset, argsTrainingArguments( output_dir./checkpoints/reflector, per_device_train_batch_size2, gradient_accumulation_steps8, learning_rate1e-5, num_train_epochs2, fp16True, logging_steps50, save_steps500, ), ) trainer_stage1.train()阶段二有两个选择直接在阶段一检查点基础上继续 SFT把反射模型微调成直接推理模型保留阶段一模型用它生成更多反思数据然后再做直接训练。第二种做法更接近论文的方法名 ReflectRL因为阶段一模型不只是中间产物它还给阶段二提供学习信号。# 阶段二数据只保留问题和正确推理 def build_direct_prompt(item): return f问题{item[question]}\n直接推理 direct_data load_jsonl(data/direct_train.jsonl) direct_dataset Dataset.from_list( [ {text: build_direct_prompt(item) item[direct_trajectory]} for item in direct_data ] ) # 继续在阶段一模型上训练 trainer_stage2 SFTTrainer( modelAutoModelForCausalLM.from_pretrained(./checkpoints/reflector/checkpoint-500), tokenizerAutoTokenizer.from_pretrained(your_base_model), train_datasetdirect_dataset, argsTrainingArguments( output_dir./checkpoints/reasoner, per_device_train_batch_size2, gradient_accumulation_steps8, learning_rate1e-5, num_train_epochs1, fp16True, logging_steps50, save_steps500, ), ) trainer_stage2.train()如果你要在阶段二引入强化学习可以用 TRL 的PPOTrainer也可以选择 DPO 之类的偏好优化方法奖励偏好对可以设计成“直接推理结果 vs 黄金负轨迹中的错误推理”。5.4 训练中的关键注意事项阶段二最怕灾难性遗忘。模型在阶段一刚学会反思阶段二如果只学直接推理可能把反思能力忘掉。缓解方法有几种在阶段二训练数据中混入少量反思样本做课程学习阶段二用较小学习率引入 KL 惩罚限制策略偏离反思模型太远定期在反思验证集上评估观察能力留存情况。训练日志里建议同时记录训练损失、验证准确率、平均生成 token 数。这三个指标能帮你判断模型是在“直接做对”还是“退化成什么都不输出的极简模式”。6. 模型评估与效果验证评估是整个实验里最容易做偏的部分。只测最终答案正确率不够要同时看推理过程质量和 token 成本。6.1 核心评估指标指标说明Final Answer Accuracy最终答案是否正确适合数学等有标准答案的任务PassK采样 K 次至少有一次正确适合代码生成Process Correctness推理过程步骤是否有逻辑断裂需要人工或模型打分Error Avoidance Rate是否避开了训练集中出现过的典型错误节点Token Efficiency直接推理模式的输出长度 / 反思推理模式的输出长度Reflection Quality阶段一模型是否能准确定位错误步骤只追求 accuracy 会鼓励模型输出更长的推理链然后蒙对答案只看 token 效率又会把模型逼成“简略但不完整”。建议两个方向都看。6.2 对照实验设计推荐至少跑三组对照Baseline A直接 SFT 正确轨迹即普通 CoT 微调Baseline B推理时显式反思即 inference-time reflectionReflectRL两阶段训练后直接推理。每组使用同样的训练集、验证集和评估脚本记录 accuracy 与平均输出 token。6.3 推理评估脚本示例下面的脚本基于 vLLMnormalize_answer函数需要根据自己的任务实现比如数学题可以把分数、小数、百分号做归一化代码题则要执行测试用例import json from vllm import LLM, SamplingParams def normalize_answer(text): # 示例去空白统一小写 # 数学题还需要把 3.43、3.43h、3.43小时 归一化 return .join(text.strip().lower().split()) def build_direct_prompt(question): return f问题{question}\n直接推理 model LLM( model./checkpoints/reasoner, tensor_parallel_size1, gpu_memory_utilization0.85, ) params SamplingParams(temperature0.0, max_tokens1024) data json.load(open(data/test.jsonl, r, encodingutf-8)) prompts [build_direct_prompt(item[question]) for item in data] outputs model.generate(prompts, params) hit 0 for item, out in zip(data, outputs): pred normalize_answer(out.outputs[0].text) gold normalize_answer(item[correct_answer]) if pred gold: hit 1 print(faccuracy: {hit / len(data):.4f})7. 推理部署与 API 调用模型训练完最终要接入业务。这里给出一套通用部署方案vLLM 加载模型FastAPI 暴露接口。7.1 FastAPI vLLM 服务示例# app.py from fastapi import FastAPI from pydantic import BaseModel from vllm import LLM, SamplingParams app FastAPI() llm LLM(model./checkpoints/reasoner, gpu_memory_utilization0.85) sampling_params SamplingParams(temperature0.0, max_tokens1024) class Query(BaseModel): prompt: str app.post(/v1/generate) def generate(query: Query): outputs llm.generate([query.prompt], sampling_params) return {response: outputs[0].outputs[0].text}启动服务uvicorn app:app --host 0.0.0.0 --port 8000注意把端口、模型路径、显存利用率按实际环境调整。如果你的模型部署在多卡tensor_parallel_size要设置成 GPU 数量。7.2 接口调用测试curl -X POST http://127.0.0.1:8000/v1/generate \ -H Content-Type: application/json \ -d {prompt: 问题一个水池两个进水管单开甲管6小时注满单开乙管8小时注满两管同时开放需要多少小时注满}返回结果应当是 JSON 格式包含response字段。7.3 批量任务批量任务要控制并发数避免一次性打爆显存。以下是一个通用并发调用示例import json import concurrent.futures import requests API_URL http://127.0.0.1:8000/v1/generate def call_api(question): resp requests.post(API_URL, json{prompt: question}, timeout120) return resp.json()[response] def batch_predict(test_file, max_workers8): data json.load(open(test_file, r, encodingutf-8)) questions [item[question] for item in data] with concurrent.futures.ThreadPoolExecutor(max_workersmax_workers) as pool: results list(pool.map(call_api, questions)) return results批量任务的建议单个请求设置超时时间防止模型生成过长并发数从小到大调观察显存和响应延迟写结果时保留原始数据 id方便后续对齐分析失败请求记录到失败队列单独重试。8. 资源占用与性能观察这一节给方法不写死具体数字。因为不同底座模型、上下文长度和训练策略资源占用差异很大。8.1 训练阶段显存观察训练时重点观察以下几个变量底座模型参数量上下文长度负轨迹和反思文本越长显存越高batch size 和梯度累积步数是否开启 gradient checkpointing是否使用 LoRA / QLoRA是否开启 DeepSpeed ZeRO 或多卡张量并行混合精度设置。如果你想在一张显卡上跑小规模实验建议用 QLoRA 4bit 量化并且把per_device_train_batch_size调小。7B 模型完整 SFT 的显存需求通常在 24GB 以上量化和 LoRA 可以明显降低但具体要以实际环境为准。观察命令最简单直接nvidia-smi -l 2每隔两秒刷新一次显存和利用率。训练日志里的train_runtime和train_samples_per_second也可以作为性能参考。8.2 推理阶段性能对比ReflectRL 最大的性能优势在推理阶段。对比两条路线显式反思模式模型生成错误分析 纠正过程输出 token 多耗时高直接推理模式模型一步输出最终推理输出 token 短吞吐量高。如果你要在线上对比两者建议直接记录“每请求平均生成 token 数”和“并发下的请求吞吐量”。vLLM 的日志里会有详细信息也可以用 Prometheus 拉取指标。8.3 性能调优手段推理用 vLLM 代替原生 transformers generate借助 PagedAttention 提升显存利用率设置gpu_memory_utilization时留出余量默认 0.9 在某些显卡上可能导致 OOM限制max_tokens防止模型因重复生成耗尽资源批处理请求时采用动态 batching避免单个长样本拖慢整体日志中打印 prompt token 数方便核算成本。9. 常见问题与排查方法问题现象可能原因排查方式解决方案训练时 CUDA out of memory显存不足batch size 过大或量化未开启查看 nvidia-smi 和训练日志调小 batch size开启 gradient checkpointing使用 LoRA/QLoRA模型始终不收敛黄金负轨迹噪声太大数据质量差抽看训练集反思标注质量提高筛选标准增加数据清洗减少低质量负样本反思输出大量幻觉反思训练数据不足或模型能力不够查看反思输出是否准确定位错误节点补充高质量反思标注增强底座模型提升负轨迹结构完整性阶段二训练后反思能力遗忘灾难性遗忘在训练日志中单独监控反思验证集准确率阶段二混入少量反思样本降低学习率加入 KL 约束直接推理输出退化变短模型学会偷懒奖励设计有问题检查输出 token 分布和过程完整性在训练目标中加入过程完整度指标惩罚过度简写RL 训练不稳定奖励信号稀疏、奖励噪声大观察 reward 曲线和 KL 散度增加奖励平滑调整 KL 系数先固定 reward model 再训练策略推理服务启动即 OOM显存利用率和并发设置不当查看服务启动日志和显存状态调低 gpu_memory_utilization使用多卡张量并行降低并发数API 请求响应超时输出 max_tokens 限制太大或并发过高检查请求耗时和队列堆积调小 max_tokens增加超时时间限流或增加副本测试集准确率高但业务数据效果差训练数据分布和业务分布不一致对比训练集与业务数据分布在业务数据上补充负轨迹采样做领域适应训练模型重复生成同一段内容推理温度过低或生成陷入循环检查输出序列调整温度设置 repetition_penalty调大 max_tokens 观察这十类问题基本覆盖了从训练到部署的常见坑。出现问题时先看数据和日志不要直接改模型结构。10. 最佳实践与使用建议10.1 先用小模型验证方法ReflectRL 这类训练方法不建议一上来就在超大模型上跑。先拿一个 1B 到 7B 的开源模型构造几百条黄金负轨迹跑通两阶段流程观察反思训练和直接训练是否有效。小模型跑通后再放大参数量能省很多时间和算力。10.2 负轨迹质量是首要因素黄金负轨迹的质量决定训练上限。宁可少而精不要多而杂。每次训练前抽 20 到 50 条数据人工检查确认错误轨迹结构完整错误节点描述一致反思反馈与错误节点对应直接推理链不包含反思内容。10.3 保留一份“反思模型”阶段一训练的反思模型不要删。它既可以在后续生成更多反思数据也可以作为阶段二训练时的奖励信号来源。在线上出现棘手推理问题时可以用反思模型做一次临时分析辅助定位问题。10.4 训练实验记录规范ReflectRL 涉及两阶段、多组训练配置实验记录必须规范。建议每个实验记录底座模型名称与版本数据集版本号和 hash黄金负轨迹筛选规则阶段一和阶段二的超参数训练时长、显存峰值、收敛情况评估指标和样本输出示例。这样后续复现和排错都容易。10.5 数据版权与合规使用实验数据的来源必须注意合规使用开源数据集时确认许可证允许用于模型训练数据集包含个人数据时需要脱敏和授权基座模型要遵守其模型许可和开源协议训练出的模型若对外提供服务要评估输出内容和安全边界涉及商业落地建议在正式环境评估后再发布示例。11. 总结与下一步ReflectRL 这个方向的亮点在于它把“错误轨迹”从训练垃圾变成了核心学习材料。黄金负轨迹的价值并不在于模型需要一遍遍复述错误而在于通过反思训练让模型理解错误产生的机制最后通过直接推理把这种理解固化进参数。推理阶段不显式反思却能做出看起来经过反思的决策这是它相比传统 CoT SFT 和 inference-time reflection 最有吸引力的地方。如果你想自己验证这个方法建议先从这三件事开始第一定义你的“黄金负轨迹”。从现有模型的采样错误里筛一批结构完整、错误可定位的样本做人工标注第二跑通阶段一的反思训练单独评测反思质量不看最终答案第三再跑阶段二的直接训练重点观察是否发生能力遗忘以及直接推理的 token 消耗比反思模式节省多少。最容易踩的坑是数据。负轨迹质量不够后续所有训练都是在噪声上做文章。其次要注意阶段二训练时对反思能力的保留不要只看最终答案准确率。如果你对大模型推理优化、负样本学习或 RL 训练感兴趣这个项目值得跟进。建议持续关注论文更新和可能的开源仓库拿到官方代码后再用真实数据在本地复现一轮。后面也可以把同样的思路迁移到代码生成、多模态推理、Agent 任务规划等场景看看“从错误中内化推理能力”在其他任务上是否同样有效。建议收藏备用。 ReflectRL：从黄金负轨迹中训练大模型反思与直接推理能力
这次我们来看一个很有意思的大模型推理训练方法ReflectRL。项目全称是 Learning from Golden Negative Trajectories via Reflective-to-Direct Reasoning翻译过来就是“通过反思式到直接式推理从黄金负轨迹中学习”。一句话概括不浪费那些有代表性的错误推理轨迹而是先让模型学会反思“我为什么错”再把它训练成不显式反思也能直接做对。这个思路和常规的监督微调差别很大。常规 SFT 会保留正确答案的推理链错误样本直接被丢掉但 ReflectRL 关注的是那些“整体错误但很有代表性”的轨迹论文里叫 Golden Negative Trajectories也就是黄金负轨迹。模型必须先能定位错误、解释错误、修正错误最后把这种能力内化到直接推理里。对数学推理、逻辑推理、代码生成这类多步任务这个方向的价值非常明显训练阶段愿意花 token 分析错误推理阶段却不额外消耗 token适合对延迟和成本敏感的落地场景。本文会结合论文标题、公开研究趋势和常见 LLM 训练实践把 ReflectRL 涉及的核心模块拆开讲清楚黄金负轨迹怎么定义、训练数据怎么构造、反思训练和直接训练怎么衔接、评估方案怎么设计、训练完的模型怎么部署成推理服务。需要注意论文具体实验设置、benchmark 数值和开源仓库状态要以原文为准本文方法的解读部分我会尽量做到严谨。适合的读者做大模型 SFT、RLHF、推理优化的算法工程师以及想把 o1 式反思能力内化到自研模型里的技术同学。如果你只是来找一个能双击启动的本地推理工具这个项目不太一样它是方法研究型项目需要跟着实验流程走。1. 核心能力速览先给一张速览表快速判断 ReflectRL 适不适合你。能力项说明项目类型LLM 推理能力训练方法偏研究型不是最终应用工具核心机制从 Golden Negative Trajectories 学习实现 Reflective-to-Direct Reasoning训练思路先训练反思能力再训练直接推理能力推理阶段不显式输出反思直接生成结果降低 token 消耗和延迟适用任务数学推理、逻辑推理、代码生成、多跳问答等多步推理任务输入数据问题 黄金负轨迹 反思信号 正确推理轨迹训练硬件取决于底座模型规模小模型可单卡起步完整实验建议多卡是否支持 CPU训练基本需要 GPUCPU 只能做轻量推理测试接口 API需要自行部署推理服务常见用 vLLM FastAPI批量任务支持需要结合推理服务并发队列开源状态需以论文公开页面或代码仓库为准本文不假设已开源表格里的具体显存数字我没有写死因为底座模型、上下文长度、batch size、是否用 LoRA 都会影响占用后面单独讲性能观察。2. 方法动机与核心思想为什么只学正样本不够这是理解 ReflectRL 的起点。2.1 正负样本在推理训练里的角色差异标准 SFT 里我们用“问题-正确推理链”训练模型。模型学到的是一段正确的作答路径但它并不知道“哪里容易出错”。这就像一个人只背过标准答案但没看过错题集遇到变形题时容易在同一个坑里反复摔。错误轨迹之所以有价值是因为它模型真实错误分布。真正有效的不是随便一条错题而是那些错误类型稳定、错误节点清晰、修正后能变成正确路径的样本。这类样本就是 Golden Negative Trajectories。具体来说一条黄金负轨迹通常具备以下特征最终结果是错的但推理过程是完整的不是胡言乱语错误节点可以定位能指出从哪一步开始不对错误具有代表性同类问题中模型容易重复犯修正成本可控错误节点之后存在清晰的修复路径能写成自然语言的反思反馈供模型学习。如果一条错误轨迹是无意义的乱写或者错误随机性太强它就不具备学习价值甚至会把模型带偏。2.2 Reflective-to-Direct 的核心逻辑先看一条我们熟悉的路线模型在推理时先生成一段自我反思发现错误再修正最后给出答案。这种 inference-time reflection 能提升准确率但代价是生成 token 大幅增加。对线上服务来说延迟和成本都不可接受。ReflectRL 的设计目标是把这个反思能力“训练进模型”。整体可以拆成两个阶段Reflective stage输入问题和黄金负轨迹让模型输出反思分析定位错误节点、解释错误原因、给出修正方向Direct stage只输入问题让模型跳过显式反思直接输出正确的推理链。第二个阶段的训练依赖第一阶段获得的反思能力。也就是说反思不是推理时的一个附加步骤而是被压缩进了参数里。这个做法和“先学带辅助轮再拆辅助轮”的训练逻辑类似。先让模型在错误轨迹上做诊断理解推理断点在哪里再通过正确轨迹和奖励信号把诊断能力转化为一步到位的正确推理。2.3 和已有工作相比的差异点你在相关热搜词里会看到 Reflective-to-Direct Reasoning 和 Golden Negative Trajectories这实际上是把两个已有概念组合成了一个新的训练范式Self-Refine 类方法关注推理时反思但一般用正向样例拒绝采样微调也用过错误轨迹但通常直接丢掉或简单当作负例ReflectRL 的差异在于“黄金负轨迹”的质量要求以及“反思训练后做直接化”的两阶段路径。这个设计从学术角度看是合理的不过具体实现细节还是建议回到论文原文验证。3. 黄金负轨迹数据体系构建对 ReflectRL 来说数据质量直接决定上限。这一节讲数据字段设计、筛选标准和构造流程。3.1 训练数据需要哪些字段从标题反向推导一份典型的 ReflectRL 训练数据至少需要这几类字段字段作用question原始问题或任务描述golden_negative_trajectory模型产生的错误推理链要求结构完整wrong_answer该错误轨迹对应的最终错误结果correct_answer标准答案或验证器给出的正确结果reflective_feedback对错误节点的定位、原因分析和修正方向direct_trajectory不包含反思解析的正确推理链metadata难度、错误类型、抽样配置等信息这里给出一份 JSONL 格式的训练数据示例注意这是“一种可行的组织方式”实际以论文数据设计为准{ id: sample-0001, task: math, question: 一个水池有两个进水管单开甲管6小时注满单开乙管8小时注满两管同时开放需要多少小时注满, golden_negative_trajectory: 设工程量为1。甲管效率是1/6乙管效率是1/8。两管同时开的效率是1/6 1/8 7/24所以时间是24/7小时。但这里忽略了两个管同时开放时可能存在的相互干扰于是答案写成3小时。, wrong_answer: 3小时, correct_answer: 24/7小时, reflective_feedback: 错误出现在最后一步混淆了分式计算结果与整数近似。1/6 1/8 7/24倒数为24/7约等于3.43小时不能直接写成3小时。修正方向合并效率后取倒数保留分数形式不要提前取整。, direct_trajectory: 设工程总量为1。甲管效率1/6乙管效率1/8合并效率1/6 1/8 7/24。所需时间为1 / (7/24) 24/7小时。, metadata: { difficulty: easy, error_type: computation_error, source: sampled_from_base_model } }这份数据的要点是golden_negative_trajectory和direct_trajectory描述的是同一个问题错误轨迹在结构上接近正确轨迹只是在某个推理节点出了偏差。这种“对比差”是最强的学习信号。3.2 黄金负轨迹从哪里来一个通用生成流程是用基座模型在训练集上采样多次推理链设置温度 0.7 到 1.0增加路径多样性用验证器或标准答案判断结果正误保留最终结果错误的轨迹对错误轨迹做结构解析按步骤切分定位错误节点可以用规则判断比如计算步骤前后不一致、公式使用错误、条件代入错误也可以用一个较强的模型来做错误标注过滤低质量样本删除推理过程不完整、存在重复循环、与问题无关的轨迹对剩余的轨迹打分排序筛选出“修正成本低、错误原因清晰”的样本作为黄金负轨迹。这里要特别注意负样本不是越多越好。如果数据里塞满了低质量噪声模型学到的是“乱输出也可以”反而伤害推理质量。3.3 错误类型的归类和去重为了训练稳定建议在 metadata 里记录 error_type例如computation_error计算错误formula_error公式用错condition_error条件代入错误logic_error推理逻辑断裂missing_step关键步骤缺失approximation_error过早近似导致答案偏差。去重逻辑不要只看问题文本还要看错误轨迹的相似度。两个问题不同但错误模式相同是有价值的扩充同一个问题采样出大量几乎一致的错误轨迹则要抽样控制数量。4. 复现实验环境准备ReflectRL 不是开箱即用的 WebUI而是一套训练流程。环境准备分三块硬件、软件、数据。4.1 硬件要求训练阶段对硬件要求较高。具体的显存取决于底座模型参数量、上下文长度、batch size 和是否使用 LoRA。一个稳妥的建议是先用 7B 或更小的模型跑通整个两阶段流程起步阶段用 LoRA / QLoRA 降低显存压力完整复现论文效果通常需要多卡环境例如多张 24GB 以上显存的 GPUCPU 基本不用考虑训练推理阶段如果模型量化足够小可以试。不要凭一张卡硬跑 70B 级别模型这样会浪费大量时间在 OOM 排查上。4.2 软件依赖建议使用 Python 3.10 或更高版本并给项目单独建一个虚拟环境。通用依赖如下# 先确认显卡驱动和 CUDA nvidia-smi nvcc --version # 创建虚拟环境 python -m venv venv source venv/bin/activate # 安装 torch具体 cuda 版本号以机器驱动为准 pip install torch --index-url https://download.pytorch.org/whl/cu121 # 训练常用库 pip install transformers datasets accelerate peft deepspeed # RL / SFT 相关库可以根据自己的框架选择 pip install trl # 推理部署 pip install vllm fastapi uvicorn这里没有指定死版本号因为不同显卡驱动适配的 PyTorch 版本不同。装之前建议先看官方文档。4.3 数据目录规划建议按以下结构管理项目reflectrl/ ├── checkpoints/ │ ├── reflector/ # 阶段一反思模型 │ └── reasoner/ # 阶段二直接推理模型 ├── data/ │ ├── raw/ # 原始问题集 │ ├── negative/ # 采样出的错误轨迹 │ ├── refined/ # 筛选后的黄金负轨迹 │ ├── reflective_train.jsonl │ ├── direct_train.jsonl │ └── test.jsonl ├── scripts/ │ ├── build_data.py │ ├── train_stage1.py │ ├── train_stage2.py │ └── evaluate.py └── logs/分目录管理的好处是训练数据、过滤脚本、模型权重互不干扰出问题时容易回滚。5. 训练流程与实现思路这一节是核心。我会给出整体流水线和两阶段训练的伪代码你可以按自己选择的框架调整。5.1 整体训练流水线原始数据集 └─ 基座模型多路采样 └─ 结果校验 错误轨迹筛选 └─ 黄金负轨迹 反思标注 └─ 阶段一反思能力训练 └─ 阶段二直接推理训练 └─ 评估与部署阶段一产出的反思模型有两个用途一是作为后续直接推理训练的初始化二是可以用来生成反思数据扩充阶段二的数据。部分实现可能还会把反思模型当作奖励信号来源判断直接推理是否满足了修正方向。5.2 阶段一反思能力训练这个阶段的训练目标是给定问题与黄金负轨迹模型输出反思分析。输入模板可以设计为请分析以下错误推理过程中最关键的错误步骤并说明修正方向。 问题{question} 错误推理{golden_negative_trajectory} 反思结果目标输出是reflective_feedback字段。你可以用 SFT 来训练也可以把它设计成 RL 任务用“错误定位是否准确”作为奖励信号。先用 SFT 跑通是最省事的做法。5.3 阶段二直接推理训练这个阶段的输入只包含问题不再输入错误轨迹也不要求模型输出反思内容。目标输出是direct_trajectory。直接训练可以继续用 SFT但如果你想更贴近 ReflectRL 里的“RL”属性可以在 SFT 之后加一个偏好优化或策略优化阶段奖励来源包括最终答案正确率推理过程步骤是否完整是否避免了黄金负轨迹中出现过的错误节点输出长度是否控制在合理范围。这里给出一份两阶段训练过程的大小写清晰的 Python 伪代码。需要注意这是示意实现不是某个开源仓库的复制代码 ReflectRL 两阶段训练示意代码 依赖transformers / peft / trl具体模型名需要替换 import json from datasets import Dataset from transformers import AutoModelForCausalLM, AutoTokenizer, TrainingArguments from trl import SFTTrainer def load_jsonl(path): items [] with open(path, r, encodingutf-8) as f: for line in f: line line.strip() if line: items.append(json.loads(line)) return items # 阶段一数据问题 负轨迹 - 反思 def build_reflective_prompt(item): return ( 请分析以下错误推理过程中最关键的错误步骤并说明修正方向。\n f问题{item[question]}\n f错误推理{item[golden_negative_trajectory]}\n 反思结果 ) reflective_data load_jsonl(data/reflective_train.jsonl) reflective_dataset Dataset.from_list( [ {text: build_reflective_prompt(item) item[reflective_feedback]} for item in reflective_data ] ) # 阶段一训练输出目录checkpoints/reflector trainer_stage1 SFTTrainer( modelAutoModelForCausalLM.from_pretrained(your_base_model), tokenizerAutoTokenizer.from_pretrained(your_base_model), train_datasetreflective_dataset, argsTrainingArguments( output_dir./checkpoints/reflector, per_device_train_batch_size2, gradient_accumulation_steps8, learning_rate1e-5, num_train_epochs2, fp16True, logging_steps50, save_steps500, ), ) trainer_stage1.train()阶段二有两个选择直接在阶段一检查点基础上继续 SFT把反射模型微调成直接推理模型保留阶段一模型用它生成更多反思数据然后再做直接训练。第二种做法更接近论文的方法名 ReflectRL因为阶段一模型不只是中间产物它还给阶段二提供学习信号。# 阶段二数据只保留问题和正确推理 def build_direct_prompt(item): return f问题{item[question]}\n直接推理 direct_data load_jsonl(data/direct_train.jsonl) direct_dataset Dataset.from_list( [ {text: build_direct_prompt(item) item[direct_trajectory]} for item in direct_data ] ) # 继续在阶段一模型上训练 trainer_stage2 SFTTrainer( modelAutoModelForCausalLM.from_pretrained(./checkpoints/reflector/checkpoint-500), tokenizerAutoTokenizer.from_pretrained(your_base_model), train_datasetdirect_dataset, argsTrainingArguments( output_dir./checkpoints/reasoner, per_device_train_batch_size2, gradient_accumulation_steps8, learning_rate1e-5, num_train_epochs1, fp16True, logging_steps50, save_steps500, ), ) trainer_stage2.train()如果你要在阶段二引入强化学习可以用 TRL 的PPOTrainer也可以选择 DPO 之类的偏好优化方法奖励偏好对可以设计成“直接推理结果 vs 黄金负轨迹中的错误推理”。5.4 训练中的关键注意事项阶段二最怕灾难性遗忘。模型在阶段一刚学会反思阶段二如果只学直接推理可能把反思能力忘掉。缓解方法有几种在阶段二训练数据中混入少量反思样本做课程学习阶段二用较小学习率引入 KL 惩罚限制策略偏离反思模型太远定期在反思验证集上评估观察能力留存情况。训练日志里建议同时记录训练损失、验证准确率、平均生成 token 数。这三个指标能帮你判断模型是在“直接做对”还是“退化成什么都不输出的极简模式”。6. 模型评估与效果验证评估是整个实验里最容易做偏的部分。只测最终答案正确率不够要同时看推理过程质量和 token 成本。6.1 核心评估指标指标说明Final Answer Accuracy最终答案是否正确适合数学等有标准答案的任务PassK采样 K 次至少有一次正确适合代码生成Process Correctness推理过程步骤是否有逻辑断裂需要人工或模型打分Error Avoidance Rate是否避开了训练集中出现过的典型错误节点Token Efficiency直接推理模式的输出长度 / 反思推理模式的输出长度Reflection Quality阶段一模型是否能准确定位错误步骤只追求 accuracy 会鼓励模型输出更长的推理链然后蒙对答案只看 token 效率又会把模型逼成“简略但不完整”。建议两个方向都看。6.2 对照实验设计推荐至少跑三组对照Baseline A直接 SFT 正确轨迹即普通 CoT 微调Baseline B推理时显式反思即 inference-time reflectionReflectRL两阶段训练后直接推理。每组使用同样的训练集、验证集和评估脚本记录 accuracy 与平均输出 token。6.3 推理评估脚本示例下面的脚本基于 vLLMnormalize_answer函数需要根据自己的任务实现比如数学题可以把分数、小数、百分号做归一化代码题则要执行测试用例import json from vllm import LLM, SamplingParams def normalize_answer(text): # 示例去空白统一小写 # 数学题还需要把 3.43、3.43h、3.43小时 归一化 return .join(text.strip().lower().split()) def build_direct_prompt(question): return f问题{question}\n直接推理 model LLM( model./checkpoints/reasoner, tensor_parallel_size1, gpu_memory_utilization0.85, ) params SamplingParams(temperature0.0, max_tokens1024) data json.load(open(data/test.jsonl, r, encodingutf-8)) prompts [build_direct_prompt(item[question]) for item in data] outputs model.generate(prompts, params) hit 0 for item, out in zip(data, outputs): pred normalize_answer(out.outputs[0].text) gold normalize_answer(item[correct_answer]) if pred gold: hit 1 print(faccuracy: {hit / len(data):.4f})7. 推理部署与 API 调用模型训练完最终要接入业务。这里给出一套通用部署方案vLLM 加载模型FastAPI 暴露接口。7.1 FastAPI vLLM 服务示例# app.py from fastapi import FastAPI from pydantic import BaseModel from vllm import LLM, SamplingParams app FastAPI() llm LLM(model./checkpoints/reasoner, gpu_memory_utilization0.85) sampling_params SamplingParams(temperature0.0, max_tokens1024) class Query(BaseModel): prompt: str app.post(/v1/generate) def generate(query: Query): outputs llm.generate([query.prompt], sampling_params) return {response: outputs[0].outputs[0].text}启动服务uvicorn app:app --host 0.0.0.0 --port 8000注意把端口、模型路径、显存利用率按实际环境调整。如果你的模型部署在多卡tensor_parallel_size要设置成 GPU 数量。7.2 接口调用测试curl -X POST http://127.0.0.1:8000/v1/generate \ -H Content-Type: application/json \ -d {prompt: 问题一个水池两个进水管单开甲管6小时注满单开乙管8小时注满两管同时开放需要多少小时注满}返回结果应当是 JSON 格式包含response字段。7.3 批量任务批量任务要控制并发数避免一次性打爆显存。以下是一个通用并发调用示例import json import concurrent.futures import requests API_URL http://127.0.0.1:8000/v1/generate def call_api(question): resp requests.post(API_URL, json{prompt: question}, timeout120) return resp.json()[response] def batch_predict(test_file, max_workers8): data json.load(open(test_file, r, encodingutf-8)) questions [item[question] for item in data] with concurrent.futures.ThreadPoolExecutor(max_workersmax_workers) as pool: results list(pool.map(call_api, questions)) return results批量任务的建议单个请求设置超时时间防止模型生成过长并发数从小到大调观察显存和响应延迟写结果时保留原始数据 id方便后续对齐分析失败请求记录到失败队列单独重试。8. 资源占用与性能观察这一节给方法不写死具体数字。因为不同底座模型、上下文长度和训练策略资源占用差异很大。8.1 训练阶段显存观察训练时重点观察以下几个变量底座模型参数量上下文长度负轨迹和反思文本越长显存越高batch size 和梯度累积步数是否开启 gradient checkpointing是否使用 LoRA / QLoRA是否开启 DeepSpeed ZeRO 或多卡张量并行混合精度设置。如果你想在一张显卡上跑小规模实验建议用 QLoRA 4bit 量化并且把per_device_train_batch_size调小。7B 模型完整 SFT 的显存需求通常在 24GB 以上量化和 LoRA 可以明显降低但具体要以实际环境为准。观察命令最简单直接nvidia-smi -l 2每隔两秒刷新一次显存和利用率。训练日志里的train_runtime和train_samples_per_second也可以作为性能参考。8.2 推理阶段性能对比ReflectRL 最大的性能优势在推理阶段。对比两条路线显式反思模式模型生成错误分析 纠正过程输出 token 多耗时高直接推理模式模型一步输出最终推理输出 token 短吞吐量高。如果你要在线上对比两者建议直接记录“每请求平均生成 token 数”和“并发下的请求吞吐量”。vLLM 的日志里会有详细信息也可以用 Prometheus 拉取指标。8.3 性能调优手段推理用 vLLM 代替原生 transformers generate借助 PagedAttention 提升显存利用率设置gpu_memory_utilization时留出余量默认 0.9 在某些显卡上可能导致 OOM限制max_tokens防止模型因重复生成耗尽资源批处理请求时采用动态 batching避免单个长样本拖慢整体日志中打印 prompt token 数方便核算成本。9. 常见问题与排查方法问题现象可能原因排查方式解决方案训练时 CUDA out of memory显存不足batch size 过大或量化未开启查看 nvidia-smi 和训练日志调小 batch size开启 gradient checkpointing使用 LoRA/QLoRA模型始终不收敛黄金负轨迹噪声太大数据质量差抽看训练集反思标注质量提高筛选标准增加数据清洗减少低质量负样本反思输出大量幻觉反思训练数据不足或模型能力不够查看反思输出是否准确定位错误节点补充高质量反思标注增强底座模型提升负轨迹结构完整性阶段二训练后反思能力遗忘灾难性遗忘在训练日志中单独监控反思验证集准确率阶段二混入少量反思样本降低学习率加入 KL 约束直接推理输出退化变短模型学会偷懒奖励设计有问题检查输出 token 分布和过程完整性在训练目标中加入过程完整度指标惩罚过度简写RL 训练不稳定奖励信号稀疏、奖励噪声大观察 reward 曲线和 KL 散度增加奖励平滑调整 KL 系数先固定 reward model 再训练策略推理服务启动即 OOM显存利用率和并发设置不当查看服务启动日志和显存状态调低 gpu_memory_utilization使用多卡张量并行降低并发数API 请求响应超时输出 max_tokens 限制太大或并发过高检查请求耗时和队列堆积调小 max_tokens增加超时时间限流或增加副本测试集准确率高但业务数据效果差训练数据分布和业务分布不一致对比训练集与业务数据分布在业务数据上补充负轨迹采样做领域适应训练模型重复生成同一段内容推理温度过低或生成陷入循环检查输出序列调整温度设置 repetition_penalty调大 max_tokens 观察这十类问题基本覆盖了从训练到部署的常见坑。出现问题时先看数据和日志不要直接改模型结构。10. 最佳实践与使用建议10.1 先用小模型验证方法ReflectRL 这类训练方法不建议一上来就在超大模型上跑。先拿一个 1B 到 7B 的开源模型构造几百条黄金负轨迹跑通两阶段流程观察反思训练和直接训练是否有效。小模型跑通后再放大参数量能省很多时间和算力。10.2 负轨迹质量是首要因素黄金负轨迹的质量决定训练上限。宁可少而精不要多而杂。每次训练前抽 20 到 50 条数据人工检查确认错误轨迹结构完整错误节点描述一致反思反馈与错误节点对应直接推理链不包含反思内容。10.3 保留一份“反思模型”阶段一训练的反思模型不要删。它既可以在后续生成更多反思数据也可以作为阶段二训练时的奖励信号来源。在线上出现棘手推理问题时可以用反思模型做一次临时分析辅助定位问题。10.4 训练实验记录规范ReflectRL 涉及两阶段、多组训练配置实验记录必须规范。建议每个实验记录底座模型名称与版本数据集版本号和 hash黄金负轨迹筛选规则阶段一和阶段二的超参数训练时长、显存峰值、收敛情况评估指标和样本输出示例。这样后续复现和排错都容易。10.5 数据版权与合规使用实验数据的来源必须注意合规使用开源数据集时确认许可证允许用于模型训练数据集包含个人数据时需要脱敏和授权基座模型要遵守其模型许可和开源协议训练出的模型若对外提供服务要评估输出内容和安全边界涉及商业落地建议在正式环境评估后再发布示例。11. 总结与下一步ReflectRL 这个方向的亮点在于它把“错误轨迹”从训练垃圾变成了核心学习材料。黄金负轨迹的价值并不在于模型需要一遍遍复述错误而在于通过反思训练让模型理解错误产生的机制最后通过直接推理把这种理解固化进参数。推理阶段不显式反思却能做出看起来经过反思的决策这是它相比传统 CoT SFT 和 inference-time reflection 最有吸引力的地方。如果你想自己验证这个方法建议先从这三件事开始第一定义你的“黄金负轨迹”。从现有模型的采样错误里筛一批结构完整、错误可定位的样本做人工标注第二跑通阶段一的反思训练单独评测反思质量不看最终答案第三再跑阶段二的直接训练重点观察是否发生能力遗忘以及直接推理的 token 消耗比反思模式节省多少。最容易踩的坑是数据。负轨迹质量不够后续所有训练都是在噪声上做文章。其次要注意阶段二训练时对反思能力的保留不要只看最终答案准确率。如果你对大模型推理优化、负样本学习或 RL 训练感兴趣这个项目值得跟进。建议持续关注论文更新和可能的开源仓库拿到官方代码后再用真实数据在本地复现一轮。后面也可以把同样的思路迁移到代码生成、多模态推理、Agent 任务规划等场景看看“从错误中内化推理能力”在其他任务上是否同样有效。建议收藏备用。