一个做产品/市场/策略的人，给非研究者的技术翻译本

边界层 · 算法&论文｜推理模型走进“数据时代”：一篇 NeurIPS 论文带来的启发

---

过去这一年，大家都在讨论 DeepSeek-R1、o1 这一类“会认真想一想”的推理模型：参数不一定最大，但在 AIME、LiveCodeBench 这类基准上，数学和代码成绩一路往上刷。

AIME 是 American Invitational Mathematics Examination，美国高水平高中数学竞赛，现在经常被做成 AIME24、AIME25 这样的推理 benchmark，用来测试模型的多步推理能力。对于从业者来说，它代表的是一种“真正要动脑子”的题型，而不是只靠记忆就能应付的测试。

前几天，我和一位还在上海交大读人工智能博士的学妹聊起今年 NeurIPS 。她自己也中了一篇，但因为签证被卡，最后没能去现场。聊天时，她把实验室的一篇工作发给我看——《Which Data Attributes Stimulate Math and Code Reasoning? An Investigation via Influence Functions》，他们提出的框架叫 Infra（Influence-based Reasoning Attribution）所以下文中就简称Infra 论文。

征得她同意之后，我决定从一个不写代码、但长期看产品和产业路线的视角，把这篇论文解读一遍，也顺便把这一条“训练数据归因 / 数据配方”的方法路线梳理清楚。

换句话说：

当推理模型开始“走进数据时代”，我们不再只看参数和显卡，而是要认真问一句——到底是哪些数据，在教会模型“会想”和“会写”？

---

一、从产业一线的困惑出发：推理能力，真的只是“多算力 + 多数据”吗？

如果你在公司负责大模型相关的产品或项目，这一年大概听过类似的话：

有的版本里，模型在 demo 和榜单上表现惊艳，AIME24、AIME25、LiveCodeBench 这些数字很好看，但一旦换成业务里的真实问题——哪怕只是换一种问法、换一套场景——效果就开始“漏气”。有的团队于是开始“多喂数据”：FAQ 再爬一圈、SQL 再加一批、业务文档全部塞进去，但训完指标并没有线性拉升，甚至偶尔还掉一点，于是开始怀疑：是模型不行、数据不行，还是我们根本不知道自己在喂什么。

尤其在“会推理”的场景里，大家心里的目标其实是：希望模型像一个靠谱的分析师，先把条件梳理清楚，再给结论，而不是直接“爆答案”。但现实经常是：

有时候模型变得非常啰嗦，却没什么新增信息，只是语言上的堆砌；有时候则学会了“表演推理”，写一长串看起来像思考的东西，但本质是在绕着既有答案转圈。

这些现象的共同点是：我们往往只在看“结果”——模型是不是做对题、指标是不是提高——却缺乏一套工具，去回答一个更基础的问题：

到底是哪些训练数据、哪些推理过程，真的把这点能力“教”给模型的？

这正是“训练数据归因（Training Data Attribution）”想要解决的事情，也是 Infra 这篇论文所在的研究方向。

---

二、“训练数据归因”到底在干什么？——从家教课的类比说起

“训练数据归因”听起来很学术，其实可以先忘掉数学，从生活里的一个场景开始：

想象你给孩子请了一位家教老师，上一整个学期的课，做了很多套卷子，期末孩子在数学和程序设计考试里都考得不错。作为家长，你自然会问三件事：

• 到底是哪几套卷子最有用，是那几套高难度综合题，还是贯穿一学期的基础练习题？

• 是哪几次讲题方式最关键，是一步步拆解、画图推理，还是直接给公式、让他记住套路？

• 哪种表达方式对孩子最友好，是“首先……其次……因此……”这种很清晰的逻辑结构，还是密密麻麻写公式？

训练数据归因做的，就是在模型世界里回答同一类问题。在模型已经训练好的前提下，往回看：

• 如果把某一类训练样本“拨掉”，模型在某个基准（比如 AIME24、LiveCodeBench）上的表现会掉多少？

• 如果把某一种推理行为删掉（比如探索尝试、验算步骤），结果会有什么变化？

• 如果换一种语言结构（多一些逻辑连接词，或者多一些代码结构标记），推理质量会不会不一样？

为了解答这些问题，这两年出现了几条代表性的路线。

一条是 Anthropic 把“影响函数（Influence Functions）”扩展到大模型。影响函数本来是统计学里的经典工具，大意是：如果把某个训练样本的权重调高一点点，看模型参数和输出会怎么变化。Anthropic 把这套方法扩展到了 50B 级别的 LLM，用它来分析不同能力（数学、编程、角色扮演）的“能力来源”。

