# Mid-train 技术综述与落地手册：面向有 post-train 经验的基模团队

资料范围：近两年公开资料；同一模型家族优先最新一版，最多看上一版，更老版本只在有不可替代证据时保留
目标读者：有 post-train 经验、准备承担 mid-train 的基模团队；也适合 Model / Data / Training / Eval / Post-train DRI 协作使用
结论性质：技术研究与工程参考，不构成任何商业或投资建议

## 使用导航 / 主线地图

这篇文章不是必须从头读的文献综述，而是一套 gate-driven 启动手册。若今天要开 mid-train 启动会，先读 0.2、0.3、8、9；若要设计数据和实验，读 4.2-4.6、6、11；若训练已经出事故，直接读 7；若要核查公开资料和引用边界，读 2、3、12。

**主线只有一条：先证明目标值得 mid-train，再证明数据和评估可信，再证明短程训练有效，最后证明 post-train 后收益仍保留。**

| 决策问题 | 主要证据 | 对应章节 | 产出 |
| --- | --- | --- | --- |
| 是否真的需要 mid-train | 目标能力、不可牺牲能力、替代方案排除 | 0.1、1、8.0 | Mid-train charter |
| 公开资料能支持到哪一步 | 报告事实、工程类比、不可外推边界 | 2、3、12 | claim/source matrix |
| 第一轮验证什么 | 主假设、数据桶、不可同时改变的变量 | 4.0、4.4、11 | ablation plan |
| 数据能不能进训练 | data manifest、license、污染、合成数据治理 | 4.2、7.3、9.1 | data readiness memo |
| checkpoint 是否值得继续 | scorecard、guardrail、事故记录、Pareto 曲线 | 5、6、7、8.0 | extend / rollback / kill 决策 |
| post-train 后是否保留收益 | frozen paired protocol、seed、AUC、raw outputs | 6.6、7.6、8.0 | post-train readiness report |
| 是否放大 | go/no-go memo、model registry、成本收益 | 8、9、13 | scale / shrink / stop 决策 |

## 0. 摘要

**Mid-train 不是 post-train 的放大版，也不是简单把 pretrain 再跑一段。** 本文采用一个保守的工程定义：

> Mid-train 是 base pretrain 后、SFT/RL 等 post-train 前的一段受控继续训练，用来改变模型的能力分布、上下文适应能力，以及后续 SFT/RL 可利用的可训练性。

公开资料中，OLMo 2 明确把 base pretraining 之后、post-training 之前的阶段称为 mid-training；Qwen3、DeepSeek-V3、Qwen2.5-1M 等报告并不总使用这个词，而是称为 pre-training、continued pre-training、context extension 或 long-context pre-training。本文只在工程意义上把这些阶段归入 mid-train-like 范畴，不能等同于原报告术语。

资料选择上，本文不做模型历史复盘。每个模型家族优先读最新一版公开技术报告；只有当上一版披露了当前版本没有替代的信息，例如 1M context、显式 mid-training 命名、annealing 或 synthetic data 细节时，才保留上一版或必要例外。执行项目时，应先用目标模型家族的最新报告替换本文中的历史样本。

实践上，新团队不应先追大规模训练，而应先做小模型 ablation、数据桶验证、污染检查、base 回归评估，再用主模型短程训练验证方向，并用固定 post-train recipe 检验收益是否保留。**Mid-train 的成功标准不是某个 base benchmark 上涨，而是能力增强、遗忘可控、post-train 后收益仍存在。**

边界上，本文不把所有 continued pretraining 都等同于 mid-train，也不把 DCA、YaRN、sparse attention、chunked prefill 等推理或架构技巧简单归为训练配方。公开案例只能作为设计参考，不能照搬为 recipe。

文中的数据比例、token budget、90 天路线图、质量门和事故 runbook 均为面向新团队的工程起步建议，不是公开论文直接给出的通用结论。

对一个有 post-train 经验、准备承担 mid-train 的基模团队，**最重要的不是立刻上大规模训练，而是先建立四件事**：

1. **明确目标能力和不可牺牲能力**：例如数学提升不能以通用对话、事实知识、多语能力大幅退化为代价。
2. **做小模型和短程 ablation**：先验证数据桶、学习率、序列长度、污染控制和遗忘风险。
3. **建立 mid-train 专用评估**：不能只看 pretrain loss，也不能只看 post-train 后的榜单。
4. **让 Post-train DRI 接力验证**：mid-train 的成功标准之一，是 SFT/RL 后收益仍能保留、训练更可控，而不只是 base checkpoint 某几个 zero-shot 分数更好。

### 0.1 读者决策树：你到底该做哪类 mid-train

| 目标 | 优先路线 | 第一轮实验 | 关键评估 | 不建议一开始做 |
| --- | --- | --- | --- | --- |
| 数学、代码、STEM、复杂 QA | Capability mid-train | 小模型数据 mix + 低 LR 短程训练 | 目标能力提升 + 通用能力回撤 | 同时拉长到 128K/1M |
| 32K/128K 长上下文 | Context extension | 逐步长度扩展 + 长文档数据桶 | 多证据、长文档、长代码任务 | 只看 needle-in-a-haystack |
| RL reasoning 上限 | Reasoning substrate mid-train | 验证 base 是否已有 edge-of-competence | 固定 RL/RLVR recipe 接力对比 | 把 RL 当成能力来源本身 |
| 垂直领域能力 | Domain continued pretraining | 低比例领域数据 + 通用保真数据 | 领域任务 + 通用回归 | 用单一领域语料灌满训练 |
| Coding agent / tool use | Code/FIM/trajectory mid-train | FIM、repo-level completion、多文件定位 | repo task、编辑任务、post-train 后 agent eval | 把交互格式全部前移到 mid-train |

这个决策树是执行入口，不是排他分类。一个成熟项目最后可能同时包含 capability shaping、long-context adaptation 和 post-train readiness，但**第一轮最好只验证一个主假设**。

### 0.2 第一天怎么启动

如果今天就要启动 mid-train 项目，**不要先开训练。第一天只做 7 件事**：

1. 拉齐 Model、Data、Training Infra、Eval、Post-train、Safety/Compliance、Product/Domain 的 DRI。
2. 写一页 Mid-train charter：目标能力、不可牺牲能力、为什么必须在 mid-train 做、预算边界。
3. 冻结 eval registry 的 v0 owner 和 schema；训练前再冻结 v1 eval registry，包括 base eval、专项 eval、长上下文 eval、私有 holdout、人工样例审查。没有 v1，不进入 Gate 1。
4. 让 Post-train DRI 冻结 paired protocol 的 v0 owner 和 schema；训练前再冻结 v1 paired protocol，包括 SFT/RL 数据版本、训练预算、seed、harness、评估集和失败判定。
5. 创建实验台账 schema，规定没有台账的实验不进入结论。
6. 定义 Gate 0-5 的通过条件、阻断条件和签字人。
7. 明确第一周不允许做什么：不边看私有 holdout 边调参，不在同一个实验 ID 下改 mix/过滤器/eval 版本，不把 proxy 成功当成主模型必然成功。

### 0.3 如何使用本文：按角色和任务跳读

这篇文章可以从头读，也可以当内部手册查。第一次启动 mid-train 项目时，建议按角色分工阅读：

| 角色 | 先读章节 | 需要带走的产出 |
| --- | --- | --- |
| Decision owner / Model Lead | 0、1、4.6、8、11 | 项目是否该做、目标能力、不可牺牲能力、Gate 0-5 决策口径 |
| Data DRI | 4.2、4.2.1、4.2.2、7.3、9.1 | 数据桶准入卡、data manifest、污染检查、合成数据边界 |
| Training Infra DRI | 4.3、4.5、5、7.4 | 训练旋钮冻结项、context curriculum、checkpoint lineage、resume runbook |
| Eval DRI | 6、7.5、9.3、12.3 | eval registry、scorecard、holdout 分层、claim/source 边界 |
| Post-train DRI | 1.2、6.6、7.6、8 | paired protocol、seed/预算/harness、收益保留判断 |
| Safety / Product / Domain DRI | 0.1、4.1、6.3、7.1、10 | 不可牺牲能力、guardrail、真实任务、发布阻断条件 |

如果只开一次 90 分钟启动会，会议不要讨论“大概要训多少 token”，而是按下面顺序收敛：

| 时间 | 问题 | 退出条件 |
| --- | --- | --- |
| 0-15 分钟 | 目标能力是否真的需要 mid-train | 写出 1 个主目标和 3-5 个不可牺牲能力 |
| 15-35 分钟 | 第一轮只验证哪一个假设 | 明确 capability / context / domain / reasoning substrate 中的主线 |
| 35-55 分钟 | 数据、eval、post-train paired protocol 是否能冻结 | 确认 data manifest、eval registry、post-train paired protocol owner |
| 55-75 分钟 | Gate 0-2 的 kill 条件是什么 | 写出污染、回撤、事故、post-train 不保留收益的阻断线 |
| 75-90 分钟 | 本周交付物和不开工条件是什么 | 形成 charter、台账、责任人和第一周 no-go 清单 |

## 1. 术语边界：什么是 mid-train

### 1.1 一个实用定义

本文采用工程定义，而不是术语洁癖式定义：

> Mid-train 是 base pretrain 后、post-train 前的继续训练阶段。它仍主要使用语言建模目标或其变体，但数据、学习率、序列长度和能力目标已经从“最大覆盖世界文本”转向“高质量能力塑形”。

这一定义覆盖几类公开实践：

- late-stage pretraining / annealing：在较低学习率下，用高质量数据继续训练，追求更低损失和更强下游能力。
- domain / capability continued pretraining：围绕代码、数学、STEM、医学、法律、金融、多语等能力继续训练。
- long-context extension：在原 base context 上扩展到 32K、128K、256K 等，配套位置编码、attention 优化和长文档数据；若目标是 1M 级上下文，应单独验证训练长度、位置/attention 外推、chunked prefill、KV cache 和 serving 成本，不能写成单纯继续训练或数据配方。
- reasoning-oriented mid-train：用数学、代码、合成推理、教材式数据、QA/CoT 等让 base model 更适合后续 RL 或 RLVR。

Mid-train 和 continued pretraining 有重叠，但强调点不同：continued pretraining 描述“训练从哪里接着跑”；mid-train 更强调“为什么跑、用什么数据塑形、如何服务 post-train”。

### 1.2 它和 post-train 的分工

Post-train 团队容易把 mid-train 想成“更多 SFT 数据”或“更早一点的 SFT”。这是危险的，因为两者优化对象不同。

Mid-train 关注：

- 模型内部是否有解决问题所需的知识、算法模式和表征能力。
- 长上下文中位置编码、attention、检索和跨段归纳是否可用。
- 代码、数学、工具轨迹、复杂指令的基础分布是否进入模型参数。
- 后续 SFT/RL 是否更容易把能力激发出来。

Post-train 关注：

- 指令遵循、回答风格、安全拒答、偏好排序。
- 多轮对话和用户意图对齐。
- 推理过程是否外显、是否符合产品策略。
- RL/RLHF/RLAIF/RLVR 中的 reward 可优化行为。

粗略说，mid-train 更偏向改变能力可达性和参数内分布，post-train 更偏向改变任务接口、行为策略和产品呈现；但在 reasoning、tool use、agent 和长上下文任务上，两者会交叠，必须用 paired protocol 判断收益来自哪里。

### 1.3 不宜把所有训练都叫 mid-train

本文不把以下情况简单归为 mid-train：

- 从零开始的大规模通用预训练。
- 单纯为了对齐、安全或格式的 SFT。
- 只在 post-train 数据上继续跑语言建模，但没有能力目标、数据控制和回归评估。
- RAG、外部工具、推理时 search 等不改变模型参数的系统工程。

边界要清楚，否则团队会用 post-train 的评估和组织方式管理 mid-train，最后很难判断收益来自哪里。

### 1.4 给有 post-train 经验的基模团队的 10 条差异认知

1. **Mid-train 的对象是能力分布，不是回答风格。**
2. Mid-train 的主损失通常仍接近语言建模目标，不是偏好优化。
3. Mid-train 数据可以包含 QA/CoT/FIM，但**不要把 SFT 数据整体前移**。
4. **Mid-train 的好 checkpoint 不一定是 loss 最低 checkpoint**，而是能力提升和遗忘之间的 Pareto 点。
5. **Mid-train 的收益必须在 base eval 和 post-train readiness 中同时观察。**
6. **数据污染在 mid-train 中比 SFT 更危险**，因为它会进入 base 能力判断。
7. 合成数据要先被验证和分层，不应因为”便宜”而提高比例。
8. 长上下文能力要区分训练长度、推理外推长度和线上可服务长度。
9. **RL 的收益通常依赖 base 已有可达能力区间**，不能把所有 reasoning 问题推给 RL。
10. **放大训练前必须有停止条件**；mid-train 不是”预算还没花完就继续跑”。

## 2. 公开证据强弱分层

公开材料不完全一致，最容易出错的地方是把“报告明确写出的训练阶段”“研究者的归纳”和“访谈里的行业经验”混为一谈。本文按证据强弱和模型版本新旧两条线使用资料：同一模型家族优先最新一版，最多上一版；更早材料只在有不可替代证据时作为例外。

