数据管线博弈
《AI 数据全书》· 第 5 章 · 文本抽取与清洗用 FLUX 论文的真实 per-stage 读数装配一条数据管线 — 级联口径对照、真·帕累托前沿、单阈值暴政与双 bin OR 机制沙盒
数据管线博弈
用 arXiv:2603.13972 的真实 per-stage 读数装配一条管线 —— 级联口径、帕累托前沿、阈值机制，全部浏览器内真算
📊 数据管线博弈
初始 424.9B tokens · 预算 60 CPU-hrs · 目标：靠近 Table 22 的帕累托前沿
🎮 预设（对应 Table 22 消融档）
⚠️ 消融档 → 模块集合的映射是教学映射（Table 21 组件矩阵未逐条回源）； 右侧散点上的 token/aggregate 才是论文 Table 22 的实测读数。
🔧 管线阶段（Table 20）
12/12 启用⚙️ Parser 与分类器选型
反直觉：Apex 成本最低（4.31h）且 token 最多；Trafilatura 质量最高（0.433）却只剩 35.5B 英语 token （Apex 54B），成本 11×。
双 bin 是单 bin 的 2× 分类算力（60min vs 30min）；BERT(110M) 是 43×。 机制与代价见 Tab ②。
📐 级联口径对照：读数随口径变化有多大
实测 8.84% 与加和口径（9.61%）只差 0.77pp， 而连乘口径给出 17.30%——高估保留率约 2.0×。 这说明 FLUX 各阶段抓的是不同类型的问题文档（互补），不是互相重复； 「过滤器高度冗余」这个直觉在这条管线上是错的。
📈 帕累托前沿（Table 22，真·非支配排序）
🧮O(n²) 两两支配判定结论方向比旧版更强，也更反直觉：前沿上只有 URL+LID（42.39B, 41.76） 与 FLUX-Base（27.22B, 45.45） 两个点， 两个公开 SOTA 基线 FineWeb（24.50B, 44.31）与 DCLM（24.81B, 44.40）都不在帕累托前沿上—— 它们 token 更少、分也更低，被 FLUX-Base 完全支配。旧版画出的「四点递增折线」是假前沿。
⚠️ Table 20 的分母是 424.9B（pre-dedup），Table 22 的 token 数是 post-dedup 且出自 530M scale 实验。两者基数不同，不要把 8.84% 直接乘到 42.39B 上。
🌊 逐阶段存活瀑布
💰 成本明细（CPU-hrs · 预算 60）
48.5 / 60⚠️ 标注项（基础 I/O 与 12 个阶段）是教学分摊；分摊已锚定 「全开 + Apex + 双 bin ≈ 48.5 CPU-hrs = Table 0 的 FLUX 实测值」。 Parser 与分类器的读数是论文 Table 2 / Table 1 的真实值。
🏁 真实 benchmark 读数（Table 7）
| 数据集 | MMLU | Aggregate（9 项） | Δ MMLU vs FineWeb |
|---|---|---|---|
| FineWeb | 0.298 | 0.4883 | — |
| DCLM | 0.319 | 0.5048 | +2.1pp |
| FLUX | 0.321 | 0.5192 | +2.3pp |
small-scale proxy（论文 Table 7 的 530M/3B 档读数），不是 70B 模型的 MMLU。旧版用「人造 0-100 质量分 → 线性映射到 MMLU」的假指标，已删除； 这里只列已回源的 MMLU 与 aggregate 两项（论文共 9 项 benchmark，其余 7 项未回源故不列）。
⚡ 管线级效率（Table 0）
| 管线 | 输入 | 墙钟 | CPU-hrs | CPU-hrs/TB | vs FLUX |
|---|---|---|---|---|---|
| DCLM | 1.2 TB | 11h07m | 355.7 | 296.4 | 6.26× |
| FineWeb | 0.6 TB | 5h39m | 181 | 301.3 | 6.36× |
| FLUX | 1.03 TB | 1h31m | 48.5 | 47.3 | 1× |
📜 论文原话（逐字引用）
"retention [and precision] are coupled through a single decision threshold: raising the threshold improves precision at the direct cost of recall, forcing a zero-sum trade-off. A dual-bin framework breaks this rigidity — by deploying two independently calibrated classifiers under a logical-OR acceptance rule, documents rejected by one bin may be recovered by the other."
"ϕ_DCLM preferentially selects documents with high world-knowledge content, making room to recover high-value reasoning documents via the BETR bin"
"while the original DCLM pipeline operates ϕ_DCLM at a standalone threshold of 0.018112, deploying it in a dual-bin logical-OR architecture requires recalibration"
"results in very low retention (often below 10%) and incurs high computational cost"
- · arXiv:2603.13972《FLUX: Data Worth Training On》，[v1] 2026-03-14，标题以 abs 页 citation_title 为准
- · Table 20：12 个阶段的 per-stage 移除率（分母 = 初始 424,893,496,759 tokens）
- · Table 22：六个消融/基线点的 post-dedup token 产出与 aggregate 分
- · Table 0：DCLM 355.7 / FineWeb 181.0 / FLUX 48.5 CPU-hrs
- · Table 1：分类 100B tokens —— 单 bin 30min / 双 bin 60min / BERT 1290min
- · Table 2：Parser —— Apex 4.31h / Resiliparse 6.63h / Trafilatura 47.33h
- · Table 7：MMLU 0.298 / 0.319 / 0.321，aggregate 0.4883 / 0.5048 / 0.5192
- · Related Work 原话：LLM 标注分类器类方法 "results in very low retention (often below 10%)"
- · 两种级联口径下的保留率与保留 token 数（加和 / 连乘，浏览器内真算）
- · Table 22 六点的非支配排序（O(n²) 暴力，n=6）与帕累托前沿连线
- · CPU-hrs 求和：baseI/O + 12 阶段 + parser + 分类器（按 token 量缩放）
- · 阈值沙盒：2000 篇文档的 (ϕ_DCLM, ϕ_BETR) 打分用 Box-Muller 采样，混淆矩阵逐条真数
- · 「锁定保留量」约束下的阈值二分求解（单 bin 一维 / 双 bin 网格 + 二分）
- · 12 个阶段的 cpuHrs 是教学分摊（⚠️），锚点为「全开 + Apex + 双 bin ≈ 48.5 CPU-hrs = Table 0 实测」
- · 消融 档 → 模块集合的映射是教学映射（⚠️），Table 21 组件矩阵未逐条回源
- · 阈值沙盒的三类文档占比与两个高斯分布的 μ/σ 是教学设定（⚠️），论文未公开真实打分分布
- · 双 bin 的 token 回收效果在 Tab ① 未建模为百分比（Table 20 无分类器阶段读数），其机制放在 Tab ② 真算
🔧 2026-10-08 重建说明： 初版 12 个模块的 token 损耗是「对初始量取百分比后相加」的，12 个模块损耗之和 172pp，全开时保留率被钳到 0.1%（真实级联连乘应为 13.83%）；双 bin 被建模成 tokenLoss: −5 的「负损耗模块」（语义是凭空加回 token，单独开启保留率 105%）； 四个参考点硬编码且 FineWeb-Edu 写 45%（论文原文是 "often below 10%"）； 帕累托前沿用「x 升序后 y 递增」的假判据把 4 个点全收进前沿，画成上升折线—— 而真前沿只有 2 个点，两个 SOTA 基线都不在上面。以上全部已修正，数字改为论文 Table 0/1/2/7/20/22 的实测读数。