另一条是 Daunce 用“不确定性”做归因。它的想法更工程一点：不再算复杂的二阶矩阵，而是围绕目标模型训练一批带轻微扰动的版本，看每个训练样本的 loss 在这些模型之间波动有多大，把这种“协方差”当作贡献度。波动大，说明这个样本对模型行为更关键。这套方法在 vision 和 LLM 上都做了实验，还用在 GPT 这类闭源模型上，对产业来说门槛更低。

第三条，是 DATE-LM 把各种归因方法拉到一个统一的评测场里。DATE-LM 本身是一个 benchmark，用来评估不同数据归因方法到底好不好用，任务包括训练数据选取、有害/偏见过滤、事实归因三类，用的都是 LLM 的真实场景。结论之一是：没有“一招鲜”的通吃方法，很多场景里，复杂归因方法和简单基线之间是 trade-off。

（这里顺便解释一下：DATE-LM 可以理解为“专门评估数据归因方法的一套标准试卷”，而不是新的归因算法。）

所以，你可以先把“训练数据归因”看成一种工程工具，而不是魔法：

它不会直接帮你训练一个更强的模型，

但会帮你回答：

这次模型考高分，大概率是被哪几类题“教”出来的。

Infra 这篇论文，就是把这套工具专门用在“数学 + 代码推理”上，逐层拆给你看。

---

三、推理时代的三个方法“旋钮”：架构、RL 和数据结构

如果抽象一点看，大家现在在“让模型更会推理”这件事上，大概在拧三只旋钮。

第一只是模型架构的旋钮。各种新的注意力结构、更长上下文、适合长链路推理的架构（比如最近经常被提到的一些 linear attention、DeltaNet 一类工作）都是在这里发力——目的都是让模型从算子层面更适合做长推理。

第二只是训练目标和强化学习（RL）的旋钮。RL（Reinforcement Learning）就是我们熟悉的强化学习，用奖励信号引导模型调整行为。例如 NVIDIA 的 AceReason-Nemotron：从一个蒸馏自 DeepSeek-R1 的 14B 模型出发，先做一轮监督微调（SFT，Supervised Fine-Tuning，可以理解为用人类标注好的输入-输出对再训一遍模型），然后完全通过 RL 去优化数学和代码推理，而不再额外堆数据。AceReason-Nemotron-14B 在 AIME24、AIME25、LiveCodeBench 这些基准上，相对起点模型都有两位数的提升，属于“固定参数、靠目标函数和策略把潜力榨出来”的代表。

第三只是本文的主角：数据结构与数据归因的旋钮。这一支上，前面说到的 Anthropic 影响函数、Daunce、DATE-LM，还有今天重点聊的 Infra 这篇论文，都在尝试回答一个问题：

在模型架构和训练框架基本确定的前提下，

换不同的数据结构（题目难度、领域配比、CoT 写法）， 能否系统地看出：哪些组合最“值回算力”？

如果把推理模型的训练看成一个实验室，这三只旋钮基本上就是：

“脑子长成什么样”（架构），

“老师怎么给你打分和反馈”（RL / 训练目标），

以及“你到底做了什么题、怎么做的题”（数据结构）。

Infra 这篇论文，专挑第三只旋钮做文章。

---

四、Infra 想回答的核心问题：哪些数据，真的在教模型“会想”和“会写”？

在当前主流的推理模型 pipeline 里，大多数团队大概是这样做的：先用一个更强的老师模型（比如 R1 一类），给数学题和代码题生成带推理过程的 CoT（Chain-of-Thought）；然后用这些“题目 + 推理过程”去做 SFT 或 RL，最后看 AIME、LiveCodeBench 这些指标是否提升。

但这里有几个一直靠经验拍脑袋的问题：数学和代码数据的比例怎么配？题目难度是多难算合适，是一股脑上高难题，还是难易混合？CoT 要保留多少“多余思考”，那些探索、验算要不要清洗掉？

Infra 做的事情，就是用一套影响函数框架，把这些问题拆开来、量化一下。它在 SFT 阶段选了几组代表场景：例如不带长 CoT 的数学数据，用 Llama3-8B 去学 MetaMathQA 之类的数据集；带长 CoT 的场景，则用 Qwen2.5-7B/14B 去学基于 DeepSeek-R1 蒸馏得到的 BS-17k 数据。

简单说，它做了三层“放大镜”：

• 在样本级别，看不同类型的数学题、代码题，对 AIME、LiveCodeBench 这些测试集的贡献度；

• 在序列级别，把 CoT 按“探索、验证、总结”等行为拆开，观察删掉其中一类句子后的影响；

• 在 token 级别，看哪些词、哪些标记在高影响力样本中反复出现，是否构成了某种“推理骨架”。