### 2.0 本文的证据标签

为避免把公开事实和工程推断混在一起，后文默认使用四类证据标签：

| 标签 | 含义 | 能用于什么 | 不能用于什么 |
| --- | --- | --- | --- |
| 报告事实 | 技术报告、论文或官方材料直接披露的阶段、token、context、数据类型、训练目标 | 描述某团队实际做了什么 | 推出其它团队应照搬同一配方 |
| 论文归纳 | 综述或受控实验给出的机制、taxonomy、变量关系 | 设计内部 ablation、建立假设 | 直接升级为产业级训练定律 |
| 工程归纳 | 本文基于多个案例抽出的保守实践建议 | 制定项目流程、gate、台账和风险控制 | 声称是某篇报告原文结论 |
| 待验证假设 | 访谈、博客、行业口径或小样本实验启发的方向 | 进入小模型/短程实验候选 | 进入主模型放大决策 |

读者在使用本文时，应把“报告事实”当作事实底座，把“论文归纳”和“工程归纳”当作实验设计输入，把“待验证假设”当作 backlog。任何会消耗大规模训练预算的决策，都应回到团队自己的 data manifest、eval registry 和 post-train paired protocol。

### 2.1 强证据：技术报告明确披露的阶段设计

强证据指模型团队在技术报告中直接披露的训练阶段、token 规模、上下文长度或数据策略。

| 案例 | 使用级别 | 报告原术语 | 公开报告直接支持 | 本文工程类比 |
| --- | --- | --- | --- | --- |
| Qwen3 | 主读 | pre-training stages | General / Reasoning / Long Context 三个 pre-training stage；约 36T 总量、约 5T reasoning-stage tokens、32K 长上下文训练 | mid-train-like capability shaping + context adaptation |
| DeepSeek-V3 | 主读；有同家族新报告时替换 | long context extension | 14.8T base pre-training 后，使用 YaRN 做两段各 1000 steps 的 4K -> 32K -> 128K context extension | mid-train-like long-context extension，但主要支持长度阶段化结论 |
| GLM-4.5 | 主读 | mid-training | 23T pre-training 后约 1.1T mid-training tokens，显式分三个子阶段：repo-level code（~500B，4K→32K）、synthetic reasoning（~500B）、long-context + agent（~100B，→128K）；MoE 355B/32B | 显式 mid-training 命名 + 多子阶段能力塑形 + 渐进式 context extension；MoE 架构下 mid-train 的参考样本 |
| Qwen2.5-1M | 上一版专项保留 | long-context pre-training / post-training / inference scaling | progressive long-context pre-training、长上下文 post-training、DCA/YaRN 外推、稀疏注意力和 chunked prefill 部署优化 | context adaptation + inference/deployment 协同样本 |
| OLMo 2 | 必要例外 | mid-training | pretraining -> mid-training -> instruction/preference tuning 的清晰分层；Dolmino Mix、50B/100B/300B、micro-annealing 等细节较透明 | 狭义 mid-training 的公开参考样本 |
| Phi-4 | 必要例外 | pretraining / midtraining / post-training | 合成数据贯穿 pretraining/midtraining/post-training；midtraining 明确把 4K context 扩到 16K | synthetic-heavy training strategy + context extension 边界样本 |
| Llama 3 | 降级参考 | initial pre-training / long-context pre-training / annealing | 405B 在 15.6T tokens 上 initial pre-training，约 800B tokens long-context pre-training 到 128K，最后 40M tokens annealing | late-stage continued pre-training 和 annealing 的保守参考 |

这些报告能支撑“阶段设计”的存在，但通常不能支撑“照搬数据比例或学习率”。未公开的 tokenizer、数据清洗、采样策略、基础 checkpoint 状态、优化器状态和系统实现，都会显著影响结果。

### 2.2 中证据：综述和受控实验的归纳

Mid-training survey、PRISM 以及 pre-training / mid-training / RL interplay 这类研究能帮助团队理解变量关系：数据保留与能力迁移、能力是否位于模型可达边界、RL 是否能从 mid-trained checkpoint 获益等。

这些研究的价值是提出机制假设和实验维度，而不是给出可直接外推的产业配方。尤其是受控 synthetic task 或小规模模型上的结论，不能直接升级成“所有大模型训练定律”。

### 2.3 弱证据：访谈、博客和行业口径

访谈和博客通常能提供两类信息：术语如何被从业者使用，以及团队如何描述训练阶段的组织逻辑。但这类资料常常省略失败实验、数据细节和工程约束，所以只能作为趋势背景，不能作为硬事实。

如果访谈声称某个阶段“非常重要”，本文会把它当作待验证假设；只有技术报告、可复现实验或团队内部 ablation 支持后，才进入训练决策。

### 2.4 从公开资料抽出的保守共识

第一，mid-train-like 阶段通常发生在 base 能力形成之后、post-training 之前。Qwen3、DeepSeek-V3、GLM-4.5 是主读样本；Qwen2.5-1M、OLMo 2、Phi-4、Llama 3 分别作为上一版专项、必要例外或降级参考。其中 GLM-4.5 和 OLMo 2 显式使用 mid-training 术语，GLM-4.5 进一步把 mid-training 拆成 code / reasoning / long-context 三个子阶段，是目前公开报告中子阶段拆分最细的样本。

第二，在 Qwen3、OLMo 2、Phi-4、Llama 3 等案例中，late-stage / continued pre-training 往往伴随更强的数据筛选、能力定向采样或高质量数据上调；但 DeepSeek-V3 这类 context extension 案例主要支持阶段化长度扩展，不直接支持数据配比结论。更稳妥的说法是：晚期 token 的边际价值更依赖质量、配比和训练目标，而不是简单追加 web tokens。

第三，长上下文不是只改 RoPE scaling。真实长上下文能力需要训练数据、长度 curriculum、位置/注意力机制、推理框架和评估任务共同成立。DCA、YaRN、sparse attention、chunked prefill 等技术要区分其作用位置：有些影响训练可行性，有些主要服务推理外推和部署成本。

第四，reasoning mid-train 更适合作为“提高 RL 可用 substrate”的强工程假设，而不是已被证明的普遍定律。较保守的说法是：如果 base/mid-trained checkpoint 对目标任务完全没有可解性，RL 通常很难稳定地产生能力；但 RL 是否带来真实能力增益，还取决于 pretraining 暴露、任务是否位于模型能力边界、reward 设计和探索预算。

第五，合成数据有价值，但不是免费午餐。Phi-4 说明 synthetic data 可以显著影响 reasoning 表现，也提醒团队仍需要有机数据来补世界知识、表达多样性和真实分布。

第六，透明的实验台账比单点榜单更重要。OLMo 2 这类报告的最大价值之一，是把 pretraining、mid-training、post-training 和数据构成分开描述，帮助后来团队建立自己的 lineage、分桶 loss 和回归评估。

第七，公开报告能证明“某些成熟团队采用了阶段化 late-stage training”，但很少能证明“某个数据比例、学习率或 token budget 是通用最优”。本文后续所有 recipe 表都应读作搜索空间和质量门，而不是从某个模型报告复刻出的配方。

## 3. 公开案例能证明什么，不能证明什么

本章不是模型报告复述，也不是 recipe 来源。案例只用于回答“哪些公开事实能转成内部检查项”，并遵循版本筛选规则：同一模型家族优先最新一版，最多上一版；更早样本必须写明保留理由。

| 案例 / 资料 | 使用级别 | 为什么保留 | 可安全归纳 | 不得推出 | 内部验证动作 |
| --- | --- | --- | --- | --- | --- |
| Qwen3 | 主读：当前/最新公开技术报告样本 | 披露 General / Reasoning / Long Context 三阶段 pre-training | capability shaping 和 context adaptation 可分目标管理 | 原报告自称 mid-training，或完整数据配比可反推 | 把能力与长上下文实验拆成不同 experiment_id |
| DeepSeek-V3 | 主读：DeepSeek-V 系列公开 base report 样本；若后续同家族新报告披露同类细节，应替换 | 披露 14.8T base pre-training 后的 32K/128K context extension，并强调架构/系统协同 | 长上下文必须同时验证训练、架构、serving、eval | context extension 等于普通数据继续训练 recipe | 做 offline/online 长上下文一致性和短任务回归 |
| GLM-4.5 | 主读：GLM 家族最新公开技术报告样本 | 显式使用 mid-training 术语，披露 ~1.1T tokens 的三子阶段（repo-level code / synthetic reasoning / long-context + agent），渐进式 4K→32K→128K context extension | mid-training 可按能力目标拆成多个子阶段独立管理；合成推理数据和 agent 轨迹数据可在 mid-train 阶段注入 | GLM-4.5 的 MoE 架构、子阶段 token 比例或专家路由策略直接适合 dense model | 按子阶段拆 experiment_id；MoE 需额外监控路由熵和专家负载 |
| Qwen2.5-1M | 上一版专项保留 | Qwen3 不替代其 1M context 训练、外推和部署细节 | 训练长度、推理外推、部署成本和真实任务要分开验收 | 直接 mid-train 到 1M，或纯推理技巧即可 | 分开记录 training length、serving config、latency/cost 和真实长任务 |
| OLMo 2 | 必要例外 | 明确使用 mid-training 术语，且披露数据混合、micro-annealing、post-training 分层 | mid-train 可独立管理并保留 lineage/eval gate | OLMo 2 的 Dolmino mix、token 数适合其它模型 | 建立 checkpoint lineage、mid-train scorecard、post-train 前评估 |
| Phi-4 | 必要例外 | 披露 synthetic data for pretraining and midtraining，且显式 midtraining 承担 4K -> 16K context 扩展 | 合成数据要有 verifier、风格多样性和有机数据兜底 | reasoning 增益可精确归因到“合成 CoT mid-train” | 建立 synthetic bucket 验证、模板重复率和人工错误率 |
| Llama 3 | 降级参考 | 仅在需要 late-stage continued pre-training、long-context pre-training、annealing 的公开细节时阅读 | late-stage 收敛需绑定高质量数据、LR、checkpoint 选择 | Llama 3 token budget 或 annealing recipe 是小团队默认值 | 把 annealing 当搜索变量，不当默认动作 |
| PRISM / pre-mid-RL 研究 | 机制假设，不属于模型版本线 | 用受控实验提出 retention、interaction、RL substrate 问题 | 机制假设可进入 proxy ablation | 可升级成产业大模型定律 | 用 paired SFT/RL protocol 验证收益保留 |

这张表的使用方式很简单：先读主读样本；只有当前模型报告没有覆盖某个关键问题，才读上一版或必要例外。若目标团队做的是某个特定模型家族，例如 Qwen、DeepSeek、Llama 或自研模型，内部资料包应优先替换成该家族最新报告，再保留最多一份上一版作为对照。

旧版本案例只保留三种情况：第一，它提供当前版本没有的术语或治理结构，例如 OLMo 2 的 mid-training 分层；第二，它提供专项能力的关键工程拆解，例如 Qwen2.5-1M 对 1M context 的训练/外推/部署拆分；第三，它提供一个仍未被新报告替代的受控变量，例如 Llama 3 的 annealing 或 Phi-4 的 synthetic data 边界。除此之外，旧模型不要进入主读清单。

## 4. Mid-train 的设计框架

本章先按第一轮最小闭环来读：Gate 0 冻结目标能力、不可牺牲能力、eval registry 和 post-train paired protocol；Gate 1 冻结 data manifest；Gate 2 用 control mix + 3-5 个单变量变体在 proxy scale 排除坏方向；Gate 3 用 target model 短程训练寻找能力/遗忘 Pareto checkpoint；Gate 4 用同一套 frozen post-train paired protocol 验证收益是否保留。4.1-4.6 分别解释这个闭环中的目标、数据、训练旋钮、ablation、curriculum 和组织质量门。

一个可执行的 mid-train 项目，最终应回答五个问题：目标能力是什么，哪些能力不能退化，能力由哪些数据桶驱动，训练长度/学习率/context curriculum 如何设置，以及如何证明它对 post-train 有帮助。

### 4.0 第一轮最小闭环

第一次做 mid-train 时，不要先设计完整训练系统。这里的“最小闭环”不是最小训练配方，而是最小证据链：用尽可能小的实验代价验证数据、训练、评估和 post-train 接力是否能形成可解释结论。先跑通一个目标、一个主假设、一组数据桶、一套 eval registry、一个短程训练窗口、一个 frozen post-train paired protocol。

| 闭环环节 | 只回答一个问题 | 最小证据 | 失败就回到哪里 |
| --- | --- | --- | --- |
| 目标 | 为什么必须 mid-train | 目标能力、不可牺牲能力、替代方案排除 | 回到 charter，改目标或不做 mid-train |
| 数据 | 哪个桶可能驱动目标能力 | data manifest、污染检查、linked eval、人工样例 | 回到数据桶准入卡 |
| 训练 | 低风险短程是否出现方向性收益 | 固定 LR/mix/context 的 checkpoint 曲线和分桶 loss | 回到训练旋钮或数据 mix |
| 评估 | 收益是否不是公开榜单或格式假阳性 | private holdout、raw output、人工审查、scorecard | 回到 eval registry |
| 接力 | post-train 后收益是否保留 | paired SFT/RL protocol、seed、AUC、失败样例 | 回到 post-train recipe 或 mid-train 目标 |
| 决策 | 是否 extend / rollback / kill | Gate dashboard、evidence_path、owner 签字 | 回到对应 gate |

