paper reading-pretrain data相关

October 31, 2026 · 18 min read

Tags:

ayanami

数据的配比一直是一个很重要甚至非常关键的问题，但，怎么配呢？目前大体可以分成两派，

传统派信奉人的先验和经验，靠人的一些想法，例 "语言 = 日语 && domain=工业自动化上采样"，因为日本的先进制造强革新派采用一些启发式搜索或者相信小模型的scaling law的方法，在小模型上进行一些消融搜索，然后scale到大模型如果从“科学”的角度来考虑，革新派肯定是更加科学的，但问题在于，国内给pretrain data的算力实在是有限，如果你太革新，那就验不完了，所以大部分pretrain data团队还是使用的传统 + 革新的方式，即，用传统派定一个或若干个方案，而方案的具体参数可以革新（不过这里的另一个玄学是，你到底信不信小模型的结果能scale到大模型，以及多大的模型的消融是可信的，以及你到底信不信你的metric和benchmark，显然，你的mmlu涨分的原因除了模型学到了更好的东西之外，也可能只是新分布更类似于bench数据的分布）

在最早的nvidia Nemotron-CC之中，就提出了两个实验结论：

质量分桶是对的，高质量样本完全可以多采样过滤的正确性要看质量，也要看多样性，提高阈值的方案是不如分档加权保多样性的方案的

而在weborganizer这篇文章之中，则更近一步，提出了领域分类树可以把网页数据按照领域（法律、代码、...）和形态（论坛、博客、...）分成两个领域树，把领域树和质量 join 起来进行配比，会比仅使用质量进行配比要好得多

而如何形成领域树，则有两派方案：聚类方案和人工方案，人工方案就是先归类一版，然后从共现矩阵和模糊case去衡量哪些领域是可以归并的，哪些领域划分的并不好，聚类就是先embedding再想办法找个解释

文章中的结论是，1. 人工方案是比聚类方案更好的 2. 聚类方案更类似于基于领域的分类，我们的embedding对与更general的骨架或者说格式其实是比较低敏感的

但不难看出，这些文章主要还是研究网页的配比问题，但code呢？ code的形态（如果以语言或者技术栈之类定义）的话和领域（如果以应用范围，例如前端、后端、系统...) 依然能保持这个交叉关系吗？

一些细微的差别是，code对于筛选其实是更加敏感的（数据不够），以及，code的形态，往往不局限于一个用于聚类的中间维度，而是作为目标本身存在（例如，网页没有about页，其实我觉得是没什么问题，code没有rust代码就不可能会写rust）...

在pretrain data中，构建可信的benchmark几乎等同于构建整个配比方案，可惜学界对此能做的探究确实太少, 写到此，笔者就再去进行了一些paper reading(让cc帮我找了找)，不过配比的文章确实不多，所以下面也很多是一些general的data部分

放点觉得有意思的部分和没意思的部分。

HERMES: A Multi-Granularity Labeling Substrate for Pre-training Data Mixtures https://arxiv.org/abs/2607.02266

ai-gen。

Essential-Web v1.0: 24T tokens of organized web data https://arxiv.org/abs/2506.14111

没什么好说的。

propella-1: Multi-Property Document Annotation for LLM Data Curation at Scale https://arxiv.org/abs/2602.12414

结论非常 well known：按语言配单独阈值，多维度避免 bias。

Topic Over Source: The Key to Effective Data Mixing for Language Models Pre-training https://arxiv.org/abs/2502.16802

结论非常 well known：按 domain 配比，按 source 配好。

QuaDMix: Quality-Diversity Balanced Data Selection for Efficient LLM Pretraining https://arxiv.org/abs/2504.16511

革新派传统文章，用拍脑袋的公式得到一个看似科学的配比，实则并不是很科学。

Scaling Laws for Mixture Pretraining Under Data Constraints https://arxiv.org/abs/2605.12715

有趣的观点，但暂时信度不大：长尾小领域可以训更多遍，但这个「更多」会随着模型变大而变小，只有个定性的结论，并且还是不一定可以 scale。

InfoLaw: Information Scaling Laws for Large Language Models with Quality-Weighted Mixture Data and Repetition https://arxiv.org/abs/2605.02364

