AI自我造题与迭代训练：35B小模型如何逼近万亿参数效果

大概一年前大模型圈子里还流行一个简单粗暴的等式参数越多模型越强。于是我们看到万亿参数模型接连出现几百张GPU只是入场券训练一次的电费都够买一台不错的车。但现在这个等式开始被打破了。上海交通大学的一支研究团队把“35B参数模型打出万亿参数效果”这件事做到了台面上。初看是典型的“小模型逆袭”故事但真正值得开发者和算法工程师关注的不是参数量的逆袭而是它背后的训练范式变化模型开始自己造题自己评分自己挑选数据完成一轮又一轮的自我迭代。换句话说模型不再只是“被训练”的对象它开始参与训练自己的过程。这才是这篇文章真正想讲清楚的事所谓“AI给自己造题还能自我迭代”底层机制是什么为什么它能让35B的小模型撬动接近万亿模型的效果对普通开发者来说这种训练范式意味着什么有没有可能自己复现一个简化版本先说结论这个方向把“数据质量”从人工标注的瓶颈里解放了出来让高质量训练数据的规模不再受限于人类专家。如果你在做大模型微调、数据构造、RAG评测或者正在纠结“小模型到底能不能用”这篇文章值得读完。1. 这篇文章真正要解决的问题先泼一盆冷水如果只是看到“35B干赢万亿”然后得出结论“以后不用买大卡了小模型够了”那这个判断是错的。从材料看这个工作的核心成果不是“小模型全面超越大模型”而是“在特定训练范式下小模型通过自我生成数据、自我迭代达到了接近甚至超越超大模型的水平”。这里有一个非常关键的限定词特定训练范式。所以这篇文章要解决的问题是三个第一**它解决了数据稀缺的问题。**大模型训练最贵的不是算力而是数据。人类的文本数据快被用完了专家标注的偏好数据又贵又慢。如果模型能自己生成训练数据理论上数据的产量是无限的。第二**它解决了小模型能力天花板的问题。**以前我们觉得35B模型再调也就那样因为知识容量在那摆着。但上交大这个工作说明当训练数据的质量和分布足够好时35B模型可以在很多任务上逼近更大的模型。第三**它解决了“迭代闭环”的问题。**传统训练流程是人类收集数据 → 人类标注 → 训练模型 → 人类评估 → 再收集数据。这个循环里人类是瓶颈。新的范式是模型自己出题 → 自己回答 → 自己评分 → 挑选高质量结果 → 继续训练自我迭代。人类只在关键节点把关。如果你正在做大模型应用开发可能最关心的是这个范式跟我的日常工作有什么关系关系很大。很多人做私有化部署发现7B、14B模型效果不够于是直接上70B结果GPU内存吃紧、推理延迟飙升。但如果把“自我迭代”的思路引入微调阶段小模型的能力是可以被明显抬升的。这才是这个工作对普通开发者最直接的启示。2. 核心概念拆解造题、评分、迭代到底在说什么在深入代码之前先把几个概念讲扎实。因为不搞清楚这些词后面看什么都是雾里看花。2.1 什么是“模型自己造题”传统做法里训练数据几乎都来自人类人类写文章、人类写代码、人类回答数学题。就算用GPT-4去生成数据最后也还是要人来筛选一遍。这就像老师给学生出题——老师见过多少题学生的视野就局限在多少题里。“自我造题”的意思是模型根据已有的知识基础自己生成新的问题。这个问题可以是数学题、代码任务、逻辑推理也可以是某个领域的小测验。它最大的价值在于问题生成的数量和质量不再受人类标注速度的限制。从材料看上交大这个工作里模型会针对自身的薄弱点主动生成训练样本相当于学生自己找出自己哪里不会然后自己给自己出专项练习题。2.2 什么是“自我评分”问题来了模型自己出的题答案可能也是错的。如果拿错误答案去训练自己那不是南辕北辙吗所以“自我评分”机制是整套流程里最关键的保险丝。模型生成答案之后会有一个评分模块去判断答案的准确性、完整性和逻辑一致性。这个评分模块可能是另一个模型也可能是同一个模型用不同的prompt方式来做判别。这就像学生自己批改作业写完题之后再拿参考答案或者是自己的知识体系去核对。如果判断能力足够强这个自产自销的数据循环就能良性运转。2.3 什么是“自我迭代”自我迭代是结果的累积第一轮模型生成一批数据筛选后拿去训练得到模型v2v2比v1强所以v2生成的数据质量也更高再筛选再训练得到v3。每一轮迭代都站在上一轮的肩膀上数据质量呈螺旋式上升。从材料看这正是“35B干赢万亿”的核心机制——不是一次训练完成的而是多轮自我对齐、自我强化的结果。2.4 三个概念之间的逻辑关系用一张简单的表格把这几个概念的关系说清楚概念通俗理解解决的核心问题自我造题模型自己出练习题数据产量突破人工限制自我评分模型自己批改作业数据质量有保障自我迭代越学越强再学更强模型能力持续上升这三件事合在一起构成了一个不再依赖人类持续介入的训练闭环。这也回应了标题里“AI开始给自己造题还能自我迭代”的真正含义。3. 为什么说这可能是新的技术范式要理解这个工作为什么值得关注就需要把它放到大模型训练方法的演进时间线里看。3.1 从“人类教AI”到“AI教AI”过去两三年大模型的主流训练流程基本是预训练在海量无标注文本上学习语言规律。监督微调SFT用人类写好的指令-回答对训练。人类反馈强化学习RLHF人类对模型回答排序打分让模型学会对齐人类偏好。这套流程最大的问题在于每个环节都有人类参与而人类的参与速度就是整个系统的天花板。特别是RLHF阶段人工标注一份偏好数据的成本并不低而且很多领域的专家比如医疗、法律、数学本身就稀缺。新范式的核心转变在于把“人类提供数据 → 模型学习”变成“模型生成数据 → 模型筛选 → 模型学习”的自我循环。人退到幕后只在关键节点做审查和校准。3.2 和传统数据飞轮的本质差异业界早就有“数据飞轮”的说法产品用户越多产生的数据越多模型越好。但传统数据飞轮依赖真实用户行为产生数据周期长、噪音大、成本高。自我造题范式相当于把数据飞轮搬进了训练机房模型对照自己的不足主动合成“虚拟用户”会问的问题。不需要等真实用户来提问也不需要雇标注团队去整理。这个改变对研究团队和中小公司来说意味着数据成本的结构性下降。3.3 为什么35B能逼近甚至追平万亿参数这个问题需要从两个维度来看。首先是知识压缩效率。万亿参数模型确实拥有更强的记忆容量但它的很多能力优势本质上是“见多识广”带来的。如果35B模型通过自我迭代把最高质量的解题路径、推理模式反复强化那么它在特定任务分布上可以表现出与万亿模型相当的水准。其次是数据分布的对齐程度。万亿模型的通用能力强是因为它要在海量任务上均衡发力。但35B模型如果专注在自我生成的、贴近自身能力边界的数据上训练它相当于是“专项特训”。在专项任务上特训的专业选手完全可以和全能选手一较高下。从材料里的信息看“35B干赢万亿参数大模型”并不是说全面碾压而是在多个基准任务上达到甚至超过这已经是一个值得从业者认真对待的信号了。4. 如何理解这套训练流程从数据生成到模型更新现在进入稍微技术一点的层面。这一节会拆解“自我造题自我迭代”训练流程的整体逻辑为后面动手实践做个铺垫。4.1 整体训练循环把整个流程抽象成四个阶段阶段一问题生成。从已有语料、任务描述或模型自身知识库中提取主题让模型生成一批指令或问题。需要覆盖不同难度、不同领域避免单一分布。阶段二答案生成与过滤。模型对生成的问题给出回答。然后通过规则校验、模型评分等机制过滤掉低质量样本。数学题就核对答案代码题就跑测试用例开放题就做质量打分。阶段三增量训练。把过滤后的高质量数据作为新的训练集对当前模型做一轮监督微调或偏好优化。这里一般会混合原始训练数据防止灾难性遗忘。阶段四评估与更新。在测试集上评估新模型效果如果指标提升则把新模型作为下一轮数据生成的基底模型重复上述过程。这个循环可以跑很多轮。而且因为每一轮生成数据的模型都比上一轮更强生成的数据质量也在不断提升——这就是“自我迭代”的意义所在。4.2 为什么不能直接拿模型生成的数据全部喂回去有一个读者容易误解的地方模型自己生成的数据真的比自己现在的水平更高吗答案是单看任何一条数据不一定更高。但经过筛选后数据分布会向高质量区域倾斜。这就像一个学生做练习册他不可能每次都能做对但把做对的题反复总结、做错的题反复订正他的知识网络会越来越扎实。所以滤波筛选环节是整套机制的灵魂。没有这个环节就是噪声在训练噪声效果只会越来越差。4.3 在“数据生成”和“数据筛选”上的成本对比很多团队可能会担心这个流程是不是需要非常大的算力其实最大的算力消耗在“生成数据”阶段。需要让模型以不同的采样温度、不同的prompt模板生成大量候选样本。而筛选阶段如果规则写得足够好可以用比较轻量的方式完成不一定要每次都调一个大模型来做判别。这也是为什么说这个范式对小团队相对友好——算力开销可以接受主要门槛在数据管道和评估体系的设计上。5. 在35B模型上实践“自我迭代”的简化示例这一章可能是整篇文章里你最想直接复制走的部分。我会用一个简化但可运行的设计演示如何在一个35B规模的开源模型上搭建“造题 → 答题 → 筛选 → 微调”的闭环。需要说明的是完整复现上交大这个工作的训练规模和实验环境个人开发者几乎不可能。但核心思路是可以在自己的环境里跑通的。下面的示例聚焦在流程本身使用公开API和开源组件实现一个最小可用的自我迭代训练管道。5.1 环境准备推荐环境参考如下版本以实际安装为准Python 3.10PyTorch 2.1transformers 4.40vLLM 或 FastChat用于模型推理加速peft trl用于高效微调pip install torch transformers vllm peft trl datasets如果你有单张A100/A80080G可以尝试7B、13B模型跑通流程。要跑35B级别的完整训练建议使用多卡或云GPU环境。5.2 第一步构造“造题”的种子主题自我造题不是凭空乱问需要给模型一个知识范围。我们用一组种子主题作为起点这些主题可以来自业务场景也可以来自历史用户问题。# 文件路径seed_topics.py seed_topics [ Python中列表推导式的执行顺序, Rust的所有权与借用规则, SQL中EXISTS与IN的区别, 分布式事务的最终一致性方案, 大模型推理时的KV Cache原理, Python GIL对多线程性能的影响, Docker镜像分层机制, Kubernetes Pod的调度流程, ]这一步的作用是给“出题”过程限定边界避免模型生成发散、无用的问题。5.3 第二步模型自己造题基于种子主题调模型生成多个问题。为了增加多样性可以设置不同的prompt模板和不同的temperature。# 文件路径generate_questions.py from vllm import LLM, SamplingParams llm LLM(modelQwen/Qwen2.5-7B-Instruct, tensor_parallel_size1) question_prompt 你是一名资深技术面试官。请根据下面的主题出一道适合考察工程师基本功的问题要求问题具体、有深度、且答案没有歧义。 主题{topic} 请只输出问题本身不要输出答案。 sampling_params SamplingParams(temperature0.9, top_p0.95, max_tokens256) topics [...] prompts [question_prompt.format(topict) for t in topics] # 每个主题生成5道题 for t in topics: prompts.extend([question_prompt.format(topict) for _ in range(5)]) outputs llm.generate(prompts, sampling_params) questions [out.outputs[0].text.strip() for out in outputs]这里每道题都是模型自己“想”出来的不需要人工编写。这是整个流程的起点。5.4 第三步模型自己回答同样是这个模型或者用当前的迭代版本对每个问题生成答案。# 文件路径generate_answers.py from vllm import LLM, SamplingParams llm LLM(modelQwen/Qwen2.5-7B-Instruct, tensor_parallel_size1) answer_prompt 请回答下面的问题。要求逻辑清晰、内容完整、代码示例准确。 问题{question} sampling_params SamplingParams(temperature0.4, top_p0.9, max_tokens1024) prompts [answer_prompt.format(questionq) for q in questions] outputs llm.generate(prompts, sampling_params) answers [out.outputs[0].text.strip() for out in outputs]回答时的temperature比造题时要低目的就是让答案更稳定、更具确定性。5.5 第四步规则模型混合打分这一步是整个闭环的守门员。推荐用“规则 评分模型”的组合方式既能过滤低级错误又能保证质量。# 文件路径filter_samples.py def rule_based_check(question, answer, answer_tokens): # 过短答案直接淘汰 if len(answer_tokens) 100: return False # 包含明显安全问题的淘汰 dangerous_keywords [ignore previous, 黑客教程, 违法] if any(k in answer.lower() for k in dangerous_keywords): return False # 代码类问题必须包含代码块 if 代码 in question and not in answer: return False return True def model_based_score(question, answer): prompt f请对下面的问答对进行质量评分1-5分评分标准 - 5分答案完全正确逻辑清晰可以直接作为训练数据 - 4分答案正确但不够完善 - 3分部分正确存在明显遗漏 - 2分答案错误或答非所问 - 1分问题或答案无意义 问题{question} 答案{answer} 请只输出一个数字。 # 调用评分模型 ... return score filtered_data [] for q, a in zip(questions, answers): token_count len(a.split()) if not rule_based_check(q, a, token_count): continue score model_based_score(q, a) if score 4: filtered_data.append({question: q, answer: a})这一步会把很多低质量的样本拦截在外面。实际工程中建议结合具体的任务场景配置过滤规则。5.6 第五步用筛选后的数据做增量微调得到高质量数据后用Peft做一次LoRA微调得到模型v2。# 文件路径train_iteration.py from datasets import Dataset from peft import LoraConfig, get_peft_model from transformers import AutoModelForCausalLM, AutoTokenizer, Trainer, TrainingArguments model AutoModelForCausalLM.from_pretrained(Qwen/Qwen2.5-7B-Instruct) tokenizer AutoTokenizer.from_pretrained(Qwen/Qwen2.5-7B-Instruct) # 把过滤后的数据转成训练集 samples [{text: f问题{d[question]}\n答案{d[answer]}} for d in filtered_data] dataset Dataset.from_list(samples) def tokenize_func(examples): return tokenizer(examples[text], truncationTrue, max_length2048, paddingFalse) tokenized_dataset dataset.map(tokenize_func, batchedFalse) lora_config LoraConfig( r16, lora_alpha32, lora_dropout0.05, biasnone, task_typeCAUSAL_LM, ) model get_peft_model(model, lora_config) training_args TrainingArguments( output_dir./model_v2, per_device_train_batch_size1, gradient_accumulation_steps8, learning_rate2e-5, num_train_epochs3, logging_steps10, save_strategyepoch, ) trainer Trainer( modelmodel, argstraining_args, train_datasettokenized_dataset, ) trainer.train()到这里模型就完成了一轮“自我迭代”它自己出了题自己回答了自己筛选了高质量答案然后把这些数据用于微调自己。下一轮迭代时直接用新训练好的模型去替代原来的模型作为数据生成器。5.7 如何运行和验证建议不要一次性跑全流程而是分阶段验证# 1. 先验证造题效果 python generate_questions.py # 2. 再验证回答质量 python generate_answers.py # 3. 查看过滤后剩多少数据 python filter_samples.py # 4. 最后才启动微调 python train_iteration.py在完整跑通之前先拿少部分样本试运行一遍。数据管道跑通了再放开规模。这一步真的非常重要不然你很可能在某一阶段等待数小时后才发现问题出在一开始的数据格式上。6. 评测视角怎么判断模型真的“变强了”“自我迭代”最大的风险在于它可能只是让模型在自评的标准上变好而不是在真实任务上变好。就像学生自己出题自己考分数一路攀升但一到高考就露馅了。所以我们必须在每一轮迭代之后用第三方基准来客观评估。6.1 评测集的设计原则至少准备三类评测数据评测集类型来源目的领域QA集专家标注或权威题库答案是否准确对抗样本集模型上一轮答错的题难点是否被攻克开放指令集真实的用户问题分布泛化能力观察这里最重要的原则评测集必须是迭代模型没有见过的、不受模型生成数据影响的独立数据。如果不是独立数据集自我评分和最终评测就会形成闭环作弊。6.2 对比基线不迭代的Base模型验证迭代是否带来增量。更大参数的模型验证“35B迭代后”是否逼近“70B/万亿模型”。上一轮迭代版本观察每轮提升的幅度。没有这些对照你只看到“模型每轮在提升”但不知道提升的绝对价值在哪里。6.3 判断标准不只是分数变高评估时还应该关注数据多样性是否下降。如果模型越迭代越“自嗨”只擅长自己出的题真实任务反而变差说明训练分布收缩了需要及时止损。指令遵循能力是否退化。很多模型在自我迭代后对话流畅度下降容易复读答案。是否有灾难性遗忘。如果发现基础能力明显退化下一轮迭代要混入更多原始数据。所以在每一轮迭代结束后不要只看评测分数还要到测试用例里人工抽样看效果。7. 常见问题与排查思路这里整理一些我在实践这类流程时遇到的典型问题供参考。问题现象可能原因排查方式解决方案模型生成的问题太相似种子主题覆盖度不够采样温度太低打印生成结果统计问题相似度增加主题数量提高temperature多模板生成过滤后数据所剩无几过滤规则过严或生成答案本身质量差查看每个阶段的淘汰率分步统计淘汰率放宽非核心规则提高生成次数模型迭代后基础能力退化增量数据占比太高覆盖了原训练分布在旧任务集上跑回归测试按比例混合原始训练数据降低学习率训练一轮后效果基本没变LoRA秩太小或学习率不合适检查训练loss和梯度增大秩调大学习率增加训练轮次生成数据重复度过高采样策略单一统计n-gram重复率增加随机性使用不同prompt模板加入去重逻辑模型在自评集上分数很高但外部评测分数不高评分模型对自身生成数据有偏好换用独立评分模型增加规则校验定期用人工标注数据校准评分模型还有一个特别常见的坑生成环节和训练环节的tokenizer不一致。比如用vLLM生成时用的是A模型的分词器训练时加载的是B模型的分词器两者对同一个问题的切分差异可能会导致训练数据格式错乱。建议全程固定同一个模型系列的tokenizer。8. 最佳实践与工程建议前面讲完了原理和示例这一部分集中分享一些工程层面的判断。8.1 数据质量大于数据数量自我迭代最大的诱惑是无限生成数据。但无限生成不等于无限有效。质量不达标的数据混入训练集轻则浪费时间重则污染模型。一个朴素但有效的原则每一轮迭代只保留高质量样本宁缺毋滥。一个经过严格筛选的1000条数据很可能比未筛选的10000条数据带来的提升更大。8.2 给数据管道加“监控仪表盘”当你开始跑多轮迭代最容易遇到的问题是“不知道哪一轮开始变差了”。建议给数据管道增加几个关键指标每轮生成多少条候选数据规则过滤掉了多少模型评分后剩多少平均答案长度生成问题的重复率这些指标能帮你快速定位是哪一环出了问题而不是等到几轮训练结束后才回头找原因。8.3 不要追求过高的自我迭代轮数“自我迭代”听起来很美好但大量实验经验表明模型的能力提升不会一直线性增长。通常前几轮提升明显后续轮次会出现收益递减甚至能力回退。要尽早通过评测集发现这个拐点然后在最优版本停止迭代。8.4 权限、安全和合规边界需要注意如果这个流程要用于生产环境有几点需要特别注意模型生成的数据可能包含错误或误导性信息。即使是“高评分”数据也只代表评分模型认为好不代表真实正确。关键领域需要人工抽检。如果使用第三方大模型API生成数据要确认数据使用的许可条款特别是商用场景。生成数据的去重和安全过滤不能只依赖模型评分必须有规则层兜底。微调后的模型要重新走完整的安全评估流程不应默认继承原始模型的安全边界。8.5 什么时候该用这套范式自我迭代范式并不适合所有场景。它更适合有明确答案标准的领域数学、代码、逻辑推理、法律条文类问题。数据标注成本极高的领域医疗、金融、科研。需要持续演进的能力比如模型作为Agent工具使用的各种指令解析。不太适合的场景包括纯创意生成、主观审美相关任务以及缺乏客观评判标准的场景。这些场景里模型自评的可靠性会大打折扣。9. 总结与后续学习方向回到题目本身“35B干赢万亿参数大模型”这个标题确实吸引眼球但它背后真正值得记录的技术事实是当训练数据可以自我生成、自我筛选、自我迭代时模型规模的边际价值被重新评估了。这不是“小模型取代大模型”的宣言而是“高质量数据 高效训练范式可以显著弥补参数规模的差距”的一次有力证明。对任何一个正在做垂直领域模型的团队来说这都意味着一种新的可能性与其花高昂成本去训练或调用万亿参数模型不如把资源投入到高质量数据管道的构建上。如果你看完这篇文章想动手实践建议按这个顺序推进先不用管35B还是70B拿一个你手头最熟悉的对话模型搭建“造题→答题→筛选→微调”的最小闭环。固定一个外部评测集跑两轮迭代看真实指标的变化。确认这套流程稳定了再去扩大模型规模和数据规模。这条路线真正的门槛并不在GPU数量而在于你能否设计出足够客观的评测机制。模型可以自己造题但最终好不好用还得看它在真实任务上的表现。