程序性推理骨架提取：构建跨域可迁移的推理结构中训练数据

触发动机

本周两篇论文的发现拼在一起，指向一个非常具体的数据构建思路。

发现 1：上海 AI Lab 的 “Rethinking Generalization in Reasoning SFT”（arXiv:2604.06628，HuggingFace 本周最热，226 upvotes）做了一项令人惊讶的实验——在 Countdown（一个简单的算术凑数游戏）上训练的模型，数学和代码任务的表现也提升了。前提条件是：训练数据包含清晰的”试错 → 回溯 → 验证”程序性步骤。论文的核心结论是：跨域迁移的本质不是学科知识，而是推理程序——分解问题、尝试方案、发现错误、回溯修正、验证结果。

发现 2：Apple 的 SSD（Simple Self-Distillation，arXiv:2604.01193）证明了一件违反直觉的事：Qwen3-30B 用自己在合适温度下的采样输出做 SFT，LiveCodeBench v6 的 pass@1 从 42.4% 直接跳到 55.3%——没有任何外部数据、没有教师模型、没有验证器。机理分析显示 SSD 通过重塑 token 分布来工作：在精度关键位置抑制干扰项，在探索位置保留多样性。

两者结合的洞察：如果推理 SFT 的泛化来自”程序性结构”而非领域内容，而模型自身的采样输出已经包含了这些结构，那么是否可以从模型的推理输出中自动提取”推理骨架”——剥离掉领域特定的内容，只保留程序性结构——作为中训练数据？

这不是简单的 self-distillation。SSD 是用完整输出做 SFT。我提出的是先提取骨架再做中训练——一个更早阶段（中训练 vs SFT）的、更抽象（骨架 vs 完整输出）的数据注入。

战略判断：为什么”程序性骨架”值得单独做

论文揭示的三个条件与一个反直觉

“Rethinking Generalization in Reasoning SFT” 揭示了推理 SFT 泛化的三个条件变量：

变量	要求	当前做法的问题
优化充分性	必须训够（多轮），早停会落在性能低谷	很多团队因为”过拟合恐惧”训练不足
数据程序性	必须包含试错/回溯/验证等程序性步骤	大量 SFT 数据只有最终答案，缺少过程
模型能力	≥8B 才能选择性学习推理连接词	小模型只学到长度和格式

反直觉发现：在 Countdown（凑数游戏）上训练可以提升数学和代码能力。这意味着推理能力的跨域迁移是真实存在的，且迁移的载体是程序性结构。

但论文也指出了一个严重的副作用：推理泛化和安全退化是不对称的——长 CoT 训练在提升推理能力的同时，会导致模型学会”自我合理化”来绕过安全约束。这意味着数据中需要有机制来保留安全信号。

为什么不直接用完整 CoT 数据

站内已有多个 proposal 涉及”长思维链数据构建”（形式化验证辅助的推理链、科学图表问答蒸馏等），但都是领域内的完整 CoT。问题在于：

1. 领域内容 vs 推理结构：完整 CoT 中，领域知识和推理结构混在一起。论文证明迁移的只是后者，但模型不一定能自动分离两者
2. 数据效率：完整 CoT 很长（数千 token），但其中真正有跨域迁移价值的程序性结构可能只占 20-30%
3. 中训练适配性：完整 CoT 更适合 SFT（有明确的 prompt-response 结构）。中训练需要的是连续文本形式的”推理范式暴露”

推理骨架恰好解决了这三个问题：剥离领域内容只保留结构、大幅压缩长度、天然适合 next-token prediction 形式。

竞争格局

据我所知（推测），目前没有公开的工作专门做”推理骨架提取”这件事。DeepSeek 和 OpenAI 的中训练数据细节不公开，但从他们的推理模型表现来看，某种形式的程序性推理训练应该已经在做了——只是很可能是”混在领域数据中”而非”专门提取骨架”。

核心思路

从强模型在不同领域的推理输出中，自动提取”推理骨架”——保留推理的程序性结构（分解、假设、尝试、回溯、验证、结论），替换领域特定内容为占位符或抽象描述——作为中训练语料注入，让模型在预训练阶段就内化跨域通用的推理程序。

用一个类比：如果完整 CoT 是一道数学题的详细解题过程，推理骨架就是”审题→分析条件→选择方法→尝试→发现不对→换方法→验证→结论”这个结构本身。

方法论

Step 1：多领域推理输出采集