第 11 章给出的是这个闭环的一组示例搜索网格，不是默认配方。第 4 章先讲设计对象，第 6-8 章讲如何判断证据，第 11 章才给可执行起步样例。

### 4.1 能力目标分层

建议把目标分成四层：

第一层：通用 base 保真

- 通用语言建模 loss 不异常上升。
- 常识、事实、多语、基础指令理解不明显退化。
- 多轮对话虽然不是 mid-train 主目标，但基本可读性不能崩。

第二层：核心能力增强

- 数学：GSM8K、MATH、AIME 类，以及内部可验证题库。
- 代码：HumanEval、MBPP、EvalPlus、repo-level completion、FIM、多文件定位等；SWE-bench 更适合在固定 harness、轻量 instruction wrapping 或 post-train readiness 阶段使用。
- STEM：GPQA、MMLU-Pro、领域题库。
- 推理：BBH、ARC、逻辑推理、复杂 QA。

第三层：结构能力

- 长上下文检索、综合、冲突消解。
- FIM、代码补全、多文件编辑。
- 表格、日志、长 PDF、长会议纪要理解。

第四层：post-train readiness

- SFT 后是否更容易学会目标格式。
- RL/RLVR 后是否更稳定提升。
- reward hacking 是否减少。
- 推理轨迹是否更可控。

### 4.2 数据桶设计

建议至少建立以下数据桶：

| 数据桶 | 目标 | 主要风险 | 建议控制 |
| --- | --- | --- | --- |
| 高质量 web / book | 保持通用语言与世界知识 | 噪声、重复、版权/合规 | 去重、质量分类、采样上限 |
| 代码 | 编程能力、形式化结构 | license、重复、benchmark 泄漏 | license 过滤、repo 去重、题库隔离 |
| 数学 / STEM | 推理与符号能力 | 过拟合竞赛题、解答错误 | 可验证题、难度分层、proof/answer 校验 |
| 合成教材 | 概念压缩、教学式推理 | 风格单一、teacher 错误 | 多 teacher、多模板、验证器过滤 |
| QA / CoT | 推理轨迹和任务格式 | 把 post-train 行为提前固化 | 控制比例，保留自然文本 |
| 长文档 | 长上下文适应 | 空洞 padding、低效 token | 真实长文档 + 合成长任务 |
| FIM / 代码编辑 | coding agent 能力 | 破坏普通 LM 分布 | 分桶 loss 和代码 eval |
| 领域数据 | 行业/产品能力 | 灾难性遗忘、狭窄化 | 低比例混入，通用回归 |

不要只做一个全局 mix。每个桶要有：

- 数据来源和 license 记录。
- 去重策略。
- 质量打分。
- contamination 检查。
- 采样比例。
- 单独 loss。
- 对应 eval。

### 4.2.1 数据桶准入卡

每个数据桶进入训练前，都应先进入 data manifest，而不是直接进入 mix。最小字段如下：

| 字段 | 说明 |
| --- | --- |
| `bucket_id` / `bucket_name` | 数据桶编号和名称 |
| `source_manifest` | 原始来源、时间范围、license / 合规状态 |
| `processing_commit` | 清洗、解析、过滤脚本版本 |
| `dedup_version` | 文档级、段落级、代码 repo 级、题目级去重版本 |
| `contamination_version` | 与 public benchmark、private holdout、合成 prompt 的污染检查版本 |
| `tokenizer_version` | tokenizer 和 special tokens 版本 |
| `quality_score_distribution` | 质量打分分布，不只写平均分 |
| `language_domain_distribution` | 语言、领域、文件类型、长度分布 |
| `time_distribution` | 数据时间范围、新旧分布、是否包含训练后新事件 |
| `sampling_weight` | 当前 mix 中采样权重和上限 |
| `shuffle_seed` / `bucket_interleaving` | 数据顺序、bucket 交织策略、是否阶段性改 mix |
| `bucket_validation_loss` | 分桶 validation loss 和异常变化 |
| `linked_eval_id` | 对应 eval registry 中的评估项 |
| `known_risks` | license、污染、模板化、重复、事实错误、分布过窄 |

数据桶准入门建议写成硬规则：

> [!CAUTION]
> - **没有 manifest/hash，不进入训练。**
> - **没有对应 eval，不提高采样权重。**
> - **污染命中未处理，不进入 primary 实验。**
> - **合成数据没有正确性过滤和风格多样性检查，不超过低比例探索。**
> - **领域数据没有通用回归保护，不进入主模型短程。**
> - **长上下文数据只有拼接文本、没有真实长任务，不进入 long-context primary mix。**
> - **任何改过滤器、质量模型、dedup 阈值、采样权重、合成生成 prompt 或数据顺序的动作，都必须生成新的 `data_manifest_hash` 和 `experiment_id`。**

### 4.2.2 合成数据使用边界

合成数据需要单独治理，因为它最容易在短期指标上“看起来很有效”：

| 风险 | 表现 | 控制方式 |
| --- | --- | --- |
| Teacher 错误放大 | 数学/代码答案看似流畅但不可验证 | 可执行验证、答案校验、抽样人工复核 |
| 风格模板化 | 输出都像同一个 teacher，推理步骤固定 | 多 teacher、多 prompt、多解法、混入有机数据 |
| Benchmark 近似污染 | 公开题变体大量出现 | 题干、解法结构、embedding 和 translated duplicate 检查 |
| 难度分布失真 | 训练题过简单或只覆盖一种题型 | 难度分桶、失败样例回灌、私有 holdout 对照 |
| CoT 行为前移过度 | base 模型过早学会冗长解释格式 | 控制 CoT 比例，混入短答、无 CoT、自然文本 |

**合成数据的合理用法是”可验证能力放大器”，不是低成本 token 替代品**。数学、代码、结构化推理适合多用可验证合成；开放域知识、语言风格、多语表达仍需要高质量有机数据兜底。

不同合成数据类型的边界也不同：

| 合成数据类型 | 适合用途 | 不适合用途 | 必须检查 |
| --- | --- | --- | --- |
| 可验证数学/代码 | 提高符号推理、可执行解题、单元测试能力 | 替代开放域知识 | verifier、答案执行、难度分桶 |
| 教材式解释 | 压缩概念、补齐知识结构 | 大比例替代自然语料 | teacher 多样性、表达模板、事实抽检 |
| CoT / rationale | 提供推理轨迹形式 | 让 base 过早固化冗长回答风格 | CoT 占比、短答混入、风格漂移 |
| 长上下文合成任务 | 覆盖稀缺长任务模式 | 替代真实长文档和长代码 | 证据位置、干扰信息、不可回答样本 |
| 领域合成 QA | 补足领域任务形态 | 替代真实领域文档 | 专家抽检、来源追踪、术语一致性 |

Synthetic bucket 还必须记录 teacher model/version、生成 prompt、采样参数、verifier 版本、过滤规则、被拒样本比例、模板重复率、答案可验证率、人工抽检错误率，以及生成器是否读过 eval/benchmark。合成 CoT/QA 要额外检查 style entropy、template n-gram 和 response length distribution，避免把 post-train 行为格式提前固化。

### 4.3 学习率和 token budget

公开报告通常不会完整给出所有细节，但工程上有几条稳健原则。

第一，mid-train 通常不应使用接近 pretrain 初期的高学习率。模型已经形成大量通用能力，过高学习率会导致遗忘、风格漂移和 loss spike。

第二，学习率策略要和目标匹配：

- 短程能力增强：低学习率继续训练，观察专项能力和通用回归。
- late-stage annealing：进一步降低学习率，用高质量数据收敛。
- context extension：学习率更保守，并配合长度 curriculum。
- domain adaptation：更要限制 token budget 和数据比例，避免模型变窄。

第三，token budget 不是越大越好。下面三档只是启动实验的保守刻度，不按模型规模线性通用，也不能替代 scaling ablation：

- 1B-10B tokens：用于 pipeline、数据质量、LR、污染检查和 proxy ablation。
- 10B-100B tokens：作为可观察能力增强和中小模型 recipe 验证的示例区间，实际预算要由模型规模、数据质量和 gate 结果决定。
- 100B-1T+ tokens：才适合主模型较完整的 capability shaping 或 long-context extension。

以上不是行业定律，而是工程上较保守的起步刻度。真正 token budget 应由模型规模、数据质量、目标能力和预算共同决定。

### 4.3.1 配方旋钮与不可同时改变原则

训练变量也要像数据和 eval 一样冻结版本。每次 run 至少记录：

| 变量 | 为什么要冻结 | 常见误判 |
| --- | --- | --- |
| `base_checkpoint_hash` | 决定起点能力和已有数据暴露 | 把不同 base 的差异误判成 mid-train 收益 |
| `optimizer_state_strategy` | 接续或重置会改变 loss 曲线和稳定性 | 重置后 warmup 不足导致假性退化 |
| `lr_schedule` / `warmup` | 影响遗忘、收敛和 loss spike | 只比较最终分数，不比较训练稳定性 |
| `peak_lr` / `min_lr` / `decay_shape` | 决定实际优化轨迹 | 都叫“低 LR”，但训练动态完全不同 |
| `gradient_clipping` / `precision` | 影响稳定性和数值误差 | 把数值不稳误判成数据 mix 问题 |
| `global_batch` / `microbatch` | 改变有效 batch 和训练噪声 | 小 batch 噪声被误判成能力波动 |
| `sequence_length_distribution` / `length_bucket_ratio` | 改变有效 token 分布和训练动力学 | 把长度变化带来的收益归因给数据 mix |
| `data_order` / `shuffle_seed` | curriculum、annealing、长上下文阶段对顺序敏感 | 同一 mix 不同顺序得出相反结论 |
| `packing_policy` / `masking_policy` | 影响 FIM、长文档和短样本比例 | 短任务退化但全局 loss 正常 |
| `checkpoint_selection_policy` | 决定最终比较对象 | 事后挑最佳 checkpoint 夸大收益 |
| `eval_cadence` | 决定何时发现遗忘和漂移 | 训练结束才发现不可逆回撤 |

Scale-up 也要保守。Proxy 成功只能说明某个方向值得继续，不说明目标规模必然成功。进入更大训练前至少满足四个条件：

1. 两个 scale 或 target 短程 run 的方向一致。
2. 分桶 loss、目标 eval、base regression 的变化能被同一个数据/训练假设解释。
3. 相同 mix 下不同 seed 不反转，训练吞吐、checkpoint resume 和监控已经验证。
4. 成本上可接受：如果放大 10 倍 token 后只可能换来边际小幅收益，就应先改善数据或 eval，而不是加预算。

一次实验不要同时改太多旋钮。建议把常见旋钮拆开看：

| 旋钮 | 可调方式 | 主要风险 | 观测信号 | 何时停止 |
| --- | --- | --- | --- | --- |
| LR / warmup | 低 LR、进一步降低、短 warmup sweep | 遗忘、loss spike、收敛过慢 | 全局 loss、分桶 loss、梯度范数 | spike 不恢复或保真指标快速下跌 |
| Token budget | 递增短程预算 | 浪费预算、过拟合窄分布 | checkpoint 间 delta、Pareto 曲线 | 边际收益消失或回撤扩大 |
| Sequence length | 逐步拉长长度分布 | 长训伤短任务、吞吐下降 | 长度分桶 loss、短任务回归 | 短任务显著退化或 serving 成本不可接受 |
| Batch / packing | 改 packing、混长短样本 | 有效数据分布改变 | 吞吐、padding、短样本 loss | 全局 loss 正常但分桶异常 |
| Optimizer state | 接续或重置 | 继承动量或 warmup 不足 | early loss、梯度、resume 连续性 | early instability 无法解释 |
| Synthetic ratio | 逐步增加上限 | 模板化、teacher 错误放大 | 私有 eval、风格审查、失败样例 | 风格坍缩或私有集不涨 |
| Domain ratio | 低比例混入 | 模型变窄、通用能力退化 | 通用回归、领域私有任务 | 领域涨幅小于通用回撤代价 |

### 4.4 第一轮 ablation 设计表

第一轮不要追求“最好配方”，而要快速排除错误方向。下表中的比例只是搜索变量示例，用来暴露灵敏度和坏方向，不能作为主训练默认 mix。

| 实验目的 | 模型规模示例 | Token budget 示例 | 数据 mix 搜索变量示例 | LR 变量 | 成功指标 | 停止条件 |
| --- | --- | --- | --- | --- | --- | --- |
| Pipeline 和 eval 校准 | proxy model，例如 1B/3B | 1B-3B tokens | 小样本全桶 mix | 低 LR 单点 | loss 正常、eval 可复现 | loss spike、eval 不稳定 |
| 通用保真底线 | proxy model，例如 3B/7B | 3B-10B tokens | 通用高质量占比 30/50/70% | 固定低 LR | 通用能力回撤可控 | 多语/事实大跌 |
| 数学/STEM 注入 | proxy model，例如 3B/7B | 5B-20B tokens | 数学/STEM 10/20/30% | 低 LR + 更低 LR | 数学提升且通用不崩 | 只提升公开题型 |
| 代码/FIM 注入 | proxy model，例如 3B/7B | 5B-20B tokens | 代码/FIM 10/20/30% | 固定低 LR | completion/FIM/repo task 提升 | 普通生成明显代码化 |
| 合成数据占比 | proxy model，例如 3B/7B | 5B-20B tokens | synthetic 5/15/30% | 固定低 LR | 可验证任务提升、风格多样 | 模板化或污染风险 |
| 主模型短程验证 | target model | 10B-100B tokens | 候选 2-3 个 mix | 低 LR sweep | Pareto checkpoint 出现 | 目标能力不涨或遗忘过大 |

