Kimi K2背后的冷门绝招：海量语料“重写”如何榨干每个token？

李宇琛 2025-08-13 23:36 河北

一文看懂语料重写的全链路范式

©作者 | 李宇琛

研究方向 | 大模型预训练和对齐

前段时间 K2 作为国际一线模型发布，优秀的效果、开源权重和新技术验证赢得海内外一片掌声，其技术报告中罕见地提到了部分数据构成的细节，例如对于信息密度较高的领域数据进行大规模重写操作。笔者在过去一段时间恰好调研和实践过，遂有此文蹭一蹭热度。

LLM 研究早成显学，即便细分方向也堪称汗牛充栋，加上出发点、研究视角不同也导致很多工作内容相似却并互相认知和引用，难免挂一漏万，故此文也算抛砖引玉，欢迎各位同行朋友批评指正、补充观点和材料。

第一部分：K2中的语料重写

我们先从 K2 技术报告开始。K2 研发中的核心动机之一是尽可能提高 token 利用率，采用和优化 Muon 是第一步，重写（rephrase）预训练数据是第二步。

▲ 对长文本的自回归（顺序）分段重写 pipeline

报告中介绍了两个特定领域对应的改写方法：

1. 对高质量、信息丰富的知识类语料，只训练一个 epoch 非常浪费（参考 Physics of Language Models 的一千次曝光分析），因此：

• 调试 prompt 进行多风格、多视角改写，但同时需要保证信息的忠实度：

• 分块自回归：对长文档，先分块以适应改写模型窗口再改写，每次改写都会将前面改写完的内容拼接到窗口内，最后直接 concat

• 忠实度验证：猜测有一个微调的小模型或基于 SLM 调试 prompt

2. 对数学类语料，引用了 SwallowMath，将数学文档改写为“学习笔记的风格”，还将许多非英文高质量材料翻译成英文

幕间

在重写这一节最后，K2 列出了基于 LLM 进行批量数据重写的三类重大挑战：

1. 继续扩大多样性同时确保信息准确

2. 减少训练幻觉和毒性

3. 在大规模数据集上的可扩展性

以上三类问题，在语料库级别的 rephrase 任务或者说大规模数据合成任务中非常普遍。其通常流程是：

1. prompt 调试，找到有效的提示词模板，保证产生的文本大部分可用或只需要简单后处理，这在操作多样、庞大的语料库时并不容易，通常需要反复试验和有效的验证手段

2. 批量推理，需要推理效率并保证输出的正确性

3. 结果内容验证、后处理和错误重试

4. 实验验证数据效力，确认收益

目标语料库的复杂性和规模使得当面对不同领域、不同任务、不同产出目标甚至使用不同模型时，往往需要构造新的 pipeline，导致这类工作的可复用性并不高，为了保质保量甚至有可能退化成依赖专家但人力密集型工作，在 LLM 接触更少的大规模垂类数据任务上尤甚。下方文献的分析和评价中会有所体现。

另外，K2 此板块中只引用了两篇文章。如果作者是诚实的，倒也说明这类工作仍然比较缺乏统一、稳健的方法论，仍然需要大量人工干预。随着模型能力和方法的提升，我们是否有更多机会实现更高程度的自动化呢？

第二部分：大规模语料重写相关论文摘录

SwallowMath/Code：对数学和代码结合领域知识重写预训练数据

K2 引用的唯一一篇第三方数据合成工作，发表于 25 年 5 月 2 日。

作者是来自日本的 LLM 团队，该工作是他们基于 Qwen 基座研发日语大模型的分支任务。

论文：

Rewriting Pre-Training Data Boosts LLM Performance in Math and Code

https://arxiv.org/abs/2505.02881

数据集：

https://huggingface.co/datasets/tokyotech-llm/swallow-math

3.1 摘要

1. 代码：语法验证、pylint 风格过滤、两阶段重写

2. 数学：取出样板代码（boilerplate）、恢复上下文、重写 solution 为 CoT 形式的方案

3.2 相关工作

LLM-based 预训练语料库重写

1. 没提 rephrased web 这类工作

2. 引文 15 提到 LLM 将代码改写为指令，关注命名、模块化、注释，但只用来做微调