使用强 Teacher 模型（如 Qwen3-72B 或同等能力的模型），在 6 个领域生成带思维链的推理输出：

领域	任务来源	目标量
数学	MATH、GSM8K-hard、AMC/AIME 题库	5,000 题
代码	LiveCodeBench、SWE-bench 子任务	5,000 题
科学	FeynmanBench、SciQ-hard、GPQA	3,000 题
逻辑	ARC、LogiQA2.0、Countdown	3,000 题
工具使用	ToolBench、BFCL 子集	2,000 题
搜索推理	HotpotQA、MuSiQue	2,000 题

采集时启用长思维链输出（如 Qwen3 的 <think> 模式），保留完整推理过程。使用领域验证器过滤错误答案。

Step 2：推理骨架自动提取

这是本 proposal 的核心技术环节。骨架提取分三步：

2a. 推理步骤切分

用 LLM 将连续的思维链文本切分为离散的推理步骤，标注每步的功能类型：

功能类型词表（8 类）：
- DECOMPOSE: 将问题分解为子问题
- HYPOTHESIZE: 提出解题假设或方案
- EXECUTE: 执行具体计算或操作
- CHECK: 检查中间结果的正确性
- BACKTRACK: 发现错误，回溯到之前的节点
- REFORMULATE: 重新理解问题或换一种方法
- VERIFY: 验证最终结果
- CONCLUDE: 得出结论

2b. 领域内容抽象化

将每步中的领域特定内容替换为结构化占位符：

原始（数学）：
EXECUTE: 将 x^2 + 5x + 6 分解为 (x+2)(x+3)

抽象后：
EXECUTE: 对 [表达式] 应用 [因式分解] 方法，得到 [分解结果]

原始（代码）：
CHECK: 运行测试发现 test_login 报 AssertionError，
       expected status 200 but got 401

抽象后：
CHECK: 执行 [验证操作] 发现 [错误类型]，
       [预期结果] 与 [实际结果] 不符

抽象的粒度是关键。过度抽象会丢失可学习的信号，过度保留会重新引入领域依赖。我提出的策略是保留操作类型（分解、搜索、比较），抽象操作对象（具体数字、变量名、函数名）。

2c. 骨架序列化

将抽象化的步骤序列化为连续文本，适合中训练的 next-token prediction：

[REASONING_SKELETON domain=math difficulty=hard steps=7]

DECOMPOSE: 原问题包含 [N] 个约束条件。先处理 [约束1] 和 [约束2] 
的关系，再将结果代入 [约束3]。

HYPOTHESIZE: 如果 [条件A] 成立，那么可以用 [方法X] 求解。

EXECUTE: 应用 [方法X]，对 [对象] 进行 [操作]，中间结果为 [值]。

CHECK: 验证 [中间结果] 是否满足 [约束2]... 不满足。
[检查失败原因]: [方法X] 的前提条件 [条件B] 在此处不成立。

BACKTRACK: 回到 HYPOTHESIZE 步骤。[条件A] 的假设可能有误。
重新分析 [约束1]，发现 [新观察]。

REFORMULATE: 基于 [新观察]，改用 [方法Y]。

EXECUTE: 应用 [方法Y]，得到 [最终结果]。

VERIFY: 将 [最终结果] 代回原始 [N] 个约束条件：
[约束1] ✓ [约束2] ✓ [约束3] ✓

CONCLUDE: 最终答案为 [结果]，置信度高。

[/REASONING_SKELETON]

Step 3：质量验证

骨架数据的质量验证不同于普通文本：

1. 结构完整性：每条骨架必须包含至少一次 DECOMPOSE 和 VERIFY，没有”虎头蛇尾”的不完整推理
2. 回溯真实性：如果包含 BACKTRACK，回溯理由必须与之前的 CHECK 失败一致（而非凭空回溯）
3. 非平凡性：排除”一步到位”的简单推理（DECOMPOSE → EXECUTE → CONCLUDE），保留包含至少一次试错/回溯的骨架
4. 跨域一致性：同一推理结构（如”分解→尝试→失败→换方法→成功”）在不同领域的抽象形式应该高度相似——如果差异过大，说明抽象粒度不对

Step 4：数据增强

基于提取的骨架，可以做两种增强：

增强 A：骨架复用——将从数学领域提取的骨架结构，用代码领域的内容重新填充。如果填充后的推理过程仍然是合理的，说明骨架确实捕获了跨域可迁移的结构。

