大模型自改进实战：自一致性投票与伪标签微调全流程

简介这份PDF文档《Large Language Models Can Self-Improve》面向自然语言处理研究者、大模型算法工程师及对AI自我进化机制感兴趣的进阶学习者聚焦一个核心问题大模型能否在不依赖人工标注数据的前提下提升自身推理能力。文档共1个PDF文件压缩包约532KB内容为完整英文研究论文含摘要、引言、方法、消融实验与结果分析等标准学术结构便于系统研读与引用。论文提出利用预训练LLM对未标注问题生成高置信度的思考链增强答案再以这些自生成解作为目标输出进行微调使540亿参数模型在GSM8K上从74.4%提升至82.1%、DROP从78.2%升至83.0%、OpenBookQA从90.0%升至94.4%、ANLI-A3从63.4%升至67.9%全程未使用真实标签。消融研究进一步表明基于推理的微调是自我提升的关键。目前已有366人学习适合希望深入理解无监督自我改进范式、借鉴实验设计与评估指标的读者精读参考。1. 自改进这件事为什么值得你花一个周末跑通大模型自改进Self-Improve这个词最近被提得很多但真正动手跑过一轮的人不多。我第一次认真读那篇讲 LLM 自我提升的论文时最直接的感受是它没有引入任何外部标注数据也没有依赖更强的教师模型只靠模型自己生成答案、自己打分、自己筛选就能在推理类任务上把准确率往上抬一截。这件事对一线工程师的意义很实在——你手里如果只有一个基础模型和一批无标注问题理论上就能启动一轮迭代不需要额外买标注、不需要等人工评审。它适合谁适合手头有推理类任务数学题、逻辑题、代码补全且已经能跑通基础推理的团队。不适合指望它解决知识幻觉或事实性错误的人因为自改进主要优化的是「解题路径的稳定性」不是「知识边界的扩展」。下面我把这套流程拆成能复现的步骤包括数据怎么造、答案怎么筛、参数怎么设、哪里最容易翻车。2. 自改进的闭环到底转在哪几个齿轮上2.1 从「一个问题多个答案」到「一个答案多个投票」自改进的核心机制其实不复杂对同一道题让模型用较高的温度采样多次得到一组候选答案然后对这些答案做多数投票majority voting把票数最高的结果当作伪标签最后用这些伪标签去微调模型本身。下一轮再用微调后的模型重复这个过程。这里有个容易被忽略的细节多数投票能成立的前提是「错误答案足够分散正确答案足够集中」。如果模型对某道题的所有采样都错得一模一样投票就失效了。所以温度不能太低否则采样多样性不够也不能太高否则正确答案本身被稀释。常见做法是把温度设在 0.7 到 1.0 之间top-p 保持在 0.9 到 0.95。2.2 为什么用「自一致性」而不是「自我批评」很多人第一反应是让模型自己写评语、自己打分。这条路我试过翻车率很高模型对自己的错误往往过于宽容打分和实际正确率的相关性很弱。自一致性self-consistency绕开了这个问题——它不要求模型判断对错只要求答案之间相互投票。投票是一种弱监督但它比自我评分稳定得多因为不需要模型具备「元认知」能力。代价是采样成本。一道题采 8 次推理开销就是 8 倍。所以实际落地时通常只对训练集做多轮采样推理阶段仍然用单次前向。这个成本账要提前算清楚。2.3 最小可跑通的伪代码结构# 自改进单轮循环的骨架不依赖具体框架 def self_improve_round(model, questions, sample_n8, temperature0.8): pseudo_labels [] for q in questions: # 1. 同一问题多次采样 candidates [model.generate(q, temperaturetemperature) for _ in range(sample_n)] # 2. 提取最终答案假设答案在特定标记后 answers [extract_final_answer(c) for c in candidates] # 3. 多数投票 best_answer, votes majority_vote(answers) # 4. 只保留投票一致性高的样本 if votes / sample_n 0.5: pseudo_labels.append((q, best_answer)) # 5. 用伪标签做一轮监督微调 model.finetune(pseudo_labels) return model这段代码里最关键的不是采样而是第 4 步的过滤阈值。votes / sample_n 0.5意味着至少一半的采样结果一致才保留。阈值设太低噪声标签会污染微调设太高可用样本量骤减。我一般会先统计投票分布的直方图再决定阈值而不是拍脑袋定 0.5。2.4 采样数量与收益的边际曲线采样数从 4 提到 8准确率通常有明显提升从 8 提到 16提升幅度就明显放缓但推理成本线性增长。对于大多数推理任务8 是一个性价比比较平衡的点。如果任务本身答案空间很小比如选择题4 次采样就够如果是开放式数学证明可能需要 16 次以上才能让投票稳定。3. 把自改进跑起来数据构造、采样与微调的三段式操作3.1 第一步构造无标注问题集与答案提取规则自改进的起点是一批「只有问题、没有答案」的数据。来源可以是现有训练集的题目部分也可以是从业务日志里脱敏后的问题。关键是每道题必须有明确的最终答案格式否则投票无法进行。# 答案提取规则示例假设模型输出中答案在 #### 之后 import re def extract_final_answer(text): # 匹配最后一个 #### 后面的内容 matches re.findall(r####\s*(.), text) if matches: return matches[-1].strip() return None # 提取失败该样本丢弃提取规则必须和模型的输出格式严格对齐。如果模型有时写「答案是 42」有时写「#### 42」提取就会漏。解决办法是在采样前用 few-shot 示例固定输出格式或者在提取函数里做多模式匹配。我一般会先跑 50 条样本人工看一眼提取成功率低于 90% 就先调格式提示词不要急着往下走。3.2 第二步采样参数与投票过滤的实操配置采样阶段需要控制的参数不止温度。下面是常用配置的对照表参数推荐范围作用设错后的现象temperature0.7–1.0控制采样多样性太低投票无意义太高正确答案被淹没top_p0.9–0.95截断低概率词太低答案重复太高出现乱码sample_n4–16每题采样次数太少投票不稳太多成本失控vote_threshold0.4–0.6保留样本的一致性门槛太低噪声大太高样本少max_tokens按任务定防止截断太小答案不完整提取失败投票过滤的代码逻辑如下from collections import Counter def majority_vote(answers): # 过滤掉提取失败的 None valid [a for a in answers if a is not None] if not valid: return None, 0 counter Counter(valid) best, count counter.most_common(1)[0] return best, count注意count是绝对票数后面要和sample_n做除法得到一致性比例。如果某道题所有答案都不同count就是 1一致性比例极低直接丢弃。3.3 第三步用伪标签做轻量微调拿到伪标签后微调阶段不需要太重的配置。学习率通常比正常监督微调低一个数量级因为伪标签本身有噪声学习率太大会把噪声学进去。# 微调命令示例以常见训练脚本的参数风格为例 python train.py \ --train_file pseudo_labels.jsonl \ --learning_rate 1e-5 \ --num_train_epochs 1 \ --per_device_batch_size 4 \ --gradient_accumulation_steps 8 \ --warmup_ratio 0.03 \ --lr_scheduler_type cosinenum_train_epochs设为 1 是常见做法因为伪标签只值得过一遍。跑多个 epoch 会让模型过拟合到投票产生的特定模式上反而降低泛化。gradient_accumulation_steps用来在显存有限时模拟更大 batch一般凑到等效 batch size 32 左右比较稳。微调完成后用同一批问题再跑一轮采样和投票对比准确率变化。如果第二轮没有提升说明第一轮的伪标签质量不够需要回头检查提取规则或投票阈值。4. 避坑自改进里最容易翻车的五个地方4.1 投票一致性很高但准确率反而下降现象过滤后保留了 80% 的样本投票一致性看起来很好但微调后模型在验证集上掉点。原因模型对某类错误答案存在系统性偏好多次采样都收敛到同一个错误答案投票一致性高但标签是错的。这种情况在模型本身能力不足时尤其常见。解决在投票前先做一轮「答案合理性检查」比如数学题可以用符号计算工具验证最终结果代码题可以跑单元测试。没有自动验证手段时至少人工抽检 100 条高一致性样本确认投票结果确实正确。4.2 答案提取失败率过高样本被大量丢弃现象采样了 8 次提取函数只返回 3 个有效答案其余都是 None。原因模型的输出格式不稳定或者提取正则写得太窄。常见于模型在推理过程中插入大量解释性文字最终答案被淹没。解决在提示词里用明确的格式指令比如「最后一行必须以 #### 开头后面只跟最终答案」。同时把提取函数改成多级回退先找 ####找不到再找「答案是」再找不到就取最后一行数字。回退逻辑要记录命中率方便定位问题。4.3 微调后模型只会输出投票最多的那种格式现象微调后模型在开放问题上变得很死板回答长度和结构高度一致。原因伪标签只保留了投票胜出的答案这些答案在格式上趋同模型学到了「格式模板」而不是「解题能力」。解决在伪标签里混入少量原始模型的高质量输出不经过投票筛选保持输出多样性。比例可以控制在 10% 到 20%。另外微调时的 dropout 不要设得太低保留一定的随机性。4.4 多轮迭代后性能不升反降现象第一轮提升明显第二轮持平第三轮开始下降。原因伪标签的噪声在多轮迭代中被逐步放大模型越来越自信地犯同样的错误。这是自改进最典型的退化模式。解决不要盲目跑多轮。每轮结束后在固定验证集上评估一旦连续两轮没有提升就停止。另外每轮可以重新从原始模型出发做微调而不是在上轮模型上继续微调这样能减缓退化。4.5 采样成本超出预期训练时间翻倍现象原本计划一天跑完的实验因为采样次数太多拖了三天。原因采样阶段是串行的每题 8 次采样意味着 8 倍推理时间。如果问题集有上万条开销非常可观。解决采样阶段用批量推理把同一批问题一次性喂给模型利用 GPU 并行。另外可以先在小规模子集上确定最佳采样数和阈值再全量跑。不要一上来就全量采样。5. 进阶用验证器加权投票替代朴素多数投票朴素多数投票假设每个采样答案权重相同但实际中有些答案的推理过程更可靠。一个值得尝试的进阶做法是训练一个轻量验证器对每个候选答案打分然后用分数加权投票。验证器的训练数据可以来自第一轮自改进中投票一致性高的样本作为正例一致性低的作为负例。验证器不需要很大一个小的分类头或者甚至基于规则的打分函数就能起作用。比如数学题可以用「最终答案能否代入原式成立」作为打分依据代码题可以用「能否通过已有测试用例」作为依据。# 加权投票示例每个答案带一个验证器分数 def weighted_vote(answer_score_pairs): score_sum {} for ans, score in answer_score_pairs: if ans is None: continue score_sum[ans] score_sum.get(ans, 0) score if not score_sum: return None return max(score_sum, keyscore_sum.get)加权投票相比朴素投票在验证器可靠的条件下能明显提升伪标签质量。但验证器本身如果偏差大反而会引入新的系统性错误。我一般会先用规则验证器跑一轮确认加权投票的收益后再考虑上模型验证器。另一个实用技巧是「答案归一化」。数学题的1/2和0.5应该被视为同一个答案代码题的空白差异应该被忽略。归一化函数要在投票前执行否则投票会被表面格式差异打散。这个细节看起来小但在实际跑的时候能影响好几个点的准确率。最后说一个我自己的习惯每轮自改进结束后我会把投票一致性最低的那 50 条样本单独拉出来看一遍。这些样本往往暴露了模型能力边界或者提取规则的漏洞比看整体准确率更有信息量。希望帮到你。本文还有配套的精品资源点击获取