公式太多太简化了，且暴力拟合（重复衰减 e 指数，指数因子实验数据拟合），但最后实验的论断是有一些意义的（虽然也 well known 了）：

首先，在训练令牌数量固定的情况下，较小的模型倾向于使用更高比例的高质量数据，而较大的模型则更注重数据多样性，因此分配给高质量数据的比例较小。其次，随着训练令牌总数的增加，最优 LayerMix 参数从优先考虑高质量数据转向优先考虑数据多样性。

The Finetuner's Fallacy: When to Pretrain with Your Finetuning Data https://arxiv.org/abs/2603.16177

给一个经验结论带来了一些定量实验：

为了最大限度地利用领域数据，应尽早将其纳入训练过程，垂域数据进预训 > 微调，CPT 的兴起就是类似的观点。

不过它得到了一个有趣的数字，这个增益在下游 bench 上约等于 50% 这个量级的 token efficiency 提升。

为了理解 SPT 为何能降低过拟合，我们比较了领域训练集与测试集之间的差距在预训练和微调过程中的变化（图6）。关键在于，在微调阶段，过拟合领域数据的风险远高于预训练阶段。在预训练阶段，领域词元仅占每个批次的一小部分，而周围的通用数据则起到了天然的正则化作用。

这个倒是其他论文也有提到：

预训练数据和微调数据之间的分布差距增大，SPT 带来的增益也随之增加

当预训练语料库已经包含领域相关信号时，在预训练期间纳入领域数据带来的改进较小

不奇怪。很容易想到的原则，反过来说，越是缺少对应的数据/能力，在预训就学足够的量越重要，这是否解释了一些工作想要把一些特殊的后训方向数据前移到预训？anyway，也再次佐证了预训数据分布的重要性。

Replay is not a substitute for early domain exposure.

Scaling Laws for Code: Every Programming Language Matters https://arxiv.org/abs/2512.13472

看过这篇，几个实验结论：

解释型与编译型语言的差异：解释型语言（如 Python）比编译型语言（如 Rust）对模型规模和数据扩展表现出更强的收益；而严格类型语言通常比动态类型语言更容易学习
语言复杂度排序（Irreducible Loss 序）：从易到难的复杂度顺序大致为：C# < Java ≈ Rust < Go < TypeScript < JavaScript < Python
多语言协同效应（Synergy）：多语言混合预训练能带来正向迁移，句法相似的语言之间协同效应最强（例如 Java-C# 或 JavaScript-TypeScript）

但我其实很 challenge 的一个点是，到底有多少结论是因为语言本身，有多少论断是因为不同语言的领域分布本身就不同。感觉除非根据语言分桶，论文的大部分结论并不能直接用。

并且局限于翻译任务有点 narrow。

On Code-Induced Reasoning in LLMs https://arxiv.org/abs/2509.21499

几乎所有扰动都会降低性能，使其低于未扰动的、经过微调的基线模型。更重要的是，结构扰动对性能的损害始终比语义扰动更为严重，尤其是在数学和编程任务中（例如，图3）。随着模型规模的扩大，这种差异更加明显（例如，图23）。这与先前的研究结果相似，即推理结构而非内容对学习过程更为关键（Li 等人，2025）。我们假设，数学和编程等任务更依赖于格式和布局线索来构建推理过程。

然而，对于其他任务，某些抽象形式（例如伪代码或流程图）通常可以达到甚至超越未扰动代码的性能，因为它们突出了算法结构，同时去除了表面语法。相比之下，最隐式的形式——自然语言过程——几乎没有优势，并且在所有任务中通常表现最差。

这个挺有意思的，结构而不是内容实质上引导了 reasoning。

大幅或适度降低密度通常能达到甚至优于基线的性能。

that's why we need info density in labeling

有趣的是，低可读性变体尽管增加了噪声或失真，但通常不会比未扰动的基线性能下降太多，而且通常与中等可读性变体的性能相当甚至更好（例如图6、图38-42）。这种反直觉的趋势表明，模型可以利用即使在噪声或不透明的形式中仍然存在的表面规律和重复出现的结构线索。

然而，在数学任务中，高级脚本语言的性能始终低于中级和低级系统语言（例如，图7顶部，图48-51(a)）。我们假设，低级语言中更丰富的结构细节为数学推理提供了有益的信号。