3. 本工作（SCOR ）则全面执行了 Google Python 风格的标准，包括变量名、类型注释、模块化函数、错误处理、可读性格式化等；还引入了语义增强，通过解决依赖关系、优化算法和把简单代码转换为有教学意义的示例提高自包含特性

4. 对低质量文本会优化升级

代码合成

领域种子的最佳实践不确定，不如利用已有的大量数据进行改写

3.3 Code 语料构建

基于实证和探索性方法驱动，每个步骤多种方法执行后预训练，根据结果评估是否采用

代码：

https://github.com/rioyokotalab/swallow-code-math

实验设置：

• llama 3.1 8B CPT，max_seq 8k，50B token 预算，gbz 4M token，每次消融不超过 1 个 epoch，10 个下游基准，每 10B token inference 一次

• 基于 Megatron-LM

过滤：

1. 语法错误过滤、linter-based 过滤。基于 LLM 的过滤耗费大效果差，没有采用

2. 语法错误过滤：Python3.10 用 compile() 函数编译每个代码样本，将样本从 41M 减少到 37M

3. 基于 linter：启发式评分，排除 7 分以下样本，36.7M→24.1M

4. 基于 LLM 的评分：prompt 里加入 Google 的风格指南，但相对改进不够有效

5. 基于 LLM 的改写

① SGCR：风格引导改写，参考 Google Python Style Guide

② SCOR：自包含优化改写，继续扩展为自包含结构和语法优化，例如更高效的算法和使用示例

6. 没有往 QA 对方向改写，而是保留原结构。Llama3.3 70B inst 执行

SGCR 方法

HumanEval 上升但 MBPP 大幅下降，发现可能是因为解决方案中使用非标准函数和类名（这是不是 openai 官方后续不测 mbpp 的原因……）

SCOR 方法

SGCR 的问题：

• 缺少依赖（幻觉）

• 算法效率低下

• 琐碎的代码段（常见的调试类型代码）

没有做消融，因为发现同时使用两种策略产生的数据不对，实际的实验顺序参考附录部分

3.4 数学

原始数据使用 finemath4+。重写策略包括

1. 删除页眉页脚和隐私声明

2. 取出不相关的元数据

3. 恢复不完整的问题或答案中缺失的上下文

4. 将推导步骤重写得简洁全面

5. 提供清晰、逐步的解决方案

3.5 附录

附录和代码库中给出了处理数据使用的函数和 prompt，以及代码消融实验的顺序：

3.6 评价

1. 从文章来看，K2 借鉴的数学语料合成并没有使用特别复杂的方法，反倒是代码的处理非常细致

2. 数据、处理代码开源得很彻底，是对行业的巨大贡献

reStructured pretraining

本工作发表于 2022 年，全文 112 页，正文 40 页左右，内容有点杂。有兴趣的朋友可以去考个“古”。原文太长内容太多我就不赘述了，核心内容提取如下：

1. 本工作从更高的高度对 LLM 的训练全过程进行了抽象，认为“更有效地利用信息是关键”；有价值的信息无处不在，但需要识别其中的“信号”并重构

2. 整理了几十个网站的典型数据，统一建模为 Text-to-text 生成任务（光是 prompt 模板就有 1K+），按此模式收集了大量训练语料，本质上是将原先形式不同的结构化数据改造为自然语言表述的文本

3. 构建了 Gaokao benchmark，基于 T5 架构训练的模型（RST）表现远超 GPT3 水平

4.1 评价

1. 整理的工作量是真大，非常好奇当初是想干啥……通讯作者 Pengfei Liu 当时开了家 startup，疑似想做数据生意，但后面应该是关掉了

2. 没错，就是上交 GAIR-NLP 的刘老师，Less is More、LIMO 的作者。cognition engineering、Journey Learning 等也都是他们的大作，看来数据集分析、精美的排版和插图是有传统的……

3. 与本文的关联：这篇的数据工作是按照经典 NLP 建模方式，把网页数据转换为与下游 benchmark 更接近的自然语言，因此达到同等 performance 需要的数据更少（但怎么感觉像 T5 中万物皆可 NLP 的扩展呢

4. 这篇应该是 LLM-based rephrase 类技术最早的工作之一。但看引用量跟实际的工作量完全不成正比