这些分析背后的数学技术都不轻，但对我们来说，可以只看它得出的“配方建议”。

---

五、关键发现：高难数学 + 简单代码，配出来的是一套“推理菜单”

对产业一线而言，Infra 最有意思的地方在于它得出的不是抽象理论，而是一套非常具体的“训练菜单”。

第一，高难数学题，是同时喂数学和代码的“逻辑增压器”。

论文的结果表明，在训练数据里加入真正多步推理、难度较高的数学题，不仅能明显提升 AIME 这类数学基准的表现，对代码推理（比如 LiveCodeBench）也有正向影响。

换成人话，就是：这些高难数学题在训练的是抽象逻辑能力，而这套“逻辑肌肉”在写代码时同样会被调用——你需要拆分问题、建立中间量、检查边界条件，不只是写语法。

第二，简单却结构清晰的代码题，是“语法和模式训练器”。

在代码数据这一侧，Infra 的结论有点反直觉：对 LiveCodeBench 这类评测来说，极高难度的代码题，边际贡献不一定最大。相反，那些难度适中、结构非常清楚、模式稳定的代码题，对模型的帮助更大。

用“带新人写代码”的直觉去理解就很自然：要一个新人能稳定写出可读的业务代码，重点不是每天发一题 ICPC 金牌题，而是持续练习“标准结构的程序”：函数怎么拆、错误怎么处理、日志怎么打、边界条件怎么写。这类题，才是在塑造模型对“结构化输出”的直觉。

第三，CoT 里那些看似啰嗦的“探索句子”，其实非常值钱。

Infra 把 CoT 拆成不同类型的行为：尝试不同解法的探索句子、算完结果再复核的验算句子、最后做总结和反思的句子。然后分别把某一类行为“剪掉”，看 AIME、LiveCodeBench 上的分数变化。结论是：如果把这些看起来啰嗦、甚至“已经算完还要想两步”的探索行为删掉，模型在数学、代码推理上的表现会有明显下降。

这对现在很多团队一味追求“短 CoT、高压缩”的做法，是一个清晰的提醒：训练时的“多想几步”“试错再修正”，确实在帮模型形成更稳的推理习惯，而不仅仅是浪费 token。如果把所有中间过程都压缩成一句“因此可得”，短期看起来更优雅，长期可能是在牺牲模型的泛化能力。

第四，在 token 层面，数学爱逻辑词，代码爱结构标记。