在单个语言层面（例如图7底部、图49-51(b)），在所有模型中，Python 在自然语言任务上通常表现最佳，这可能是因为其表面形式更接近自然语言。与群体层面的结果一致，Java 和 Rust 等底层语言在数学任务中通常名列前茅。对于跨多种语言的代码任务，结果则更为复杂，没有明显的领先者，性能差距也相对较小。

有意思的结论。

Not All Code Is Equal: A Data-Centric Study of Code Complexity and LLM Reasoning https://arxiv.org/abs/2601.21894

除了推理时的辅助之外，在训练过程中接触代码也被证明可以更广泛地增强推理能力：与仅使用自然语言训练的模型相比，使用代码数据训练的模型通常在多步骤推理和定量问题解决方面表现出更优的性能。

我们的研究结果表明，并非所有代码都是相同的。

代码微调并不能带来一致的推理增益：即使使用先前证明有效的代码数据集，改进效果也会因模型和基准测试的不同而有很大差异，并且很大程度上取决于微调数据的结构复杂性

代码复杂度和推理性能之间的关系是强烈的非单调的：准确率通常在中等复杂度水平上达到峰值，对于非常简单和非常复杂的代码都会下降

混合了所有复杂程度代码的控制数据集很少是最优的：在 83% 的实验中，将微调限制在特定的复杂程度范围内比在多样化的代码语料库上训练能产生更好的推理性能

很神奇的结论，但研究的是 posttrain 微调，pretrain 存疑。

绝对结构复杂性——而非这种复杂性是源于问题难度还是解法的多样性——才是影响推理能力的主要因素。

和上面那一篇的结论类似。

这些案例表明，结构复杂度并非仅仅是收益递减的信号，当其超出模型的有效范围时，还会导致负迁移效应。

这表明，先前报道的大型代码语料库带来的性能提升，可能并非源于多样性本身，而是更多地源于偶然接触到恰好适合特定模型的结构属性。

On the Interplay of Pre-Training, Mid-Training, and RL on Reasoning Language Models https://arxiv.org/abs/2512.07783

well known。

PRISM: Demystifying Retention and Interaction in Mid-Training https://arxiv.org/abs/2603.17074

感觉很多结论都不可信了啊，看起来像是兜兜转转几次才放出来的，怎么 26 年还在用 GPT-4，剩下的一些结论大多是 well known 的。

Understanding Reasoning from Pretraining to Post-Training https://arxiv.org/abs/2607.16097

强化学习过程中推理轨迹质量有所提高，但更深层次的搜索仍然具有挑战性。解析后的轨迹表明，模型主要扩展的是搜索的广度而非深度：搜索的宽度与深度之比以及分支因子均有所增加，而最大搜索深度则基本保持不变。

对于较简单的谜题，强化学习（RL）训练主要放大了 SFT 策略已经偏好的正确走法；而对于较难的谜题，它既会挖掘出 SFT 策略下几乎不存在的走法，也会强化错误走法。

感觉也基本 well known 了，前者和 pass@k 放大相同，后者看各家排各种 bug 就知道了。

Procedural Knowledge in Pretraining Drives Reasoning in Large Language Models https://arxiv.org/abs/2411.12580

好早期的文章，感觉似乎给到了一些结论，但这个实验 setting 有点太古早了。

Which Data Attributes Stimulate Math and Code Reasoning? An Investigation via Influence Functions https://arxiv.org/abs/2505.19949

不复杂的归因，但问题在于无论是数据集还是 bench 还是模型都太老了，它的结论「简单 code 能更好配合难 math」这个事情也信度不高了。

CodeI/O: Condensing Reasoning Patterns via Code Input-Output Prediction https://arxiv.org/abs/2502.07316

太早了，DeepSeek 做的，但是已经没什么参考价值了。

Understanding by Reconstruction: Reversing the Software Development Process for LLM Pretraining https://arxiv.org/abs/2603.11103

Seed 的合成数据方法，但实验不 solid，没什么参考价值。

Procedural Pretraining: Warming Up Language Models with Abstract Data https://arxiv.org/abs/2601.21725

很有意思的 research，但是应该和主线没什么关系，但是确实很有趣，不知道真假。