WRAP：重构网页语料的早期探索

论文：

Rephrasing the Web: A Recipe for Compute and Data-Efficient Language Modeling

https://arxiv.org/abs/2401.16380

5.1 评价

1. 非常详细的实验论文。motivation 似乎是想做开源的 Phi（的确 Phi 虽然模型开源界没人用，textbook quality 的理念非常有吸引力，像 EL5 等等的 CoT 风格优化也都是这套思路）

2. 初步效果看起来 promising，但细看已经说到了合成数据放大偏见、后处理麻烦的问题，使用方法也需要大量实验调试验证，与 K2 可以相互印证

3. 具体方法：用质量比较好（主要是指令理解和遵循）、部署高效的开源模型，人工定义几种模板去改写

4. 同时期 huggingface 的 Cosmopedia 也采用了这类方法，存在的问题也一样：多样性不足、依赖种子数据、幻觉隐患。这些问题是合成数据类工作普遍存在的

5.2 摘要

1. 该工作发表于 24.1，基于当时的开源指令模型按照特定 prompt 解释文档，基于 C4 数据集优化后可以加速预训练 3 倍以上；保持相同计算总量时，可降低 10%+ 的 PPL，13 个任务上 0-shot 提升 2%+

2. 基于风格重新措辞对模型影响很大，其中有些风格更接近评测

5.3 引言部分

1. 数据处理的行业黑盒；可预见的数据墙问题

2. 合成数据广泛使用，但方法上并不十分透明而且依赖高成本的商业 LLM API，而且不清楚合成数据的表现好是因为更高质量还是特定的主题选择

3. 提出了 WRAP 方法以应对三个挑战：

① 应该对哪些数据进行预训练？

② 如何使用有限的数据预训练？

③ 如何计算高效地预训练？

4. 解决了 Phi1 工作中遗留的两个问题：生成成本和数据偏差。

① 通过重新措辞，WRAP 允许更小的开源 LLM 以不同风格重新表述非结构化和措辞不佳的文档，因为 LLM 此处不作为知识库

② 由于改写的信息保持性，能够利用网页的自然多样性，而不用过度担心 LLM 产生的幻觉或额外偏见

③ 结果表明，仅仅风格的因素就能带来明显提升

5. C4 上应用 WRAP，合成数据预训练使等效模型的数据量减小 5 倍、计算量减少 3 倍，也优于 3T tokens 的 Tinyllama

① Pile 上降低了 50% 的困惑度

② 350M 参数在 C4 15% 的语料上训练真实+合成数据组合，表现优于整个 C4 上训练 1.3B 参数

6. 对数据泄露、合成数据格式特性、如何提升 WRAP 的效果做了分析

5.4 WRAP 技术

Phi 生成足够好的数据需要

1. 包含足够多世界知识的语言模型

2. 仔细选择提示以生成高质量、多样化的文章

3. 后续工作提到可能无意识中产生偏见，与网页数据的特性正相反

5.5 方法

1. 四种改写风格：简单、中等、困难、QA

2. 生成

① 使用 Mistral-7B instruct

② 对于“中等”：“对于以下段落，请用维基百科式词句的高质量英语进行同意复述”。这条 prompt 是经过迭代式人工反馈比较中等模型与 GPT-4 的输出而产生的（意思是没训模型，调 prompt 直到模型输出跟 GPT4 效果差不多）

③ 每段话 300tokens，因为经验发现输出超过这个长度时会产生信息丢失

④ 混合数据 1:1 采样

3. 实施细节：模型架构、预训练

5.6 评估

C4 训练，Pile 评估，原因是训练目标是最小化 C4 上的目标，多种风格则包含了多个分布，因此比较是不公平的，而采用第三者

1. 结果：在更复杂的领域数据上 ppl 下降更多；学习速度飞快

2. 基线：自己训练的、Pythia、TinyLLama

3. 一般改进：更少的数据更高的性能，真实数据没有起到明显作用

4. 专业知识：合成数据没有传授新知识，知识帮助更快训练

① 在更大数据集上得分更高

② 但改进已经饱和

5. 显著改进：TruthfulQA，在改写时纠正了潜在误解，添加真实数据会降低这一结果；其他结果损益不一