这些实验的产出不是最终模型，而是决策：哪个数据桶有效，哪个比例危险，哪个学习率区间安全，是否值得进入更长主训练。

### 4.4.1 如何读 ablation

Ablation 的产出是排除坏方向和形成候选 Pareto，不是证明最终配方。建议按五条规则判读：

1. **Proxy 成功不等于 target 成功**；进入主模型前需要两个 scale 方向一致，或 target 短程 run 复核。
2. **单一公开榜上涨不等于能力增强**；必须和 private holdout、失败样例簇、人工审查一起看。
3. **Target 能力提升必须和 guardrail 一起看**；数学/代码涨而多语、事实、自然生成明显跌，不算干净收益。
4. 接近阈值的结果要重复 run 或相邻 checkpoint 复核；**不要用一次 seed 的小幅收益做放大决策**。
5. **任何中途改 mix、filter、LR、长度 curriculum 或 eval 版本的实验，都必须重开 experiment_id。**

### 4.5 Curriculum：先能力，后长度，还是并行？

建议新团队不要一开始把所有目标混在一起。

更稳的顺序是：

1. Base 保真检查：确认 checkpoint、tokenizer、optimizer state、数据 pipeline、评估体系可用。
2. 能力型 mid-train：数学/代码/STEM/高质量合成数据，短程 ablation。
3. 长上下文适应：从较短 context 逐步拉长，单独监控长上下文 loss 和真实任务。
4. 小规模 post-train 接力：用固定 SFT/RL recipe 比较 mid-train 前后 checkpoint。
5. 决定是否合并为主训练配方。

为什么建议先能力后长度？因为长上下文训练成本高、debug 难，而且容易把架构和数据问题混在一起。如果模型基础 reasoning/代码能力没有改善，长上下文只是放大输入窗口，不一定放大任务能力。

也有例外：如果产品目标就是法律/金融长文档 QA 或代码库 agent，长上下文可以前置，但仍建议先在小模型上验证。

| 产品主目标 | 推荐先验 | 第一轮验证 | 反证信号 |
| --- | --- | --- | --- |
| 数学、代码、STEM、复杂 QA | 先能力，后长度 | 能力桶 + 通用保真桶短程 ablation | 目标能力只在 public benchmark 涨，private/人工样例不涨 |
| 法律/金融/科研长文档 QA | 能力和长度并行，但分两个实验 ID | 一条能力短程、一条 32K/64K context 短程 | 长上下文检索好但综合/冲突/不可回答任务差 |
| 代码库 agent / repo-level editing | 代码/FIM 与中长上下文并行 | FIM/repo task、长代码定位、短代码回归 | repo task 涨但普通代码生成或短任务明显退化 |
| 领域继续训练 | 先低比例领域，再看是否需要长度 | 领域桶 5/10/20% + 通用回归 | 领域任务涨幅小于通用能力回撤代价 |
| 长上下文展示能力 | 先确认产品价值，再做 context extension | 真实长任务、serving 成本、短任务回归 | NIAH 好看但真实任务、线上成本或短任务不成立 |

长上下文 curriculum 要记录长度分布，而不是只记录最大长度。每个阶段至少记录：

- 4K/16K/32K/64K/128K 样本比例。
- packing 策略、padding 浪费、短样本是否被过度上采样。
- 长样本来源：自然长文档、长代码、合成长任务、跨文档集合。
- 任务结构：证据密度、不可回答样本、冲突证据、多跳证据、证据位置、输出长度。
- 训练 kernel 与推理 kernel 是否一致。

否则“扩到 128K”只是一个最大长度声明，不能解释模型到底学到了长上下文理解、长距离检索，还是只学会在更长输入里保持 loss 不崩。

### 4.6 组织运行机制：角色、台账和质量门

Mid-train 项目不是训练团队单独完成的模型续训，而是 data、training、eval、post-train 四方共用同一张实验台账、同一组质量门的能力塑形项目。每个组织概念都必须绑定工程对象：checkpoint、data manifest、eval version、gate、owner 和 decision。

第一，设定 DRI，而不是泛泛“多团队参与”。

| 工作流 | 唯一 DRI | 参与团队 | 最终拍板 | 关键产出 |
| --- | --- | --- | --- | --- |
| 目标定义 | Model Lead | Product/Domain、Eval、Post-train | Model Lead | Mid-train charter、不可牺牲能力、实验假设 |
| 数据构建 | Data DRI | Research、Safety/Compliance、Eval | Data DRI + Safety/Compliance | 数据桶说明、data manifest/hash、lineage、contamination report |
| 训练执行 | Training Infra DRI | Model、Data、Infra | Training Infra DRI | 训练 runbook、LR/token budget 配置、checkpoint ledger、事故记录 |
| 评估体系 | Eval DRI | Model、Product/Domain、Post-train | Eval DRI | eval registry、私有 holdout、scorecard、人工审查样例 |
| Post-train 接力 | Post-train DRI | Eval、Safety、Model | Post-train DRI | frozen post-train paired protocol、readiness report、对齐回归 |
| 长上下文系统 | Infra DRI | Training、Eval、Serving | Infra DRI + Eval DRI | kernel/serving 一致性报告、KV cache/latency/cost 评估 |
| 风险与发布 | Safety/Compliance DRI | Data、Product、Release | Decision owner | 合规审查、风险登记表、go/no-go memo |

第二，实验台账要有固定 schema。没有台账的实验不进入结论；任何中途改 mix、改过滤器、改 eval 版本，都必须新建 experiment_id。

| 字段 | 说明 |
| --- | --- |
| `experiment_id` / `hypothesis` / `owner` | 实验编号、要验证的假设、唯一负责人 |
| `base_checkpoint_hash` / `training_code_commit` | 起点 checkpoint 和训练代码版本 |
| `data_manifest_hash` / `data_bucket_ratio` | 数据 manifest、采样权重、数据桶比例 |
| `dedup_version` / `contamination_version` | 去重、近重复和污染检查版本 |
| `lr_schedule` / `warmup` / `optimizer_state_strategy` | 学习率、warmup、optimizer state 接续或重置 |
| `token_budget` / `sequence_length_distribution` | token 预算和长度分布，不只记录最大长度 |
| `eval_suite_version` / `private_holdout_version` | eval registry、私有 holdout、harness commit |
| `seed` / `cost` / `incident_log` | 随机种子、训练成本、异常事件和处理动作 |
| `result_summary` / `decision` / `signoff` | 结论摘要，kill/retry/extend/promote 决策，签字人 |
| `post_train_readiness_result` | 固定 SFT/RL recipe 后收益是否保留 |

第三，质量门的唯一权威看板放在第 8.0 节；本节只定义角色、台账字段和签字责任。本文不能替团队设阈值，但 gate memo 至少要定义：目标能力最低提升、通用能力最大回撤、私有 eval 通过率、污染命中率上限、loss spike 处理规则、风格漂移判定、post-train 后收益保留比例。任何 gate 状态、证据路径、版本 hash 和过期时间，都以第 8.0 节 dashboard 为准。

| Gate | 进入条件 | 退出条件 | 阻断条件 | 签字人 |
| --- | --- | --- | --- | --- |
| Gate 0: charter | 目标能力、不可牺牲能力、预算和 post-train 接力需求明确 | Mid-train charter 通过；v1 eval registry 和 v1 post-train paired protocol 状态以第 8.0 节 dashboard 为准 | 无 DRI、无 paired protocol owner/schema、无私有 holdout owner/schema | Model Lead、Eval DRI、Post-train DRI |
| Gate 1: 数据冻结 | 数据源、license、清洗、去重和污染检查完成 | data manifest/hash 冻结，人工抽检无系统性错误 | benchmark 泄漏、license 不清、合成数据模板化明显 | Data DRI、Safety/Compliance DRI、Eval DRI |
| Gate 2: proxy ablation | 至少两个候选 mix 和固定 eval suite | proxy 只用于排除坏方向；进入主模型前需两个 scale 方向一致，或 target 短程验证关键信号 | 只涨公开 benchmark，私有任务不动，通用能力大跌 | Model Lead、Eval DRI、Data DRI |
| Gate 3: 主模型短程 | 训练 runbook、resume、监控和 kill switch 就绪 | 出现能力/遗忘 Pareto checkpoint，分桶 loss 可解释 | NaN、不可恢复 loss spike、梯度异常、吞吐异常、resume 不连续、长上下文伤短任务 | Training Infra DRI、Eval DRI、Model Lead |
| Gate 4: post-train 接力 | paired protocol 的 recipe、seed、预算、harness、失败判定已冻结 | 固定 paired protocol 下 post-train 后收益仍保留，安全/风格无显著恶化 | mid-train 收益在 post-train 后消失、paired protocol 中途改变，或对齐难度显著增加 | Post-train DRI、Eval DRI、Safety DRI |
| Gate 5: 放大训练 | 收益来源可解释，数据/eval/训练自动化稳定 | go/no-go memo 通过，进入下一阶段预算 | 收益依赖污染、窄评估、偶然 checkpoint 或无法复现 | Decision owner、Model Lead、Release owner |

第四，会议节奏要服务决策，不服务汇报：

- Daily training review：loss、吞吐、NaN/loss spike、checkpoint、resume、事故处理。
- Twice-weekly eval review：目标能力、通用回归、私有 holdout、人工样例审查。
- Weekly decision review：kill、retry、extend、promote，只基于台账和 gate memo 决策。
- Post-train handoff review：paired protocol 是否有效，收益是否保留，安全和风格是否退化。

这套机制的底线是：**日历不能替代质量门**。90 天只是参考节奏，是否进入下一阶段由数据就绪度、训练稳定性、eval 稳定性和 post-train 接力验证决定。

## 5. 训练工程检查点

### 5.1 启动前检查

启动 mid-train 前，应完成：

- Base checkpoint 的完整 eval 快照。
- Optimizer state 是否接续的决策。
- Tokenizer 和 special tokens 冻结。
- 数据去重和 benchmark contamination 检查。
- 每个数据桶的样例审查。
- 小规模 dry run，确认 loss、吞吐、显存、checkpoint、resume 正常。
- Post-train DRI 确认后续 SFT/RL 的 paired protocol。

如果没有 post-train 接力验证，mid-train 很容易优化错目标。

### 5.2 训练中监控

至少需要监控：

- 全局 training loss / validation loss。
- 按数据桶分解的 validation loss。
- 通用能力 benchmark 的回归。
- 目标能力 benchmark 的增益。
- 长上下文不同长度段的 loss。
- 生成样例的风格漂移。
- MoE 模型的专家负载、路由熵和 token drop。
- 梯度范数、loss spike、checkpoint 间差异。

**不要等训练结束才做 eval。** Mid-train 的失败常常在早期就有信号：通用 eval 大跌、输出风格模板化、某个数据桶 loss 异常、长上下文短任务退化。

### 5.3 Checkpoint 策略

建议保留：

- pre-mid checkpoint。
- 每个阶段的 early/mid/final checkpoint。
- 学习率变化前后的 checkpoint。
- context length curriculum 每个长度阶段的 checkpoint。
- 用于 post-train 接力的候选 checkpoint。

不要只保留最后一个。**Mid-train 的最佳 checkpoint 可能不是 loss 最低的 checkpoint，而是目标能力和遗忘之间的 Pareto 最优点。**

### 5.4 容易低估的工程风险

第一，mixed-length batching 和 context parallelism 会带来负载不均。长上下文 batch 的吞吐、显存碎片、padding 浪费和通信模式都和短上下文不同，训练监控必须按长度段拆开，否则全局吞吐会掩盖局部不稳定。

第二，optimizer state 接续或重置都可能出问题。接续 optimizer state 更像原训练轨迹延长，但可能继承旧阶段动量；重置 optimizer state 更干净，但需要重新设计 warmup，否则容易出现 loss spike 或过慢收敛。两种方案都应先在 proxy scale 测。

第三，**训练 attention kernel 和部署 attention kernel 不一致会制造假阳性**。离线 eval 通过，不代表线上 128K/1M 服务可用；长上下文训练、推理外推、kv cache、chunked prefill、sparse attention 和 serving 框架必须联合验证。

## 6. 评估体系

### 6.0 从 benchmark list 到 eval registry

Mid-train 的评估系统不是榜单集合，而是一组带版本、污染状态、运行 harness、阈值和原始输出存档的 eval object；**没有进入 registry 的评估结果，只能作为观察，不能作为 go/no-go 依据**。

每个项目最多设置 3-5 个 primary 指标，另设若干 guardrail 和 diagnostic。Primary 太多会诱导 cherry-pick，diagnostic 太少会让团队不知道为什么涨跌。

