TL;DR
可执行的结论是三条账分开算。对 web 爬取池,强 exact/near-exact dedup 通常是默认项:长重复 substring、镜像页与近重复文档会同时浪费 compute、抬高逐字记忆化、并增加 train-test 泄漏;文档级 hash 不够,至少要 substring 匹配 + MinHash,并把“长重复 substring 占比”当一等指标 [1]。但只在单个语料里 dedup 不足以控制曝光:同一文档会跨 C4/RedPajama/Dolma 等池复用,需要跨语料指纹账本统计全局曝光次数 [6]。
对漂白后的有限高质量池,均匀多 epoch 在约 2–4 轮内接近“等效新鲜 token”,超过后边际收益快速变差 [2];更该盯的是曝光分布,热子集过曝会额外退化,并在 induction head 留下机制指纹 [3]。对 benchmark/PII/版权文本,稳的规则不是“少重复”,而是默认 0–1 次曝光,并用 provenance、prefix/suffix dedup 与独立评测管线控制污染;可恢复记忆化风险随重复、模型规模与更长 context 上升 [4][5]。合成数据自回流训练是另一类问题,不能照搬“4 epochs”经验 [10]。
核心断言
§1 三条账:token 利用率、曝光分布、风险曝光
把“重复”压成一个数,会混淆三类决策:web 冗余、有限池多 epoch、敏感数据污染的目标函数并不相同。web 冗余首先损害 token 利用率:镜像页、模板页、转载链把同一信息以近重复形式塞进 batch。Lee et al. [1] 进一步指出,主要坏账常不体现在文档级重复率,而藏在长重复 substring(例如页脚、导航、版权声明、列表模板)中;这些片段在训练中被高频看到,浪费 compute,也更容易被逐字复述。
有限高质量池的问题不是“是否有重复”,而是“重复是否均匀”。Muennighoff et al. [2] 给出工程可用窗口:前约 2–4 轮均匀重复的收益接近新鲜 token;之后边际收益快速变差。Hernandez et al. [3] 将风险点从平均 epoch 转到曝光分布:少量热子集被高倍重复会造成额外退化,并在 induction head 中留下可解释指纹,说明必须监控 per-document exposure 的尾部。
敏感/评测/版权文本是第三条账:目标不是更低 loss,而是更低可恢复泄漏和更低评测污染。Carlini et al. [4] 将可恢复记忆化与重复曝光、模型规模、以及更长 context 关联起来;Deng et al. [5] 显示污染会抬高分数,且难靠粗过滤消除,因此更稳的控制变量是“曝光次数上限 + provenance 证据 + 独立评测管线”。
同样是“重复”,web 池关心 token 利用率,有限池关心曝光分布,敏感池关心可恢复泄漏与评测污染;把 KPI 混在一起会得到不可执行的结论。
§2 web 池:强 near-dedup 是默认项,但要把“片段级重复”单列
web 池的重复治理,常见误区是“做完文档 hash 就结束”。Lee et al. [1] 的经验是:near-duplicate 与长重复 substring 会同时存在;后者即使在“文档都不相同”时,也能制造高曝光片段。工程上的最低稳态配置是三件套:文档级 exact hash(挡住完全重复)、substring 匹配(挡住长 boilerplate)、MinHash/LSH(挡住 near-duplicate)。这套组合的价值不只是提高 token 利用率,还在于降低 train-test 泄漏与逐字复述风险 [1]。
另一个误区是把“去重”理解成纯删除。D4 更像预算重分配:Tirumala et al. [8] 用 embedding 聚类把近重复聚成簇,再在簇内做多样化采样,目标是在同 compute 下保留覆盖面。它和 Lee et al. [1] 不冲突:前者处理“信息同质”的冗余,后者处理“字面重复/片段重复”的坏账。合起来更像两阶段管线:先用 substring/MinHash 把明显重复压低,再用聚类/多样化把 token 投向更广的主题覆盖。
还需要单列一条账:跨语料重复会让“单池去重率”失真。Elazar et al. [6] 指出公开池之间存在 overlap;如果训练配方混入多个池(例如 C4 + RedPajama 变体),单池 dedup 无法给出总曝光次数。因此 web 池的 KPI 不应只报“本池去重后剩余 token”,还要报“全局指纹下的曝光分布”。
| 目标/账本 | 主要坏账形态 | 最低配工具 | 更强工具 | 主要证据锚点 |
|---|---|---|---|---|
| web 冗余 | 镜像/转载、模板页、长重复 substring、near-duplicate | doc hash + substring 匹配 + MinHash/LSH | embedding 聚类 + 簇内多样化采样 | |
| 有限池 epochs | 均匀重复的边际收益衰减;热子集过曝 | 统计 per-document exposure 分布(p50/p95/p99)并设上限 | 按簇/主题做 reweighting,避免尾部过曝 | |
| 敏感/评测/版权 | 可恢复逐字泄漏;benchmark contamination | 默认 0–1 次曝光 + provenance 记录 + 独立评测管线 | prefix/suffix dedup、来源隔离、可审计过滤证据 |
§3 有限池:2–4 epochs 是默认窗口,但要把“曝光尾部”当红线
“多 epoch”是有限高质量池中的合理工具,但不是无条件经验法则。Muennighoff et al. [2] 的关键做法,是把收益折算为可比较的“等效新鲜 token”:均匀重复的前约 2–4 轮仍接近消耗新数据;再往后,同样的 compute 带来的 loss 改善明显放缓。这给出了默认上限窗口,但前提是曝光分布近似均匀。
Hernandez et al. [3] 给出更接近工程事故的反例:当少量样本被高倍重复(例如热子集、热门域名、某类模板化文本),即使平均 epoch 不高,也会出现额外退化;induction head 还会学到可解释的“重复结构”,说明模型在机制层面把重复当成捷径。合并两条结果,更稳的控制变量不是只报 epochs,而是同时报告 per-document exposure 的分位数和尾部上限(例如 p99 不超过 p50 的 5–10×,或对单文档设置硬上限)。
这也解释了为什么“先去重再多 epoch”通常比“先多 epoch 再补去重”更可控:去重先把曝光尾部压平,epochs 才更接近 Muennighoff et al. [2] 的均匀假设;反过来先跑 epochs 会放大热子集过曝,后续删数据也无法撤回已经发生的高曝光。
2–4 epochs 更像“默认窗口”,不是“安全证明”;安全边界在曝光尾部,而不是平均值。
§4 跨语料指纹 + 风险池隔离:把“零重复”落到可审计的曝光上限
“我在主语料里过滤过 benchmark/PII/版权文本”在工程上常不可证伪:同一文本可能经不同路径进入多个数据池。Elazar et al. [6] 的 overlap 审计显示,公开池之间复用普遍;当训练配方混合多个来源(例如 C4 + RedPajama + 自爬取)时,单池过滤无法界定“总曝光次数”。因此需要跨语料指纹账本:至少在文档级维护 hash/MinHash,并把每条样本的 provenance(来源、抓取时间、许可、过滤版本)写入可追溯记录 [6]。
对风险池,更稳健的目标是“可审计的曝光上限”,不是口头承诺“绝对零”。Carlini et al. [4] 表明可恢复记忆化随重复曝光、模型规模与更长 context 上升;Deng et al. [5] 表明污染会抬高评测分数,且难靠粗过滤消除。合成工程规则就是:风险数据默认不进主训练池;若必须用于对齐/指令微调,也应使用单独管线、单独 checkpoint lineage,把曝光次数限制为 0–1(或极低上限),并做 prefix/suffix dedup,防止“题面轻微改写”绕过过滤 [5]。
合成数据自回流训练需要单独对待。Shumailov et al. [10] 指出的退化机制是分布塌缩与多样性损失;它更像“语义空间变窄”,而不是“同一文本重复”。因此在合成数据闭环中,关键 ledger 不是 epochs,而是新鲜度与分布漂移(例如人类数据占比、生成器版本多样性、去重阈值随代数变化)。
§5 数据稀缺 ladder:『unique data 不可替代』是错觉吗?
把『重复』视为纯坏处,是 dedup 视角下的直觉;它只在 data-rich 区成立。当 unique-token 预算被 compute 卡住时,问题反过来变成:同 compute 下,repeat + 更好配方,是否比 1-pass + 更少处理得到更低 loss、更稳的其它指标?Muennighoff et al. [2] 正是在这个问题上形式化了 'data-constrained scaling laws':在 1.4B–6.7B 区间,他们用 (compute, unique tokens, epoch) 三元组画出 loss 等效曲线,显示重复在约 2–4 个 epoch 内仍近似新数据;超过这个窗口后边际衰减才明显出现,但仍是温和衰减而非崩溃。因此,默认假设『必须 scaling unique tokens』在 data-constrained 区并不成立——前提是配方 leverage 跟得上。
三类『替代 unique tokens 的训练侧方法』在 2024 年都被独立验证,且收益不互相替代:(1) 更严的 filter——DCLM [17] 在 412M 上的 ladder 显示,对同一个 web pool 做一次 fasttext-quality + per-domain 截断粗滤,等效于把 unique-token budget 扩大约 1.3–1.7×;(2) rephrase / paraphrase——Maini et al. [16] 用一个较小的指令模型,把每条 web 文档重写成『Wikipedia 风格』『QA 风格』『paraphrase 风格』三种变体;固定 compute 下,rephrase 的等效新鲜 token ≈ 1.5×(精确数字依任务而异,但方向稳定);(3) grounded synthetic——基于已有 base 模型生成结构化数据(数学题、代码、问答)。grounded 版本(带可验证 reward 或可执行检查)的等效率接近 1×,未 grounded 的 synthetic 衰减更快。三者不是择一关系:在 8-epoch 区,filter 主要砍曝光尾部噪声,rephrase 主要用新表述复用同一语义,synth 主要补稀缺分布——它们在 ladder 上可叠加;但缺任一项时,重复 ≥4 epoch 又会退回原始衰减斜率。
工程结论是:『需不需要 scaling unique data』不是全局问题,而是 ladder 上的 if 分支(图 §5 决策流)。Compute / unique-tokens ratio ≤ 4:直接 repeat;4–16:必须叠 filter + rephrase + (optional grounded synth);≥ 16:ladder 已进入 memorization-bound 区,配方加成救不动,唯一可靠 fix 是补 unique tokens。这个 if 分支可以用极小 ladder(例如 412M ↔ 1.4B)廉价验证:DCLM 在 412M 上的 mixture 决策,在多数子集上能以 Spearman ≈ 0.7+ 的 rank correlation 转移到 7B [17]。因此,ladder 成本和一条 6.7B full-loss 曲线一样可控,没有理由只看单次大模型运行就拍板。
在 data-constrained 区,『换配方』的 loss 差和『换 unique-token 量』的 loss 差几乎同量级——这才是『不必 scaling unique tokens 也能继续涨』的真正含义。
§6 loss 不该是唯一指标:repetition ladder 必须用 multi-metric 验收
Muennighoff 2023 [2] 的 ladder 写在 (loss, epochs) 平面上,因此『2–4 epoch 等效新鲜』的结论只针对 loss。这也是工程读者最容易误读的地方:loss 单调下降不表示模型在所有维度上都变好,只表示 next-token CE 变好。把指标切到下游能力、记忆化、生成多样性,曲线会立即分化(图 §6 metric divergence):loss 单调下降,memorization-recall 单调上升(Carlini et al. [4] 早期就指出可恢复记忆化随重复次数与模型规模上升),generation diversity(type-token ratio / n-gram entropy)单调下降,downstream zero-shot 在低 epoch 区间小幅上升、到 8 epoch 后转向退化(Hernandez et al. [3] 报告的『重复降低 induction head 质量』正是这个现象的内部投影)。
工程默认值因此很直接:repetition ladder 的验收必须并列 ≥3 个独立指标,至少包含 loss + downstream + (memorization 或 diversity 之一)。理由不是『loss 不准』——它仍是 next-token 上最敏感的量纲——而是不同指标对应不同 root cause,呈现 Hernandez 2022 现象式的分化:loss 看到平均字段,diversity 看到分布尾部,memorization 看到分布峰部。把三者压成一个数,会抹掉它们之间的因果信号。Muennighoff 2023 的『2–4 epoch』窗口放到 multi-metric 视角下,其实收窄到 ≈2 epoch:diversity 与 memorization 在第 3 个 epoch 之前就开始转向。因此工程上常见的『随手 4 epoch,因为 paper 说 OK』并不严格成立。
成本上没有借口。DCLM [17] 已经证明,412M ladder 上的 mixture 决策能以 Spearman ≈ 0.7+ 转移到 7B;把 loss + 4 个评测子集 + 一组 memorization probe + 一个 generation diversity 指标跑完,wallclock 与单条 6.7B loss 曲线同量级。把 multi-metric 写进 ladder 验收流程,至少能把 dedup / repetition / synthetic 这类决策从『感觉对』推进到『可证伪』——而 §1–§4 里的所有具体配方建议都依赖这一步。
Muennighoff 2023 的『2–4 epoch 等效新鲜』结论在 multi-metric 视角下其实是『2-epoch 等效新鲜 + 后续 epoch 用 diversity 与 memorization 偿还』。把单条 loss 当成 ladder 验收,等于给 repetition 决策开了个不可证伪的后门。
时间线
- Kaplan et al. 给出 compute–data–model scaling 基线,明确 data-limited 区间[9]
- Lee et al. 把 near-duplicate 与长重复 substring 变成去重 KPI,并量化收益[1]
- Hernandez et al. 指出热子集过曝会退化,并在 induction head 留下机制指纹[3]
- Carlini et al. 系统量化可恢复记忆化风险与重复/规模/context 的关系[4]
- Muennighoff et al. 给出数据受限下 2–4 epochs 的等效新鲜 token 窗口[2]
- Elazar et al. 把跨语料 overlap 变成可审计对象,推动“指纹账本”需求[6]
- Deng et al. 证明现代 benchmark contamination 持续存在,粗过滤不足[5]
研究立场对比
阵营 A:激进去重优先(从 exact 到 near,再到语义)
立场 — 重复主要是无效 token 与风险放大器;对 web 池宁可删多也不留,把重复率压到最低,再谈 epochs 与配方。语义近重复与主题簇内冗余同样吞预算,应尽早用 embedding 去重/多样化把 token 换成覆盖率。
反方 — 反驳 c-841441e807 / c-bce7a179d3:在数据受限的高质量池里,“删到极致”并不总可行;Muennighoff et al. [2] 显示均匀重复前 2–4 轮仍接近新鲜 token 的收益。另一个边界是误删:语义去重可能把“同主题但互补”的样本当冗余,目前公开负面结果偏少,缺少同预算对照来界定阈值 [7]。
判词 — 更务实的定位:web 爬取池默认走激进 exact/near-exact 去重,并把长重复 substring 单列 KPI [1];语义去重/多样化作为第二阶段,用于把剩余预算从同质簇搬到覆盖面 [8]。但在漂白高质量池里,不把“激进去重”当成唯一杠杆,先用曝光分布约束把过曝尾部压平,再决定是否做语义去重。
阵营 B:epochs 优先(数据受限时先把训练跑满)
立场 — 当独特高质量 token 不够时,均匀多 epoch 是最直接的 compute 利用方式;前几轮收益接近新增同量新鲜 token,默认把 epochs 拉到约 2–4,再考虑扩数据或更复杂的数据工程。
反方 — 反驳 c-766e70d1a1 / c-2c9c18bcfc:平均 epochs 不能替代曝光分布控制。Hernandez et al. [3] 显示热子集过曝会额外退化并留下 induction head 指纹;对敏感/评测/版权文本,重复曝光会把可恢复记忆化与污染风险推高,不能用“平均 4 epochs”论证安全 [4][5]。
判词 — 结论层面的建议:把 2–4 epochs 当默认窗口,但把 per-document exposure 尾部当硬约束;先做能压平尾部的去重/采样,再谈把 epochs 拉满 [2][3]。
阵营 C:语义去重才是主战场(exact/MinHash 只解决一半)
立场 — web-scale 的大头冗余来自改写、转载换皮、同主题簇内的语义近重复;仅靠 exact/MinHash 会留下大量“信息重复但字面不同”的 token。应把 embedding 相似度、聚类与簇内多样化作为核心数据效率杠杆。
反方 — 修正 c-8720d900a9 / c-2a25c7719f:语义去重解决不了两类关键账:长重复 substring(片段级坏账)与跨语料曝光(同一文档在多个池复用)。前者需要 substring/MinHash 管线 [1],后者需要跨语料指纹账本与 provenance [6]。此外,语义去重的阈值选择缺少统一的“误删代价”评估,尤其在长尾能力(小语种、专业领域)上更难靠公开基准验证。
判词 — 一个更稳的读法:语义去重是“第二层预算优化”,不是替代 exact/near-exact 的基础卫生。先把片段级重复与 near-duplicate 压下去 [1],再用语义聚类/多样化把剩余预算投向覆盖面 [8],同时用跨语料指纹把总曝光算清 [6]。
阵营 D:风险数据零曝光(或 0–1 次曝光)优先于任何数据效率讨论
立场 — benchmark、PII、版权内容不应进入主训练池;默认 0–1 次曝光,并把治理做成可审计配置(provenance、opt-out、过滤证据)。理由是污染会扭曲评测,记忆化会带来可恢复泄漏风险,且风险随规模与更长 context 上升。
反方 — 修正 c-b0ed1be495 / c-45889dd38a:工程现实是“绝对零”往往不可证伪:风险文本可能以多版本、多池复用形式进入训练配方。Elazar et al. [6] 的 overlap 现象意味着需要把目标从“绝对零”落到“可审计的曝光上限 + 可复现的过滤证据 + 跨语料指纹账本”。
判词 — 结论层面的建议:对风险数据坚持“默认 0–1 次曝光”,但把交付物从口号换成可审计工件:跨语料指纹账本、provenance 记录、prefix/suffix dedup 规则与独立评测管线 [5][6]。
实践要点
可执行的清单(带边界):
1) Do:先把“重复”拆成三条账并分别设 KPI:web 池报冗余率、长重复 substring 占比;有限池报 epochs + per-document exposure 分位数(p50/p95/p99);风险池报曝光次数上限与 provenance 完整度 [1][2][5]。Don’t:只报一个“去重率”或“平均 epochs”。
2) Do:web 池默认强 exact/near-exact dedup,最低配=doc hash + substring 匹配 + MinHash/LSH [1]。Don’t:只做文档级 exact hash 就宣称去重完成。
3) Do:把“长重复 substring”单列成一等指标,并对 boilerplate 做专门规则(例如页脚/导航/模板块)[1]。Don’t:只看文档级重复率。
4) Do:在漂白高质量池里,把 2–4 epochs 当默认窗口;超过 4 轮前先回答“是否还能压平曝光尾部/扩独特 token” [2]。Don’t:把“跑满 compute”当唯一目标。
5) Do:对有限池设曝光尾部红线:监控 per-document exposure 的尾部,并避免热子集被高倍重复;一旦出现尾部拉长,优先做采样/重加权/去重而不是继续加 epochs [3]。Don’t:用平均 epoch 为热子集过曝背书。
6) Do:做跨语料指纹账本:至少 hash/MinHash 统一到全局 key,并统计同一文档跨池总曝光次数;混合多个公开池时把 overlap 当成默认存在 [6]。Don’t:每个语料各自 dedup,最后直接混。
7) Do:风险数据默认 0–1 次曝光,并走独立管线;配套 prefix/suffix dedup 与隔离评测,避免污染抬分 [5],同时把可恢复记忆化当成规模与长 context 的函数来评估 [4]。Don’t:用“混入比例很小”当安全论证。
8) Open(证据不足):语义去重阈值的误删代价缺少统一评估;更稳的做法是把语义去重放在第二阶段,并对长尾域/小语种保留白名单或更宽阈值 [7][8]。
悬而未决的问题
- Q1.语义去重的阈值如何和“误删代价”对齐:在长尾能力(小语种、专业领域、格式化代码/数学)上,embedding 相似度删掉的到底是冗余还是互补?需要同一语料、同一 compute 的 controlled experiment,并公开误删审计样例 [7][8]。
- Q2.跨语料指纹账本的最小可复现标准:hash/MinHash/embedding 三类指纹在不同 tokenizer、不同规范化(HTML 清洗、Unicode 归一)下的一致性如何定义?需要公开的“指纹一致性基准”与版本化 provenance 规范 [6]。
- Q3.曝光尾部红线的可迁移性:Hernandez et al. [3] 的热子集过曝退化在不同模型规模、不同 context 长度下是否有统一的“尾部阈值”(例如 p99/p50 比例)?需要跨规模的系统扫描。
- Q4.风险数据的“可审计 0–1 曝光”如何落地:当风险文本无法被完美识别、且跨池复用普遍存在时,什么样的过滤证据与独立评测管线足以让外部复现“确实没见过”?需要公开工件而不只是声明 [5][6]。
- Q5.合成数据闭环的 ledger 应该是什么:Shumailov et al. [10] 指向分布塌缩,但工程上需要可监控指标(生成器版本多样性、人类数据占比、语义覆盖率)与去重策略的交互曲线。
- [1]Katherine Lee, Daphne Ippolito, Andrew Nystrom, Chiyuan Zhang, Douglas Eck, Chris Callison-Burch. Deduplicating Training Data Makes Language Models Better. arXiv, 2021论文
- [2]Niklas Muennighoff, Alexander M. Rush, Boaz Barak, Teven Le Scao, Aleksandra Piktus, Nouamane Tazi. Scaling Data-Constrained Language Models. arXiv, 2023论文
- [3]Danny Hernandez, Tom Brown, Tom Conerly, et al.. Scaling Laws and Interpretability of Learning from Repeated Data. arXiv, 2022论文
- [4]Nicholas Carlini, Daphne Ippolito, Matthew Jagielski, Katherine Lee, Florian Tramèr, Chiyuan Zhang. Quantifying Memorization Across Neural Language Models. ICLR, 2023论文
- [5]Chunyuan Deng, Yilun Zhao, Xiangru Tang, Mark Gerstein, Arman Cohan. Investigating Data Contamination in Modern Benchmarks for Large Language Models. arXiv, 2023论文
- [6]Yanai Elazar, Akshita Bhagia, Ian Magnusson, Abhilasha Ravichander, Dustin Schwenk, Alane Suhr. What's In My Big Data?. arXiv, 2023论文
- [7]Amro Abbas, Kushal Tirumala, Dániel Simig, Surya Ganguli, Ari S. Morcos. SemDeDup: Data-efficient learning at web-scale through semantic deduplication. arXiv, 2023论文
- [8]Kushal Tirumala, Daniel Simig, Armen Aghajanyan, Ari S. Morcos. D4: Improving LLM Pretraining via Document De-duplication and Diversification. arXiv, 2023论文
- [9]Jared Kaplan, Sam McCandlish, Tom Henighan, et al.. Scaling Laws for Neural Language Models. arXiv, 2020论文
- [10]Ilia Shumailov, Zakhar Shumaylov, Yiren Zhao, et al.. The Curse of Recursion: Training on Generated Data Makes Models Forget. arXiv, 2023论文
- [11]Together Computer. RedPajama: An Open Dataset for Training Large Language Models. Together Blog, 2023博客
- [12]Allen Institute for AI (AI2). Dolma: An Open Corpus of Three Trillion Tokens for Language Model Pretraining. Project page, 2024报告
- [13]AllenAI. c4: Colossal Clean Crawled Corpus (dataset documentation and code). GitHub repository, 2020报告
- [14]
- [15]Reiichiro Nakano, Jacob Hilton, Suchir Balaji, et al.. WebGPT: Browser-assisted question-answering with human feedback. arXiv, 2021论文
- [16]Pratyush Maini, Skyler Seto, He Bai, David Grangier, Yizhe Zhang, Navdeep Jaitly. Rephrasing the Web: A Recipe for Compute and Data-Efficient Language Modeling. arXiv, 2024论文
- [17]Jeffrey Li, Alex Fang, Georgios Smyrnis, Maor Ivgi, Matt Jordan, et al.. DataComp-LM: In Search of the Next Generation of Training Sets for Language Models. arXiv, 2024论文