简介这份PDF论文《Large Language Models Can Self-Improve》面向自然语言处理研究者、大模型算法工程师及对ChatGPT类技术感兴趣的进阶学习者聚焦一个核心问题大模型能否在无监督标注数据的情况下自我提升推理能力。论文提出利用预训练LLM生成高置信度的思考链增强答案再以这些自生成解作为目标输出进行微调从而在GSM8K、DROP、OpenBookQA、ANLI-A3等基准上显著提升540亿参数模型的通用推理表现且全程不依赖真实标签。资源包内仅含1个PDF文件大小约532KB便于快速下载与离线研读。内容涵盖引言、方法、消融实验与结果分析重点论证了基于推理的微调对自我提升的关键作用。目前已有366人学习适合希望深入理解大模型自我学习机制、探索无监督推理优化路径的读者参考。1. 当模型开始“自己教自己”一份无标注数据也能涨点的实战笔记手里只有一堆没答案的问题却想让大模型推理能力再上一个台阶这事放在两年前我会直接劝你放弃。但这份《Large Language Models Can Self-Improve》的论文拆完我发现它给了一条很实在的路子不碰人工标注只靠模型自己生成多条推理链、投票选出最一致的答案再拿这些“自产自销”的样本回炉微调。论文里 540B 参数的模型在 GSM8K 上从 74.4% 拉到 82.1%DROP 从 78.2% 到 83.0%全程没用一条 ground truth。这套方法叫 LMSILanguage Model Self-Improved适合手头有未标注业务数据、想低成本提升模型推理稳定性的团队也适合想搞懂 self-training 在 LLM 上到底怎么落地的工程师。下面我按“原理—复现—参数—避坑”的顺序把这份 PDF 里的关键设计拆成能直接抄的步骤。2. 拆开 LMSI 的黑匣子从 CoT 采样到多数投票的完整链路论文的核心链路其实就四步给问题加 few-shot CoT 示例 → 高温采样多条推理路径 → 多数投票筛出高置信答案 → 用这些答案做混合格式增强后微调。听起来简单但每一步都有设计细节漏掉一个就可能白跑。2.1 为什么必须是“推理增强”而不是直接微调答案论文的消融实验里有一个反直觉结论如果只拿多数投票选出的最终答案去微调提升非常有限必须把完整的 CoT 推理路径一起喂回去模型才能学到“怎么想”。这背后的逻辑是答案只是一个标签而推理路径包含了中间步骤的分布信息相当于 Hinton 说的 dark knowledge——软目标比硬标签携带更多相对概率信息。论文里明确写了“fine-tuning on reasoning is critical for self-improvement”所以你在构造训练样本时千万别图省事只留答案。具体到样本格式论文用了 mixed formats 做增强也就是同一个问题保留多条通向同一答案的推理路径并且这些路径的 prompt 模板不完全一样。这样做的好处是防止模型过拟合到某一种固定句式提升 OOD 泛化。我一般会保留 3 到 5 条不同表述的路径太少起不到增强效果太多会引入噪声。2.2 多数投票的阈值怎么定m 和 T 的联动关系采样条数 m 和温度 T 是这套方法里最需要调的两个参数。论文里 m 设的是 40T 在生成阶段用 0.7 左右但这不是死数。m 太小投票结果不稳定m 太大推理成本线性上涨。我的经验是对于 GSM8K 这类数学题m20 已经能拿到大部分收益m40 是边际递减前的甜点区对于 OpenBookQA 这种知识型任务m10 到 15 就够因为答案分布更集中。T 的选择更玄学一点。T 太低多条路径几乎一样投票没意义T 太高推理路径质量崩坏投票选出来的“高置信”答案可能是错的。论文在消融里试了 T0.5 到 1.0最终生成阶段用 0.7微调后的评估阶段反而用 greedy decodingT0。这里有个容易翻车的点生成训练数据时的 T 和最终推理时的 T 是两回事别混用。# 伪代码多数投票筛选高置信样本 from collections import Counter def filter_high_confidence(question, model, m40, T0.7): # 1. 高温采样 m 条 CoT 推理路径 paths [] for _ in range(m): output model.generate(question, temperatureT, max_tokens512) paths.append(output) # 2. 从每条路径里解析出最终答案 answers [extract_answer(p) for p in paths] # 3. 多数投票选出票数最高的答案 vote_counter Counter(answers) top_answer, top_count vote_counter.most_common(1)[0] # 4. 只保留通向 top_answer 的推理路径 kept_paths [p for p, a in zip(paths, answers) if a top_answer] # 5. 置信度阈值至少 1/3 的路径一致才保留 if top_count / m 0.33: return None # 丢弃低置信样本 return {question: question, paths: kept_paths, answer: top_answer}这段逻辑里m控制采样广度T控制多样性top_count / m是置信度门槛。论文没有硬性规定门槛值但我在复现时发现低于 0.3 的样本噪声极大宁可丢掉。extract_answer需要根据任务类型写正则数学题抓“The answer is X”选择题抓选项字母。2.3 混合格式增强同一答案的多路径怎么组织成训练样本筛出高置信样本后不能直接把原始输出拼起来微调。论文的做法是给每条路径套上不同的 prompt 模板比如有的用“Lets think step by step”有的用“Q: ... A:”有的直接给 CoT 示例格式。这样模型在微调时见到的输入分布更广推理时对 prompt 措辞的鲁棒性更强。我一般会准备 3 套模板按 1:1:1 分配。如果某个问题只筛出 2 条路径就随机选 2 套模板。注意模板里的 few-shot 示例要和当前任务领域匹配数学题配数学示例逻辑题配逻辑示例别混搭。3. 从 PDF 到可跑脚本数据构造、微调与评估的落地步骤把论文里的方法搬到自己环境最大的障碍不是算法本身而是数据管线和训练配置。这一章按“准备未标注问题集 → 生成自训练数据 → 微调 → 评估”的顺序把每个环节的参数和命令写清楚。3.1 未标注问题集的来源与预处理论文用的是多个 NLP 任务数据集的输入部分去掉了标签。你手头如果有业务日志里的用户提问、客服对话里的问题句都可以直接拿来用。关键要求是问题必须是自然语言问句且模型有能力通过 CoT 推理出答案。如果问题本身超出模型知识范围采样再多路径也投不出高置信答案只会浪费算力。预处理步骤我一般做三件事去重、过滤过短问题少于 5 个 token 的丢掉、按任务类型分桶。分桶的目的是后续配 few-shot 示例时能对号入座。比如数学应用题一个桶常识推理一个桶自然语言推断一个桶。每个桶至少准备 8 个带 CoT 的 few-shot 示例论文里用的是 8-shot我试过 4-shot 也能跑但 8-shot 的投票一致性明显更好。# 数据预处理示例去重并过滤短问题 python preprocess.py \ --input raw_questions.jsonl \ --output clean_questions.jsonl \ --min_tokens 5 \ --dedup truemin_tokens根据你的 tokenizer 调整中文场景下建议 8 到 10。dedup用简单的 MD5 去重就够别上语义去重容易误杀。3.2 生成自训练数据的批量推理配置生成阶段是整个流程里最吃算力的。论文用 540B 模型跑普通团队不可能有这个条件。我的建议是如果你的基座模型在 7B 到 13B 之间m 设 15 到 20 就够T 用 0.8 补偿模型能力不足带来的多样性缺失。批量推理时注意控制 batch size避免 OOM。# 批量生成自训练数据 from transformers import AutoModelForCausalLM, AutoTokenizer model AutoModelForCausalLM.from_pretrained(your-base-model) tokenizer AutoTokenizer.from_pretrained(your-base-model) def generate_training_data(questions, m20, T0.8, batch_size4): all_samples [] for i in range(0, len(questions), batch_size): batch questions[i:ibatch_size] for q in batch: sample filter_high_confidence(q, model, mm, TT) if sample: all_samples.append(sample) return all_samplesbatch_size根据显存调7B 模型在 24G 显存上跑 4 路并发比较稳。m和T的联动关系在 2.2 节说过这里不再重复。生成完后统计一下保留率如果低于 50%说明要么问题太难要么 T 太高需要回调。3.3 微调阶段的损失掩码与学习率设置微调时有一个关键细节损失只计算在推理路径和答案的 token 上问题部分的 token 要 mask 掉。论文没有明说这一点但这是 self-training 的常规做法否则模型会花精力去拟合问题分布而不是推理模式。学习率我一般用 1e-5 到 2e-5比常规微调小一档因为自训练数据本身有噪声学习率太大会放大噪声。# 微调时的 loss mask 示例 def tokenize_with_mask(question, reasoning_path, tokenizer): q_ids tokenizer(question, add_special_tokensFalse)[input_ids] r_ids tokenizer(reasoning_path, add_special_tokensFalse)[input_ids] input_ids q_ids r_ids labels [-100] * len(q_ids) r_ids # 问题部分 mask 掉 return {input_ids: input_ids, labels: labels}-100是 PyTorch CrossEntropyLoss 的默认 ignore_index。如果你的框架用别的值记得同步改。训练 epoch 数控制在 2 到 3多了会过拟合自训练数据里的错误模式。3.4 评估greedy 解码与多路径投票的差异对比论文里评估分了两种greedy decoding 和 multi-path voting。微调后的模型在 greedy 下就能涨点说明推理能力确实内化了多路径投票还能再高一点但推理成本翻倍。我一般先看 greedy 结果如果 greedy 没涨说明微调没学到东西得回头查数据质量。评估集要留一部分完全没参与自训练数据生成的问题用来测 OOD 泛化。论文里 AQUA、StrategyQA、MNLI 就是 OOD 测试集涨点幅度比 in-domain 小但方向一致。如果你发现 OOD 掉点大概率是自训练数据过拟合了某个任务的表面模式需要增加模板多样性或降低学习率。4. 避坑指南自训练数据构造中最容易翻车的五个点这套方法看起来步骤不多但每个环节都有隐蔽的坑。下面五条是我和身边同事复现时真实踩过的按“现象 → 原因 → 解决”整理。4.1 投票选出的“高置信”答案其实是错的现象某些问题的多数投票答案和常识矛盾但票数很集中。原因模型在某个错误推理模式上形成了局部一致T 太低导致路径多样性不足投票变成了错误共识。解决把 T 从 0.7 提到 0.9 重跑或者对投票结果做一次外部校验——数学题用计算器验算选择题用检索验证。论文里也提到 imperfect CoT 可以被利用但前提是错误率不能太高。4.2 微调后模型只会输出一种句式现象不管什么问题模型都用同一个模板回答推理步骤变得机械。原因混合格式增强没做到位训练样本里某一种模板占比过高。解决检查模板分配是否均匀强制每个问题至少用 2 种不同模板。如果已经跑完一轮可以用低学习率再微调一轮混入更多样式的样本。4.3 生成阶段显存爆炸现象批量采样时 OOM单条跑又太慢。原因m 设太大或者 max_tokens 没限制长推理路径把显存吃满。解决把 max_tokens 限制在 512 以内m 降到 15用 gradient checkpointing 换显存。如果还不行用 vLLM 或 TGI 做推理加速别硬扛。4.4 保留率过低导致训练数据不够现象筛完高置信样本后只剩不到 30% 的问题可用。原因基座模型能力不足或者问题领域和 few-shot 示例不匹配。解决先换更强的基座模型或者针对领域重新写 few-shot 示例。如果数据实在少可以把置信度门槛从 0.33 降到 0.25但要做好噪声变大的心理准备。4.5 微调后 in-domain 涨了但 OOD 掉了现象训练任务上的指标很好看换一个任务就崩。原因自训练数据覆盖的任务类型太单一模型过拟合了特定推理模式。解决在构造训练数据时混入多个任务类型的问题比例按 1:1:1 分配。论文的多任务设置就是干这个的别只拿一个数据集跑。5. 进阶玩法让模型自己生成问题和提示模板论文最后提了两个延伸方向一个是让模型从有限输入问题里生成更多问题另一个是让模型自己生成 few-shot CoT 提示模板。后者在 GSM8K 上拿到了 74.2% 的 zero-shot 成绩对比 Kojima 等人的 43.0% 提升巨大。我试过让模型自己写 few-shot 示例效果不稳定但配合人工筛选后确实能减少写 prompt 的工作量。具体做法是先给模型几个种子问题让它生成一批新问题再用第 2 章的方法筛高置信样本。生成的问题要过滤掉语义重复和过于简单的否则训练数据会退化。提示模板自生成则是让模型看几个 CoT 示例后自己总结一个模板出来你人工改一改就能用。验证自训练是否真的让模型“学会推理”而不是“记住答案”我一般用两个手段一是把评估集的问题做同义改写看指标是否稳定二是检查模型在中间步骤上的注意力分布如果微调后模型对推理关键词的注意力显著提升说明确实学到了推理模式。这两个手段论文没写但我在实际项目里靠它们判断过好几次该不该继续加数据。从那以后我每次跑自训练流程都强制先在小规模数据上验证保留率和投票一致性确认数据质量没问题再全量跑。希望帮到你。本文还有配套的精品资源点击获取