在 token 级分析中，论文发现：数学 CoT 中各种逻辑连接词（first, then, therefore, however, alternatively…）在高影响力样本中的权重非常高；而代码 CoT 中，结构性标记（Markdown 的 ``` 代码块、函数签名、括号、缩进等）贡献更大。

这其实把很多人的直觉用数据形式确认了一遍：

对数学推理来说，“话要讲顺、逻辑链清楚”很重要；对代码推理来说，“格式清晰、结构明朗”更重要。

最后，是一组硬指标：不加参数，只改配方，也能把成绩翻一倍。

在 Qwen2.5-7B-Instruct 这类 7B 参数的模型上，作者用一个非常朴素的策略——在数学上加高难题，在代码上多用简单、结构清晰的题，做了一个“难度翻转”的配比调整，结果是：AIME24 正确率从 10% 提升到 20%，LiveCodeBench 从 33.8% 提到 35.3%。

数字本身未必惊人，但它传递的信息很直接：在模型和训练框架都不变的前提下，单纯通过“重配训练数据结构”，就可以把推理能力明显拉一截。

---

六、理性看待局限：有价值的方向，还需要更多实证

作为一条还在快速演化中的方法线，训练数据归因和 Infra 这样的工作，既有清晰的工程价值，也有需要耐心验证的部分。

一方面，从 Anthropic 到 Daunce，再到 DATE-LM 和 Infra，我们已经看到：在大型语言模型上，影响函数类方法和基于不确定性的归因方法，确实能在一定程度上刻画“哪些训练样本更关键”。很多细节，比如高难数学与简单代码的配合、CoT 行为的保留与删减，在这篇论文给出的结果中，有相当清晰的信号。

另一方面，这些方法本身也还在迭代。影响函数依赖二阶近似，对模型规模和训练细节比较敏感；Daunce 这类方法需要多模型扰动，在算力和工程实现上有自己的成本；DATE-LM 也明确指出，不同方法在不同任务上各有长短，没有一劳永逸的“最优解”。未来还需要更多复现和横向比较，把今天这些漂亮的实验结果，稳稳地落在更广泛的模型和场景上。

从我的视角看，这些都不是什么坏消息。恰恰相反，它意味着我们正在形成一套更细腻的“数据工程工具箱”，而不是又多了一句新的口号。对做模型和做产品的人来说，重要的是保持一个温和的态度：既不过度神化一篇论文，也不要忽视它激活的方向。

---

七、落回产业：模型厂和普通企业，各自能做什么？

站在一线的角度，我会把这条线转成几条很具体的思路。

对做基础模型、云上推理产品的厂商来说，“数据配方 + RL”完全可以写进 roadmap，而不是只写“参数量”。规划下一代 R1-like 推理模型时，可以把过程拆成两步：

先用类似 Infra 的方法，在候选数据池里识别高价值题型和难度组合，建立一份“数据红蓝榜”；

再用 AceReason 一类的 RL 配方，在这些关键区域内挖掘最后那几十分。

对外讲产品，也可以从“我们烧了多少 A100 小时”变成“我们如何设计题库和推理过程”，讲清楚为什么要高难数学配简单代码，为什么 CoT 里要保留探索，而不是一味压缩。

对普通企业和应用团队来说，不需要自己上手搞那些复杂的算法实验，只要借用这些研究给出的方向，从几件成本很低的小动作开始就够了。

比如，在训练样本里刻意加入真正需要多步逻辑的“难题”，而不是只有 FAQ；在写 CoT 或示范答案时，允许出现“尝试—修正—确认”的过程，而不是只留最后一句“因此”；在文档和提示词里，有意识地使用逻辑连接词和结构化标记，让模型更容易抓住思路和格式。

更重要的是，在采购模型或者和供应商讨论“我们想要一个会推理的模型”时，可以多问一句：

• 你们在数据结构设计上做了什么？

• 有没有对不同题型、难度、CoT 风格做过系统区分和评估？

• 有没有用类似 DATE-LM 的基准去核查数据归因方法？

这些问题不一定会立即得到详尽答案，但会逼迫对方在“数据配方”上给出更清晰的产品叙事，而不是只报一个模型名字和参数量。

---

边界层笔记：我从这条线里得到的三个启发

对我自己来说，这条线带来的启发大概有三点。

第一，推理能力已经不只是“架构问题”，更是“数据结构问题”。 架构当然重要，但现在越来越清楚的是：题库怎么选、难度如何分布、推理过程怎么写，至少和“模型有多大”一样重要。

第二，“高难 + 低难”的组合，是一种非常值得抄的配方。 不只是在数学和代码上，任何需要推理的领域都可以尝试这样的组合：用少量高难题拉逻辑上限，用大量结构清晰的中低难题打输出稳定性。

第三，数据归因，更像是一种长期运营工具，而不是短期刷榜工具。 它给团队提供了一个新视角：不只是看一次评测分数高不高，而是去理解——哪些数据是这次成功背后的“关键样本”，下一个版本，我们能否更有针对性地放大这些部分。

---

延伸阅读：如果你想顺着这个方向往下看

如果这篇文章勾起了你对“推理数据配方”和“训练数据归因”的兴趣，可以按下面几个方向往下翻：

如果你想先把本文主角看完整，可以直接读 NeurIPS 论文（https://arxiv.org/abs/2505.19949?utm_source=chatgpt.com ）：

Siqi Kou, Qingyuan Tian, Hanwen Xu, Zihao Zeng, Zhijie Deng.

Which Data Attributes Stimulate Math and Code Reasoning? An Investigation via Influence Functions. 上海交通大学团队，对数学 + 代码推理数据做的系统归因分析。

如果你想了解影响函数在大模型上的整体用法，可以看 Anthropic 的工作 Studying Large Language Model Generalization with Influence Functions，这是把影响函数真正推上 50B 级 LLM 的早期代表。

如果你更关心“不确定性视角”的归因方法，可以看 Daunce: Data Attribution through Uncertainty Estimation，用一组扰动模型 + loss 协方差来刻画训练样本的重要性。

如果你想知道各种归因方法到底表现如何，可以看 DATE-LM: Benchmarking Data Attribution Evaluation for Large Language Models，Cathy Jiao 等人给出的统一评测场，在多种任务上比较了现有方法。

如果你对“数据配方 + RL”这一整套推理路线感兴趣，可以结合 NVIDIA 的 AceReason-Nemotron: Advancing Math and Code Reasoning through Reinforcement Learning 及其后续版本资料，一起看 RL 如何在既有模型基础上，把数学和代码推理进一步打磨出来。

---

✍️ 科里笔记 Coralyx Notes 

Written by 科里（Coralyx），发表于「边界层」

如果你在一线做模型、做平台、做应用，已经在实践自己的“推理数据配方”，也欢迎在评论区分享一些经验——以后在这里可以继续把这些零散的实践，总结成更系统的框架。

如果想联系论文作者讨论，也可以后台给我留言。