增强 B：骨架变体生成——对同一骨架做微调，如在 BACKTRACK 后尝试不同的 REFORMULATE 路径，生成同一问题的多种推理路径骨架。这增加了推理策略的多样性。

输出格式

中训练语料：纯文本形式的骨架序列，按难度和领域交错排列。

每条骨架约 300-800 token（相比完整 CoT 的 1,500-5,000 token 压缩了 3-5 倍），但保留了全部的程序性结构信息。

规模与可行性估算

数据规模

阶段	领域	原始 CoT 数量	有效骨架	Token 量
采集	6 领域	20,000	-	~6,000 万
骨架提取	-	-	~14,000（70% 通过质量验证）	~700 万
增强 A（跨域填充）	-	-	~8,000	~400 万
增强 B（变体生成）	-	-	~14,000	~700 万
合计	-	-	~36,000	~1,800 万

1,800 万 token 的骨架数据，在中训练配方中占比 0.1-0.5%。规模不大，但论文证明程序性结构的迁移效果在小数据量下就可以观测到（Countdown 实验只用了几千条数据）。

资源需求

• Teacher 模型推理：20,000 × 6,000 token（平均输出）= 1.2 亿 token 的推理成本
• 骨架提取（LLM 辅助）：20,000 × 2,000 token（平均提取消耗）= 4,000 万 token
• 总 API 成本：约 $500-1,000（按 Qwen3-72B 级别定价）
• 人工审核：抽样 500 条骨架做质量校准，约 2 人天

时间线

• PoC（1 周）：数学 + 代码两个领域各 1,000 条，验证骨架提取的可行性和质量
• 全量生产（2 周）：6 领域全覆盖 + 增强
• 消融验证（2 周）：在 1B-8B 模型上测试中训练效果

与已有工作的关系

直接互补：

• 形式化验证辅助推理链（站内）：关注的是”正确性可验证”的推理数据，本 proposal 关注的是”跨域可迁移”的推理数据。两者的数据可以混合使用——形式化验证保证质量，骨架提取保证迁移性
• Adaptive 数据配比（站内）：动态调整数据分布的框架。骨架数据可以作为”通用推理能力”的底层数据，在 Adaptive 框架中作为基线混入各阶段

差异化：

• 与 SSD（Apple）的区别：SSD 用完整输出做 SFT，我提出的是提取骨架做中训练。阶段不同（中训练 vs SFT），抽象程度不同（骨架 vs 完整输出）
• 与 “Rethinking Generalization” 论文的区别：论文是分析性的（证明了程序性结构驱动泛化），本 proposal 是工程性的（怎么系统化地提取和利用这种结构）

数据独特性： 目前没有任何公开的”推理骨架”数据集。所有的推理数据——无论是 NuminaMath-CoT、OpenMathInstruct 还是 DeepSeek-R1 的蒸馏数据——都是完整的领域内推理过程。专门提取骨架结构作为独立数据类型是一个新方向。需要注意的是，骨架是否真的比完整 CoT 更有效是一个需要实验验证的假设（推测），这也是 PoC 阶段的核心验证目标。

落地路径

Phase 1：概念验证（1 周）

1. 选择数学和代码两个领域，各采集 1,000 条强模型 CoT
2. 设计骨架提取 prompt，人工审核 50 条确定提取质量
3. 提取 ~1,400 条骨架
4. 核心验证：在 1B 模型上对比三种中训练数据的效果：
   • (A) 完整 CoT（1,000 条数学 + 1,000 条代码）
   • (B) 数学骨架 + 代码骨架（等 token 量）
   • (C) 数学骨架 + 代码完整 CoT（混合）
5. 评估指标：数学→代码的跨域迁移效果、代码→数学的反向迁移效果
6. 产出：可行性报告 + 骨架提取 prompt 模板

Phase 2：全量生产与验证（3 周）

1. 6 领域全覆盖 + 增强数据生成
2. 在 8B 模型上做完整消融实验
3. 重点验证：骨架 vs 完整 CoT 在中训练阶段的效率差异（每 token 的边际收益）
4. 安全评估：确认骨架数据是否也会导致论文中发现的”安全退化”问题
5. 产出：~1,800 万 token 的骨架数据集 + 完整实验报告

Phase 3：集成优化（2 周）

1. 确定骨架数据在中训练配方中的最优占比
2. 与站内其他数据（任务执行轨迹、元轨迹、工具使用数据）联合训练
3. 设计持续生产管线：每周从新的 Teacher 模型输出中提取新骨架