### 6.1 Eval registry 的最小 schema

Eval DRI 应在 Gate 0 冻结 v0 owner 和 schema，并在进入 Gate 1 前冻结 v1 eval registry。最小字段如下：

| 字段 | 含义 |
| --- | --- |
| `eval_id` | 唯一编号 |
| `eval_family` | base regression / target capability / long-context / post-train readiness / safety-style |
| `task_name` | 任务名 |
| `data_source` | public / dev-private / sealed-private / final-blind / synthetic / human-written |
| `created_at` / `data_hash` | 创建时间和数据 hash；私有集必须早于对应训练数据 mix 冻结 |
| `split_policy` | dev / private holdout / regression set / final-blind |
| `contamination_check_version` | exact / n-gram / MinHash / embedding / paraphrase / translated duplicate / manual |
| `harness_commit` | 评估代码版本 |
| `prompt_or_wrapper_version` | base prompt、minimal prompt、few-shot policy、light instruction wrapper、agent harness 版本 |
| `decoding_params` | temperature、top_p、max tokens、pass@k 等 |
| `metric` / `aggregation` | accuracy、pass@k、F1、judge score、latency/cost 等，以及聚合方式 |
| `decision_role` | primary / guardrail / diagnostic |
| `threshold_or_guardrail` | 提升阈值、最大回撤、失败条件、最小显著差异 |
| `sample_size` | 样本量和抽样规则 |
| `manual_review_rubric` | 需要人工审查时的 rubric |
| `raw_output_path` | 原始输出存档位置 |
| `owner_note` | 解释性备注，不放组织责任 |

Eval 版本变更规则要写死：改样本、改 prompt、改答案抽取器、改 metric、改 harness、改阈值，都必须生成新 `eval_suite_version`，旧结果不能横向混比。

私有 holdout 建议分三层：

- dev-private：调 pipeline、校准 harness，不进入最终 gate。
- sealed-private：阶段门使用，禁止针对它调数据 mix 或 prompt。
- final-blind：只在 Gate 5 或发布前使用，避免被反复优化成“另一套训练目标”。

### 6.2 Eval suite matrix

| Eval family | 目的 | 代表任务 | 适用 checkpoint | Metric | 失败信号 | Raw output 要求 |
| --- | --- | --- | --- | --- | --- | --- |
| Base regression | 保护不可牺牲能力 | 通用知识、多语、基础生成、事实 QA | pre-mid、mid、post-train 后 | 最大回撤、低分桶变化、人工审查 | 平均分小跌但某语言/风格崩 | 固定样本篮子完整输出 |
| Target capability | 判断目标能力是否真的变强 | 数学、代码、STEM、领域任务、FIM | pre-mid、mid | delta、难度分桶、私有任务通过率 | 只涨公开榜，私有任务不动 | 成功/失败样例簇 |
| Long-context | 判断长上下文是否可用 | 多证据 QA、冲突消解、长代码定位、长表格/日志 | mid、post-train 后 | 长度分桶表现、短任务回归、latency/cost | needle 满分但真实任务差 | 输入长度、证据位置、backend 配置 |
| Post-train readiness | 判断收益是否在 SFT/RL 后保留 | 固定 SFT/RL recipe 后的真实任务和安全评估 | paired post-train checkpoints | 收益保留比例、训练曲线 AUC、方差 | base 涨但 post-train 后消失 | recipe、seed、checkpoint selection policy |
| Safety/style | 防止风格、安全和拒答漂移 | 安全集、拒答边界、中文写作、长答案质量 | mid、post-train 后 | 回归率、人工 rubric、拒答误伤 | 模板化、冗长 CoT、幻觉变多 | 人工审查样本和评分理由 |

目标能力 eval 回答“能力是否真的变强”；base regression eval 回答“有没有伤到别的能力”；post-train readiness eval 回答“这个 base 变化是否能穿过 SFT/RL 仍然有价值”。

### 6.3 Base regression eval

Base regression 的重点不是证明模型更强，而是保护不可牺牲能力。它应覆盖：

- 通用知识：MMLU、MMLU-Pro、内部知识题。
- 推理：BBH、ARC、GPQA、逻辑题。
- 数学：GSM8K、MATH、AIME 风格内部题。
- 代码：HumanEval、MBPP、EvalPlus、repo-level completion、FIM、多文件定位。
- 多语：中文、英文和目标市场语言。
- 生成质量：长回答、摘要、解释、翻译、自然对话。

Base model 未必稳定遵循复杂格式，所以要区分“能力不足”和“格式不服从”。每个 base eval 应记录 minimal prompting、few-shot policy、答案抽取器版本和人工复核规则。SWE-bench、agent 任务、tool-use eval 混入了指令遵循、工具协议、环境稳定性和 scaffold 质量，更适合作为 readiness/diagnostic，而不是裸 base 主指标。

Base regression scorecard 至少报告：

- 不可牺牲能力最大回撤，而不只是平均分。
- 低分桶和长尾语言变化。
- 输出风格、拒答、冗长程度和幻觉样例。
- 固定人工审查样本篮子的结论。

### 6.4 Target capability eval

Target capability eval 要和 base regression 分开。它不只是问“公开榜有没有涨”，而是问“目标能力是否在真实任务和私有任务上变强”。

| 目标能力 | 评估方式 | 必要防线 |
| --- | --- | --- |
| 数学/STEM | 难度分桶、可验证答案、私有变体题、失败样例簇 | 防止竞赛题近重复和 synthetic overfit |
| 代码/FIM | HumanEval/MBPP/EvalPlus、FIM、repo-level completion、多文件定位 | SWE-bench/tool-use 作为 readiness 或 diagnostic |
| 领域能力 | 领域私有题、真实文档 QA、专家人工 rubric | 防止领域数据让通用能力变窄 |
| Agent/tool-use | 固定 harness、环境版本、工具协议、任务轨迹 | 不把 scaffold 变好误判成 base 变强 |

如果目标能力只在 public benchmark 上升，而 private holdout、失败样例簇和人工审查不支持，应先视为污染、格式适配或窄分布优化。

### 6.5 Long-context eval

长上下文评估要分三层：

- 机械检索：Needle-in-a-haystack、多 needle、不同位置和不同噪声密度。它只能作为 diagnostic，不应进入主 gate。
- 真实理解：长文档 QA、多章节摘要、多证据综合、冲突信息判断、长表格/日志分析。
- 任务完成：长代码库修改、多文件 bug 定位、法律/财报/论文综合分析、agent 轨迹复盘和下一步决策。

长上下文 eval registry 必须按轴展开：

| 轴 | 必测切片 |
| --- | --- |
| Context length bucket | 4K、16K、32K、64K、128K；如目标是 1M，再加 256K/1M |
| 任务类型 | 检索、摘要、多证据 QA、代码定位、跨段推理、不可回答问题 |
| 证据密度 | 稀疏事实、密集表格、长代码、冲突证据 |
| 干扰信息 | 无干扰、同主题干扰、矛盾证据、过期信息 |
| 证据位置 | 开头、中间、末尾、多位置证据 |
| 输出要求 | 短答、结构化表格、长答案、引用证据 |
| 推理 backend | attention kernel、KV cache、chunked prefill、batching、serving 配置 |
| 成本约束 | latency、吞吐、显存、单位请求成本 |
| 短任务回归 | 短任务放进长上下文后是否退化 |

长上下文的 hard gate 不应只看“最长长度能跑通”。更合理的门槛是：短上下文能力不明显退化，中长上下文真实任务有收益，推理系统在目标长度下成本和延迟可接受。

### 6.6 Post-train readiness eval

Post-train readiness 要用 paired protocol：

- pre-mid checkpoint 和 mid checkpoint 使用同一套 frozen post-train paired protocol。
- 固定数据顺序、seed、预算、checkpoint selection policy、reward/verifier、harness、decoding 和失败判定。
- 关键结论接近阈值时，跑多 seed 或重复 run，并报告方差或 bootstrapped CI。
- 不用“最佳 post-train checkpoint”做事后比较；要比较固定预算、固定选择规则下的结果，或报告训练曲线 AUC。

这里冻结的 SFT/RL recipe 是诊断仪器，用于比较 pre-mid 与 mid checkpoint，不代表最终生产 post-train 配方。若为追求更好结果而调整 recipe，应重新登记 experiment_id，原 mid-train 结论不得直接沿用。

| 比较项 | 看什么 | 失败信号 |
| --- | --- | --- |
| 收敛速度 | 同预算下是否更快达到目标能力 | 只在个别 seed 变快 |
| 最终能力 | 目标能力是否在 post-train 后仍保留 | base 涨，post-train 后消失 |
| Reward 行为 | RL 是否减少 reward hacking 或提升可验证任务 | 冗长推理、投机格式、答案漂移 |
| 安全/风格 | 拒答边界、中文表达、长答案质量 | 安全回归、模板化、拒答误伤 |
| 长上下文 | post-train 后长任务是否继续可用 | SFT 后长上下文能力被覆盖 |

四格判读：

| 结果 | 解释 | 决策 |
| --- | --- | --- |
| base 涨，post-train 后也涨 | 最可信的 mid-train 收益 | 可进入放大候选 |
| base 涨，post-train 后不涨 | 可能是 base eval 假阳性或 post-train 覆盖掉收益 | 回到数据/eval，不能直接放大 |
| base 不涨，post-train 后涨 | 可能改善了可训练性或与 SFT/RL 交互 | 重复 seed 和真实任务验证 |
| base 跌，post-train 后涨 | 高风险 trade-off | 只有不可牺牲能力未破坏时才可继续 |

### 6.7 Scorecard：如何读评估结果

每个候选 checkpoint 都应生成一页 scorecard。它是 Eval DRI 给 gate 的输入，不替代 4.6 的最终 go/no-go 决策。

| 字段 | 内容 |
| --- | --- |
| `checkpoint_id` | checkpoint hash、训练步数、token 数、context length |
| `target_capability_delta` | primary 指标变化、难度分桶变化、私有任务变化 |
| `base_regression_max_drawdown` | 不可牺牲能力最大回撤和低分桶变化 |
| `private_holdout_result` | dev-private、sealed-private 的使用情况和结果；final-blind 在 Gate 5 或发布前应保持 unused/reserved，并记录是否仍未触碰 |
| `long_context_result` | 长度分桶、真实任务、短任务回归、serving 配置 |
| `post_train_readiness_result` | paired protocol、seed、收益保留、方差 |
| `contamination_status` | exact/near-duplicate/embedding/manual 检查结果 |
| `known_regressions` | 已知退化、失败样例簇、人工审查结论 |
| `recommended_action` | kill / retry / extend / promote |

**如果某个指标收益异常高，而私有任务、人工审查和相邻 eval 不支持，应先假设污染、格式适配或过拟合，而不是先宣布能力突破。**

Gate meeting 里先看一行红黄绿摘要，再看完整 scorecard：

| 状态 | 含义 | 会议动作 |
| --- | --- | --- |
| Green | target、guardrail、private holdout、post-train readiness 同方向支持，且证据路径完整 | 可讨论 extend/promote |
| Yellow | 有收益但方差、回撤、污染、post-train 保留或 serving 成本仍不清楚 | 指定 owner 补证据，不进入放大 |
| Red | 不可牺牲能力越线、污染/license 未清、事故未归因、post-train 后系统性变差 | rollback/kill，或重开 experiment_id |

## 7. 风险与事故处理 Runbook

第 7 章不是失败模式科普，而是训练中的事故处理 runbook：任何异常都必须能落到一个症状、一个实验 ID、一个受影响 checkpoint、一组证据路径和一个继续/回滚/kill 决策。

### 7.0 如何使用本章

正常监控、eval registry 和 gate 机制分别放在第 4-6 章；本章只处理异常。触发异常后，值班 DRI 先冻结现场，再做 30 分钟首轮诊断，最后给出临时决策。没有完成归因前，不要在同一个 run 里改数据、改学习率、改 eval harness 或改 post-train recipe。

事故出现后先做三步，不要先改配置：

| 步骤 | 动作 | 输出 |
| --- | --- | --- |
| 1. 冻结现场 | 保存 checkpoint、optimizer、data manifest、eval raw outputs、系统指标和相关 commit | `incident_id` 和 evidence paths |
| 2. 判定级别 | 判断 observation / alert / blocker，指定 30 分钟首查 owner | 临时 stop/continue 决策 |
| 3. 分层隔离 | 依次做 system replay、data manifest diff、eval harness diff、model checkpoint diff | root cause 或 unresolved 标记 |

事故先按六类登记：

| 事故类型 | 典型范围 |
| --- | --- |
| numerical | NaN、Inf、loss 爆炸、梯度异常、混合精度溢出 |
| data | 数据桶污染、格式漂移、license 问题、合成数据模板化、采样权重错误 |
| eval | harness、prompt、judge、metric、抽样或污染导致的分数异常 |
| infra | 吞吐、GPU 利用率、NCCL、存储、checkpoint、serving 配置异常 |
| capability | 目标能力不涨、通用能力回撤、guardrail 变坏、长上下文真实任务退化 |
| post-train handoff | SFT/RL 接力后收益消失、reward hacking 增加、recipe 噪声放大 |

