预训练数据不再一刀切：DataOrchestra 让每条数据都有自己的清洗流程

做预训练的人都有一个心照不宣的共识：模型性能的墙，多半不是卡在算力上，而是卡在数据上。爬回来的网页文本有多脏就不说了，一个现实的问题是——用一种规则洗所有的数据，一定有一部分被洗坏了，另一部分该洗的却没洗到。Corpus-level 的清洗策略，是在赌大部分数据能被同一种方式处理好。

上海交大彭湃团队（Zhen Huang、Yikun Wang、Shijie Xia、Pengfei Liu）7 月 27 日上传了一篇新论文，提出的框架叫 DataOrchestra，思路很直接：每条数据（即每个 chunk）进来，先由 orchestrator 判断——扔掉、不动，还是需要处理。如果需要处理，再拆成具体步骤，一步是一道指令，交给对应的工具模型去执行。

这套逻辑把数据清洗从「批处理」改成了「逐例编排」。Orchestrator 先做一次三选一（drop / untouch / clean），对标记为 clean 的 chunk，再选下游操作——可以是一些程序化的编辑规则，也可以走 LLM 改写。走 LLM 改写时，orchestrator 还会生成一条具体的 instruction，相当于告诉改写模型「这段文本哪里有问题、按什么方向改」。整个过程是一个轻量的决策树，而不是一个固定的流水线。

论文的实验从 0.5B 一路做到 7B，模型都是从零开始预训练，用的 web 数据经过 DataOrchestra 处理后，在 11 个 benchmark 上稳定优于单一处理方法的基线。而且不是只有通用预训练有效——他们在数学 continued pretraining 上也做了验证，结果比更强的处理基线还要好。

DataOrchestra 可以在处理过程中跳过不必要的下游操作，不止提升数据质量，还节省算力。很多 chunk 本来就是干净的，或只需轻量处理，不需要每次都过一遍 LLM rewrite。这部分省下来的 compute，对大规模预训练来说是一笔可观的节省。

当然，这套框架的落地代价也很清楚：orchestrator 本身需要训练，下游 LLM rewrite 步骤仍有推理成本。而且 orchestrator 的决策质量直接决定了整个管线的上限——它要是误判了一个 chunk 该不该处理，后面再好的 rewrite 也救不回来。

但大方向是对的。预训练数据的天花板问题已经越来越清晰：量的积累到了一定程度，瓶颈落在质量不够均匀上。DataOrchestra 让清洗变得有选择性、有针对性——不再靠一条规则包打天下。每条数据走自己的流程，这个直觉在工程上迟早会被更多人接受。

论文 36 页，arXiv 地址在 2607.24717，代码和数据目前还没公开，但思路本身值得跑工程的人跟进一下。