我最早看到“35B干赢万亿参数大模型！上交大AI开始给自己造题还能自我迭代了”这个标题时，第一反应是：这到底是营销话术，还是行业真的开始换打法了？
放在两年前，参数规模几乎等于模型能力的代名词。谁训练了更大的模型，谁就掌握了更多“智能”。但这两年，越来越多的研究开始指向一个反直觉的结论：在特定任务、特定成本约束下，一个 35B 参数的模型，确实有可能在效果上逼近甚至超过一个万亿参数模型。关键不在“少参数”，而在它怎么设计数据、怎么构造问题、怎么持续迭代。
“自己给自己造题”这个说法，听起来像玄学，实际上去对应了大模型技术里一个很接地气但极其重要的工程方向：合成数据、自指令生成、自我对弈、以及模型自我迭代。这个概念不是某个团队独有，而是从 Self-Instruct、Self-Play 一路延伸下来的方法论。只是在过去，它更多被用在强化学习和机器人控制里，而现在，它成了大模型训练的新主线之一。
这篇文章我想从技术演变的逻辑、可落地的工程路径、以及最容易踩坑的地方三个层面展开，聊聊这类“小参数 + 自我迭代”方案的真实价值，以及它到底适合谁、不适合谁。
1. 参数规模的神话，为什么会开始松动
1.1 万亿参数的吸引力与代价
万亿参数模型之所以让人兴奋，是因为它确实打开了很多原本做不了的事。更大的参数量意味着更强的记忆能力、更复杂的模式拟合能力，以及更好的跨任务泛化潜力。我们过去看到的很多“智能涌现”，都建立在足够大的模型规模之上。
但万亿参数并不等于零成本。训练一个万亿参数模型，需要成千上万张 GPU、数月时间、海量数据清洗治理，以及一个能处理分布式训练崩溃的工程团队。更麻烦的是推理成本：即便是 16-bit 或 8-bit 部署，每次请求都要经过数千亿甚至万亿参数的前向传播，延迟、显存、带宽、能耗都随之上涨。
更隐蔽的问题是：参数规模的边际收益正在递减。当模型已经具备基本语言能力和推理能力后，继续增加参数量，真正提升的往往不是“核心智能”，而是对训练数据中细节模式的记忆和复述。换句话说，大模型可能不是更聪明，而是记得更多。
1.2 小模型跑赢大模型，靠的不是魔法，而是任务收敛
“35B 干赢万亿参数”如果属实，最可能出现的场景是垂直任务、特定基准或受限领域。这不是说小模型在通用能力上已经全面碾压大模型，而是说小模型在一个定义清晰的评价体系里，通过更聚焦的数据分布，做到了更高的“任务命中率”。
我理解这背后的原理很像考试：万亿参数模型像一个博览群书但没针对这张卷子专门复习的人，35B 模型则像一个只研究考纲和真题集的人。如果考试范围固定、评分规则明确，后者完全可能考出更高分数。但它换一张卷子、换一个开放性问题，可能又会被前者拉开差距。
所以，这里要先彻底丢掉“单挑”的心态。小模型跑赢大模型，赢的是一个场景、一套评估标准、一类数据分布，而不是全维度能力。
1.3 “干赢”不等于全面超越
标题里“干赢”这个词很有煽动力，但落到工程上，我们必须追问几个问题：
- 用的是哪个评测基准？是公开榜单，还是自己构建的业务测试集？
- 评测任务是什么？是推理、编程、数学、客服，还是多轮对话？
- 成本口径是什么？训练成本、推理成本、延迟、吞吐，还是端到端运维成本？
- 评测是单次结果，还是多次采样后的稳定性？
如果这些条件不写清楚，“35B 干赢万亿参数”就只是一个无法被验证的判断。我更愿意把它理解成：在算力和数据双重约束下，小而精的模型配合自我迭代数据流水线，可以在某些任务上实现“以弱胜强”。
注意：看见类似标题时，第一步不是相信结论，而是找出它的评测边界。没有边界的能力对比，本质上没有工程参考价值。
2. “自己给自己造题”到底是什么机制
2.1 从 Self-Instruct 到合成数据流水线
“自己给自己造题”如果用技术语言翻译，就是让模型基于自身已学会的知识，生成新的指令、输入、输出或思维链，再通过筛选和打分，把这些数据投入下一轮训练。
这个方法的前身是 Self-Instruct。它的核心思想很简单：先用少量人工种子指令，让模型生成更多指令和回答，然后过滤低质量内容，再用这份扩展后的数据微调模型。这样循环几轮，模型就能在指令跟随能力上逐渐变强。
后来，这个方法被扩展到多个方向：
- 生成思维链数据，让模型学会逐步推理；
- 生成偏好对，用于 DPO 或 RLHF 训练；
- 生成问题分解路径，提升 Agent 的任务规划能力；
- 让两个不同模型互相出题、互相评价，形成对抗式进化。
这些做法本质上都是“自问自答 + 外部筛选”的组合。
2.2 模型不再只是学习者，也变成出题人
传统训练流程里，人类负责设计问题，模型负责学习答案。人类是出题人，模型是解题人。自我迭代思路把角色改变了：模型先当出题人，自己生成问题；再当解题人，自己给出回答；然后让评审模块打分；最后把高分样本作为新训练数据。
这个循环的最大价值，是突破了人工数据生产的瓶颈。人工写指令、标注答案、构造思维链，成本高且天花板低。模型生成方案虽然会夹杂噪声，但胜在规模和多样性。
当然，太依赖模型自产数据也有风险。如果出题人本身只会做一类题，它生成的题目就会越来越单一。怎么办？要靠外部信号来对冲：人工规则、知识库、代码执行结果、真实用户反馈、独立的打分模型。这些外部信号相当于给“自问自答”加了一个裁判，避免模型自嗨。
2.3 迭代闭环：生成、筛选、训练、评估、再来一轮
一个完整的自我迭代闭环，至少包含以下几个环节：
- 采样一组高质量种子任务或种子数据；
- 由当前模型生成候选答案、候选题目或候选思维链；
- 使用规则过滤、模型打分、人工抽查等方式筛选；
- 把筛选后的数据拼入训练集，做一轮 SFT、DPO 或 RLHF；
- 在固定的验证集和业务评测集上对比新旧版本；
- 如果效果提升，保存新版本，进入下一轮；如果没提升，回退并调整数据生成策略。
这个流程并不神秘，真正难的是每个环节的“质量门槛”怎么设。生成多少条？过滤阈值是多少？打分的 prompt 怎么设计？人工抽查比例是多少？不同任务的答案对错怎么判断？这些参数直接决定迭代会不会退化。
2.4 为什么这条路对小模型尤其友好
小模型参数少，训练相对快，单次实验成本低，这使它天然适合高频迭代。你可以今天跑一轮生成，明天微调出新版本，后天在评测集上看结果。万亿参数模型跑整套循环可能要按周计算，35B 模型则可以按天甚至按小时计算。
另一个原因是，小模型在面对“自己生成的数据”时，更容易被数据分布拉向目标方向。大模型的世界知识已经非常丰富，合成数据带来的边际影响有限；小模型则像一块海绵，改进空间大，吸收快。很多“小模型自我迭代后能力大增”的实验，本质上是把模型从不熟悉某个任务分布，迭代成熟悉这个任务分布。
理解了这一点，再看“35B 干赢万亿参数”，就不难明白：真正赢的不是参数，而是训练循环的迭代速度和数据分布的对齐程度。
3. 小模型自我迭代的工程落地：先跑通一条最小链路
3.1 前置条件：你需要什么
如果想把这类方法用到自己的项目里，不需要一开始就构建复杂的多模型对抗系统。先准备以下基础能力：
- 一个基础模型：可以是 7B、14B、35B，也可以是开源社区任意一个可微调的模型；
- 训练环境：单卡或几卡 GPU，能跑 SFT / DPO 即可；
- 评估集：至少 100 到 500 条与业务目标强相关的评测样本；
- 数据过滤脚本：规则去重、长度过滤、关键词过滤、格式校验；
- 一个打分方案：可以是规则、脚本执行、代码运行结果，也可以是一个更强的模型作为 judge；
- 版本管理：每个迭代周期保存模型 checkpoint、训练数据、评测结果，便于回滚。
如果连评估集都没有，先别急着做自我迭代。否则你无法判断模型是进步了还是退化了。
3.2 最小闭环的六个环节
我建议的落地顺序是：
- 先跑通静态训练：用现有数据微调一版模型，确认训练流程可复现。
- 构造种子任务：从真实用户问题、业务日志、历史工单里抽取 100 到 1000 条问题。
- 让模型生成答案：用当前模型对种子任务生成多个候选答案。
- 筛选和过滤：去除空内容、重复内容、格式错误，并用规则或打分模型筛掉明显差的回答。
- 增量微调：把筛选后的数据合并到训练集，再做一轮 SFT 或 DPO。
- 跑评测：在固定验证集上对比新旧版本，记录每个指标。
只要这六步能走通，就已经具备最基本的“自我造题 + 自我迭代”能力了。后续才需要考虑更复杂的事情，比如多轮迭代、多模型互相生成、动态评测集等。
3.3 关键参数与配置理解
这里的参数不是单纯的大模型学习率，而是整条数据流水线里最容易影响结果的部分。
- 生成温度：如果想让模型生成多样性的候选答案，temperature 可以设置在 0.7 到 1.0 之间；如果只想生成稳定答案，用 0.2 到 0.4。自我迭代早期建议温度稍高，增加数据多样性。
- top_p / top_k：可以按默认值设置，但要注意和 temperature 配合，避免生成过于碎片化。
- 最大长度：不要设置过长，否则容易生成大量废话，增加过滤成本。按任务实际输出长度设置即可。
- 筛选阈值：如果用打分模型，建议先在小样本上人工校一遍打分结果，确认阈值合理，而不是直接套用 70 分。
- 微调轮数：SFT 阶段 1 到 3 个 epoch 通常就够，太多反而容易过拟合。
- 学习率：建议比正常微调略低，因为合成数据往往多样性不足，过大的学习率会加速对单一分布的拟合。
以上这些不是固定值，但理解它们的意义比记住数字更重要。
3.4 一个通用伪代码结构
以下是一个简化版的流程示意，用于说明代码组织方式，不是可直接运行的完整项目。
# self_iteration_pipeline.py # 这是一个最小闭环的伪代码结构 seed_tasks = load_seed_tasks("data/seed.jsonl") base_model = load_model("base_model_path") for round_idx in range(3): current_model = base_model if round_idx == 0 else latest_model # 1. 生成候选答案 generated = [] for task in seed_tasks: samples = current_model.generate( task["instruction"], temperature=0.8, num_return_sequences=3, ) generated.extend(samples) # 2. 过滤 filtered = [] for sample in generated: if pass_rule_filter(sample): score = judge_model.score(sample) if score >= threshold: filtered.append(sample) # 3. 拼接训练集 train_data = seed_tasks + filtered # 4. 微调 latest_model = sft_train( base_model=current_model, train_data=train_data, epochs=2, ) # 5. 评估 metrics = evaluate(latest_model, eval_set) print(f"round {round_idx}: {metrics}") if not metrics_improved(metrics): latest_model = rollback_to_best_model() break这段代码最重要的一行是rollback_to_best_model()。自我迭代不是只能前进，它完全可能倒退。保留历史 checkpoint、自动回滚，是长期迭代的安全底线。
3.5 如何判断一轮迭代是否值得继续
判断标准不能只看单一指标提升。我建议同时观察：
- 目标指标是否提升，比如准确率、通过率、人工好评率；
- 该指标是否稳定，多次运行是否有较大方差；
- 失败案例变化，是否有原本正确但现在错误的情况；
- 生成多样性是否下降，模型是不是开始只输出一种安全但重复的答案；
- 长尾场景是否变差，越是高价值场景越需要单独监控。
如果目标指标提升但多样性大幅下降，或者长尾场景变差，这种提升是不可持续的。
建议：每一轮迭代后，至少人工查看 50 条新生成的数据和 50 条评测失败数据，不要只看平均数。
4. 不能忽略的坑：模型崩溃、奖励黑客、评估过拟合
4.1 model collapse：吃自己数据的代价
模型反复使用自己生成的数据训练，会出现一个非常经典的退化现象：生成结果的多样性逐代降低，错误会被固化，极端情况下模型会开始重复输出固定句式。很多人叫它“模型崩溃”。
这不是危言耸听。当一轮迭代中的高质量数据被下一轮模型吸收后，下一轮模型生成的数据会离人类真实数据越来越远。如果没有外部新鲜数据注入，几轮之后，模型可能变成一个“自说自话”的复读机。
应对方法也很直接：
- 每一轮都保留一部分原始人工数据；
- 每一轮都注入新的真实用户反馈或新爬取的数据；
- 控制合成数据占比，不要让它完全盖过真实数据；
- 对生成数据做去重和多样性检测，相似度过高的直接丢弃。
4.2 奖励黑客与自我打分的盲区
如果用模型自己或另一个大模型作为打分器筛选数据，很容易出现“奖励黑客”。比如，打分模型可能偏好更长的回答，而不是更准确的回答；可能偏好看起来很有逻辑但实际错误的内容；也可能被某些固定表达影响，比如“首先、其次、最后”这类连接词。
我在实际工作中看到过一种情况：模型学会了在答案里加入“根据以上分析，我们可以得出结论”，结果打分模型的分数明显变高，但业务方拿到答案后觉得根本没法用。
要降低这个风险，需要为打分模型设计更具体的评分标准，比如：
- 答案是否直接回答了问题，而不是铺垫过多；
- 是否包含事实错误；
- 格式是否符合业务要求；
- 是否有步骤、有依据，但克制；
- 如果任务有标准答案，是否必须用代码执行结果或规则判断。
打分只是筛选手段，不是最终裁判。
4.3 评估集污染比过拟合更隐蔽
自我迭代还有一个隐蔽风险：评估集被污染。如果模型生成的数据被加入训练集，而训练集和评估集来自同一个数据源，评估分数自然会被虚高。更麻烦的是，模型完全可能“背下”评估集的答案，而不是学会任务本身。
要避免这个问题，评估集必须与训练集完全隔离，而且要定期更新。我不建议长期使用同一套固定测试题。比较稳妥的做法是：
- 建立训练集、验证集、测试集三层隔离；
- 测试集只用于最终评估，不参与任何训练或筛选；
- 从真实业务中持续抽取新样本，替换已污染的测试题目；
- 对新版本模型做盲测，评审人员不知道哪份答案是哪个版本生成的。
4.4 排查链路：先看输入、再看环境、最后看数据分布
如果迭代后模型效果没有提升，甚至变差了，不要急着调参。按下面顺序排查：
- 输入侧：种子任务是否太简单？生成数据是否大量重复？过滤阈值是否过于宽松或严格？
- 环境侧：训练脚本是否误用了旧 checkpoint？学习率、批次大小、随机种子是否发生变化？依赖版本是否不一致？
- 评估侧：评估集是否被污染？是否换过评估 prompt？是否用了不同采样温度？
- 数据分布侧：合成数据与真实数据的比例是否合理？新数据是否集中在少数模式上？模型是否开始产生同质化输出？
大多数“迭代后变差”的问题，都不是模型能力下降了，而是某个环节的数据分布发生了偏移。
5. 这类方法适合谁，不适合谁
5.1 适合的场景
- 垂直领域任务：如客服、法律咨询、医疗问答、代码修复、数据分析。任务边界越清晰，自我迭代越容易收敛。
- 已有真实反馈积累的团队：每天有大量用户反馈、工单、日志可以回流，合成数据和真实数据可以交替使用。
- 算力有限但希望持续优化效果的团队：小模型迭代快、成本低，适合在固定算力预算内追求“够用且稳定”。
- Agent / 工具调用场景：可以通过代码执行结果判断模型输出是否正确，天然适合自动筛选。比如模型生成 SQL、Python 代码、JSON 配置，结果能不能跑，就是最硬的标签。
5.2 不适合的场景
- 开放性极强的通用对话：任务边界模糊，评判标准多样，自我迭代很容易变成“自我偏见放大”。
- 冷启动阶段，没有评估集和真实反馈：如果连第一个版本的打分逻辑都没建立，盲目迭代只会放大随机噪声。
- 追求全方位能力的团队：如果希望模型同时成为编程高手、写作专家、翻译专家、Agent 规划大师，小模型自我迭代的样本效率可能不够。
- 对生成内容安全性要求极高的场景：模型自己生成数据容易引入偏见、违规内容和错误事实，必须要有强人工审核。
5.3 长期迭代前需要补齐的工程能力
如果你打算把这个思路用到长期项目里，还需要补齐几块工程能力：
- 数据版本管理：记录每一轮生成数据的来源、过滤条件、处理脚本和采样参数；
- 自动评估平台：至少能跑回归评测，支持看 diff、看失败 case；
- 模型发布流水线：能快速回滚到上一版，避免坏模型在线残留；
- 监控告警：关注生成多样性、输出长度、拒绝率、用户反馈率等指标；
- 人工审核闭环：对高影响样本和低置信度结果，保留人工复核通道。
这几块能力比任何单轮训练技巧都重要。只有它们稳定了，自我迭代才能从“实验”变成“生产系统”。
5.4 如果团队资源有限，建议从哪个方向开始
资源有限的情况下，我会更建议从“评估集 + 真实反馈回流”开始，而不是直接做大规模合成数据。
先把 200 条真实业务问题做成固定评测集。让现有模型在这些问题上跑一版成绩。然后让模型对每个问题生成多个答案，再用规则过滤 + 人工打分，挑出一批优于原答案的数据。最后用这少数高质量数据做一次微调。这样一轮下来，一般就能看到相对明显的效果提升。
先别做多轮迭代。先做一轮，确认整个流程的每一环都能被量化。等流程稳定了，再慢慢增加轮次和数据规模。
6. 回到主线：参数数量不是终点，迭代能力才是
6.1 “35B 干赢万亿参数”背后真正值得记住的框架
如果要从“35B 干赢万亿参数”这个标题里提炼出一个可复用的框架，我的答案是：
能力 = 基础模型参数 × 数据质量 × 任务收敛度 × 迭代速度
参数只是其中一项。数据质量决定了模型能在什么方向上成长，任务收敛度决定了最终效果能不能被量化和优化，迭代速度决定了你能不能快速试错。
所以，当你再看到一个“小模型干赢大模型”的标题时，不要只盯着参数对比，可以尝试拆解：
- 它用什么数据训练？
- 它用什么标准筛选数据？
- 它如何评估效果？
- 它迭代了几轮？
- 每一轮的数据和模型版本是否可追溯？
这些问题拆完，标题的神秘感就消失了大半。
6.2 模型发布只是起点，持续自我迭代才是长期护城河
过去我们习惯了“训练一次，发布模型，然后等下一个大版本”。但自我迭代思路带来的是一个更连续的开发模式：模型上线后持续收集反馈，每周或每月跑一轮数据生成、筛选、微调、评估、发布。模型不再是一个静态产物，而是一套持续进化的系统。
这种模式对团队带来的改变，不只是技术上的，还有组织上的。它要求算法、数据、工程、评测、甚至业务方坐在一起，持续定义“什么样才是好的答案”，而不是把模型发布出去就万事大吉。
6.3 下一步行动建议
如果你认同这个方向，可以先做三件事：
- 建立一个真实业务评测集，无论有多少条，先让模型有“及格线”；
- 用规则和代码执行结果，而不是模型主观打分，先做一轮自动筛选；
- 保存好第一版模型和第一批数据，作为后续所有迭代的对照基线。
自我迭代不是一个可以一蹴而就的功能，它更像一套训练“模型如何更好地学习”的工程体系。35B 能不能干赢万亿参数，最终取决于你怎么出题、怎么判分、怎么迭代。参数规模是入场券，但迭代能力，才是真正拉开差距的地方。