> [!CAUTION]
> **硬规则：任何能力结论或训练效果结论必须先完成四层隔离**：system replay、data manifest diff、eval harness diff、model checkpoint diff；若某一层与事故无关，应标记为 `N/A` 并写明理由。**证据不齐时，只能登记为未归因事故，不能写入能力结论。**

### 7.1 事故分级：观察、警报、阻断

| 级别 | 触发信号 | 现场动作 | 可否继续训练 |
| --- | --- | --- | --- |
| 观察 | 单个 eval 小幅波动、分桶 loss 轻微偏移、单次 seed 接近阈值 | 记录 incident_id，复跑相邻 checkpoint 或固定样本篮子 | 可以继续，但不能 promotion |
| 警报 | 连续 checkpoint 指标异常、public/private 分歧、某数据桶 loss 明显偏离、目标能力涨但 guardrail 变坏 | 冻结变量，拉 Data/Eval/Training DRI 做 30 分钟首查 | 视 guardrail 决定；通常暂停放大 |
| 阻断 | NaN/Inf、resume 不连续、污染或 license 不清、不可牺牲能力越线、离线可用但线上不可服务 | 停止 run 或停止发布，回滚到最近健康 checkpoint，开事故复盘 | 不继续，除非复盘后新建 experiment_id |

处理原则：

| 原则 | 具体做法 |
| --- | --- |
| 先冻结现场 | 保存 checkpoint、optimizer state、训练日志、data manifest、eval raw outputs、系统指标和相关 commit |
| 先分层归因 | 分清 system、data、eval、model、post-train recipe 哪一层先变了 |
| 先看分桶 | 全局 loss 正常不代表数据桶、语言、长度、任务都正常 |
| 先保护 guardrail | 不可牺牲能力超阈值回撤时，不用等目标能力继续上涨 |
| 不做隐性修补 | 改过滤器、采样权重、prompt、harness、judge、decoding 或 serving config 都必须新建 experiment_id |

### 7.2 训练中事故 triage 表

| 事故类型 | 现场症状 | 30 分钟首查 | 分层归因 | 立即决策 | 必须留档 |
| --- | --- | --- | --- | --- | --- |
| numerical | NaN / Inf / loss 爆炸 | 梯度范数、overflow 计数、LR/warmup、最近 batch、optimizer state、resume 日志 | system：精度/kernel；data：坏样本；model：LR/clip；checkpoint：resume | 阻断；回滚到最近健康 checkpoint，replay 问题 batch | `checkpoint_id`、batch id、overflow log、optimizer hash、replay 结果 |
| numerical / model | 阶段切换后 loss spike | 阶段切换 commit、LR schedule、mix 权重、长度分布、optimizer/RNG 是否连续 | data：mix 突变；model：schedule；system：resume；eval：窗口口径 | spike 可解释且快速恢复则观察；持续异常则 rollback | phase-change diff、前后 3 个 checkpoint 曲线、data manifest diff |
| infra | 吞吐下降 / GPU 利用率异常 | tokens/s、MFU、dataloader wait、NCCL、存储 IO、kernel 版本、batch shape | system 优先；确认前不要解释为模型变化 | 暂停能力结论；必要时停 run 排查 | system metrics、profile trace、代码/镜像版本、复跑对比 |
| data | 全局 loss 正常但某桶 loss 异常 | bucket validation loss、sampling weight、tokenizer/packing、manifest diff、样例抽查 | data 优先；再看 tokenizer/packing 和 eval bucket | 冻结或下线问题桶；严重时 rollback manifest | bucket id、manifest hash、抽样样例、过滤器版本、修复 diff |
| data / capability | 合成数据模板化或错误率升高 | teacher/version、prompt、verifier、template n-gram、response length、人工错误率 | data：生成器；eval：样例太窄；model：学到格式而非能力 | 降低 synthetic ratio 或隔离桶；不把格式收益写成推理收益 | generator config、verifier 版本、重复率、人工审查记录 |
| capability | 通用能力早期大幅回撤 | base regression max drawdown、低分桶、语言/领域固定篮子、数据 mix | model：LR/训练过长；data：专项比例过高；eval：抽样偏差 | 触发 guardrail；回滚或降低专项比例 | scorecard、失败样例簇、mix curve、rollback 点 |
| capability | 目标能力上涨但 guardrail 变坏 | 目标指标、不可牺牲能力、相邻 checkpoint、错误类型变化 | model/data 权衡；确认不是 eval 口径变化 | 不 promotion；只有 trade-off 被业务接受且可复现才 extend | Pareto 曲线、guardrail 阈值、DRI 签字、样例对照 |
| eval | Eval 突然大涨/大跌 | data_hash、harness_commit、prompt/wrapper、judge、decoding、答案抽取器 | eval 优先；用同一 checkpoint 跑新旧 harness diff | 冻结能力结论；旧/新 harness 交叉复跑 | eval diff、raw outputs、judge 版本、metric 变更说明 |
| eval / data | Public benchmark 涨但 private 不涨 | contamination report、private holdout、题型相似度、raw output | data 污染或 eval 过拟合；也可能 public 太窄 | 从 primary 指标降权；不能放大 | contamination 证据、holdout 使用记录、剔除样本列表 |
| capability / context | Needle 好但真实长任务差 | 长任务 raw output、证据位置、信息密度、不可回答样本、长度分布 | eval：needle 过窄；data：缺综合/冲突任务；system：serving 差异 | 不把 needle 作为主 gate；暂停长训放大 | 长任务失败簇、证据定位、长度桶分数、serving 配置 |
| capability / context | 长上下文训练伤短任务 | sequence_length_distribution、短任务回归、packing/padding、短样本占比 | data：长样本稀释；model：位置/attention 适应副作用 | 回滚长度 mix 或恢复短样本比例 | 长度分布 diff、短任务 scorecard、curriculum 版本 |
| infra / context | 离线长上下文可用但线上不可用 | serving config、KV cache、chunked prefill、batching、kernel、latency/cost | system 优先；模型能力结论暂缓 | 系统阻断；不发布，不把线上失败记成模型失败 | offline/online config diff、线上 raw output、profile |
| post-train handoff | Post-train 后收益消失 | paired protocol、seed、SFT/RL 数据版本、checkpoint selection、训练曲线 AUC | post-train recipe 或 base eval 假阳性；也可能 mid-train 不稳 | 不放大；重复 paired run 或回到目标数据 | recipe hash、seed、A/B 曲线、post-train raw outputs |
| post-train handoff | Reward hacking 增加 | RL raw output、reward/verifier、拒答/安全、格式依赖、CoT 模板 | post-train reward 漏洞；mid-train 可能提前固化格式 | 降低行为格式数据；修 reward/verifier 后重跑 | reward 版本、hacking 样例、行为数据比例、修复记录 |
| infra | Checkpoint resume 不连续 | resume 前后 loss、optimizer/RNG、data cursor、checkpoint hash、训练代码版本 | system/checkpoint 优先；排除后再看 data/model | rollback；replay resume 测试通过后新建 run | checkpoint lineage、RNG/data cursor、replay log、代码 hash |
| eval | Checkpoint 间结论反复 | 相邻 checkpoint、CI/方差、多 seed、selection policy、raw outputs | eval 噪声或 selection 偏差；model 真实波动需二次验证 | 不用单点决策；报告曲线而非最好点 | selection policy、完整曲线、置信区间、失败样例 |

### 7.3 数据事故 runbook

数据事故的第一原则是隔离版本，不是现场修补。任何过滤器、生成器、去重、采样权重、tokenizer 或 packing 变化，都必须产生新的 data_version 和 manifest hash。

| 步骤 | 动作 | 退出条件 |
| --- | --- | --- |
| 1. 冻结 | 保存旧 manifest、采样权重、生成器配置、过滤器版本和抽样样例 | 能复现事故前的数据输入 |
| 2. Diff | 对比 token 数、语言/领域/长度分布、重复率、污染率、坏样本率 | 解释至少一个异常分桶 |
| 3. 隔离 | 下线或降权问题桶，保留通用保真桶和 guardrail eval | 问题桶不再进入继续训练 |
| 4. 复跑 | 用固定 checkpoint 复跑 data validation 和 linked eval | 证明修复来自数据，而不是 eval 改口径 |
| 5. 复盘 | 更新数据桶准入卡和 prevention_rule | 新 data_version 才能进入下一次训练 |

如果污染、license 或隐私边界无法解释清楚，应直接 kill 该数据版本。对 mid-train 来说，“可能污染但分数好”不是可接受状态。

### 7.4 训练事故 runbook

训练事故优先保护可恢复性。发现 numerical 或 resume 类问题后，不要先调学习率碰运气；先确认 checkpoint、optimizer、RNG、data cursor 和代码版本是否能 replay。

| 步骤 | 动作 | 退出条件 |
| --- | --- | --- |
| 1. 停表 | 标记 incident_id，冻结当前 run，不再写入能力结论 | 现场日志和状态完整 |
| 2. 回放 | 从最近健康 checkpoint 回放短窗口，确认是否可复现 | 能复现则定位，不能复现则记录系统不确定性 |
| 3. 单变量修复 | 每次只改一个变量：LR、clip、precision、bad batch、resume 逻辑之一 | 修复与指标变化可归因 |
| 4. 回归 | 重新跑分桶 loss、base regression 和关键 target eval | 没有新增 guardrail 事故 |
| 5. 决策 | kill / retry / rollback / extend / promote | 有 DRI 签字和证据路径 |

训练继续的最低条件是：数值稳定、系统 replay 成功、数据 manifest 未漂移、eval harness 未漂移。缺任一项，只能 retry 或 rollback，不能 promote。

### 7.5 评估事故 runbook

评估事故最常见的错误，是把工具变化当成能力变化。只要 prompt、wrapper、judge、答案抽取器、decoding、样本集或 metric 任一项变化，旧分数和新分数都不能直接横比。

| 排查矩阵 | 旧 checkpoint | 新 checkpoint |
| --- | --- | --- |
| 旧 harness | 复现历史基线 | 看模型真实增量 |
| 新 harness | 看工具口径变化 | 只作为新口径结果 |

只有当“旧 harness 下新 checkpoint 变好”和“新 harness 下旧 checkpoint 没有同等变好”同时成立，才可以把收益初步归因给模型。若 private holdout 被反复查看或调参，应降级为 dev-private，并重新建立 sealed-private 或 final-blind。

### 7.6 Post-train 接力事故

Mid-train 的收益如果在 post-train 后消失，先不要简单判定 mid-train 无效。需要同时排查四件事：

| 排查项 | 可能问题 | 处理 |
| --- | --- | --- |
| recipe 是否冻结 | SFT/RL 数据、seed、预算、reward/verifier、decoding 变化 | 重跑 paired protocol |
| selection 是否偏差 | 只挑了 post-train 最好点或 base 最好点 | 用固定 checkpoint selection policy |
| 能力是否被覆盖 | SFT 风格数据压过了目标能力，RL 奖励偏向短答或格式 | 若调整 post-train 数据/奖励，必须新建 experiment_id 或 paired_protocol_version 后再测 readiness |
| 收益是否是假阳性 | base eval 污染、public 过拟合、样例太窄 | 回到第 6 章 eval registry 和第 7.5 节 |

**如果 post-train 接力连续两轮在 paired protocol 下失败，且 base 端收益只存在于 public benchmark 或单个 seed，应 kill 该 mid-train 方向**；如果 base 端收益稳定但被 SFT/RL 覆盖，则把结论写成“post-train handoff 未打通”，不要写成“mid-train 无收益”。为排查覆盖问题而调整 SFT/RL 数据、reward、verifier、预算或 seed 时，旧 paired protocol 的结论不能继续作为 mid-train 收益证据，只能作为诊断线索。

### 7.7 事故复盘模板

每个警报或阻断级事故都要有一条复盘记录。复盘不是追责文档，而是让下一次训练能少踩同一个坑。

```text
incident_id:
experiment_id:
incident_type: numerical | data | eval | infra | capability | post-train handoff
severity: observation | alert | blocker
first_detected_at:
affected_checkpoint:
symptom:
root_cause: confirmed | suspected | unresolved
changed_variables:
rollback_point:
evidence_paths:
four_layer_isolation:
  system_replay:
  data_manifest_diff:
  eval_harness_diff:
  model_checkpoint_diff:
decision: kill | retry | rollback | extend | promote | unresolved
prevention_rule:
owner:
reviewed_by:
```

如果 `root_cause` 仍是 `unresolved`，事故可以关闭训练动作，但不能关闭认知结论：文档中只能写“未归因事故，已隔离”，不能写“模型能力退化”或“某数据桶有效”。

## 8. 给新团队的 90 天路线图

这张路线图是参考节奏，不是日历承诺。**进入下一阶段应由 Gate 0-5 决定，而不是由第几天决定。**

### 8.0 Gate dashboard：每一阶段只回答一个决策问题

90 天路线图的用途不是排期，而是把项目从“想训练”推进到“证据足够再训练”。每个 gate 只回答一个问题：