5.7 分析和消融

● 数据组合分析：真实 C4 数据有多重要？

• QA 提示的合成数据足够在 QA 任务中获得良好表现，但 Pile 困惑度增大了，可能是因为原始数据中有不少特殊字符，而合成数据相对干净

• 从预训练中删除真实 C4 数据单独训练合成数据会显著提高困惑度，可能是合成数据中不包含一些普遍存在的标签或样式

• WRAP 是更好的策略

● 多个数据集组合是否可以提高性能？

• 1:1、1:2 指 QA+medium:C4

• 发现 QA+C4 最佳

• 组合能降低困惑度

● 方法消融：高质量的 rephraser 有多重要？

• 使用四种复述模型，T5、Qwen1.8B、Mistral7B-chat、Vicuna

• 使用相同的提示

• T5-base 经过 Vicuna 的复述对训练（1epoch）

• Qwen、Mistral 都很好

• 但所有模型的复述都减少了 ppl

• 最小有多小，有待进一步验证

● 合成数据是否比增强有效？

• 基线：NL-Augmenter 的同义词替换和随机删除

• 15B token 训练 350M 模型，但总的 pool 仅有 1.5B

● 合成数据的风格如何影响特定领域性能？

• 没有全局最佳做法

• 性能提升是否因为数据泄露？

5.8 讨论

合成数据，还是训练更长时间？

● WRAP 有两种应用范式

• 低资源数据，例如小语种

• 丰富数据，例如 CC

● TinyLlama 显示更多 token 并没有带来更强性能

● 比较生成成本与额外训练成本

• Mistral7B 在单卡 A100 上每小时 300 万 token（vllm）。85B tokens 需要 25K GPU·H

• 64 卡 0.5M token 吞吐量，训练模型大概需要 6K GPU·H，13B 模型需要 30K GPU·H

• 基于合成数据可以减少时间到 3～10 倍

● 小模型用于改写更快更便宜，生成策略也能通过其他优化降低 3～5 倍

其他优势

1. 合成数据是一次性投资

2. 合成是 100% 可并行的，训练贵得多

生成多样性：写作辅助研究发现合成数据的多样性存在问题

Nemotron-CC：模型驱动的语料refine技术

24.12 发表，数据集开源

https://arxiv.org/pdf/2412.02595v2

6.1 评价

1. 多个打分器的方法比较新颖，启发了后续多个 model-based 数据过滤工作

2. 相比充实的内容效果说不上多惊艳。但最终产生的语料成为了 NV 在 Nemotron 系列开源模型的基石

6.2 TakeAways

1. 不同的 prompt、权重不同：4 种分类器合并打分，分 20 个桶，区分高低质量

① 高质量：多种方式改写（细节见原文附录，提供了 prompts）

② 低质量：提取其中的知识、规范化

2. 两种比较

① 1T 限制，HQ 数据比 DCLM 高不少，但总的数据集跟 DCLM 差不多

② 15T，比 llama3.1 强

3. 消融

① 提取器：Justext 比 Trafilatura 强

② 过滤器：对高质量数据，不用过滤器更好

③ 分类器：多种分类器合作使用比单个分类器好太多，召回率也更高

④ 合成数据的作用：有提升也有下降

ProX：让模型使用工具去除语料中的噪声

同样来自 GAIR-NLP，开源代码和数据集：

https://github.com/GAIR-NLP/ProX

7.1 评价

1. 把定制 SLM 用于文本清理，不是 rephrase 而是阅读后写脚本（此方法在 CodeContest+ 等工作中亦有应用），避免在长文输入输出中丢失信息，但比较依赖训练数据的多样性

2. 为了简化任务程序/处理函数只有固定的几种，模型需要学会使用哪几种脚本和正确填入参数

3. 实验很详细也有事后的 case 分析。错误（丢弃/清理）率居然很低，这点让人有些意外

7.2 TakeAways

1. proX 是对预训练语料的一种有效补充，与当前多种预处理技术正交；基于多个不同领域开源数据的处理和使用实验表明该方法相当有效

2. 算力投入训练还是推理（作为数据预处理），ROI 可估计