| Gate | 决策问题 | 必备证据 | Blocker | Owner | Next action |
| --- | --- | --- | --- | --- | --- |
| Gate 0 | 这个目标是否真的需要 mid-train | charter、不可牺牲能力、v1 eval registry、v1 post-train paired protocol | 目标可由 SFT/RAG/产品逻辑解决；eval 或 holdout 未冻结 | Model Lead | go / no-go charter |
| Gate 1 | 数据是否可以进入实验 | data manifest/hash、license、污染检查、抽样审查、linked eval | 数据来源不清、合成生成器读过 eval、holdout 泄漏 | Data DRI | data readiness memo |
| Gate 2 | proxy ablation 是否排除了坏方向 | 目标收益、通用回撤、两个 scale 或 target 短程信号、失败样例簇 | 只有 public benchmark 涨；合成数据模板化；proxy 结论不稳定 | Eval DRI | ablation decision memo |
| Gate 3 | 主模型短程是否值得继续 | checkpoint 曲线、分桶 loss、scorecard、事故记录、Pareto 结果 | NaN/loss spike、resume 不连续、guardrail 越线、长上下文伤短任务 | Training Infra DRI | extend / rollback / kill |
| Gate 4 | 收益能否被 post-train 保留 | paired SFT/RL 结果、seed、AUC、raw outputs、reward/safety 回归 | base 涨但 post-train 后消失；recipe 中途改变；reward hacking 增加 | Post-train DRI | readiness report |
| Gate 5 | 是否进入放大训练或收缩重做 | go/no-go memo、model registry、rollback checkpoint、成本收益判断 | 收益来自污染/窄评估/单 seed；事故未归因；无法解释回撤 | Decision owner | scale / shrink / stop |

> [!CAUTION]
> **只要某个 gate 的证据不完整，就不要用”再训一点看看”绕过去。** Mid-train 的项目成本高，**真正的节奏控制来自 gate，而不是日历**。

每个 gate 的 dashboard 记录还必须包含 `status`、`owner`、`evidence_path`、`version_hash`、`stale_after` 和 `next_action`。**没有证据路径的绿色状态，应视为黄色。**

### 第 0-14 天：定义目标和评估

对应 Gate 0，主责为 Model Lead、Eval DRI 和 Post-train DRI；本阶段的决策会议只回答一个问题：这个目标是否真的需要 mid-train。

交付物：

- Mid-train charter：目标能力、不可牺牲能力、目标 checkpoint、预算。
- Eval matrix：base eval、能力 eval、长上下文 eval、post-train readiness。
- 数据桶设计文档。
- 风险清单和 go/no-go gate。
- Frozen post-train recipe：SFT/RL 数据版本、训练预算、seed、harness、评估集和失败判定。

Go/no-go：

- 如果 eval registry、私有 holdout 和 post-train 接力 recipe 没有冻结，不进入训练。
- 如果私有 holdout 创建时间晚于训练数据混合，或允许针对私有 holdout 调参，不进入训练。

### 第 15-35 天：数据和小模型 ablation

对应 Gate 1-2，主责为 Data DRI 和 Eval DRI；所有实验必须登记到 4.6 的实验台账。

交付物：

- 例如 1B/3B/7B proxy model 上的数据 mix 实验；具体 scale 由团队现有模型谱系和预算决定。
- 学习率和 token budget sweep。
- 合成数据正确性和多样性报告。
- 每个数据桶的 loss 和能力关联分析。
- Data manifest/hash、near-duplicate 检测报告、污染检查报告、人工抽检样本。

Go/no-go：

- 至少一个 mix 在目标能力上提升，且通用能力回撤可接受。
- 合成数据没有明显污染和风格坍缩。
- Proxy 成功只说明坏方向被排除，不能证明 target scale 一定成立；进入主模型短程前，至少需要两个 scale 方向一致，或 target model 短程 run 验证关键信号。

### 第 36-60 天：主模型短程 mid-train

对应 Gate 3，主责为 Training Infra DRI、Eval DRI 和 Model Lead；本阶段必须先定义 kill switch，再启动训练。

交付物：

- 主模型短程训练，例如 10B-100B token 级窗口；具体 token budget 由 Gate 2 证据和训练成本决定。
- 每日 checkpoint eval。
- 能力/遗忘 Pareto 曲线。
- 候选 checkpoint 选择。
- 训练 runbook、checkpoint lineage、resume 记录、训练代码 commit、事故记录。

Go/no-go：

- 目标能力提升不是单一 benchmark 驱动。
- 通用能力下降低于事先定义阈值。
- 生成样例没有明显风格漂移。
- 出现 NaN、不可恢复 loss spike、梯度异常、吞吐异常、某数据桶 loss 反常、checkpoint resume 不连续，或长上下文训练伤害短任务时，触发停止或回滚。

### 第 61-75 天：post-train 接力验证

对应 Gate 4，主责为 Post-train DRI 和 Eval DRI；如果 post-train recipe 在本阶段改变，mid-train 结论应视为无效或重新标记实验 ID。

交付物：

- 固定 SFT recipe 对比。
- 如适用，固定 RL/RLVR recipe 对比。
- post-train 后真实任务评估。
- reward hacking / safety / style 回归报告。
- Post-train readiness report：recipe 版本、seed、预算、harness、失败判定和收益保留比例。

Go/no-go：

- Mid-trained checkpoint 在 post-train 后仍保留收益。
- 对齐难度没有显著增加。

### 第 76-90 天：放大或收缩决策

对应 Gate 5，主责为 Decision owner、Model Lead 和 Release owner；本阶段不是自动放大，而是决定继续、收缩、重做数据或停止。

交付物：

- 放大候选 recipe 或下一阶段收缩重做 recipe。
- 是否进入 100B-1T+ token 训练的决策。
- 数据和评估自动化改进清单。
- 长上下文或第二能力目标的下一阶段计划。
- Model registry：checkpoint lineage、data manifest、eval raw outputs、训练日志、权限、保留周期和可回滚 checkpoint。

Go/no-go：

- **如果收益主要来自污染、窄评估或 post-train 偶然性，不放大。**
- 如果收益稳定、可解释、可在 post-train 后保留，进入主训练。

## 9. 可执行 checklist

### 9.0 最小交付包与交付物索引

如果团队不想一开始就维护完整文档体系，至少要有下面 8 个交付物。缺任意一个，mid-train 结论都很难复盘。

| 交付物 | Owner | 模板位置 | 冻结 Gate | 用在哪个会议 |
| --- | --- | --- | --- | --- |
| Mid-train charter | Model Lead | 0.2 / 8.0 | Gate 0 | 启动会、go/no-go 会 |
| Data manifest | Data DRI | 4.2.1 / 9.1 | Gate 1 | 数据 readiness 会、事故复盘 |
| Eval registry | Eval DRI | 6.1 / 9.3 | Gate 0-1 | eval freeze 会、checkpoint review |
| Training runbook | Training Infra DRI | 4.3.1 / 5 / 7.4 | Gate 3 | train launch 会、事故处理 |
| Experiment ledger | Model Lead / PM | 4.6 | Gate 0 后持续更新 | 每周实验例会 |
| Checkpoint scorecard | Eval DRI | 6.7 | Gate 3-5 | checkpoint review、放大决策 |
| Post-train readiness report | Post-train DRI | 6.6 / 7.6 | Gate 4 | post-train handoff 会 |
| Incident review | 事故 owner | 7.7 | 警报/阻断事故后 | 事故复盘、prevention review |
| Go/no-go memo | Decision owner | 8.0 / 9.4 | Gate 5 | 放大、收缩或停止决策 |

Checklist 的作用是验收这些交付物，不是制造流程负担。对新团队来说，先把最小交付包跑通，比追求完美平台更重要。

每个 checklist 项都不应只打勾，还要绑定最小审计字段：

```text
owner:
evidence_path:
version_hash:
stale_after:
gate_role: primary | guardrail | diagnostic
status: green | yellow | red
```

如果一项检查没有 `evidence_path` 或 `version_hash`，它最多只能算 yellow，不能作为 gate 通过证据。

### 9.1 数据 checklist

- [ ] 每个数据版本都有 data manifest/hash，记录 source snapshot、processing commit、tokenizer、dedup、contamination、sampling weight、shuffle seed。
- [ ] 每个数据源有 license / 合规记录。
- [ ] 每个数据桶有质量打分和人工样例审查。
- [ ] 每个数据桶绑定 linked_eval_id，未绑定 eval 的桶不提高采样权重。
- [ ] benchmark contamination 检查完成。
- [ ] 训练集、验证集、私有 holdout 分离。
- [ ] 合成数据记录 teacher/version、prompt、采样参数、verifier、过滤规则、拒样比例、模板重复率、人工错误率。
- [ ] 合成数据有正确性过滤、多样性、模板化和 style entropy 检查。
- [ ] 长上下文数据包含真实长任务，不只是拼接文本。
- [ ] 通用数据保留比例有 ablation 支持。

### 9.2 训练 checklist

- [ ] Base checkpoint eval 完成。
- [ ] Tokenizer / special tokens 冻结或变更有充分理由。
- [ ] Optimizer state 接续策略明确。
- [ ] LR schedule、warmup、peak/min LR、decay shape、gradient clipping、precision 记录清楚。
- [ ] global batch、microbatch、packing/masking、data order、shuffle seed 记录清楚。
- [ ] checkpoint selection policy 在训练前冻结。
- [ ] 每个阶段有 checkpoint 保存策略。
- [ ] 分桶 validation loss 可观测。
- [ ] MoE/attention/long-context 系统指标可观测。
- [ ] 训练可 resume，checkpoint 可复现。

### 9.3 评估 checklist

- [ ] Eval registry 已冻结，包含 eval_id、eval_family、data_hash、harness_commit、prompt_or_wrapper_version、metric、decision_role、threshold_or_guardrail、raw_output_path。
- [ ] Base eval、能力 eval、长上下文 eval 分开。
- [ ] 每个 eval 标明 primary、guardrail 或 diagnostic，primary 指标不超过 3-5 个。
- [ ] 指标包含真实任务和人工审查。
- [ ] 不只看平均分，也看能力回撤。
- [ ] 每个候选 checkpoint 生成 scorecard，包含目标能力 delta、最大回撤、污染状态、失败样例和建议动作。
- [ ] 每个候选 checkpoint 做同一套 eval。
- [ ] 私有 holdout 分为 dev-private、sealed-private、final-blind，创建时间早于训练数据 mix 冻结，且不得针对 sealed/final 调参。
- [ ] 长上下文 eval 覆盖长度、位置、信息密度、任务类型和部署一致性。
- [ ] Post-train 接力 recipe 固定，并记录数据顺序、seed、harness、预算、checkpoint selection policy 和失败判定。
- [ ] Post-train 后收益可复现。

### 9.4 组织 checklist

- [ ] 数据团队、训练团队、Post-train DRI 共用同一张实验台账。
- [ ] 每次实验记录数据 mix、LR、token budget、context length、eval 版本。
- [ ] Research、Data、Training、Eval、Post-train、Release owner 均已明确。
- [ ] Model Lead、Data DRI、Training Infra DRI、Eval DRI、Post-train DRI、Safety/Compliance DRI、Product/Domain DRI、Decision owner 均已明确。
- [ ] Mid-train charter、data manifest/hash、eval registry、runbook、checkpoint ledger、post-train readiness report、go/no-go memo 均有 owner。
- [ ] 项目开始前冻结“不可牺牲能力”和各阶段回滚条件。
- [ ] 每个 gate 的阈值、阻断条件和签字人已在实验前写入 gate memo。
- [ ] 任何中途改 mix、改过滤器、改 eval 版本的行为都会新建 experiment_id。
- [ ] 训练中有停止条件。
- [ ] 放大训练前必须过 go/no-go gate。
- [ ] 发布前保留 pre-mid、mid、post 三类 checkpoint 的完整报告和 model registry。

## 10. 对有 post-train 经验的基模团队的特别提醒

第一，**不要用 SFT 的心智做 mid-train**（详见 1.2、1.4）。Mid-train 数据可以包含 QA、CoT、代码任务，但其目标不是让模型学会产品回答格式，而是改变能力分布。**自检：如果数据 mix 大部分是指令-回答对，大概率在做提前的 SFT，而不是能力塑形。**

第二，**不要让 RL 背所有锅**（详见 2.4 第四点、6.6）。如果 base model 没有足够的数学、代码、长上下文和自我纠错 substrate，RL 很可能只学到表面搜索或冗长推理。**自检：如果目标任务的 zero-shot pass@100 为零，说明能力不在 base 的可达边界内，RL 大概率无法稳定探索到正确解。**

第三，**不要只追榜**（详见 6.4、7.2 eval 事故、8.0）。Mid-train 的真实收益要在私有任务、真实产品任务和 post-train 接力中同时成立。**自检：如果某个 eval 收益超过 5 个百分点但私有 holdout 不动，先假设是污染或格式适配。**

第四，**不要一开始就追 1M context**（详见 4.5）。对多数团队，先把 32K/128K 做到可靠，比展示极长 context 更实际。**自检：如果短任务（<4K）性能在拉长后明显下降，说明 context extension 的成本还没控制住。**

第五，**不要忽视数据工程**（详见 4.2、4.2.1、9.1）。Mid-train 项目中，训练代码常常不是瓶颈，数据 lineage、污染控制、分桶 eval 和实验纪律才是。**自检：如果团队无法在 30 秒内说出当前训练使用的 data manifest hash 和污染检查版本，数据治理还没到位。**

## 11. 第一轮搜索空间：示例搜索网格，不可直接作为默认 mix

这一章是工作样例，不是配方。它的用途是帮助第一次做 mid-train 的团队把数据、训练、评估和 post-train 接力串成一个最小证据链（”最小闭环”的定义见 4.0）。

如果团队已有一个可用 base model 和稳定 post-train pipeline，建议第一轮不要做大而全，先做一个”能力型 mid-train + post-train 接力”的最小闭环。以下比例不是推荐 recipe，而是用于启动 ablation 的搜索空间；不同模型规模、预训练历史、目标语言和产品任务会显著改变最优 mix，主训练前必须通过 proxy scale 和短程主模型验证。下列比例和 token 区间只用于设计 ablation 变量，不得作为默认 mix、默认 LR 或默认预算。

只有在 base checkpoint、目标能力、不可牺牲能力、eval registry、data manifest 和 post-train paired protocol 已冻结后，下面的区间才可作为 ablation 变量；否则不应进入训练配置。

目标：

- 提高数学、代码、STEM 和复杂 QA。
- 不显著伤害通用、多语、事实和自然生成。
- 验证 SFT/RL 后是否仍有收益。

数据 mix 搜索空间（bucket sensitivity sweep 轴）：

- 高质量通用文本：用低/中/高几个点测试保真底线，例如 30/50/70%，不是固定占比建议。
- 代码与 FIM：用低/中/高几个点测试代码能力和普通生成漂移，例如 10/20/30%。
- 数学/STEM：用低/中/高几个点测试推理注入收益、饱和点和通用回撤。
- 合成教材/可验证推理：用上限 sweep 测试 verifier 质量、模板化和 teacher 错误放大。
- QA/CoT/短答任务形态：用单独开关或低比例混入测试格式漂移，避免把 post-train 行为格式提前固化。

这些 bucket 轴只用于第一轮单变量或少变量搜索，不是要同时满足的归一化比例表。实际 mix 必须通过小模型和短程主模型实验决定。

这个起点不是任何公开模型的复刻配方，也不是从公开报告反推出的最优比例。它只是一组便于新团队暴露数据冲突、遗忘风险和合成数据边界的搜索网格。

主训练前必须有 mix sensitivity curve，而不是只选择一个看起来最好的点。至少回答：

- 通用数据比例下降时，哪些不可牺牲能力最先回撤？
- 数学/STEM 或代码比例提高时，收益是否线性、饱和还是反转？
- Synthetic ratio 增加时，私有任务、风格审查和模板重复率是否同步恶化？
- 同一 mix 在不同 seed 或相邻 checkpoint 上方向是否一致？
- 目标能力收益是否足以补偿通用回撤和训练成本？

第一轮不要只跑一个 mix。更好的做法是保留一个 control mix，再围绕单一变量做小矩阵：

| 变体 | 改什么 | 不改什么 | 目的 |
| --- | --- | --- | --- |
| Control | 低风险通用保真 mix | LR、token budget、context length | 建立回归底线 |
| Math/STEM up | 只提高数学/STEM | 代码、通用、LR 不变 | 判断推理注入收益和遗忘代价 |
| Code/FIM up | 只提高代码/FIM | 数学、通用、LR 不变 | 判断代码能力和普通生成漂移 |
| Synthetic cap | 限制 synthetic 上限 | 其它桶不变 | 判断合成数据是否带来模板化 |
| General retain | 提高高质量通用数据 | 目标桶不变 | 判断通用保真能否降低回撤 |
| LR lower | 只降低 LR | 数据 mix 不变 | 区分数据问题和优化问题 |

每个变体只能改 1-2 个主变量。边训边改 mix、过滤器、LR 或 eval 版本，会让实验无法解释。

通过 Gate 2 后的主模型短程验证起点：

- 低学习率继续训练。
- 先用原 context length 或小幅扩展。
- 10B-50B tokens 级短程主模型验证上限示例；实际预算必须由 proxy 结果、target model 短程信号、遗忘阈值和成本共同决定。
- 每 10%-20% token 保存 checkpoint 并 eval。

评估起点：

- Base eval：MMLU/MMLU-Pro、BBH、GPQA、GSM8K/MATH、HumanEval/MBPP、多语集。
- 私有 eval：内部数学、代码、复杂 QA、真实用户任务。
- Post-train readiness：固定 SFT recipe，对比 pre-mid 和 mid checkpoint。

如果这轮闭环没有稳定收益，不要急着扩大 token budget。先回到数据和学习率。

## 12. 资料地图

本章不是文献综述的尾注，而是读者复核本文结论的路线图。使用原则是：同一模型家族先读最新一版公开技术报告；最多补读上一版；更早材料只在提供不可替代证据时保留，并在内部资料包中标为“必要例外”。

### 12.1 一手技术报告：事实底座

| 资料 | 使用级别 | 原文优先核查 | 本文如何使用 |
| --- | --- | --- | --- |
| Qwen3 Technical Report: <https://arxiv.org/abs/2505.09388> | 主读 | 三阶段 pre-training、reasoning/context 阶段、推理外推/部署技术 | capability shaping + context adaptation 的主样本 |
| DeepSeek-V3 Technical Report: <https://arxiv.org/abs/2412.19437> | 主读；若同家族新报告披露同类细节，应替换 | 14.8T pre-training、32K/128K context extension、架构与训练协同 | 长上下文扩展必须和架构、系统、训练稳定性一起看 |
| GLM-4.5 Technical Report: <https://arxiv.org/abs/2508.06471> | 主读 | 显式 mid-training 三子阶段：repo-level code（~500B，4K→32K）、synthetic reasoning（~500B）、long-context + agent（~100B，→128K）；MoE 355B/32B；~1.1T mid-training tokens | 多子阶段 mid-training 的工程拆分样本；合成推理和 agent 轨迹注入 mid-train 的参考；MoE 下 mid-train 路由/负载参考 |
| Qwen2.5-1M Technical Report: <https://arxiv.org/abs/2501.15383> | 上一版专项保留 | progressive long-context pre-training、post-training、DCA/YaRN、chunked prefill | 拆清训练扩展、1M 推理外推和部署优化的边界 |
| OLMo 2 Technical Report: <https://arxiv.org/abs/2501.00656> | 必要例外 | 明确 mid-training 分层、数据混合、micro-annealing、post-training | 学习阶段命名、data lineage 和透明实验台账 |
| Phi-4 Technical Report: <https://arxiv.org/abs/2412.08905> | 必要例外 | synthetic data for pretraining and midtraining；4K -> 16K context 扩展 | 合成数据治理、verifier、风格多样性和有机数据兜底 |
| The Llama 3 Herd of Models: <https://arxiv.org/abs/2407.21783> | 降级参考 | long-context pre-training、annealing、checkpoint 选择 | 只在需要 late-stage/annealing 公开细节时阅读 |

不要把这张表理解成“必读清单”。如果团队已经有目标模型家族的最新报告，应先替换主读样本；若新报告没有披露 mid-train 相关细节，再保留上一版或必要例外作为工程类比。

### 12.2 综述和受控实证研究：假设来源

| 资料 | 主要用途 | 使用边界 |
| --- | --- | --- |
| Mid-Training of Large Language Models: A Survey: <https://arxiv.org/abs/2510.06826> | 建立 mid-training taxonomy、任务类型和资料入口 | 综述是二手归纳，不能替代原报告事实核查 |
| A Survey on LLM Mid-training: <https://arxiv.org/abs/2510.23081> | 对比不同 mid-training 目标、数据形态和评估口径 | taxonomy 可借鉴，具体配方仍需内部实验验证 |
| PRISM: Demystifying Retention and Interaction in Mid-Training: <https://arxiv.org/abs/2603.17074> | 设计 retention / interaction / capability transfer 的受控 ablation | 受控实验的模型规模、数据和任务分布有限，不能直接外推为主模型预算 |
| On the Interplay of Pre-Training, Mid-Training, and RL on Reasoning Language Models: <https://arxiv.org/abs/2512.07783> | 建立“RL 是否依赖 pre/mid 阶段能力边界”的实验假设 | reasoning/RL 结论尤其要保守，需用团队自己的 RLVR/SFT paired protocol 验证 |

### 12.3 Claim / source matrix

| Claim | 正文位置 | 最强支撑 | 支持强度 | 建议措辞 |
| --- | --- | --- | --- | --- |
| 狭义 mid-training 可以独立管理 | 0 / 1 / 3 / 4.6 | OLMo 2 明确使用 mid-training；Phi-4 使用 pretraining/midtraining/post-training 分层 | 强：报告事实 + 工程归纳 | “公开报告中已有把 mid-training 独立成阶段的样本；团队可借鉴其治理方式。” |
| 许多案例只是 mid-train-like | 0 / 2 / 3 | Qwen3、DeepSeek-V3、Llama 3、Qwen2.5-1M 的原报告术语 | 强：报告事实 | “本文在工程意义上类比，不改写原报告术语。” |
| Qwen3 有 General / Reasoning / Long Context 三个 pre-training stage | 3 / 12.1 | Qwen3 Technical Report | 强：报告事实 | “Qwen3 原文称 Pre-training Stage，不称 mid-training。” |
| DeepSeek-V3 的长上下文扩展是 14.8T base pre-training 后两段 1000 steps | 3 / 12.1 | DeepSeek-V3 Technical Report | 强：报告事实 | “支持阶段化 context extension；不支持反推通用数据 mix。” |
| Qwen2.5-1M 的 1M 能力来自训练、post-training、外推和部署协同 | 3 / 12.1 | Qwen2.5-1M Technical Report | 强：报告事实 + 工程归纳 | “不是直接训练到 1M，也不是纯推理技巧。” |
| Llama 3 的 long-context 和 annealing 可作为 late-stage 参考 | 3 / 12.1 | Llama 3 Technical Report | 强：报告事实 | “405B 规模样本，不是小团队预算建议。” |
| 合成数据有价值，但必须治理模板化、污染和 teacher 错误 | 3 / 4.2.2 / 12.1 | Phi-4、Qwen3，以及合成数据相关受控研究 | 中强：报告事实 + 论文归纳 | “合成数据是可验证能力放大器，不是低成本 token 替代品。” |
| Reasoning mid-train 更像提高 RL substrate 的工程假设 | 2.4 / 3 / 6.6 | PRISM、pre/mid/RL interplay 论文 | 中：论文归纳 + 待验证假设 | “需用团队自己的 paired RL/SFT protocol 验证。” |
| Public benchmark 上涨不足以证明 mid-train 成功 | 6 / 7 / 8 | 多个公开报告的评估实践 + 本文工程治理 | 中：工程归纳 | “必须看 private holdout、raw output、污染和 post-train readiness。” |
| 公开报告通常不能给出可复制 recipe | 4 / 11 / 12 | 一手报告共同体现关键细节不完整公开 | 中：工程归纳 | “本文 recipe 表是搜索空间和质量门，不是公开模型复刻配方。” |

### 12.4 推荐阅读顺序

1. 先读目标模型家族最新报告；没有目标家族时，先读 Qwen3 和 DeepSeek-V3。
2. 只在做 1M/超长上下文时补读 Qwen2.5-1M。
3. 只在需要明确 mid-training 治理范式时补读 OLMo 2。
4. 只在合成数据是主变量时补读 Phi-4。
5. 只在需要 late-stage/annealing 公开细节时补读 Llama 3。
6. 最后读 survey、PRISM 和 pre/mid/RL 论文，把机制假设转成自己的 ablation。

## 13. Go/no-go memo 最小模板

具体启动动作见 0.2，交付物索引见 9.0。正文最后只保留一个决策模板：每一次 go/no-go 都必须能追到证据路径、版本和 owner。

```text
decision_id:
gate:
status: green | yellow | red
decision: go | no-go | retry | rollback | kill
target_capability:
non_regression_guardrails:
evidence_paths:
version_hash:
stale_after:
data_manifest_hash:
eval_registry_version:
post_train_protocol_version:
checkpoint_or_run_id:
known_risks:
owner:
signoff:
reviewed_by:
next_action:
```

**一个成熟的 mid-train 项目不是”训练跑起来”才开始，而是在第一个 checkpoint 产生前就已经能回答：目标是什么、不能牺牲什么、证据在哪里、谁来判定继续或停止。**

## 附录：使用边界与更新原则

本文可作为基模团队启动 mid-train 项目的内部手册，但不是训练配方，也不是公开模型的复刻说明。

| 维度 | 当前状态 | 使用时注意 |
| --- | --- | --- |
| 资料筛选 | 同一模型家族优先最新一版，最多上一版，更老版本只作为必要例外 | 使用前先复核目标模型家族最新报告，替换本文中的历史样本 |
| 事实限定 | 区分报告事实、论文归纳、工程归纳和待验证假设（第 12 章 claim/source matrix） | 新报告发布后按同一矩阵更新，不直接追加旧模型案例 |
| Recipe 边界 | 第 11 章是 sensitivity sweep 样例，不是默认 mix、LR 或 token budget | 放大训练前仍需内部 ablation、污染检查、holdout 管理和 post-train paired protocol 共同验证 |
| 风险控制 | 覆盖数据、训练、eval、infra、capability、post-train handoff 六类事故 | 需接入团队真实训练平台、eval 系统和 model registry 后才算工程落地 |