3. 基本方法：微调模型写处理脚本——放在现在也算一种会用工具的 agent 了？

▲ 算力分配效能对比

▲ 可以看到，定制模型输出的是编辑文本的函数

▲ 用到的函数也不多

▲ 他们是真喜欢用 Llama3.x

▲ 对比的基线我理解也不算很严格（采样类算法），可能是类似方法比较少

▲ 处理后的数据训练模型验证

▲ 处理后的文本长度分布：更短的数据占比减少

▲ 大规模处理时的运行算法

MAGA：结构化扩充预训练数据

https://arxiv.org/html/2502.04235

8.1 评价

1. idea 非常棒，让人觉得哇好简单但很合理

2. 实验详尽，但实施细节披露有限，文章写得比实际效果好看，值得学习

8.2 Takeaways

1. source data 是 smollm 的 fineweb-dedup

2. 基本方法是，rephrase prompt 中设定两个结构化变量，genre（风格/流派）和 audience（阅读者视角），这部分数据是从所谓的优质语料（未披露来源）中抽取得到，调试 prompt 收集样本，然后训练内部自研模型产生工具模型，在大规模语料库进行扩展，产生语料后经过一个 LLM judge 进行质量校验

总结：书读百遍，其义自见？

以上比较初步且有些随机地简述了几篇大规模语料重写技术的代表性工作：

1. SwallowMath/Code 体现了领域级定制化的作用，即结合领域知识的 prompting 和后处理对提升语料质量的帮助

2. reStructured pretraining 在 ChatGPT 前夜延续了 T5 的将语言相关任务统一为 text-to-text 语料的思路，暗合业界“面向下游场景合成数据”的普遍思路

3. WRAP 应该是比较早期在大规模语料库上进行的实验，算是更开放版本的 Phi 吧

4. Nemotron-CC 开源了相关数据集，也是比较早公开的、对不同价值评分的语料分情况处理的工作

5. Pro-X 考虑长内容复述的保真度问题，将改写转化为写脚本任务，降低了复杂度，而且脚本处理后的文本并不改变重要信息，主要去掉原文本中的噪声（页眉页脚、错误符号等等），基本不会改变原始分布

6. MAGA：将改写任务进行了风格维度上的初步结构化，利用“genre”“audience” 两个变量组合进行多倍扩充，明确了【多个定制化模型】+【多步改写和质量验证】的主要构件，以及一个比较常规的 pipeline

归根结底，语料库重写是数据合成方向在【有种子数据】+【语料库级规模】下的特殊情况，同样是扩充可用数据和提高信息利用率的候选解决方案。

“上规模”就意味着会遇到各种长尾问题，如何快速开发 pipeline 同时保证质量，或者确定一个比较好的 trade-off。

这类经验目前似乎都集中在头部厂商的特定 domain/task 上，且免不了高质量人类的参与（seed 开的日结“领域专家”岗位：什么？在想我的事？）；能够快速实现这套实验装置的工程师也值得更多的 pay（

另一方面，合成数据固有的数据多样性、有效信息量、幻觉控制等问题尚且看不到很好的解决方法，目前似乎还是人工归类处理。这么看如果哪天 LLM 能进化到自动正确处理数据，那也就是 AGI 了不是吗：）

就重述/改写语料本身而言，看起来也还有很多值得思考和探索的问题

1. 如何用低成本地重述/改写出最合适的内容？如何保证改写出的内容是我们想要的？

2. 改写质量的评估，更接近对写作还是指令遵循能力的评估？

3. 如何检测和抑制大规模改写中的幻觉问题？这类幻觉对模型的影响有哪些？

4. 如何调试/训练一个好的改写模型？

5. ……

另外笔者在做 surveying 时看到的一些相关且优秀的工作，推荐对合成数据感兴趣的读者阅读：

1. Evaluating Language Models as Synthetic Data Generators

2. The age of synthetic data and small LLMs

3. ORCHESTRATING SYNTHETIC DATA WITH REASONING

4. Self-Improvement via Synthetic Data Augmentation

5. 欢迎补充

🔍

现在，在「知乎」也能找到我们了

进入知乎首页搜索「PaperWeekly」

点击「关注」订阅我们的专栏吧

·

阅读原文

跳转微信打开