diff --git a/docs/zh/part1/ch01_data_change.md b/docs/zh/part1/ch01_data_change.md
index 09854548..1cc8339d 100644
--- a/docs/zh/part1/ch01_data_change.md
+++ b/docs/zh/part1/ch01_data_change.md
@@ -1,10 +1,23 @@
 # 第1章 大模型时代的数据变革
 
-## 1.1 开篇：一个训练项目为何败在数据上
+## 摘要
 
-在系统性地探讨大模型数据工程体系之前，最直观的切入点莫过于复盘一场真实的“工程灾难”。在这个行业中，由于数据劣质而导致巨构算力和数月时间化为泡影的案例比比皆是。
+本章说明大模型研发为何从以模型结构为中心，转向由数据、算力和基础设施共同约束的系统工程。章节首先通过一个匿名化复合案例说明，低质量语料、重复样本和基准污染会被误判为优化器、并行训练或模型结构问题，并在训练、评测和业务指标之间形成脱钩。随后，本章回顾 Scaling Laws、Chinchilla 法则、Phi 系列和合成数据实践所揭示的规律：数据规模、数据质量和数据多样性共同决定模型能力边界，且三者之间存在成本与工程约束。最后，本章给出大模型数据工程中的角色接口、数据飞轮和全书十四篇结构，为后续质量评估、基础设施、预训练数据、多模态数据、对齐数据、RAG、DataOps 和合规治理章节建立统一坐标。
 
-### 1.1.1 场景引入：当百万算力换来“复读机”与“做题家”
+**关键词**：大模型数据工程；Scaling Laws；数据质量；数据飞轮；基准污染；数据基础设施；模型训练生命周期
+
+**学习目标**
+
+- 理解大模型研发从模型中心转向数据中心的主要原因。
+- 区分训练指标、评测指标和业务指标之间的常见脱钩方式。
+- 掌握规模、质量和多样性三者之间的工程权衡。
+- 了解大模型数据工程中的关键角色、接口和全书结构。
+
+## 1.1 开篇：一个训练项目为何受制于数据质量
+
+在系统性地讨论大模型数据工程体系之前，先看一个匿名化复合案例。该案例综合了公开技术报告、社区复盘和工业项目中反复出现的共性问题，用来说明低质量数据如何在训练、评测和上线阶段逐层放大。
+
+### 1.1.1 场景引入：当算力投入未能转化为有效能力
 假设你是一家人工智能（AI）创业公司的数据负责人。随着公司融资到位，团队刚刚花费三个月时间，利用数百台服务器组成的分布式爬虫集群，从公网爬取并集成了近 50TB 的中文网页语料、1TB 的 GitHub 开源代码以及 500GB 的 Reddit 讨论数据。团队信心满满地启动了千卡 A100 集群，利用 Megatron-LM 框架开始预训练一个 7B 参数的基座模型。整个算法和工程团队在基础设施搭建（如 RDMA 网络调优）、并行训练策略（3D 混合并行架构）和算力节点容错调度上，投入了极大的精力。
 
 然而，机器全速运转两周后，危机出现了。在监控面板上，Loss（交叉熵损失）曲线在降到 2.1 附近时突然“躺平”，甚至出现了小幅震荡向上的反常现象。不仅如此，在研发团队进行早期的 Checkpoint 评估（Interactive Evaluation）时，模型输出表现出令人担忧的怪异感：
@@ -13,44 +26,44 @@
 2. **“复读机”死循环**：当模型生成 Python 代码时，在写完第一个 `def` 函数后，它仿佛陷入了无限循环，开始大量重复 `\n\n\n\n\n` 或 `return return return` 直至达到最大序列长度。
 3. **强背诵弱推理**：给模型输入一道简单的鸡兔同笼变形题，它居然一字不差地默写出了某年 GMAT 考试的长篇阅读原题以及尾部的版权声明，而面对简单的 3 位数加法却一错再错。
 
-在紧急叫停训练的复盘会议上，团队分歧严重。算法工程师怀疑是学习率预热（Warmup）步数不够或 AdamW 优化器的参数设置错误；分布式计算工程师怀疑是某几张坏卡导致通信梯度同步出现了 NaN 毒化了全局权重；而最终在解剖了最近一次喂入模型的数据后，资深架构师抛出了一个让全场彻底哑火的尖锐结论：“我们花了 100 万算力费训练的根本不是通用语言模型，而是一个毫无逻辑的互联网 SEO 垃圾和题库的压缩索引。”
+在紧急叫停训练的复盘会议上，团队分歧严重。算法工程师怀疑是学习率预热（Warmup）步数不够或 AdamW 优化器参数设置不当；分布式计算工程师怀疑是少量异常设备导致通信梯度同步出现 NaN 并污染全局权重；数据工程师则在抽检最近一次输入批次后发现，低质 SEO 页面、重复模板代码和公开题库内容在训练样本中占比异常。这个结论改变了排障方向：问题不只是模型如何训练，而是训练数据是否具备可学习的信号。
 
-这个场景并非为了吸引眼球的杜撰。在 2023 年至 2024 年的大模型“百模大战”浪潮中，无论是明星初创团队还是老牌科技巨头，都不同程度地在同样的问题上付出过高昂的代价。
+这类问题并非单一团队的偶发事故。在 2023 年以来的大模型训练实践中，语料重复、网页噪声、评测集污染和数据血缘缺失，都被反复证明会显著影响模型能力和训练成本。
 
 ### 1.1.2 表现：数据问题如何被误判为模型问题
-在传统后端软件开发中，系统崩溃通常伴随着明确的堆栈报错（Stack Trace），指向引发 Bug 的确切代码行。但在以神经网络黑盒为主的纯数据驱动范式（即大语言模型训练）中，**数据质量的劣质往往会隐蔽地伪装成模型架构或优化器的缺陷**，极大地增加排障难度。
+在传统后端软件开发中，系统崩溃通常伴随着明确的堆栈报错（Stack Trace），指向引发 Bug 的确切代码行。但在以神经网络黑盒为主的数据驱动范式中，**数据质量缺陷往往会表现为模型架构或优化器问题**，从而增加排障难度。
 
 我们总结了实战中最容易相互混淆的三大症状：
 
 1. **梯度爆炸/消失 vs. 数据严重异常**
     * **排查误区**：当监控看板探测到 Loss 剧烈抖动、或者梯度范数（Gradient Norm）瞬间飙升发散为 NaN 时，算法人员通常的第一反应是调整学习率（Learning Rate）或将梯度裁剪（Gradient Clipping）的阈值调严。
-    * **真实根因**：往往是数据集清洗不彻底导致的。例如，数据集中混入了未擦除干净的巨块 HTML/XML 标签树、极长无意义的 base64 图片编码字符串或特殊的控制字符。这些数据在送入分词器（Tokenizer）后，可能被切分成大量罕见 Token 甚至单字符序列，导致注意力机制（Attention Mechanism）在计算指数部分时出现数值溢出（Overflow），从而在反向传播时彻底毒化整个批次的梯度。
+    * **可能根因**：往往是数据集清洗不彻底导致的。例如，数据集中混入了未擦除干净的大段 HTML/XML 标签树、极长无意义的 base64 图片编码字符串或特殊控制字符。这些数据在送入分词器（Tokenizer）后，可能被切分成大量罕见 Token 甚至单字符序列，导致注意力机制（Attention Mechanism）在计算指数部分时出现数值溢出（Overflow），从而污染整个批次的梯度。
 
 2. **生成退化（“复读机”） vs. 注意力崩塌**
     * **排查误区**：当模型生成陷入死循环或反复输出相同字词时，算法层面可能会归结为推理阶段温度参数（Temperature）设置过低，或者是惩罚因子（Repetition Penalty）失效，进而怀疑是多头注意力机制（Multi-Head Attention）坍缩并集中在了某几个固定的 Query-Key 映射上。
-    * **真实根因**：这种“复读机”的病根几乎无一例外指向**未经过大基数严格去重（Deduplication）的训练集**。互联网上存在海量的模板代码、导航栏文本和被机器大量转载的 SEO 文章。当大模型在预训练时，连续几个 Epoch 千百次地暴露于这些高度雷同的文本段落时，它的概率分布预测（Logits）就会强迫性地向这些低价值模式发生偏移，形成极深的“概率沟壑”。在推理时，只要碰到类似的上下文前缀，模型就会滑入死循环无法自拔。
+    * **可能根因**：这类生成退化通常指向**未经过严格去重（Deduplication）的训练集**。互联网上存在大量模板代码、导航栏文本和被机器大量转载的 SEO 文章。当大模型在预训练时反复暴露于这些高度雷同的文本段落时，其概率分布预测（Logits）会向低价值模式偏移。在推理时，只要碰到类似的上下文前缀，模型就容易进入重复生成模式。
 
 3. **“幻觉（Hallucination）”严重 vs. 世界知识构建失败**
     * **排查误区**：对于模型在特定实体领域内的“一本正经胡说八道”，很多团队将其视为大模型固有的基因缺陷，并寄希望于在预训练结束后，通过堆砌大量的领域监督微调（SFT）补丁或者外接检索增强生成（RAG）(Lewis et al. 2020) 系统来外挂式修复。
-    * **真实根因**：“基座不牢，地动山摇”。如果基础清洗管线未能有效过滤低信噪比的网络噪声——如大量重复无意义的灌水内容、事实性错误严重的伪科普文章，或内部逻辑自相矛盾的劣质语料——，“基座模型”的世界模型（World Model）从一开始就被严重扭曲。此时的模型并没有学习到事物之间的普遍逻辑法则，而是变成了错误相关性的记忆体。后期在对齐阶段试图通过少量微调去掩盖这巨大的基础缺陷，无异于杯水车薪。
+    * **可能根因**：如果基础清洗管线未能有效过滤低信噪比的网络噪声，例如重复灌水内容、事实错误明显的伪科普文章，或内部逻辑自相矛盾的劣质语料，基座模型的世界模型（World Model）从训练早期就会受到干扰。此时模型学到的可能是错误相关性，而非稳定的事实与推理关系；后续对齐阶段的少量微调很难完全弥补这一基础缺陷。
 
 ### 1.1.3 训练指标、评测指标与业务目标为何背离
-如果我们进一步深入这个失败案例，会发现一个更值得注意的现象：在大规模训练的早期监控中，单看训练集的 Validation Loss 是正常随拟合步数在平滑下降的；甚至在一些评估平台上跑出来的得分也不错，但到了真实业务的人工评测盲测中却一塌糊涂。
-这种指标脱轨直接揭示了低水平数据工程带来的掩耳盗铃效应。
+如果进一步分析这个失败案例，会发现一个更值得注意的现象：在大规模训练的早期监控中，Validation Loss 可能随训练步数平滑下降；模型在部分评估平台上的得分也可能较高，但在真实业务的人工盲测中表现明显不足。
+这种指标脱钩说明，数据工程缺陷可能同时影响训练监控、离线评测和业务评估之间的对应关系。
 
-*   **训练指标（Loss）的欺骗性陷阱**：在缺乏正确数据分离机制的情况下，如果用来计算 Validation Loss 的保留测试语料，最初与训练语料是从同一个未经去重和去污染的池子中按比例拆分的，那么这会导致严重的**数据分布同质性重叠**。模型在测试集上表现出的低 Loss，根本不意味着它掌握了泛化推理能力，它仅仅只是在证明：它强大地记忆了那些充斥两边的低质量数据或高频重复样本。
-*   **深水炸弹：基准测试污染（Benchmark Contamination）**：这是预训练工程中最隐蔽也最具破坏性的数据质量问题之一。业界不乏这样的案例：团队在公开基准测试（如逻辑推理评测 GSM8K (Cobbe et al. 2021)、通用知识评测 MMLU (Hendrycks et al. 2021)）上取得了令人振奋的高分，但在真实业务场景的人工盲测中却表现平平。事后的数据溔源审计往往指向同一根因：爬虫管线曾不加区分地抓取了包含这些公开评测题库及其解答的代码仓库或网页，由于缺乏 N-Gram 级别的去污染检测，相关题目畅通无阻地混入了预训练语料。此时模型展示的并非真正的推理泛化能力，而是对已见题目的强记忆匹配——一旦遇到分布之外的新问题，能力断崖便立刻暴露无遗。
+*   **训练指标（Loss）的解释风险**：在缺乏正确数据分离机制的情况下，如果用于计算 Validation Loss 的保留测试语料与训练语料来自同一个未经去重和去污染的池子，那么会导致严重的**数据分布同质性重叠**。模型在测试集上的低 Loss 不一定意味着它掌握了泛化推理能力，也可能只是记忆了训练集和验证集共同包含的低质量数据或高频重复样本。
+*   **基准测试污染（Benchmark Contamination）**：这是预训练工程中隐蔽且影响严重的数据质量问题之一。团队可能在公开基准测试（如逻辑推理评测 GSM8K (Cobbe et al. 2021)、通用知识评测 MMLU (Hendrycks et al. 2021)）上取得较高分数，但在真实业务场景的人工盲测中表现平平。事后的数据溯源审计往往指向同一根因：爬虫管线曾不加区分地抓取包含公开评测题库及其解答的代码仓库或网页，由于缺乏 N-gram 级别的去污染检测，相关题目混入了预训练语料。此时模型展示的并非真正的推理泛化能力，而是对已见题目的记忆匹配；一旦遇到分布之外的新问题，能力差距就会暴露。
 
-这次事故的教训不仅是几百万云账单的付诸东流，更是在产品侧延误了长达数月的市场关键冲刺期。它以极为高昂的代价，向大航海时代的 AI 从业者证明了一条今天已被奉为圭臬的铁律：**在模型底层算子与 Transformer 变体架构高度同质化、趋于收敛的今天，优质且极具壁垒的数据工艺流水线，才是拉开巨头之间模型智商差距的核心优势。**
+这次事故的教训不仅体现在算力账单上，也体现在产品节奏、团队信任和后续数据治理成本上。它说明了一个基本事实：当主流模型结构、并行训练框架和推理服务栈逐渐趋同时，数据来源、数据清洗、数据配比和数据质量验证会成为模型能力差异的重要来源。
 
 
 ## 1.2 从模型中心到数据中心的范式迁移
 
-回顾前深度学习时代，在古典机器学习（如推荐系统或早期 CV 任务）的时期中，“特征工程 + 结构各异的复杂算法（SVM/决策树组/胶囊网络等）”曾是绝对的王道。在 2012 年至 2020 年这快速发展的黄金十年里，研究者们坚信“复杂庞大的架构创新创造跨时代奇迹”（从 AlexNet (Krizhevsky et al. 2012), ResNet (He et al. 2016) 到 Transformer 框架各异变体 (Vaswani et al. 2017)）。
-然而，当 GPT-3 (Brown et al. 2020) 的雷霆之光划破长空并以单一自回归语言模型（Autoregressive LM）“一统江山”之后，天平彻底倾覆。“数据中心主义（Data-centric AI）”以其不可逆转之势，正式取代了“模型中心主义”。这是一场基于算力重塑和规律发现的全面范式迁移。
+回顾前深度学习时代，在古典机器学习（如推荐系统或早期 CV 任务）中，“特征工程 + 结构各异的复杂算法（SVM、决策树组、胶囊网络等）”曾是主要路径。在 2012 年至 2020 年的深度学习快速发展阶段，研究者持续通过模型结构创新推动任务性能提升，从 AlexNet (Krizhevsky et al. 2012)、ResNet (He et al. 2016) 到 Transformer 及其变体 (Vaswani et al. 2017)，均体现了这一方向。
+然而，GPT-3 (Brown et al. 2020) 等大规模自回归语言模型（Autoregressive LM）的出现，使研究和工程投入进一步集中到规模化训练、数据组织和训练配方上。“数据中心主义（Data-centric AI）”并不是否定模型结构创新，而是强调：在相近模型架构下，数据规模、数据质量和数据混合策略对能力表现具有决定性影响。
 
 ### 1.2.1 定量规律：Scaling Laws 的起源与 Chinchilla 对数据配比的重塑
-如何让大语言模型拥有比肩人类的智力？2020 年，OpenAI 的研究员们给出了一个剥去神秘主义色彩的硬核回答。在里程碑式的论文《Scaling Laws for Neural Language Models》(Kaplan et al. 2020) 中，他们详细揭示了由惊人数据得出的一个核心规律：大型语言模型的最终性能（以交叉熵损失表征的 Loss）与三个关键要素构成稳固的幂律（Power Law）制约关系——
+如何理解大语言模型能力随规模增长的规律？2020 年，OpenAI 的研究员在论文《Scaling Laws for Neural Language Models》(Kaplan et al. 2020) 中给出了一个重要经验规律：大型语言模型的最终性能（以交叉熵损失表征的 Loss）与三个关键要素构成稳固的幂律（Power Law）制约关系——
 模型参数量 $N$、投入训练的高质量数据集规模 $D$、以及消耗的总算力 $C$。
 
 其核心等价描述可以简化为：
@@ -59,60 +72,60 @@ $$
 L(N, D, C) \approx \left(\frac{N_c}{N}\right)^{\alpha_N} + \left(\frac{D_c}{D}\right)^{\alpha_D} + \left(\frac{C_c}{C}\right)^{\alpha_C}
 $$
 
-这个公式宣告了一个事实：只要给定充分燃烧的硅基算力，同时同向且以适当比例扩大模型神经元容量和喂入的优质数据，模型的智慧水平就会呈现**高度可预测的线性演进与能力跃迁**。从这天起，凭直觉试错的研发方式被终结，大模型训练变成了一门如同造桥铺路般的精密系统工程。
+这个公式说明：在给定计算预算下，模型参数量、训练数据规模和计算量需要协同增长，模型性能才会持续改善。由此开始，大模型训练逐渐从依赖直觉试错的研发活动，转向可通过数据、算力和训练配方共同规划的系统工程。
 
 **Chinchilla 法则：对数据规模渴求的重估**
-然而，在 Scaling Laws 发布初期的浪潮中，存在一个巨大认知盲点。很多公司一味追求扩大参数量（譬如争相发布千亿、甚至万亿参数规模的超大模型，如早期的 175B 的 GPT-3 (Brown et al. 2020) 以及各家追随者），认为模型大就是性能好。
+然而，在 Scaling Laws 发布初期，行业中存在一个重要认知偏差。许多团队优先追求扩大参数量（例如发布千亿甚至万亿参数规模的大模型，如早期 175B 参数的 GPT-3 (Brown et al. 2020) 以及后续追随者），并倾向于把模型规模直接等同于性能。
 但到了 2022 年，DeepMind 的一篇名为《Training Compute-Optimal Large Language Models》（即著名的 Chinchilla 论文）(Hoffmann et al. 2022) 的研究打破了这一幻觉。
 
-DeepMind 研究团队进行了严格控制变量的计算最优（Compute-Optimal）实验。他们的结果令整个学术界震惊：参数量仅有 70B（700 亿）的 Chinchilla 模型，由于吃透了深度清洗过的 1.4T（1.4万亿）Tokens 的优质数据，其各项评测得分竟然全面超越了公司自己此前训练的体积大它 4 倍的 280B 的大模型 Gopher (Rae et al. 2021)。
+DeepMind 研究团队进行了严格控制变量的计算最优（Compute-Optimal）实验。结果显示：参数量为 70B（700 亿）的 Chinchilla 模型，在使用约 1.4T（1.4 万亿）Tokens 训练数据后，多项评测结果超过了此前参数量更大的 280B Gopher 模型 (Rae et al. 2021)。
 
 **表 1-1：DeepMind 旧范式模型与新范式模型数据资源对比**
 
 | 模型代号（发布方） | 参数量 $N$ | 投入训练数据的 Token 数 $D$ | 训练算力消耗占比估计 | 推理侧表现特征 |
 | :--- | :--- | :--- | :--- | :--- |
-| **Gopher** (Rae et al. 2021) | 280B | 300B Tokens (约 0.3T)| 同等控制变量 | 内存占用庞大不利于部署落地产出 |
-| **Chinchilla** (Hoffmann et al. 2022) | **70B** | **1.4T Tokens** | 同等控制变量 | **低推理成本，且综合评测全面碾压超越** |
+| **Gopher** (Rae et al. 2021) | 280B | 300B Tokens (约 0.3T)| 同等控制变量 | 参数量较大，推理部署成本更高 |
+| **Chinchilla** (Hoffmann et al. 2022) | **70B** | **1.4T Tokens** | 同等控制变量 | 参数量较小，在多项综合评测中取得更优结果 |
 
-Chinchilla 法则指出：过去行业内的模型普遍**“体型胖导致超重，但肚子空空营养不良（Under-trained）”**。若想获取计算预算下的最大收益，模型参数量和训练数据所需的 Token 数，应当以大致相同的比例同步增加。这条黄金法则是：
-> **模型每增加 1 个参数，需要起码为其配套投入约 20 个高质量 Token 的训练数据才能使其吃饱。**
+Chinchilla 法则指出：过去行业内的许多模型处于**训练不足（Under-trained）**状态。若想获取计算预算下的最大收益，模型参数量和训练数据所需的 Token 数，应当以大致相同的比例同步增加。一个常用经验口径是：
+> **模型每增加 1 个参数，通常需要配套约 20 个高质量 Token 的训练数据。**
 
-这意味着，今天如果某团队想立项研发一个仅仅 7B 级别的主流开源基座模型基准线，他们准备的高质量、无损语料保底规模必须达到惊人的 140B（即 1400 亿）Tokens 以上。若放眼追求极致性能的小体量旗舰（如 LLaMA-3 8B 版本），其最终所吞噬的精炼数据竟直逼 15T（15万亿）Tokens (Dubey et al. 2024)——値得注意的是，这已远超 Chinchilla 最优点（约 160B Token），这是 Meta 刻意采用的「过训练（Over-training）」策略：用更多数据换取更低的推理部署成本，使小模型在同等算力下获得更强的长期性能，而非 Chinchilla 法则本身的要求。这种指数级增大的饭量，让所有公司的目光从“寻找模型新结构”被迫转向到了“拿什么填饱算力巨兽的大嘴”上。
+这意味着，如果某团队计划研发 7B 级别的开源基座模型，其高质量训练语料规模通常需要达到约 140B Tokens 以上。若追求更高小模型性能，例如 LLaMA 3 8B，其训练数据规模达到约 15T Tokens (Dubey et al. 2024)。需要注意的是，这已远超 Chinchilla 最优点（约 160B Tokens），属于 Meta 刻意采用的过训练（Over-training）策略：用更多数据换取更低的推理部署成本，使小模型在同等推理预算下获得更强能力。这种趋势推动团队把注意力从单纯寻找模型结构创新，转向如何持续供给高质量训练数据。
 
 ### 1.2.2 质量的逆袭：Phi 系列极端实验与合成数据的曙光
-就在所有头部企业纷纷大秀爬虫肌肉，比拼谁能搂来超大量级的互联网底库时，微软研究院却出人意料地通过名为”Phi”的系列论文彻底颠覆了关于“大就一定好”的路径依赖，给全行业结结实实地上了一堂关于**纯净极限质量（Extreme Data Quality）**的教学课。
+在规模扩张之外，微软研究院的 Phi 系列工作提供了另一条重要路径：通过高度筛选和合成的高质量数据，提升小参数模型在特定任务上的能力表现。
 
-微软发布的 Phi-1 模型是一个异类。它在训练开始前就被限定在了一个近乎“侏儒”级别的架构上（仅有 1.3B 的微小参数量），不仅如此，训练消耗的数据仅有可怜的 7B Token。但是，就是在这种硬件和规模的全面劣势下，当它被放在 HumanEval (Chen et al. 2021) 代码评测榜等硬核逻辑图谱上时，小小的 Phi-1 却将不少百亿体量的开源界大哥斩落马下。
+微软发布的 Phi-1 模型参数量仅为 1.3B，训练数据规模约为 7B Tokens。尽管规模远小于许多开源代码模型，Phi-1 在 HumanEval (Chen et al. 2021) 等代码评测上取得了具有竞争力的结果。
 
-Phi-1 何以四两拨千斤？论文名字揭示了核心方法——《Textbooks Are All You Need》(Gunasekar et al. 2023)（教科书就是你需要的全部）。研究团队舍弃了公网上随处可见的充斥着评论对骂、错别字与烂尾代码的 StackOverflow 类似帖子截留，转而动用强大的 GPT-3.5/GPT-4 充当“专家级教师”，依靠严谨规划的 Prompt，让强模型源源不断地自动生成结构丝滑、循序渐进、从零解释算法基础的高质量编程解说教程 (Li et al. 2023)。
+Phi-1 的核心方法来自《Textbooks Are All You Need》(Gunasekar et al. 2023)：研究团队减少对低质量论坛内容和未筛选代码片段的依赖，转而利用 GPT-3.5/GPT-4 生成结构清晰、循序渐进、类似教材的高质量编程语料 (Li et al. 2023)。
 
-当模型吸收的全部都是高纯度、高密度的信息“精酿”，没有被迫在理解充满矛盾的、不符合逻辑的、带口音的噪音上浪费哪怕一点参数量时，“涌现”的阈值被极大地提前了。这直接揭示了数据工程中不应被遮蔽的真理：以超高质量和极速提纯的人工合成数据（Synthetic Data）或精炼专家知识来“浓缩干预”，依然可以实现对“大力出奇迹”大规模扩展策略的弯道超车。
+当训练数据具有更高信息密度、更少噪声和更清晰的任务结构时，小模型也可能在特定能力上获得显著提升。这说明，合成数据（Synthetic Data）和专家知识蒸馏不是规模扩张的替代品，但可以成为提高数据效率和降低训练成本的重要手段。
 
-### 1.2.3 核心基石：规模、质量与多样性的“大模型不可能三角”
-从上述对深度学习历史脉络的层层解剖中，我们可以清晰地构筑出现代 LLM 数据科学家们案头的最终决策拓扑模型。在大模型数据工程范式下，真正制约模型智力边界的不是单一维度，而是存在着互相博弈、互相撕扯的**"核心三要素（Scale, Quality, Diversity）工程权衡铁三角"**——三者之间在有限资源约束下无法同时做到最优，每一项的极端化必然以牺牲另外两项为代价。
+### 1.2.3 核心基石：规模、质量与多样性的工程权衡
+从上述研究脉络可以看到，在大模型数据工程范式下，真正制约模型能力边界的不是单一维度，而是**规模（Scale）、质量（Quality）与多样性（Diversity）**之间的组合权衡。三者在有限预算和有限时间内很难同时达到最优，每一项的极端化通常会带来另外两项或工程成本上的代价。
 
-**表 1-2：大模型数据工程的三阶魔方——质量、规模与多样性成本约束基准矩阵**
+**表 1-2：大模型数据工程中规模、质量与多样性的成本约束矩阵**
 
-| 切片核心维度 | 数据处理的核心战术执行手段 | 获取的直接能力与模型显著收益 | 面对的强痛点约束（成本代价转移区） |
+| 核心维度 | 主要数据处理手段 | 直接收益 | 主要约束 |
 | :--- | :--- | :--- | :--- |
-| **强横的海量规模 (Scale)** | 依托 CommonCrawl 或底层云全站爬虫广撒网进行无差别高并发抓取存储，常采用局部敏感哈希（MinHash LSH）等廉价模糊匹配执行粗糙除重清洗，只求吃下互联网所有公开底库。 | 强行堆砌起足够厚的广泛世界知识字典，确保超大模型见过所有常识实体的底层关联；同时规模也是触及 Scaling Laws 智商跨越式涌现质变点的唯一底线物理门票。 | **海量吞噬高昂的云端算力与网络存储带宽经费成本**。动辄需要上百 PB 级的温热对象存储费用对齐。另外，如果因为盲目堆砌导致垃圾泛滥，导致 Token 序列超长过剩泛滥，每多一个无意义的训练长 Epoch 就会成线性吞噬高昂的万卡 H100 GPU 训练阵列节点物理上架机时费用。 |
-| **近乎洁癖的极致质量 (Quality)** | 选择高配置的机器过滤逻辑。常常利用数十个大模型作为重型判别评估打分官，配合巨型图谱知识校验或基于 PPL 的高维困惑度算法拦截。有时为了冲量，还得花重金聘请具备各行业真实专业背景的高级全职雇员从零手写结构优良的 SFT 对话样本。 | 斩点模型陷入生成混乱及重复的数学逻辑诅咒，强硬打破普通数据堆叠再怎么塞也无法提升智力的深远瓶颈。赋予了所出大模型推理链输出时卓越的逻辑严密性与人类友好表达能力，对模型编造事实的幻觉（Hallucination）具有显著抑制效果。 | **容易陷入长期治理的经验真空泥沼与人手枯竭**。高价值高质量的纯公网开源语料在自然界中极少，且早就被几家科技先行者垄断挖掘殆尽。“寻找并提炼真金”本身变成一件比研发算法架构更消耗脑血力的心智负荷劳动；聘请专家人工治理的边际资金成本不断攀升，快速逼近项目预算与有效劳动极限。 |
-| **广度超宽的分布多样 (Diversity)**| 数据工程师执行精细复杂、且在数以万次实验磨合出的黄金配比（Data Mixing Schedule）；横跨几十门不同底层语族的小语种逻辑，强行打散穿插混编医学临床、法律条文判例、建筑电气图纸、各类底层架构编程 C++ 等各重垂直学术壁垒孤岛，甚至要同时涵盖琐碎的微短日常问答互动邮件与万字深度反思总结。 | 极大地预防并杜绝灾难性遗忘症（Catastrophic Forgetting）。彻底防止模型因为某批数据扎堆而沦为某种特定古怪语境下的井底之蛙；在多样性能的激荡下构建如全科医师般强悍的逻辑抗造干扰能力以及令人惊叹的零样本指令泛化适应与应对各路刁钻安全攻击挑战。 | **极高强度的跨语种与变态复杂模态解析结构底层框架的反复重构运维成本。难度大到直接劝退新手团队**。这需要中台架构师针对多达数百种截然不同、杂乱无序的数据底包排版格式进行高度个性化地定制千奇百怪的分布式正则解析流水线，以及维护各自截然不同的底层向量验证调度器，代码重如泰山管理异常艰辛。 |
+| **规模 (Scale)** | 依托 Common Crawl、自建爬虫、代码仓库镜像和授权语料库进行大规模采集，并使用 MinHash LSH、语言识别和基础质量过滤完成第一轮筛选。 | 提供广泛世界知识和多领域语言模式，是模型进入 Scaling Laws 有效区间的必要条件。 | 存储、网络和预处理成本快速上升；如果规模扩张缺少质量闸门，低价值 Token 会直接转化为训练算力浪费。 |
+| **质量 (Quality)** | 使用规则过滤、PPL 打分、质量分类器、事实核验、专家标注和合成数据审计等机制提升信噪比。 | 降低生成退化、事实错误和格式混乱的风险，在代码、数学、专业问答等高精度任务中尤为关键。 | 高质量数据稀缺，自动评估和人工审计成本高；过度清洗还可能削弱覆盖度和模型泛化。 |
+| **多样性 (Diversity)**| 通过语种、领域、模态、任务类型和难度层级的混合配比，构建可持续迭代的数据混合策略（Data Mixing Schedule）。 | 减少灾难性遗忘和领域偏置，提高模型在长尾场景、多语言场景和新任务上的适应能力。 | 多样性要求更复杂的解析器、采样策略、数据版本管理和跨团队协调，容易增加平台复杂度。 |
 
-由于无法“全要都要”，每一个团队首席数据工程师所主导的全流程高阶数据设计，实质上就是戴着极为繁重的经费、人力与项目交付时间的限制脚镣，在这三个强约束变量构成的顶角之间寻找一条堪堪可行的马鞍面最优平衡逃生生路。
+由于无法同时把规模、质量和多样性推到极致，数据工程负责人需要在预算、训练目标、上线时间和风险边界之间做权衡。成熟的数据设计不是简单地扩大语料，而是在三个变量之间找到可解释、可复现、可迭代的平衡点。
 
-### 1.2.4 传统 AI 生命周期链路 vs. LLM 数据管线的全面错位与崩溃落寞
-对于绝大多数刚刚拿到大规模风投打算踏入大语言模型训练战场、但整个职业生涯原本长期从事于内容推荐算法分发或者工业机器视觉图像检测系统搭建领域的资深架构师们来说，他们在转型之初最容易产生痛苦的“水土不服”。因为他们最深刻痛楚的领悟迟早会降临：过往数年如珍宝般积累并奉为至高真理的整套 Hadoop 系传统大数据报表清洗方法论体系，在这里遭遇了极大的错位与失效。由于底层任务的最终导向目标，从老一代“处理格式高度规整的行列表格来推测一个小目标变量”，跨越性地走向了“需要模型独自以完全无监督的孤狼模式，在几乎无穷维度的语言文字与逻辑联系连续体海洋中，自己去理解整个浩瀚世界的复杂规则运转规律”，因此整条原始沉重的管线范式彻底地需要被重置击碎重构。我们需要为新时代的大模型开发者强力构筑并打造出彻底贴合这套逻辑的全新“AI 原生的高并发数据栈与流水线方法论体系”。
+### 1.2.4 传统 AI 生命周期链路与 LLM 数据管线的主要差异
+对于长期从事推荐系统、搜索排序或工业视觉任务的工程团队来说，转向大语言模型训练时常会遇到方法论迁移困难。传统数据仓库和机器学习流水线主要处理结构化表格、日志特征和有限标签空间，而大模型训练面对的是非结构化文本、代码、文档、多模态长序列和开放式生成目标。因此，许多传统 ETL 经验仍然有价值，但不能直接替代面向 LLM 的数据清洗、去重、污染检测、配比、版本管理和训练 I/O 优化。
 
-**表 1-3：传统经验 AI 机器学习研发生命线 vs 大语言模型（LLM）原生数据体系**
+**表 1-3：传统机器学习数据链路与大语言模型原生数据体系对照**
 
-| 对峙痛点底层切片剖面 | 前沿工业经典 AI 开发稳健流水线（以推荐系统算法为主干） | 大语言生成模型快速发展下的纯靠原生算力堆叠开发数据深远体系 |
+| 对比维度 | 传统机器学习数据流水线（以推荐系统为例） | 大语言模型原生数据体系 |
 | :--- | :--- | :--- |
-| **核心数据类型载体** | 企业历经重兵开发留存的高度纯粹强依赖结构化的用户行为映射 SQL 宽表矩阵。以及大量拥有固定生命时效和定长的平台截取日志、高保真传感器埋点时序切片数据。 | 一大团边界模糊且庞大绵延不绝的海量杂交错语言文字流；其中还要嵌套着高阶计算机调用链条代码，充满各种肉眼难以剥离排版混乱复杂的万页巨幅 PDF，以及最近半年急速兴起的超长多维多模态理解图文音视流长序列。 |
-| **底层吞吐计算数据物理体量** | 基本上维持在大容量的 GB 直到底线级别的早期 TB 量级段位。绝大多数利用 Pandas 基本调用简单组合切片筛选清洗一下，然后再统一合并经过离线高延迟的重量级 Hive 数据仓库表查询引擎映射调度。 | 前所未有的量级挑战：直接将吞吐需求跳跃扩张攀升跨域到 PB 级乃至 EB 级黑洞。短时间内极易超出各种在过去看来源源不绝宽裕的企业总线 IO 网络通讯数据管道流带宽。 |
-| **质量风控博弈点** | 全力解决在人工或机器标注期间发生的低级人为错误，或者是重点解决某几种类别罕见负样本失衡的分布不平衡问题。 | 全力排查并消灭数千亿字词中的深层隐藏文本重复度问题（去除同质化记忆毒药）、深切检验语意表达自洽隔离关联、斩断极容易侵犯隐私和价值观崩溃的脏数据、抵御刻意知识污染拉齐价值观底线。 |
+| **核心数据类型载体** | 以用户行为表、业务事件表、传感器日志和特征宽表为主，结构较稳定。 | 以网页文本、代码、论文、PDF、图文对、音视频和交互日志为主，格式多样且边界不稳定。 |
+| **底层吞吐计算数据物理体量** | 通常处于 GB 到 TB 级，主要依赖 SQL、Spark、Hive 或特征平台处理。 | 常扩展到 TB、PB 乃至更高规模，并同时受 CPU 清洗、对象存储、网络带宽和训练 DataLoader 吞吐约束。 |
+| **质量风控博弈点** | 关注缺失值、异常值、标签错误、类别不平衡和特征泄漏。 | 关注文本重复、网页噪声、基准污染、版权与 PII、领域偏置、时效衰败和跨模态错位。 |
 
-从上述表格的对峙中不难看出为什么企业要全面转型。在 LLM 新的工业范式下，去获取一份“提纯过更具营养价值的干净数据”所硬性消耗的综合集群服务器开销、网络经费和智力试错成本，已经跨越了临界点，甚至**远远超过了研究人员费尽心力去“寻找并调试一种更好的底层深度神经网络图层结构算法”的所有投入**。很多一线实验室内部：超过 60% 以及以上名片印着高薪的 AI 研究人员，他们在本质上，正在全职从事一份叫做“大语言智能数据顶级配方烹饪师”的角色工作。
+从上述对比可以看到，LLM 数据工程的关键挑战并不是把传统数据平台扩大一两个数量级，而是重新定义数据的生产目标、质量指标和训练接口。在很多一线团队中，研究人员和工程人员的大量工作已经转向数据配方、清洗规则、评测集隔离、合成数据审计和训练吞吐优化。数据工程由此从辅助环节变为模型研发的核心能力。
 
 
 ## 1.3 LLM 项目中的角色重组与协作接口
@@ -123,11 +136,11 @@ Phi-1 何以四两拨千斤？论文名字揭示了核心方法——《Textbook
 
 在 LLM 研发体系中，角色的融合与接口定义的清晰变得前所未有的重要。此时不再是单向移交数据的流水线，而是必须构建首尾相连的"**数据飞轮（Data Flywheel）**"。
 
-所谓数据飞轮，指的是一个持续自我强化的数据闭环：模型上线后，前端用户的真实交互行为（如对回答的赞/踩、修改建议、放弃率等）会实时被采集记录；这些在线负反馈数据经过数据工程师的清洗、标注和结构化处理，转化为下一轮 RLHF (Ouyang et al. 2022) 的偏好对比集；新的偏好数据喂入对齐阶段训练出更好的模型；更好的模型再次部署，产生更高质量的在线反馈数据——飞轮就此转动，且越转越快。
+所谓数据飞轮，指的是一个持续自我强化的数据闭环：模型上线后，前端用户的交互行为（如对回答的赞/踩、修改建议、放弃率等）会被采集记录；这些在线负反馈数据经过数据工程师的清洗、标注和结构化处理，转化为下一轮 RLHF (Ouyang et al. 2022) 的偏好对比集；新的偏好数据进入对齐阶段训练出更好的模型；更好的模型再次部署，产生更高质量的在线反馈数据。
 
-![图：大模型时代数据工程职责重构图](../../images/part1/data_engineering_roles_1775830393574.png)
+![图1-1：大模型时代数据工程职责重构图，展示平台、数据、算法、标注、产品与合规角色之间的闭环接口](../../images/part1/data_engineering_roles_1775830393574.png)
 
-*图1-1：大模型时代数据工程职责重构图 —— 展现了从平台架构、数据采集到模型微调验证再到产研迭代的角色飞轮闭环。*
+*图1-1：大模型时代数据工程职责重构图。来源：本书自绘。该图展现了从平台架构、数据采集到模型微调验证再到产研迭代的角色飞轮闭环。*
 
 这个飞轮得以高速运转的前提，是每个角色之间存在**清晰、可执行的数据交接 SLA（服务级别协议）**。否则，一旦某个接口模糊（例如"产品侧说反馈数据给数据团队，但格式和字段没有约定"），飞轮就会在最脆弱的环节停滞。
 
@@ -139,7 +152,7 @@ Phi-1 何以四两拨千斤？论文名字揭示了核心方法——《Textbook
 | **大模型数据工程师** | 原始语料采集（爬虫/API）、多阶段清洗（去重、去噪、脱敏）、数据配比与混合采样、数据版本管理 | 算法团队的领域权重配比需求、安全合规的黑名单规则、标注团队的 SFT 样本反馈 | 通过质量评分卡验收的 Parquet/JSONL 格式数据包；数据血缘文档 | 每批次数据包的清洁度评分 ≥ 0.85；交付 SLA：提出需求后 T+3 个工作日内完成新语料接入 |
 | **算法 / 预训练研究员** | 设计 Tokenizer 词表、制定训练数据配比策略（Data Mixture Recipe）、关注 Loss 曲线与 Eval 基准变化 | 清洗后的标准化数据包；数据集统计报告（领域分布、去重率、PPL 分布） | 数据配比权重需求文档；新增的 Eval 套件定义；消融实验结论（某类数据对哪个基准有多大提升） | 消融实验周期 ≤ 2 周出结论；关键领域数据增量需求提前 2 周提出 |
 | **AI 标注 / 提示词专家** | 设计符合人类偏好的 SFT 样本指令集、制定 RLHF 打分规范、精编 RAG 知识库 Q&A | 数据工程师提供的原始文本供筛选；算法团队的模型弱点报告（哪类指令失效） | 高质量的（Prompt, Response）对；偏好打分集（chosen/rejected）；RAG 标准评测集 | SFT 样本日产量 ≥ 500 条（专家级）或每轮标注一致性 κ > 0.7 |
-| **模型产品 / 应用层** | 收集线上真实用户反馈、定义业务场景覆盖需求、提供线上异常监控代理指标 | 算法团队提供的模型 API 及性能报告；数据团队提供的覆盖度分析 | 线上负样本（用户踩踏、修改的回答）；新场景的数据需求规格书；线上幻觉异常 case 汇总报告 | 线上异常 case 的汇总周期：每周一次；新场景数据需求描述在提出后 1 周形成书面规格 |
+| **模型产品 / 应用层** | 收集线上真实用户反馈、定义业务场景覆盖需求、提供线上异常监控代理指标 | 算法团队提供的模型 API 及性能报告；数据团队提供的覆盖度分析 | 线上负样本（用户负反馈、修改后的回答）；新场景的数据需求规格书；线上幻觉异常 case 汇总报告 | 线上异常 case 的汇总周期：每周一次；新场景数据需求描述在提出后 1 周形成书面规格 |
 | **安全与合规专员** | 源语料版权溯源审计、PII 个人隐私数据监控、毒性内容与偏见评估拦截 | 所有即将入库语料的来源元信息（URL、抓取时间戳、许可证类型）；SFT 样本的最终版本 | 版权合规评估报告；PII 过滤规则集更新；毒性/偏见评估分数；合规通过的 Green-light 证明 | 每批数据的合规审查 ≤ 5 个工作日；高风险来源数据的预警发出时间 < 24小时 |
 
 **数据飞轮的完整时序：一次典型的迭代周期（约 4-6 周）**
@@ -164,20 +177,20 @@ Phi-1 何以四两拨千斤？论文名字揭示了核心方法——《Textbook
 [T+5  周] 产品团队确认幻觉 case 复现率降低 76% → 全量发布，进入下一轮飞轮
 ```
 
-以上就是一个最小可行数据飞轮（MVP Data Flywheel）的完整时序。**没有这种级别精确的角色分工与 SLA 约束，飞轮就会在某个环节发生严重的信息失真或时间拖延，从而变成一个每三个月才能转动一次的"钝锈齿轮"**，完全跟不上商业竞争的迭代节奏。
+以上就是一个最小可行数据飞轮（MVP Data Flywheel）的完整时序。没有这种级别的角色分工与 SLA 约束，飞轮会在某个环节出现信息失真或时间拖延，最终使模型迭代周期从数周延长到数月。
 
 ### 1.3.2 团队能力模型与岗位演进
 
-现代的"**大模型数据工程师（LLM Data Engineer）**"是一个在 2023 年前几乎不存在、却在 2024 年突然成为 AI 独角兽企业争抢的新物种。他们不再仅仅是坐在数据仓库旁边编写 SQL 提取报表的"管道工"，也不再是执行逐条规范标注任务的"流水线工人"。这个角色高度融合，处于模型研发链条的核心枢纽地带，必须在以下四个维度上同时具备能力：
+现代的**大模型数据工程师（LLM Data Engineer）**已经从传统数据工程、机器学习工程和平台工程之间分化出来。这个角色不再只负责 SQL 报表或离线 ETL，也不只是执行标注规范，而是处于模型研发链条的数据接口位置，需要同时具备以下四类能力：
 
 1. **大规模分布式计算能力**：熟练掌握 Ray Data、Apache Spark、Dask 等大规模并行计算框架，能够在数千个 CPU 核心上设计并调优由 MinHash LSH (Broder 1997) + Bloom Filter (Bloom 1970) 驱动的高效去重作业。要能感知 I/O 瓶颈与计算瓶颈的差异，懂得如何调整分区策略（Partitioning）来避免整个作业被几个超大 Shard 文件拖垮。
 2. **算法感知度（ML-Awareness）**：需要深刻理解 Tokenization 的底层原理（BPE、Unigram LM），懂得如何解读 Perplexity（困惑度）曲线来判断数据质量好坏，知道如何利用 KenLM (Heafield 2011) 这样的 N-gram 语言模型为候选数据打出"信息密度评分"，从而在算力成本和语料质量之间做出精确权衡。他们有时需要与算法研究员一起设计"消融实验"（Ablation Study），通过"数据集 A vs 数据集 B"的对照组，探明某类语料对某项基准测试提升的真实贡献率。
 3. **数据治理与版本控制工程**：像 Git 控制代码版本一样，用 LakeFS 或 DVC 管理 TB 乃至 PB 级别的数据集版本。每一次数据过滤规则的修改、每一次领域配比权重的调整，都应当形成一个可追溯的数据版本提交（commit）。这是数据工程区别于"数据搬运"的根本体现——当模型训练出问题时，必须能够"git bisect"般地将脏数据的源头精确定位到某次配比调整或某一批爬取数据。
 4. **大语言模型生态嗅觉与工具链整合**：熟悉各类主流开源数据集（如 The Pile (Gao et al. 2020)、RefinedWeb (Penedo et al. 2023)、FineWeb-Edu (Lozhkov et al. 2024)、Dolma (Soldaini et al. 2024)、DCLM-Baseline (Li et al. 2024)），了解各数据集的内容偏向与局限；同时能熟练使用 Data-Juicer (Chen et al. 2024)、datatrove (Penedo et al. 2024)、dolma-toolkit 等专为 LLM 逻辑设计的数据处理工具框架，而非用通用 ETL 工具生搬硬套。
 
-**表 1-5：LLM 数据工程师 vs 传统 ML 数据工程师能力边界对照表**
+**表 1-5：LLM 数据工程师与传统 ML 数据工程师能力边界对照表**
 
-| 能力维度 | 传统 ML 数据工程师 | LLM 数据工程师（新物种） |
+| 能力维度 | 传统 ML 数据工程师 | LLM 数据工程师 |
 | :--- | :--- | :--- |
 | **核心技术栈** | SQL / Pandas / Spark ETL / BI 报表 | Ray Data / datatrove / MinHash / KenLM / LakeFS |
 | **数据体量经验** | GB ~ TB（结构化表格为主） | TB ~ PB（非结构化文本 / 代码 / 图文混排） |
@@ -186,124 +199,89 @@ Phi-1 何以四两拨千斤？论文名字揭示了核心方法——《Textbook
 | **合规意识** | 了解 GDPR 基础脱敏要求 | 需具备版权法律认知、PII 检测能力（NER + 正则）、robots.txt 合规观 |
 | **数据版本习惯** | 数据库 Schema 版本 / 定时快照备份 | 数据集 Git 化：LakeFS commit / DVC pipeline 追踪 |
 
-**新人 LLM 数据工程师 90 天能力成长路线图**
-
-```
-[第 1-30 天：夯实基础与工具链上手]
-  Week 1-2: 精读 FineWeb 与 RefinedWeb 论文, 理解大规模文本清洗的设计哲学
-  Week 3:   本地搭建 datatrove 或 Data-Juicer 环境, 跑通一个完整的 1GB 规模清洗 pipeline
-  Week 4:   学习 MinHash LSH 去重原理, 手写一个简单版 MinHash 实现 (≤ 100 行 Python)
-
-[第 31-60 天：深入核心并参与真实数据项目]
-  Week 5-6: 参与团队的实际数据清洗 PR, 贡献至少一条新的质量过滤规则
-  Week 7:   学习 LakeFS 或 DVC 的数据版本控制, 为现有项目的数据集添加版本追踪
-  Week 8:   独立完成一次数据消融实验: 对比两种去重阈值设置对小模型 PPL 的影响
-
-[第 61-90 天：建立体系化视角与交叉协作能力]
-  Week 9-10: 与算法团队一起解读 Loss 曲线异常, 找到至少一次由数据引发的问题根因
-  Week 11:   设计并维护一份团队层面的「数据质量评分卡」, 并做一次内部分享
-  Week 12:   完成一个从爬取 → 清洗 → 版本管理 → 消融验证的完整数据生命周期项目, 写出复盘文档
-```
+对于刚进入该方向的工程师，可以把能力建设拆成三个阶段：第一阶段掌握大规模文本清洗、MinHash 去重、PPL 过滤和基础工具链；第二阶段参与真实数据流水线，补齐 DVC、LakeFS、数据版本和质量评分卡能力；第三阶段与算法、标注、产品和合规团队协作，把数据变更与模型指标、业务反馈和审计记录关联起来。这样的路径比单纯学习某个工具更稳健，因为 LLM 数据工程的核心不是单点脚本，而是可追溯、可复盘、可持续迭代的数据系统。
 
 ---
 
 ## 1.4 全生命周期地图与十四篇制导读
 
-理解了上述范式变革后，我们需要有一个全局鸟瞰图来梳理大模型数据工程的广袤天地。本书以系统工程视角将知识结构分为“十四篇制”。
+理解上述范式变革后，需要用一个全局地图来定位大模型数据工程的主要问题域。本书以系统工程视角将知识结构组织为十四篇。
 
-![图：全书十四篇制生命周期地图](../../images/part1/data_lifecycle_map_1775830407042.png)
+![图1-2：全书十四篇制生命周期地图，展示从总论、预训练、多模态、对齐、应用、平台、合规到项目实战的知识结构](../../images/part1/data_lifecycle_map_1775830407042.png)
 
-*图1-2：全书十四篇制生命周期地图 —— 以基础设施为底座，穿插从预训练、多模态、大模型对齐再到项目落地的完整数据管线。*
+*图1-2：全书十四篇制生命周期地图。来源：本书自绘。该图以基础设施为底座，串联预训练、多模态、对齐、应用、平台治理、合规与项目实战。*
 
 
 ### 1.4.1 十四篇制如何覆盖各阶段痛点
-1. **基础篇（第1篇）**：即本篇，确立世界观与地基。解决的是“用什么基础设施能撑起 PB 级别并发处理的问题”。
-2. **语言理解内核（第2篇）**：文本预训练数据工程。这是模型地基的一环，包含爬虫、去重、清洗、分词、DataLoader 优化的主战场，**也是整书方法论的最核心基础**。
-3. **感官拓展（第3篇）**：多模态数据工程。纯文字不够描述现实，这里解决图文对、交织文本、长视频切片与 OCR 融合等非统一载体的困难。
-4. **人类意志与逻辑（第4-6篇）**：
-    * **第4篇（指令对齐）**讨论如何教会模型“听懂人话”且懂礼节，专注于构建优质微调 Prompt 和偏好排序。
-    * **第5篇（合成数据）**讲述人类语料枯竭后的解法——让大模型左脚踩右脚上天，用强模型生产无瑕疵的“幻化教科书”。
-    * **第6篇（Agent与推理）**关注 CoT 思维链构建与 Tool-Use 动作交互标注，让模型获得逻辑推理脑和执行手。
-5. **深入业务现场（第7篇）**：讲透 RAG 系统背后庞大的文档切片、向量嵌入与长下文检索技术，化解业务侧的幻觉困扰。
-6. **合规平台运营（第8、9篇）**：将手工作坊演变为现代化数据工厂，应对 DataOps 的版本追踪与审计，并在第 9 篇建立隐私数据防护的篱笆。
-7. **项目与开源实战（第13-14篇）**：用 10 个完整的项目流水线，串联从 0 构建 Mini-C4 到垂直领域 DataOps 系统搭建的全流程，并辅以实用附录速查。
+1. **第一篇（总论与基础设施）**：确立问题意识、质量语言与基础设施坐标。
+2. **第二篇（文本预训练数据工程）**：覆盖采集、清洗、去重、分词、序列化和高效加载。
+3. **第三篇（多模态数据工程）**：处理图文对、文档 OCR、视频音频和跨模态对齐。
+4. **第四至第六篇（对齐、合成与推理数据）**：
+    * **第四篇（指令微调与偏好数据）**讨论 SFT、偏好数据、奖励信号和标注 QA。
+    * **第五篇（合成数据工程）**讨论如何用强模型、规则验证和数据审计构建可控的合成数据工厂。
+    * **第六篇（推理与 Agent 数据工程）**关注 CoT、Tool-Use、Agent 记忆和多轮交互数据。
+5. **第七篇（应用级数据工程）**：讨论 RAG、多模态检索、在线反馈和知识更新。
+6. **第八至第十一篇（平台、资产与合规治理）**：覆盖 DataOps、数据版本、可观测性、数据资产、数据契约、隐私合规和联邦学习。
+7. **第十二至第十四篇（专项数据集、项目与开源实战）**：用专项数据集和项目流水线展示从数据集设计到工程落地的完整路径。
 
 ---
 
 ## 1.5 本书学习路径与后续章节承接
 
-面对这厚达千余页的数据工程体系，不同的角色应当有不同的探险路线图。在这里，我们按照"最快提升实际生产力"的原则，为不同背景的读者提供三条差异化的阅读路线。
+本书后续章节覆盖预训练数据、多模态数据、对齐数据、RAG 应用、平台治理、合规和项目实战。为避免篇幅在总论中过度展开，本节只给出三类读者的阅读优先级，具体工程细节将在相应章节中展开。
 
 ### 1.5.1 不同角色的阅读路径建议
 
-**路线 A：平台工程 / MLOps 导向（聚焦基础设施与效率）**
-
-如果你的日常工作是维护训练集群、优化数据管线吞吐、设计分布式存储方案，推荐如下顺序：
-1. **必读（精读）**：第1章 → 第2章（质量框架/评分卡工程化）→ 第3章（存储选型）→ 第8篇（DataOps）。
-2. **重点研读**：第2篇的分布式清洗与 DataLoader 优化节，直接影响 GPU 利用率和训练吞吐。
-3. **略读即可**：第4篇（SFT样本设计），了解下游需求即可，不需深入数据质量评估内部。
-4. **预期收益**：读完上述路径后，你应当能独立设计一套支持 PB 级数据并发清洗的 Ray 集群方案，并搭建出覆盖数据血缘追踪的 DataOps 监控系统。
-
-**路线 B：搜广推 / 传统机器学习背景转型者（跨越认知鸿沟）**
-
-如果你有数年传统机器学习或推荐系统经验，最大的障碍是从"结构化特征工程"思维跨越到"非结构化语义清洗"思维。推荐路径：
-1. **必须优先补课**：第1章 → 第2章（质量框架，特别是 PPL 和去重指标）→ 第2篇全部内容（预训练数据处理）。
-2. **迁移类比学习**：第4篇（SFT数据构建），其中的"正负样本区分"逻辑与推荐系统的点击正负样本非常类似，容易迁移；第7篇（RAG）的向量检索与你熟悉的 ANN 近似近邻搜索原理高度相同。
-3. **按需深入**：第5篇（合成数据），这对于习惯用真实用户行为数据的工程师来说是全新知识点，需要慢慢理解"蒸馏式合成"与传统数据增强的本质区别。
+**路线 A：平台工程 / MLOps 导向。** 平台工程师应优先阅读第1章至第3章，随后进入第二篇的分布式清洗与 DataLoader 优化内容，再系统阅读第八篇（DataOps 平台建设）和第九篇（数据资产与数据契约）。这一路线的目标是建立吞吐、版本、血缘和可观测性的基础设施视角。
 
-**路线 C：全栈 LLM Data 专家体系化成长路线（从业者深修版）**
+**路线 B：传统机器学习背景转型者。** 具有推荐系统、搜索排序或传统机器学习经验的读者，应在第一篇完成范式迁移后，重点阅读第二篇（文本预训练数据工程）和第四篇（指令微调与偏好数据）。这一路线有助于把结构化特征工程经验迁移到非结构化语义清洗、去重、污染检测和样本设计中。
 
-如果你的目标是成为团队中主导数据工程决策的核心专家，推荐按此顺序逐篇啃透：
-1. **基础层**：第1章（范式认知）→ 第2章（质量框架）→ 第3章（基础设施选型）
-2. **数据获取层**：第2篇（预训练文本）→ 第3篇（多模态数据工程）
-3. **价值对齐层**：第4篇（SFT指令微调）→ 第5篇（合成数据工厂）→ 第6篇（CoT与Agent工具链数据）
-4. **应用落地层**：第7篇（RAG应用级数据栈）
-5. **系统运营层**：第8篇（DataOps平台可观测性）→ 第9篇（隐私、合规与联邦学习）
-6. **实战验收层**：第10篇（十大工业级项目实战）→ 附录 A-F（速查手册）
+**路线 C：全栈 LLM Data 专家。** 需要主导数据工程决策的读者，可以按“第一篇基础框架 → 第二、三篇数据获取与处理 → 第四至第六篇对齐与推理数据 → 第七篇应用级数据工程 → 第八、九、十一篇平台与治理 → 第十三、十四篇项目实战”的顺序阅读。该路线强调从数据来源、质量评估、平台接口到合规审计的端到端能力。
 
-**表 1-6：各类型读者的章节优先级权重建议**
+**表 1-6：各类型读者的章节优先级建议（1=低，5=高）**
 
 | 篇章 | 平台/MLOps 工程师 | 转型机器学习工程师 | 全栈 LLM Data 专家 |
 | :--- | :---: | :---: | :---: |
-| 第1篇（本篇）范式与总纲 | ★★★★★ | ★★★★★ | ★★★★★ |
-| 第2篇 预训练文本数据 | ★★★★★ | ★★★★★ | ★★★★★ |
-| 第3篇 多模态数据 | ★★★☆☆ | ★★★☆☆ | ★★★★★ |
-| 第4篇 SFT 指令微调 | ★★☆☆☆ | ★★★★☆ | ★★★★★ |
-| 第5篇 合成数据工厂 | ★★☆☆☆ | ★★★☆☆ | ★★★★★ |
-| 第6篇 CoT 与 Agent 数据 | ★★☆☆☆ | ★★★☆☆ | ★★★★★ |
-| 第7篇 RAG 应用级数据栈 | ★★★☆☆ | ★★★★★ | ★★★★★ |
-| 第8篇 DataOps 平台 | ★★★★★ | ★★★☆☆ | ★★★★★ |
-| 第9篇 隐私与合规 | ★★★★☆ | ★★★☆☆ | ★★★★★ |
-| 第10篇 项目实战 | ★★★★☆ | ★★★★☆ | ★★★★★ |
+| 第一篇（本篇）范式与总纲 | 5 | 5 | 5 |
+| 第二篇 预训练文本数据 | 5 | 5 | 5 |
+| 第三篇 多模态数据 | 3 | 3 | 5 |
+| 第四篇 SFT 与偏好数据 | 2 | 4 | 5 |
+| 第五篇 合成数据工厂 | 2 | 3 | 5 |
+| 第六篇 CoT 与 Agent 数据 | 2 | 3 | 5 |
+| 第七篇 RAG 应用级数据栈 | 3 | 5 | 5 |
+| 第八篇 DataOps 平台 | 5 | 3 | 5 |
+| 第九篇 数据资产与数据契约 | 4 | 3 | 5 |
+| 第十一篇 隐私与合规 | 4 | 3 | 5 |
+| 第十三篇 项目实战 | 4 | 4 | 5 |
 
 ### 1.5.2 避免本位主义的常见误区
 
 在正式推开大门前，有三个特别容易被传统背景工程师触发的"本位主义误区"，必须提前规避：
 
-**误区一：只关注模型参数修改，忽视上游数据的异动。**
-当训练 Loss 发生抖动时，大多数工程师的第一反应是"调学习率、改优化器"。然而正确的排查顺序应该是反过来的：首先检查最近一轮是否有新批次数据接入，检查数据打乱（Shuffle）逻辑是否因为分布式节点数量变化而失效，或者检查数据长度打包（Packing）策略是否因为某批超长文本的混入而打破了原有分布。**数据优先于参数**，是 LLM 工程排障的第一原则。
+**误区一：只关注模型参数修改，忽视上游数据变化。**
+当训练 Loss 发生抖动时，常见反应是调整学习率或优化器参数。但在 LLM 工程中，应首先检查最近一轮是否有新批次数据接入，数据打乱（Shuffle）逻辑是否因分布式节点数量变化而失效，或数据长度打包（Packing）策略是否因某批超长文本混入而打破原有分布。**数据优先于参数**，是 LLM 工程排障的基本原则。
 
 **误区二：轻视数据版本与运营体系，认为数据是"一次写成，永远可用"的静态资产。**
-事实上，LLM 的训练数据集是一条持续回流的河流，而不是一个一次性锻造完成的铁块。版权法律可能随时要求你从已训练集中移除某个来源的语料（这在技术上称为 Machine Unlearning，复杂）；新的有效对抗 Prompt 被公开时，你需要立刻更新安全对齐数据；业务线上新增了一个垂直领域的需求，需要实时补充专域语料。没有一套严谨的数据质量评分机制和版本回滚能力，团队只会在临时打补丁的修补循环中疲于奔命，无法实现可持续的数据工程体系。
+事实上，LLM 的训练数据集是一类持续演进的资产，而不是一次性完成的静态文件。版权和合规要求可能要求团队移除某个来源的语料；新的对抗 Prompt 被公开后，安全对齐数据需要及时更新；业务新增垂直领域需求时，也需要补充专域语料。没有严谨的数据质量评分机制和版本回滚能力，团队很难形成可持续的数据工程体系。
 
 **误区三：将"合成数据"与"低质数据"画等号。**
-受早期 GAN 合成图像质量低劣的印象影响，许多工程师对合成数据抱有天然的不信任感。然而，现代大模型时代的合成数据（以强带弱的"知识蒸馏"范式）早已与过去的随机噪声增强不是一个概念。精心设计的 Prompt 与强大的 GPT-4o 或 Claude-3.5 配合，完全可以产出在逻辑严密性和覆盖场景多样性上超越人工标注的高价值样本。第五篇将完整展示合成数据工厂的最佳实践。
+受早期低质量合成样本的影响，许多工程师容易低估合成数据的价值。然而，现代大模型时代的合成数据，尤其是以强模型带弱模型的知识蒸馏范式，已经不同于简单随机增强。精心设计的 Prompt、强模型生成、规则验证和人工审计相结合，可以产出在逻辑严密性和场景覆盖度上具有较高价值的样本。第五篇将系统讨论合成数据工厂的工程实践。
 
 ### 1.5.3 承先启后：下一章我们探讨什么？
 
-如果说第一章是我们站在大坝最高处，俯瞰整条精心设计的人工智能"水系"，明确了"我们要建造怎样的数据生命周期系统并规划清晰的组织角色"，那么在真正动工浇筑每一堵墙体之前，我们必须立刻定义一个全链路所有人都认同的**工程验收标准**——即那把贯穿全书的"万用刻度尺"。
+第一章明确了大模型数据工程的基本问题、角色接口和全书地图。进入具体工程章节之前，还需要定义全链路共同认可的**工程验收标准**，即贯穿全书的数据质量语言。
 
-在下一章（**第2章：LLM数据生命周期与质量评估框架**）中，我们将系统建立大模型数据的"质量字典"：从统一的质量语言出发，逐一剖析预训练、SFT、RLHF、RAG 四大阶段各异的质量标准，并引入"数据发布评分卡（Data Release Scorecard）"这个工程化工具，让质量评估从感性判断升级为可量化、可触发自动拦截的工程闸门。而随后的第3章，我们将讨论究竟需要何种级别的"兵器库"（Ray + Apache Iceberg + S3 / MinIO 对象存储），才能支撑起这套庞大的数据质量治理体系的底层底座。
+在下一章（**第2章：LLM数据生命周期与质量评估框架**）中，我们将建立大模型数据的质量字典：从统一的质量语言出发，逐一分析预训练、SFT、RLHF、RAG 四个阶段的质量标准，并引入数据发布评分卡（Data Release Scorecard），使质量评估从经验判断升级为可量化、可触发自动拦截的工程闸门。随后的第3章将讨论 Ray、Apache Iceberg、S3 / MinIO 对象存储等基础设施如何支撑这套数据质量治理体系。
 
-只有确立了质量共识和底层平台基础，我们才能在第二篇浩如烟海的 Common Crawl 文本沼泽中，从容不迫、有的放矢地提炼出构建国际水准大模型所需的黄金预训练数据。
+只有确立质量共识和底层平台基础，第二篇关于 Common Crawl、网页文本、代码和专业语料的预训练数据工程才有稳定的执行坐标。
 
 ---
 
 **本章小结**
 
-本章以一个由于数据劣质导致模型崩溃的真实工程灾难开篇，论证了在 Scaling Laws 与 Chinchilla 法则的双重数学约束下，"**数据质量即模型智力的终极上限**"这一核心论断的严肃工程意义。我们完整解析了规模、质量、多样性三角之间的博弈与成本转移机制，用六行对比表格揭示了传统 AI 数据链路与大模型原生数据体系之间的认知断层，并深入剖解了为什么数据飞轮胜于单向数据传递。通过定义六大核心角色的精确职责边界与 SLA（含完整时序图），以及 LLM 数据工程师 90 天能力成长路线图，我们让这个看似宏大抽象的组织课题落地为了可操作的团队协议。最后，通过三条差异化的读者路线图与章节优先级权重表，确保了这本厚达千页的著作对不同经验层次的读者都具有平等的实用价值。
+本章以一个匿名化复合案例开篇，说明数据质量问题会在训练、评测和业务上线之间持续放大。随后，本章结合 Scaling Laws 与 Chinchilla 法则，论证数据规模、质量和多样性共同决定模型能力边界，并通过对比表格揭示传统 AI 数据链路与大模型原生数据体系之间的差异。最后，本章定义了六类核心角色、数据交接 SLA、数据飞轮和差异化阅读路径，为后续章节讨论质量框架、基础设施和具体数据流水线奠定基础。
 
-**数据工程不是简单的数据搬运，它已经是主导大模型智力演进轨迹的核心引擎。** 带着这一认知，让我们进入第2章，开始为整个体系建立统一的质量标准与治理语言。
+**数据工程不是简单的数据搬运，而是影响大模型能力边界、成本结构和风险治理的核心系统。** 带着这一认知，下一章将为整个体系建立统一的质量标准与治理语言。
 
 ---
 
diff --git a/docs/zh/part1/ch02_quality_framework.md b/docs/zh/part1/ch02_quality_framework.md
index c43ca9c2..177f0374 100644
--- a/docs/zh/part1/ch02_quality_framework.md
+++ b/docs/zh/part1/ch02_quality_framework.md
@@ -1,12 +1,25 @@
 # 第2章：LLM数据生命周期与质量评估框架
 
+## 摘要
+
+本章建立贯穿全书的数据质量评估框架。大模型项目中的“高质量数据”并不是单一指标，而是随训练阶段、任务目标和业务场景动态变化的多维约束。章节首先说明算法、数据、标注和产品团队为何会在质量定义上产生分歧，并提出以数据质量术语契约统一沟通。随后，本章按照预训练、指令微调、偏好对齐和 RAG 应用四个阶段，拆解质量目标、检测指标和典型风险；再从样本级、批次级、数据集级和系统平台级建立分层评估视角。最后，本章给出六类核心数据缺陷、数据发布评分卡、CI/CD 质量闸门和匿名化复合案例，说明如何把质量评估转化为可执行的治理动作、告警策略和回滚机制。
+
+**关键词**：数据质量评估；数据生命周期；数据评分卡；基准污染；数据治理；RAG 评估；DataOps
+
+**学习目标**
+
+- 建立跨团队一致的数据质量术语和指标语言。
+- 区分不同训练阶段的数据质量目标和评估方法。
+- 将常见数据缺陷映射为可检测、可阻断、可复盘的工程指标。
+- 设计数据发布评分卡、质量闸门和回滚流程。
+
 ## 2.1 为什么需要统一质量语言
 
-在大模型开发过程中，不同专业背景的团队往往在“什么是好数据”上存在巨大的沟通鸿沟。这种缺少统一“质量语言”的情况，正是造成许多 LLM 项目搁浅的核心原因。
+在大模型开发过程中，不同专业背景的团队往往在“什么是好数据”上存在显著认知差异。这种缺少统一“质量语言”的情况，是造成许多 LLM 项目延期、返工或模型效果不稳定的重要原因。
 
 ### 2.1.1 团队对"高质量数据"的误解来源
 
-在一个典型的大模型研发团队里，"高质量数据"对不同角色意味着截然不同的东西。以下是三个真实发生在联合评审会上的典型对话场景，它们揭示了这种认知断层的危险程度。
+在一个典型的大模型研发团队里，"高质量数据"对不同角色意味着截然不同的东西。以下三个匿名化复合场景综合了一线项目中常见的联合评审会分歧，用来说明这种认知断层的风险。
 
 **场景一：算法研究员 vs 数据工程师**
 
@@ -29,7 +42,7 @@
 
 问题根因：内部评测集的金融知识截止时间是上一年，而用户在线上问的是实时信息，**时效性（Staleness）**这个质量维度在内部评测中根本没被设计进去。
 
-三个场景的共同点是：每一方都没有"说谎"，每个人都在用自己理解的"质量"评判数据——但恰恰这种"各说各话"，造成了模型表现的系统性失误。
+三个场景的共同点是：每一方都基于自身职责理解“质量”，但这些局部定义没有形成共同指标体系，最终造成模型表现的系统性偏差。
 
 **落地方案：建立统一质量语言的 Workshop**
 
@@ -37,7 +50,7 @@
 
 其次，文档必须为不同训练阶段分别定义各自的合格线阈值：Pre-training 数据的合格线与 SFT 数据的合格线在量级和维度上都存在根本性差异，永远不能混用。更重要的是，文档应当建立起术语到代码的精确映射。例如当某一方说"重复率过高"时，全组所有人对这五个字的理解必须统一：它在工程上的含义是"MinHash Jaccard 相似度大于 0.8 的样本对在整批数据中占比超过 5%"，而不是各自凭感觉的"这批数据看起来好像有点重复"。
 
-这份契约文档并非一劳永逸的静态文件，而是随项目进展持续演进的活文档。在每一个重要的 milestone（例如新模型版本发布后）必须组织一次回顾，检查已有的指标定义在新阶段是否仍然适用，是否需要随业务场景的变化而扩展或调整。
+这份契约文档不是静态文件，而是随项目进展持续演进的版本化文档。在每一个重要的 milestone（例如新模型版本发布后）必须组织一次回顾，检查已有指标定义在新阶段是否仍然适用，是否需要随业务场景变化而扩展或调整。
 
 ### 2.1.2 生命周期视角下质量目标为何会动态变迁
 
@@ -52,13 +65,13 @@
 | **偏好对齐 (RLHF/DPO)** | 数万 ~ 数十万条偏好对 | 偏好差异显著性、价值观贴合度、无害性 | 标注一致性 Cohen's κ (Cohen 1960)；chosen/rejected 质量差距；毒性评分 | 标注员偏好不一致（κ < 0.6）；chosen/rejected 差距不够大（信号弱）；存在文化偏见 | 多轮 calibration；Reward Model 预筛；Perspective API (Lees et al. 2022) |
 | **RAG 应用落地** | 数千 ~ 数万篇文档 | 时效性、业务覆盖率、检索召回精度 | 知识截止时间分布；场景覆盖召回率；Faithfulness 评分 | 知识库陈旧（6个月未更新）；切片粒度太大导致召回噪声过高；PDF 解析乱码 | LlamaIndex / LangChain；RAGAs 评估框架；Embedding 质量评估 |
 
-从表格中可以清晰地看到：同样是"质量评估"，从预训练阶段的"去重率与 PPL 分布"到 RLHF 阶段的"标注一致性与偏好差距"，主要指标已经发生了根本性的切换。一个在预训练阶段的"合格"数据（流畅、无重复），放到 SFT 阶段可能因为不够精确而"不合格"。这种阶段性的质量目标迁移，要求数据工程团队必须建立**分阶段的质量合同（Phase-Specific Quality Contract）**，而不是一套打天下的万能通用标准。
+从表格中可以看到：同样是"质量评估"，从预训练阶段的"去重率与 PPL 分布"到 RLHF 阶段的"标注一致性与偏好差距"，主要指标已经发生切换。一个在预训练阶段合格的数据集，放到 SFT 阶段可能因为事实精度、格式合规或任务覆盖不足而不合格。这种阶段性的质量目标迁移，要求数据工程团队建立**分阶段的质量合同（Phase-Specific Quality Contract）**，而不是使用单一通用标准衡量所有阶段。
 
 
 ### 2.1.3 没有统一框架时的治理失效现象
 当缺乏统一的数据质量评估框架时，项目必然会出现“治理失效”。典型症状包括：
 
-1. **指标孤岛（Metric Silos）**：预训练团队用困惑度（PPL）为核心的脚本；微调团队用 ROUGE-L 衡量回复质量；安全团队用 Perspective API 的毒性分数作为合规指标——三套系统之间毫无公共语言。当某批数据同时触发三个团队的告警时，谁主导修复？各团队说"我看这批数据没问题"（各说各的），结果进入了三重相互扯皮的无效博弈。
+1. **指标孤岛（Metric Silos）**：预训练团队用困惑度（PPL）为核心脚本；微调团队用 ROUGE-L 衡量回复质量；安全团队用 Perspective API 的毒性分数作为合规指标。三套系统之间缺少公共语言。当某批数据同时触发多个团队的告警时，团队很难判断由谁主导修复，也难以确定哪个指标具有发布否决权。
 
 2. **噪音传导放大（Noise Propagation Amplification）**：没有统一框架时，上游数据管线的小噪声往往无法被早期拦截，沿着管线扩散放大，在下游产生成数量级的危害：
 
@@ -72,9 +85,9 @@
     【最终代价】    模型版本被迫回滚，损失 3 周训练算力与市场窗口期
     ```
 
-    这种"1% 上游错误 → 10% 中游异常 → 30% 下游损失"的指数放大效应，被称为**数据管线的"蝴蝶效应"**。它的根治方案，正是本章将要建立的统一质量闸门体系。
+    这种"1% 上游错误 → 10% 中游异常 → 30% 下游损失"的放大效应，可以理解为数据管线中的跨阶段误差传导。它的治理方案，是本章将要建立的统一质量闸门体系。
 
-3. **经验无法沉淀（Experience Loss）**：由于没有统一的缺陷分类标准，每次模型出问题后的复盘会议，结论永远是模糊的"数据太差了，下次要注意"。"太差"到底是因为重复率过高？还是领域配比失衡？还是基准污染？由于分类不清，这些教训无法转化为下一版清洗 pipeline 的具体规则修改，团队注定在同样的坑里反复栽跟头。引入统一质量框架后，每次数据问题都能归类到明确的缺陷类型（见2.3节），都有对应的修复算子和量化改进目标，复盘文档从"数据太差了"变成了"本次事故根因：重复率超标（MinHash相似度>0.8的样本占比从2.3%升至7.1%），修复方案：收紧阈值至0.7，下一版增量验证去重率复测"。
+3. **经验无法沉淀（Experience Loss）**：由于没有统一的缺陷分类标准，每次模型出问题后的复盘结论往往停留在"数据太差了，下次要注意"。"太差"到底是因为重复率过高、领域配比失衡，还是基准污染？由于分类不清，这些教训无法转化为下一版清洗 pipeline 的具体规则修改。引入统一质量框架后，每次数据问题都能归类到明确缺陷类型（见 2.3 节），并对应修复算子和量化改进目标。复盘文档应从"数据太差了"变为"本次事故根因：重复率超标（MinHash 相似度 > 0.8 的样本占比从 2.3% 升至 7.1%）；修复方案：收紧阈值至 0.7，下一版增量验证去重率复测"。
 
 
 ---
@@ -83,22 +96,22 @@
 
 要解决语言不统一的问题，我们必须在生命周期的各个阶段建立明确的“质量目标层级”。
 
-![图：生命周期视角下的多维度质量分层架构](../../images/part1/data_quality_hierarchy_1775835516841.png)
+![图2-1：生命周期视角下的多维度质量分层架构，展示不同阶段质量指标权重从规模、多样性转向真实性、帮助性](../../images/part1/data_quality_hierarchy_1775835516841.png)
 
-*图2-1：生命周期视角下的多维度质量分层架构 —— 展现从下到上各阶段对指标权重的迁移（从“规模/多样性”转移到精准的“真实性/帮助性”）。*
+*图2-1：生命周期视角下的多维度质量分层架构。来源：本书自绘。该图展现了不同阶段对指标权重的迁移，从规模、多样性逐步转向真实性、帮助性和可追溯性。*
 
 
-### 2.2.1 各阶段的目标差异与"接力跑"
+### 2.2.1 各阶段的目标差异
 
-如果把大模型的整个训练链路比作一场奥运接力赛，那么每一棒的运动员拿到接力棒时，都有着截然不同的战术目标——而不是所有人一律"跑快点"就行了。
+大模型训练链路中的每个阶段都有不同质量目标。预训练关注语料规模、多样性和低重复率；SFT 关注指令覆盖、格式合规和事实准确；偏好对齐关注对比信号和标注一致性；RAG 应用则关注知识时效、检索召回和证据可追溯性。
 
-**预训练（Pre-training）阶段**是第一棒，跑的是长跑。此时对语料的要求并不是每一句话绝对正确，而是规模足、多样好、无过拟合。这一阶段模型在以无监督的方式"见世面"，需要尽可能广地接触到各种领域、各种语言风格、各种知识边界，才能构建出对世界的基础认知图谱。在这一阶段，一篇事实略有过时的科普文章问题不大，但同一篇 SEO 广告文如果在语料库里复现了几千次，就会让模型形成极强的"复读"惯性，成为后续所有阶段都难以根治的顽疾。
+**预训练（Pre-training）阶段**是第一阶段，目标是建立广泛的语言、代码和知识表示。此时对语料的要求并不是每一句话绝对正确，而是规模足、多样性高、重复率低。这一阶段模型以无监督方式接触不同领域、语言风格和知识边界，构建基础表示能力。在这一阶段，一篇事实略有过时的科普文章通常不是主要风险，但同一篇 SEO 广告文如果在语料库里重复出现数千次，就会显著增加生成退化和记忆性过拟合风险。
 
-**指令微调（SFT）阶段**是第二棒，跑的是精准的短跑冲刺。这里的质量目标从"广度"骤然收窄至"精度"：指令的多样性、回复格式的合规性以及推理链条的完整性，缺一不可。一个关键的行业共识是，哪怕在整个 SFT 数据集中混入 100 条格式混乱或逻辑错误的样本，都足以在可观测层面损害一个 7B 模型在对应任务上的表现——SFT 阶段对污染的敏感度远高于预训练阶段，因为此时模型在"学动作"，而不是"见世面"。
+**指令微调（SFT）阶段**是第二阶段，质量目标从"广度"收窄至"精度"：指令的多样性、回复格式的合规性以及推理链条的完整性，缺一不可。SFT 阶段对污染的敏感度通常高于预训练阶段，因为此时模型学习的是任务格式和交互行为；少量格式混乱或逻辑错误的样本，也可能在对应任务上造成可观测的退化。
 
-**偏好对齐（RLHF/DPO）阶段**是第三棒，拼的是毫米级精度。这一阶段的核心质量目标是对比数据的有效性与价值观贴合度：chosen 答案必须和 rejected 答案之间有足够可分辨的质量差距 (Ouyang et al. 2022; Rafailov et al. 2023)，否则奖励信号将过于微弱，如同在嘈杂的环境中发出极轻的指令，模型根本无从学习人类真正的偏好方向。
+**偏好对齐（RLHF/DPO）阶段**是第三阶段，核心质量目标是对比数据的有效性与价值观贴合度：chosen 答案必须和 rejected 答案之间有足够可分辨的质量差距 (Ouyang et al. 2022; Rafailov et al. 2023)，否则奖励信号过弱，模型难以学习稳定的人类偏好方向。
 
-**RAG 应用落地阶段**是第四棒，也是最贴近用户的那一棒。这里的质量指标完全转向了时效性与检索精度：知识库中超过 6 个月未更新的文档比例、检索到的 Chunk 是否准确覆盖用户问题的真实意图，以及 PDF 与表格的解析是否存在字段错位——这些问题在前三个阶段根本不会出现，但在 RAG 落地阶段却是决定最终用户体感的核心变量。
+**RAG 应用落地阶段**是第四阶段，也是最贴近用户的一环。这里的质量指标转向时效性与检索精度：知识库中超过 6 个月未更新的文档比例、检索到的 Chunk 是否准确覆盖用户问题意图，以及 PDF 与表格解析是否存在字段错位。这些问题在前三个阶段并不总是显性出现，但在 RAG 场景中会直接影响最终回答质量。
 
 ### 2.2.2 离线、在线与业务质量的三角映射
 
@@ -111,15 +124,15 @@
 
 ### 2.2.3 切面分层：样本级到系统级
 
-质量评估还需要在"颗粒度"这个维度上做切面分层。不同粒度的质量问题，发现时机、修复成本和修复手段都截然不同，若混为一谈则容易造成"用大炮打蚊子"或"用弹弓打坦克"的错配。
+质量评估还需要在"颗粒度"这个维度上做切面分层。不同粒度的质量问题，发现时机、修复成本和修复手段都截然不同。若混为一谈，容易出现修复手段与问题层级不匹配的情况。
 
 最细粒度的是**样本级（Sample-level）**。这是数据管线中最早能检测的层级——这一条长文本是否包含 HTML 标签残余？这张图片与对应文字描述是否语义对齐？这个问答对中的答案是否与问题方向严重偏离？样本级问题量大但单条修复成本低，适合用自动化规则批量处理。
 
-往上一级是**批次级（Batch-level）**。这一粒度关注的是一批次数据的整体统计分布特征：这个批次的领域采样配比是否与预设的黄金比例产生了 10% 以上的偏移？代码语料与自然语言的比例是否因为某个爬虫配额失效而发生了骤变？批次级问题不会在单条样本上显现，只有在批次整体的统计画像上才能被发现，因此需要专门的滚动分布雷达来监控。
+往上一级是**批次级（Batch-level）**。这一粒度关注的是一批次数据的整体统计分布特征：这个批次的领域采样配比是否与预设基线产生了 10% 以上的偏移？代码语料与自然语言的比例是否因为某个爬虫配额失效而发生骤变？批次级问题不会在单条样本上显现，只有在批次整体的统计画像上才能被发现，因此需要专门的滚动分布监控。
 
 再往上是**数据集级（Dataset-level）**，关注的是整张训练集的宏观健康度：整个语料库的知识时间分布是否严重集中在某几年？有多大比例的内容在基准测试污染检测中被标记为高风险？各语种的比例是否符合多语言能力的训练需求？这一层级的问题是战略性的，通常由数据工程负责人在版本发布前以人工审查和报表复核的方式完成，而非依赖自动化流水线。
 
-最后是**系统平台级（System-level）**，即数据管线这个工程实体本身的运行健康状态：某条 Kafka 消费队列是否出现了积压？某个版本的 MinHash 去重任务是否因为内存 OOM 而静默地提前退出，留下了大量未处理的重复数据？这一层的问题不在数据内容本身，而在于数据管线的工程质量监控，属于 DataOps 可观测性的核心关注点（第8篇将深入展开）。
+最后是**系统平台级（System-level）**，即数据管线这个工程实体本身的运行健康状态：某条 Kafka 消费队列是否出现了积压？某个版本的 MinHash 去重任务是否因为内存 OOM 而静默地提前退出，留下了大量未处理的重复数据？这一层的问题不在数据内容本身，而在于数据管线的工程质量监控，属于 DataOps 可观测性的核心关注点（第八篇将深入展开）。
 
 ---
 
@@ -127,11 +140,11 @@
 
 要建立公共的治理动作，必须将那些模糊的“数据不好”翻译为具体、可测量的缺陷指标矩阵。
 
-![图2-2：大模型数据缺陷与质量指标交叉映射图](../../images/part1/defect_metric_radar_1775835533937.png)
+![图2-2：大模型数据缺陷与质量指标交叉映射图，展示六类缺陷与准确度、一致性、多样性、覆盖度和可追溯性之间的关系](../../images/part1/defect_metric_radar_1775835533937.png)
 
-*图2-2：大模型数据缺陷与质量指标交叉映射图 —— 展示六大核心缺陷类型（噪声、重复、基准污染、系统偏差、结构缺失、时效衰败）与五大核心质量指标（准确度、一致性、多样性、覆盖度、可追溯性）之间的影响关系网络。*
+*图2-2：大模型数据缺陷与质量指标交叉映射图。来源：本书自绘。该图展示六大核心缺陷类型（噪声、重复、基准污染、系统偏差、结构缺失、时效衰败）与五大核心质量指标（准确度、一致性、多样性、覆盖度、可追溯性）之间的影响关系网络。*
 
-### 2.3.1 六大核心缺陷分类 (The "Dirty Dozen" of LLM Data)
+### 2.3.1 六类核心数据缺陷 (Six Core Defect Classes)
 
 针对大模型训练，我们建立了如下六大核心缺陷维度，每种缺陷均配有自动化检测方案：
 
@@ -156,6 +169,8 @@ def noise_score(text: str) -> float:
 # 过滤阈值: noise_score > 0.1 则丢弃
 ```
 
+*代码清单2-1：文本噪声比例检测示例。生产环境中应补充语言、编码、HTML 解析器版本和异常样本抽检日志。*
+
 **2. 恶性重复 (Repetition)**
 
 定义：同一内容（精确或近似）在训练集重复出现大量次数，模型被迫"背诵"这些片段，引起记忆性过拟合，推理时变成"复读机"。工业界一般用 MinHash LSH 进行近似去重。
@@ -174,6 +189,8 @@ def build_minhash(text: str, num_perm: int = 128) -> MinHash:
 lsh = MinHashLSH(threshold=0.8, num_perm=128)
 ```
 
+*代码清单2-2：基于 MinHash LSH 的近似重复检测示例。生产环境中应记录阈值、分片策略和抽样复核结果。*
+
 **3. 基准污染 (Benchmark Contamination)**
 
 定义：爬虫不加筛选地将各类公开 AI 评测题库（GSM8K、HumanEval、MMLU 等）的原题及解答一并抓入预训练集，模型在基准测试上得分虚高（机械背诵而非推理）。
@@ -194,6 +211,8 @@ def ngram_overlap(text: str, benchmark_ngrams: set, n: int = 13) -> float:
 # 建议阈值: 13-gram 重叠率 > 0.1 则标记为疑似污染并人工复核
 ```
 
+*代码清单2-3：基准污染 N-gram 重叠检测示例。生产环境中应维护独立的评测集指纹库和人工复核流程。*
+
 **4. 系统偏差 (Bias)**
 
 定义：由于数据抓取站点地域、语言或话题侧重，导致数据存在国别、性别、种族、意识形态等系统性知识偏见，模型在特定群体相关任务上表现失衡。
@@ -219,6 +238,8 @@ def check_completeness(sample: dict) -> list:
     return issues
 ```
 
+*代码清单2-4：SFT 样本结构完整性检测示例。生产环境中应按任务类型补充 schema 校验、字段长度分布和抽样复核规则。*
+
 **6. 时效衰败 (Staleness)**
 
 定义：知识库或预训练语料停留在某一时间截止点，无法回应截止日期之后发生的事实性变化。这在 RAG 应用场景中尤为致命。
@@ -239,7 +260,7 @@ def staleness_ratio(docs: list, threshold_days: int = 180) -> float:
 # 建议: staleness_ratio > 0.3 时触发知识库更新任务
 ```
 
-
+*代码清单2-5：知识库时效衰败检测示例。生产环境中应按领域、数据源和业务优先级设置不同阈值。*
 
 ### 2.3.2 建立核心指标矩阵
 为了将缺陷定量化，书中统一采用五大考核指标：
@@ -260,15 +281,15 @@ def staleness_ratio(docs: list, threshold_days: int = 180) -> float:
 
 质量评估框架最终必须落地为具体的工程化自动闸门。我们通过设立“数据发布评分卡（Data Release Scorecard）”建立闭环。
 
-![图：数据评分卡驱动的自动截断与治理流](../../images/part1/data_quality_gates_1775835548587.png)
+![图2-3：数据评分卡驱动的自动截断与治理流，展示硬闸门、软闸门、人工复核和回滚动作](../../images/part1/data_quality_gates_1775835548587.png)
 
-*图2-3：数据评分卡驱动的自动截断与治理流 —— 类似工业化自动化品控线，利用硬闸门和软闸门阻隔被污染或劣化的数据样本。*
+*图2-3：数据评分卡驱动的自动截断与治理流。来源：本书自绘。该图展示硬闸门、软闸门、人工复核和回滚动作如何共同阻隔被污染或劣化的数据样本。*
 
 ### 2.4.1 数据评分卡的设计与落地
 
 评分卡是由一套规则脚本和校验模型综合得出的"数据体检报告"。其核心设计原则是：**客观可重复计算、阈值基线配置化、面向动作拦截**。在正式发布任意版本的训练数据集之前，评分卡脚本必须被强制触发，并将评估结果序列化为标准 JSON 格式存档。
 
-**完整评分卡 JSON 示例（SFT 数据集）**
+**代码清单2-6：SFT 数据集发布评分卡 JSON 示例**
 
 ```json
 {
@@ -321,7 +342,7 @@ def staleness_ratio(docs: list, threshold_days: int = 180) -> float:
 }
 ```
 
-**与 CI/CD 流水线集成（GitHub Actions 示例）**
+**代码清单2-7：与 CI/CD 流水线集成的 GitHub Actions 示例**
 
 ```yaml
 # .github/workflows/data_quality_gate.yml
@@ -354,10 +375,10 @@ jobs:
           print(d['gate_decision'])
           ")
           if [ "$DECISION" != "APPROVED_FOR_TRAINING" ]; then
-            echo "❌ Data quality gate FAILED: $DECISION"
+            echo "Data quality gate FAILED: $DECISION"
             exit 1
           fi
-          echo "✅ Data quality gate PASSED"
+          echo "Data quality gate PASSED"
 
       - name: Upload Scorecard Report
         uses: actions/upload-artifact@v3
@@ -377,23 +398,23 @@ jobs:
 一旦事后监控发现线上模型退化严重（由于数据引发），DataOps 平台应该支持**一键回退到上一个“清洁”的数据指针组合**。
 
 ### 2.4.3 将告警转化为修复动作
-发现分数低下后如何修复？我们采取标准化排坑预案。若是污染率告警，则立刻启动 N-gram 反向过滤剔除作业；若是格式校验（如某批次数据缺失字段），则阻挡导入并定位到原始爬虫解析脚本节点，重新剥离 ETL 字段。只有让告警直接驱动对应的清洗算子，治理才能形成闭环体系。
+发现分数异常后，需要将告警映射为标准化修复动作。若是污染率告警，则启动 N-gram 反向过滤剔除作业；若是格式校验失败（如某批次数据缺失字段），则阻断导入并定位到原始爬虫解析脚本节点，重新抽取 ETL 字段。只有让告警直接驱动对应的清洗算子，治理才能形成闭环体系。
 
 ---
 
-## 2.5 真实世界的跨阶段传导放大案例
+## 2.5 跨阶段传导放大案例
 
-为了加深理解这种“牵一发而动全身”的数据质量传导机制，我们复盘两个经典的真实案例。
+为了加深理解这种“牵一发而动全身”的数据质量传导机制，本节复盘两个匿名化复合案例。案例中的时间线和指标用于说明排障逻辑，不代表某一公开项目的完整事件记录。
 
 ### 2.5.1 案例回放一：预训练语料的“隐性语法漂移”
 2023年某开源模型发布后，发现随着步数增长，生成代码的能力不仅没有提升，反而开始退化甚至带入罕见的奇怪空白符。
 **溯源分析**：团队追溯上一批数据接入，发现在进行语言识别清洗时，某些 HTML 格式过滤器的包被升级了，原本正常跳过的 `<pre>` 代码标签引发了解析失效，导致大量带特殊空格缩进的网页源码在最后 1T 数据中占比突然升高了 4倍（这是质量指标中“一致性”未设置基线检查导致的失重）。模型在长期训练中无声无息地发生了“分布漂移”。
 **教训与复盘**：在批次级（Batch-level）中，缺乏长周期的静态分布平稳性监控，这迫使该团队后来搭建了一套滚动 N-gram 分布雷达。
 
-### 2.5.2 案例回放二：RAG 场景下的“离线高分，上线溃败”
+### 2.5.2 案例回放二：RAG 场景下的“离线高分，线上失效”
 金融知识问答模型在使用某批次私有研报 SFT 训练后，在离线评估集上的 Rouge/Bleu 得分远超基线模型。然而业务部门上线后反馈，模型在遇到长尾公司研报时，频繁编造数据（严重幻觉）。
-**溯源分析**：SFT 训练时使用的研报问答对（由低级大模型生成），虽然格式漂亮（SFT 阶段的多样性/格式表现佳），但是抽检发现由于表格拆分解析错误，大量财务数字错位。模型由于离线评估集同样是被这个低级流程造出来的，实现了“用作弊数据集考到满分”。
-**教训与复盘**：这个严重的幻觉漏洞说明“自己考自己”、“离线上线指标割裂”危险。在这一版后，公司强制引入了**独立金标准评估集（Gold Standard Set）由人类专家手写，坚决不参与任何模型合成或生成链路，以作最后的试金石**。
+**溯源分析**：SFT 训练时使用的研报问答对由弱模型生成，格式较整齐，但抽检发现由于表格拆分解析错误，大量财务数字错位。离线评估集也由同一流程生成，因此评估数据与训练数据共享同一类解析错误，导致 Rouge/Bleu 得分高估了真实能力。
+**教训与复盘**：这个案例说明，自引用评估和离线上线指标割裂会显著放大风险。在这一版后，团队引入了**独立金标准评估集（Gold Standard Set）**，由人类专家独立编写，不参与任何模型合成或生成链路，并作为上线前的否决性评估集。
 
 **完整排障时间线（案例一）**
 
@@ -420,16 +441,18 @@ def detect_tab_drift(prev_texts, curr_texts, z_threshold=2.0):
     return {"prev": prev_r, "curr": curr_r, "change": change, "alert": change > z_threshold}
 ```
 
+*代码清单2-8：批次级缩进字符漂移检测示例。生产环境中应将告警阈值改为基于历史分布的统计阈值。*
+
 **完整排障时间线（案例二）**
 
 - **T+0 天**：上线 6 小时内，多位用户反映财报数据与官网不符（相差约 20%）
 - **T+1 天**：运营团队复核 50 个幻觉 case，全部涉及表格数据（营收、EPS 等）
-- **T+2 天**：数据团队抽检 200 条含财务表格样本，发现 **34% 的财务数字发生了错位**！根因：弱模型解析多列 PDF 表格时列与列之间数字发生错误行对齐
-- **T+3 天**：进一步发现离线评估集也是由同一套弱模型生成的，即"用作弊数据集考满分"——ROUGE-L 0.63 完全不可信
+- **T+2 天**：数据团队抽检 200 条含财务表格样本，发现 **34% 的财务数字发生错位**。根因是弱模型解析多列 PDF 表格时，列与列之间数字发生错误行对齐。
+- **T+3 天**：进一步发现离线评估集也是由同一套弱模型生成的，ROUGE-L 0.63 高估了系统真实能力。
 - **T+5 天**：应急处理：停止弱模型自动生成财务类 QA，改为人工标注；对含财务数字的 RAG Chunk 增加人工复核标记
-- **T+14 天**：引入独立金标准评估集（600 条，100% 人工手写）。修复后 ROUGE-L 为 **0.49**（下降！这才是真实水平），但系统幻觉率从 **34% 降至 4.7%**，用户投诉清零
+- **T+14 天**：引入独立金标准评估集（600 条，100% 人工编写）。修复后 ROUGE-L 为 **0.49**，但系统幻觉率从 **34% 降至 4.7%**，用户投诉显著减少。
 
-**核心教训**：**自引用评估（Self-referential Evaluation）** 是最危险的陷阱。强制引入独立金标准评估集，要求：(1) 人类专家独立手写；(2) 与训练数据管线完全物理隔离；(3) 每次数据集迭代发布后，金标准集结果必须列入评分卡作为上线的否决权指标。
+**核心教训**：**自引用评估（Self-referential Evaluation）** 是 RAG 与合成数据场景中的高风险问题。独立金标准评估集应满足三项要求：(1) 人类专家独立编写；(2) 与训练数据管线物理隔离；(3) 每次数据集迭代发布后，金标准集结果必须列入评分卡，作为上线否决指标。
 
 
 ---
@@ -438,9 +461,9 @@ def detect_tab_drift(prev_texts, curr_texts, z_threshold=2.0):
 
 本书从本章节起，正式确立了适用于贯穿数百页的各种工程化手段的“公共契约”。
 
-*   **对于第二编（预训练）和第三编（多模态）**：第五章与第九章构建的庞大清洗代码，其截断阈值和过滤基线，正是来源于本章定下的“信噪比与一致性”底线原则组合。
-*   **对于第四编（微调与对齐）**：这里的指标矩阵将在第 12、13 章衍生为自动化数据合成时的 Reward 模型打分体系底座。
-*   **为了支撑第八编（DataOps 平台）**：平台上的告警大屏，其所有面板的图表展现的正是本章探讨的核心指标库与可回滚概念。
+*   **对于第二篇（文本预训练）和第三篇（多模态）**：清洗、去重、解析和对齐中的阈值与过滤基线，正是来源于本章定下的“信噪比与一致性”底线原则组合。
+*   **对于第四篇（指令微调与偏好数据）和第五篇（合成数据）**：这里的指标矩阵将在 SFT 数据设计、偏好数据构造和合成数据审计中转化为 Reward 模型打分、规则验证和人工复核依据。
+*   **为了支撑第八篇（DataOps 平台）**：平台上的告警大屏和质量看板，其核心图表展现的正是本章探讨的指标库、闸门状态和可回滚数据版本。
 
 所以，这是一本"全书通用"的 Checklist。在推进到每一个特定阶段的执行动作前，首先确保整个团队已经在这些术语上完成了"认知对齐"。带着本章这套系统的度量尺，现在，让我们在下一章走进真正能实现和支撑这些度量动作的基础工程——**AI 原生的现代数据基础设施**。
 
@@ -448,13 +471,13 @@ def detect_tab_drift(prev_texts, curr_texts, z_threshold=2.0):
 
 **本章小结**
 
-本章系统性地建立了贯穿全书的"数据质量公共契约"。我们从三个真实的跨角色撕扯对话场景出发，剖析了为何不同专业背景的团队在"高质量数据"上始终存在认知断层——这绝非个人问题，而是缺乏统一质量框架的必然结构性结果。
+本章系统性地建立了贯穿全书的"数据质量公共契约"。我们从三个匿名化复合对话场景出发，剖析了为何不同专业背景的团队在"高质量数据"上始终存在认知断层——这绝非个人问题，而是缺乏统一质量框架的必然结构性结果。
 
 通过四阶段质量目标演变矩阵，我们揭示了质量标准不是静态的，而是随训练生命周期动态迁移的：预训练阶段追求规模与多样性，SFT 阶段追求精确与格式合规，RLHF 阶段追求偏好差异显著性，RAG 阶段追求时效性与检索召回。用一套固定的标准衡量所有阶段，必然导致误判。
 
 六大核心缺陷分类（噪声、重复、基准污染、系统偏差、结构缺失、时效衰败）为团队提供了将模糊的"数据不好"翻译为可测量、可操作指标的公共语言，并为每种缺陷附上了可直接运行的 Python 检测代码。
 
-数据发布评分卡（含完整 JSON 示例）和 GitHub Actions CI/CD 集成方案，将质量评估从人工感性判断升级为可自动触发阻断的工程闸门。两个深度复盘案例（语法漂移与自引用评估）则通过真实的 T+N 天时间线，揭示了数据问题在管线中指数放大的蝴蝶效应，以及独立金标准评估集的不可替代价值。
+数据发布评分卡（含完整 JSON 示例）和 GitHub Actions CI/CD 集成方案，将质量评估从人工感性判断升级为可自动触发阻断的工程闸门。两个深度复盘案例（语法漂移与自引用评估）则通过 T+N 天时间线，揭示了数据问题在管线中的跨阶段放大机制，以及独立金标准评估集的不可替代价值。
 
 带着这套质量度量体系，我们已经为整本书的工程内容奠定了坚实的治理基础。
 
diff --git a/docs/zh/part1/ch03_data_stack.md b/docs/zh/part1/ch03_data_stack.md
index b0f94b08..c7e3aa75 100644
--- a/docs/zh/part1/ch03_data_stack.md
+++ b/docs/zh/part1/ch03_data_stack.md
@@ -1,12 +1,25 @@
 # 第3章 AI原生数据栈与成本治理
 
-## 开篇场景：数据平台的"野蛮生长"之痛
+## 摘要
 
-你刚以数据负责人的身份加入一家完成 B 轮融资的大模型创业公司。接手后的第一周，你做了一次数据基础设施的全面摸底，结论令人头皮发麻：语料数据零散地分布在 50 多台工程师的本地硬盘上，格式五花八门——`.txt`、`.json`、`.csv`、`.parquet` 混用，没有任何统一规范；每次需要处理新的数据，都靠一名工程师手工编写 Python 脚本在单机上跑，一份 500GB 的文件跑三天是常态；三个月前有人因为文件路径搞错，把一个关键的高质量 SFT 数据集覆盖掉了，而这份数据没有任何备份和版本记录。CEO 问你：一个月后公司计划开始第一轮 7B 模型的预训练，数据平台能不能 ready？
+本章讨论支撑大模型数据工程的 AI 原生数据栈与成本治理方法。与传统数仓主要服务分析查询不同，LLM 数据栈的目标是稳定、低成本地向训练和应用链路提供可追溯、可评估、可版本化的数据资产。章节首先比较传统数据仓库与大模型数据栈在目标、工作负载和成本约束上的差异；随后将数据栈拆解为采集接入、处理编排、存储索引、评测运营和治理安全五个层级，并讨论 Spark、Ray Data、Iceberg、对象存储、向量数据库、DVC 与 MLflow 等工具的适用边界。最后，本章给出成本模型、ROI 决策框架和三类团队架构方案，帮助读者在初创、中型和大型组织中选择与阶段匹配的数据基础设施。
 
-这个场景并非夸张的极端案例。在大量快速成立的大模型团队中，这种状态在早期几乎是普遍现象——因为算法和模型架构是团队最优先关注的焦点，数据基础设施往往被视为"能凑合就行"的配角，直到某次关键数据丢失、训练集群因为数据 I/O 成为瓶颈，或因为合规审计发现训练数据来源不清，才被迫进行紧急的基础设施建设。
+**关键词**：AI 原生数据栈；数据基础设施；Ray Data；Apache Iceberg；对象存储；成本治理；DataOps
 
-而这，恰恰是最昂贵的建设方式。因为在这种情况下，数据工程师不是在构建平台，而是在救火。
+**学习目标**
+
+- 区分传统数仓与 LLM 数据栈在目标和工作负载上的差异。
+- 理解 AI 原生数据栈的五层架构及其关键接口。
+- 掌握数据处理、存储、标注、推理服务和训练 I/O 的成本构成。
+- 根据团队规模选择轻量栈、平台化栈或多租户数据平台方案。
+
+## 开篇场景：数据平台缺少治理时的风险
+
+你刚以数据负责人的身份加入一家完成 B 轮融资的大模型创业公司。接手后的第一周，你做了一次数据基础设施的全面摸底，发现语料数据零散地分布在 50 多台工程师的本地硬盘上，格式包括 `.txt`、`.json`、`.csv`、`.parquet`，缺少统一规范；每次处理新数据，都由工程师手工编写 Python 脚本在单机上运行，一份 500GB 文件跑三天是常态；三个月前还曾因为文件路径错误覆盖了关键 SFT 数据集，而这份数据没有备份和版本记录。CEO 问你：一个月后公司计划开始第一轮 7B 模型预训练，数据平台能否支撑？
+
+这个场景并非夸张的极端案例。在许多快速成立的大模型团队中，这种状态在早期较为常见：算法和模型架构通常是团队最优先关注的焦点，数据基础设施则容易被视为短期可延后的工作，直到关键数据丢失、训练集群因数据 I/O 成为瓶颈，或合规审计发现训练数据来源不清，团队才被迫进行紧急基础设施建设。
+
+这种被动建设方式成本较高，因为团队需要在业务压力、训练窗口和合规风险同时存在的条件下补齐平台能力。
 
 ## 3.1 AI 原生数据栈为什么不同于传统数仓
 
@@ -14,11 +27,11 @@
 
 然而，当你把这套体系原封不动地搬到大语言模型的数据工程场景时，你会发现它在几乎每一个关键维度上都存在严重的不匹配。
 
-### 3.1.1 目标根本不同：从"分析"到"喂养"
+### 3.1.1 目标根本不同：从"分析查询"到"训练供给"
 
 传统数据仓库服务的核心目标是**分析与洞察**：把业务数据汇聚起来，通过 SQL 查询和 BI 工具，帮助业务决策者回答"过去发生了什么"和"现在的业务状态如何"。在这个目标下，数据的核心价值体现在**可查询性**（Query Performance）和**一致性**（Consistency）上：数据必须准确、结构整齐、可以被快速JOIN和聚合。
 
-LLM 数据栈服务于截然不同的核心目标：**训练一个神经网络模型**。数据的最终消费者不是人，而是 GPU 上运行的 Attention 计算。在这个目标下，数据的核心价值体现在**训练效率**（Training Throughput）和**质量信噪比**（Signal-to-Noise Ratio）上：GPU 的利用率必须保持在 85% 以上（否则花费数百万的算力成本就是在空转），而数据中的每一个 Token 都必须经过精心筛选，确保不会让模型学到错误的知识或低质量的语言模式。
+LLM 数据栈服务于截然不同的核心目标：**训练一个神经网络模型**。数据的最终消费者不是人，而是 GPU 上运行的 Attention 计算。在这个目标下，数据的核心价值体现在**训练效率**（Training Throughput）和**质量信噪比**（Signal-to-Noise Ratio）上：GPU 利用率需要保持在较高水平，数据中的 Token 也需要经过筛选，以降低模型学习错误知识或低质量语言模式的风险。
 
 这种目标的差异，直接导致了两套体系在技术选型上的全面分叉。
 
@@ -30,21 +43,21 @@ LLM 数据栈的工作负载有着截然不同的特征结构：
 
 **预训练数据处理**是整个体系最重的工作负载。数十 TB 到 PB 级别的原始语料需要经过去重、过滤、格式转换和分词等多道串行处理，每一步都是 CPU 密集型操作，需要在数千个核心上并行执行，才能在合理的时间窗口内完成。这类工作负载要求计算层能够高效调度和追踪数以亿计的文件/文档级任务。
 
-**与 GPU 训练的 I/O 对齐**是另一个关键约束。模型训练期间，DataLoader 需要以極高的频率（每 step）向 GPU 喂入数据，任何 I/O 等待都会导致 GPU 空转，直接燃烧算力预算。因此存储层必须具备能够匹配 GPU 训练带宽需求的读取速度，这对对象存储的访问模式（顺序大文件 vs 随机小文件）和网络带宽（InfiniBand / 100GbE 以太网）都有严格的要求。
+**与 GPU 训练的 I/O 对齐**是另一个关键约束。模型训练期间，DataLoader 需要以很高频率（每 step）向 GPU 提供数据，任何 I/O 等待都会导致 GPU 空转并增加算力成本。因此存储层必须具备能够匹配 GPU 训练带宽需求的读取速度，这对对象存储的访问模式（顺序大文件 vs 随机小文件）和网络带宽（InfiniBand / 100GbE 以太网）都有严格要求。
 
-**在线推理与实时反馈的并存**进一步加剧了系统复杂度。当模型上线运行推理业务时，用户的真实交互数据（包括对话记录、满意度反馈、有价值的纠错案例）需要实时回流，经过清洗和标注，进入 SFT 或 RLHF 数据管线。这意味着数据栈必须同时支持离线批处理（预训练语料清洗）和低延迟在线写入（用户反馈回流），这两种工作负载对存储和计算层的要求完全不同，在一套系统中同时支持两者，本身就是一个巨大的架构挑战。
+**在线推理与实时反馈的并存**进一步增加了系统复杂度。当模型上线运行推理业务时，用户交互数据（包括对话记录、满意度反馈、有价值的纠错案例）需要回流，经过清洗和标注后进入 SFT 或 RLHF 数据管线。这意味着数据栈必须同时支持离线批处理（预训练语料清洗）和低延迟在线写入（用户反馈回流）。这两种工作负载对存储和计算层的要求不同，需要在系统设计阶段明确隔离与协同方式。
 
 ### 3.1.3 成本约束的多维交织
 
 在传统 BI 体系中，成本主要体现在**存储成本**和**查询计算成本**上。而在 LLM 数据体系中，四类成本形成了复杂的多维约束：
 
-首先是**算力成本**（GPU/TPU 训练集群）。一块 H100 GPU 的租用价格约为每小时 3-4 美元，8 卡 DGX 节点约 25-30 美元/小时，一次 7B 模型的预训练往往需要持续数百小时，总算力成本轻松突破百万人民币量级。这意味着任何由于数据问题造成的训练中断或重启，代价都是昂贵的——这是 LLM 数据栈必须以"不允许训练失败"为最高设计准则的根本原因。
+首先是**算力成本**（GPU/TPU 训练集群）。截至 2026-06，公有云或租赁市场上一块 H100 GPU 的小时价格常见估算区间约为 3-4 美元，8 卡节点约为 25-30 美元/小时，实际价格会随地域、合约、供需和云厂商折扣变化。一次 7B 模型预训练往往需要持续数百小时，总算力成本可能达到百万人民币量级。这意味着任何由于数据问题造成的训练中断或重启，代价都很高，也是 LLM 数据栈必须强调稳定性和可回滚性的根本原因。
 
 其次是**数据处理成本**。PB 级的语料清洗任务在 CPU 集群上运行，每次完整的预处理管线可能需要数十万核心小时的计算，这在公有云上的费用可达数万至数十万美元。如何通过精细调度（如使用 Spot 实例）和算法优化（如 MinHash (Broder 1997) 近似去重替代精确去重）来降低单次处理成本，是工程化必须考量的核心命题。
 
 第三是**标注与人工成本**。高质量的 SFT 样本需要具备专业背景的标注员手工撰写，月人均产能仅约 500-2000 条高质量样本，而一个中等规模的 SFT 项目往往需要数十万条样本，这意味着标注成本很容易成为整个数据工程预算中占比最高的单项。
 
-最后是**存储成本**。PB 级别的温热数据存储在对象存储上，即使是最便宜的 S3 Standard 层也约为 \$0.023/GB/月，100PB 的数据每月存储费用约为 235 万美元，而仅一次预训练所需的数据量就可能达到数十 PB。如何在数据的全生命周期内合理规划冷热分层（Hot / Warm / Cold），避免为已不再使用的历史数据支付高额的活跃层存储费用，是成本治理的重要课题（将在 §3.3 深入展开）。
+最后是**存储成本**。截至 2026-06，S3 Standard 等活跃对象存储的公开标价常见量级约为 \$0.023/GB/月，不同云厂商、区域、折扣和访问模式会导致实际费用差异。按这一量级估算，100PB 温热数据每月存储费用约为数百万美元。如何在数据的全生命周期内合理规划冷热分层（Hot / Warm / Cold），避免为已不再使用的历史数据支付高额活跃层存储费用，是成本治理的重要课题（将在 §3.3 深入展开）。
 
 ---
 
@@ -52,9 +65,9 @@ LLM 数据栈的工作负载有着截然不同的特征结构：
 
 在明确了 AI 原生数据栈与传统数仓的本质差异之后，我们可以开始系统性地建立这套体系的架构蓝图。一套完整的 LLM 数据栈，从底到顶可以拆解为五个功能层级，每一层都有其核心职责和关键的技术选型决策。
 
-![图3-1：AI原生数据栈五层架构](../../images/part1/ai_data_stack_architecture.png)
+![图3-1：AI原生数据栈五层架构，展示采集接入、处理编排、存储索引、评测运营和治理安全层之间的数据流](../../images/part1/ai_data_stack_architecture.png)
 
-*图3-1：AI 原生数据栈五层架构 —— 从底层治理安全到顶层采集接入，五层协同驱动数据从原始爬取语料流向可训练的高质量数据集，右侧箭头标注了整体数据流向。*
+*图3-1：AI 原生数据栈五层架构。来源：本书自绘。该图展示采集接入、处理编排、存储索引、评测运营和治理安全层如何协同驱动数据从原始语料流向可训练数据集。*
 
 
 
@@ -94,6 +107,8 @@ def register_ingestion(record: DataIngestionRecord, metadata_db_path: str):
         f.write(json.dumps(record_dict, ensure_ascii=False) + '\n')
 ```
 
+*代码清单3-1：数据接入元数据登记示例。生产环境中应写入事务型元数据库，并补充权限、审计和幂等控制。*
+
 ### 3.2.2 处理编排层：数据工厂的流水线调度中枢
 
 数据进入平台后，需要经历一系列串行的处理步骤，才能从原始的"毛坯数据"转化为可以直接送入训练的"精加工数据"。这些处理步骤通常包括：HTML 标签剥离与文本提取、语言识别与过滤、基于规则的噪声过滤（去除 URL 密集、广告语段等低质文本）、近似去重（MinHash LSH）、精确去重（精确匹配）、质量评分（PPL 打分或基于分类器的质量筛选）、以及最终的分词序列化。
@@ -111,7 +126,7 @@ def register_ingestion(record: DataIngestionRecord, metadata_db_path: str):
 | **GPU 计算支持** | 需借助 NVIDIA RAPIDS 插件（cuDF/cuML），集成较复杂 | 原生支持 GPU 调度，可直接在算子中调用 CUDA 算子或部署 ML 模型 |
 | **内存使用模式** | 算子之间必须物化中间结果到磁盘/内存，内存压力较大 | 流水线执行，上下游算子可以重叠运行，内存效率更高 |
 | **SQL 与 BI 生态** | Spark SQL 极为成熟，兼容 Hive 元数据，生态完整 | SQL 支持较弱，没有成熟的 SQL 查询接口 |
-| **容错与稳定性** | 经过十余年 PB 级生产验证，稳定性极高 | 相对年轻，大规模部署的最佳实践积累少于 Spark |
+| **容错与稳定性** | 经过十余年 PB 级生产验证，稳定性成熟 | 相对年轻，大规模部署的最佳实践积累少于 Spark |
 | **典型代码风格** | 函数式（map/filter/groupBy 的链式调用） | 声明式 pipeline（`ds.map_batches()` 的链式拓扑） |
 
 选择哪一个，取决于团队背景和工作负载特征。如果团队具备传统大数据背景，且数据处理管线中有大量 SQL 逻辑和对 Hive/Iceberg 的依赖，Spark 是更稳健的选择；如果团队是 AI/ML 背景，需要在数据处理中频繁调用 ML 模型（如用分类器打 PPL 分、用 NER 模型做 PII 检测），Ray Data 的 Python 原生和 GPU 调度优势则会非常明显。许多大型团队最终采用的是混合方案：Spark 负责海量粗过滤（语言识别、规则去重），Ray Data 负责需要 ML 推理的精细化处理（质量评分、基准污染检测）。
@@ -151,6 +166,8 @@ ds = (
 ds.write_parquet("s3://my-bucket/processed/cc_cleaned/")
 ```
 
+*代码清单3-2：Ray Data 清洗流水线示例。生产环境中应补充失败重试、指标上报、数据版本和输出校验。*
+
 ### 3.2.3 存储索引层：三类数据的差异化存储策略
 
 LLM 数据栈要同时管理三种性质截然不同的数据，每种数据对存储层的要求都不相同，因此存储索引层需要采用差异化的技术方案。
@@ -172,7 +189,7 @@ LLM 数据栈要同时管理三种性质截然不同的数据，每种数据对
 
 对于大多数 LLM 数据工程场景，**Apache Iceberg** (Kinley and Li 2020) **+ S3**的组合是最推荐的方案，原因是其引擎中立性——它允许你同时用 Spark 做海量清洗处理、用 DuckDB 做轻量的数据探查分析，而无需迁移数据，也不担心被任何一家商业厂商锁定。
 
-**向量数据（Embeddings）**是第二类存储需求，主要服务于 RAG（检索增强生成）场景。向量数据库的核心职责是将海量文本 Chunk 转化为高维稠密向量并建立索引，支持高效的近似最近邻（ANN）检索 (Malkov and Yashunin 2020)。目前主流的向量数据库有 Milvus（开源，支持大规模分布式部署）、Qdrant（Rust 实现，性能极高，轻量部署友好）和 Weaviate（内置多模态向量支持，Schema 友好）等。选型时的核心决策因素是：向量数量规模（100万以下 vs 亿级）、是否需要 Hybrid Search（稠密向量 + BM25 (Robertson and Zaragoza 2009) 稀疏检索的混合）、以及运维团队对分布式系统的运维能力。
+**向量数据（Embeddings）**是第二类存储需求，主要服务于 RAG（检索增强生成）场景。向量数据库的核心职责是将海量文本 Chunk 转化为高维稠密向量并建立索引，支持高效的近似最近邻（ANN）检索 (Malkov and Yashunin 2020)。目前主流的向量数据库有 Milvus（开源，支持大规模分布式部署）、Qdrant（Rust 实现，性能较强，轻量部署友好）和 Weaviate（内置多模态向量支持，Schema 友好）等。选型时的核心决策因素是：向量数量规模（100 万以下 vs 亿级）、是否需要 Hybrid Search（稠密向量 + BM25 (Robertson and Zaragoza 2009) 稀疏检索的混合）、以及运维团队对分布式系统的运维能力。
 
 **模型 Checkpoint 与实验产物**是第三类，包括训练过程中保存的模型权重文件（动辄数百 GB）、TensorBoard 或 W&B 的训练日志、以及 Tokenizer 配置等。这类数据量大、访问频率不均匀（训练中频繁写入，训练后几乎只读），适合以对象存储为主存储，配合 DVC（Data Version Control）(Ruslan et al. 2021) 或 MLflow Artifacts 做版本追踪。
 
@@ -186,6 +203,8 @@ dvc push  # 将实际数据推送到 S3 远程存储
 # 其他工程师可用 dvc pull 拉取完全相同的数据
 ```
 
+*代码清单3-3：使用 DVC 追踪数据集版本的命令示例。生产环境中应配合远程对象存储权限、数据哈希校验和发布审批。*
+
 ### 3.2.4 评测运营层：让数据质量"可见"
 
 评测运营层的职责是为整个数据平台提供可观测性（Observability）——让团队能够实时看到数据管线的运行状态、数据质量的变化趋势，以及各类实验的追踪记录。它是数据飞轮得以持续转动的"仪表盘"。
@@ -202,21 +221,21 @@ dvc push  # 将实际数据推送到 S3 远程存储
 
 ## 3.3 成本模型与预算治理
 
-大模型数据工程的成本结构远比传统数据工程复杂。很多团队在项目立项时，只将算力（GPU 租用费用）纳入预算核算，而将数据处理、标注和存储成本视为"打杂费"一笔带过，结果在项目执行到一半时，才发现数据侧的成本已经远远超出了原始预算。
+大模型数据工程的成本结构远比传统数据工程复杂。很多团队在项目立项时，只将算力（GPU 租用费用）纳入预算核算，而将数据处理、标注和存储成本粗略归入杂项支出。项目执行到中期后，数据侧成本往往会明显超出原始预算。
 
 ### 3.3.1 五大成本维度全景拆解
 
 LLM 数据工程的成本可以拆分为五个主要维度，理解每个维度的成本驱动因素是制定合理预算的基础。
 
-**数据获取成本**是第一项。这包括爬虫服务器的租用和带宽费用（AWS EC2 Spot 实例推荐，成本约为按需实例的 1/3），付费购买的商业语料（如特定领域的专业数据库授权），以及 API 接口调用费用（如通过 Diffbot 或 Apify 等数据服务平台获取结构化网页内容）。对于百 TB 量级的数据获取任务，爬取成本通常在数万到十几万人民币量级。
+**数据获取成本**是第一项。这包括爬虫服务器的租用和带宽费用、付费购买的商业语料（如特定领域的专业数据库授权），以及 API 接口调用费用（如通过 Diffbot 或 Apify 等数据服务平台获取结构化网页内容）。截至 2026-06，云端 Spot 实例价格通常显著低于按需实例，但折扣幅度随区域、实例类型和供需变化而变化。对于百 TB 量级的数据获取任务，爬取成本通常在数万到十几万人民币量级。
 
-**数据处理成本**是第二项，也是最容易被低估的。一次完整的百 TB 语料清洗管线（包括解析、过滤、去重、质量评分），在 AWS EMR + Spot 实例上的成本约为 \$2,000-\$8,000 美元（取决于具体的处理逻辑复杂度和数据规模）。如果需要在数据中进行 ML 推理（如用 GPU 运行 PPL 分类器），GPU 实例的使用成本会进一步叠加。
+**数据处理成本**是第二项，也是最容易被低估的。以 2026-06 常见公有云价格量级估算，一次完整的百 TB 语料清洗管线（包括解析、过滤、去重、质量评分），在托管集群 + Spot 实例上的成本可能处于数千到数万美元区间，具体取决于处理逻辑复杂度、数据规模、区域价格和重试次数。如果需要在数据处理中进行 ML 推理（如用 GPU 运行 PPL 分类器），GPU 实例成本会进一步叠加。
 
-**标注成本**是第三项，也往往是整个数据预算中占比最高的单项。专业领域的高质量 SFT 样本（如医学、法律、金融），需要聘请具备相应领域背景的专家进行标注，每条高质量样本的人工成本约为 \$3-\$15 美元（取决于领域难度和单样本字数），十万条样本的标注成本可能高达数百万人民币。通用领域的基础 SFT 数据标注成本相对较低（约 \$0.5-\$2 美元/条），但整体数量需求更大。
+**标注成本**是第三项，也往往是整个数据预算中占比最高的单项。专业领域的高质量 SFT 样本（如医学、法律、金融）需要具备相应领域背景的专家参与。截至 2026-06，按外包、全职专家或平台化标注的不同模式估算，专业样本单条成本可能处于数美元到十余美元区间；通用领域基础 SFT 样本单条成本通常更低，但整体数量需求更大。实际成本需按标注规范、样本长度、质检比例和地区劳动力价格重新核算。
 
-**存储成本**是第四项，看似单价很低（S3 Standard 约 \$0.023/GB/月），但随着数据量的累积，也会成为实质性的持续支出。100TB 的温热数据每月存储费用约 \$2,300 美元；如果不做冷热分层管理，让大量已处理完毕的中间产物继续占用活跃层存储，长期累计的费用是非常可观的。
+**存储成本**是第四项。以 2026-06 常见对象存储公开标价量级估算，S3 Standard 等活跃层约为 \$0.023/GB/月，100TB 温热数据每月约 \$2,300；实际价格需以云厂商、区域、折扣和访问模式为准。如果不做冷热分层管理，让大量已处理完毕的中间产物继续占用活跃层存储，长期累计的费用会持续上升。
 
-**推理服务成本**是第五项，用于在数据处理阶段调用强模型（如 GPT-4o、Claude-3.5）进行质量评估、合成数据生成或自动化标注的 API 费用。GPT-4o 的 API 价格约为 \$5/百万 input tokens，如果用其为 1 亿条样本进行质量打分，仅 API 费用就需要约 \$500,000 美元以上，是一项需要非常谨慎规划的成本。
+**推理服务成本**是第五项，用于在数据处理阶段调用强模型进行质量评估、合成数据生成或自动化标注。以 2026-06 常见商用模型 API 价格量级估算，百万 input tokens 的费用可能从数角到数美元不等，取决于模型规格和服务商。若为 1 亿条样本进行质量打分，仅 API 费用就可能达到数十万甚至更高美元量级，因此需要通过抽样、级联评估和缓存策略进行规划。
 
 ### 3.3.2 训练前、中、后的分阶段成本核算
 
@@ -224,9 +243,9 @@ LLM 数据工程的成本可以拆分为五个主要维度，理解每个维度
 
 在**训练前**阶段，数据获取和处理是主要成本。此时最关键的预算决策是确定数据规模目标（多少 Token），以及选择自建处理集群还是使用云端 Spot 实例。通常情况下，对于百亿 Token 以内的项目，云端 Spot 实例（Ray on AWS Spot）是性价比最高的方案；对于千亿 Token 以上的大规模项目，自建或租用专用 CPU 集群可以降低单位 Token 的处理成本。
 
-在**训练中**阶段，算力成本占绝对主导，但数据 I/O 的质量直接影响 GPU 利用率，进而影响实际算力成本。一个 GPU 利用率为 70% 的训练任务，相比 GPU 利用率 90% 的任务，在数学上意味着需要多花 28% 的训练时间，等同于多烧掉 28% 的算力预算——这是用于数据 I/O 优化的工程投资拥有极高 ROI 的根本原因。
+在**训练中**阶段，算力成本占主导，但数据 I/O 的质量直接影响 GPU 利用率，进而影响实际算力成本。一个 GPU 利用率为 70% 的训练任务，相比 GPU 利用率 90% 的任务，在相同有效计算量下需要更长训练时间。因此，数据 I/O 优化通常具有较高 ROI。
 
-在**训练后**阶段，模型评测、数据版本归档和知识库维护（RAG更新）形成持续性成本。此时的重点是建立清晰的数据生命周期策略：已进入正式版本的数据集迁移至 S3 Glacier Instant Retrieval（成本约为 Standard 层的 1/4）；临时实验用的中间数据集设置 30 天自动删除策略；只保留有明确标记和说明的最终版本数据集。
+在**训练后**阶段，模型评测、数据版本归档和知识库维护（RAG 更新）形成持续性成本。此时的重点是建立清晰的数据生命周期策略：已进入正式版本的数据集可迁移至低频访问存储层；临时实验用中间数据集可设置 30 天自动删除策略；只保留有明确标记和说明的最终版本数据集。低频访问存储的具体单价与取回费用变化较快，应以 2026-06 之后的云厂商公告为准。
 
 ### 3.3.3 ROI 决策框架
 
@@ -238,9 +257,9 @@ $$\text{数据工程 ROI} = \frac{\Delta\text{模型性能} \times \text{模型
 
 将以上三个环节（规划→监控→评估→优化→复盘）串联为一个持续迭代的闭环，即构成了大模型团队的**成本治理闭环**，如下图所示：
 
-![图3-2：训练数据成本治理闭环图](../../images/part1/cost_governance_loop.png)
+![图3-2：训练数据成本治理闭环图，展示预算规划、成本监控、ROI评估、优化决策和预算复盘的循环](../../images/part1/cost_governance_loop.png)
 
-*图3-2：训练数据成本治理闭环 —— 从预算规划出发，经过成本监控、ROI 评估和优化决策，最终回归预算复盘，形成跨版本迭代的成本降本与效能提升正循环。*
+*图3-2：训练数据成本治理闭环。来源：本书自绘。该图展示从预算规划出发，经过成本监控、ROI 评估和优化决策，最终回归预算复盘的跨版本迭代过程。*
 
 
 ---
@@ -255,9 +274,9 @@ $$\text{数据工程 ROI} = \frac{\Delta\text{模型性能} \times \text{模型
 
 在这个阶段，最大的工程陷阱是**过度设计**：花三个月搭一套"工业级"的分布式数据平台，等到平台搭完，团队可能已经在对的方向上落后了两个月。初创团队的正确策略是：以最低成本验证核心假说，等到需要处理的数据量真正触碰到单机极限时，再逐步引入分布式能力。
 
-推荐的轻量栈技术组合为：存储层使用 **S3 / MinIO + Parquet**（不需要 Iceberg，手动管理版本目录即可）；计算层使用 **DuckDB**（单机处理 100GB 以内的数据游刃有余，SQL 语法友好，无需配置集群）和 Python pandas/polars；版本控制使用 **DVC**（10 行命令即可上手）；管道编排使用 **Prefect** 或 **Dagster**（比 Airflow 轻得多，本地运行即可）。这套组合的工程搭建时间通常可以控制在 1-2 周以内。
+推荐的轻量栈技术组合为：存储层使用 **S3 / MinIO + Parquet**（暂不引入 Iceberg，手动管理版本目录即可）；计算层使用 **DuckDB**（单机处理 100GB 以内数据时通常足够，SQL 语法友好，无需配置集群）和 Python pandas/polars；版本控制使用 **DVC**；管道编排使用 **Prefect** 或 **Dagster**。这套组合的工程搭建时间通常可以控制在 1-2 周以内。
 
-值得特别说明的是，DuckDB 在初创团队中常常被低估。它可以直接读写 S3 上的 Parquet 文件，无需将数据下载到本地，同时支持标准 SQL 语法，让不熟悉 PySpark 的工程师立刻上手。一台 64 核、512GB 内存的高配云主机（AWS r7i.16xlarge，按需约 $4/小时，Spot 约 $1.2/小时）配合 DuckDB，足以在 2 小时内完成对单个 100GB Parquet 文件的全套清洗过滤，性价比远超同场景下拉起一套 Spark 集群的方案。
+值得特别说明的是，DuckDB 在初创团队中常常被低估。它可以直接读写 S3 上的 Parquet 文件，无需将数据下载到本地，同时支持标准 SQL 语法，让不熟悉 PySpark 的工程师快速上手。以截至 2026-06 的常见云主机价格量级估算，一台 64 核、512GB 内存的高配云主机配合 DuckDB，通常足以在小时级完成单个 100GB Parquet 文件的过滤和聚合。实际耗时与费用取决于区域、实例折扣、数据格式、压缩方式和查询复杂度。
 
 
 
@@ -277,7 +296,7 @@ $$\text{数据工程 ROI} = \frac{\Delta\text{模型性能} \times \text{模型
 
 推荐的大型团队方案以**统一数据平台**为核心：底层采用 Kubernetes 统一管理计算资源（包括 CPU 和 GPU 节点），Ray on Kubernetes 或 Spark on Kubernetes 提供调度；数据隔离通过 S3 的 IAM 权限策略在 Bucket-level 实现（不同项目使用独立 Bucket 或带有严格 Prefix 隔离的共享 Bucket）；元数据管理引入专业的数据目录工具（如 Apache Atlas 或 AWS Glue Data Catalog），统一管理公司内所有数据资产的血缘关系；平台团队维护一套标准化的数据处理算子库（Data Operator Library），各业务线通过调用算子库的接口开发自己的清洗管线，确保质量检测逻辑的统一。
 
-一个重要的经验是：大型团队的数据平台应当**分三个阶段建设**，而不是一步到位。第一阶段（1-3个月）优先打通核心链路——存储接入 + 基础清洗算子 + 版本管理，确保数据能够以受控方式流转；第二阶段（3-6个月）围绕可观测性建设，搭建质量看板、实验追踪和告警系统，让平台从"黑匣子"变成"仪表盘"；第三阶段（6个月以上）才着手引入更复杂的多租户隔离机制、跨项目数据血缘洞察和资源配额管理。过早进入第三阶段往往是大型团队在数据平台建设上"失控"的根本原因——为了支撑未来可能出现的需求，花费大量工程资源建设当下根本用不到的能力，最终平台越来越复杂，但核心的数据流转效率却并没有真正提升。
+一个重要经验是：大型团队的数据平台应当**分三个阶段建设**，而不是一步到位。第一阶段（1-3 个月）优先打通核心链路：存储接入、基础清洗算子和版本管理，确保数据能够以受控方式流转；第二阶段（3-6 个月）围绕可观测性建设，搭建质量看板、实验追踪和告警系统，让平台从缺少透明度的流程变成可观测系统；第三阶段（6 个月以上）再引入更复杂的多租户隔离机制、跨项目数据血缘洞察和资源配额管理。过早进入第三阶段容易使平台复杂度超过实际需求，反而降低核心数据流转效率。
 
 **表 3-3：三类团队数据栈选型速查矩阵**
 
@@ -301,15 +320,15 @@ $$\text{数据工程 ROI} = \frac{\Delta\text{模型性能} \times \text{模型
 
 **第八篇（DataOps 平台建设）**是本章的"升维扩展版"：第8章将在本章五层架构的基础上，深入探讨如何构建数据管线的端到端可观测性系统、如何实现数据资产的自动化治理，以及如何将本章讨论的质量评分卡与 CI/CD 流水线深度集成，最终让整个数据平台从"手工作坊"升级为"智能数据工厂"。
 
-关于能力边界的核心原则：**凡是多个项目或多个数据阶段共同需要的能力，应当平台化**（如去重算子库、质量评分卡框架、数据版本管理）；**凡是与特定业务场景高度定制的能力，应当项目化**（如某个垂直领域的实体识别规则、某个特定数据源的解析逻辑）。平台化的边界不是越大越好——过度抽象会让平台变成一个庞大但缺乏灵活性的"屠龙刀"，让每一个具体项目都被迫适应平台的接口，而不是平台服务于项目的实际需求。
+关于能力边界的核心原则：**凡是多个项目或多个数据阶段共同需要的能力，应当平台化**（如去重算子库、质量评分卡框架、数据版本管理）；**凡是与特定业务场景高度定制的能力，应当项目化**（如某个垂直领域的实体识别规则、某个特定数据源的解析逻辑）。平台化的边界不是越大越好。过度抽象会降低具体项目的迭代效率，使项目团队被迫适应平台接口，而不是让平台服务于实际需求。
 
 ---
 
 **本章小结**
 
-本章系统性地建立了 AI 原生数据栈的完整架构蓝图。我们首先从目标差异、工作负载特征和成本约束三个维度，剖析了为什么面向 BI 分析设计的传统数仓技术栈无法直接移植到 LLM 数据工程场景。在此基础上，我们将数据栈拆解为采集接入、处理编排、存储索引、评测运营和治理安全五个功能层，每一层给出了工业界验证过的主流选型方案和具体的技术比较依据。成本模型章节揭示了五大成本维度的构成和分阶段核算方法，并给出了量化的 ROI 决策框架。最后，针对初创、中型和大型三类不同规模的团队，分别给出了与其阶段相匹配的差异化架构方案，避免了"用小公司的资源搭大厂的架构"的常见陷阱。
+本章系统性地建立了 AI 原生数据栈的完整架构蓝图。我们首先从目标差异、工作负载特征和成本约束三个维度，剖析了为什么面向 BI 分析设计的传统数仓技术栈无法直接移植到 LLM 数据工程场景。在此基础上，我们将数据栈拆解为采集接入、处理编排、存储索引、评测运营和治理安全五个功能层，每一层给出了工业界验证过的主流选型方案和具体的技术比较依据。成本模型章节揭示了五大成本维度的构成和分阶段核算方法，并给出了量化的 ROI 决策框架。最后，针对初创、中型和大型三类不同规模的团队，分别给出了与其阶段相匹配的差异化架构方案，避免在早期阶段引入超出团队能力和业务需求的平台复杂度。
 
-带着这套基础设施蓝图，从下一章开始，我们将正式进入第二篇——文本预训练数据工程的主战场，探讨在这套数据栈之上，如何从浩如烟海的公开语料中挖掘出构建顶尖大模型所需的黄金预训练数据。
+带着这套基础设施蓝图，从下一章开始，本书将进入第二篇——文本预训练数据工程，探讨如何在这套数据栈之上，从大规模公开语料中构建可训练、可追溯、可评估的预训练数据集。
 
 ## 参考文献
 
@@ -328,4 +347,3 @@ Malkov Y A, Yashunin D A (2020) Efficient and Robust Approximate Nearest Neighbo
 Kinley J, Li R (2020) Iceberg: A Modern Table Format for Huge Analytic Datasets. In: Proceedings of the 2020 ACM SIGMOD International Conference on Management of Data, pp 2955-2962.
 
 Ruslan K, Barrak M, Shcherbatyi I, others (2021) DVC: Data Version Control - Git for Data and Models. In: Proceedings of the Workshop on MLOps Systems at MLSys 2021.
-
diff --git a/docs/zh/part1/index.md b/docs/zh/part1/index.md
index 9297ae5d..c0a247ce 100644
--- a/docs/zh/part1/index.md
+++ b/docs/zh/part1/index.md
@@ -2,7 +2,22 @@
 
 ## 本篇定位
 
-第一篇建立全书的共同认知框架，重点说明大模型数据工程的对象、边界、核心成本项与基础设施分层，为后续各篇的预训练、多模态、RAG、DataOps 和隐私治理内容提供统一坐标系。
+第一篇建立全书的共同认知框架，重点说明大模型数据工程的对象、边界、质量目标、核心成本项与基础设施分层。它不以单一工具或单一模型为中心，而是从数据生命周期出发，解释为什么数据已经成为大模型能力、成本和风险控制的共同约束。
+
+从出版稿结构看，本篇承担三项功能。第一，第1章给出问题背景和范式迁移，说明大模型研发为何必须从“模型中心”转向“数据与系统共同治理”。第二，第2章建立贯穿全书的数据质量语言，将噪声、重复、污染、偏差、缺失和时效等问题转化为可测量、可复盘、可阻断的工程指标。第三，第3章把质量框架落到基础设施层，讨论采集接入、处理编排、存储索引、评测运营和治理安全如何共同支撑训练与应用。
+
+## 本篇学习目标
+
+读完本篇后，读者应能够：
+
+- 解释大模型数据工程与传统数据仓库、传统机器学习数据处理之间的关键差异。
+- 识别预训练、指令微调、偏好对齐和 RAG 应用阶段的不同质量目标。
+- 将常见数据问题映射为可检测的质量指标、治理动作和回滚策略。
+- 依据团队规模和训练目标，初步设计 AI 原生数据栈与成本治理方案。
+
+## 章节关系
+
+第1章提出全书的基本命题：数据质量、数据规模和数据多样性共同决定模型能力边界。第2章回答“如何判断数据是否可用”，并给出质量评分卡和治理闸门。第3章回答“用什么基础设施承载这些治理动作”，并将后续各篇的清洗、对齐、RAG、DataOps 与合规内容放入统一架构中。
 
 ## 全书总目录
 
diff --git a/docs/zh/part2/ch04_data_sources.md b/docs/zh/part2/ch04_data_sources.md
index 284803b1..ae0de272 100644
--- a/docs/zh/part2/ch04_data_sources.md
+++ b/docs/zh/part2/ch04_data_sources.md
@@ -1,12 +1,28 @@
 # 第4章 数据源、采集与版权
 
+## 摘要
+
+本章讨论文本预训练数据工程的源头治理问题，重点回答哪些数据可以采集、如何采集以及如何证明其来源和许可边界。章节首先说明数据源选择对模型能力、版权风险和后续清洗上限的影响，随后建立开放网页、论坛问答、百科知识、代码、学术论文、书籍、企业内部数据和用户反馈数据的分类框架。接着，章节从分布式采集、异构格式解析、元数据存证和任务可靠性四个角度说明生产级采集流水线的基本要求，并进一步给出白名单、灰名单、黑名单和许可证分类机制。两个匿名化复合案例用于说明 Common Crawl 解析路线和企业内部文档版权审查中的典型风险。通过本章，读者应能够在大规模抓取或内部数据接入之前建立可审计的数据来源清单、许可判断框架和元数据记录规范，从而为后续清洗、分词和训练评估提供可靠边界。
+
+## 关键词
+
+数据源；数据采集；版权许可；Common Crawl；元数据存证；robots.txt；许可证分类；来源治理
+
+## 学习目标
+
+- 能够区分主要预训练数据源的质量价值、规模潜力和许可风险。
+- 能够设计包含 robots.txt 检查、解析质量抽检和断点续传的采集流水线。
+- 能够为每批数据建立来源、许可、解析器版本和处理配置等元数据记录。
+- 能够使用白名单、灰名单、黑名单和许可证分类机制降低版权风险。
+- 能够解释为什么源头治理决定后续清洗和训练数据质量的上限。
+
 ## 开篇场景：一个"数据够多了"的团队，为什么还是失败了
 
-某 AI 研究院的算法团队花费了三个月时间，从公开的网络资源里爬取并积累了超过 2TB 的中文文本数据。按照 Chinchilla 最优配比，这足以支撑一轮 7B 模型的预训练。在信心满满地启动了长达两周、耗资数十万元算力的训练任务之后，团队进行了首次评测——结果却令人沮丧：模型在中文阅读理解和数学推理上的表现不如同规模的开源基线，更严重的是，模型频繁输出"SEO 风格"的凑字数段落，以及疑似来自某些论坛的仿网络小说片段。
+以下为匿名化复合案例，数字用于说明工程量级和风险口径。某 AI 研究院的算法团队花费了三个月时间，从公开的网络资源里爬取并积累了超过 2TB 的中文文本数据。按照 Chinchilla 最优配比，这足以支撑一轮 7B 模型的预训练。在信心满满地启动了长达两周、耗资数十万元算力的训练任务之后，团队进行了首次评测——结果却令人沮丧：模型在中文阅读理解和数学推理上的表现不如同规模的开源基线，更严重的是，模型频繁输出"SEO 风格"的凑字数段落，以及疑似来自某些论坛的仿网络小说片段。
 
 问题在哪里？数据量是够的，训练过程也没有异常。复盘后，团队才发现问题的根源：彼时的 2TB 数据里，有接近 60% 来自 SEO 站群（内容通过自动采集和改写生成的低质量网站），15% 是各类网络小说正文（版权高度存疑），只有不到 25% 是有实质知识密度的内容——百科、技术文档、学术摘要等。换言之，团队采集的不是"数据"，而是"网络噪声"。模型忠实地学习了训练集的分布，表现出了符合训练数据特征的行为：输出流畅却空洞的文字。
 
-这个案例揭示了预训练数据工程中一个反常识的铁律：**输在源头，无法靠清洗挽救。** 当你的数据源本质上是低质量的，无论后续的清洗管线多么精良，都无法把"沙子"炼成"黄金"——你只能把"脏沙子"变成"干净的沙子"。
+这个案例揭示了预训练数据工程中的基本原则：**源头质量决定后续清洗能够达到的上限。** 当数据源本质上是低质量的，无论后续清洗管线多么精细，都只能降低噪声，而不能凭空补足缺失的知识密度和许可边界。
 
 ---
 
@@ -24,7 +40,7 @@
 
 **偏差源头（Biased Source）**：数据主要来自特定平台、特定人群或特定风格的内容。例如，某团队将某头部内容平台作为主要语料来源——这个平台的内容固然质量较高，但其整体写作风格、话题分布和读者人群极为一致，结果导致模型在这类写作风格上表现异常流畅，但在学术写作、法律文本、技术文档等风格上能力明显偏弱，呈现出强烈的"平台腔"。
 
-**低密度来源（Low-Density Source）**：数据量虽大，但知识密度极低。上文场景引入中提到的 SEO 站群是典型案例。另一个常见情形是直接使用爬虫抓取的微博/微信转发类内容——这类内容的句子本身通常语言流畅，但信息量极低，充斥着情感表达和无实质信息的碎片化短文，而这恰恰是大模型记忆和知识提取最难发力的内容类型。
+**低密度来源（Low-Density Source）**：数据量虽大，但知识密度极低。上文匿名化场景中提到的 SEO 站群是典型案例。另一个常见情形是直接使用爬虫抓取的微博/微信转发类内容——这类内容的句子本身通常语言流畅，但信息量极低，充斥着情感表达和无实质信息的碎片化短文，而这恰恰是大模型记忆和知识提取最难发力的内容类型。
 
 **版权高风险来源（High Copyright Risk Source）**：数据量和质量都不错，但版权归属存在重大法律风险。2023 至 2024 年间，OpenAI、Google、Stability AI 等公司先后面临来自媒体机构、出版商和作者的版权诉讼，核心争议点都集中在训练数据的版权归属问题上。国内监管环境同样日趋收紧——《生成式人工智能服务管理暂行办法》明确要求训练数据合规，且数据提供者对数据版权合法性承担相应责任。对这一风险的忽视，可能在产品上线后给企业带来难以估量的法律和商业损失。
 
@@ -32,7 +48,7 @@
 
 "数据越多越好"是预训练数据工程中流传最广的误区之一。这个观念在宏观层面是有一定道理的——在数据质量一定的情况下，规模确实带来能力提升（Scaling Law 的核心结论）。但它在微观执行层面极易被滥用，演变为用体积代替质量的决策依据。
 
-FineWeb 的论文（Penedo et al. 2024）提供了一个振聋发聩的数据点：在相同的 Token 数量约束下，从 CommonCrawl 中精心筛选的高质量子集（约 15T Token）训练出的 LLM，在多项基准评测上**全面超越**了用原始 CommonCrawl 全量数据训练的模型——尽管后者的原始 Token 数远多于前者。换言之，"少而精"在预训练数据领域完全可以击败"多而杂"。
+FineWeb 的论文（Penedo et al. 2024）提供了一个重要观察：在相同的 Token 数量约束下，从 Common Crawl 中筛选的高质量子集（论文报告约 15T Token）训练出的 LLM，在多项基准评测上优于用原始 Common Crawl 全量数据训练的模型——尽管后者的原始 Token 数远多于前者。换言之，"少而精"在预训练数据领域可以优于"多而杂"。
 
 这一结论为整章的数据源选择策略奠定了基础：**数据配方（Data Recipe）的制定，应优先关注每个来源的知识密度和信息多样性，而非原始体积。**
 
@@ -44,11 +60,11 @@ FineWeb 的论文（Penedo et al. 2024）提供了一个振聋发聩的数据点
 
 ![图4-1：预训练数据源分层地图](../../images/part2/pretrain_data_source_map.png)
 
-*图4-1：预训练数据源分层地图 —— 三层分类体系按照处理复杂度、知识密度和许可风险对主流数据来源进行定位，并给出典型的配比参考区间。*
+*图4-1：预训练数据源分层地图 —— 三层分类体系按照处理复杂度、知识密度和许可风险对主流数据来源进行定位，并给出典型的配比参考区间。来源：本书自绘；Alt text：预训练数据源分层地图，展示开放网页、论坛问答、百科、代码、学术论文、书籍、企业内部数据和用户反馈数据的质量与合规位置。*
 
 ### 4.2.1 八类核心数据源全景
 
-**开放网页（Open Web）** 是体量最大、也最难驾驭的一类来源，以 Common Crawl 为代表。Common Crawl 从 2008 年起持续抓取互联网，每月发布数十亿网页的快照，累计数据量超过 PB 级，是目前几乎所有大规模预训练数据集的上游来源，无论是 GPT 系列、LLaMA 还是国内的主流大模型，都或多或少地依赖它。然而，开放网页的原始数据质量极差——据 FineWeb 项目的统计 (Penedo et al. 2024)，Common Crawl 原始内容中，真正具备知识密度的正文内容占比不超过 10%，剩余 90% 是广告、导航栏、SEO 垃圾、JavaScript 代码等噪声。这意味着网页数据必须经过极为严苛的清洗才能使用（详见 Ch05）。
+**开放网页（Open Web）** 是体量最大、也最难驾驭的一类来源，以 Common Crawl 为代表。Common Crawl 从 2008 年起持续抓取互联网，每月发布数十亿网页的快照，累计数据量超过 PB 级，是目前许多大规模预训练数据集的上游来源。然而，开放网页的原始数据质量差异很大——据 FineWeb 项目的统计 (Penedo et al. 2024)，Common Crawl 原始内容中，真正具备知识密度的正文内容占比有限，大量内容为广告、导航栏、SEO 垃圾、JavaScript 代码等噪声。这意味着网页数据必须经过严格清洗才能使用（见第5章）。
 
 **论坛与问答（Forums & Q&A）** 以 Reddit、StackOverflow、知乎、Quora 等平台为代表。这类数据的独特价值在于：它是真实用户针对真实问题产生的自然语言交互，包含了大量的问题追问、答案修正和社区讨论，这对提升大模型的对话能力和"追问理解能力"有很高价值。StackOverflow 在技术领域的采用极为普遍，是 LLM 代码理解能力的重要来源之一。需要注意的是，这类数据在 2023-2024 年纷纷修改 API 条款（Reddit、Twitter/X 均关闭或收费化 API），获取难度大幅上升。
 
@@ -95,7 +111,7 @@ FineWeb 的论文（Penedo et al. 2024）提供了一个振聋发聩的数据点
 | **垂直行业模型（如金融/医疗）** | 25-30% | 8-12% | 15-20% | 10-15% | 30-40% | 领域数据占比显著提升，通用语料保底维持通用能力 |
 | **多语言base模型** | 55-60% | 15-18% | 8-10% | 8-12% | 按语言目标分配 | 网页数据中需控制各语言分布与目标语言能力需求一致 |
 
-配比策略还需要考量**动态调整机制**：不同阶段的训练（预训练初期 vs Cooldown 阶段）应当采用不同的配比权重。越接近训练后期，越应当提高高质量精选数据（书籍、学术论文、企业数据）的比例，同时降低低质量海量数据（原始网页）的权重——这与 LLaMA-3 (Dubey et al. 2024) 和 Gemma 等顶级模型在预训练后期将高质量数据权重提升至 2-3 倍的工程实践一致。
+配比策略还需要考量**动态调整机制**：不同阶段的训练（预训练初期 vs Cooldown 阶段）应当采用不同的配比权重。越接近训练后期，越应当提高高质量精选数据（书籍、学术论文、企业数据）的比例，同时降低低质量海量数据（原始网页）的权重——这与 LLaMA-3 (Dubey et al. 2024) 和 Gemma 等代表性公开模型在预训练后期将高质量数据权重提升至 2-3 倍的工程实践一致。
 
 ---
 
@@ -107,7 +123,9 @@ FineWeb 的论文（Penedo et al. 2024）提供了一个振聋发聩的数据点
 
 在面对千万级 URL 的增量数据源（如特定垂直领域网站群）时，单线程同步爬虫的效率无法满足工程需求。工业级实践通常采用基于 `aiohttp` 或 `Scrapy` 的分布式异步采集架构。同时，为了避免引发法律纠纷和保障站点的可用性，**必须在核心调度器中强制集成 robots.txt 检查机制**。
 
-以下是一个基于 `aiohttp` 的轻量级异步并发采集框架，它利用 `urllib.robotparser` 在发送请求前自动校验合规性：
+代码清单4-1给出了一个基于 `aiohttp` 的轻量级异步并发采集框架示意。它利用 `urllib.robotparser` 在发送请求前自动校验合规性；生产环境中还应加入速率限制、审计日志、异常重试和法务维护的来源策略。
+
+**代码清单4-1：异步并发采集与 robots.txt 校验示意代码**
 
 ```python
 import asyncio, aiohttp
@@ -168,7 +186,11 @@ class AsyncEthicalCrawler:
 
 不同类型的数据源需要截然不同的解析技术路线，使用错误的解析工具会导致严重的内容损失或噪声引入：
 
-**网页（HTML/WARC）** 是最常见、也最需要专业工具处理的格式。Common Crawl 提供了三种数据格式——WARC（原始 HTTP 响应+完整 HTML）、WAT（元数据）和 WET（预提取纯文本）。许多团队在早期会直接使用 WET 文件，因为它看起来最省事——已经是纯文本了，直接用就好。这是一个非常危险的陷阱：Common Crawl 的 WET 提取使用的是通用算法，解析质量相当低劣，会保留大量导航栏、页脚、广告文字和 JavaScript 代码片段。正确的做法是从 WARC 文件出发，用高质量的正文提取库（如 Trafilatura (Barbaresi 2021)）重新解析，尽管这耗时更长，但能带来显著的质量提升（通常可使后续过滤后的有效内容保留率提升 30-50%）。
+**网页（HTML/WARC）** 是最常见、也最需要专业工具处理的格式。Common Crawl 提供了三种数据格式——WARC（原始 HTTP 响应+完整 HTML）、WAT（元数据）和 WET（预提取纯文本）。许多团队在早期会直接使用 WET 文件，因为它看起来最省事——已经是纯文本了，直接用就好。这是一个非常危险的陷阱：Common Crawl 的 WET 提取使用的是通用算法，解析质量相当低劣，会保留大量导航栏、页脚、广告文字和 JavaScript 代码片段。正确的做法是从 WARC 文件出发，用高质量的正文提取库（如 Trafilatura (Barbaresi 2021)）重新解析，尽管这耗时更长，但通常能带来更稳定的正文抽取质量。不同语种、站点和解析器配置会导致有效内容保留率显著不同，因此应以抽样审阅和批次统计为准。
+
+代码清单4-2展示了从 WARC 文件解析正文并保留来源元数据的示意流程。
+
+**代码清单4-2：WARC 正文解析与来源元数据保留示意代码**
 
 ```python
 import trafilatura
@@ -221,7 +243,9 @@ def parse_warc_to_clean_text(warc_path: str) -> list[dict]:
 
 在数据采集的同时建立可追溯的元数据档案，是整个数据治理体系的奠基石。一条数据如果没有完整的元数据，在日后的合规审计中就无法证明其来源合法——这与财务账目一样，"我记得是合法的"不能替代"我有凭证证明是合法的"。
 
-每一批采集的数据，应当在落盘（写入对象存储）的同时，向元数据数据库写入以下标准字段：
+每一批采集的数据，应当在落盘（写入对象存储）的同时，向元数据数据库写入以下标准字段。代码清单4-3给出的是示例字段，实际系统应根据数据源、授权方式和审计要求扩展。
+
+**代码清单4-3：采集批次元数据存证字段示例**
 
 ```json
 {
@@ -243,7 +267,7 @@ def parse_warc_to_clean_text(warc_path: str) -> list[dict]:
 
 ![图4-2：数据采集与权属存证流程图](../../images/part2/data_ingestion_provenance_chain.png)
 
-*图4-2：数据采集与权属存证流程——从数据源触达到最终归档，每个处理阶段均向"Provenance Ledger（权属账本）"追加元数据记录，形成完整的可审计数据血缘链路。*
+*图4-2：数据采集与权属存证流程——从数据源触达到最终归档，每个处理阶段均向"Provenance Ledger（权属账本）"追加元数据记录，形成完整的可审计数据血缘链路。来源：本书自绘；Alt text：数据采集与权属存证流程图，展示来源触达、采集、解析、清洗、入库和审计记录之间的链路。*
 
 ### 4.3.4 断点续传与任务可靠性
 
@@ -275,7 +299,9 @@ def parse_warc_to_clean_text(warc_path: str) -> list[dict]:
 
 **灰名单（Graylist）**：许可存在争议或条款限制较多的来源，使用前需要逐案提交法务审核，并记录审核结论。常见的灰名单来源包括：其他 arXiv 论文（需逐篇核查）、平台 API 数据（受平台服务条款约束）。
 
-**黑名单（Blacklist）**：明确不可用的来源——包括已发生诉讼的来源（如 Books3）、robots.txt 明确禁止的网站、以及任何包含明确"禁止用于 AI 训练"声明的数据。技术上，可以通过 URL 域名前缀匹配的方式，在采集管线的入口阶段自动拦截黑名单来源：
+**黑名单（Blacklist）**：明确不可用的来源——包括已发生诉讼的来源（如 Books3）、robots.txt 明确禁止的网站、以及任何包含明确"禁止用于 AI 训练"声明的数据。技术上，可以通过 URL 域名前缀匹配的方式，在采集管线的入口阶段自动拦截黑名单来源。代码清单4-4展示了简化实现：
+
+**代码清单4-4：版权黑名单入口拦截示意代码**
 
 ```python
 # 版权黑名单：在采集入口拦截禁止来源
@@ -294,7 +320,9 @@ def is_url_allowed(url: str) -> bool:
 
 ### 4.4.3 许可证类型自动分类
 
-对于代码数据，许可证信息通常以 LICENSE 或 LICENSE.md 文件的形式存放在仓库根目录，可以通过规则或分类器自动识别：
+对于代码数据，许可证信息通常以 LICENSE 或 LICENSE.md 文件的形式存放在仓库根目录，可以通过规则或分类器自动识别。代码清单4-5展示了简化实现，生产系统应使用更严格的许可证解析库和法务审核流程：
+
+**代码清单4-5：许可证类型自动分类示意代码**
 
 ```python
 import re
@@ -326,11 +354,11 @@ def classify_license(license_text: str) -> dict:
 
 ## 4.5 案例复盘与实践建议
 
-### 案例一：Common Crawl 中文语料接入的全流程教训
+### 案例一：Common Crawl 中文语料接入的全流程教训（匿名化复合案例）
 
-**项目背景**：某团队计划从 Common Crawl 2024-10 批次中提取约 200GB 高质量中文文本，作为通用中文基座模型预训练的语料主体。
+**项目背景**：某团队计划从 Common Crawl 某批次中提取约 200GB 高质量中文文本，作为通用中文基座模型预训练的语料主体。以下规模、耗时和比例为截至 2026-06 的工程估算示例，实际结果取决于抓取批次、语言过滤策略、解析器版本和人工抽检口径。
 
-**T+0（决策日）**：团队初步评估了 Common Crawl 2024-10 的 WET 文件大小（约 15TB 压缩），认为直接使用 WET 最简单——毕竟 WET 里已经是纯文本，省去了解析步骤。他们下载了一个 WET 子集（约 500GB 压缩，对应约 5000 万文档）并做了快速评估。
+**T+0（决策日）**：团队初步评估了该批次 WET 文件大小（约 15TB 压缩），认为直接使用 WET 最简单——毕竟 WET 里已经是纯文本，省去了解析步骤。他们下载了一个 WET 子集（约 500GB 压缩，对应约 5000 万文档）并做了快速评估。
 
 **T+3（发现问题）**：数据工程师随机抽取了 500 条中文文档进行人工审阅，发现质量严重低于预期：约 35% 的文档包含大量导航栏和菜单文字（如"首页 | 关于我们 | 联系我们 | 版权声明"）；约 20% 是广告或商品描述堆砌；约 15% 的内容是被截断的不完整段落；真正是完整文章正文的内容不超过 30%。
 
@@ -346,9 +374,9 @@ def classify_license(license_text: str) -> dict:
 
 ---
 
-### 案例二：金融企业内部知识库采集的合规风险
+### 案例二：金融企业内部知识库采集的合规风险（匿名化复合案例）
 
-**项目背景**：某金融集团决定基于内部的研报、合规手册、产品说明书等文档，训练一个内部专属的金融问答模型。数据规模约 500GB（PDF + Word 格式），覆盖近 10 年的内部文档积累。
+**项目背景**：某金融集团决定基于内部的研报、合规手册、产品说明书等文档，训练一个内部专属的金融问答模型。数据规模约 500GB（PDF + Word 格式），覆盖近 10 年的内部文档积累。以下比例和规模用于说明风险类型，不代表特定企业公开事件。
 
 **T+0（数据摸底）**：数据工程师拿到了集团 IT 部门提供的文档目录清单，开始批量解析 PDF 文件。工程推进顺利，两周内完成了文档解析和初步清洗，生成约 2 亿 Token 的训练数据。
 
@@ -366,7 +394,7 @@ def classify_license(license_text: str) -> dict:
 
 本章从"为什么先输在源头"出发，系统建立了预训练数据源体系的完整认知框架。我们构建了涵盖八类核心数据源的分层地图，并通过风险矩阵（表4-1）和配比策略矩阵（表4-2）为工程决策提供了可操作的量化工具。在采集流水线部分，我们揭示了 WET 直接使用的陷阱，给出了基于 Trafilatura 的高质量 WARC 解析实现，并建立了"每条数据都有出生证明"的元数据存证标准。版权治理部分引入了白/灰/黑名单的三级管理机制，配合许可证自动分类代码，为商业化 LLM 团队提供了可落地的合规工程方案。两个案例——Common Crawl 中文语料接入的质量教训和金融企业内部知识库的合规风险——分别从技术和法律两个维度，印证了"源头治理"的核心价值。
 
-进入下一章，我们将在本章采集到的"毛坯数据"基础上，展开预训练数据工程最重要的旗舰章节：**第5章 清洗、去重与去污染**——探讨如何将有缺陷的原始语料转化为可以直接送入训练的高质量数据集。源头治理决定了可以送入清洗管线的语料的上限，而清洗管线决定的则是从上限中最终能榨取多少真正有价值的训练 Token——两章共同构成预训练数据工程最核心的质量守门体系。
+进入下一章，我们将在本章采集到的原始数据基础上，讨论**第5章 清洗、去重与去污染**。源头治理决定可以送入清洗管线的语料上限，而清洗管线决定哪些样本能够最终进入训练集。两章共同构成文本预训练数据工程的质量守门体系。
 
 ## 参考文献
 
@@ -381,4 +409,3 @@ Joulin A, Grave E, Bojanowski P, Douze M, Jegou H, Mikolov T (2017) FastText.zip
 Lopez P (2009) GROBID: Combining Automatic Bibliographic Data Recognition and Term Extraction for Scholarship Publications. In: Proceedings of the 13th European Conference on Digital Libraries, pp 473-474.
 
 Penedo G, Kydlíček H, allal L B, Lozhkov A, Mitchell M, Raffel C, Von Werra L, Wolf T (2024) The FineWeb Datasets: Decanting the Web for the Finest Text Data at Scale. arXiv preprint arXiv:2406.17557.
-
diff --git a/docs/zh/part2/ch05_cleaning_dedup.md b/docs/zh/part2/ch05_cleaning_dedup.md
index b79bb83b..7cc33e08 100644
--- a/docs/zh/part2/ch05_cleaning_dedup.md
+++ b/docs/zh/part2/ch05_cleaning_dedup.md
@@ -1,22 +1,38 @@
 # 第5章 清洗、去重与去污染
 
+## 摘要
+
+本章讨论文本预训练数据从原始语料转化为训练语料的关键步骤，覆盖规则过滤、模型质量评分、文本标准化、精确去重、模糊去重、语义去重、PII 脱敏和基准去污染。章节首先说明重复、低信息密度、隐私泄露和评测污染如何在训练阶段被放大，随后给出规则、模型和人工抽检协同的清洗框架。去重部分从 SHA-256 精确匹配扩展到 MinHash LSH 和 Embedding 相似度，强调去重不足与去重过度的双重风险。隐私和去污染部分分别讨论结构化 PII、命名实体、API Key 等机密检测，以及评测集 N-gram 指纹隔离。最后，章节通过匿名化复合案例和三档团队配置说明清洗管线的落地路径。读者应能够根据数据规模、团队资源和目标模型能力，设计具备可追溯、可抽检、可迭代能力的文本清洗方案。
+
+## 关键词
+
+数据清洗；去重；MinHash；PII 脱敏；基准去污染；质量评分；文本标准化；人工抽检
+
+## 学习目标
+
+- 能够解释重复、低质量文本、PII 和基准污染对预训练模型的影响。
+- 能够组合规则过滤、模型评分和人工抽检形成分层清洗流程。
+- 能够区分精确去重、模糊去重和语义去重的适用边界。
+- 能够设计结构化 PII、API Key 和评测污染的检测与隔离策略。
+- 能够根据团队规模选择轻量级、标准或平台级清洗方案。
+
 ## 开篇：一批"看起来很干净"的数据，为何让模型开始复读？
 
-某团队在完成了第4章描述的精心数据采集之后，信心满满地启动了一个 7B 参数中文基座模型的预训练。训练过程非常稳定——Loss 曲线平滑下降，GPU 利用率保持在 90% 以上，一切指标都符合预期。直到第一次基准评测的结果出来，团队发现了一个令人困惑的现象：模型在续写任务中会反复生成完全相同的句子，有时一段回复里同一句话重复了三四遍；更奇怪的是，给模型一个简单的触发词，它竟然能够背出某电商平台商品描述的完整格式，逐字不差。
+以下为匿名化复合案例。某团队在完成了第4章描述的精心数据采集之后，启动了一个 7B 参数中文基座模型的预训练。训练过程非常稳定——Loss 曲线平滑下降，GPU 利用率保持在 90% 以上，一切指标都符合预期。直到第一次基准评测的结果出来，团队发现了一个令人困惑的现象：模型在续写任务中会反复生成完全相同的句子，有时一段回复里同一句话重复了三四遍；更奇怪的是，给模型一个简单的触发词，它竟然能够背出某电商平台商品描述的完整格式，逐字不差。
 
 这是典型的**数据重复导致的过拟合**。在排查过程中，工程师发现训练数据中有一个大型电商平台的商品描述语料，通过不同的 URL 路径被爬取了数十次，导致同一类商品描述格式在训练集中出现了数万次之多。尽管在数据接入时做了基于 URL 的精确去重，但这些内容的 URL 不同（不同商品的 URL、不同时间爬取同一商品的归档 URL），因此精确去重完全没有发现这个问题。
 
-这个案例说明了一个核心命题：**清洗不是"删脏数据"，而是构建训练数据质量上限的工程体系。** 从这个意义上讲，清洗章是全书工程密度最高的核心章节。
+这个案例说明了一个核心命题：**清洗不是简单删除低质量数据，而是构建训练数据质量上限的工程体系。** 从这个意义上讲，清洗章是文本预训练数据工程的核心章节之一。
 
 ---
 
-## 5.1 为什么清洗章是全书旗舰章
+## 5.1 为什么清洗决定训练数据质量上限
 
 ### 5.1.1 清洗投入与训练收益的非线性关系
 
-FineWeb 项目（Penedo et al. 2024）给出了一个量化答案：针对同样规模的 Common Crawl 数据，不同的清洗策略会带来相差数倍的训练效果差异。使用精细多阶段清洗管线处理的数据，在下游基准评测上的表现，比使用简单规则清洗的数据高出 5-12 个百分点——而这种差距，无法仅靠增加训练算力弥补。
+FineWeb 项目（Penedo et al. 2024）给出了一个量化答案：针对同样规模的 Common Crawl 数据，不同的清洗策略会带来显著训练效果差异。使用精细多阶段清洗管线处理的数据，在下游基准评测上的表现优于简单规则清洗的数据。具体收益会随模型规模、语料结构和评测集而变化，不能脱离实验设置直接复用。
 
-这一发现颠覆了早期"数据量足够大，质量不那么重要"的粗放思维。在算力资源有限的情况下（几乎所有团队都面临这一约束），**把有限算力用在高质量数据上，永远优于把同等算力用在垃圾数据上**。从这个视角来看，数据清洗工程投资的 ROI，是整个 LLM 研发链路中最高的环节之一。
+这一发现修正了早期"数据量足够大，质量不那么重要"的粗放思维。在算力资源有限的情况下，**把有限算力用在高质量数据上，通常优于把同等算力用在低质量数据上**。从这个视角来看，数据清洗工程投资的 ROI，是 LLM 研发链路中较高的环节之一。
 
 ### 5.1.2 上游缺陷如何在训练阶段被指数放大
 
@@ -36,7 +52,7 @@ FineWeb 项目（Penedo et al. 2024）给出了一个量化答案：针对同样
 
 ![图5-1：清洗与去污染全景流程图](../../images/part2/cleaning_pipeline_overview.png)
 
-*图5-1：清洗与去污染全景流程图 —— 多阶段质量闸门从原始语料（100%）精炼至最终训练语料（~15-25%），每阶段标注了典型的过滤比例。*
+*图5-1：清洗与去污染全景流程图 —— 多阶段质量闸门从原始语料（100%）精炼至最终训练语料（约15-25%），每阶段标注了典型的过滤比例。来源：本书自绘；Alt text：清洗与去污染全景流程图，展示规则过滤、模型评分、去重、PII 脱敏、去污染和人工抽检的顺序关系。*
 
 ### 5.2.1 第一道闸门：规则过滤
 
@@ -48,6 +64,10 @@ FineWeb 项目（Penedo et al. 2024）给出了一个量化答案：针对同样
 
 **重复行比例过滤**专门针对"模板噪声"——许多低质量网页会在同一页面内多次重复导航栏、版权声明、广告区域等内容，导致文档内大量行完全一致。若重复行占比超过 30%，文档可被视为低质量候选，触发进一步审查或直接丢弃。
 
+代码清单5-1展示了多规则启发式质量过滤器的示意实现。
+
+**代码清单5-1：多规则启发式质量过滤示意代码**
+
 ```python
 import re
 from typing import Tuple
@@ -86,9 +106,9 @@ class HeuristicQualityFilter:
 
 规则过滤能快速过滤"明显"的低质量内容，但面对一段语法完全正确、格式也没有问题、但实质上是无意义的广告堆砌或 SEO 软文，规则过滤往往无能为力。这时需要**模型过滤（Model-Based Filtering）**——利用训练好的评分模型，对文档的语言质量进行更细粒度的判断。
 
-**困惑度过滤（Perplexity Filter）**是目前最广泛采用的模型过滤方法。使用 **KenLM (Heafield 2011) n-gram 语言模型**（而非神经网络模型）计算困惑度时，可以将文本质量量化：高质量的新闻和百科文本困惑度通常在 100-300 之间；普通通顺网页文本在 200-500 之间；乱码、机器翻译、广告堆砌等低质量内容往往超过 500。值得注意的是，困惑度并非越低越好——困惑度极低（低于 50）的文本可能是高度同质化的样板文本（如格式几乎固定的法律条文或商品说明），也需要额外关注。（注：若改用神经网络参照模型如 LLaMA-7B 计算，相同文本的 PPL 数值会显著缩小至 20–150 区间，详见 Ch07 §7.3.1，两者不可混用阈值。）
+**困惑度过滤（Perplexity Filter）**是目前最广泛采用的模型过滤方法。使用 **KenLM (Heafield 2011) n-gram 语言模型**（而非神经网络模型）计算困惑度时，可以将文本质量量化：高质量的新闻和百科文本困惑度通常在 100-300 之间；普通通顺网页文本在 200-500 之间；乱码、机器翻译、广告堆砌等低质量内容往往超过 500。值得注意的是，困惑度并非越低越好——困惑度极低（低于 50）的文本可能是高度同质化的样板文本（如格式几乎固定的法律条文或商品说明），也需要额外关注。（注：若改用神经网络参照模型如 LLaMA-7B 计算，相同文本的 PPL 数值会显著缩小至 20-150 区间，见第7章 7.3.1节，两者不可混用阈值。）
 
-**质量分类器（Quality Classifier）**是 RefinedWeb (Penedo et al. 2023)、Dolma (Soldaini et al. 2024) 等顶级数据集采用的进阶手段：用一个经过人工标注的高质量文档 vs 低质量文档数据集，微调一个 fastText 或轻量级 BERT 分类器，将质量打分做成强监督的二分类或五分类问题。这种方法在覆盖"规则和困惑度都无法发现但人类能判断"的质量问题上有显著优势，代价是需要一定量的人工标注成本来构建训练集。
+**质量分类器（Quality Classifier）**是 RefinedWeb (Penedo et al. 2023)、Dolma (Soldaini et al. 2024) 等代表性数据集采用的进阶手段：用一个经过人工标注的高质量文档 vs 低质量文档数据集，微调一个 fastText 或轻量级 BERT 分类器，将质量打分做成强监督的二分类或五分类问题。这种方法在覆盖"规则和困惑度都无法发现但人类能判断"的质量问题上有显著优势，代价是需要一定量的人工标注成本来构建训练集。
 
 ### 5.2.3 三阶段协同：规则、模型、人工的合理分工
 
@@ -112,6 +132,10 @@ class HeuristicQualityFilter:
 
 **繁简体处理策略**对中文大模型有特别的重要性。训练全参数的多方言中文模型时，繁体字和简体字应当共存；但若目标是一个专注于大陆简体中文的模型，建议对繁体语料进行简体转换（opencc 库可以实现高质量的繁简转换）。需注意：机械的繁简转换会丢失一些台湾、香港等地区特有的词汇和表达，对于涉及这些地区的垂直领域模型，需要谨慎处理而非一刀切简繁归一。
 
+代码清单5-2展示了文本标准化的示意实现。
+
+**代码清单5-2：文本标准化处理示意代码**
+
 ```python
 import unicodedata, re
 
@@ -173,6 +197,10 @@ def normalize_text(text: str, to_simplified: bool = False) -> str:
 
 **第三步：LSH 分桶**。将 128 维签名向量分成 b 个 band（每 band 含 r = 128/b 个维度）。两个文档只要在任意一个 band 内的签名完全匹配，就被放入同一个"候选桶"，后续只需对同桶内的文档对进行精确相似度计算。调节 b 和 r 可以控制实际的相似度检测阈值与召回率之间的权衡。
 
+代码清单5-3展示了 MinHash LSH 模糊去重的示意实现，生产环境应将桶结构持久化到分布式存储或流式计算框架中。
+
+**代码清单5-3：MinHash LSH 模糊去重示意代码**
+
 ```python
 import hashlib, numpy as np
 from typing import Set
@@ -244,6 +272,10 @@ PII 检测通常采用**规则 + NER 模型**的组合方案：
 
 **正则表达式规则**对于结构化 PII（手机号、邮箱、身份证、IP 地址等）有极高的查全率，且运行速度极快，适合作为第一道检测层：
 
+代码清单5-4展示了结构化 PII 检测与脱敏的示意实现。
+
+**代码清单5-4：结构化 PII 检测与脱敏示意代码**
+
 ```python
 import re
 
@@ -282,6 +314,10 @@ Benchmark Contamination（基准污染），是指训练数据中意外混入了
 
 目前最常用的去污染方案是 **N-gram 重叠检测**：将所有评测集（MMLU (Hendrycks et al. 2021)、GSM8K (Cobbe et al. 2021)、HumanEval (Chen et al. 2021)、CEVAL 等）的题目和答案预先计算 13-gram 指纹集合，然后对训练数据中的每个文档进行扫描，只要与任何评测集的 13-gram 匹配率超过 50%，就将该文档标记为"污染风险"并移入隔离区（不是直接删除，而是先隔离，以便后续审查）：
 
+代码清单5-5展示了评测集 N-gram 指纹构建与重叠率计算的示意实现。
+
+**代码清单5-5：评测集 N-gram 指纹与污染率计算示意代码**
+
 ```python
 from collections import Counter
 
@@ -315,6 +351,10 @@ def contamination_score(doc: str, eval_ngrams: set[str], n=13) -> float:
 
 清洗不应该是"非黑即白"的二元判断，而应当对每个文档给出一个多维质量评分向量，用于后续的分层采样：
 
+代码清单5-6展示了多维文档质量评分对象的示意定义。
+
+**代码清单5-6：多维文档质量评分对象示意代码**
+
 ```python
 from dataclasses import dataclass
 
@@ -345,7 +385,7 @@ class DocumentQualityScore:
 
 ![图5-2：质量过滤漏斗与抽检闭环图](../../images/part2/quality_filter_funnel_loop.png)
 
-*图5-2：质量过滤漏斗与抽检闭环 —— 左侧漏斗展示每阶段的数据留存率，右侧闭环展示人工抽检如何驱动过滤规则的持续迭代优化。*
+*图5-2：质量过滤漏斗与抽检闭环 —— 左侧漏斗展示每阶段的数据留存率，右侧闭环展示人工抽检如何驱动过滤规则的持续迭代优化。来源：本书自绘；Alt text：质量过滤漏斗与抽检闭环图，展示规则过滤、模型评分、去重、人工抽检和规则回写之间的循环关系。*
 
 每个清洗批次完成后，固定执行以下"质量快照"流程：随机抽取 500 条数据，由数据工程师进行人工标注（OK / 噪声 / PII 遗漏 / 误杀的高质量内容 / 近似重复漏网），统计各类错误的发生率，并追踪是哪个过滤步骤导致了该错误（误杀 or 漏检）。当某类错误率连续两个批次超过 5%，必须触发对应规则或模型阈值的审查和更新。这套机制将清洗管线从"一次性工程产物"转变为"持续迭代的质量引擎"。
 
@@ -368,7 +408,9 @@ class DocumentQualityScore:
 
 **表5-2：清洗动作对训练效果影响对照**
 
-| 清洗动作 | 不做时的典型模型症状 | 完整做时的预期提升 | 成本周期 |
+注：表5-2中的提升幅度为截至 2026-06 的工程经验示例，实际收益取决于语料结构、模型规模、评测集、清洗阈值和训练配置，不应作为跨项目固定承诺。
+
+| 清洗动作 | 不做时的典型模型症状 | 完整做时的可能收益（示例） | 成本周期 |
 | :--- | :--- | :--- | :--- |
 | 语言过滤 | 模型混用语言；中文回答夹杂英文 | 语言一致性提升 | CPU，数小时 |
 | 启发式规则过滤 | 模型输出格式混乱（HTML标签/广告词） | 输出流畅度提升 5-10% | CPU，数小时 |
@@ -382,7 +424,9 @@ class DocumentQualityScore:
 
 ## 5.8 大规模工程案例与踩坑复盘
 
-### 案例一：清洗过度导致知识损失——一次"阈值调过头"的代价
+以下案例均为匿名化复合案例，数据规模、比例和周期用于说明工程口径；截至 2026-06，实际数值会随语料来源、清洗规则、模型规模和评测方法变化。
+
+### 案例一：清洗过度导致知识损失——一次"阈值调过头"的代价（匿名化复合案例）
 
 **背景**：某团队在完成了首轮 7B 模型预训练后，计划对数据清洗管线进行升级，目标是进一步提升训练数据的"纯净度"。团队将启发式过滤规则提升了标准：最小文档长度从 200 字提升到 800 字、PPL 阈值从 500 下调至 150、MinHash 相似度阈值从 0.85 下调至 0.6。处理后，语料库从原来的 500GB 缩减至 120GB。
 
@@ -394,11 +438,11 @@ class DocumentQualityScore:
 
 ---
 
-### 案例二：PII 遗漏引发的安全事故
+### 案例二：PII 遗漏引发的安全风险（匿名化复合案例）
 
-**背景**：某公司在将一套面向企业用户的 AI 助手产品上线后，很快收到用户反馈：在询问某些技术相关问题时，模型会在生成的代码示例中输出看起来像真实 API Key 的字符串（格式为 `sk-xxxxxxxxxxxxxxxxxxxxxxxx`，与 OpenAI API Key 格式完全一致）。
+**背景**：某公司在将一套面向企业用户的 AI 助手产品上线后，很快收到用户反馈：在询问某些技术相关问题时，模型会在生成的代码示例中输出看起来像真实 API Key 的字符串（格式为 `sk-xxxxxxxxxxxxxxxxxxxxxxxx`）。
 
-**T+0（事故发生）**：安全团队立即展开排查，确认模型输出的是**真实有效的 API Key**，来自训练数据中某个 GitHub 仓库里被提交的硬编码密钥。由于 PII 脱敏管线只覆盖了手机号、邮箱、身份证等常规类型，未将 API Key 纳入检测范围，这批密钥在训练过程中被完整学习。
+**T+0（风险确认）**：安全团队立即展开排查，确认模型输出与真实密钥格式高度一致，疑似来自训练数据中某个 GitHub 仓库里被提交的硬编码密钥。由于 PII 脱敏管线只覆盖了手机号、邮箱、身份证等常规类型，未将 API Key 纳入检测范围，这批密钥在训练过程中被完整学习。
 
 **T+1（紧急处置）**：安全团队通知密钥所属服务商进行紧急吊销，同时下线模型接受审查。经排查，共发现约 8400 条 GitHub 提交记录中包含各类 API Key 或密码硬编码，覆盖 AWS、OpenAI、GitHub、数据库连接字符串等多种类型，均未被现有脱敏管线捕获。
 
@@ -416,6 +460,8 @@ class DocumentQualityScore:
 
 轻量级方案聚焦于"守住底线"，用最少的工程投入过滤掉危害最大的缺陷：
 
+**表5-3：轻量级清洗方案最小可行组合**
+
 | 步骤 | 实现方案 | 工具 | 是否必须 |
 |:--- |:--- |:--- |:--- |
 | 语言过滤 | FastText 识别，置信度 > 0.8 | fasttext | ★ 必须 |
@@ -435,9 +481,9 @@ class DocumentQualityScore:
 
 在轻量级方案的基础上，补充：**KenLM 困惑度过滤**（拟合 5-gram 语言模型，针对目标语言训练），过滤 PPL > 500 的文档；**MinHash LSH 模糊去重**（Jaccard 阈值 0.8，128 维签名，16 个 band）；**NER 模型辅助 PII**（spaCy 中文模型，覆盖人名/地址/机构等规则难以枚举的 PII 类型）；**领域分层阈值**（为代码、学术论文等特殊内容类型配置独立的过滤参数，避免"通杀"）。这套方案需要约 2-4 周工程实现，并需要一定的 GPU 资源用于 NER 模型的批量推理，是中型团队最推荐的完整方案。
 
-### 5.9.3 旗舰方案（10+ 人数据平台团队，数据规模 > 10TB）
+### 5.9.3 平台级方案（10+ 人数据平台团队，数据规模 > 10TB）
 
-旗舰方案面向工业级大规模数据处理，在标准方案之上进一步引入：**分布式处理架构**（Ray Data 或 Spark on Kubernetes 实现所有步骤的完全分布式化，支持数十至上百节点水平扩展）；**自定义质量分类器**（用人工标注的 10,000 条高/低质量样本对，微调 BERT 或 fastText 分类器，将文档质量判断做为强监督的分类任务）；**全量评测集去污染**（维护包含所有主流评测集的 N-gram 指纹库，并定期更新）；**自动化质量快照仪表盘**（每批次清洗完成后自动生成质量报告，展示各阶段过滤率、质量分分布、PII 发现率等关键指标）。完整旗舰方案的搭建周期通常需要 2-4 个月，但一旦建立，可以支持公司所有大模型项目的语料质量基础设施共享复用。
+平台级方案面向工业级大规模数据处理，在标准方案之上进一步引入：**分布式处理架构**（Ray Data 或 Spark on Kubernetes 实现所有步骤的完全分布式化，支持数十至上百节点水平扩展）；**自定义质量分类器**（用人工标注的 10,000 条高/低质量样本对，微调 BERT 或 fastText 分类器，将文档质量判断做为强监督的分类任务）；**全量评测集去污染**（维护包含所有主流评测集的 N-gram 指纹库，并定期更新）；**自动化质量快照仪表盘**（每批次清洗完成后自动生成质量报告，展示各阶段过滤率、质量分分布、PII 发现率等关键指标）。完整平台级方案的搭建周期通常需要 2-4 个月，但一旦建立，可以支持公司所有大模型项目的语料质量基础设施共享复用。
 
 
 
@@ -445,7 +491,7 @@ class DocumentQualityScore:
 
 ## 本章小结
 
-本章作为全书工程密度最高的旗舰章节，从"清洗为何构成训练数据质量上限"出发，按照清洗生命周期的顺序，系统介绍了规则过滤、模型评分、精确去重、MinHash 模糊去重、PII 脱敏与基准去污染的完整技术体系。两张表格（表5-1 缺陷-检测-代价矩阵、表5-2 清洗动作效果对照）为工程师提供了可直接参考的决策工具。两个案例复盘——"清洗过度导致知识损失"和"PII 遗漏引发安全事故"——从正反两个方向印证了清洗体系的精细化配置要求。
+本章围绕"清洗为何构成训练数据质量上限"展开，按照清洗生命周期的顺序，系统介绍了规则过滤、模型评分、精确去重、MinHash 模糊去重、PII 脱敏与基准去污染的完整技术体系。两张表格（表5-1 缺陷-检测-代价矩阵、表5-2 清洗动作效果对照）为工程师提供了可直接参考的决策工具。两个匿名化复合案例——"清洗过度导致知识损失"和"PII 遗漏引发安全风险"——从正反两个方向印证了清洗体系的精细化配置要求。
 
 携带这套完整的清洗技术体系，我们已经具备了将原始语料精炼为高质量训练数据的完整能力。下一章将在清洗完成的数据上，继续探讨预训练数据工程的最后一公里：**第6章 分词、序列化与高效加载**——把干净的文本转化为 GPU 可以高效消费的 Token 序列。
 
@@ -474,4 +520,3 @@ Cobbe K, Kosaraju V, Bavarian M, Chen M, Jun H, Kaiser L, Plappert M, Tworek J,
 Hendrycks D, Burns C, Basart S, Zou A, Mazeika M, Song D, Steinhardt J (2021) Measuring Massive Multitask Language Understanding (MMLU). In: International Conference on Learning Representations.
 
 Chen M, Tworek J, Jun H, Yuan Q, Pinto H P d O, Kaplan J, Edwards H, Burda Y, Joseph N, Brockman G, others (2021) Evaluating Large Language Models Trained on Code (HumanEval). arXiv preprint arXiv:2107.03374.
-
diff --git a/docs/zh/part2/ch06_tokenization_loading.md b/docs/zh/part2/ch06_tokenization_loading.md
index 753c3b88..5fdd6255 100644
--- a/docs/zh/part2/ch06_tokenization_loading.md
+++ b/docs/zh/part2/ch06_tokenization_loading.md
@@ -1,12 +1,28 @@
 # 第6章 分词、序列化与高效加载
 
+## 摘要
+
+本章讨论清洗后的文本如何被转换为可供大模型高效训练的输入管道，覆盖分词器设计、数据格式选择、序列 Packing、多源混采、DataLoader 配置、缓存策略和分布式读取。章节首先通过匿名化复合案例说明 I/O 瓶颈如何导致 GPU 空转和训练成本浪费，随后比较 BPE、WordPiece 与 SentencePiece 的工程特性，并分析词表大小、领域词表扩充和多语言平衡对训练效率与能力分布的影响。序列化部分比较 JSONL、Parquet、Arrow、MDS、WebDataset 与 memmap 等格式，强调离线分词和二进制 shard 对吞吐的作用。后半章进一步讨论 Packing、温度采样、课程学习和 Smoke Test，并给出多节点读取的 rank-aware 配置。读者应能够为不同规模的预训练任务设计稳定、可诊断、成本可控的输入管道。
+
+## 关键词
+
+分词；Tokenizer；序列化；DataLoader；MDS；Packing；数据混采；吞吐诊断
+
+## 学习目标
+
+- 能够比较 BPE、WordPiece 和 SentencePiece 在大模型输入管道中的工程取舍。
+- 能够解释词表大小、领域词表扩充和多语言采样对模型训练的影响。
+- 能够选择适合预训练规模的数据格式、shard 策略和离线分词方案。
+- 能够通过 Smoke Test、GPU 利用率、I/O 监控和 Profiler 定位输入瓶颈。
+- 能够设计多节点分布式读取方案，避免重复读取、NFS 瓶颈和全局 shuffle 失效。
+
 ## 开篇：一次"数据管线比模型慢"的训练事故
 
-某团队在启动 13B 参数模型的预训练时，申请了 64 张 A100 GPU 组成的计算集群，按照 H100 价格的折算，这套集群的租用成本约为每小时 1.6 万元人民币。训练在第 2 小时开始出现异常：`nvidia-smi` 显示 GPU 利用率稳定在 **38%** 左右，而不是预期的 85% 以上。初步排查认为是模型配置问题——直到工程师打开 `iostat` 监控，才发现磁盘 I/O 已经跑满：读速度维持在磁盘上限的 100%，但 DataLoader 仍然追不上 GPU 的消费速度。
+以下为匿名化复合案例，成本、利用率和吞吐数字为截至 2026-06 的估算示例，实际价格取决于云厂商、地区、实例类型、采购折扣和训练配置。某团队在启动 13B 参数模型的预训练时，申请了 64 张 A100 GPU 组成的计算集群，按照高端 GPU 云实例的价格折算，这套集群的租用成本约为每小时 1.6 万元人民币。训练在第 2 小时开始出现异常：`nvidia-smi` 显示 GPU 利用率稳定在 **38%** 左右，而不是预期的 85% 以上。初步排查认为是模型配置问题——直到工程师打开 `iostat` 监控，才发现磁盘 I/O 已经跑满：读速度维持在磁盘上限的 100%，但 DataLoader 仍然追不上 GPU 的消费速度。
 
 根本原因很快被定位：团队将清洗好的语料存放在普通 HDD 阵列上，每个 shard 是一个压缩的 `.jsonl.gz` 文件，DataLoader 需要在运行时实时解压和分词，导致 CPU 和磁盘双双成为瓶颈。最终，该团队将训练暂停了整整 18 个小时，重新对所有数据进行离线分词和序列化为 MDS 格式（Mosaic Data Shard），迁移到 NVMe SSD 存储，才将 GPU 利用率恢复到 88%。
 
-**代价：约 3 万元算力浪费，外加 18 小时的工程延误。** 而这个问题完全可以在训练启动前 1 天的 smoke test 阶段被发现。
+**代价：约 3 万元算力浪费，外加 18 小时的工程延误。** 该估算用于说明输入管道瓶颈的成本量级，实际损失需按真实集群单价、训练暂停策略和排队时间重新核算。而这个问题完全可以在训练启动前 1 天的 smoke test 阶段被发现。
 
 这个案例说明了本章的核心命题：**数据输入管道（Input Pipeline）的效率，是预训练中最容易被低估、一旦出问题代价最高的工程环节之一。** 它处于"清洗已完成，训练还没开始"的灰色地带——既不属于数据工程的关注重点，也不属于训练系统的调优范围，结果往往被双方忽视，直到真实的算力浪费产生才被迫正视。
 
@@ -16,9 +32,9 @@
 
 ### 6.1.1 GPU 空转的隐性成本
 
-在大规模预训练场景下，GPU 集群的租用成本通常以小时计，且居高不下（H100 SXM 单卡按需价格约 $3-4/小时，80 卡集群每小时成本超过 240 美元）。在这种成本结构下，"GPU 利用率"不再只是一个性能指标，而是直接换算为财务损耗的经济指标——每降低 10% 的 GPU 利用率，就意味着有 10% 的算力支出被浪费在"等待数据"上，没有产生任何实际的梯度更新。
+在大规模预训练场景下，GPU 集群的租用成本通常以小时计，且居高不下。截至 2026-06，H100/A100 等高端 GPU 的云端按需价格会因地区、供应商、实例规格和采购协议大幅波动；本章涉及的单价只作为成本估算示例，实际价格应以云厂商公告或合同为准。在这种成本结构下，"GPU 利用率"不再只是一个性能指标，而是直接换算为财务损耗的经济指标——每降低 10% 的 GPU 利用率，就意味着有 10% 的算力支出被浪费在"等待数据"上，没有产生任何实际的梯度更新。
 
-理论上，一个配置合理的 LLM 训练系统，其 GPU 利用率（更精确的指标是 **Model FLOPS Utilization，MFU**）应当保持在 40-50% 以上（考虑到通信和计算重叠后，顶级基础设施也很少超过 60%）。如果 MFU 持续低于 30%，几乎可以断定数据管线是瓶颈之一。
+理论上，一个配置合理的 LLM 训练系统，其 GPU 利用率（更精确的指标是 **Model FLOPS Utilization，MFU**）应当保持在 40-50% 以上（考虑到通信和计算重叠后，高性能基础设施也很少超过 60%）。如果 MFU 持续低于 30%，几乎可以断定数据管线是瓶颈之一。
 
 ### 6.1.2 从数据格式到 GPU 的全链路延迟拆解
 
@@ -45,6 +61,11 @@
 目前主流大模型采用的分词算法以三种为主：
 
 **BPE（Byte Pair Encoding）** (Sennrich et al. 2016) 是最广泛使用的算法，GPT 系列（包括 ChatGPT、GPT-4）均基于此。其核心思想是从字符（或字节）级别出发，反复合并出现频率最高的相邻 token 对。
+
+代码清单6-1展示了 BPE 合并过程的简化伪代码。
+
+**代码清单6-1：BPE 合并过程简化伪代码**
+
 ```python
 # BPE 合并原理伪代码
 def bpe_train(corpus, num_merges):
@@ -57,7 +78,7 @@ def bpe_train(corpus, num_merges):
 ```
 BPE 的字节级变体（Byte-level BPE，如 GPT-2 的 tiktoken）通过将原始字节而非 Unicode 字符作为起始单元，彻底解决了 OOV 问题，被 LLaMA 2/3、Mistral 等模型广泛采用。
 
-**WordPiece** 是 BERT 的分词方案，与 BPE 极其相似，但合并标准并非绝对频率，而是**基于语言模型的最大似然估计（Likelihood）**。WordPiece 在合并 $A$ 和 $B$ 时，考察的是 $\frac{P(AB)}{P(A)P(B)}$ 的得分（类似互信息）。这意味着如果 $A$ 和 $B$ 各自单独出现的概率极低，但它们凑在一起出现的概率极高，WordPiece 也会果断将它们合并。
+**WordPiece** 是 BERT 的分词方案，与 BPE 较为相似，但合并标准并非绝对频率，而是**基于语言模型的最大似然估计（Likelihood）**。WordPiece 在合并 $A$ 和 $B$ 时，考察的是 $\frac{P(AB)}{P(A)P(B)}$ 的得分（类似互信息）。这意味着如果 $A$ 和 $B$ 各自单独出现的概率较低，但它们一起出现的概率较高，WordPiece 会倾向于将它们合并。
 
 **OOV（Out-of-Vocabulary）危机与未登录词问题**：
 在传统的基于词级（Word-level）的旧时代分词器中，如果遇到未被记录在词表中的生僻字或罕见词，模型通常会抛出一个代表未知的 `<UNK>`（Out-of-Vocabulary）占位符。这在医学、法律等专业领域是灾难性的：一段含有复杂化学式的文本会变成满屏的 `<UNK>`。而 BPE 和 WordPiece 这种基于 Subword 的方案，在遇到未见过的单词时，会一直向下拆分为更基础的子词甚至单字母/单字节。虽然增加了序列长度，但永远不会出现真正的 OOV 截断，保证了信息的无损传入。
@@ -66,6 +87,10 @@ BPE 的字节级变体（Byte-level BPE，如 GPT-2 的 tiktoken）通过将原
 
 对于中文大模型，推荐以 **Byte-level BPE**（tiktoken 实现）为基础方案，词表大小建议在 **64K-100K** 之间——这一区间在中文字符覆盖率（中文汉字约 5 万字，基础常用字约 3500 字）和嵌入矩阵参数量之间取得了合理平衡。词表过小（32K）会导致大量中文汉字被切分为字节级别的多个 token，严重增加序列长度；词表过大（200K+）则会使嵌入矩阵参数量过于庞大，影响训练效率。
 
+代码清单6-2展示了使用 `tiktoken` 进行离线批量分词的示意实现。
+
+**代码清单6-2：离线批量分词示意代码**
+
 ```python
 # 使用 tiktoken 进行离线批量分词（推荐用于预处理阶段）
 import tiktoken, json
@@ -101,7 +126,11 @@ def tokenize_document(doc: dict, max_length: int = 4096) -> dict | None:
 
 **跨语言词表平衡** 对多语言基座模型（如 BLOOM、mT5、Qwen）是另一个关键挑战。若词表直接在多语言语料上联合训练，高资源语言（英文）会因其高频率占据更多词表空间，低资源语言（如泰语、阿拉伯语）的词汇被严重压缩，出现所谓"词表诅咒"（Vocabulary Curse）——这些语言的文本在模型看来是一串几乎无意义的字节碎片，导致低资源语言的理解和生成能力远低于高资源语言。
 
-解决方案是在训练分词器时对不同语言的语料进行**上采样均衡**：将每种目标语言的训练文本采样到大致相同的 token 数量（或使用温度参数 T=3-5），确保每种语言都获得足够的词表"席位"；同时通过 SentencePiece 的 `character_coverage=0.9999` 参数，确保每种语言的基本字符集（哪怕频率极低）都被纳入词表。这是 mT5、BLOOM 等顶级多语言模型词表设计的核心工程实践。
+解决方案是在训练分词器时对不同语言的语料进行**上采样均衡**：将每种目标语言的训练文本采样到大致相同的 token 数量（或使用温度参数 T=3-5），确保每种语言都获得足够的词表"席位"；同时通过 SentencePiece 的 `character_coverage=0.9999` 参数，确保每种语言的基本字符集（哪怕频率很低）都被纳入词表。这是 mT5、BLOOM 等多语言模型词表设计中的常见工程实践。
+
+代码清单6-3展示了 SentencePiece 多语言词表训练的示意配置。
+
+**代码清单6-3：SentencePiece 多语言词表训练配置片段**
 
 ```python
 # SentencePiece 多语言词表训练（示意）
@@ -132,7 +161,7 @@ spm.SentencePieceTrainer.train(
 | 格式 | 类型 | 顺序读速度 | 随机访问 | 压缩支持 | 跨框架支持 | 适用场景 |
 | :--- | :--- | :--- | :--- | :--- | :--- | :--- |
 | **JSONL (.jsonl)** | 文本行 | 慢（需 JSON 解析） | 不支持 | ✗（需 .gz 组合）| 极好 | 数据交换、调试 |
-| **Parquet** | 列式二进制 | 快（列裁剪） | 支持（行组级） | √ Snappy/Zstd | 很好（Spark/pandas）| 批处理分析、Ch05 输出 |
+| **Parquet** | 列式二进制 | 快（列裁剪） | 支持（行组级） | √ Snappy/Zstd | 很好（Spark/pandas）| 批处理分析、第5章输出 |
 | **Apache Arrow / Feather** | 行式二进制 | 极快（零拷贝） | 支持 | √ LZ4/Zstd | 好（PyArrow）| CPU→GPU 中间层 |
 | **MDS（Mosaic）** | Shard二进制 | 极快 | Shard级 | √ Zstd | 好（Streaming Datasets）| LLM 预训练首选 |
 | **WebDataset (.tar)** | Tar打包 | 快（流式）| Shard级 | √（内部文件压缩）| 好（Torchvision）| 多模态训练 |
@@ -156,6 +185,10 @@ Shuffle 是预训练数据准备中的另一个关键步骤。未经 shuffle 的
 
 **序列 Packing（Sequence Packing）** 是解决这一问题的标准工程手段：将多个短文档拼接在同一个序列中，用特殊的 `[EOS]` token 作为文档边界，使每个序列的有效 token 比例接近 100%。Attention Mask 中对应地在 `[EOS]` 处切断跨文档的注意力（避免文档 A 的末尾影响文档 B 的开头的 attention），保持各文档的语义独立性。
 
+代码清单6-4展示了贪心序列 Packing 的示意实现。
+
+**代码清单6-4：贪心序列 Packing 示意代码**
+
 ```python
 def greedy_pack_sequences(
     token_id_lists: list[list[int]],
@@ -189,7 +222,7 @@ def greedy_pack_sequences(
     return packed
 ```
 
-实践数据表明，对于包含大量短文档（平均长度 < 512 token）的训练集，启用 Packing 可以使有效 Token 吞吐量（Tokens/s）提升 **40-80%**，折算成算力等效节省相当显著。
+实践数据表明，对于包含大量短文档（平均长度 < 512 token）的训练集，启用 Packing 可以使有效 Token 吞吐量（Tokens/s）提升 **40-80%**。该区间为截至 2026-06 的经验性示例，实际收益取决于文档长度分布、max sequence length、attention mask 实现和硬件配置。
 
 ### 6.3.2 多源混采：温度权重与领域比例控制
 
@@ -231,6 +264,10 @@ PyTorch 的 `DataLoader` 提供了多个直接影响 I/O 吞吐的参数，以
 
 **`prefetch_factor`**：每个 worker 提前预加载的 batch 数量（默认为 2）。适当增大（如 4-8）可以隐藏磁盘读取延迟，但会增加 CPU 内存占用。
 
+代码清单6-5展示了基于 MosaicML Streaming Dataset 的 DataLoader 配置示例。
+
+**代码清单6-5：MosaicML Streaming Dataset DataLoader 配置片段**
+
 ```python
 from torch.utils.data import DataLoader
 from streaming import StreamingDataset  # MosaicML Streaming Datasets
@@ -252,12 +289,16 @@ dataloader = DataLoader(
 )
 ```
 
+代码清单6-6展示了基于 `np.memmap` 的二进制 Token ID 数据集示意实现。
+
+**代码清单6-6：基于 np.memmap 的 Token ID 数据集示意代码**
+
 ```python
 # 应对千万级小文件 IO 优化的 Memmap 二进制加载器伪代码
 import numpy as np
 class MemmapDataset(torch.utils.data.Dataset):
     def __init__(self, bin_path, seq_len=4096):
-        # 使用 np.memmap 映射巨大的二进制 .bin 文件 (Raw Token IDs)
+        # 使用 np.memmap 映射大型二进制 .bin 文件 (Raw Token IDs)
         # 完全避免了将整个数据集加载进内存，依靠 OS 的 Page Cache 极速随机读取
         self.seq_len = seq_len
         self.data = np.memmap(bin_path, dtype=np.uint16, mode='r')
@@ -269,7 +310,7 @@ class MemmapDataset(torch.utils.data.Dataset):
 
     def __getitem__(self, idx):
         start_idx = idx * self.seq_len
-        # 切片操作极其轻量，由底层 C 代码和 OS 内存分页完成，吞吐极高
+        # 切片操作较轻量，由底层 C 代码和 OS 内存分页完成，吞吐较高
         chunk = self.data[start_idx : start_idx + self.seq_len]
         return torch.from_numpy(chunk.astype(np.int64))
 ```
@@ -280,7 +321,7 @@ class MemmapDataset(torch.utils.data.Dataset):
 
 ![图6-2：吞吐瓶颈诊断流程图](../../images/part2/io_bottleneck_diagnosis_flow.png)
 
-*图6-2：吞吐瓶颈诊断流程图 —— 从 GPU 利用率异常出发，通过三级决策树定位磁盘 I/O 瓶颈、CPU 预处理瓶颈和 PCIe 传输瓶颈，并给出对应的修复方案。*
+*图6-2：吞吐瓶颈诊断流程图 —— 从 GPU 利用率异常出发，通过三级决策树定位磁盘 I/O 瓶颈、CPU 预处理瓶颈和 PCIe 传输瓶颈，并给出对应的修复方案。来源：本书自绘；Alt text：吞吐瓶颈诊断流程图，展示从 GPU 利用率异常到磁盘 I/O、CPU 预处理和 PCIe 传输排查的决策路径。*
 
 **Step 1 - 确认 GPU 是否在等数据**：运行 `nvidia-smi dmon -s u` 监控 SM 利用率；若 SM 利用率周期性下降到 0 且 `sm_active` 间歇性为 0，说明 GPU 正在等待。同时检查 MFU（Model FLOPS Utilization）指标，若 MFU < 30%，极大概率是数据管线瓶颈。
 
@@ -309,6 +350,10 @@ class MemmapDataset(torch.utils.data.Dataset):
 
 **推荐方案二：MosaicML Streaming 从 S3 流式读取**。这是近年来大型团队越来越流行的方案——数据集存放在 S3/GCS 等对象存储上，每个节点在训练期间通过 `StreamingDataset` 按需下载 shard（下载一个 shard，训练完毕后删除，再下载下一个），本地磁盘只作为缓存层（缓存大小可配置）。这种方案的优势是数据集无需预先拷贝到各节点，新节点可以立即加入训练；局限是需要稳定的网络带宽（每个节点约需 1-2GB/s 的 S3 读取带宽），且网络延迟比本地 SSD 高 5-20 倍，不适合 shard 极小或对延迟敏感的场景。
 
+代码清单6-7展示了多节点分布式训练中的 DataLoader 配置示意。
+
+**代码清单6-7：多节点分布式 DataLoader 配置片段**
+
 ```python
 # 多节点分布式训练中的 DataLoader 配置
 import torch.distributed as dist
@@ -352,11 +397,11 @@ dataloader = DataLoader(
 
 ![图6-1：训练输入管道分层图](../../images/part2/training_input_pipeline_layers.png)
 
-*图6-1：LLM 训练输入管道分层架构 —— 从分词、序列化、数据混采、Packing 到 DataLoader GPU 馈送的五阶段完整路径，底部标注了两个最高频的瓶颈风险点（磁盘 I/O 和 CPU↔GPU 传输）。*
+*图6-1：LLM 训练输入管道分层架构 —— 从分词、序列化、数据混采、Packing 到 DataLoader GPU 馈送的五阶段完整路径，底部标注了两个最高频的瓶颈风险点（磁盘 I/O 和 CPU↔GPU 传输）。来源：本书自绘；Alt text：训练输入管道分层图，展示分词、序列化、混采、Packing、DataLoader 和 GPU 馈送之间的顺序关系。*
 
 ### 案例：从 JSONL+在线分词 到 MDS+离线分词 的迁移收益
 
-接续开篇案例，详细记录该团队完成存储格式迁移后的量化收益对比：
+接续开篇匿名化复合案例，下面记录该团队完成存储格式迁移后的量化收益对比。所有吞吐、时间和成本节省均为示例性参数，实际结果取决于硬件、存储、数据格式、batch size 和框架实现。
 
 **迁移前**（JSONL.gz，HDD，在线分词）：
 - 磁盘读取速度（IPC 读取）：约 180MB/s（HDD 上限）
@@ -370,7 +415,7 @@ dataloader = DataLoader(
 - GPU 利用率：88%
 - 每 1B token 处理时间：约 2,632 秒（约 43 分钟）
 
-**核心收益**：相同训练目标（1T token，7B 模型），迁移前预计耗时约 966 天 GPU 小时，迁移后约 440 天 GPU 小时，**实際算力成本降低约 54%**，工程改动耗时 18 小时（离线重分词 + 存储迁移）ROI 极高。
+**核心收益**：相同训练目标（1T token，7B 模型），迁移前预计耗时约 966 天 GPU 小时，迁移后约 440 天 GPU 小时，**实际算力成本降低约 54%**，工程改动耗时 18 小时（离线重分词 + 存储迁移）。这一收益用于说明 I/O 优化的量级，不能脱离具体硬件和数据分布直接复用。
 
 ### 6.5.1 输入管道优化检查清单
 
@@ -403,9 +448,9 @@ dataloader = DataLoader(
 
 ## 本章小结
 
-本章以一次真实 I/O 瓶颈导致 GPU 空转 62% 的训练事故开篇，系统建立了训练输入管道的完整技术认知。我们详细梳理了分词算法选型（BPE/SentencePiece 的工程权衡）、数据格式选择（从 JSONL 到 MDS/Arrow 的性能跃升）、Packing 策略（消除 Padding 带来的 40-80% 吞吐提升）、温度采样与课程学习的混采策略（表6-2），以及系统化的 I/O 瓶颈诊断三步法（图6-2）。附录中的"输入管道优化检查清单"可直接作为生产级预训练任务的启动前核验工具。
+本章以一个匿名化复合案例说明 I/O 瓶颈如何导致 GPU 空转和成本浪费，系统建立了训练输入管道的完整技术认知。我们详细梳理了分词算法选型（BPE/SentencePiece 的工程权衡）、数据格式选择（从 JSONL 到 MDS/Arrow 的性能跃升）、Packing 策略（消除 Padding 带来的 40-80% 吞吐提升）、温度采样与课程学习的混采策略（表6-2），以及系统化的 I/O 瓶颈诊断三步法（图6-2）。附录中的"输入管道优化检查清单"可直接作为生产级预训练任务的启动前核验工具。
 
-本章与 Ch03（成本治理）的成本视角深度呼应——在 GPU 算力成本极高的预训练专案中，输入管道的工程质量差异可以直接决定数十乃至数百万人民币的算力成本节省。进入下一章，我们将视角从"如何把数据送进模型"转向"如何评价模型用这些数据学到了什么"：**第7章 数据评估、质量闭环与运营迭代**。
+本章与第3章成本治理的视角呼应——在 GPU 算力成本极高的预训练项目中，输入管道的工程质量差异可以直接决定数十乃至数百万人民币的算力成本节省。进入下一章，我们将视角从"如何把数据送进模型"转向"如何评价模型用这些数据学到了什么"：**第7章 数据评估、质量闭环与运营迭代**。
 
 ## 参考文献
 
@@ -422,4 +467,3 @@ Sennrich R, Haddow B, Birch A (2016) Neural Machine Translation of Rare Words wi
 Xue L, Constant N, Roberts A, Kale M, Al-Rfou R, Siddhant A, Barua A, Raffel C (2021) mT5: A Massively Multilingual Pre-trained Text-to-Text Transformer. In: Proceedings of the 2021 Conference of the North American Chapter of the Association for Computational Linguistics, pp 483-498.
 
 Brown T B, Mann B, Ryder N, Subbiah M, Kaplan J, Dhariwal P, Neelakantan A, Shyam P, Sastry G, Askell A, others (2020) Language Models are Few-Shot Learners (GPT-3). Advances in Neural Information Processing Systems 33:1877-1901.
-
diff --git a/docs/zh/part2/ch07_data_operations.md b/docs/zh/part2/ch07_data_operations.md
index 445413e5..b03f958b 100644
--- a/docs/zh/part2/ch07_data_operations.md
+++ b/docs/zh/part2/ch07_data_operations.md
@@ -1,17 +1,33 @@
 # 第7章 数据评估、质量闭环与运营迭代
 
+## 摘要
+
+本章讨论预训练数据在清洗完成后的持续评估、版本治理和运营迭代问题。章节首先通过匿名化复合案例说明“更干净”的数据并不必然带来更好的模型效果，随后建立数据运营（DataOps）的基本框架：离线代理指标、代表性抽样、质量看板、问题样本库、版本对比和上游策略回写。指标部分重点解释困惑度、类型/令牌比率、有毒性与 PII 密度、基准污染和领域覆盖等指标的适用边界，并强调它们只是代理信号，必须与小规模验证器模型和人工抽检结合。后半章给出 5 Whys 根因复盘、周度运营节奏、仪表盘告警和数据资产向 SFT/RAG 复用的路径。读者应能够将数据处理从一次性交付扩展为可追踪、可回滚、可审计的持续运营体系。
+
+## 关键词
+
+数据运营；代理评估；质量闭环；DVC；问题样本库；A/B 测试；数据漂移；仪表盘
+
+## 学习目标
+
+- 能够解释为什么预训练数据需要持续评估和版本化运营。
+- 能够设计 PPL、TTR、PII 密度、基准污染和领域覆盖等离线代理指标。
+- 能够使用问题样本库、DVC 版本和 A/B 测试定位数据变更的模型影响。
+- 能够建立数据质量看板、自动告警和周度运营节奏。
+- 能够将评估结论回写到采集、清洗、SFT 和 RAG 数据资产中。
+
 ## 开篇：一次令人意外的"效果倒退"
 
-在某个 7B 语言模型的研发项目中，数据团队经过两个月的努力，将预训练语料库清洗到了一种近乎"洁癖"的程度。他们严格使用启发式规则排除了所有短文本，用大受好评的困惑度评分去除了所有“非标准语言”，并用高度严格的 MinHash 阈值查重。数据工程师骄傲地宣称：这是迄今为止最干净、最高质量的数据版本。
+以下为匿名化复合案例，指标、时间和数据规模用于说明复盘方法。截至 2026-06，类似项目中的评测波动会受到模型规模、语料配比、训练步数和基准选择影响。某个 7B 语言模型研发项目中，数据团队经过两个月的努力，将预训练语料库清洗到非常严格的程度。他们使用启发式规则排除了大量短文本，用困惑度评分去除了“非标准语言”，并用较低的 MinHash 阈值进行查重。团队认为这是一版更干净、更可控的数据。
 
-然而，基于新版数据训练出的模型（代号 v2.0）在多项基准评测上的表现，竟然全面落后于一个月前用粗糙数据（v1.0）训练的版本。深入排查后，大家才发现几个令人哭笑不得的真相：
+然而，基于新版数据训练出的模型（代号 v2.0）在多项基准评测上的表现，全面落后于一个月前用粗糙数据（v1.0）训练的版本。深入排查后，团队发现了几个重要事实：
 1. 因为剔除了一切带有“大量换行和符号”的文本，模型几乎完全丧失了生成代码和渲染 Markdown 的能力。
 2. 因为剔除了“非标准口语化表达”，模型失去了在对话任务中的共情回应能力，变得像一台冰冷的百科全书。
 3. 严格的去重使得某些极高频事实（如常识地理、基础历史）在训练集中的出现频率过低，导致模型发生了严重的“知识遗忘”。
 
-这次危机给团队上了沉重的一课：**高质量并不是一个静态标准，脱离了模型效果的“单方面洁净”毫无意义。**
+这次复盘给团队带来一个关键结论：**高质量并不是一个静态标准，脱离模型效果的“单方面洁净”并不充分。**
 
-本章将视角从具体的数据处理代码拉回系统工程层面，探讨大模型项目的最终决胜环节——**数据评估与运营迭代**。我们将打破“交出数据就算完工”的传统偏见，建立以离线评估和代理指标驱动的数据治理循环，让数据成为一个随着模型能力增长而进化的持续资产。
+本章将视角从具体的数据处理代码拉回系统工程层面，探讨大模型项目中的**数据评估与运营迭代**。我们将打破“交出数据就算完工”的传统偏见，建立以离线评估和代理指标驱动的数据治理循环，让数据成为一个随着模型能力增长而演进的持续资产。
 
 ---
 
@@ -21,40 +37,40 @@
 
 在传统的深度学习（如图像分类或序列标注）时代，数据集往往被视为静态资产：收集、标注、发布，然后长年冻结。基于这种范式，工程师习惯了“一次性交付”思维。
 
-然而在大语言模型（LLM）的预训练中，数据（Data）与模型（Model）的边界变得模糊。模型的不同成长阶段需要截然不同的数据配方。比如：在冷启动初期（0 - 100B Token），模型迫切需要大规模的广度信息来学习通用语法和基础世界观；而在收敛后期或退火阶段（Cooldown），模型则需要高度稠密的高质量知识材料（数理化推理、代码结构）来拔高质量上限。**一套从头用到尾的静态数据，绝不可能训出 SOTA 模型。**
+然而在大语言模型（LLM）的预训练中，数据（Data）与模型（Model）的边界变得模糊。模型的不同成长阶段需要截然不同的数据配方。比如：在冷启动初期（0-100B Token），模型需要大规模广度信息来学习通用语法和基础世界知识；而在收敛后期或退火阶段（Cooldown），模型则需要高度稠密的高质量知识材料（数理化推理、代码结构）来提高能力上限。**一套从头用到尾的静态数据，很难支撑高水平模型训练。**
 
-这使得数据工程师的角色从“矿工（一次性挖掘）”转变为“营养师（持续调节摄入）”，这就要求建立一套完整的数据运营（Data Operations，简称 DataOps）体系。
+这使得数据工程师的角色从一次性数据交付者，转变为持续调整数据配方和质量边界的运营者；相应地，团队需要建立一套完整的数据运营（Data Operations，简称 DataOps）体系。
 
 ### 7.1.2 训练完成后再评估，为何已经太晚？
 
 传统链路常常是流水线式的：数据团队花一个月洗数据 → 训练团队花一个月跑完预训练跑道 → 评测团队进行基准测试验证效果。如果最终结果不如预期，溯源问题将变得困难：是数据本身不佳？还是采样配比失调？亦或是学习率或优化器的超参崩溃？
 
-由于 LLM 单次长周期训练的成本极为高昂，容错空间基本为零。如果不将评估体系前置（即脱离了动辄数百万美元的正式训练也能评估数据价值），如果缺乏周期性的灰度校验模型，项目就犹如蒙眼狂奔。这就必须引入**离线代理指标**（Proxy Evaluation）与**即时反馈运营**。
+由于 LLM 单次长周期训练的成本极为高昂，容错空间有限。如果不将评估体系前置，也就是在正式训练前先用代理指标和小规模验证器模型评估数据价值，项目团队往往只能在高成本训练结束后才发现数据问题。这就必须引入**离线代理指标**（Proxy Evaluation）与**即时反馈运营**。
 
 ### 7.1.3 数据运营与模型运营的边界协同
 
 在现代化的大模型研发组中，典型的协作边界与组织交叉点如下：
 - **模型工程师**：负责监控算力集群健康度、处理梯度异常（如 Gradient Norm Spike）、设计架构调优与退火策略。
 - **数据工程师**：关注数据的产线吞吐、Token 成本以及流水线错误处理。
-- **数据运营长/评估官**：这一新兴岗位的职责是连接上述两侧——他们从模型的瞬时行为（如突然出现的 Loss 尖峰、模型特定能力的急剧下滑）中定位出具体的“数据批次毒药”，并指导上游及时切断或更新清洗规则。
+- **数据运营负责人/评估负责人**：这一岗位的职责是连接上述两侧——他们从模型的瞬时行为（如训练损失异常峰值、模型特定能力的急剧下滑）中定位具体问题批次，并指导上游及时切断或更新清洗规则。
 
 这种跨职能协同正是通过“运营飞轮”来实现的。
 
 ![图7-1：数据运营飞轮图](../../images/part2/data_operations_flywheel.png)
 
-*图7-1：数据运营飞轮图 —— 左侧展示高成本的起步区，右侧展示经过长期模型评估与根因分析反哺后，逐渐形成的自动化、高质量且ROI极高的数据资本积累正循环。*
+*图7-1：数据运营飞轮图 —— 左侧展示高成本的起步区，右侧展示经过长期模型评估与根因分析反哺后，逐渐形成的自动化、高质量数据资产积累循环。来源：本书自绘；Alt text：数据运营飞轮图，展示数据生产、模型评估、根因分析、规则回写和资产复用之间的循环关系。*
 
 ---
 
 ## 7.2 离线评估与在线代理指标设计
 
-解决评测滞后的唯一手段是设计能够脱离耗时主训练的代理指标（Proxy Metrics）。这涉及一套系统的检测动作，确保每一个版本的抽样数据在交给 GPU 之前，都经过了彻底的基因测序。
+解决评测滞后的关键手段，是设计能够脱离耗时主训练的代理指标（Proxy Metrics）。这涉及一套系统的检测动作，确保每一个版本的抽样数据在交给 GPU 之前，都经过可量化的质量检查。
 
 ### 7.2.1 统计分层与代表性评估
 
-首先要解决“评估什么”的问题。在万亿甚至几个 Token 的规模下进行全面的全量统计不仅耗费昂贵算力，而且毫无必要。最核心的方法是**分层抽样**。
+首先要解决“评估什么”的问题。在万亿级 Token 的规模下进行全面的全量统计不仅耗费昂贵算力，而且通常没有必要。最核心的方法是**分层抽样**。
 
-具体实践中，根据文档所属的类别（新闻、维基、特定域名论坛、代码库），随机按 0.1% 或 0.01% 在数据装车（Serialization）前抓取固定规模的数据沙箱（例如 1亿 Token 的子集）。所有离线分析都在这个子集上进行，如果该子集的分布呈现明显异常，就能代表整个批次的坍塌。
+具体实践中，根据文档所属的类别（新闻、维基、特定域名论坛、代码库），随机按 0.1% 或 0.01% 在数据序列化（Serialization）前抓取固定规模的数据沙箱（例如 1 亿 Token 的子集）。所有离线分析都在这个子集上进行；如果该子集的分布呈现明显异常，就说明整个批次也存在较高风险。
 
 评估一个语料库通常包含以下四大核心维度（代理指标）：
 
@@ -67,9 +83,13 @@
 - **验证手段**：使用一个成熟但体积较小的参照模型（Reference Model，例如使用 LLaMA-7B 基础版本，或在早期通过干净数据训练的 1B 验证版）对抽取出来的批次做无梯度的前向计算。
 - **数学本质**：困惑度本质上是交叉熵损失的指数形式（$PPL = e^{Loss}$）。如果模型觉得这句话“非常常见、理所应当”，PPL 就会很低；如果觉得“令人困惑或像乱码”，PPL 就会飙升。
 - **解读逻辑**：这并不是一个“越低越好”的单向指标。
-  - **极低（PPL < 5）**：通常意味着样板代码（Boilerplate）、被无限复制的免责声明或过度去重遗留的 SEO 内容。模型在这些数据上学不到任何新智力。
-  - **极高（PPL > 500）**：意味着格式重度乱码、未对齐的机器翻译伪经或纯粹的无序字符串重击。
-  - **优选区间**：以神经网络参照模型（如 LLaMA-7B）为基准时，优质文本往往分布在 **PPL 20–150** 之间（新闻类分布更窄、科学文献分布稍宽）。注意：若使用 n-gram 语言模型（如 Ch05 §5.2.1 中的 KenLM）作为参照，同类文本的 PPL 数值区间会显著偏大（新闻/百科约 100–300），两者使用不同参照模型，不可混用阈值。
+  - **极低（PPL < 5）**：通常意味着样板代码（Boilerplate）、被无限复制的免责声明或过度去重遗留的 SEO 内容。模型在这些数据上学到的新信息有限。
+  - **极高（PPL > 500）**：通常意味着格式乱码、未对齐的机器翻译文本或无序字符串。
+  - **优选区间**：以神经网络参照模型（如 LLaMA-7B）为基准时，优质文本往往分布在 **PPL 20-150** 之间（新闻类分布更窄、科学文献分布稍宽）。注意：若使用 n-gram 语言模型（如第5章 5.2.1节中的 KenLM）作为参照，同类文本的 PPL 数值区间会显著偏大（新闻/百科约 100-300），两者使用不同参照模型，不可混用阈值。
+
+代码清单7-1展示了离线困惑度抽样计算的示意实现。
+
+**代码清单7-1：离线困惑度抽样计算示意代码**
 
 ```python
 # 一个典型的离线困惑度抽样计算伪代码（基于 PyTorch 和 HuggingFace API）
@@ -93,7 +113,7 @@ def calculate_perplexity_batch(texts, cache_model_path="llama-1b-ref"):
             ppl = torch.exp(loss)
             ppl_results.append(ppl.item())
             
-    return ppl_results  # 返回一盘数组供下游产出直方图
+    return ppl_results  # 返回数组供下游生成直方图
 ```
 
 #### 2. 多样性稀疏度（Type-Token Ratio, TTR & 词汇覆盖率）
@@ -101,6 +121,10 @@ def calculate_perplexity_batch(texts, cache_model_path="llama-1b-ref"):
 - **验证手段**：统计前述文档集内不同独特词汇（Type，如词表内单独的词根）和总文本序列长度（Token）的比值。大跨度段落的 TTR 通常较低，故须用特定算法作窗口平均化（如 MATTR (Covington and McFall 2010)）。
 - **解读逻辑**：如果你的文档沙箱在 1 个亿 Token 下算出的全体未重复词数少于 5 万个，说明这批数据集存在极严重的“词穷”现象（可能源于大量的电商灌水或者机翻死循环）。长此以往，模型将陷入机械式的平庸作答。
 
+代码清单7-2展示了 Type-Token Ratio 的离线计算示意。
+
+**代码清单7-2：Type-Token Ratio 离线计算示意代码**
+
 ```python
 # 典型的离线 TTR (Type-Token Ratio) 计算伪代码
 def calculate_ttr(texts, tokenizer=None):
@@ -119,14 +143,14 @@ def calculate_ttr(texts, tokenizer=None):
     return unique_types / total_tokens
 ```
 
-- **进阶验证 - 词汇覆盖（Coverage）**：团队需要专门编纂一套“暗语词库”（例如各类罕见病种、最新的冷门代码框架、或特定文学的人名全集）。如果在沙箱中，这类靶向词汇覆盖率不足 5%，应立刻给对应域名上游抓取添加白名单权重。
+- **进阶验证 - 词汇覆盖（Coverage）**：团队需要专门编纂一套领域词表（例如各类罕见病种、最新的冷门代码框架、或特定文学的人名全集）。如果在沙箱中，这类靶向词汇覆盖率不足 5%，应立刻给对应域名上游抓取添加白名单权重。
 
 #### 3. 有毒性与负向泄露率（Toxicity & PII Density）
-- **检测目标**：直接关系到商业落地的风控合规死线。检查有害内容（仇恨、恐怖、辱骂、软色情）以及 PII（个人身份、电话、密码信标）的清洗残留比率的稳定性。
+- **检测目标**：直接关系到商业落地的风控合规底线。检查有害内容（仇恨、恐怖、辱骂、软色情）以及 PII（个人身份、电话、密码信标）的清洗残留比率的稳定性。
 - **验证手段**：这是整个指标链中计算最密集的部分。通常需要调用一个专门为安全微调（Safety Tuning）的轻量化判别器（如 Perspective API (Lees et al. 2022) 的离线开源化变体，或者是用 RoBERTa 专门训练的 5 分类判别器），对抽样文章进行打分。
 - **解读逻辑**：
-  - 毒性分数不是均值游戏，而是**千分位异常捕猎**（P99 或 P99.9 指标）。
-  - 如果抽样中发现 P99 分位数得分越界（>0.8），必须立刻熔断（Circuit Break）。
+  - 毒性分数不应只看均值，还要关注 **P99 或 P99.9 分位数**。
+  - 如果抽样中发现 P99 分位数得分越界（>0.8），必须立刻触发隔离与复核。
   - 此外，还需要对包含类似于 `sk-****` (API Token)、`13[0-9]*` (手机号码特征) 的文本触发率进行正则监控，确认 PII 屏蔽层没有在更新时意外抛错。
 
 #### 4. 领域分类与掺杂重叠（Subpopulation Overlap）
@@ -179,7 +203,7 @@ def calculate_ttr(texts, tokenizer=None):
 
 ### 7.3.3 从失败实验中沉淀 5 Whys 根因复盘框架
 
-不要将精力损耗在彼此指责，而应运用系统的复盘模型来萃取教训。工业界标准的“5个为什么（5 Whys）数据归因法”，通过强迫向下穿透，把工程事故转化为防御专利：
+不要将精力损耗在彼此指责，而应运用系统的复盘模型来沉淀教训。工业界标准的“5个为什么（5 Whys）数据归因法”，通过逐层追问，把工程事故转化为可复用的治理规则：
 
 **5 Whys 异常排查与具体执行动作示例：**
 - **Why 1（表现层）**：为什么这版模型生成代码时总是大量输出无意义的空白字符？
@@ -193,31 +217,31 @@ def calculate_ttr(texts, tokenizer=None):
 - **Why 5（根因层/组织层）**：为什么这个全局性高危规则合并主干前没有被拦截？
   *治理动作：由于缺乏独立的自动化灰度审查拦截。必须立刻强制部署 CI/CD 管线中的“多领域回归沙箱试运行（Regression Sandbox Test）”，确保任何单领域策略改动不引起跨域污染。*
 
-### 7.3.4 案例复盘实战：一次令人窒息的 Loss 尖峰侦破
+### 7.3.4 案例复盘：一次训练损失异常峰值的根因定位
 
-在某科技巨头的万亿集群上，当模型训练到第 870 亿个 Token 时，监控警报骤然响起：原本平滑下降至 1.8 左右的训练 Loss，在仅仅 15 个 Step 内，以一根呈 85 度角的直线攀升至 14.5。算力账单在此刻变成了严重的算力浪费，且该节点的梯度完全爆炸（Gradient Norm 变成 NaN）。模型工程师立刻将大盘拉停，并回滚到 100 步前的 Checkpoint，随后排查任务转交给了数据资产运营团队。
+以下为匿名化复合案例，Token 数、Loss 数值、数据规模和成本为示例性参数。某大规模训练任务在第 870 亿个 Token 附近触发监控警报：原本平滑下降至 1.8 左右的训练 Loss，在 15 个 Step 内上升至 14.5，且该节点的 Gradient Norm 变为 NaN。模型工程师暂停训练并回滚到 100 步前的 Checkpoint，随后排查任务转交给数据资产运营团队。
 
-这是一次典型的由脏数据引发的“数据中毒（Data Poisoning）”现象。数据复盘团队接手后，立刻启动了标准侦破作业：
+这是一次典型的由异常数据引发的训练不稳定现象。数据复盘团队接手后，启动了标准根因定位流程：
 
-**动作一：捕获致死序列（Lethal Batch Trapping）**
-由于训练集被打散（Shuffle）过，直接去原文件找无异于大海捞针。团队从日志系统调出了在出事前最晚加载到显卡的一批 Token IDs 序列，即第 86,995 个 Batch。
+**动作一：捕获异常批次（Batch Trapping）**
+由于训练集被打散（Shuffle）过，直接在原文件中定位问题样本效率很低。团队从日志系统调出了出事前最晚加载到 GPU 的 Token IDs 序列，即第 86,995 个 Batch。
 
 **动作二：从 Token IDs 逆向逆分词（Detokenization）**
-工程师将这串引发系统崩溃的 Token 数组，使用 TikToken 词库进行解码操作。屏幕上呈现出一副诡异的画面：长达 4096 个 Token 的句子里，没有哪怕一个标点符号和一个常见字词。充斥着诸如 `\uA4\uB6\uFF\uC2` 的截断性乱码以及毫无意义的 Unicode 替代符（Placeholder）。这串高熵信息超出了模型注意力的容纳上限，引发了前向计算数值溢出（Overflow）。
+工程师将这串引发系统崩溃的 Token 数组，使用 TikToken 词库进行解码操作。结果显示：长达 4096 个 Token 的句子里几乎没有标点符号和常见字词，充斥着诸如 `\uA4\uB6\uFF\uC2` 的截断性乱码以及无意义的 Unicode 替代符（Placeholder）。这串高熵信息超出了模型注意力的稳定处理范围，引发了前向计算数值溢出（Overflow）。
 
 **动作三：批次寻根（Batch-to-Source Tracing）**
-怎么会有这么一段离奇的数据进入最高级别的数据队列？利用全局唯一标识符（GUID），数据团队检索了该文档的血统（Lineage）。结果指向了三周前一次针对“东南亚某国公开学位论文 PDF 库”的大规模拉取。
+利用全局唯一标识符（GUID），数据团队检索了该文档的血缘（Lineage）。结果指向三周前一次针对某公开学位论文 PDF 库的大规模拉取。
 
 **动作四：定位清洗器缺陷**
-追查当时的清洗日志发现：这些 PDF 因为经过了早期的第三方软件加密，其底层文字层实则是经过混淆处理的字节流。然而巧合的是，这些乱码在经过传统的语言识别模型（FastText Language ID）时，被算法十分自信地误判为某种“生僻印第安语系”（置信度高达 0.92），从而逃过了“非标准文字比例过高”的过滤漏斗；随后，因为这串内容实在太罕见了，在去重阶段自然显示为高度罕见的“独特内容”，就这样顺理成章地被当成极品知识喂给了模型。
+追查当时的清洗日志发现：这些 PDF 因为经过早期第三方软件加密，其底层文字层实际是经过混淆处理的字节流。这些乱码在经过传统的语言识别模型（FastText Language ID）时，被误判为某种低资源语言（置信度 0.92），从而逃过了“非标准文字比例过高”的过滤漏斗；随后，因为这串内容非常罕见，在去重阶段被保留为“独特内容”，最终进入高权重数据队列。
 
 **复盘与治理动作（Root Cause Action）**
 查明真相后，团队立刻采取了三步走操作：
-1. **清理毒源**：将属于该来源的所有 PDF 解析数据连夜从数据湖中剔除，共计 1.4 TB（约 3.5 亿 Token）。
-2. **规则补丁**：给 FastText 语言模型前置一道强硬的“有效 UTF-8/中英文字符占比检测器”，强制规定主流自然语言中的标点符号密度下限必须达到 2%。
+1. **隔离问题来源**：将属于该来源的所有 PDF 解析数据从数据湖中隔离复核，共计 1.4 TB（约 3.5 亿 Token，示例口径）。
+2. **规则补丁**：给 FastText 语言模型前置一道“有效 UTF-8/目标语言字符占比检测器”，并设置主流自然语言中的标点符号密度下限。
 3. **安全再审核**：针对同批次入库的异构文本，额外增加一重利用小型 LLaMA 判别其能否符合基本语法结构的过滤门禁。
 
-这次高达数万美元算力浪费的教训，深刻诠释了什么是“从失败实验中沉淀复盘金字塔”。所有的防御代码都是用显卡的电费燃烧和工程师的加班写出的规律。
+这次成本较高的训练中断说明，数据运营团队必须能够从异常 Batch 追溯到源头文档、解析器版本和清洗规则，并把复盘结论固化为自动化检查。
 
 **表7-2：版本迭代记录模板表**
 
@@ -228,7 +252,7 @@ def calculate_ttr(texts, tokenizer=None):
 | **基础信息** | 版本号：v2.1 → v2.2；操作人：张三（DataOps）；提交日期：2026-X-X |
 | **主要变更（Changelog）** | 1. 扩充了 StackOverflow 的 30GB 中高质量问答（通过新爬虫接入）。<br>2. 收紧了 MinHash 的阈值（0.85→0.8）针对 Wikipedia 中文库的同源去重。<br>3. 修复了针对 `<p>` 标签误伤前序段落的正则表达式漏洞。 |
 | **规模变化** | 预期新增 50GB，实际清理去重后净增 23GB；总 Tokens 达 1.45T。 |
-| **A/B 评测结果核心点** | 小标号对撞实验中，HumanEval（代买评测）通过率提成 4.1 个点，其余通用基准上下浮动不超过 0.3%，视为无害改动。 |
+| **A/B 评测结果核心点** | 小规模对照实验中，HumanEval（代码评测）通过率提升 4.1 个点，其余通用基准上下浮动不超过 0.3%，视为低风险改动。 |
 | **存在及预知风险（Known Issue）** | 在增加 StackOverflow 后，部分十分陈旧的回答掺入了模型。目前暂未剔除年份久远的贴文，计划在 v2.3 使用启发式时间戳过滤修复。 |
 | **最终审核结论** | √ 验证通过，允许挂载进 v2.2 生产主路队列提供预训练消费。 |
 
@@ -248,29 +272,29 @@ def calculate_ttr(texts, tokenizer=None):
 
 ![图7-2：数据评估闭环图](../../images/part2/data_evaluation_loop.png)
 
-*图7-2：数据评估闭环图 —— 从抽取式盲审到针对评估指标启动根因排查，再针对具体现象采取系统治理动作的环形架构。*
+*图7-2：数据评估闭环图 —— 从抽取式盲审到针对评估指标启动根因排查，再针对具体现象采取系统治理动作的环形架构。来源：本书自绘；Alt text：数据评估闭环图，展示抽样评估、指标异常、根因排查、治理动作和规则更新之间的闭环。*
 
 ### 7.4.2 自动化质量预警系统架构 (Automated Alerts)
 
-仪表盘若是单纯的“死报表”，依赖人工每日盯着屏幕巡查，必然存在巨大的遗漏风险。世界顶尖的大模型数据工厂不仅拥有静态看板，更具备一套犹如自动驾驶系统般的“主动阻断与预警哨兵”。这套预警架构往往建立在分布式的流式计算框架（如 Apache Flink 或 Spark Streaming）之上，实现毫秒级的脏数据拦截。
+仪表盘若只是静态报表，依赖人工每日巡查，必然存在遗漏风险。成熟的大模型数据工厂不仅拥有静态看板，也需要一套主动阻断与预警机制。这套预警架构往往建立在分布式的流式计算框架（如 Apache Flink 或 Spark Streaming）之上，实现低延迟的异常数据拦截。
 
 **第一级：基线漂移预警（Data Drift Alerts）**
-每天，新的网络抓取语料、清洗后语料、甚至合成语料会如洪水般涌入数据湖。算法每天提取样本集计算分布熵（Entropy）。如果某类特定的词频在今天的批次中暴涨了 300%（可能是某特定域名的爬虫陷入死循环，不断下载冗余的导航栏标签），Slack 或飞书频道会立刻触发红色的 `[P1-DataDrift]` 告警。数据流会被自动挂起（Suspended），直到工程师人工登录仪表板解除封控。
+每天，新的网络抓取语料、清洗后语料、甚至合成语料会持续进入数据湖。系统每天提取样本集计算分布熵（Entropy）。如果某类特定词频在当天批次中上升 300%（可能是某域名爬虫陷入循环，不断下载冗余导航栏标签），Slack 或飞书频道会触发 `[P1-DataDrift]` 告警。数据流会被自动挂起（Suspended），直到工程师人工登录仪表板解除封控。该比例为示例阈值，生产系统应结合历史分布和业务容忍度校准。
 
 **第二级：成本与时延红线预警**
 数据预处理也是大量消耗 CPU 资源的。如果在看板上发现 `FastText` 或 `正则表达式过滤阶段` 的节点 CPU 核心打满，且数据吞吐量从平时的 2GB/s 暴跌至 100MB/s。这类警报一旦触发，必定是某段包含“灾难性回溯”（Catastrophic Backtracking）的正则表达式在处理超长文档时发生了严重的时间复杂度爆炸（也就是经典的 ReDoS 攻击现象）。此时调度系统可直接终止超时进程，保障主流水线不受阻。
 
 **第三级：多模态异常预警（面向下一代系统）**
-随着图文多模态时代的逼近（这将在本书第 8 章详细展开），看板上开始增加图像坏链率（Broken Links）、文本-图片 Clip 相似度极值监控。一旦一批语料中图文无关比例超过阈值，也会立即鸣笛。
+随着图文多模态数据的引入（见第8章），看板上还需要增加图像坏链率（Broken Links）、文本-图片 CLIP 相似度极值监控。一旦一批语料中图文无关比例超过阈值，也应立即触发复核。
 
 ### 7.4.3 梯队化的责任边界体系
 
-在这种全副武装的自动化雷达探测下，大型 AI 研发组织的权责边界得到了史无前例的清晰量化，杜绝了过去常见的踢皮球现象。
+在自动化监控与复核机制下，大型 AI 研发组织的权责边界可以被更清晰地量化，减少故障定位中的职责不清。
 
-- **预训练数据架构（Data Infrastructure）组**的北极星指标只有一个：稳定吞吐与绝对成本（Cost_per_Token）。他们要证明：不惜一切代价为下游提供最高速、最低存储 I/O 开销的分布式存储架构；如果 GPU 因为 `DataLoader` 卡脖子而跌掉一分钟运算时间，就是这支团队的直接责任事故。
-- **爬虫与数据采集引擎（Data Hunter）组**的眼光锁定在：获取广度覆盖度与合规（Legal/Copyright）安全。突破特定的反爬墙，拿下核心机构财报或最新 StackOverflow 源是他们的日常；如果有 PII 或极高危的有毒负面样本逃逸进入训练场，引爆公关危机，他们将承担首责。
+- **预训练数据架构（Data Infrastructure）组**的北极星指标是稳定吞吐与单位 Token 成本（Cost_per_Token）。他们需要为下游提供高速、低存储 I/O 开销的分布式存储架构；如果 GPU 因为 `DataLoader` 瓶颈长期空转，这一团队需要负责定位和修复。
+- **爬虫与数据采集引擎（Data Ingestion）组**关注获取广度、覆盖度与合规（Legal/Copyright）安全。如果有 PII 或高风险有害样本逃逸进入训练场，他们需要承担源头排查责任。
 - **预训练模型研究员（Pre-train Researchers）**的核心视线则在于：使用怎样的架构（MoE还是Dense，MHA还是GQA）以及配置合理的超参数去充分利用硬件集群，能否通过当前的数据配比使得 Loss 严格按照 Scaling Law 下降。
-- **数据质量裁判（Data Ops / Evaluator）**：承担类似总厨或营养师的角色。他们正是这套“质量看板与预警流”的核心维护者！他们决定面糊的配比（网页：代码：论文 = 6:2:2），并且需要利用看板实时判断，采集工程师搞来的配菜营养浓度是否够格，同时需要评定这些配料在经过模型工程师的猛火重组后，有没有在评测集上炼就出现实世界里真正的智力跃迁。如果发现某阶段评测效果疲垮，发文叫停训练并回炉改造，正是他们被赋予的核心职权。
+- **数据质量评估（Data Ops / Evaluator）团队**：维护质量看板与预警流，决定数据配比（如网页：代码：论文 = 6:2:2），并利用看板判断采集数据是否达到入库标准。他们还需要结合模型评测结果判断数据配方是否有效；如果某阶段评测效果明显下降，应推动训练暂停、样本回溯和规则更新。
 
 ---
 
@@ -284,7 +308,7 @@ def calculate_ttr(texts, tokenizer=None):
 **主要动线**：
 1. **周末预训练巡检**：查看刚刚过去的周末内，主预训练分支持续喂入的总 Token 数。核对 `nvidia-smi` 监控面板是否因 DataLoader 卡顿或存储 I/O 阻塞出现 GPU 空转现象（MFU 低于警戒线）。如果存在，需要立刻在当天的第一顺位记录 I/O 缺陷日志。
 2. **离线检测报告开箱**：针对周日晚间最新完成清洗的 T-1 批次数据（通常是两三个抽样后的 10GB 测试沙箱），提取 KenLM (Heafield 2011) 困惑度（PPL）、类型/令牌比率（TTR）、文本长度分布直方图。
-3. **指标异常警报排查**：如果 PPL 均线突然飙升至 500 以上，通常意味着最新接入的数据源包含了未被解析干净的 HTML 杂质。如果安全阻截率（Toxicity Alert）翻倍，那是因为近期加量抓取了社群讨论源（例如某开源技术论坛的风控板块）。在会议上不纠结论，只定下需要深度钻取的“异常点”。
+3. **指标异常警报排查**：如果 PPL 均线突然上升至 500 以上，通常意味着最新接入的数据源包含未被解析干净的 HTML 杂质。如果安全阻截率（Toxicity Alert）翻倍，可能与近期增加社群讨论源有关。在会议上不急于下结论，只确定需要深度钻取的异常点。
 
 ### 7.5.2 周二与周三：异常追溯与小股试错验证 (Root Cause Defecting)
 
@@ -300,7 +324,7 @@ def calculate_ttr(texts, tokenizer=None):
 **主要动线**：
 1. **A/B 效果对照**：周四早晨，微型实验跑出结果。模型工程师将公布两组数据版本的验证集 Loss 曲线是否发生交叉，以及其在特定的下游测试基准（例如 MMLU (Hendrycks et al. 2021) Code 分项或 GSM8K (Cobbe et al. 2021)）上的通过率偏差。
 2. **定性分析**：如果新数据（`v1.2_CodePatch`）让代码能力提升了 5%，且没有拉垮通用的指令遵从度，那么这个清洗补丁（Patch）宣告胜利，代码将合入主预训练清洗仓库。
-3. **数据重配子集比重**：在本步骤，也是决定下一周正式推入大型集群“混合面糊（Data Mix）”的时刻。架构师会下达指令：由于近期评测表明基础推理能力疲软，从周五开始的下一个百万步（Step），要求提升 arXiv 论文和高分书籍的占比至 30%，相对降低开放百科的占比至 15%。数据引擎将随之改变抽样概率（Temperature Sampling）。
+3. **数据重配子集比重**：在本步骤，团队决定下一周正式推入大型集群的数据混合（Data Mix）。例如，若近期评测表明基础推理能力偏弱，从周五开始的下一个百万步（Step）可将 arXiv 论文和高质量书籍占比提升至 30%，相对降低开放百科占比至 15%。数据引擎将随之改变抽样概率（Temperature Sampling）。这些比例为示例参数，需要通过消融实验校准。
 
 ### 7.5.4 周五：全量产线构建与封版交付 (Production Release)
 
@@ -308,7 +332,7 @@ def calculate_ttr(texts, tokenizer=None):
 **主要动线**：
 1. **周度版本封版（Freeze）**：结合本周通过检验的修复脚本，从原始数据湖里滚雪球式地提炼出最新一版的增量 Token。所有元数据（Metadata）记录并更新，存入云托管环境，将指向这段最新语料的指针更新至 DataLoader 的配置文件中。
 2. **发布预演（Smoke Test）**：在一组闲置的 8 卡节点上运行一个长约 2 小时的拟真环境，确保这个混入了新权重的序列，在分词（Tokenization）装载、二进制压缩读取和 Tensor 拼装后，能被顺利推送进显卡且不报错。
-3. **主训投料发车**：确认无误后，周五晚间对正在轰鸣的“7B主模型训练集群”执行无感热切，模型将在下一个 Checkpoint 读取到最新的 `v1.3` 高质量数据版本。整个工作流在此完成闭环，工程师可以安心度过周末。
+3. **主训数据切换**：确认无误后，周五晚间对“7B 主模型训练集群”执行无感热切，模型将在下一个 Checkpoint 读取到最新的 `v1.3` 数据版本。整个工作流在此完成闭环。
 
 ---
 
@@ -320,13 +344,13 @@ def calculate_ttr(texts, tokenizer=None):
 
 在预训练后期，运营评估往往会发现某些非常具体、狭窄的能力缺失（例如：模型在处理德语等少数语言表现惊艳，但在处理南亚某国特小语种时频繁陷入死循环；或者在量子物理领域经常出现幻觉）。
 
-**反向采集指令**：此时需要向上游下达“靶向抓取”任务。比如，指定定向爬取特定的特定领域的开源 PDF 书籍（例如 ArXiv Physics 类别）；或者采购特定的某机构财务报表数据库。这种根据木桶短板决定数据挖掘方向的做法，就是数据资本的高端形式。如果盲目的进行广撒网爬虫，只会带来越发沉重的废数据冗余。
+**反向采集指令**：此时需要向上游下达“靶向抓取”任务。比如，指定定向爬取特定领域的开源 PDF 书籍（例如 arXiv Physics 类别），或者采购特定机构财务报表数据库。这种根据能力短板决定数据挖掘方向的做法，是数据资本化的重要形式。盲目扩大通用爬虫规模，往往只会带来更重的低价值数据冗余。
 
 ### 7.6.2 向“数据清洗期”回写规则
 
-大部分在基准评测上的挫败都可以被归因为数据清洗体系的“松鼠症”（什么都想留）或“厌食症”（过滤得过于极端破发）：
+大部分在基准评测上的挫败，都可以归因为数据清洗体系的两类极端倾向：过度保留和过度过滤。
 - **对抗过度去重**：当模型生成明显缺少特定事件维度，发现该维度的数百篇新闻因为引用了一套完全相似的前情摘要，被 MinHash 的 0.85 相似度全面过滤。我们需要回写规则：建立领域白名单（White-listing），或者通过降低特定主题下的去重警戒线来捞回被错杀的文档。
-- **对抗知识毒化**：如果安全检测组在灰度发布时发现某些回答引向了已关闭的色情暗网链接。通过源头域名 ID 反查，定位到某一类老旧网址库被恶意篡改。必须立即在清洗侧将这些关联的 Domain 塞入极高优先级的拦截黑名单，并通知重新清洗全量该段语料库提取器。
+- **对抗知识污染**：如果安全检测组在灰度发布时发现某些回答引向已关闭或高风险链接。通过源头域名 ID 反查，定位到某一类老旧网址库被篡改。必须立即在清洗侧将这些关联 Domain 加入高优先级拦截名单，并重新清洗该段语料。
 
 ### 7.6.3 沉淀为 SFT（指令微调）与 RAG 的可复用资产
 
@@ -342,11 +366,11 @@ def calculate_ttr(texts, tokenizer=None):
 
 ## 本章小结
 
-本章作为数据工程的指挥塔，阐述了以“数据评估、质量闭环与运营迭代”为核心的数据资产治理逻辑。我们从大模型训练阶段不可忽视的“一次性交付工程幻觉”说起，指出了如果将数据测试动作置于训练末端其后果是极为沉痛和昂贵的。
+本章阐述了以“数据评估、质量闭环与运营迭代”为核心的数据资产治理逻辑。我们从大模型训练阶段不可忽视的“一次性交付工程幻觉”说起，指出了如果将数据测试动作置于训练末端，返工代价会显著增加。
 
-为此，本章全面解构了建立“离线代理指标（PPL/TTR等）”的必要性，并借由此指标引申出了严谨的 DVC 版本比对、问题样本库留底、A/B Testing 实验，最终汇总沉淀为包含四大运营动作周期的敏捷工作流。这使得大语言模型的数据研发不再是一个孤立的黑盒车间，而是一条兼顾质量红绿灯、能够通过不断发现的“效果缺失”反推上游数据挖掘采集的高速飞轮。
+为此，本章系统说明了建立“离线代理指标（PPL/TTR 等）”的必要性，并由此引出 DVC 版本比对、问题样本库留存、A/B Testing 实验，最终沉淀为包含四大运营动作周期的敏捷工作流。这使得大语言模型的数据研发不再是孤立的黑盒流程，而是一条能够通过效果缺失反推上游采集和清洗策略的质量闭环。
 
-从最初的原始万维网网页，经过质量把控、排雷洗净、混分配比、最后高效流入GPU，整个浩繁的大模型文本数据流已经跑完了属于它的半路旅程。然而智能的形态远不止于抽象的文字。下一章，随着大模型感官边界的扩张，我们将跨入全书的第三篇，探讨结构复杂但在认知突破上至关重要的前沿领域：“**第 8 章 图文对数据工程**”，见证多模态工程下更为波澜壮阔的数据交响篇章。
+从原始网页到质量把控、清洗去重、混合配比，再到高效流入 GPU，第二篇完成了文本预训练数据工程的主体链路。下一章将进入第三篇，讨论结构更复杂、成本更高、对齐要求更严格的多模态数据工程：**第8章 图文对数据工程**。
 
 ## 参考文献
 
diff --git a/docs/zh/part2/index.md b/docs/zh/part2/index.md
index 28c2c2ac..f5eb2e11 100644
--- a/docs/zh/part2/index.md
+++ b/docs/zh/part2/index.md
@@ -2,7 +2,27 @@
 
 ## 本篇定位
 
-第二篇聚焦文本预训练语料，从数据源获取、版权边界、清洗去重、分词序列化到质量闭环，完整展开大规模文本数据流水线的构建方法。
+第二篇聚焦文本预训练语料的生产、治理与持续迭代，讨论从数据源获取、版权边界、清洗去重、分词序列化，到质量评估与运营闭环的完整工程链路。本篇承接第一篇关于数据基础设施和质量框架的讨论，将抽象的数据生命周期落到可执行的文本预训练流水线；同时也为第三篇的多模态数据工程提供对照基线：只有先理解文本数据如何被采集、过滤、打包和评估，才能准确判断图像、文档、视频和音频数据为何会引入更复杂的表示、对齐和成本问题。
+
+从 Springer 技术书章节结构看，本篇的目标不是罗列工具，而是建立可复用的工程判断框架。读者应能够回答三个问题：第一，哪些数据源适合进入预训练语料库，哪些来源需要隔离或剔除；第二，清洗、去重、去污染和脱敏如何共同定义训练数据质量；第三，分词、序列化、加载和评估运营如何把“可用数据”稳定转化为“可训练数据”。
+
+## 本篇学习目标
+
+- 建立文本预训练数据从来源、采集、解析到存证的完整治理视角。
+- 掌握清洗、去重、PII 脱敏和基准去污染的关键工程方法。
+- 理解分词、序列化、Packing、Mixing 与高效 DataLoader 对训练吞吐的影响。
+- 能够设计离线代理指标、数据版本管理和质量闭环，支持持续迭代的数据运营。
+- 能够区分公开网页、代码、学术论文、书籍、企业内部数据和用户反馈数据的不同风险边界。
+
+## 读者前置知识
+
+阅读本篇前，建议读者已理解第一篇中的数据生命周期、质量维度、成本治理和数据栈分层。若读者已有传统 ETL、数据湖或机器学习数据处理经验，可重点关注本篇与传统文本处理不同的部分：训练语料的版权与许可边界、基准污染、离线分词、序列 Packing、跨节点 DataLoader 和数据版本回滚。
+
+## 章节逻辑
+
+第4章回答“数据从哪里来以及是否能用”的问题，重点是来源画像、采集管线、版权许可和元数据存证。第5章回答“原始语料如何变成高质量语料”的问题，重点是规则过滤、模型评分、去重、PII 脱敏和基准去污染。第6章回答“高质量语料如何高效进入训练系统”的问题，重点是分词、序列化、Shard、Packing、Mixing 和 DataLoader 吞吐。第7章回答“如何判断数据版本是否真的改善模型”的问题，重点是离线代理指标、数据版本化、问题样本库、根因复盘和运营节奏。
+
+本篇与前后篇的关系也很明确：它把第一篇提出的数据质量框架落到文本预训练语料的生产流程；同时，它为第三篇多模态数据工程提供对照基线。读者会看到，许多看似属于“文本清洗”的问题，例如来源许可、去重、污染、打包和评估，在图像、视频和音频场景中会变得更复杂。
 
 ## 本篇目录
 
@@ -11,8 +31,4 @@
 - [第6章：分词、序列化与高效加载](ch06_tokenization_loading.md)
 - [第7章：数据评估、质量闭环与运营迭代](ch07_data_operations.md)
 
-## 建议阅读顺序
-
-- 先读第4章，明确数据来源、授权条件与采集合规。
-- 再读第5章和第6章，理解清洗、去重、分词与训练输入组织。
-- 最后读第7章，把离线评测、线上反馈与运营闭环串起来。
+建议按第4章至第7章顺序阅读。已有预训练经验的读者可以先读第7章建立质量闭环视角，再回到第4至第6章检查自己的数据管线是否具备可追溯、可诊断和可复现能力。
diff --git a/docs/zh/part3/ch08_multimodal_image.md b/docs/zh/part3/ch08_multimodal_image.md
index a09202bd..989d10f3 100644
--- a/docs/zh/part3/ch08_multimodal_image.md
+++ b/docs/zh/part3/ch08_multimodal_image.md
@@ -1,78 +1,87 @@
-**篇前导读**
+# 第8章 图文对数据工程
 
-如果说纯文本大模型（LLM）是在学习人类几千年沉淀下来的“抽象符号系统”，那么以 GPT-4V、Gemini 乃至 Sora 为代表的多模态大模型（MLLM），则是在直接吞吐我们所生存的“物理世界镜像”。从干瘪的纯文本跃迁到栩栩如生的图文对、交错排版的网页图文、乃至奔流不息的视频和音频片段，这绝不仅仅是给基础大模型多插配一个预训练好的 Encoder 插件这么简单。跨越模态护城河的旅途，在数据工程底层面临着**四重维度的爆炸性挑战**：
-1. **对齐（Alignment）**：文字和图像在数字世界的构成法则是天然割裂的，如何向一个仅仅懂得矩阵乘法的模型证明“Apple”这个序列与一张由红色与多边形构成的像素矩阵精确指向同一个物理实体？
-2. **表示（Representation）**：纯文本先天拥有确定的 1D 序列边界（即明确切分好的 Vocabulary 词表），而多模态视觉信号是连续且具有极高维度的。如何将一张极高分辨率的 4K 网页截图压缩并无损打包进变长 Token 序列列车？
-3. **评价（Evaluation）**：文字可以通过 PPL 或 TTR 指标来极其低成本地测量基本质量，而试图判断一幅图是否具备“高质量摄影美学”或“存在阴暗的版权水印”，其计算代价通常要调动千万级别参数的额外深度学习模型去进行特征扫描。
-4. **算力成本（Cost）**：图像的磁盘存储、分布式集群的 I/O 解码带宽（如 PCIe）与内存张量传输成本，往往是等额纯文本的 100 倍到 1000 倍以上。
+## 摘要
 
-本篇（第8至第10章）将系统性揭秘全球前沿多模态大模型的训练基础底座与算力调度体系。我们将以业界最成熟经典的“**图文对数据工程**”为起点（直接支撑起集团 P03 等超大型视觉对话模型的研发构建），随后深入探讨攻克商业落地顽疾的重标注与真实文档 OCR 理解（第9章），最终进阶到处理时序相关的视频与高并发数字音频流（第10章）。
+本章讨论图文对与交错图文数据工程的基本问题，重点回答视觉数据为什么不能沿用纯文本清洗范式。章节首先说明视觉噪声、语义错配、分辨率成本和图像表示带来的工程挑战，随后比较图文对、交错图文和文档截图三类样本范式。清洗部分从图像解码、分辨率与宽高比过滤、NSFW/水印/隐私拦截切入，进一步介绍基于 CLIP/SigLIP 的图文语义匹配和多粒度重标注策略。后半章讨论 AnyRes 动态切分、长宽比分组、图文混采和质量风险，并通过匿名化复合案例说明图库水印污染与二次清洗的必要性。读者应能够设计可追溯、可评估、成本可控的图文数据预处理流水线。
 
----
+## 关键词
 
-# 第8章 图文对数据工程
+图文对；交错图文；CLIP Score；SigLIP；AnyRes；图像清洗；重标注；多模态数据
+
+## 学习目标
+
+- 能够解释图文数据在噪声类型、语义对齐、分辨率成本和质量评价上的特殊性。
+- 能够区分 Image-Caption、Interleaved Image-Text 和 Document Grounded 三类样本范式。
+- 能够设计图像解码、尺寸过滤、水印/隐私拦截和语义匹配的多阶段清洗流程。
+- 能够说明 CLIP/SigLIP 过滤、Re-captioning 和 AnyRes 动态切分的适用边界。
+- 能够识别图库污染、图文错配和比例混采失衡对模型训练的影响。
 
 ## 8.1 多模态数据为何难于文本
 
-当一个 NLP 数据工程师首次接手视觉语言模型（Vision-Language Model, VLM）的数据清洗任务时，最真切的体会常常是：“原本极其确定的规则，突然全部失效了。” 
+当一个 NLP 数据工程师首次接手视觉语言模型（Vision-Language Model, VLM）的数据清洗任务时，最直接的变化是：许多在纯文本中有效的确定性规则，在图像场景下只能覆盖一小部分问题。
 
-### 8.1.1 视觉噪声的隐蔽性与“薛定谔的坏图”
+### 8.1.1 视觉噪声的隐蔽性与不确定性
 
-在纯文本的数据工厂中，所谓的“脏数据”或“乱码”往往是可以被极其廉价地检测出来的——写个正则表达式、跑个 MinHash 或者算一下困惑度（PPL），甚至不需要动用 GPU 即可筛除。但在图像的世界里，什么是噪声？它常常呈现出“薛定谔的状态”：
-- **概念隔离噪声**：一张 4K 高清、画质完美、色彩极好的风景照，由于被人为恶意编辑，角落里带有一个仅占 15x15 像素的半透明色情水印（NSFW），这种图对多模态合规性是致命的。
-- **空间失真噪声**：一张背景极其凌乱的东南亚街头杂货铺抓拍，描述语写的是“摊位上的一把梳子”。但这把关键的梳子在全图中仅仅占了 3 个像素，不仅人眼难辨，经过卷积网络下采样后更是荡然无存。
-- **频域（Frequency Domain）压缩噪声**：一张包含详尽财务报表或医学心电图的截图，由于在其流传过程中经历了多次微信、推特的二次 JPEG 压缩，高频细节周围产生了严重的“振铃伪影（Ringing Artifacts）”。人类看似乎还能猜出文字，但对依赖边缘特征的深度识别网络（OCR）而言则变成了无法跨越的灾难障碍。
+在纯文本的数据工厂中，所谓的“脏数据”或“乱码”往往可以用低成本方法检测出来：写正则表达式、跑 MinHash 或计算困惑度（PPL），甚至不需要动用 GPU 即可筛除。但在图像数据中，噪声常常依赖语义、空间位置和视觉上下文判断：
+- **概念隔离噪声**：一张 4K 高清、画质完美、色彩极好的风景照，由于被人为恶意编辑，角落里带有一个仅占 15x15 像素的半透明色情水印（NSFW），这种图会对多模态合规性造成高风险。
+- **空间失真噪声**：一张背景凌乱的街头杂货铺抓拍，描述语写的是“摊位上的一把梳子”。但这把关键的梳子在全图中仅占 3 个像素，不仅人眼难辨，经过卷积网络下采样后也可能丢失。
+- **频域（Frequency Domain）压缩噪声**：一张包含详尽财务报表或医学心电图的截图，由于在其流传过程中经历了多次二次 JPEG 压缩，高频细节周围产生严重的“振铃伪影（Ringing Artifacts）”。人类仍可能猜出文字，但依赖边缘特征的深度识别网络（OCR）会明显受损。
 
-这些“视觉隐蔽噪声”根本无法通过传统的哈希指纹或文件 MD5 对比来排除。在多模态数据流中，我们常常必须部署并长期运行数个预先训练好的轻量级视觉判别引擎（如基于 ResNet-50 的二分类水印检测器、基于 LAION Aesthetics 评估器）来进行“稠密推理扫雷”。这意味着，**即便是“洗数据”这件毫无产出的前置工作，也开始大把大把地燃烧异常昂贵的 GPU 计算时。**
+这些“视觉隐蔽噪声”无法通过传统的哈希指纹或文件 MD5 对比排除。在多模态数据流中，通常需要部署并长期运行数个预训练视觉判别器（如基于 ResNet-50 的二分类水印检测器、基于 LAION Aesthetics 的评估器）来进行密集推理。这意味着，图像清洗本身就会消耗可观的 GPU 计算资源。
 
 ### 8.1.2 语义缺失与跨模态“多义错位”（WebTox）
 
-多模态的对齐学习，建立在一个天真的假设之上：我们抓取到的（Image, Text）对，它们彼此在描述同一个事物。然而，互联网上海量的“图片与替代文本（Alt-text）”天然是高度撕裂且毫不对应的。
+多模态的对齐学习，建立在一个前提之上：抓取到的（Image, Text）对彼此描述同一个事物。然而，互联网上海量“图片与替代文本（Alt-text）”并不天然对应。
 
-由于十余年来网页爬虫与 SEO（搜索引擎优化）被恶劣滥用，爬虫工程师每天都会抓取到几百亿个长成这样的恶性图文对：
+由于十余年来网页爬虫与 SEO（搜索引擎优化）的使用方式复杂，爬虫工程师经常会遇到如下高风险图文对：
 - **肉眼看到的图片内容**：一只正在草地上开心奔跑的金毛犬。
 - **HTML 里提取到的 Alt-text**：“2023包邮正品优质特价全场满减买一送一宠物用品”。
 
-如果你将这种充满了商业目的诱导数据，不做任何因果剥离直接喂给模型，模型将在反向传播（Back-propagation）中，被迫压榨自身的特征权重，最终学会了“金毛犬的毛发纹理等于包邮促销折扣”这种极其荒谬的绑定逻辑（即跨模态的语义强行错位）。
+如果将这种充满商业目的的诱导数据，不做任何因果剥离直接喂给模型，模型将在反向传播（Back-propagation）中被迫建立错误关联，最终学会“金毛犬的毛发纹理等于包邮促销折扣”这类不合理绑定（即跨模态语义错位）。
 这一现象在多模态数据工程实践中被研究者俗称为 **WebTox（网络语义毒数据）**。实验表明，该类噪声的大量混入甚至会使得千亿规模模型在视觉问答（VQA）基准上的表现，劣于未经微调的 1B 基线模型。正是为了系统性地缓解这一问题，学界与工业界才逐步发展出了以 CLIP Score 为核心的跨模态语义过滤技术。
 
-### 8.1.3 画像分辨率与 GPU 显存的四次方博弈
+### 8.1.3 图像分辨率与 GPU 显存的成本权衡
 
-在纯语言建模时代，无论作者是写一篇长篇大论的主题报告，还是随口吟诵的一句几字短诗，送入大语言模型的代价仅仅与 Token 的长度呈线性增长（Linear Scaling）。但在多模态领域，**图像分辨率（Resolution）对于计算开销（FLOPs）的惩罚是极其严厉且呈指数级攀升的**。
+在纯语言建模时代，无论输入是一篇主题报告，还是一句短诗，送入大语言模型的代价主要与 Token 长度呈线性增长（Linear Scaling）。但在多模态领域，**图像分辨率（Resolution）会显著放大计算开销（FLOPs）**。
 
 我们以最主流的基于 ViT（Vision Transformer）(Dosovitskiy et al. 2020) 架构的视觉编码器为例。假设我们设定的切割模块（Patch Size）尺寸恒定为 $14 \times 14$ 像素：
-- 当向网络输入一张极为克制的低清 $224 \times 224$ 分辨率图片时，它会被切成 $(224/14) \times (224/14) = 256$ 个 Patch Token。此时，自注意力机制（Self-Attention）的计算复杂度大约是 $256^2 = 65,536$ 级运算量。
+- 当向网络输入一张 $224 \times 224$ 分辨率图片时，它会被切成 $(224/14) \times (224/14) = 256$ 个 Patch Token。此时，自注意力机制（Self-Attention）的计算复杂度大约是 $256^2 = 65,536$ 级运算量。
 - 但如果你为了让模型能够看清楚一张扫描版发票上的数字，不得不拔高输入分辨率至 $1008 \times 1008$（以保留文档图像上的微小文字），那么图像 Token 序列的长度将剧增至 $(1008/14) \times (1008/14) = 5184$ 个。
 - 由于标准 Transformer 的 Attention 计算开销是与其产生的 Token 序列长度呈“二次方（Quadratic）复杂度”的，此时单层注意力的计算量飙升到了 $5184^2 \approx 26,873,856$ 级运算量！
 
-仅仅将图像的边长拉大了 4.5 倍，**Attention 层的计算量**就显著地膨胀了近 **410 倍**（注意：这里衡量的是 Self-Attention 的二次方复杂度，而非整个模型的 FLOPs；其他层如 FFN 的计算量与序列长度呈线性增长，实际总训练算力涨幅仍然显著但略小于 410 倍）！这样暴戾的显卡显存消耗，将使得再庞大的训练集群也难以负担。因此，图文多模态数据工程最为核心的技术妥协艺术之一，就是不断摸索**“如何对超清大图执行最高效的动态裁切降维与多尺度 Patching 策略”**。
+仅仅将图像的边长拉大 4.5 倍，**Attention 层的计算量**就会增加近 **410 倍**（注意：这里衡量的是 Self-Attention 的二次方复杂度，而非整个模型的 FLOPs；其他层如 FFN 的计算量与序列长度呈线性增长，实际总训练算力涨幅仍然显著但略小于 410 倍）。因此，图文多模态数据工程的核心任务之一，是在保留局部细节与控制训练成本之间设计动态裁切、降维与多尺度 Patching 策略。
 
 ![图8-1：图文数据工程全景图](../../images/part3/multimodal_data_panorama.png)
 
-*图8-1：多模态图文数据工程全景图 —— 从最左侧的 DOM 树抓取与 PDF 解析起始，依次穿透格式解析、水印底线过滤、CLIP 语义对齐、直至最右侧的交错序列拼装与 Token 化表示。分布式计算与 Metadata 是横跨底层的核心支撑。*
+*图8-1：多模态图文数据工程全景图 —— 从最左侧的 DOM 树抓取与 PDF 解析起始，依次穿过格式解析、水印过滤、CLIP 语义对齐、直至最右侧的交错序列拼装与 Token 化表示。分布式计算与 Metadata 是横跨底层的核心支撑。来源：本书自绘；Alt text：图文数据工程全景图，展示 DOM 抽取、图片下载、格式解析、过滤、语义对齐、重标注和序列拼装之间的流程。*
 
 ---
 
 ## 8.2 图文样本的范式：从配对到交错
 
-大模型不同阶段的训练目标，决定了我们需要喂入极其不同格式的数据。根据近年来的前沿结构（如 Flamingo (Alayrac et al. 2022), LLaVA (Liu et al. 2023), GPT-4V），典型的多模态文本主要被塑造成三种范式：
+大模型不同阶段的训练目标，决定了需要使用不同格式的数据。根据近年来的前沿结构（如 Flamingo (Alayrac et al. 2022), LLaVA (Liu et al. 2023), GPT-4V），典型的多模态文本主要包括三种范式：
 
 ### 8.2.1 图文对 (Image-Caption Pairs)
-这是最古典、最“堆量”的范式。
+这是最基础、最易规模化的范式。
 - **形式**：严格的一张图对应一段独立的强描绘文字 `{ "image": "dog.jpg", "text": "A golden retriever playing fetch in the park." }`。
 - **代表开源集**：LAION-5B (Schuhmann et al. 2022), COYO-700M。
 - **适用场景**：主要用于冷启动阶段的**多模态对比学习（Contrastive Pre-training）**，比如训练 CLIP 的前置模型，或者给新接入的 Vision Encoder 建立基础的视觉感知基线。
-- **致命弱点**：无法教会模型推理，只能使其学会认物。
+- **主要局限**：难以单独教会模型推理，更多用于建立基础物体识别和跨模态检索能力。
 
 ### 8.2.2 交错图文 (Interleaved Image-Text)
 为了赋予模型在复杂上下文中的“多图关联推理”能力，数据引擎必须从网页端提取还原“原生交错版面”。
 - **形式**：类似于我们在维基百科或微信公众号中看到的结构：一段起因 + `<img_1>` + 发展过程 + `<img_2>` + 结局总结。图像 Token 被视为一种特殊的词汇，散落在长文本序列之间。
 - **代表开源集**：OBELICS (Laurençon et al. 2023), MMC4 (Zhu et al. 2023)。
-- **适用场景**：这是当今**生成式 VLM 预训练**的最核心弹药。它教会模型如何根据“前文”和“图片 1”，去推断“后文”或“图片 2”应该是什么。
+- **适用场景**：这是当今**生成式 VLM 预训练**的重要数据形态。它教会模型如何根据“前文”和“图片 1”，去推断“后文”或“图片 2”应该是什么。
 - **采集挑战与 DOM 解析工程**：交错图文的工程难度庞大。传统的文本爬虫遇到 `<img>` 标签直接跳过，而为了组装交错格式，爬虫必须解析极为庞杂的 HTML DOM 树，并进行**“基于渲染坐标的相对距离计算”**。
-  因为在很多现代网页的复杂级联样式（CSS）中，代码文档树的顺序往往并不是用户眼里的视觉排版顺序。如果仅按照 HTML 标签顺序提取，很可能把页面底部的免责声明强行与顶部的配图绑定。
+  因为在很多现代网页的复杂级联样式（CSS）中，代码文档树的顺序往往并不是用户眼里的视觉排版顺序。如果仅按照 HTML 标签顺序提取，很可能把页面底部的免责声明错误绑定到顶部配图。
   
-  为此，顶尖团队通常会使用带渲染引擎的无头浏览器（Headless Browser，如 Playwright）运行 JavaScript 生成页面快照，利用类似于下面的规则提取元素：
+  为此，工程团队通常会使用带渲染引擎的无头浏览器（Headless Browser，如 Playwright）运行 JavaScript 生成页面快照，利用类似于下面的规则提取元素。
+
+  代码清单8-1展示了 DOM 交错节点提取的示意逻辑。
+
+  **代码清单8-1：DOM 交错节点提取示意代码**
+
   ```python
   # 简化的 DOM 交错节点提取伪代码
   text_nodes, img_nodes = get_rendered_nodes(page)
@@ -88,19 +97,19 @@
               interleaved_sequence.append(f"<img_{node.id}>")
               save_to_image_db(node.url, node.id)
   ```
-  一旦 DOM 结构提取错位，模型就会读出张冠李戴的荒谬逻辑。
+  一旦 DOM 结构提取错位，模型就会学习到错误的图文对应关系。
 
 ### 8.2.3 长文档理解与截图 Grounding (Document Grounded)
-面对 B 端商业落地的真实需求（看财报、读发票），传统的自然图像训练完全失效，必须引入高分辨率文档数据。
+面对 B 端商业落地的真实需求（看财报、读发票），传统自然图像训练往往不足，必须引入高分辨率文档数据。
 - **形式**：输入的是渲染后的高频高清晰度截屏文档图（如 ArXiv 论文或密集型的 Excel 截图），对应输出结构化的 JSON 取值序列或者边界框（Bounding Box）坐标 `<box>`。
-- **适用场景**：极其依赖极高分辨率的分块（Patching）和 OCR 的辅助。主要用于 SFT（监督微调阶段）教会模型实施精密的值提取与逻辑结构理解（如公式与图表的指代排版）。
-- **坐标归一化工程**：在 Grounding 任务中，模型需要输出物体的具体像素坐标。然而，训练图片的分辨率千差万别，为了让语言引擎能“读懂”坐标，通常需要将原始的绝对像素坐标 `(X, Y)` 映射到位 `[0, 1000]` 的离散 Token 桶中（即 `[<loc_255>, <loc_899>]`）。这种离散化强行将连续空间的坐标变为了大语言模型熟悉的“词汇表”。
+- **适用场景**：依赖高分辨率分块（Patching）和 OCR 辅助。主要用于 SFT（监督微调阶段）教会模型实施精密的值提取与逻辑结构理解（如公式与图表的指代排版）。
+- **坐标归一化工程**：在 Grounding 任务中，模型需要输出物体的具体像素坐标。然而，训练图片的分辨率千差万别，为了让语言引擎能“读懂”坐标，通常需要将原始的绝对像素坐标 `(X, Y)` 映射到位 `[0, 1000]` 的离散 Token 桶中（即 `[<loc_255>, <loc_899>]`）。这种离散化将连续空间坐标转化为大语言模型熟悉的“词汇表”形式。
 
 **表8-1：图文样本类型、特征与适用任务表**
 
 | 样本类型 | 数据特征 | 核心获取手段 | 最高适用阶段 | 带来的关键能力 |
 | :--- | :--- | :--- | :--- | :--- |
-| **纯图文对 (Image-Caption)** | T/I 一对一，高噪声 | 网页 `<img alt>`，公有云 OSS 爬取 | 对齐预训练 (Alignment) | 基础特征感知、跨模态检索检索 |
+| **纯图文对 (Image-Caption)** | T/I 一对一，高噪声 | 网页 `<img alt>`，公有云 OSS 爬取 | 对齐预训练 (Alignment) | 基础特征感知、跨模态检索 |
 | **交错图文 (Interleaved)** | T/I 多对多，长序列 | DOM 树渲染解析、PDF 线性化剥离 | 主力生成式预训练 | 多轮逻辑推理、Few-shot 上下文感知 |
 | **长文档截图 (Doc/OCR)** | 超高分辨率，文本密集 | PDF 渲染、无头浏览器自动化截图 | 深度 SFT / 强化学习 | 排版理解、表单/论文/发票抽取分析 |
 | **高精描绘 (Grounded Caption)** | 含边界框 `<box>` 的长文 | 标注员框选，或闭源千亿模型重写 | 高阶 SFT / RAG 对齐 | 图像细粒度空间感知与抗幻觉能力 |
@@ -109,16 +118,16 @@
 
 ## 8.3 清洗、过滤与语义对齐技术 (上篇：基础清洗)
 
-从全网抓取来的 Raw Data 泥沙俱下，必须经历至少三轮不同级别的漏斗挤压。我们将这一阶段称为前置清洗期（涉及极多的纯工程 I/O 操作及硬件加速的分类器运用）。
+从全网抓取来的原始数据质量差异很大，必须经历至少三轮不同级别的漏斗过滤。我们将这一阶段称为前置清洗期，它涉及大量 I/O 操作、图像解码和硬件加速分类器。
 
-### 8.3.1 格式硬解法则与 GPU 的“像素抢夺战”
+### 8.3.1 图像解码与 GPU 端预处理
 文本清洗时，`JSON.loads` 或 `open()` 几乎是零开销的操作；但面对数十 TB 甚至 PB 级的图像压缩包，**解码（Decoding）**本身就会演化为整个训练集群最大的吞吐瓶颈（Bottleneck）。
 在互联网上，图片可能是古老的 JPEG、体积庞大的 PNG，甚至带有破损文件头或嵌入 ICC 颜色配置错误的网络恶搞变种（WebP）。
 
 如果使用标准 Python 生态下的 CPU `Pillow` 或 `OpenCV-Python` 库来执行 Resize 和 Normalize：
 - 在 8 卡 A100 的节点上，哪怕给 PyTorch DataLoader 开满 `num_workers=64`。
 - 密集的 CPU 图片缩放运算也会瞬间填满所有物理核心。
-- 更致命的是，由于进程间通信（IPC）将庞大的非压缩 RGB 张量搬运到 GPU 显存中，PCIe 带宽也会被瞬间挤爆。从而导致 GPU 算力远未喂饱，处于高频的“饥饿等粮（GPU Starvation）”状态（MFU 跌破 20%）。
+- 更严重的是，由于进程间通信（IPC）需要将庞大的非压缩 RGB 张量搬运到 GPU 显存中，PCIe 带宽也可能成为瓶颈，从而导致 GPU 算力无法充分利用，出现 GPU Starvation（MFU 跌破 20%）状态。
 
 **工程解法：基于 NVIDIA DALI 的端到端流水线**
 在大型企业的图文处理阵列中，通常会强制切入基于 **NVIDIA DALI（Data Loading Library）** (NVIDIA 2023) 的显存级加速流水线。
@@ -127,27 +136,27 @@
 2. **NVJPEG 硬件解码**：字节流通过 PCIe 极宽的车道送入 GPU 后，调用 GPU 集成的专属 JPEG 硬件解码器（NVJPEG）在显存内部瞬间完成解压。
 3. **融合算子变换**：随后的裁剪（Crop）、调整尺寸（Resize）与方差均值归一化（Normalize）等操作全部被编译为一个 CUDA Graph，直接在张量上执行。
 
-通过这种“硬件接管一切”的手段，使得处理单张 512x512 图像的时间延迟能够从 CPU 端的 8ms 锐减至 0.4ms 以下。这是支撑万亿参数多模态模型能活下来的生命线（*详见附录与遗留参考图 `图6_2_使用DALI与不使用DALI的区别`*）。
+通过这种 GPU 端解码与融合预处理方式，处理单张 512x512 图像的时间延迟可以从 CPU 端约 8ms 降至 0.4ms 以下。该数字为截至 2026-06 的示例性性能口径，实际收益取决于图片格式、硬件、DALI 版本和并发设置；生产环境需按目标硬件复测。
 
 ### 8.3.2 分辨率与宽高比控制（Aspect Ratio Filtering）
-在原始清洗期，最无情也是提效最快的手法是制定“一刀切”的尺寸抛弃规则：
+在原始清洗期，提效最快的方法之一是制定尺寸过滤规则：
 - **拒绝像素孤岛**：对于短边低于 `224px` 或总体积低于 `20KB` 的图片直接抛弃。因为它们通常是 UI 小图标（如点赞按钮、小箭头），缺乏任何深层语义供大模型学习。
-- **猎除“极端面条图”**：由于互联网长图（如电商宣传页的全量拼接长图）的宽高比可能极度畸形（例如宽 500、长 9000）。当把这样的图片强行 Resize 缩放到 $336 \times 336$ 正方形以供常规 ViT 编码器吸收时，里面的内容将被挤压成一条竖线从而丢失一切轮廓特征。因此，通常要求**宽高比强制限制在 $[0.33, 3.0]$ 的区间内**，任何落出此区间的会被标记并进入针对性的“动态切片”旁路（会在 8.4 节详细介绍）。
+- **识别极端长宽比图片**：由于互联网长图（如电商宣传页的全量拼接长图）的宽高比可能极端（例如宽 500、长 9000）。当把这样的图片强制 Resize 到 $336 \times 336$ 正方形以供常规 ViT 编码器处理时，内容会被严重压缩并丢失轮廓特征。因此，通常要求**宽高比限制在 $[0.33, 3.0]$ 的区间内**，任何落出此区间的图片会被标记并进入针对性的“动态切片”旁路（见 8.4 节）。
 
 ### 8.3.3 NSFW、面部隐私与水印靶向拦截
-图文工程相比纯文本工程受到极高伦理合规关注：你决不能让你的多模态模型一开口或者一描述就生成人名隐私或版权宣发图。
+图文工程相比纯文本工程受到更高伦理合规关注：多模态模型不应学习素人人脸隐私、敏感内容或版权水印模板。
 在这一阶段的流水线通常串联部署了三至四个小型的纯视觉或分类网络：
-1. **NSFW 分类器**：对任何概率打分超过阈值（如0.4）的高挑感图像直接软删除。
+1. **NSFW 分类器**：对概率打分超过阈值（如 0.4）的高风险图像执行删除或隔离复核。
 2. **水印鉴别器 (Watermark Detector)**：由于大量网络图片来自图库（Getty Images、Shutterstock），一旦模型吸收了这些图，模型不仅会频繁在生成回答中“幻想”出那些水印字样，还会不可避免地遭到商用风险反噬。我们必须过滤掉所有带密集斜纹或高光中心水印的样本。
-3. **模糊度判定阈值 (Blur/Aesthetic Score)**：利用类似 LAION 团队训练的 AES（Aesthetic Predictor）美学评分模型，抛弃那些重度失焦、光照极度昏暗或充斥单纯彩色噪点的垃圾片源。
+3. **模糊度判定阈值 (Blur/Aesthetic Score)**：利用类似 LAION 团队训练的 AES（Aesthetic Predictor）美学评分模型，剔除重度失焦、光照极度昏暗或充斥彩色噪点的低质量图片。
 
 **多模态敏感数据过滤 Checklist（工业界标准）：**
-- [ ] 是否在文本侧集成了禁止词库（Blocklist），对 `<alt>` 标签中的暴恐、色情文字进行了强硬剔除？
+- [ ] 是否在文本侧集成了禁止词库（Blocklist），对 `<alt>` 标签中的暴恐、色情文字进行了过滤或隔离？
 - [ ] 视觉 NSFW 分类器是否针对二次元/插画模型（Anime NSFW）进行了补充训练以防漏网之鱼？
 - [ ] 肖像权隐私：是否调用了人脸模糊（Face Blurring）算法将高清晰度的素人人脸（非公众人物）打码？
 - [ ] 商业水印拦截库是否处于周度更新（Weekly Update）状态，防止新涌现图床的污染？
 
-完成了这三大基础清洗关卡，你的 100 亿庞大抓取库可能已经急剧锐减到了不到 40 亿规模。这些幸存的坚挺图像干净脱俗，但别高兴太早——**此时它们依然没有与文字发生过有效的“核心交流”**。在接下来的下篇，我们将祭出大杀器：CLIP Score。
+完成这三类基础清洗后，一个 100 亿级抓取库可能会缩减至 40 亿级以下。剩余图像在视觉层面更干净，但仍未证明与文本存在有效语义对应。接下来需要引入 CLIP Score 等跨模态匹配指标。
 
 ---
 
@@ -157,7 +166,7 @@
 
 ### 8.4.1 CLIP Score 及其进阶者 SigLIP 的量化哲学
 
-在 OpenAI 放出 CLIP（Contrastive Language-Image Pre-training）(Radford et al. 2021) 模型之前，判断图文匹配几乎是一门玄学。CLIP 通过大规模对比学习，巧妙地将图像片段（Image Embedding）和文本片段（Text Embedding）拉入到了同一个高维特征向量空间。
+在 CLIP（Contrastive Language-Image Pre-training）(Radford et al. 2021) 模型出现之前，判断图文匹配主要依赖人工规则或弱监督启发式。CLIP 通过大规模对比学习，将图像片段（Image Embedding）和文本片段（Text Embedding）映射到同一个高维特征向量空间。
 
 **1. 基础过滤动作与 InfoNCE Loss 的遗产**：
 我们通常使用预训练的稳定版 CLIP（例如开源版的 `OpenCLIP ViT-L/14`）分别对图和对应的 Caption 进行向量化前向推理，并计算两个向量的**余弦相似度（Cosine Similarity，即 CLIP Score）**。
@@ -169,8 +178,12 @@
 
 **2. 从 CLIP 到 SigLIP：摒弃全局 Softmax 的新方向**
 在大型企业数据管线中，传统的 CLIP 模型正逐渐被一种名叫 **SigLIP（Sigmoid Loss for Language Image Pre-Training）** (Zhai et al. 2023) 的新架构所取代。
-在传统 CLIP 训练时，模型计算的是整个 Batch 内图像和文本的全局 Softmax 概率。这就带来一个致命工程问题：如果你的分布式 Batch Size 巨大（例如 $32768$），那么强迫模型区分如此多对（Pair）的微小差异，会导致模型对某些“难负样本（Hard Negatives）”过于敏感，进而在推理 CLIP Score 时产生震荡。
-SigLIP 则将这个全局多分类问题，优雅地转化为了**逐对（Pairwise）的二分类 Sigmoid 预测问题**。这使得 SigLIP 对“部分匹配”或“复杂背景图文”拥有更高的宽容度和稳定的 Score 打分。工程团队可以设定更加精准一致的截断阈值，而不用担心因为领域漂移导致阈值突然失效。
+在传统 CLIP 训练时，模型计算的是整个 Batch 内图像和文本的全局 Softmax 概率。这会带来工程问题：如果分布式 Batch Size 很大（例如 $32768$），模型需要区分大量样本对的细微差异，可能对某些“难负样本（Hard Negatives）”过于敏感，进而使推理阶段的 CLIP Score 出现震荡。
+SigLIP 则将这个全局多分类问题转化为**逐对（Pairwise）的二分类 Sigmoid 预测问题**。这使得 SigLIP 对“部分匹配”或“复杂背景图文”拥有更高的容错空间和更稳定的 Score 分布。工程团队可以设定更一致的截断阈值，但仍需要在目标数据上校准。
+
+代码清单8-2展示了基于 SigLIP/CLIP 的图文对齐度过滤示意实现。
+
+**代码清单8-2：SigLIP/CLIP 图文对齐度过滤示意代码**
 
 ```python
 # 基于 SigLIP/CLIP 的图文对齐度过滤伪代码（可扩展为工业级流处理）
@@ -178,7 +191,7 @@ import torch
 from transformers import AutoProcessor, AutoModel
 
 device = "cuda" if torch.cuda.is_available() else "cpu"
-# 使用更稳定、无需巨型 Batch Size 的 SigLIP 权重
+# 使用无需超大 Batch Size 的 SigLIP 权重
 processor = AutoProcessor.from_pretrained("google/siglip-base-patch16-224")
 model = AutoModel.from_pretrained("google/siglip-base-patch16-224").to(device)
 
@@ -199,94 +212,94 @@ def filter_by_semantic_score(image, text_caption, threshold=0.25):
 
 ### 8.4.2 挽救优质图像：多粒度合成重标注 (Synthetic Re-captioning)
 
-当一张图像拥有极高的分辨率、绝佳的构图和罕见的实体，但其附带的原始网页文本却全都是废话（例如“IMG_20230401.jpg”）时，直接抛弃它是对数据资产的极大浪费。在算力充裕的今天，使用庞大强悍的专家级视觉大模型（如 LLaVA-1.5 (Liu et al. 2024)、Qwen-VL-Max (Bai et al. 2023) 或 GPT-4V）来**反客为主、重新生成描述**，是目前头部 AI 企业构建超越开源版 LAION 数据质量的杀手锏。
+当一张图像拥有较高分辨率、良好构图和罕见实体，但其附带的原始网页文本只是“IMG_20230401.jpg”这类无信息标签时，直接抛弃它会造成数据资产浪费。在算力允许的情况下，使用专家级视觉大模型（如 LLaVA-1.5 (Liu et al. 2024)、Qwen-VL-Max (Bai et al. 2023) 或 GPT-4V）重新生成描述，是提升图文训练数据质量的重要手段。
 
 在最新的大模型工程实践中，为了兼顾“冷启动对齐”与“后期长文本生成”的双重要求，数据团队会对这批图像实施流水线维度的“**多粒度（Multi-granularity）重标注阵列**”：
 
 1. **短描述（Short/Brief Caption）提取**：
    - **指令（Prompt）设为**：“仅用一句话，指出画面正中央最主要的主体及其核心动作。不超过 15 个字。”
    - **产出结果**：“一名拉小提琴的亚裔女性。”
-   - **工程价值**：极其纯净、没有修饰词的短句，非常适合在预训练最早期的第 1 个 Epoch 中，用于迅速拉平视觉 Encoder 和文本 LLM 之间极其基础的注意力绑定。如果一开始就喂入长篇大论，模型往往会因对齐焦点涣散而出现“幻视”。
+   - **工程价值**：信息集中、没有复杂修饰词的短句，非常适合在预训练早期用于建立视觉 Encoder 和文本 LLM 之间的基础注意力绑定。如果一开始就喂入长篇描述，模型可能因对齐焦点分散而出现幻觉。
 
 2. **长描述（Detailed/Dense Caption）渲染**：
-   - **指令（Prompt）设为**：“作为一名盲人视听解说员，请巨细靡遗地描写图片中的构图、光影、人物特征、服饰颜色、背景元素以及潜在的情绪氛围。长度在 150 字左右。”
+   - **指令（Prompt）设为**：“请客观描述图片中的构图、光影、人物特征、服饰颜色、背景元素以及可能的情绪氛围。长度在 150 字左右。”
    - **产出结果**：“在纽约时代广场的黄昏下，天空呈现出深邃的紫橘色晚霞。画面正中央，一名穿着破洞做旧牛仔裤和白色毛衣的亚裔女性正闭着眼拉奏一把红棕色的木质小提琴。画面的景深（Bokeh）较浅，她的背后是模糊的黄色出租车和闪烁的霓虹灯牌，整体氛围显得忧郁而专注。”
-   - **工程价值**：这种高密度信息是训练模型获得极强逻辑感、细节抵抗力和防止“一问三不知”幻觉的核心燃料。只有使用这种数据进行 SFT，模型才会被赋予出色的“图片观察描述力”。
+   - **工程价值**：这种高密度信息有助于训练模型获得细节识别能力和更稳定的图像描述能力。使用此类数据进行 SFT，可以提升模型在观察、描述和指代任务中的表现。
 
 3. **结构化边界框与 OCR 注入 (Grounded Injection)**：
-   - **并行流合并**：仅仅用大模型去“看”还不够准确，尤其是画面里出现密集数字时。重标注引擎的旁路（Side-car Workflow）会同步唤醒 PaddleOCR。如果在长描述发现画面背景恰好有一块广告牌，合并脚本会将其坐标转化为特殊的 Token 拼接入文本：`...背景是一块写着 "<box_45_120_350_200> Broadway 5th Ave. </box>" 的广告牌。` 这真正实现了将纯视觉符号在底层转化为确切的字符串引擎。
+   - **并行流合并**：仅用大模型观察图像仍不够准确，尤其是画面里出现密集数字时。重标注引擎的旁路（Side-car Workflow）会同步调用 PaddleOCR。如果在长描述中发现画面背景有一块广告牌，合并脚本会将其坐标转化为特殊 Token 拼接入文本：`...背景是一块写着 "<box_45_120_350_200> Broadway 5th Ave. </box>" 的广告牌。` 这使视觉符号能够在训练样本中转化为可定位的字符串和坐标信息。
 
 ![图8-2：图像语义对齐与过滤流程图](../../images/part3/image_semantic_alignment_flow.png)
 
-*图8-2：图像语义对齐与过滤流程图 —— 展示了具有工业水准的量化决策树：基于 CLIP 与启发式规则将劣质匹配筛出并送往大模型 Re-captioning 流水线，最后将图片 Zero-pad 或动态切分后存入黄金训练池。*
+*图8-2：图像语义对齐与过滤流程图 —— 展示基于 CLIP 与启发式规则的量化决策树，将低匹配样本筛出，将中等匹配但高价值图片送往 Re-captioning 流水线，最后将图片 Zero-pad 或动态切分后存入训练池。来源：本书自绘；Alt text：图像语义对齐与过滤流程图，展示质量过滤、CLIP 打分、重标注、动态切分和训练池入库之间的路径。*
 
 ---
 
 ## 8.5 采样配比、表示和训练适配策略
 
-完成了千难万险的数据清洗，终于到了将它们送往 GPU 嘴边的最后一米。在送入前，“切片打包（Packing）”和“比例混合（Mixing）”极其考验架构师的手感。
+完成数据清洗后，图文样本还需要在送入训练前完成切片打包（Packing）和比例混合（Mixing）。这一步直接影响显存占用、有效 Token 比例和能力分布。
 
-### 8.5.1 图像在序列中的“霸权”与 AnyRes 动态切分
+### 8.5.1 图像 Token 占用与 AnyRes 动态切分
 
-在常见的纯文本打包中，1000 个文字可能只需要 300 个 Token。但对于多模态，图像是一个绝对的序列霸主。以一张常规切分的 $336 \times 336$ 图片经过 ViT-L/14 处理为例，它将硬生生地挤占 576 个 Token 的槽位。
+在常见的纯文本打包中，1000 个文字可能只需要 300 个 Token。但在多模态训练中，图像会占用大量序列位置。以一张常规切分的 $336 \times 336$ 图片经过 ViT-L/14 处理为例，它会占用 576 个 Token 槽位。
 
 早期 VLM（如 CLIP 及其时代的诸多模型）通常对输入图像采取固定尺寸缩放（Resize）：无论是横版风景图还是纵向长文档，一律强制压缩至 $224 \times 224$ 的正方形，导致内容比例严重失真。为解决这一问题，现代数据工厂在预处理阶段普遍引入了 **AnyRes（动态高分辨率保持）** 策略：
 
 ![图8-3：AnyRes 动态多分辨率切割算法原理图](../../images/part3/anyres_dynamic_patching.png)
 
-*图8-3：AnyRes 动态多分辨率切割算法原理图 —— 展示了 AnyRes 的核心思想：左侧的超长全景图（High-Res Input）不再被暴戾压缩。而是被自适应网格（Adaptive Grid）划分为 $1 \times 3$ 个原生分辨率的局部图像块（Local Patches），同时结合右上方全局缩略图（Global Thumbnail）一同送入 Vision Encoder。这极大地保留了高频局部特征与宏观语义。*
+*图8-3：AnyRes 动态多分辨率切割算法原理图 —— 展示 AnyRes 的核心思想：左侧的超长全景图（High-Res Input）不再被强制压缩，而是被自适应网格（Adaptive Grid）划分为 $1 \times 3$ 个原生分辨率的局部图像块（Local Patches），同时结合右上方全局缩略图（Global Thumbnail）一同送入 Vision Encoder，以保留高频局部特征与宏观语义。来源：本书自绘；Alt text：AnyRes 动态多分辨率切割算法原理图，展示全景图被切成局部块并与全局缩略图共同输入视觉编码器。*
 
 **AnyRes 原理与核心策略详解：**
 1. **基础补零（Zero-padding / Letterboxing）策略**：对于不想失去原始横纵比，且分辨率未溢出的图，在周围补全黑色或均值边框凑成正方块，使得模型能学到相对的无失真几何形状。
-2. **多重补丁切割（Multi-Patch Splitting / Grid Cropping）**：将一张 $336 \times 1008$ 的超清竖版图片，动态匹配到 $1 \times 3$ 的切割网格（Grid），切割成 3 张 $336 \times 336$ 的正方形子图（Local Sub-patches）。同时，为了不失去全图视野，还会外加一张经过大幅下采样（Down-sampled）的**全局缩略图（Global Context Patch）**。这意味着这 1 张原图将被输入为 4 份 576 Token 的巨大矩阵块（合计消耗 2304 个 Token）。
+2. **多重补丁切割（Multi-Patch Splitting / Grid Cropping）**：将一张 $336 \times 1008$ 的竖版图片，动态匹配到 $1 \times 3$ 的切割网格（Grid），切割成 3 张 $336 \times 336$ 的正方形子图（Local Sub-patches）。同时，为了不失去全图视野，还会外加一张经过大幅下采样（Down-sampled）的**全局缩略图（Global Context Patch）**。这意味着这 1 张原图将被输入为 4 份 576 Token 的矩阵块（合计消耗 2304 个 Token）。
 3. **坐标编码注入（Positional Embedding Injection）**：被切开的子图不能随便丢进模型。在 DataLoader 组装阶段，必须为每个子图块打上类似 `[<row_1>, <col_1>]` 的二维相对位置编码，让模型知道哪块图在左、哪块在右。
 
-若不对这种交错图文做严格拼接控制，GPU 显存中将被庞大的无声像素挤满，文本逻辑学得极其缓慢。为此我们需要使用**基于长宽比分组（Aspect-Ratio Grouping）的 Sequence Packing** 技术：像贪吃蛇一样，把多长条同类的图文对塞入同一个 4096 的 Sequence 窗口，并在图像和图像块之间插入特殊的界限标识符 `<image>` 与 `</image>`，利用 Attention Mask 阻断跨文档的计算污染，从而节约显存边界带来的极大浪费。
+若不对这种交错图文做严格拼接控制，GPU 显存会被大量图像 Token 占用，文本逻辑学习效率下降。为此需要使用**基于长宽比分组（Aspect-Ratio Grouping）的 Sequence Packing** 技术：把形状相近的图文对放入同一个 4096 的 Sequence 窗口，并在图像和图像块之间插入特殊界限标识符 `<image>` 与 `</image>`，利用 Attention Mask 阻断跨文档计算污染，从而减少显存浪费。
 
 ### 8.5.2 三足鼎立的配比调参 (Data Mixing)
 
-正如人类的大脑需要不同知识成分的刺激，一个平衡的 MLLM 预训练面糊（Data Mix）需要精确分配抓取源的比重：
-1. **通用自然图像（Web Images）占比约 50-60%**：提供基础的世界物体常识（猫狗、汽车、风景色准、人物神态）。这部分通常由极其严酷 CLIP Score 筛选后的开源数据集（如 DataComp-1B (Gadre et al. 2023) 的核心过滤提纯集）承担。
-2. **图表与代码图纸（Charts/Plots/Math）占比约 15-20%**：提供顶尖的抽象数理推理能力。如果缺失此部分，大模型看折线图、股票 K 线图或是复杂的思维导图时，将会完全胡编乱造。
+一个平衡的 MLLM 预训练数据混合（Data Mix）需要精确分配不同来源的比重。以下比例为截至 2026-06 的示例性参数，实际需结合模型能力目标和消融实验校准：
+1. **通用自然图像（Web Images）占比约 50-60%**：提供基础的世界物体常识（猫狗、汽车、风景色准、人物神态）。这部分通常由严格 CLIP Score 筛选后的开源数据集（如 DataComp-1B (Gadre et al. 2023) 的核心过滤提纯集）承担。
+2. **图表与代码图纸（Charts/Plots/Math）占比约 15-20%**：提供抽象数理推理能力。如果缺失此部分，大模型看折线图、股票 K 线图或复杂思维导图时，容易产生错误解释。
 3. **高密度 OCR 文档截图（Documents）占比约 20-30%**：大量的扫描版白皮书、PDF 单页、收据发票影印件。这对于未来模型去充当“合同审查专员”或者“财务发票小助手”至关重要，它训练了模型克服自然图像中极少出现的“超高细粒度文本焦点”（Fine-Grained Text Focus）能力。
 
 **表8-2：图像清洗策略与代价对照表**
 
 | 清洗阶段策略 | 算力代价 | 核心作用与收益 | 残留风险与副作用 |
 | :--- | :--- | :--- | :--- |
-| **基础分辨率切除** | 极低（I/O密集） | 剔除无意义色块，节省 30% 储存开支 | 误伤具备极高历史意义但只留下低像素版本的（如旧新闻片）纪实图 |
-| **DALI 硬件提速解码** | 中低（GPU密集） | 打破 DataLoader 瓶颈，解码提速百倍 | 业务侵入性高，遇到奇异损坏 JPEG 格式易引发 C++ 库级核爆崩溃 |
-| **NSFW / 水印检测** | 中等（CNN前向） | 严守商业落地合规红线，防范安全灾难 | 漏杀难以杜绝对抗性微小水印，极考验检测分类器的持续演进 |
-| **SigLIP/CLIP 对齐** | 高（双塔特征） | 直接消除图文语义错乱，是认知质量根基 | 高分段可能有“语义白开水化”，扼杀带有深刻隐喻、讽刺意味的独特配图 |
-| **VLM 重标注合成** | 极高（LLM生成） | 颠覆烂数据基盘的终极手法，带来源头细节 | 资金燃烧速度极快，且易混入前序旧模型的幻觉或重复的机械句式结构 |
+| **基础分辨率切除** | 极低（I/O密集） | 剔除无意义色块，节省约 30% 储存开支（示例） | 误伤具备历史意义但只留下低像素版本的纪实图 |
+| **DALI 硬件提速解码** | 中低（GPU密集） | 缓解 DataLoader 瓶颈，解码可获得数量级提速 | 业务侵入性高，遇到损坏 JPEG 格式可能引发底层库异常 |
+| **NSFW / 水印检测** | 中等（CNN前向） | 严守商业落地合规红线，防范安全风险 | 漏杀难以杜绝对抗性微小水印，检测分类器需要持续演进 |
+| **SigLIP/CLIP 对齐** | 高（双塔特征） | 直接降低图文语义错乱，是认知质量基础 | 高分段可能趋向“语义平滑化”，误伤带有隐喻或讽刺意味的配图 |
+| **VLM 重标注合成** | 极高（LLM生成） | 为低信息原始描述补充细节 | 成本较高，且易混入前序模型的幻觉或重复句式 |
 
 ---
 
-## 8.6 真实踩坑案例与商业落地长效指南
+## 8.6 匿名化复合案例与商业落地长效指南
 
-在真实商业项目（例如集团 P03 多模态底座大模型研发）中，很多错误并不是算法推导出来的，而是在损失几千张 A100 的日租费后，用血泪总结出的真理。
+以下案例为匿名化复合案例，数据规模与成本只用于说明风险类型。实际项目中的 GPU 成本、样本量和质量收益需以具体硬件、数据许可和评测口径为准。
 
 ### 8.6.1 被大图库“绑架”的反向学习
 
-在研发早期阶段，某部门曾试图偷懒，直接下载清洗版的开源数据集 LAION-5B 某子集去进行对齐训练。在阶段性的交互盲审中，技术总监震惊地发现一个诡异现象：无论给模型看什么纯风景照片，模型大肆夸赞之余，必然在结尾极其高频地带出诸如：**“下载高清免水印图片请到 Shutterstock / Getty Images 获取同款”** 的垃圾口语。
+在研发早期阶段，某团队直接下载清洗版开源图文数据集的一个子集进行对齐训练。在阶段性交互盲审中，评测人员发现一个系统性现象：无论给模型看什么纯风景照片，模型都高频在结尾带出诸如“下载高清免水印图片请到某图库获取同款”的促销式文本。
 
-**教训复盘与拔除**：这被称为“图库污染现象（Stock Photo Contamination）”。即使是经过 CLIP Score 卡了极高阈值的“优质集”，只要它在收罗初期没有使用强力的 OCR 或特征分类下狠手切除带防盗水印的高分商业图，大型图床就会用其浩如烟海的垃圾推销模板文本，缓慢渗透并侵蚀模型最终学到的词汇条件概率分布。这是绝不能偷懒省钱的学费，对于严肃的商业级大模型，**必须针对特定的商业图床建立专门的负面哈希清单，对外部数据执行严密的“二次清洗净化池”**。
+**教训复盘与处理**：这被称为“图库污染现象（Stock Photo Contamination）”。即使是经过较高 CLIP Score 阈值筛选的数据集，只要在收集初期没有使用 OCR 或特征分类器过滤带防盗水印和模板宣传语的商业图，大型图床的促销模板文本就可能渗透进模型的条件概率分布。对于商业级大模型，**必须针对特定商业图床建立负面哈希清单，并对外部数据执行二次清洗**。
 
-### 8.6.2 为项目 P03 构建的多模态数据壁垒
+### 8.6.2 多模态数据资产的长期维护
 
-回顾我们整个图像文本数据工程的战略框架，图文大模型竞争的核心门槛从来都不在于“使用怎样的魔改版 Vision Encoder”，也不在于训练脚本到底写得多花哨。**真正的较量，往往发生在模型接收到第一个多模态 Tensor Token 的那几个月之前。**
+回顾整个图像文本数据工程框架，图文大模型竞争的关键不只在于 Vision Encoder 或训练脚本，也在于模型接收到第一个多模态 Tensor Token 之前的数据准备质量。
 
-当我们把从海量互联网废墟中挖出的冗余 DOM 树残片截击存下；经过极其漫长而艰险的高速硬件解码、严格到近乎苛刻的宽高比裁剪、滴水不漏的安全风控扫描；再到昂贵算力开路的 SigLIP 量化评测与庞大机器算力驱动的全方位高分辨率幻觉重写（Re-captioning）之后——那些曾经劣质、对不齐的网图烂梗，才被提炼成了一粒粒拥有丰满中英双语、且经过 Grounded 位置锚定标注长图注的黄金多模态配对（Golden Pair）。
+只有经过 DOM 结构解析、图像下载校验、硬件解码、宽高比裁剪、安全风控扫描、SigLIP 量化评测和高分辨率重标注（Re-captioning），原始网图与弱文本才可能被转化为包含双语描述、位置锚点和质量元数据的多模态配对样本。
 
-这些流淌着算法工程师汗水的“清洁数据水库”，不再是一块块冰冷发热的固态硬盘或者散乱无章的 JSON 文件。这套复杂的流水线上游能力，以及它所缔造出的数十亿精良的多模态交错对冲数据集，正是未来十年企业在多模态商战中最为牢固且不可复制的防御壁垒。
+这种数据资产不只是存储在磁盘中的 JSON 文件，而是由来源记录、过滤规则、重标注模型、抽检记录和评测反馈共同构成的长期工程能力。
 
 ## 本章小结
 
-本章作为拥抱多模态领域的揭幕战，我们详细铺陈了多模态数据区别于纯文本的“四重地狱挑战”，并逐级点出了图文工程的三大结构范式。为了平息图片压缩包对流水线的吞噬，我们探索了依靠底座硬件优化的 DALI 极速解码模式。
+本章作为第三篇的起点，系统说明了多模态数据区别于纯文本的四类挑战，并逐级介绍了图文工程的三大结构范式。为了缓解图片压缩包对流水线吞吐的影响，本章讨论了基于 DALI 的 GPU 端解码与预处理模式。
 
-针对错综复杂的语义对齐，我们以图解的形式剖析了以“CLIP Score 过筛”结合“高维 VLM 重标注”的雷霆手腕，将垃圾数据点石成金（流程式详见图8-2）。最后，本章通过配比调参和惨痛的开源踩坑案例，为企业级视觉大语言模型指明了可落地的质量守恒方向。
+针对复杂的语义对齐问题，本章以图解形式说明了“CLIP Score 过滤”与“VLM 重标注”的组合流程（见图8-2）。最后，本章通过配比调参和匿名化复合案例，说明了企业级视觉语言模型训练中需要持续维护的质量边界。
 
-虽然图文交织占据了现今多模态的半壁江山，但在复杂的 B 端工业应用场景（财报剖析、复杂发票查验、手书医疗单识别）中，单单依靠自然景物图依旧无法应对高密度的字符考验。下一章，我们将镜头对焦极其硬核的进阶领域：“**第 9 章：重标注与文档理解（OCR）**”，深度解密大模型如何通过特殊文本引擎练就一双堪比速读大师的火眼金睛。
+虽然图文交错是当前多模态训练的重要形态，但在复杂的 B 端工业应用场景（财报解析、复杂发票查验、手写医疗单识别）中，仅依靠自然景物图仍难以应对高密度字符和版面结构挑战。下一章将进入**第9章 重标注与文档理解**，讨论 OCR、版面解析和长文档理解数据工程。
 
 ## 参考文献
 
@@ -313,4 +326,3 @@ Schuhmann C, Beaumont R, Vencu R, Gordon C, Wightman R, Cherti M, Coombes T, Kat
 Zhai X, Mustafa B, Kolesnikov A, Beyer L (2023) Sigmoid Loss for Language Image Pre-Training (SigLIP). In: Proceedings of the IEEE/CVF International Conference on Computer Vision, pp 11975-11986.
 
 Zhu D, Chen J, Shen X, Li X, Elhoseiny M (2023) MiniGPT-4: Enhancing Vision-Language Understanding with Advanced Large Language Models. arXiv preprint arXiv:2304.10592.
-
diff --git a/docs/zh/part3/ch09_recaptioning_ocr.md b/docs/zh/part3/ch09_recaptioning_ocr.md
index 30ebcc70..8cff429b 100644
--- a/docs/zh/part3/ch09_recaptioning_ocr.md
+++ b/docs/zh/part3/ch09_recaptioning_ocr.md
@@ -1,114 +1,132 @@
 # 第9章 重标注与文档理解
 
-在上一章中，我们详细探讨了多模态数据清洗的前置流水线。通过剥离低分辨率图像、去除水印干扰、过滤敏感内容，并利用 CLIP Score 截断图文语义背离的劣质样本，我们在物理层面上构建了一个相对纯净的数据湖。
+## 摘要
 
-但当我们兴高采烈地用这批号称“黄金数据”送上训练集群，满心期待训出一个能和 GPT-4V 扳手腕的视觉模型时，现实往往是一盆极其冰凉的冷水——**模型似乎只能当个“近视眼的傻子”**。
-当你问模型：“图中穿红衣服的女孩在干什么？”
-模型会回答：“这里有一个穿红色衣服的女性。”
-当你上传一张《财富》杂志全英文的财报扫描件，问模型：“2023年该公司的 Q4 营收涨了多少？”
-模型不仅大概率答非所问，甚至会对密集的财报数字当场捏造幻觉。
+本章讨论图文数据在完成基础清洗后仍需进一步重标注和文档结构化的原因。章节首先分析原始网页 Caption 的弱描述、漏描述和语义泛化问题，说明简短描述、密集描述、Grounded Caption 与多模态对话在不同训练阶段的作用。随后，本章介绍工业级重标注流水线，包括开源 VLM 批量生成、多模型互审、人工金标样本和结构化 BBox 注入，并给出成本、吞吐和风险的估算口径。文档理解部分聚焦 OCR、版面分析、表格解析、公式还原和坐标对齐，说明为什么高密度文档不能仅靠高分辨率图像输入解决。最后，章节建立重标注/OCR 质量评价矩阵，并通过匿名化复合案例说明金融文档数据重构的价值。读者应能够设计面向自然图像与长文档的重标注和 OCR 增强数据管线。
 
-这就引出了多模态数据工程步入深水区的核心命题：**为什么极其干净的图文数据，依然不足以支撑一个能思考的高级多模态模型？** 本章将解答这个问题，并带你深入多模态两大硬核高精尖工程：**高质量重标注策略（Re-captioning）** 与 **OCR 结构化文档理解（Document Understanding）**。
+## 关键词
+
+重标注；Re-captioning；OCR；文档理解；版面分析；BBox；Grounding；质量评估
+
+## 学习目标
+
+- 能够解释原始 Caption 的弱描述和漏描述如何限制视觉语言模型能力。
+- 能够设计短描述、密集描述、Grounded Caption 与多模态对话的分层数据策略。
+- 能够比较开源 VLM、商业 API、多模型互审和人工金标在重标注中的成本与风险。
+- 能够说明 OCR、版面分析、表格解析和坐标对齐在文档理解中的作用。
+- 能够建立重标注与 OCR 数据的机器质检、人工抽检和错误归因机制。
+
+在上一章中，我们详细探讨了多模态数据清洗的前置流水线。通过剥离低分辨率图像、去除水印干扰、过滤敏感内容，并利用 CLIP Score 截断图文语义背离的低质量样本，我们在视觉层面上构建了一个相对干净的数据湖。
+
+然而，视觉层面的干净并不等于训练监督信号充分。例如，当用户询问“图中穿红衣服的女孩在干什么”时，模型如果只回答“这里有一个穿红色衣服的女性”，说明它学习到了对象类别，却没有学习到动作、场景和关系。又如，将一张英文财报扫描件输入模型并询问“2023 年该公司的 Q4 营收涨了多少”，若模型无法稳定读取表格数字并进行计算，就说明基础图文对数据不足以支撑高密度文档理解。
+
+这引出了本章的核心问题：**为什么经过清洗的图文数据，依然不足以支撑高级多模态理解？** 本章将围绕两类关键工程展开：**高质量重标注策略（Re-captioning）** 与 **OCR 结构化文档理解（Document Understanding）**。
 
 ---
 
 ## 9.1 为什么原始 Caption 远远不够用？
 
-### 9.1.1 “弱描述”与“漏描述”带来的能力阉割法则
+### 9.1.1 “弱描述”与“漏描述”带来的能力限制
 
-即使那些经过前置流水线（如基于 CLIP Score 的双塔计算，余弦相似度拉满的对齐操作）层层筛选出的多模态数据，其绝大部分源头依然是基于全网粗暴爬取的。互联网文本生态存在一个根深蒂固的问题：网页开发者为了追求极致的页面加载高效、抑或是 HTML 文本填充组件（`Alt-text`）的天然设计局限，**原生网页对网络图片的伴生描述普遍是极度“干瘪”（Impoverished）甚至是敷衍了事的**。
+即使是经过前置流水线筛选出的多模态数据，其源头也往往来自互联网网页。互联网文本生态存在一个基础问题：网页开发者为了页面加载效率、SEO 或无障碍占位，通常不会为每张图片编写完整语义描述。受 HTML `Alt-text` 设计和使用习惯限制，**原生网页对网络图片的伴生描述普遍较为简略（Impoverished）**。
 
-以大规模开源数据集 LAION-5B (Schuhmann et al. 2022) 中的某个典型样本为例：一张拍摄到了金色阳光斜射的实木书桌，桌上放着一把樱桃青轴机械键盘、一杯喝了一大半的冰美式咖啡，且背景有着极具层次感的模糊书架（一张极高分辨率的 1080p 摄影图）。但在数据工厂爬取的原生态配对中，其极其简短的文本标签（Caption）很可能只是：
+以大规模开源数据集 LAION-5B (Schuhmann et al. 2022) 中的某个典型样本为例：一张拍摄到金色阳光斜射的实木书桌，桌上放着一把机械键盘、一杯冰美式咖啡，且背景有层次分明的模糊书架（一张 1080p 摄影图）。但在数据工厂爬取的原生态配对中，其文本标签（Caption）可能非常简短：
 > “*一个普通的办公桌桌面*” 或者仅仅是 “*IMG_2023_Office.jpg*”
 
-**对模型底层重构网的破坏性：**
-这种数据如果大量充斥在流水线中，其危害远大于“脏数据”。这是一种慢性毒药。如果将海量类似于“办公室一角”这种极度模糊、高度泛化的标签当做 SFT（监督微调）或者预训练的对齐前缀给到大语言网络，模型会将画面中整整 200 万个高清红绿蓝像素矩阵（RGB Pixels）全部暴力压缩并试图去拟合这短短 6 个汉字的条件概率。
-因此，在这场跨模态的运算中，模型压根就不会去学习“半杯咖啡的反光”、“机械键盘键帽的凹陷”以及“阳光照射的真实光影方向”在视觉编码器隐空间里的确切表征向量。这种由于文本特征严重偏科或缺席，导致视觉模型自动屏蔽小面积物体的现象，在深度学习工程界被称为**“弱描述导致的密集物体失明（Dense Object Blindness / Entity Dropout）”**。
+**对模型学习信号的影响：**
+这种数据如果大量进入流水线，危害不只是“信息少”，还会改变模型的注意力分配。如果将海量类似“办公室一角”这种模糊、高度泛化的标签作为 SFT 或预训练的对齐前缀，模型会尝试用画面中数百万个 RGB 像素去拟合一个信息量很低的短文本目标。
+因此，模型很可能不会学习“半杯咖啡的反光”、“机械键盘键帽的凹陷”以及“阳光照射方向”等细粒度视觉特征。这种由于文本特征严重缺席，导致视觉模型忽略小面积物体的现象，可概括为**弱描述导致的密集物体失明（Dense Object Blindness / Entity Dropout）**。
 
-这不仅导致模型彻底丧失了细节特征捕捉的精细颗粒度，更可怕的一点在于，**漏描述会引发严重的逻辑对齐冲突与训练震荡**。设想图片里明明占据主位的是一只白猫，而爬取的短文本只字未提“猫”，只提了“白色背景”。那么当强大的视觉编码器（Vision Encoder）本能地抽取出猫的轮廓向量特征，然后顺着反向传播梯度强行要求与目标文本对齐时，视觉网络就会陷入极其崩溃的“隐性矛盾”中。它会误以为猫的轮廓就是“背景”二字的具象化，从而极大地损害最终多模态基础理解层在各项客观榜单中的稳定性评估成绩（例如导致模型在 MME (Fu et al. 2023)、MMBench (Liu et al. 2023b) 的目标检测与归纳分数上止步不前）。
+这不仅会削弱模型的细节捕捉能力，还会引发逻辑对齐冲突。设想图片中主体是一只白猫，而爬取的短文本只提“白色背景”。当视觉编码器（Vision Encoder）抽取出猫的轮廓向量特征，而训练目标却要求它与“背景”对齐时，模型就会学习到错误对应关系，从而损害多模态基础理解层在 MME (Fu et al. 2023)、MMBench (Liu et al. 2023b) 等评测中的稳定性。
 
-### 9.1.2 简略描述与长文本细节描述的生态壁垒差异
+### 9.1.2 简略描述与长文本细节描述的分层差异
 
-在真实的研发与数据蒸馏管线（如支撑千亿参数基座的 P03 项目）中，数据架构师深知不能奢求“一套数据打通关”。为了使多模态基础模型的能力如阶梯般平稳爬升，必须在不同的训练阶段，将视觉数据严格划分为截然不同的文本粒度大类去投喂：
+在研发与数据蒸馏管线中，数据架构师通常不会期待“一套数据覆盖所有阶段”。为了使多模态基础模型能力逐步提升，必须在不同训练阶段，将视觉数据划分为不同文本粒度：
 
 1. **简短核心感知描述（Brief / Short-form Caption）**：
    - 展现形式：像“一只奔跑的金毛犬”或“两辆停泊的红色轿跑”。
-   - 核心效用：此类数据成本低廉且容易获得（几十亿条级别）。它的唯一价值，是能够在**多模态预训练极为早期的对齐阶段（Stage 1: Modality Alignment）**迅速建立投影关系。
-   - 工程隐喻：它就像是在给模型发“看图识字卡片”，强行教会 Transformer 底座如何将基础物理世界解构件的外形与最基础的名词词典（Vocabulary）建立坚不可摧的底层绑定系数。
+   - 核心效用：此类数据成本较低且容易获得（十亿级别）。它的主要价值，是能够在**多模态预训练早期的对齐阶段（Stage 1: Modality Alignment）**迅速建立投影关系。
+   - 工程作用：它类似于“看图识字卡片”，用于帮助 Transformer 底座将基础物体外形与名词词表（Vocabulary）建立初步对应。
 
 2. **长文本密集结构化描述（Dense Detailed Caption / Recounting）**：
    - 展现形式：如“在一片光线充足的午后草地上，天空飘着两朵稀薄的积雨云。一只金毛犬正张着嘴向画面右侧奔跑...”
-   - 核心效用：此类数据资源稀缺，原始互联网上抓取量极少，只能依靠昂贵的二次计算人工合成或机器渲染。
-   - 工程隐喻：它属于高级燃料。只有在**高阶 SFT 微调阶段（Stage 2 & Stage 3: Visual Instruction Tuning & Preference Alignment）**被克制而精准地大量注入，才能教导模型真正做到“如顶级人类观察者一般巨细靡遗地视察周围复杂环境并流利叙述”。
+   - 核心效用：此类数据资源稀缺，原始互联网上抓取量较少，通常需要二次模型生成、人工合成或机器渲染。
+   - 工程作用：它更适合在**高阶 SFT 微调阶段（Stage 2 & Stage 3: Visual Instruction Tuning & Preference Alignment）**注入，用于提升模型对复杂环境的细节观察和组织表达能力。
 
 3. **混合配比（Data Mixing）的艺术**：
    - **不能多喂短描述**：预训练后期如果 90% 都是短描述，模型会丧失长句生成能力（Caption Degradation）。
-   - **黄金比例**：在工业界标准的 SFT 阶段，通常采用 **30% 短描述 + 50% 密集描述 + 20% 多模态对话** 的混合比例，以兼顾概念认知与指令服从性。
+   - **示例比例**：在 SFT 阶段，可采用 **30% 短描述 + 50% 密集描述 + 20% 多模态对话** 的混合比例，以兼顾概念认知与指令服从性。该比例为截至 2026-06 的示例性参数，实际需按模型能力目标校准。
 
-因此，要让模型从单纯的“看图识字（感知）”走向庞大深邃的“图像理解、世界规律推理与共情（认知）”，唯一的数据破局解法就是彻底丢弃原生爬取的廉价低质文本，踏入另一条大量消耗昂贵 GPU 并行计算成本、但最终对齐产出价值爆棚的硬核主赛道：**Synthetic Re-captioning（大模型合成重述工程）**。
+因此，要让模型从“看图识字（感知）”走向“图像理解、关系推理与指令回应（认知）”，需要将原生爬取的低信息文本与高质量重标注数据结合使用。核心工程路径就是 **Synthetic Re-captioning（大模型合成重述工程）**。
 
 ---
 
-## 9.2 工业级重描述策略 (Re-captioning) 的火力阵列
+## 9.2 工业级重描述策略 (Re-captioning) 的分层流水线
 
-重描述（Re-captioning）的核心底层思想其实非常直白：既然野生爬来的标签数据太烂、太缺细节，那我们就倒逼流水线，让算力更强的闭源视觉大模型（甚至不惜动用到专家标注员）把海量的废土图片重新仔细地端详一遍，并写出一套令人赏心悦目的高质量解析长文。
+重描述（Re-captioning）的核心思想是：当原始网页标签过于简略或缺少细节时，使用能力更强的视觉语言模型或专家标注员，为图像生成更准确、更完整的描述文本。
 
-然而，在这个动辄以“10亿张图片过滤”为基础单元的预训练战场上，重修十亿量级图片所消耗的 API 调用费与 GPU 显存日租足以摧毁任何一家中型 AI 公司的年度算力财报预算。因此，不能对所有图片一视同仁。建立包含多层级过滤分诊、级联降级策略自动化并发流水线调度打法，成为了工程师们在此立足的唯一根本。
+然而，在动辄以“10 亿张图片过滤”为基础单元的预训练场景中，重标注十亿量级图片会消耗大量 API 调用费与 GPU 推理成本。因此，不能对所有图片一视同仁。工程上通常需要建立多层级过滤分诊、级联降级和自动化并发调度机制。
 
-### 9.2.1 金字塔分层流水线：从小尺寸快刷到大模型互审 (MoE-Judge)
+### 9.2.1 金字塔分层流水线：从轻量生成到多模型互审 (MoE-Judge)
 
-在真实的工业数据工厂中，为了兼顾昂贵的 GPU 算力成本和标注的纯净度，业界通常不会“一招鲜吃遍天”，而是会采用严密的**倒金字塔式漏斗调度策略（Pyramid Triage Strategy）**：
+在工业数据工厂中，为了兼顾 GPU 算力成本和标注可靠性，业界通常会采用**倒金字塔式漏斗调度策略（Pyramid Triage Strategy）**：
 
-#### （1）底层基建清刷：开源模型自动化批量重注（Fast Prompting）
-对于那些构图简单、基础物体占比超过 70% 的低端常识自然图像（如一张单纯的风景照或单色背景下的商品图），如果动量庞大数十亿，那么雇佣数据标注员甚至调用昂贵的 GPT-4V API 都是对金钱的犯罪。在这庞大如海的底座阶层，数据工程团队必须依赖部署于企业内部私有算力集群上的、且极易量产部署的“小参数但表现强悍的开源视觉模型”（如 LLaVA-1.5 (Liu et al. 2024) 7B、Qwen-VL-Chat、InternVL-1.2 等）去进行 **Fast Prompting (流水线快刷)**。
+#### （1）基础层：开源模型自动化批量重注（Fast Prompting）
+对于构图简单、基础物体占比超过 70% 的自然图像（如单纯风景照或单色背景下的商品图），如果规模达到数十亿张，直接雇佣数据标注员或调用昂贵商业 API 并不经济。在这一基础层，数据工程团队通常依赖部署于内部私有算力集群的小参数开源视觉模型（如 LLaVA-1.5 (Liu et al. 2024) 7B、Qwen-VL-Chat、InternVL-1.2 等）进行 **Fast Prompting（批量快速生成）**。
+
+**严格的 Prompt 模板约束示例**：
+想要避免开源小模型生成发散描述，Prompt 工程必须明确约束事实性、长度和输出范围。代码清单9-1给出一个重标注 Prompt 模板示例。
+
+**代码清单9-1：重标注 Prompt 模板示例**
 
-**严苛的 Prompt 模板约束示例**：
-想要避免开源小模型写成发散的记流水账，Prompt 工程必须极度收敛。
 ```text
 [System Instruction]: You are a neutral, highly objective visually impaired helper. 
 [Task]: Describe the main objects, actions, and physical background in this image concisely and accurately. 
 [Constraint]: Do NOT use any generic filler words like 'This is an image of' or 'I can see'. Do NOT guess the location if no text is shown. Keep the entire response strictly under 50 words. Focus solely on visible facts.
 ```
 
-#### （2）中坚层对冲：多模型交叉互审机制（Multi-Model-as-a-Judge）
-当我们面对稍微复杂的“交错场景”图像、密集的杂乱环境或是含有细微文化特征的图片时，单一的百亿级别开源模型必然会暴露其致命短板——**极其严重的幻觉发散倾向**（例如把地上盘踞的一条黑色花园灌溉水管，信誓旦旦地辨识成一条巨大的黑色毒蛇）。
-为了抵御这种不可避免的单一模型隐性缺陷，流水线会自动将此类复杂批次升级切入到 **“三盲交叉互审制（MoE-Judge）”** 流水线中：
+#### （2）中间层：多模型交叉互审机制（Multi-Model-as-a-Judge）
+当面对复杂的交错场景、密集环境或含有细微文化特征的图片时，单一开源模型容易出现幻觉发散（例如把地上的黑色花园灌溉水管识别成黑色蛇）。
+为了降低单一模型的隐性缺陷，流水线会自动将此类复杂批次升级到 **“三盲交叉互审制（MoE-Judge）”**：
 1. **并行分诊（Parallel Inference）**：图像同时且独立地送入架构截然不同的视觉引擎 $V_1$ (如基于 CLIP 偏向的 LLaVA)、$V_2$ (如参数量庞大的专有版 InternVL)、以及 $V_3$ (如偏向结构化认知的 Pix2Struct (Lee et al. 2023) 或 Donut (Kim et al. 2022))。
-2. **异构体产出（Heterogeneous Output）**：这三个视觉脑子会同时吐出三段极度不同的描述 $C_1, C_2, C_3$。
-3. **判官裁决（LLM Judgement & Fusion）**：此时不需要任何视觉功能，直接切入一个极其强悍的纯文本逻辑裁判（比如 Claude-3.5-Sonnet 或 GPT-4-Turbo）。裁判会提取三个描述中的“重叠高频语义实体（Overlapping Semantics）”，并将三人产生分歧（只有单方观察到）的边缘名词或者可疑实体全部无情抹平。进而熔炼出一个兼顾了“细节丰富”却又“事实防弹壁垒极高”的无争议重述结果。
+2. **异构输出（Heterogeneous Output）**：三个视觉模型会同时生成三段不同描述 $C_1, C_2, C_3$。
+3. **文本裁决与融合（LLM Judgement & Fusion）**：再调用一个纯文本模型（如 Claude-3.5-Sonnet 或 GPT-4-Turbo）提取三个描述中的重叠高频语义实体（Overlapping Semantics），并对只有单方观察到的边缘名词或可疑实体进行降权，生成兼顾细节和事实一致性的重述结果。
 
-#### （3）顶层提纯：强人工精调与 Golden Truth 标尺确立
-在整个漏斗流水线的最顶层（通常这部分数据仅占数据湖总量的不到 0.05%），自动化的脚本彻底沉寂，数据科学小组会向外部的精锐团队下达高昂的工单。
-这些人工描画不是随便扔给众包平台的日结临时工就可以应付的。由于多模态对齐对于名词的精确度和层级结构有着类似于数学定理般的严谨追求，必须经过长达四周系统培训的精锐标注员（甚至要求本科以上学历）出马。他们要在专用的内部圈注工具上对细小边角逐一打靶。这一小撮数据虽然少，但它构成了随后重描述打分系统（Reward Model）或者微调底层基座模型（Base Model）时唯一不可撼动的终极 **Golden Truth（金标真值库）**。
+#### （3）高价值层：人工精调与 Golden Truth 标尺确立
+在整个漏斗流水线的最高价值层（通常这部分数据仅占数据湖总量的不到 0.05%），自动化脚本主要承担候选筛选与质检记录，数据科学小组会把样本交给经过培训的标注团队进行精标。
+这些人工描画不能只依赖低门槛众包。由于多模态对齐对名词精确度和层级结构有较高要求，标注员通常需要接受系统培训，并在专用内部标注工具上逐一确认细小区域。虽然这部分数据占比很低，但它构成了后续重描述打分系统（Reward Model）或微调底层基座模型（Base Model）时的重要 **Golden Truth（金标真值库）**。
 
 **表9-1：重描述自动化生产梯队对比与优劣表**
 
-| 重述层级调度方式 | 每百万张评估成本 | 集群并发生产吞吐速度 | 复杂场景及图表解析能力 | 核心优越性与落地防范隐患 |
+注：表9-1中的成本与吞吐为截至 2026-06 的估算示例，实际结果取决于模型版本、云厂商/API 定价、并发限制、图片分辨率、缓存策略和人工标注地区。
+
+| 重述层级调度方式 | 每百万张评估成本（示例） | 集群并发生产吞吐速度（示例） | 复杂场景及图表解析能力 | 主要优势与落地风险 |
 | :--- | :--- | :--- | :--- | :--- |
-| **小参数 VLM 本地批刷** (参数 $< 15B$) | \~$100 极低 | > 14,000 张/节点/小时 | 极弱（面对表格几乎完全空白） | **优势**：纯属白菜价算力，能快速建立底层基础物体的对齐认知护城河。<br>**防范隐患**：极易产生幻觉灾难，绝不能用于细粒度训练。 |
-| **头部商业 API 提纯** (API 如 GPT-4o) | \~$15,000 | 严重受限 (并发限流 \~5K/小时) | 极强，逻辑满分 | **优势**：拥有无与伦比的语境常识感知，产出的长文本高密度、高质量。<br>**防范隐患**：燃烧预算飞快，且由于 API 的安全对齐过严，极易频繁遭遇阻断拒绝回答。 |
-| **私有化混合框架多路互审** | \~$800 (纯折算内部消耗卡时) | ~ 2,000 张/多节点/小时 | 较弱 | **优势**：完全本地自建防泄漏泄密，极大程度地通过交集抹杀了低级发散幻觉。<br>**防范隐患**：节点架构极其臃肿，三节点串行等待严重拖慢节奏。 |
-| **多轮高昂的人工精标** | \~$200,000 以上 (天价成本) | < 50 张/专家/小时 | 完美全解解析，附带情绪色彩 | **优势**：作为唯一不可被挑战的标尺质量天花板，指引模型上限。<br>**防范隐患**：毫无规模化放量的可能，人类标注员也极可能因视觉疲劳导致低级拖拽错位。 |
+| **小参数 VLM 本地批刷** (参数 $< 15B$) | \~$100 | > 14,000 张/节点/小时 | 弱（面对表格通常表现不足） | **优势**：成本低，能快速建立基础物体对齐。<br>**风险**：容易产生幻觉，不适合细粒度训练。 |
+| **头部商业 API 提纯** (API 如 GPT-4o) | \~$15,000 | 受限（并发限流 \~5K/小时） | 强 | **优势**：语境常识较强，产出的长文本密度较高。<br>**风险**：预算消耗快，且可能受安全策略影响出现拒答。 |
+| **私有化混合框架多路互审** | \~$800（内部卡时折算） | \~2,000 张/多节点/小时 | 中等 | **优势**：可本地运行，降低数据泄露风险，并通过交集降低幻觉。<br>**风险**：架构复杂，多节点串行等待会拖慢节奏。 |
+| **多轮人工精标** | \~$200,000 以上 | < 50 张/专家/小时 | 强 | **优势**：可作为高质量标尺数据。<br>**风险**：难以规模化，标注员可能因视觉疲劳导致拖拽错位。 |
 
 ### 9.2.2 从“看图背书”到物理世界指引：细粒度对齐与 BBox 双向注入
 
-传统的 Image Caption 技术最大的瓶颈在于：它仅仅将图像当成了一个个词汇的“堆填区（Bag of Words）”。只靠猛力堆叠文字词汇，依然不能打造出顶尖的具身智能（Embodied AI）或视觉助理模型。如果你想要让模型真正具备强悍的数学几何感、物理方位感以及对现实空间的控制力，我们必须在数据工程上引入一项具有颠覆意义的重磅操作：**细粒度属性定位标记 (Fine-grained Grounding)**。
+传统 Image Caption 技术的主要瓶颈在于：它往往只把图像映射为一组词汇或一句描述。只堆叠文字标签，仍然不足以训练具备空间定位、数学几何感和物理方位感的视觉助理模型。为此，数据工程上需要引入**细粒度属性定位标记（Fine-grained Grounding）**。
 
-毫无疑问，在这个深度技术模块的加持下，原本用来给人类阅读的连续文本，其底层的构成逻辑发生了翻天覆地的异变。文本本身必须化身为一套“自带微缩坐标系”的数据流标记结构：
-在重写高分图片的描述流水线上，架构师会在旁路（Side-car Workflow）强行唤醒如 **GroundingDINO** (Liu et al. 2023c) 乃至专门训过的 **SAM (Segment Anything Model)** (Kirillov et al. 2023) 等极强的零样本物件检测界碑框架。这些极度冷静冰冷的目标检测器，会如剥洋葱般提取到画作中所对应物体的精确像素或归一化坐标序列（例如：画面深处的一颗苹果精准定位于 `[x_min=320, y_min=550, x_max=450, y_max=690]` 这一微弱的包围盒中）。
+在这个模块中，原本给人类阅读的连续文本，需要被转化为一套自带坐标信息的数据流标记结构。在高分图片的重写流水线上，架构师会在旁路（Side-car Workflow）调用 **GroundingDINO** (Liu et al. 2023c)、**SAM (Segment Anything Model)** (Kirillov et al. 2023) 等零样本或弱监督目标检测框架，提取图像中物体的精确像素或归一化坐标序列（例如：画面深处的一颗苹果定位于 `[x_min=320, y_min=550, x_max=450, y_max=690]` 的包围盒中）。
 
-面对这种底层结构，下游负责整合的文本组装 Python 脚本，将绝不再是仅仅满足于输出一句温吞的“一个通红的苹果放置在靠左下侧的方桌上”，而是会强硬地截断生成，并向这串本是给模型食用的自然语言字符串矩阵中，极其暴力地**注入结构化且闭合的 XML 定位标记**：
+面对这种底层结构，下游负责整合的文本组装脚本不再只输出“一个通红的苹果放置在靠左下侧的方桌上”这样的自然语言句子，而是会向训练文本中**注入结构化且闭合的 XML 定位标记**。代码清单9-2展示了一个 XML Grounding 示例。
+
+**代码清单9-2：XML Grounding 定位标记示例**
 
 ```xml
-在画面深处的木制方桌的左下位置（阳光暗面），静静放置着一颗红润透亮的 <object name="apple" bbox="[[320, 550, 450, 690]]">苹果</object>，不仅如此，紧贴着它的左侧还有一摞极其陈旧的厚重 <object name="book" bbox="[[500, 520, 680, 750]]">相关医学书籍</object>。
+在画面深处的木制方桌左下位置，放置着一颗 <object name="apple" bbox="[[320, 550, 450, 690]]">苹果</object>；其左侧还有一摞 <object name="book" bbox="[[500, 520, 680, 750]]">医学书籍</object>。
 ```
 
-为什么要进行如此具有破坏性而繁琐的数据组装？
-这是因为 Transformer 本身并没自带对于“远近左高低”的空间绝对感知。当成千上万、多达数百万个这种从“人类口语词汇”横跨到充斥着密集排列的 `[Bbox_xx_yy]` 离散坐标数字令牌的数据组合进入训练引擎（SFT 流水线）被疯狂吸食之后，奇迹便会彻底发生：
-在随后的推理评测中，这个模型便犹如开了天眼一般。它不仅能在回答“图里有什么”时对答如流，更能在你质问它“指给我看苹果在哪里”时，精确地在输出的回答语句中自带出一套坐标点阵，并在 UI 返回界面上精准地框选出一个极高质量的精密红框。这不仅是跨越幻觉最硬核的对抗手段，这也是诸如网页代理执行机器人（Web Visual Automation Agent）等诸多高端应用的唯一底层数据法则。
+这样做的原因是 Transformer 本身并不天然具备“远近、左右、高低”的绝对空间感知。当大量从自然语言词汇扩展到 `[Bbox_xx_yy]` 离散坐标令牌的数据组合进入 SFT 流水线后，模型不仅可以回答“图里有什么”，还可以在“指出苹果在哪里”这类任务中输出坐标或区域引用。这是降低空间幻觉、支撑网页视觉代理（Web Visual Automation Agent）等应用的基础数据设计。
+
+**工业级重描述 JSONL 样例（Re-captioning Schema）**
+最终经过 VLM 合成的重描述数据，会被封装成带有严格元数据的 JSONL 文件。代码清单9-3给出一个示意样例，字段和路径均为脱敏示例。
 
-**工业级重描述 JSONL 样例代码库（Re-captioning Schema）**
-最终经过 VLM 合成的重描述数据，会被封装成带有严格元数据的 JSONL 文件。以下是一个真实的业务截断样例：
+**代码清单9-3：重描述 JSONL Schema 脱敏示例**
 
 ```json
 {
@@ -128,111 +146,108 @@
 }
 ```
 **字段解释**：
-- `original_caption`：原始爬取的废纸标签。
+- `original_caption`：原始爬取的低信息标签。
 - `recaption`：大模型合成的长文本描述与生成模型源记录。
-- `grounding_bboxes`：通过 GroundingDINO 提取并强行映射的细粒度实体坐标，是训练基座具备“指认能力”的核心。
+- `grounding_bboxes`：通过 GroundingDINO 提取并映射的细粒度实体坐标，是训练基座具备“指认能力”的核心。
 - `clip_score`与`quality_flag`：用于前置校验过滤的自动打分，低于 0.65 则设为 REJECT 丢弃。
 
 ![图9-1：重标注与 OCR 双流线增强图](../../images/part3/recaptioning_ocr_pipeline.png)
 
-*图9-1：重标注与 OCR 增强联合的双轨高阶管道图（Dual-track Pipeline） —— 全景清晰展示了现代数据引擎的两副面孔：左侧展现了宽泛语义密集叙述流（Semantic Vision Track），而右侧展示了即将要步入雷区的强制包含DOM排版分割与表格矩阵的高密度结构流（Structural Text Track）。最终归一融合结为统一的混合监督模版格式。*
+*图9-1：重标注与 OCR 增强联合的双轨管道图（Dual-track Pipeline） —— 左侧展示语义密集叙述流（Semantic Vision Track），右侧展示包含 DOM 排版分割与表格矩阵的高密度结构流（Structural Text Track），最终融合为统一的混合监督模板格式。来源：本书自绘；Alt text：重标注与 OCR 双流线增强图，展示视觉重描述、OCR 结构提取、BBox 注入和混合监督格式之间的关系。*
 
-至此，针对自然图像与纯景物类图片的重标注强化管线已经建立完毕。然而，真正能够在商业落地中区分企业级视觉大模型竞争力的，是接下来的高密度字符深水区：面向长文档的强阅读推理与复杂商业报表的结构化解码解析。
+至此，针对自然图像与纯景物类图片的重标注管线已经建立。真正影响企业级视觉模型落地能力的，是下一类高密度字符场景：长文档阅读推理与复杂商业报表的结构化解析。
 
 
 ---
 
-## 9.3 突破视觉像素极限：OCR 增强与长硬干文档理解
+## 9.3 OCR 增强与长文档理解
 
-在自然景物图片中，普通的基座 VLM 似乎对分辨“这是金毛犬还是边境牧羊犬”驾轻就熟，仿佛已经具备了超越人类的认知。可一旦你给它投喂一张扫描版的增值税发票，或者包含了密密麻麻多级标题、嵌套合并单元格的 PDF 商业行研定量报告残页，哪怕你丧心病狂地把图像强行切分推高至 AnyRes 甚至夸张的 4K 分辨率输入，模型给出的答案依然会令人极度啼笑皆非：它不是理直气壮地读错关键的小数点，就是把第一列和第三列的财报数据硬给跨栏交叉连线，最终导致幻觉满天飞。
+在自然景物图片中，普通基座 VLM 可以较好地区分常见物体类别。但面对扫描版增值税发票、包含多级标题和嵌套合并单元格的 PDF 商业研报残页时，即使将图像切分推高至 AnyRes 或 4K 分辨率，模型仍可能读错关键小数点，或把不同列的财报数据错误关联，最终产生幻觉。
 
-这背后的深度机理在于：无论多么庞大、架构多么花哨的 Vision Transformer (ViT)，**它的卷积降采样（Down-sampling）或自注意力机制的本质，始终是在提取大块连贯区域的平滑光影与颜色纹理规律（如猫毛的质感、天空的渐变）**。然而，人类社会发明的文本符号恰好与纯视觉的低频渐变相反：文字是极端稀疏、频次极速变幻、充满高频断崖的离散突变点。对于字符而言，差一个偏旁部首，也就是差了 5 个像素，其代表的语义可能南辕北辙。指望大语言模型仅仅依靠纯视觉 Encoder 自身的权重，去从茫茫的 16x16 Patch 中领悟微弱的符号跳变规律学得认字认算，这就如同希望闭着眼睛的猿猴直接学会敲击键盘写出操作系统内核代码一样绝望。
+这背后的原因在于：无论 Vision Transformer (ViT) 的规模多大，**卷积降采样（Down-sampling）或自注意力机制本质上仍在提取大块连贯区域的光影与颜色纹理规律**。然而，文本符号与视觉低频纹理不同：文字是稀疏、高频、离散的符号系统。对于字符而言，差一个偏旁部首或几个像素，语义可能完全不同。仅依靠视觉 Encoder 从 16x16 Patch 中学习所有字符与表格结构，通常并不可靠。
 
-为了攻克这道似乎违背了信息论法则的铁腕屏障，数据工程领域不得不从纯端到端的迷梦中醒来，并坚决引入了一条较为繁琐但实证有效的古典混合辅线：**外挂 OCR 与文档解析强制增强流水线 (Optical Character Recognition & Layout Boosting)**。
+因此，数据工程需要在纯端到端视觉输入之外，引入一条繁琐但实证有效的混合辅线：**外挂 OCR 与文档解析增强流水线（Optical Character Recognition & Layout Boosting）**。
 
-### 9.3.1 文档图像的结构化拆卸工序 (Layout Demolition)
+### 9.3.1 文档图像的结构化解析工序 (Layout Parsing)
 
-处理长文档绝不仅仅是调用一下网上的某个百度 OCR 或者 Google Vision API 服务，拉回连续文本就万事大吉了。商业长文本存在常见且难处理的**非线性视觉排版（Non-linear Layouts）**：左右分栏的双栏学术论文、横插在段落中间的财报宽图、侧边竖排的审阅注释、甚至毫无营养的页眉页脚和防伪水印干扰。如果在塞入模型之前不预先进行基于视觉结构感知的“解构重组”，暴力提取出的文字序列在模型语言大脑的眼里将毫无逻辑，阅读顺序完全错乱。
+处理长文档并不是简单调用 OCR 或云视觉 API 后拉回连续文本。商业长文本存在常见且难处理的**非线性视觉排版（Non-linear Layouts）**：左右分栏的双栏学术论文、横插在段落中间的财报宽图、侧边竖排的审阅注释，以及页眉页脚和防伪水印干扰。如果在进入模型之前不预先进行基于视觉结构感知的“解构重组”，直接提取出的文字序列往往缺少逻辑顺序。
 
-在顶流的数据清洗车间中，文档的预处理会被切割为如同流水线装配一般的严密层级：
+在成熟的数据清洗车间中，文档预处理通常被拆分为层级化流水线：
 
-1. **第一级 OCR：版面边界截断网（Layout Detection）**
-   我们要上的第一把重型手术刀，是专门打磨的版面定位网络（如基于 YOLOv8 或 LayoutLMv3 (Huang et al. 2022)）。它的任务是**圈划疆场**，在几十毫秒内精准定位：标题组（Title）、正文池（Body Text）、脚注（Footnote）、柱状图容器及代码块（Code Snippet）。
+1. **第一级 OCR：版面边界定位（Layout Detection）**
+   第一层通常是专门的版面定位网络（如基于 YOLOv8 或 LayoutLMv3 (Huang et al. 2022)）。它的任务是在页面中定位标题组（Title）、正文池（Body Text）、脚注（Footnote）、柱状图容器及代码块（Code Snippet）。
 2. **第二级 OCR：多维领域特化提取管线（Domain-specific Extraction Pipeline）**
-   完整的 PDF 被“拆除粉碎”后，各类独立的像素模块（Cropped Patches）会被并发推送（Dispatch）给极其特化的提取管线中进行抢救萃取：
+   完整 PDF 被切分为独立像素模块（Cropped Patches）后，会被并发推送（Dispatch）给领域特化的提取管线：
    - **文档级文本提取**：对于纯文字段落，分发给 Tesseract 或 PaddleOCR 进行高精度拼写矫正提取。
    - **数学公式逆向编译**：遇到密集公式组，标准 OCR 错误率极高。路由给专门微调的开源引擎（如 Nougat (Blecher et al. 2023)）或商业服务（如 Mathpix），将图像直接还原为严格的 LaTeX 代码流（如：`\int_{0}^{\infty} e^{-x^2} dx`）。
-   - **复杂表格拓扑重构**：带有合并单元格与跨页表头的表格最令人头疼。必须重载类似 TableMaster 的专精架构，将视觉上的横竖线，强制转换为连人类难以手写、但机器读起来极工整的 HTML 表格标签链或 Markdown 树。
+   - **复杂表格拓扑重构**：带有合并单元格与跨页表头的表格最难处理。可以使用类似 TableMaster 的专门架构，将视觉上的横竖线转换为机器可读的 HTML 表格标签链或 Markdown 树。
 
-在多级 OCR 提取后，核心工程难点在于**坐标全对准机制（Modality Absolute Geometric Alignment）**。提取出的这三类文字如果不与图片上的像素区域建立羁绊，模型依旧不知道眼睛往哪儿看。业界在每段文本后强行追加 `<box_coord>` 的文本映射串，迫使注意力机制遵循这些“坐标指南针”。
+在多级 OCR 提取后，核心工程难点在于**坐标对准机制（Modality Absolute Geometric Alignment）**。提取出的文字如果不与图片上的像素区域建立绑定，模型仍不知道应关注页面的哪个区域。常见做法是在每段文本后追加 `<box_coord>` 映射串，让注意力机制可以参考这些坐标锚点。
 
 ![图9-2：文档结构 Layout-to-Token 映射图](../../images/part3/document_structure_sample.png)
 
-*图9-2：文档结构 Layout-to-Token 映射图（Document Structure Layout-to-Token Mapping） —— 图中左半区全景展示了一份经典的极度复杂双栏学术报告残页；系统首先通过 Bounding Box 阵列将其残暴洗劫与拆卸提取（配合各异的红黄蓝分类颜色锚框标注）；而右半区则详尽地解剖了：由外挂特化模型矩阵（Nougat+PaddleOCR）各自为战硬解析后，又是如何通过脚本后置强制归并，最终交织生成为层级深渊分明的（Hierarchical Textual Tokens） Markdown 代码文本 + 精确离散绝对坐标 `[x_y]` 的巨长富文本数据流。正是这批包含了海量知识拓扑的数据流，构成了深度教导基座 SFT 从此“懂得认知世界规整排版”的终极“微积分强化课本”。*
+*图9-2：文档结构 Layout-to-Token 映射图（Document Structure Layout-to-Token Mapping） —— 左半区展示一份双栏学术报告残页；系统首先通过 Bounding Box 阵列定位标题、正文、图表和公式区域；右半区展示 Nougat、PaddleOCR 等特化模型输出如何经脚本后处理，归并为层级化 Markdown 文本与离散坐标 `[x_y]` 的富文本数据流。来源：本书自绘；Alt text：文档结构 Layout-to-Token 映射图，展示文档页面被版面检测、OCR、公式解析和坐标标注转换为层级文本序列。*
 
-### 9.3.2 “强文本引擎”对超高分辨率的碾压收缩与降维打击
+### 9.3.2 文本引擎对超高分辨率输入的降维作用
 
-这种建立在“视觉特征提取 -> Bounding Box -> 结构化离散字符串序列”基础上的数据预处理机制，一旦打通，将极大地释放底层训练集群的计算瓶颈。因为原本需要视觉模型在训练期耗费大量算力去识别的高难度字符集，已经在外挂预处理车间（CPU/GPU 混合 OCR Pipeline）中被解析为了长文本 Prompt，并作为上下文输入。此时，视觉模型只需在相对较低的分辨率下快速处理全图，**提取宏观的排版布局与物理空间特征即可**。
+这种建立在“视觉特征提取 -> Bounding Box -> 结构化离散字符串序列”基础上的数据预处理机制，可以显著降低底层训练集群的字符识别负担。原本需要视觉模型在训练期识别的高难度字符集，已经在预处理阶段（CPU/GPU 混合 OCR Pipeline）中被解析为长文本 Prompt，并作为上下文输入。此时，视觉模型只需在相对较低的分辨率下处理全图，**提取宏观的排版布局与物理空间特征即可**。
 
-系统随后将立刻切断视觉端的所有负荷，将所有剩下的长文本账单深究主场任务（如第三行和第十行的乘积是多少），统统让渡给大模型基座体内那个深沉如海、强悍无匹、计算成本相对廉价的**长上下文序列分析器（Long-context LLM Brain）**。
-这就将**多模图文理解**这场超级难缠的二维恶战，降维打击式地拉扯到了**超十万字上下文运算阅读 (Long-context Comprehension)** 这一大语言自然模型最无敌、也是其最擅长统治的主战场赛道之上。这也直接揭开了为何近期涌现的那批最新架构（犹如 Qwen-VL (Bai et al. 2023) 等系列），只靠不高的百亿参数，便能在各大中英双语的复杂财报查验与顶级商业卷宗试卷榜单中，做到大杀四方的终极底气和面纱。
+系统随后将部分高难度字符识别负荷转移到文本侧，将长文本账单分析任务（如第三行和第十行的乘积是多少）交给计算成本相对可控的**长上下文序列分析器（Long-context LLM）**。
+这会将多模图文理解中的一部分二维视觉解析问题，转化为长上下文阅读（Long-context Comprehension）问题。也正因如此，Qwen-VL (Bai et al. 2023) 等架构能够通过 OCR、版面结构和视觉特征结合，在复杂财报、商业文档和试卷类任务中取得较好表现。
 
 ---
 
 ## 9.4 质量评价框架、抽检漏斗与缺陷归因测试矩阵
 
-在这个每天动辄用千万级人民币经费砸出来的 OCR 与长程 Re-captioning 庞杂交织预处理车间里，如果你把质量监督环节当做可有可无的放羊式管理，那么哪怕仅仅是 0.5% 的崩塌样本或者幻觉标签倒灌，也足以让耗资几个亿的千卡算力集群在几个月的日夜运转后，最终吐出一个只会胡言乱语、毫无商业价值的“智障模型”。因此，在将这些合成后的重注数据推向主训练流之前，我们必须建立起一道不讲任何情面、如同铁腕一般的**大厂工业级数据质检刑场**。
+在 OCR 与长程 Re-captioning 交织的预处理车间里，如果质量监督环节缺位，即便只有 0.5% 的崩塌样本或幻觉标签倒灌，也可能在长周期训练中被放大。该比例为示例阈值，实际容忍度取决于训练阶段、数据权重和目标任务。因此，在将合成后的重标注数据推向主训练流之前，必须建立工业级数据质检流程。
 
-### 9.4.1 机器无情评分的悬丝诊脉法（Heuristic & Model Scaling Validation）
+### 9.4.1 机器评分与启发式验证（Heuristic & Model Scaling Validation）
 
-对于高达数亿级别的数据，人工是不可能看完哪怕万分之一的。我们首先必须部署全量自动化的大规模启发式与验证模型（Heuristic & Scaled Validator）：
+对于数亿级别的数据，人工无法覆盖足够比例的样本。首先需要部署全量自动化的大规模启发式与验证模型（Heuristic & Scaled Validator）：
 
-1. **苛刻的长短文本一致性交叉降维校验（Consistency Penalty Test）**：
-   - **算法架构流水线**：重注中心通常会产出长达 500 字的啰嗦密集文本（Dense Caption）。前置质检探针（Probe）会先将这 500 个字通过一个轻量级的词性标注器（如 NLTK 或 SpaCy），强制抽提浓缩成 5 个最核心的物理实体大名词（如“键盘、咖啡、桌子、显示器、阳光”）。
-   - **双盲自裁决标准**：随后，让这五个被抽提出来的大名词回归最初的本源：强行使用最底层的原版视觉网络去跑一遍前代的 CLIP Score 相似度余弦散列计算（将抽提名词特征空间与原始图片像素特征点阵列比对）。如果发现这五个**核心名词的特征向量内积均值**，不仅没有比原始互联网爬取的废纸标签（如“办公室一角”）变得更高，反而出现了异常跌落——系统会立刻触发 P0 级红色警报。这必然说明上游的“重注大模型彻底飘了”，它完全放弃了看图，陷入了不可名状的自言自语。运维中控机将立刻发令定点爆破，销毁该节点当日产生的所有数据包。
+1. **长短文本一致性交叉校验（Consistency Penalty Test）**：
+   - **算法架构流水线**：重注中心通常会产出长达 500 字的密集文本（Dense Caption）。前置质检探针（Probe）会先将这 500 个字通过轻量级词性标注器（如 NLTK 或 spaCy）抽取成 5 个最核心的实体名词（如“键盘、咖啡、桌子、显示器、阳光”）。
+   - **一致性标准**：随后，将这五个实体名词与原始图片重新计算 CLIP Score 或 SigLIP 相似度。如果核心名词的特征向量内积均值没有比原始互联网标签（如“办公室一角”）更高，甚至出现异常下降，系统应触发 P0 级质检警报。这通常说明上游重标注模型没有充分依据图像内容生成描述，需要隔离该节点当日产生的数据包。
 
-2. **纯粹粗暴的标点、正则流与大语言防环路污染过滤（Syntax & Glitch Sweeping）**：
-   - 即便不看复杂的几何语义模型反馈，光看生成文本的隐层字符排布也能抓住严重的合成质量问题。如果大批经过 OCR 模型（如 PaddleOCRv4）加持后生成的 PDF 富文本数据末尾，频频出现了孤立异常规模的未闭合 HTML 标签诸如 `</html>`、连串卡死的 `[ERROR] [NO_RESPONSE]`、值得注意的乱码（比如满屏的 `äääää` 或 `` 占位符污染）。
-   - 最为致命的，是大模型长程推理常常陷入的**连续超过 20 行完全重复的无逻辑废话（经典的 Repetition Glitch 极速死循环死锁）**。一旦系统日志中此类正则异常截断率超过节点水位线的 0.05%，调度节点必须直接物理熔断该推理实例，防止毒数据无底线地注入核心特征水库。
+2. **标点、正则与重复环路过滤（Syntax & Glitch Sweeping）**：
+   - 即便不运行复杂的几何语义模型，只检查生成文本的字符排布也能发现严重合成质量问题。例如，大批经过 OCR 模型（如 PaddleOCRv4）处理后的 PDF 富文本数据末尾，频繁出现孤立的未闭合 HTML 标签 `</html>`、连续的 `[ERROR] [NO_RESPONSE]`、乱码（如 `äääää`）或占位符污染。
+   - 另一类高风险问题是大模型长程推理陷入重复环路，例如连续超过 20 行完全重复。若系统日志中此类正则异常截断率超过节点水位线（如 0.05%，示例口径），调度节点应暂停该推理实例并隔离输出数据。
 
-### 9.4.2 Human-in-the-Loop 人工盲抽与多阶层法医级归因框架
+### 9.4.2 Human-in-the-Loop 人工盲抽与多层归因框架
 
-即便机器防御雷达扫描过的地方一切安好，最后一道昂贵的**专家人工盲抽校验池（Human-in-the-Loop Blind Sampling & Verification）**依旧不可逾越。每天，总控中心会随机抽样调取 20,000 张包含重箱嵌套结构的超复杂文档测试用例样本，派发给高度专业的人工审核专家大厅。
+即便机器质检指标全部通过，最后一道**专家人工盲抽校验池（Human-in-the-Loop Blind Sampling & Verification）**仍然必要。每天，总控中心可随机抽样调取包含复杂嵌套结构的文档测试用例样本，派发给专业人工审核团队。20,000 张/日这类数字仅为大型团队的示例口径，实际抽样量应按数据量、风险等级和预算确定。
 
-这批专家不仅要评判优劣，更要像法医一样，从长达几百页的 Token 列表中为模型开发团队提供详尽的“战损归因报告”。为了彻底阻断“算法各模块的工程师遇到训练发散时只会互相甩锅不承认”（例如视觉工程师怪大语言底座差，大语言工程师怪视觉漏了特征），集团评测组必须依照如下铁律架构，建立了工业界最为著名的事故定性分流排查树：
+这批专家不仅要评判优劣，还要从长文档 Token 列表中为模型开发团队提供错误归因报告。为了减少训练发散后的责任不清（例如视觉工程师认为语言底座不足，语言工程师认为视觉特征缺失），评测组需要建立事故定性分流排查树：
 
 **表9-2：跨模态及高级文档识别 OCR 核心错误归因与修复阵列矩阵**
 
-| 灾难级别错误特征在底座视角的物理表现层 | 专家工作台根源鉴定（法医级归因分析剖析） | 核心修复工程开发流水线阻击策略与架构迭代迭代方案 |
+| 错误特征在模型输出中的表现 | 专家工作台根源鉴定 | 核心修复策略与架构迭代方案 |
 | :--- | :--- | :--- |
-| **细小数学物理公式或下划线账单全线读错崩溃，小数点移位灾难** | 这是纯粹的外挂 OCR 或 Table 识别引擎提取精度的绝对失败。 | 不能怪语言模型。必须立刻更换架构或者强制重采数百张密集表格，重新微调上游基于 Paddle/Mathpix 的视觉子网络，并且将文档入模的 AnyRes 分辨率强行提高。 |
-| **版面结构彻底错乱：大纲标题串区，第一张图表的图例强行乱入了第二栏学术正文** | PDF 版面分析算法（Layout Analysis Boundary）的分类器框定策略发生破损或遭遇极强水印重叠蒙蔽。 | 立即重做布局节点特征树聚合启发式代码；立刻摒弃原本基于弱规则组合的 HTML 抽取，强行改用极其消耗算力的 LayoutLM 或高阶 YOLO 进行全监督回归画框。 |
-| **指鹿为马的高深幻觉：比如把左边桌子上的一堆细长黑色笔筒，强行赋予深远寓意解释成“茶杯拉长的水纹倒影”** | 视觉编码基座并没有瞎，而是作为大脑的 Re-captioning大模型在合成长文本时，过度文青发散，陷入了常识盲区的多模态联想幻觉发作。 | 必须换用百亿参数量以上、带有极其严格的拒绝惩罚 RLHF (强化学习对齐) 机制的模型进行二次重注；在流程中强制引入前置的三盲互审引擎投票判决机制来剔除修饰词。 |
-| **胡言乱语答非所问，前言不搭后语，输入了中英文但输出全成了不带逻辑火星文或全零矩阵** | 此类毁灭性现象通常不是弱智，绝大概率是在最底层的多线程数据序列化、Byte-Pair 打包，或是 Tokenizer 词表隐射转换过程发生极其严重的指针越界、数据越位泄漏。 | 研发主架构师接管阵列。这完全属于上层应用组装 C++/CUDA 的内存泄漏报错。必须完全叫停所有训练脚本进程，返回到数据读取算子层执行深切大修与断点排错调试。 |
+| **细小数学公式或表格小数点读错** | 外挂 OCR 或 Table 识别引擎提取精度不足。 | 更换或微调上游 Paddle/Mathpix/Table OCR 模型；补充密集表格样本；必要时提高文档入模分辨率。 |
+| **版面结构错乱：标题串区，图例进入第二栏正文** | PDF 版面分析算法的分类器框定策略失效，或受到水印/栏线干扰。 | 重做布局节点特征树聚合规则；从弱规则 HTML 抽取升级为 LayoutLM 或高阶 YOLO 版面检测。 |
+| **细节幻觉：把笔筒解释为不存在的物体或抽象含义** | Re-captioning 模型在合成长文本时过度发散，产生常识或视觉实体幻觉。 | 换用更严格的重标注模型；引入三盲互审与实体一致性过滤；降低修饰词权重。 |
+| **答非所问或输出异常乱码** | 可能是多线程数据序列化、Byte-Pair 打包或 Tokenizer 词表映射转换出错。 | 回到数据读取算子层排查；检查 Placeholder、特殊 Token、编码和 batch 拼装逻辑。 |
 
 ---
 
-## 9.5 真实工程案例与后传连接点
+## 9.5 匿名化复合案例与章节衔接
 
-### 9.5.1 金融行研知识库重生的艰难历程（项目P05）
+### 9.5.1 金融行研知识库的 OCR 重构（匿名化复合案例）
 
-在 2025 年初，集团算法部门接到了一个全公司的年度核心业务：构建某国字号券商级别的**“商业全报表智能辅助穿透与质控引擎”（代号 P05）**。起初，算法研发小组过度依赖于“大力出奇迹”的狂热信仰，他们将收集来的整整八百万份各行业研报 PDF 以及脱敏财务扫描件直接进行了粗暴分页。随后，他们寄希望于将这些切分后的纯图片输入给拥有 72B 参数的百亿视觉基座模型中，期待模型能够凭空引发奇迹并看懂一切。
-结果在耗费了极高昂算力的第一轮闭门盲测中，模型上演了令人惊骇的灾变：它不仅只能笼统地回答“图中有一张表”，更可怕的是，在回答诸如“三线城市重金属业务的分润同比下跌与环比上涨对比”这种极度细节的拷问时，它竟然会直接跨越行段当场捏造一个完全不存在的营收数字；面对一份厚达数百页、充满了页眉水印干扰的招股书扫描件，这台造价上亿算法机器的实际可用性和问答准确率甚至完全比不上使用 PDF 软件 `Ctrl+F` 搜索框的一名高校在校实习大四全职生。
+以下为匿名化复合案例，时间、规模、模型参数和提升幅度为截至 2026-06 的工程估算示例，不代表特定企业公开事件。某金融团队计划构建“商业全报表智能辅助穿透与质控引擎”。起初，算法研发小组将约八百万份各行业研报 PDF 以及脱敏财务扫描件直接分页，并将分页后的图片输入 72B 参数视觉基座模型，希望模型直接完成阅读与问答。
+结果在第一轮闭门盲测中，模型只能笼统回答“图中有一张表”。在回答“三线城市重金属业务的分润同比下跌与环比上涨对比”这类细节问题时，模型会跨行段捏造不存在的营收数字；面对厚达数百页且带有页眉水印干扰的招股书扫描件，问答准确率明显低于预期。
 
-在被愤怒的金融业务方彻底打回原形后，我们随即切断了整个算力阀门，耗时整整大半个月，硬是将这原本寄予厚望的八百万份财报打回数据车间彻底重造。
-这不再是简单地把图片丢进显存里。在新重构的极端的 OCR 装配流水线中，每一页、每一张长图都被多层网络精确、毫不留情地切割。它不仅单独扣出了饼状图与折线图的图像特征板块，更将那些繁长晦涩的密集营收表格全部压碎。随后，数据中心满载调用了重型算力集群和特种的高配 Table OCR，硬生生地在原来那 800 万份图片周边，塞满了高达大几十 GB 的巨量附魔辅助文本：其中密密麻麻地包含了所有的单元格绝对边界位置锚点（BBox Anchor）、结构化嵌套且首尾完美闭合的 HTML 或者 Markdown 转述语义标签树的数据驱动矩阵串联。
+团队随后暂停训练任务，用约半个月时间将这批财报数据退回数据车间重构。在新的 OCR 装配流水线中，每一页、每一张长图都被多层网络切分：饼状图与折线图被独立提取，密集营收表格被转化为结构化表格，随后通过 Table OCR 补充单元格边界位置锚点（BBox Anchor）、结构化 HTML 或 Markdown 标签树，以及页码、图表编号和来源元数据。
 
-真正的事实证明，**没有严格的数据工程基础，再强大的算法也难以弥补数据的缺陷**。在这如同淬高强度般严丝合缝的重建阵列护持之后，我们才再次批准重启大模型训练。仅仅三个轻量的训练周期（Epoch）过去，这个大基座模型的长复杂图表阅读推理得分（ChartQA (Masry et al. 2022)、TabMWP (Lu et al. 2022)）就如同毫无阻力一般原地飙升了超过 45 个绝对百分点，其展现出的恐怖数值洞察力瞬间彻底击穿了所有传统金融投行陈旧分析系统的基准安全红线。
+复盘结果说明，**没有严格的数据工程基础，再强大的算法也难以弥补数据缺陷**。在重建 OCR 与版面结构之后，团队重新启动轻量训练周期。以 ChartQA (Masry et al. 2022)、TabMWP (Lu et al. 2022) 等评测为例，长复杂图表阅读推理得分提升约 45 个绝对百分点（示例口径）。这一提升幅度取决于初始基线、样本难度、模型规模和评测集配置，不能直接跨项目复用。
 
-### 9.5.2 本章工程之眼，开启高维长时序视频大航海纪元
+### 9.5.2 从静态文档走向长时序数据
 
-从这份 1100 页大纲指南的第一篇开始，我们跟随着数据工程师的脚步，历经了从单模态纯文字清洗与过滤压缩（第一/二篇幅的 NLP 打怪升级）、再踏入平面多模态图文世界的草莽混沌年代（第八章的分辨率切割抗争），直到此刻——我们终于能够稳稳握住极致精密的像素解剖手术刀切开庞杂文档矩阵并完美结构化重构这个复杂的 2D 世界（本章的高阶双流向重标注与文档结构化网络构建工程）。可以说是打下了一座坚不可摧的地基：目前，在那些静态的、寂静无声的二维数字物理世界里的所有脏坑乱洼、毒数据与排版死角污染，无论图像再巨大、底噪杂音再多、工程图纸再难拆，在这套系统性打造的自动化分流筛选的铁网漏洞下，它们都会被提纯为金光璀璨的、高浓度高阶监督指令信号。
+从第一、二篇的文本清洗与过滤，到第8章的图文对齐，再到本章的重标注与文档结构化，静态二维数据工程已经形成了较完整的处理链路。通过 OCR、版面解析、BBox 标注和长文本重组，文档图像可以被转化为可训练、可追溯、可评估的高密度监督信号。
 
-**但是，物理真实世界从来都不可能仅仅是一幅定格静止的相片或一张不会变动的电子发票**！
-我们的现实世界，它是有着**前后连续逻辑的强烈纵深、有着无尽流淌的时间维度交织，以及混合着多波段空间音频信道（Audio Channels）紧密裹挟**而成的浩瀚多维时空长河。
-试想一下，在此前静态图片预训练中被我们推崇至极、大放光彩的 AnyRes 取回策略虽然强大，但它面对一秒钟就产生足足 60 幅连贯高分辨率重叠照片、并且随随便便就能持续长达几个小时播放时长的**数字时序视频怪兽**时，哪怕把你把世界上十座最宏大的万卡 GPU 高速互联网络全部凑在一起，也会在短短几秒内瞬间过载发热，便陷入极度算力崩溃、显存溢出（Out-of-Memory）报错的绝境深海。
+但现实世界并不只是一幅静态图片或一页电子发票。许多关键场景包含连续时间逻辑、运动轨迹和多波段音频信号。AnyRes 等静态图片策略虽然可以处理高分辨率图像，但面对每秒 30-60 帧、持续数分钟甚至数小时的视频时，视觉 Token、解码 I/O、音频转写和时间对齐成本会迅速增长，并可能触发显存溢出（Out-of-Memory）和数据加载瓶颈。
 
-这就残酷地引出并在整份多模态 AI 数据工程全景图的最边缘，竖立起了最后一座极其诡异、当前在整个全球学术与工业界依然尸骨累累的、尚未被大规模有效攻克的黑暗堡垒冰峰。下一节，我们将重新审视一切已知的特征工程兵器，全神贯注且极其紧绷神经，全副武装且带上最新的长序列动态压缩算子系统，正式步入跨度极度宽广、特征体量呈指数级庞大爆炸，且图文声音逻辑信道交缠得极度微弱的四维时空大雷区：“**第 10 章 视频与音频流多模态数据工程基建**”。跟随我们的视角，推开下一扇沉重的数据之门，一起来解开那条让 Sora 乃至一切世界模拟器（World Simulators）诞生出物理规律理解法则的终极数据风暴锁链吧。
+因此，下一章将从静态图文与文档理解转向长时序数据，讨论视频与音频流的切片、转写、降噪和时间对齐问题：**第10章 视频与音频数据工程**。
 
 ## 参考文献
 
@@ -263,4 +278,3 @@ Masry A, Long D, Tan J Q, Joty S, Hoque E (2022) ChartQA: A Benchmark for Questi
 Radford A, Kim J W, Hallacy C, Ramesh A, Goh G, Agarwal S, Sastry G, Askell A, Mishkin P, Clark J, others (2021) Learning Transferable Visual Models From Natural Language Supervision (CLIP). In: ICML 2021, pp 8748-8763.
 
 Schuhmann C, Beaumont R, Vencu R, Gordon C, Wightman R, Cherti M, Coombes T, Katta A, Mullis C, Wortsman M, others (2022) LAION-5B: An Open Large-Scale Dataset for Training Next Generation Image-Text Models. Advances in Neural Information Processing Systems 35:25278-25294.
-
diff --git a/docs/zh/part3/ch10_video_audio.md b/docs/zh/part3/ch10_video_audio.md
index 17537053..9cf3d96e 100644
--- a/docs/zh/part3/ch10_video_audio.md
+++ b/docs/zh/part3/ch10_video_audio.md
@@ -1,102 +1,118 @@
 # 第10章 视频与音频数据工程
 
-在经历了从自然语言文本（第一、二篇）到静态图文解析（第八、九篇）的漫长征途后，我们终于来到了构筑新一代全能大模型能力底座的最前沿深水区——**长序列时序数据工程（Temporal Video & Audio Data Engineering）**。
+## 摘要
 
-在过往基于图文对或截帧的训练中，模型就像个盲人摸象的鉴赏家：它能认识世界上的每一种苹果，但它永远无法理解一颗苹果“从桌子上掉落下来、骨碌碌滚进床底并发出清脆撞击声”所蕴含的引力常数、视听觉同步反馈与时间因果律。只有彻底吞噬时间流，模型才能进化为 Sora (Brooks et al. 2024)、Gemini 1.5 Pro (Team et al. 2024) 这样能够理解整个世界运行物理法则和声学常识的“**世界模拟器（World Simulators）**”。
+本章讨论视频与音频数据工程的核心问题，重点说明长时序多模态数据为什么在可用样本比例、解码成本、时序对齐和质量评估上显著难于静态图文。章节首先分析视频数据“看起来多、可用样本少”的原因，包括维度增长、静止冗余、底噪、音画分离和解码 I/O 瓶颈。随后建立视觉、声学和文本三轨并行流水线：镜头边界检测、关键帧抽取、ASR 转写、降噪、说话人分离、字幕纠错和时间戳对齐。后半章讨论事件标签、音画错配检测、成本模型、NVDEC/DALI 等硬件解码策略，并通过匿名化复合案例说明时序偏移如何破坏音视频学习信号。读者应能够设计可切片、可转写、可对齐、可审计的视频音频预处理管线。
 
-但这也意味着，数据工程的灾难，终于从二维平面彻底爆发向了四维超空间。
+## 关键词
+
+视频数据；音频数据；ASR；WhisperX；镜头边界检测；时序对齐；NVDEC；多模态质量评估
+
+## 学习目标
+
+- 能够解释视频与音频数据在维度、冗余、噪声和解码成本上的特殊挑战。
+- 能够设计镜头切分、关键帧抽取、ASR、降噪和说话人分离的三轨流水线。
+- 能够说明时间戳、音画同步和跨模态语义一致性对训练样本质量的影响。
+- 能够建立视频音频质量评估、严重等级和隔离策略。
+- 能够估算解码、抽帧、ASR 和封装阶段的主要成本来源。
+
+在经历了从自然语言文本（第一、二篇）到静态图文解析（第8、9章）的处理链路后，本章进入**长序列时序数据工程（Temporal Video & Audio Data Engineering）**。
+
+在基于图文对或截帧的训练中，模型可以学习到物体类别、场景和静态关系，但很难理解一颗苹果“从桌子上掉落、滚入床底并发出撞击声”所包含的运动轨迹、声画同步和时间因果。要训练 Sora (Brooks et al. 2024)、Gemini 1.5 Pro (Team et al. 2024) 这类能够处理长时序输入的模型，必须构建能够表达时间、动作和声音关联的数据样本。
+
+这也意味着，数据工程问题从二维图文扩展到时间维和音频维，成本、质量和对齐难度都会显著上升。
 
 ## 10.1 音视频数据为什么最容易“看起来多、可用样本少”
 
-许多刚接手多模态项目的架构师很容易陷入一种“富有”的错觉：互联网上每天新增成百上千万小时的 YouTube 和 TikTok 视频，这不就是取之不尽、用之不竭的数据金矿吗？然而当真正启动预训练预处理管线时，他们往往会发现，在硬盘里塞满的 1000 TB 原始视频中，真正能拿去喂给训练框架的可用样本，甚至压不榨出 10 TB。
+许多刚接手多模态项目的架构师容易产生一种错觉：互联网上每天新增大量 YouTube 和 TikTok 视频，似乎天然构成可训练数据池。然而当真正启动预训练预处理管线时，团队往往会发现，硬盘里 1000 TB 原始视频中，真正能进入训练框架的高质量样本可能不足 10 TB。该比例为示例性口径，实际取决于来源许可、内容类型、质量阈值和抽检标准。
 
-这种“抱着金饭碗要饭”的巨大反差，究其根源有以下三个致命陷阱：
+这种反差的根源主要有以下三类：
 
 ### 10.1.1 维度灾难：从二维空间到四维时空序列
 
-当我们处理纯图片（Image）时，即便分辨率再高（如 4K AnyRes），它的表达也仅限于 $(W \times H \times C)$ 的二维张量。而对于视频，张量瞬间暴涨了一个决定生死的维度：$(T \times W \times H \times C)$。
-这里的 $T$ 代表着时间帧数（Timesteps）。哪怕只有短短 1 分钟、帧率为 30 FPS 的短视频，瞬间就会产生 1,800 张连续的超清图像。从前我们引以为傲的 `Clip Score` 计算、视觉 Token 压缩算子，在这个指数级爆炸的时序张量面前，根本撑不过毫秒级别的 GPU Out-of-Memory（OOM）报错。这使得我们不得不设计严格并且几乎会丢掉 90% 以上信息的**视频抽帧（Key-frame Sampling）**体系。
+当处理纯图片（Image）时，即便分辨率很高（如 4K AnyRes），它的表达也主要是 $(W \times H \times C)$ 的二维张量。而对于视频，张量增加了时间维：$(T \times W \times H \times C)$。
+这里的 $T$ 代表时间帧数（Timesteps）。一段 1 分钟、30 FPS 的短视频会产生 1,800 张连续图像。若直接对所有帧计算 CLIP Score 或视觉 Token 压缩，显存和计算量会迅速超出预算。因此，视频数据工程必须设计严格的**视频抽帧（Key-frame Sampling）**体系，通常会保留少数关键帧并丢弃大量冗余帧。
 
-### 10.1.2 虚假的丰富：无用过采样与高模态噪声
+### 10.1.2 表面丰富：无用过采样与高模态噪声
 
 硬盘里确实有 1000 TB，但这里面 80% 可能是：
-1. **完全无信息量的静止冗余**：一个长达两小时的在线网课视频，画面可能有一整个小时仅仅是静态不变的 PPT 背景与右下角一张毫无动作起伏的人脸。如果你放任框架将这几千张高度同质化的画面编码进去，大模型的梯度将会被严重带偏。这种数据对模型认知的提升不仅是零，更是负资产。
-2. **底噪轰炸与音画分离**：大量的生活 VLOG 里混杂着刺耳的狂风噪声音轨、背景轰鸣声，甚至经常出现画面里的人在打高尔夫、背景音乐却在播放欢快流行歌的“音画毫不相干（Audio-Visual Misalignment）”情况。对于需要学习绝对物理因果律（例如看到玻璃碎裂的画面，立刻就要听到玻璃碎裂的声音）的大模型来说，绝大多数野生音视频带来的全都是认知毒药。
+1. **静止冗余**：一个长达两小时的在线网课视频，画面可能有一整个小时仅仅是静态不变的 PPT 背景与右下角的人脸。如果框架将这几千张高度同质化的画面全部编码进去，训练信号会被低信息帧稀释。这类数据对模型认知提升有限，甚至可能降低有效样本比例。
+2. **底噪与音画分离**：大量生活 VLOG 里混杂风噪、背景轰鸣，甚至经常出现画面里的人在打高尔夫、背景音乐却播放流行歌的“音画不相关（Audio-Visual Misalignment）”情况。对于需要学习物理因果（例如看到玻璃碎裂画面，应匹配玻璃碎裂声）的模型来说，这类野生音视频会提供错误监督信号。
 
-### 10.1.3 被极度低估的解码算力与存储陷阱（IO瓶颈诊断回顾）
+### 10.1.3 容易低估的解码算力与存储瓶颈（I/O 瓶颈诊断回顾）
 
-正如我们在 **Ch06（高效加载篇 §6.4）**中所复盘过的那样，存储文本只需要读取纯文本 Byte；而存储并在训练期间动态加载长视频，是对底层文件系统的极大压力。
-视频数据天生是在压缩域内（如 H.264/H.265/VP9 编码格式）打包存储的。要想提取出模型真正能消化的连续原始像素帧序列以及音频采样率，就必须在加载的第一步将其硬解码（Decoding）。如果 100 张 H100 显卡正饿着肚子等待送入批次数据，此时在前端的 CPU Data Loader 和集群 I/O 带宽早就因为同时解压几百兆的 MP4 流而全线崩溃死锁了。
+正如第6章 6.4节所讨论的那样，存储文本只需要读取纯文本 Byte；而存储并在训练期间动态加载长视频，会对底层文件系统带来更大压力。
+视频数据通常以压缩域格式（如 H.264/H.265/VP9）存储。要提取模型可处理的像素帧序列和音频采样，就必须在加载第一步执行解码（Decoding）。当 100 张 H100 GPU 同时等待批次数据时，前端 CPU DataLoader 和集群 I/O 带宽可能因为并发解压 MP4 流而成为瓶颈。该硬件规模仅为示例，实际应按集群配置复测。
 
 ---
 
 ## 10.2 切片、转写与时序对齐的“三轨并行流水线”
 
-为了驯服这头四维的巨兽，数据清洗工厂绝不能再使用早期图文对时代的“一图配一句（Image-Text Pair）”古典作坊模式。我们需要搭建一套能精确地剥离并处理视觉、声学和文本等多条独立轨道的“**音视频样本构建全流程自动化平台**”。
+面对长时序数据，数据清洗工厂不能沿用早期图文对时代的“一图配一句（Image-Text Pair）”模式。我们需要搭建一套能够剥离并处理视觉、声学和文本等多条独立轨道的**音视频样本构建全流程自动化平台**。
 
 ![图10-1：音视频对齐分布式管线图](../../images/part3/av_sample_pipeline.png)
 
-*图 10-1：音视频对齐分布式管线图（Audio-Video Pipeline: Temporal Alignment） —— 左侧原始 Video Lake 中的混合视频被彻底剥离拆分为视觉（Visual Track）、声学（Acoustic Track）双轨并行管线，视觉帧提取器与声学分离器各自独立抢救特征后，最终汇集入关键的“跨模态时间对齐引擎（Temporal Alignment Engine）”，强制生成为时间戳严丝合缝闭合的巨幅大模型多模态输入样本（Aligned Multimodal JSONL）。*
+*图10-1：音视频对齐分布式管线图（Audio-Video Pipeline: Temporal Alignment） —— 左侧原始 Video Lake 中的混合视频被剥离为视觉（Visual Track）和声学（Acoustic Track）双轨并行管线，视觉帧提取器与声学分离器各自提取特征后，最终汇集入跨模态时间对齐引擎（Temporal Alignment Engine），生成带时间戳闭合约束的多模态输入样本（Aligned Multimodal JSONL）。来源：本书自绘；Alt text：音视频对齐分布式管线图，展示原始视频被拆分为视觉轨、音频轨和文本轨，并通过时间对齐引擎生成 JSONL 样本。*
 
-### 10.2.1 视觉提取：智能镜头解剖与场景动态切片（Scene Segmentation）
+### 10.2.1 视觉提取：镜头边界检测与场景动态切片（Scene Segmentation）
 
-在进入训练之前，超长视频（例如 2 小时的电影）必须被斩断成 10 秒到 30 秒不等、在逻辑与镜头上完全连贯的小切块（Clips）。绝对不能使用简单粗暴的“固定时长一刀切（按每10秒切一刀）”，因为那必定会导致一个精彩动作或者一句话在中间被拦腰截断，造成高昂的语义残缺。
+在进入训练之前，超长视频（例如 2 小时的电影）必须被切分成 10 秒到 30 秒不等、在逻辑与镜头上连续的小片段（Clips）。不宜使用简单的固定时长切分（如每 10 秒切一段），因为这可能导致动作或一句话在中间被截断，造成语义残缺。
 
-1. **关键的镜头切换点侦测（Shot Boundary Detection）**
-   我们需要在视觉流水线（Top Path）中加入一道快速的侦测关卡卡点，如采用**双阈值颜色直方图比对**（硬切变 Hard Cut 采用高阈值、软渐变 Fade/Dissolve 采用低阈值）或轻量级的两帧之间光流差异（Optical Flow Difference）计算，以捕获视频中由于机位推拉、镜头剪辑引起的硬切变与软渐变。只有在同一镜头内保持的连续帧，才能作为一个完整的知识概念（Event Grounding）被喂给预训练视觉大模型。
+1. **关键的镜头切换点检测（Shot Boundary Detection）**
+   我们需要在视觉流水线（Top Path）中加入快速检测节点，如采用**双阈值颜色直方图比对**（硬切变 Hard Cut 采用高阈值、软渐变 Fade/Dissolve 采用低阈值）或轻量级的两帧之间光流差异（Optical Flow Difference）计算，以捕获视频中由于机位推拉、镜头剪辑引起的硬切变与软渐变。只有在同一镜头内保持的连续帧，才适合作为一个完整的知识概念（Event Grounding）进入预训练视觉模型。
 
 ![图10-2：自适应镜头边界检测与语义防泄漏架构图](../../images/part3/av_shot_boundary_hsv.png)
 
-*图10-2：自适应镜头边界检测与语义防泄漏架构图（Adaptive Shot Boundary Detection & Semantic Leakage Prevention） —— 展现了严密的双轨特征侦测逻辑。左侧输入的连续密集帧列被送入中枢并行矩阵：上层提取廉价但高效的 HSV 多通道色彩空间聚合差分，下层则抓取光流像素位移（Optical Flow）以捕捉细微运动姿态。两种张量差分在最右侧汇入严苛的“双重阈值路由（Dual-Threshold Triage）”。一旦突变分值 $\Delta$ 击穿红色高压警戒线（Hard Cut Threshold），引擎立即一刀切断分段，将不相关的过场动画与场景转换拒之门外，在源头以最低算力锁死了视觉切片的语义泄漏空间。*
+*图10-2：自适应镜头边界检测与语义防泄漏架构图（Adaptive Shot Boundary Detection & Semantic Leakage Prevention） —— 展示双轨特征侦测逻辑：上层提取 HSV 多通道色彩空间聚合差分，下层提取光流像素位移（Optical Flow）以捕捉细微运动姿态。两种张量差分在右侧汇入“双重阈值路由（Dual-Threshold Triage）”。当突变分值 $\Delta$ 超过硬切阈值（Hard Cut Threshold）时，引擎切分片段，避免场景转换导致视觉切片语义泄漏。来源：本书自绘；Alt text：自适应镜头边界检测图，展示 HSV 差分、光流差分和双阈值路由如何共同判断镜头切分点。*
 
 2. **自适应的抽帧过滤法（Adaptive Sub-sampling）**
-   切片完成后，长达 20 秒内的镜头虽然逻辑连贯，但在动作幅度上可能波澜不惊。工厂会部署小模型去持续验证当前帧与上一保留帧在稠密视觉特征（如 DINOv2 (Oquab et al. 2023) Embedding）上的位移距离。只要超过一个预设的欧氏距离阈值（即当前画面的信息量确实有了新展开），才予以打标保留。最终一段原本含 600 帧画面的 20 秒切片，可能会被精准浓缩成 10 张核心关键帧集合，使得大模型的视觉输入侧负载雪崩式下滑了整整 98%。
+   切片完成后，长达 20 秒的镜头虽然逻辑连贯，但在动作幅度上可能变化很小。工厂会部署小模型，持续验证当前帧与上一保留帧在稠密视觉特征（如 DINOv2 (Oquab et al. 2023) Embedding）上的位移距离。只有超过预设欧氏距离阈值时，才予以保留。最终，一段原本含 600 帧画面的 20 秒切片，可能会压缩成 10 张关键帧，使视觉输入侧负载降低约 98%。该比例为示例口径，实际取决于帧率、动作密度和阈值设置。
 
 ### 10.2.2 听觉剥离：多层转写、降噪与声纹剥离切割（ASR & Diarization）
 
-与视觉抽帧双线并行的底层通道（Bottom Path）里，是负责充分利用声音语义的金矿冶炼器。
+与视觉抽帧并行的底层通道（Bottom Path）负责提取声音语义。
 首先进行的是**多路音轨抽离（Audio Stripping）**，然后进入如下的三层滤网：
 
 #### A. 核心语义层提取：超大并发的 WhisperX 自动语音识别（ASR）
-对于蕴含无穷人类思考逻辑的语音轨，我们必须高压调用诸如万卡部署开源 Whisper (Radford et al. 2023) 或更激进的 WhisperX (Bain et al. 2023) 框架网络。将其将音频中夹杂着各种口音的杂乱声音翻译成高度准确的结构化文字序列。
+对于语音轨，常见做法是调用开源 Whisper (Radford et al. 2023) 或 WhisperX (Bain et al. 2023) 等框架，将夹杂口音、噪声和停顿的音频转写为带时间戳的结构化文字序列。
 
 ![图10-3：大规模 ASR 提取与时间轴动态校准对比图](../../images/part3/asr_whisperx_comparison.png)
 
-*图 10-3：大规模 ASR 提取与时间轴动态校准对比图（Large-Scale ASR Extraction & Temporal Calibration） —— 直观地揭示了声学转写的误差累积与拯救机制。图中最上方为传统的古典 ASR 管道，随着长序列的推进产生了严重的累积性时间漂移（Cumulative Temporal Drift）与致命的语义坍缩（将 `I love apples.` 误听写为 `maples.`）。图中间展示了 WhisperX 架构的强势介入：通过 VAD 切分、多路声学解码与 DTW（音素级强制对齐）矩阵，彻底重构了底层特征提取逻辑。而最下方的输出结果中，最终词汇 Token 与音频波谷被垂直虚线（Vertical Dashed Lines）完美死锁对齐，实现了真正的“零时间漂移”，为多模态融合保住了珍贵的语义连续性。*
+*图10-3：大规模 ASR 提取与时间轴动态校准对比图（Large-Scale ASR Extraction & Temporal Calibration） —— 展示传统 ASR 管道在长序列中可能产生累积性时间漂移（Cumulative Temporal Drift）和语义错误（将 `I love apples.` 误听写为 `maples.`）；中间展示 WhisperX 通过 VAD 切分、多路声学解码与 DTW（音素级强制对齐）矩阵进行时间校准；底部展示词汇 Token 与音频波谷通过垂直虚线对齐后的输出。来源：本书自绘；Alt text：ASR 提取与时间轴校准对比图，展示传统 ASR 漂移、WhisperX 校准和词级时间戳对齐结果。*
 
-#### B. 无尽底噪剥离与纯净化（Denoiser Layer）
-并非所有的视频都拥有演播室级别的隔音。大量野外采集数据混杂极强的风噪或机械共鸣。这就必须动用重型的 Demucs (Défossez et al. 2019) 或基于深度学习的音频分离算法（Source Separation），如同手术刀一般从混响光谱中强制把底层音乐（BGM）、非人类环境声（Environment Noise）和纯净的人声（Vocal）切分开来。
+#### B. 底噪分离与语音增强（Denoiser Layer）
+并非所有视频都拥有演播室级别的隔音。大量野外采集数据混杂强风噪或机械共鸣。这就需要使用 Demucs (Défossez et al. 2019) 或基于深度学习的音频分离算法（Source Separation），从混响光谱中分离背景音乐（BGM）、环境声（Environment Noise）和人声（Vocal）。
 
 #### C. “到底是谁在说话？”：说话人日志切分（Speaker Diarization）
-针对高端对话型播客（Podcast）或者多人围坐的会议视频预训练语料如果一股脑全部压成单轨字符串，模型在训练时根本无法分辨谁在提问谁在解答，只能学到精神分裂的对话。Diarization 算法犹如给声波安上了人脸识别系统，能把一条长音频截断并标注为 `[Speaker A]: 01:23-01:30` 和 `[Speaker B]: 01:31-01:40` 这种完美区分了人类物理身份与阵营的回放序列。
+针对对话型播客（Podcast）或多人会议视频，如果将所有语音压成单轨字符串，模型在训练时无法分辨谁在提问、谁在回答。Diarization 算法可以把一条长音频切分并标注为 `[Speaker A]: 01:23-01:30` 和 `[Speaker B]: 01:31-01:40` 这样的说话人片段。
 
 #### D. 大语言模型驱动的字幕纠错（Subtitle Error Correction）
-单纯的 ASR 转写往往存在领域专业词汇（如代码、医疗术语）的硬错误。在工业级管线中，通常会在 WhisperX 输出后加入一道 LLM 纠错（Error Correction）工序。通过向强 LLM 输入带有时间戳的 ASR 原始文本，并注入“请根据上下文逻辑修复错别字、标点符号，且绝对不能改变原有时间戳”的 Prompt，能够将最终语料的词错率（WER）从 15% 压低到 2% 以内。
+单纯的 ASR 转写往往存在领域专业词汇（如代码、医疗术语）错误。在工业级管线中，通常会在 WhisperX 输出后加入一道 LLM 纠错（Error Correction）工序。通过向强 LLM 输入带有时间戳的 ASR 原始文本，并注入“请根据上下文逻辑修复错别字、标点符号，且绝对不能改变原有时间戳”的 Prompt，可以降低最终语料的词错率（WER）。从 15% 降至 2% 以内是示例性目标，实际取决于语言、噪声、领域词表和 ASR 模型版本。
 
-### 10.2.3 多轨时序强对齐工程：字幕、语音、画面的时间维“极度硬对齐”机制
+### 10.2.3 多轨时序对齐工程：字幕、语音与画面的时间维绑定
 
-当把抽好的视觉关键帧阵列、写好的长串 ASR 字幕、和剥离完的纯净声音波形流收集完毕之后。最残酷的攻坚挑战，也就是真正决定这家 AI 大厂底层数据实力的**最具挑战性的对齐工程**来了——**异构多模态的几何死锁（Cross-Modal Geometric & Temporal Lock）**。
+当视觉关键帧阵列、ASR 字幕和声音波形流收集完毕后，真正困难的是将这些信号在同一时间轴上绑定，即**跨模态几何与时间对齐（Cross-Modal Geometric & Temporal Lock）**。
 
-一条字幕在 ASR 里写着大大的 “Hello World!”，但在 10 秒钟时序的波段里，究竟是哪几毫秒、哪个帧的哪个嘴型匹配这句声音？如果不强制建立这种时间纽带羁绊（Temporal Anchors），大模型在吸收的时候不仅学不会声画同步，甚至连口型匹配预测都做不出来。
+一条字幕在 ASR 中写着 “Hello World!”，但在 10 秒钟时序片段里，究竟是哪几毫秒、哪个帧、哪个嘴型匹配这句声音，需要通过时间锚点（Temporal Anchors）明确。如果不建立这种绑定，大模型难以学习声画同步和口型匹配预测。
 
 ![图10-4：跨模态时序强校准与几何锁死对齐架构图](../../images/part3/av_alignment_diagram.png)
 
-*图 10-4：跨模态时序强校准与几何锁死对齐架构图（Cross-Modal Geometric & Temporal Alignment Lock） —— 图中系统化地剖析了三层异构数据的物理拼装赛道：顶端青色轨道的视觉关键帧胶片列阵（Visual Modality）、中段灰色轨道的极高频声波列阵（Acoustic Modality）以及底端珊瑚色轨道的离散转述词块序列（Discrete Textual Tokens）。最为核心的设计在于中央那条贯穿三界的琥珀色闪烁轴线 —— `The Temporal Lock (绝对几何时间锁)`。当时间轴推移至 `t=4.2s` 时，这条轴线以物理强制力将“端起水杯的视觉动作”、“波谷处的特定声波特征”与 `<start:4.2s> "Water cup"` 的纯文本标签钉死在了一起（锚点处的小锁头标志）。最终，这三大被物理捆绑的孤岛矩阵在右侧被高度压缩坍缩，封印成为了一段极其珍贵的大模型时序预训练代码流（Unified Mixed Token Pipeline / JSONL格式），完成了从离散流媒体到世界物理认知课本的升华。*
+*图10-4：跨模态时序校准与几何对齐架构图（Cross-Modal Geometric & Temporal Alignment Lock） —— 顶端青色轨道表示视觉关键帧（Visual Modality），中段灰色轨道表示声学特征（Acoustic Modality），底端珊瑚色轨道表示离散文本 Token（Discrete Textual Tokens）。中央时间轴 `The Temporal Lock` 在 `t=4.2s` 处将“端起水杯的视觉动作”、“波谷处的声学特征”与 `<start:4.2s> "Water cup"` 文本标签绑定，最终生成统一的 Mixed Token Pipeline / JSONL 样本。来源：本书自绘；Alt text：跨模态时序校准图，展示视觉帧、音频波形和文本 Token 如何通过同一时间轴锚点绑定。*
 
-大厂通常会基于时间戳矩阵强制部署 **Multi-modal Temporal Alignment Engine（多模时序融合校验门）**。一旦前端识别器给出了一条类似 `<start:2.1s><end:4.5s>` 的坐标界限，代码就必须通过复杂的浮点数判定逻辑，去反切视频的对应帧。而在最后，这些对齐信息并不会单纯以视频形式打包丢给大模型，而是被转换为含有长串元数据集（Meta-data tags）、类似 HTML 的“**多轨混拼长序列（Mixed Token Pipeline）**”，以高度结构化（JSONL）的方式封印，交给了底层的训练 Dataloader 中展开。
+大型团队通常会基于时间戳矩阵部署 **Multi-modal Temporal Alignment Engine（多模时序融合校验门）**。一旦前端识别器给出类似 `<start:2.1s><end:4.5s>` 的坐标界限，代码需要通过浮点数判定逻辑，反切视频对应帧。最终，对齐信息不会只以视频形式交给大模型，而是被转换为包含元数据标签（Metadata Tags）、类似 HTML 的**多轨混拼长序列（Mixed Token Pipeline）**，以结构化 JSONL 方式交给训练 DataLoader。
 
 
 ---
 
-## 10.3 多模态信息深度强化池与评价漏斗过滤拦截
+## 10.3 事件标注与评价漏斗
 
-虽然在 10.2 节中我们成功地把视音频分了家并在时间维度强行捆绑了起来，但这批基础框架（Raw Structured Samples）在真正走向预训练引擎的熔炉前，仍旧缺乏更高维度的“事件监督信号（Event Grounding Signals）”和“错配除草剂（Misalignment Killer）”介入。
+虽然在 10.2 节中我们已经将视音频分轨并在时间维度绑定起来，但这批基础样本（Raw Structured Samples）在真正进入预训练引擎前，仍然需要更高维度的事件监督信号（Event Grounding Signals）和错配检测机制。
 
 ### 10.3.1 多层级连续动态事件标签强化生成网络（Event Detection & Grounding）
 
-一段野生视频不能只有单纯的画面和念字文本。它缺乏一种高阶的“物理世界动作流描述”。在大厂管线内部，会并行召唤成批的高级大标注辅助模型（如专精于行为理解视频的 LLaVA-Video (Zhang et al. 2024)、Video-LLaMA (Damonlpsg et al. 2023) 等旁路模型集群）。对那些被对齐后的视频小切片发起海量的**异步标注洗礼（Asynchronous Captioning Bath）**。
+一段野生视频不能只有画面和 ASR 文本，还需要“物理世界动作流描述”。在大型管线内部，通常会并行调用行为理解视频模型（如 LLaVA-Video (Zhang et al. 2024)、Video-LLaMA (Damonlpsg et al. 2023) 等旁路模型集群），对已经对齐的视频小切片进行**异步标注（Asynchronous Captioning）**。
 
-它们不仅要给出视频的单剧全局一句话概括（例如“一个青年在滑板公园表演滑雪后空翻失败摔倒”），更要在底层产生细致到让令人发指的**动态事件标签（Dynamic Event Tags）与阶段性密集标注（Detailed Temporal Captions）**：
+这些模型不仅要给出视频片段的一句话概括（例如“一个青年在滑板公园尝试后空翻并摔倒”），还要生成**动态事件标签（Dynamic Event Tags）与阶段性密集标注（Detailed Temporal Captions）**：
 
 1. **粗粒度事件标签提取（Event Tagging）**：为片段打上诸如 `[Sports]`, `[Skateboarding]`, `[Accident]`, `[Impact_Sound]` 等结构化类别标签，方便数据混合配比（Data Mixing）。
 2. **细粒度时间轴密标（Dense Video Captioning）**：
@@ -104,91 +120,96 @@
    - `<time: 03.5s-05.1s>`: 男生试图在高空实现 360 度转体，但其背部失去平衡...
    - `<time: 05.1s-06.8s>`: 男生后背重重砸在混凝土滑道上，产生沉闷的低频冲击声响。
 
-正是这种融合了前因与后果、因果倒推的强化标签文本与分类 Tag 注入到了我们上一节制定的那个超长超级多轨对齐树（JSONL）中，这批视频死物在 AI 的神经元里才变得具有真正的“物理时空意义”。
+这类包含前因、过程与结果的强化标签文本和分类 Tag，会被注入上一节构建的多轨对齐 JSONL 中，使视频样本具备明确的时空语义。
 
-### 10.3.2 声音与画面错位的幻觉检测防御雷达
+### 10.3.2 声音与画面错位检测
 
-长时序中严重的对齐错误，是“画面与声音发生了严重的不关联错位”。比如，视频里是一头安静吃草的长颈鹿，而因为视频剪辑者直接在该段混入了一段电音 DJ 舞曲或者一长段毫无关联的游戏解说词片段。如果这类数据顺利流入基座训练，你的下场就是：大模型在被要求看到长颈鹿图片时，会莫名其妙地为你高歌一首 DJ 舞曲并伴随着严重的幻觉（Hallucinations）。
+长时序中最严重的对齐错误之一，是画面与声音发生不相关错位。例如，视频里是一头安静吃草的长颈鹿，但剪辑者在该段混入电音或无关游戏解说。如果这类数据进入基座训练，模型可能在看到长颈鹿时错误关联到无关音乐或解说，形成跨模态幻觉（Hallucinations）。
 
-为了彻底根治此类顽疾，工程内部必须引入不讲情面的强惩罚与高昂复检流程：
+为降低此类风险，工程内部必须引入严格的错配检测与复检流程：
 
-**表10-1：时序流超频数据缺陷类型与多层检测处置策略表**
+**表10-1：时序音视频数据缺陷类型与多层检测处置策略表**
 
 | 缺陷类型与表现 | 根本原因分析 | 检测与修复策略 | 严重程度 |
 | :--- | :--- | :--- | :--- |
-| **严重音画不相关（Audio-Visual Hallucination Mismatch）**：画面是一片寂静森林的远景，而人声音轨却正在用极快的语速直播解说 FPS 射击比赛实况。 | 数据贡献者强行拼凑的二创鬼畜视频，或是自动化压片时的硬轨串线泄漏（Audio Track Bleeding）。 | **使用预训练判别器跑特征余弦比对分数**：强行抽出当前中间帧的 CLIP 视觉高阶向量，与提取并编码的人声/音频 Audio 语义向量进行矩阵点乘夹角。如果跨模态向量相似度（Cosines Similarity）跌破预警红线，就地熔断摧毁这十秒的所有标注并废弃出场。 | 终极毁灭 P0 |
-| **画面闪烁/黑屏/极端马赛克雪崩（Frame Corruption & Dark Out）** | 原视频采集流编码比特率极低崩溃，或者传输网络发生极大程度丢包。 | 计算整段片段的**亮度直方图极差均值与锐度得分过滤（Laplacian Variance Filters）**。若画面全都是黑死像素点或是均方差模糊溢出，立即触发拦截，不仅要将视频送入黑垃圾池（Trash-pool），并且记录异常并退回抽帧模块反省排查 C++ 解码算子接口。 | 严重 P1 |
-| **极端背景环境噪音使得人声淹没不可逆转（Irreversible Noise Flooding）** | 现场麦克风破音故障被拉升放大，或者背景包含震耳欲聋且极难在特征池内剥离的高频电锯轰鸣噪音。 | 使用预判小模型针对全频带频谱（Spectrogram）运行**声学信噪比基准诊断评估（SNR Estimation）**，低于底线阈值的人声轨判定为毒药级。如果是对话相关项目则彻底舍弃此视频语料的注入。 | 取决用途 P2 |
+| **严重音画不相关（Audio-Visual Hallucination Mismatch）**：画面是一片寂静森林远景，而人声音轨正在解说 FPS 射击比赛。 | 二次剪辑视频错误拼接，或自动化压片时音轨串线泄漏（Audio Track Bleeding）。 | **使用预训练判别器计算特征余弦分数**：抽取中间帧的 CLIP 视觉向量，与人声/音频语义向量进行相似度计算。如果跨模态向量相似度低于预警阈值，隔离该片段并废弃该时间窗标注。 | P0：不可入库 |
+| **画面闪烁/黑屏/极端马赛克（Frame Corruption & Dark Out）** | 原视频编码比特率过低，或传输网络发生严重丢包。 | 计算整段片段的**亮度直方图极差均值与锐度得分过滤（Laplacian Variance Filters）**。若画面长期黑屏或模糊溢出，触发拦截，记录异常并回溯抽帧模块与解码算子。 | P1：需隔离复核 |
+| **背景环境噪音淹没人声（Irreversible Noise Flooding）** | 现场麦克风破音，或背景包含难以分离的高频机械噪声。 | 使用小模型针对全频带频谱（Spectrogram）运行**声学信噪比评估（SNR Estimation）**，低于底线阈值的人声轨应被降权或剔除；对话相关项目通常直接舍弃该片段。 | P2：取决用途 |
 
 ---
 
-## 10.4 成本深渊算账、极刑量化设计与吞吐巅峰极致提效
+## 10.4 成本模型、量化设计与吞吐优化
 
-任何在大语言模型文本序列（Text-only LLMs）上高谈阔论成本的人，在进入多模时序管线后，会看到一份吓到他们辞职谢罪的云服务 GPU 账单。
+相比纯文本处理，长时序多模态管线会显著提高云服务 GPU、对象存储、网络带宽和数据解码成本。
 
-在文本处理时代，一台廉价的 64 核 CPU 服务器在一天之内足以解析和洗掉将近上亿个长篇 Markdown 爬虫文件；然而在视频大清洗阵营里，哪怕仅仅是读取 1 万小时的高清 MP4 文件序列并把它们在内存中解码转化为最纯粹的张量阵列供特征抽取使用，就能瞬间把这台服务器彻底压死并在两个小时内因过热而物理死机。
+在文本处理场景中，一台 64 核 CPU 服务器在一天内可以解析大量 Markdown 文件；而在视频清洗场景中，读取 1 万小时高清 MP4 文件并将其解码为张量供特征抽取使用，会迅速消耗 CPU、内存、PCIe 和存储带宽。这里的规模为示例口径，实际吞吐取决于视频编码格式、分辨率、并发度和硬件配置。
 
-### 10.4.1 解码器算力（CPU/GPU）与 IO 带宽的极限量化
+### 10.4.1 解码器算力（CPU/GPU）与 I/O 带宽量化
 
-最大的深水炸弹就在于“到底用什么硬件去解压缩（Decoding）视频帧”。
-1. **纯 CPU 解析防线溃败**：在最初期的架构设计中，菜鸟工程师往往贪图便宜、调用高配 CPU（配合多线程和简单的 ffmpeg 或者 python 本地 cv2 框架）进行软件解码。殊不知，高并发下的内存指针轮转会彻底霸占住所有 PCIe（高速通道）与 RAM 的带宽；
-2. **硬件编解码网络引擎加速（Hardware Video Decoders, NVDEC）**：资深架构师一定会选择把消耗并发负载的解码任务卸载至专有硬件。通过调用 GPU 芯片里的视频解码纯硬硅晶模块（例如 NVDEC API），让极高的显存带宽以惊人的数据搬运吞吐量直接绕过内存调用。虽然需要购买昂贵的 GPU 实例，但在大规模清洗下，它是降本的核心手段。
+关键问题是“到底用什么硬件解码（Decoding）视频帧”。
+1. **纯 CPU 软件解码的局限**：在早期架构设计中，团队可能使用高配 CPU、多线程 ffmpeg 或 Python OpenCV 进行软件解码。高并发下，内存搬运和 PCIe/RAM 带宽会很快成为瓶颈。
+2. **硬件编解码引擎加速（Hardware Video Decoders, NVDEC）**：更适合大规模清洗的方案，是将解码任务卸载至专有硬件。通过调用 GPU 芯片里的视频解码模块（例如 NVDEC API），可以减少 CPU 解码压力并提升吞吐。虽然需要购买 GPU 实例，但在大规模清洗下通常是降本的核心手段。
 
 ### 10.4.2 音视频综合质量评估指标（A/V Quality Assessment）
 
 为了决定一条经过解压的视频是否值得送入下一层流水线，我们需要建立自动化质量评估指标集：
-- **画面美学与清晰度得分（Aesthetic & Sharpness Score）**：使用诸如 LAION-Aesthetic 模型对抽取关键帧打分，过滤掉糊成一团的马赛克画质。
-- **动态模糊与运动过载指数（Motion Blur & Optical Flow Overload）**：如果镜头抖动极其剧烈（如手持狂奔），其光流位移方差极大，将导致大模型视觉编码器晕眩，应被剔除。
+- **画面美学与清晰度得分（Aesthetic & Sharpness Score）**：使用诸如 LAION-Aesthetic 模型对抽取关键帧打分，过滤严重模糊或马赛克画质。
+- **动态模糊与运动过载指数（Motion Blur & Optical Flow Overload）**：如果镜头抖动剧烈，其光流位移方差很大，将降低视觉编码质量，应被剔除或降权。
 - **语音信噪比与声学失真度（SNR & Clipping Ratio）**：检测环境底噪掩盖人声的程度，剔除刺耳破音片段。
 
 ### 10.4.3 工业级处理成本模型分解表
 
-数据工程师需要对每一层处理的“美分/小时”有极度敏锐的直觉。
+数据工程师需要对每一层处理的单位成本保持清晰认识。
+
+**表10-2：长时序音视频处理成本模型与降本策略**
 
-**表10-2：长时序音视频千卡集群核心处理成本模型与降本策略**
+注：表10-2中的成本占比为截至 2026-06 的估算示例，实际取决于云厂商价格、GPU 型号、视频分辨率、采样帧率、ASR 模型、缓存命中率和对象存储计费方式。
 
-| 处理阶段 | 资源开销特征 | 云成本占比估计 | 极限提效与工程降本绝招 |
+| 处理阶段 | 资源开销特征 | 云成本占比估计 | 工程降本策略 |
 | :--- | :--- | :--- | :--- |
-| **1. 原始长流抓取与分块下载** | 千兆高防网卡带宽，海量对象节点大区块 I/O。 | 10% - 15% | 引入边缘缓存网关（Edge Caching），预加载碎片入 GPU 临近的高速 NVMe 盘，杜绝直连慢存储。 |
-| **2. 强制硬解码与智能抽帧** | NVDEC 硬解模块拉满，显存与核心 PCIe 极度受压。 | **45% - 50%（核心成本）** | 使用 DALI 或 DeepSpeed-UIO 替换 Python OpenCV；结合双阈值 HSV 过滤，避免无用帧解码。 |
-| **3. ASR与密集重描述（WhisperX/LLaVA）** | 极度吃显存，密集 GPU 推理矩阵计算。 | 25% - 30% | 使用 INT8 量化模型；实施极致的动态批处理（Dynamic Batching）规避 Pad 算力浪费。 |
-| **4. 序列合并封装写入** | 后端 NAS/S3 并发写入小文件 I/O 灾难。 | < 10% | 强制采用 WebDataset (TAR) 格式，聚合成 GB 级连续块状写入，降维减负 90% 以上。 |
+| **1. 原始长流抓取与分块下载** | 高带宽网络，海量对象存储大区块 I/O。 | 10% - 15% | 引入边缘缓存网关（Edge Caching），预加载碎片到 GPU 附近的高速 NVMe 盘，减少直连慢存储。 |
+| **2. 硬解码与智能抽帧** | NVDEC 硬解模块、显存与 PCIe 带宽压力较高。 | **45% - 50%（示例核心成本）** | 使用 DALI 或 DeepSpeed-UIO 替换 Python OpenCV；结合双阈值 HSV 过滤，避免无用帧解码。 |
+| **3. ASR 与密集重描述（WhisperX/LLaVA）** | 显存消耗高，GPU 推理计算密集。 | 25% - 30% | 使用 INT8 量化模型；实施动态批处理（Dynamic Batching）减少 Pad 算力浪费。 |
+| **4. 序列合并封装写入** | 后端 NAS/S3 并发写入小文件 I/O 压力。 | < 10% | 采用 WebDataset (TAR) 格式，聚合成 GB 级连续块写入，可降低小文件开销。 |
 
 ---
 
-## 10.5 工程案例复盘与章节小结
+## 10.5 匿名化复合案例与章节小结
 
-### 10.5.1 大规模视频数据管线失败案例复盘（P 项目系列）
+### 10.5.1 大规模视频数据管线失败案例复盘（匿名化复合案例）
 
-在某视频自研项目中，团队积累了超过六万小时的高清混合视频素材，历时三个月的数据集构建工作最终以失败告终。
+以下为匿名化复合案例，视频小时数、模型参数和比例用于说明风险口径。某视频自研项目中，团队积累了超过六万小时的高清混合视频素材，历时三个月的数据集构建工作最终未达到预期。
 
-失败根源在于：工程架构中省去了多重关键的时序校准步骤。音频特征分离模块的接口传参存在约 30ms 的读取偏置（Reading Offset Bug），在数百次切分与合并操作后，该偏置累积导致约 70% 的后半段切片中，演员声音轨道相对口型和动作出现系统性超前或滞后。
+根源在于：工程架构中省去了多重关键的时序校准步骤。音频特征分离模块的接口传参存在约 30ms 的读取偏置（Reading Offset Bug），在数百次切分与合并操作后，该偏置累积导致约 70% 的后半段切片中，演员声音轨道相对口型和动作出现系统性超前或滞后。该比例为示例性复盘口径。
 
-将这批存在时序错位的数据送入 800 亿参数模型训练后，经过两周训练，模型的音视频关联能力完全混乱——在基准测试中，只要看到长发人物挥手，就会输出完全错误的声学预测。
+将这批存在时序错位的数据送入 800 亿参数模型训练后，经过两周训练，模型的音视频关联能力明显下降：在基准测试中，只要看到长发人物挥手，就会输出错误的声学预测。
 
-这一案例再次印证了本书开篇（Ch01）的核心结论：**没有严格的数据预处理工程保障，算法层面的投入无法弥补底层数据的根本缺陷。**
+这一案例再次印证了第1章的核心结论：**没有严格的数据预处理工程保障，算法层面的投入无法弥补底层数据的根本缺陷。**
 
 ### 10.5.2 本章小结与衔接
 
-从第一、二篇的文本清洗，到第八、九篇的图文像素对齐，再到本章处理的长时序音视频数据，我们已系统地掌握了各类异构数据的预处理方法——包括视频帧抽取、ASR 转写、音画对齐、事件标注与质量过滤。
+从第一、二篇的文本清洗，到第8、9章的图文像素对齐，再到本章处理的长时序音视频数据，我们已系统地掌握了各类异构数据的预处理方法——包括视频帧抽取、ASR 转写、音画对齐、事件标注与质量过滤。
 
-然而，无论数据质量多高，模型在完成预训练后仍需要明确的指令引导和价值观对齐，才能从"能理解世界"进化为"能听从人类指令"。这正是下一篇将展开的核心命题——**《第四篇：指令对齐与人类偏好反馈数据系统》**，从 Ch11 跨模态对齐延伸至 Ch12 及后续章节。
+视频与音频管线解决了长时序样本的切片、转写和时间同步问题，但多模态训练还需要回答另一个问题：图像、文本、音频和视频这些信号如何在同一语义空间中形成稳定对应关系。下一章将进入**第11章 跨模态对齐与融合**，讨论对象级、片段级和文档级的对齐样本构建。
 
 
 
 
 
-## 10.6 附录：工业级音视频管线高频崩溃日志与排雷手册
+## 10.6 附录：音视频管线高频错误日志示例与排查手册
 
-> 以下精选 5 类在大规模音视频预处理管线中真实发生的、具有代表性的崩溃模式，覆盖 I/O、解码、ASR 对齐、Diarization 和存储写入五大核心链路。每类附根因分析与修复方案，后附全类型速查表。
+> 以下为大规模音视频预处理管线中常见的匿名化错误日志示例，覆盖 I/O、解码、ASR 对齐、Diarization 和存储写入五大核心链路。日志中的主机名、路径、批次号和指标均为示例性参数，不对应公开事故；每类附根因分析与修复方案，后附全类型速查表。
 
 ---
 
 ### 10.6.1 I/O 雪崩：S3 并发拉流超限导致 DataLoader 死锁 [TMP_ERR_CODE_1001]
 
-**[故障现象]**：千卡集群在启动时，数百个 DataLoader worker 同时向 S3 对象存储发起大块 MP4 拉流请求，瞬间打爆骨干网带宽，节点文件句柄耗尽，训练进程全线卡死。
+**[故障现象]**：大规模 GPU 集群启动时，数百个 DataLoader worker 同时向 S3 对象存储发起大块 MP4 拉流请求，导致骨干网带宽和节点文件句柄迅速耗尽，训练进程进入等待状态。
+
+代码清单10-1展示了 S3 并发拉流超限导致 DataLoader 死锁的错误日志示例。
+
+**代码清单10-1：S3 并发拉流超限错误日志示例**
 
-**[堆栈快照]**:
 ```bash
 [FATAL] node-001.gpu-cluster.internal:
 Connection reset by peer. Timeout extracting frame chunk from blob: /bucket-v/dataset/vid_slice_0001.mp4
@@ -205,9 +226,12 @@ AVSync_Module: Subtitle timestamp [1.21s] completely drifts out of matched acous
 
 ### 10.6.2 NVDEC OOM：GPU 硬件解码器显存溢出 [TMP_ERR_CODE_2001]
 
-**[故障现象]**：在使用 NVIDIA NVDEC 硬件解码器进行高分辨率（4K）视频并发解码时，显存瞬间爆满，整个解码进程崩溃并拖垮训练节点。
+**[故障现象]**：在使用 NVIDIA NVDEC 硬件解码器进行高分辨率（4K）视频并发解码时，显存快速耗尽，解码进程中断并影响训练节点。
+
+代码清单10-2展示了 NVDEC 并发解码显存溢出的错误日志示例。
+
+**代码清单10-2：NVDEC 并发解码显存溢出错误日志示例**
 
-**[堆栈快照]**:
 ```bash
 [FATAL] node-007.gpu-cluster.internal:
 NVDecCreateDecoder failed: CUDA_ERROR_OUT_OF_MEMORY (error 2)
@@ -226,11 +250,14 @@ Decoder context invalidated. All queued frames dropped (estimated loss: 2.3TB).
 
 **[故障现象]**：对超过 30 分钟的长视频进行 ASR 转写时，WhisperX 输出的字幕时间戳在后半段产生累积性漂移，最严重时达 8–12 秒，导致音视频对齐完全失效。
 
-**[堆栈快照]**:
+代码清单10-3展示了 WhisperX 长视频时间戳漂移的错误日志示例。
+
+**代码清单10-3：WhisperX 时间戳漂移错误日志示例**
+
 ```bash
 [WARN] whisperx_worker_3: Timestamp drift detected at segment 847.
 Expected anchor: [1823.4s], Model output: [1831.8s]. Delta: +8.4s.
-[ERROR] TemporalAligner: Cross-modal lock failed — audio anchor outside visual frame window.
+[ERROR] TemporalAligner: Cross-modal lock failed - audio anchor outside visual frame window.
 Alignment quality score: 0.23 (threshold: 0.75). Segment rejected and quarantined.
 ```
 
@@ -244,7 +271,10 @@ Alignment quality score: 0.23 (threshold: 0.75). Segment rejected and quarantine
 
 **[故障现象]**：长时间批量运行 pyannote-audio (Bredin et al. 2023) Diarization 任务时，进程内存占用随批次数线性增长，运行约 4 小时后触发系统 OOM Killer，所有已处理任务结果丢失。
 
-**[堆栈快照]**:
+代码清单10-4展示了说话人分离任务内存泄漏的错误日志示例。
+
+**代码清单10-4：Diarization 内存泄漏错误日志示例**
+
 ```bash
 [ERROR] diarization_worker_12: Killed by OOM Killer (signal 9).
 Process memory at kill time: 187.3 GB / 192 GB RAM.
@@ -263,7 +293,10 @@ Unprocessed queue depth at crash: 3,421 audio segments (est. 68h audio).
 
 **[故障现象]**：分布式清洗管线在最终封装阶段，多个 worker 进程并发向同一 `.tar` shard 文件写入，导致文件结构损坏，训练时 DataLoader 抛出解析错误。
 
-**[堆栈快照]**:
+代码清单10-5展示了 WebDataset shard 并发写入损坏的错误日志示例。
+
+**代码清单10-5：WebDataset shard 并发写入损坏错误日志示例**
+
 ```bash
 [ERROR] training_node_44: WebDataset TarReader failed on shard: /data/processed/shard_0023.tar
 tarfile.ReadError: invalid header magic bytes at offset 2147483392.
@@ -279,9 +312,11 @@ DataLoader worker 0: Pipe broken, resetting shard iterator. Skipping shard.
 
 ## 10.6.6 高频错误速查表
 
+**表10-3：音视频管线高频错误类型与修复策略**
+
 | 错误代号 | 错误类型 | 核心触发条件 | 一句话修复策略 |
 | :--- | :--- | :--- | :--- |
-| TMP_ERR_CODE_1XXX | S3/I/O 超时雪崩 | 千卡并发拉流无抖动退避 | 加 Jitter Sleep + 边缘缓存预热 |
+| TMP_ERR_CODE_1XXX | S3/I/O 超时 | 大规模并发拉流无抖动退避 | 加 Jitter Sleep + 边缘缓存预热 |
 | TMP_ERR_CODE_2XXX | NVDEC OOM | 4K 视频无限制并发解码 | 降采样至 1080p + 限并发路数 |
 | TMP_ERR_CODE_3XXX | ASR 时序漂移 | 长视频 VAD 错误跳过静音段 | 分段转写 + 滑窗校验时间戳锚点 |
 | TMP_ERR_CODE_4XXX | Diarization OOM | Pipeline 对象批次间未释放 | 子进程隔离 + 每批显式 gc.collect |
@@ -309,4 +344,3 @@ Radford A, Kim J W, Xu T, Brockman G, McLeavey C, Sutskever I (2023) Robust Spee
 Team G, Anil R, Borgeaud S, Alayrac J B, Yu J, Soricut R, Schalkwyk J, Dai A M, Hauth A, Millican K, others (2024) Gemini 1.5: Unlocking multimodal understanding across millions of tokens of context. arXiv preprint arXiv:2403.05530.
 
 Zhang Y, Li Z, Liu C, Chen K, Ma L, Sun Y, Dou Q, Ouyang W, Yang M H, others (2024) Video Instruction Tuning with Synthetic Data (LLaVA-Video). arXiv preprint arXiv:2410.02713.
-
diff --git a/docs/zh/part3/ch11_cross_modal_alignment.md b/docs/zh/part3/ch11_cross_modal_alignment.md
index 5a7d9917..1454dd41 100644
--- a/docs/zh/part3/ch11_cross_modal_alignment.md
+++ b/docs/zh/part3/ch11_cross_modal_alignment.md
@@ -1,45 +1,56 @@
 # 第11章 跨模态对齐与融合
 
-在完成第八、第九章（图文）和第十章（音视频）的单模态清洗后，我们已将图片水印清除、错误 OCR 纠正、长视频精确抄帧为关键帧切片，付出了大量工程代价。
+## 摘要
 
-然而，**把土豆洗干净、把牛肉切好，并不等于你做出了土豆烖金錢腹**。如果只是把各自清洗完毕的图片流、声音波形和文字 Token 堆叠进大模型的 Context Window 里，模型并不会学会“跨模态推理（Cross-modal Reasoning）”——各模态信号之间的对应关系缺失，会导致训练信号相互干扰，引发严重的幻觉（Hallucination）问题。
+本章是第三篇的收束章节，讨论图像、文本、音频和视频在完成单模态清洗之后，如何构建跨模态对齐与融合训练样本。章节首先说明独立清洗并不能自动带来跨模态推理能力，若缺少语义、空间或时间绑定，模型仍会学习到错误对应关系。随后，本章建立对象级、片段级和文档级三层对齐框架，分别覆盖 BBox-词汇锚固、音视频时间轴同步和长文档交错排序。工程实现部分介绍占位符设计、特征路径解耦、多模态样本配比和难负样本挖掘，并给出跨模态召回率、时序连续性、幻觉率和蕴含冲突等质量指标。最后，章节通过匿名化复合案例说明对象错位、片段错位和语义错配的风险，并自然过渡到第四篇的指令对齐与偏好数据系统。
 
-本章作为**《第三篇：多模态高质量数据工程》**的收官章节，聚焦于多模态数据工程的核心难题——如何制作**跨模态融合的训练监督样本（Cross-modal Fusion & Alignment Samples）**，让不同模态的编码向量在同一语义空间中实现有效对齐。
+## 关键词
 
-## 11.1 问题场景：多模态对齐的失败漩涡与物理意义
+跨模态对齐；多模态融合；BBox；Temporal Alignment；Hard Negatives；Placeholder；多模态幻觉；数据配比
 
-### 11.1.1 灾难开篇：当千万美元算力换来“幻视”与“幻听”
+## 学习目标
 
-在完成第八、第九章（图文）和第十章（音视频）的单模态清洗后，我们已将图片水印清除、错误 OCR 纠正、长视频精确抄帧为关键帧切片，付出了大量工程代价。
+- 能够解释为什么单独清洗图文、音视频并不能自动形成跨模态推理能力。
+- 能够区分对象级、片段级和文档级三类跨模态对齐样本。
+- 能够设计多模态 Placeholder、特征路径和 JSONL Schema 的融合训练格式。
+- 能够构造难负样本并控制跨模态遗忘与假负例污染风险。
+- 能够建立跨模态召回率、时序连续性、幻觉率和人工抽检的质量评估机制。
 
-然而，**把土豆洗干净、把牛肉切好，并不等于你做出了土豆炖牛肉**。如果只是把各自清洗完毕的图片流、声音波形和文字 Token 机械地堆叠进大模型的上下文窗口（Context Window）里，模型并不会学会“跨模态推理（Cross-modal Reasoning）”——各模态信号之间的对应关系缺失，会导致训练信号相互干扰，引发严重的**跨模态幻觉（Cross-modal Hallucination）**。
+在完成第8、第9章（图文）和第10章（音视频）的单模态清洗后，我们已经能够去除图片水印、修正 OCR 错误，并将长视频切分为关键帧、字幕和音轨片段。
 
-在某头部大厂的早期多模态大模型（MM-LLM）预训练中，曾发生过一次著名的“幻听”事故：模型在观看一段“厨房里正在煎牛排”的静音视频时，不仅生成了“锅里在滋滋作响”的文本描述，甚至通过 Audio 编码器强行输出了狗叫的音频信号。经过长达三周的排查，团队发现根本原因在于：底层数据管道在拼装“视频+文本+音频”时，仅仅做了时间轴的粗略对齐，而没有进行语义特征的绝对绑定，导致“厨房场景”被随机耦合到了环境背景库中的狗叫声。这直接导致了上千万美元的训练算力打水漂。
+然而，如果只是把各自清洗完毕的图片流、声音波形和文字 Token 机械地堆叠进大模型的上下文窗口（Context Window），模型并不会自动学会“跨模态推理（Cross-modal Reasoning）”。各模态信号之间的对应关系缺失，会导致训练信号相互干扰，引发跨模态幻觉（Cross-modal Hallucination）。
+
+本章作为**第三篇：多模态高质量数据工程**的收官章节，聚焦于多模态数据工程的核心难题：如何制作**跨模态融合训练监督样本（Cross-modal Fusion & Alignment Samples）**，让不同模态的编码向量在同一语义空间中实现有效对齐。
+
+## 11.1 问题场景：多模态对齐失败与物理意义
+
+### 11.1.1 当高成本训练换来“幻视”与“幻听”
+
+以下为匿名化复合案例，成本、周期和故障表现用于说明风险类型。截至 2026-06，实际训练成本取决于模型规模、GPU 单价、训练时长和数据权重。某多模态大模型（MM-LLM）早期预训练中，模型在观看一段“厨房里正在煎牛排”的静音视频时，生成了“锅里在滋滋作响”的文本描述，甚至通过 Audio 编码器输出了不相关的动物叫声音频。经过三周排查，团队发现根因在于：底层数据管道在拼装“视频+文本+音频”时，只做了粗略时间轴对齐，没有进行语义特征绑定，导致“厨房场景”被随机耦合到环境背景库中的不相关声音。
 
 ### 11.1.2 模态鸿沟与异构空间挑战
 
-“对齐（Alignment）”这个词在 AI 届有着宽泛的涵义。在下一卷（第四篇）中，它将代表人类核心价值观的 RLHF 对齐；但在本章的底层数据准备中，这里的“对齐”特指解决数学级灾难的**异构空间模态鸿沟（Heterogeneity Gap）**。
+“对齐（Alignment）”这个词在 AI 领域有宽泛含义。在第四篇中，它将更多指向人类偏好和价值观对齐；但在本章的底层数据准备中，“对齐”特指解决**异构空间模态鸿沟（Heterogeneity Gap）**。
 
 文本在 Embedding 空间里是一条高度抽象的高维向量，它代表“语义（Semantics）”；而一张图片的像素矩阵如果被 Vision Encoder 编码出来，它代表的往往是“边缘、颜色、纹理集合（Patch Features）”；一段波形文件则映射着高频低频的振幅空间。
 
-这三大类向量不仅维度尺寸完全不一样，而且它们所映射的数学流形（Manifold）在原始状态下是彻底正交、老死不相往来的。所谓“跨模态对齐工程”，就是指构建出一批苛刻的高质量数据集，去**逼迫多条不同的 Encoder 编码器，在面对同一个物理概念（比如：一只正在叫的橘猫）时，输出在同一个数学空间中距离无限接近的联合表征向量。**
+这三大类向量不仅维度尺寸不同，而且它们所映射的数学流形（Manifold）在原始状态下并不天然重合。所谓“跨模态对齐工程”，就是构建一批高质量样本，使多条不同 Encoder 在面对同一个物理概念（例如一只正在叫的橘猫）时，输出可以在同一数学空间中相互接近的联合表征向量。
 
-### 11.1.3 为什么单独洗图文/音视频还不够：错配的毒药
+### 11.1.3 为什么单独洗图文/音视频还不够：错配风险
 
-在单纯的前置处理中（如 Ch08 中我们做过的那样），我们只负责把画质模糊的图片丢掉，或者把没声音的视频删掉。但如果我们仅仅满足于做这种“卫生学清洗”，就会错失真正的认知飞跃。
+在单纯的前置处理中（如第8章中所讨论的那样），我们只负责把画质模糊的图片丢掉，或者把没声音的视频删掉。但如果只满足于这种基础清洗，就会错失真正的跨模态对应关系。
 
-**独立清洗不能带来对应关系。** 想象有一百万张高清猫咪图片，另有一百万句描写猫咪的绝美网文。它们各自的数据质量都是 100 分。如果你不将这具体的某一张图与某一段文字发生**刚性连接（Hard Link）**，模型就不知道“橘黄色猫毛”这个 Token 对应的是图片里哪个像素。
+**独立清洗不能带来对应关系。** 即使同时拥有一百万张高清猫咪图片和一百万句高质量猫咪描述，如果没有把具体图片与具体文本建立**刚性连接（Hard Link）**，模型仍无法知道“橘黄色猫毛”这个 Token 对应图片中的哪个区域。
 
-当一个千亿规模的视觉端大模型训练 Loss 发生了灾难级抖动发散，或者在推理时面对图片胡言乱语。算法团队往往会第一反应去怪罪学习率没调好，或者怪罪 Attention 架构不行。
-但数据工程师必须站出来说真话：**绝大多数多模态端到端融合模型的收敛失败，根本源于对齐样本里的“软挂载”和“高伪像”带来的脏信号反噬。**
+当一个大规模视觉语言模型训练 Loss 发生明显抖动，或者在推理时面对图片答非所问，算法团队往往会先检查学习率和 Attention 架构。但数据工程师也必须检查对齐样本中的“弱相关标注”和“高伪像”是否带来错误训练信号。
 
-举例而言，当训练数据给出一张图是“巨大的埃菲尔铁塔”，而旁边的文字标注却是“我今天在巴黎开心地吃了个羊角面包”，这就是一条典型的“弱相关甚至互斥”毒药。系统将强行把“吃面包的欢快语义”和“埃菲尔铁塔的视觉张量”扯在一起强做余弦优化合并（Contrastive Loss），久而久之就把模型的常识彻底撕裂。
+举例而言，当训练数据给出一张图是“巨大的埃菲尔铁塔”，而旁边的文字标注却是“我今天在巴黎开心地吃了个羊角面包”，这就是一条典型的“弱相关甚至互斥”高风险样本。系统会在对比学习（Contrastive Loss）中强化错误关联，使视觉实体和文本语义之间形成不稳定映射。
 
 ---
 
 ## 11.2 方法框架：对齐对象的边界与三级金字塔
 
-想要实现完美对齐，必须先理清我们要对齐的“对象”到底是什么，并建立严密的层级结构设计规划。
+想要实现有效对齐，必须先理清需要对齐的“对象”是什么，并建立层级化的结构设计。
 
 ### 11.2.1 对齐对象全面梳理矩阵
 
@@ -48,54 +59,56 @@
 1. **图-文对齐（Image-Text Alignment）**：最基础的对齐。要求视觉特征能够精细映射到名词实体、颜色、空间关系和动作等文本语义。
 2. **音-文对齐（Audio-Text Alignment）**：通过 ASR（语音识别）和 Captioning，将声纹特征与文字对应。不仅是“说什么”，还包括“谁在说（Speaker）”、“什么情绪”。
 3. **视-音对齐（Video-Audio Alignment）**：画面动作与环境声的绝对同步匹配，例如“锤子敲击钉子的瞬间”与“金属碰撞声”的对齐。这是消除幻听的核心。
-4. **视-音-文三模态对齐（Video-Audio-Text Tri-modal Alignment）**：最高阶的复杂对齐，不仅需要音画同步，还需要文本精准描述该时间切片内发生的所有物理事件。
+4. **视-音-文三模态对齐（Video-Audio-Text Tri-modal Alignment）**：复杂度最高的对齐类型，不仅需要音画同步，还需要文本准确描述该时间切片内发生的关键事件。
 
 ### 11.2.2 工业级三级金字塔：对象级、片段级与文档级
 
-在顶级的大厂数据中台里，我们将上述对齐对象的颗粒度（Granularity）残酷地分为了三个阶层，构筑出跨模态对齐的三级金字塔。
+在生产级数据平台中，上述对齐对象通常会按颗粒度（Granularity）划分为三个层级，形成跨模态对齐的三级框架。
 
 ![图11-1：跨模态对齐的三级金字塔架构](../../images/part3/cross_modal_alignment_hierarchy.png)
 
-*图11-1：跨模态对齐的三级金字塔架构 —— 展现了从微观到宏观的三级对齐体系：底层为基于 BBox 的对象级对齐（Object-Level），中层为基于 DTW 时序同步的片段级对齐（Segment-Level），顶层为超级长上下文交错缝合的文档级对齐（Document-Level）。*
+*图11-1：跨模态对齐的三级金字塔架构 —— 展现从微观到宏观的三级对齐体系：底层为基于 BBox 的对象级对齐（Object-Level），中层为基于 DTW 时序同步的片段级对齐（Segment-Level），顶层为长上下文交错排序的文档级对齐（Document-Level）。来源：本书自绘；Alt text：跨模态对齐三级金字塔，展示对象级、片段级和文档级对齐之间的层级关系。*
 
 #### 1. 对象级（Object-level / Micro-alignment）：框与词的细粒度锚固
 
-这是多模态基座在婴儿期必须吃下的第一口奶也是必须要修的最底层的地基。
-在此级别不需要大道理。只需要精确的几何坐标映射关联：例如图片中出现的一只猫，就必须被绝对无误的 Bounding Box（2D边框坐标）框出来，比如 `[x1:100, y1:200, x2:350, y2:450]`；然后在对应的文本 JSON 中写道：`<box> 猫 </box>`。
+对象级对齐是多模态基座模型建立视觉词汇映射的基础层级。
+在此级别，关键是精确的几何坐标映射：例如图片中出现一只猫时，需要用 Bounding Box（二维边框坐标）框出区域，例如 `[x1:100, y1:200, x2:350, y2:450]`；随后在对应的文本 JSON 中写入 `<box> 猫 </box>`。
 
-这是为了在早期的 Projection Layer（投射层）训练中，告诉模型：“你看，不管你看到了多少眼花缭乱的光学信号，最后这个框里面的这堆红绿蓝颜色堆积，跟文本词汇表里 ID 为 `45321` 的 `Cat`，在数学上是同等存在。”
-这一层的对齐如果出大面积失真（坐标偏移导致框了猫却打上了狗的标签），将直接严重损伤大模的 Vision Encoder 本地响应映射函数。
+这一设计的目的，是在早期 Projection Layer（投射层）训练中建立视觉区域与文本词汇之间的稳定对应关系。例如，框内的图像特征应当与文本词汇表中表示 `Cat` 的 Token 建立相近表征。
+如果这一层发生大面积失真（例如坐标偏移导致框中是猫却标注为狗），Vision Encoder 的局部响应映射会受到直接影响。
 
 #### 2. 片段级（Segment-level / Meso-alignment）：连续时间序列映射
 
-这是我们在 Ch10 里重点攻坚的层级。这个级别引入了**长度的跨模态不等量换算**。一段 3.5 秒钟的视频，包含 105 个连续运动的视网膜成像帧序列，同时伴随 3.5 秒的声带高能气流波段；而转换到的对应文本，可能仅仅是为了极其简短的一句 `“The white car drives down the street.”`。
+这是第10章重点讨论的层级。这个级别引入了**长度的跨模态不等量换算**：一段 3.5 秒钟的视频可能包含 105 帧连续画面，同时伴随 3.5 秒的音频信号；转换到文本侧时，可能只对应一句简短描述，例如 `"The white car drives down the street."`。
 
 105 个视觉画面如何对应 7 个英文单词？数据工程师往往运用耗费算力的 DTW（Dynamic Time Warping，动态时间规整）或复杂的基于注意力图的软关联系统去切割它。需要注意的是，标准 DTW (Sakoe and Chiba 1978) 的时间与空间复杂度均为 O(N×M)——对于长达 4500 帧 × 6200 词的片段，内存需求可超过 90GB，因此生产环境中通常配合 **FastDTW** (Salvador and Chan 2007) 近似算法（线性复杂度）并将片段限制在 60 秒以内（详见 §11.6.4 的 OOM 案例）。在这一层对齐中，允许少量的前后滞后浮动时间容错（通常设置 Sakoe-Chiba 带宽为 ±0.3–1.0 秒），但绝不容忍"因果倒置"式的前后时序序列混乱。
 
-#### 3. 文档级（Document-level / Macro-alignment）：超长交错的多体宇宙宏观对立融合
+#### 3. 文档级（Document-level / Macro-alignment）：长上下文交错融合
 
-当模型已经能认识短句子里的所有图文和动作小视频对应后，就要进入真正的终极大考阶段（这也是目前通往 GPT-4o 级别乃至更高远深邃大一统多模态长上下文处理的最前沿主战场）。
+当模型已经能处理短图文对和短视频片段之后，还需要进一步面对长上下文、多页文档和多轮图文引用场景。
 
-这里的对象不再是切碎的块，而是动辄几十上百页带有精美图解的说明书、论文或是极长极长带连续回放的电影胶片集（例如一个巨大的 PDF 文件渲染出来的几十张连续图片序列）。
-在此时数据制作的最精髓之处，并非如何抠细节坐标。而是如何在高达 100K 乃至 1M 的 Token 训练窗口中，将这些图、文、声信号极具规律地、**错落有致地排布（Interleaved Ordering）**，让模型不仅进行微观的视觉提取，甚至需要在成百上千页文本跨度范围内，根据前面某一页给出过的图标图例去长线推理后面第 50 页文本内容的最终隐喻象征。
+这里的对象不再是孤立片段，而是几十页甚至上百页的说明书、论文、研报、网页归档，或由长视频切分得到的连续帧序列。数据制作的重点也不再只是局部坐标，而是在 100K 乃至 1M Token 的训练窗口中，将图、文、声信号按可解释规则进行**交错排序（Interleaved Ordering）**。这样模型才能在长距离上下文中利用前文图例、表格结构或音视频线索，完成后续页面或片段的指代与推理。
 
-**表11-1：三层异构对齐策略与其必须应对的最前沿大模型适用特种任务一览表**
+**表11-1：三层异构对齐策略、成本特征与适用任务**
 
-| 颗粒度封层 | 对齐的手段与重度特征表达 | 数据依赖的构建开销 / 极度成本代价 | 为大语言模型（LLM）开启解锁的核心适用顶级特工任务 |
+| 对齐粒度 | 主要手段与特征表达 | 数据构建开销 | 典型适用任务 |
 | :--- | :--- | :--- | :--- |
-| **底层防线：对象级 (Object-level)** | 高昂的人工密集标注 BBox；或者通过先进大模型教师强制生成精细抠图区域与绝对对应单词坐标点。 | （高昂，重度依赖人工众包或者大量预处理小核芯推断算力的烧录） | **Region Grounding（区域级溯源）、极小区域病理图像诊断寻找病灶、无人机视觉锁定打击。** |
-| **中层壁垒：片段级 (Segment-level)** | 时间轴对齐算法；通过双塔打分（如 CLIP Score 或 CLAP Score）进行密集矩阵过滤。 | （算力烧损，大量消耗高速内存显存用于高频短段解压重排计算） | **Action Recognition（动作解析识别）、Video Captioning（短剧解读与摘要生成）、Voice Translation。** |
-| **顶层天宫：文档级 (Document-level)** | 高级排版提取引擎（如 Nougat 的解构网络）；采用含有极其多图文互相引用的超级超长交错排序流。 | （重在长文本调度编排，对上下文缓存 Context Cache 和 KV 大幅压榨挑战极大） | **超大长流程 Multi-modal QA（多页财报或研报的审读回答）、长时多线程事件因果超级推理。** |
+| **对象级 (Object-level)** | 人工或模型辅助标注 BBox，并建立区域与词汇的坐标映射。 | 高，依赖细粒度标注、复核和局部视觉推理。 | Region Grounding、医学影像区域定位、工业缺陷检测。 |
+| **片段级 (Segment-level)** | 时间轴对齐算法；通过双塔打分（如 CLIP Score 或 CLAP Score）进行片段级过滤。 | 中到高，依赖解码、特征抽取、矩阵匹配和抽检。 | Action Recognition、Video Captioning、Voice Translation。 |
+| **文档级 (Document-level)** | 版面提取引擎（如 Nougat）与长上下文交错排序流。 | 高，依赖长上下文调度、版面重建和跨页一致性检查。 | 多页财报问答、研报审读、长文档多模态检索。 |
 
 ## 11.3 跨模态融合工程流水线：表示、配比与难负样本
 
-在明白了对齐的层次之后，接下来的核心战役是如何把它们真正打包成一个能够顺滑流过大型矩阵乘加网络（MatMul）的数据结构体。这需要高度严密的表示融合工程方案出场。一条标准的多模态数据工程流水线，涵盖了从表示统一、配比混合到负样本挖掘的完整闭环。
+在明确对齐层次之后，下一步是把这些信号打包成可被训练框架稳定读取的数据结构。一条标准的多模态数据工程流水线，通常涵盖表示统一、配比混合、负样本挖掘和质量验证四个环节。
+
+### 11.3.1 统一表示与占位符工程（Placeholder Engineering）
 
-### 11.3.1 统一超维张量表示与精细的占位符工程（Placeholder Engineering）
+大语言模型的主干通常以离散 Token 序列为接口，因此图像、音频和视频特征需要通过 Placeholder Engineering 与量化机制进入训练流。当通过 VQ-VAE (van den Oord et al. 2017) 或离散 Auto-Encoder 抽取特征后，连续的视觉或声学张量可以被表示为离散编号，例如将图像块映射为 `<IMG_TK_451>`。
 
-所有的大语言模型骨架天生只能吞吐离散化的 Token。那图片和声波怎么变成离散 Token？这就是 **Placeholder Engineering** 和 Quantization 的力量源泉。当通过诸如 VQ-VAE (van den Oord et al. 2017) 或者前沿的高阶离散 Auto-Encoder 抽取后，连续的色彩张量会被强行压成高度收敛的离散编号（如图像块转为 `<IMG_TK_451>`）。
+在合成训练流时，JSON 样本通常不会直接存放大规模浮点矩阵，而是采用显式占位符模式。代码清单11-1展示了一个多模态 JSONL Schema 的示意片段。
+
+**代码清单11-1：多模态融合样本 JSONL Schema 示例**
 
-在合成训练流时，原本的 JSON 样本数据流中并不会真正在文本字符串中塞满庞大的矩阵浮点数序列。而是采用简洁优雅的占位符模式。
 ```json
 {
   "id": "mm_00483921",
@@ -108,28 +121,28 @@
 
 ![图11-2：多模态融合与负样本挖掘管线](../../images/part3/fusion_training_sample_design.png)
 
-*图11-2：多模态融合样本设计图 —— 左侧展示了独立的图片/音频/文本池，中端展示了数据拼装 JSONL 结构，右侧通过占位符技术（Placeholder Grid）映射为离散 Token，最终打包成统一维度的融合张量块供下游模型预训练。*
+*图11-2：多模态融合样本设计图 —— 左侧展示独立的图片、音频和文本池，中间展示数据拼装 JSONL 结构，右侧通过占位符技术（Placeholder Grid）映射为离散 Token，最终打包成统一维度的融合张量块供下游模型预训练。来源：本书自绘；Alt text：多模态融合样本设计图，展示图片、音频、文本池如何通过 JSONL 和 Placeholder 映射为统一训练样本。*
 
-### 11.3.2 多模态样本配比（Data Mixing）：维持智商的平衡术
+### 11.3.2 多模态样本配比（Data Mixing）：控制能力遗忘
 
 如果训练数据中 90% 都是图文对，模型就会慢慢退化，丧失了纯文本逻辑推理的能力。这种现象被称为**跨模态遗忘（Cross-modal Catastrophic Forgetting）**。因此，样本配比（Data Mixing）是模型能否成功的关键工程决策。
 
-在工业界，多模态样本的配比绝非拍脑袋决定，而是经过严格的消融实验（Ablation Study）确定的“黄金比例”。典型的融合配比策略如下：
-- **纯文本保留池（20%~30%）**：强行混入高质量的数学、代码和逻辑推理纯文本（如书中第一篇提到的 Mini-C4 精粹），确保大语言模型的大脑不生锈。
+在生产环境中，多模态样本配比应通过消融实验（Ablation Study）确定。以下比例为截至 2026-06 的示例性参数，实际配置需要根据模型阶段、任务目标和验证集表现重新校准：
+- **纯文本保留池（20%~30%）**：保留高质量数学、代码和逻辑推理纯文本（如第一篇提到的 Mini-C4 精选语料），降低跨模态训练对语言推理能力的侵蚀。
 - **粗粒度图文对齐（40%~50%）**：海量的广域图文样本（如 LAION-5B 提纯版），用来构建最基础的世界实体认知词典。
-- **细粒度与交错数据（10%~20%）**：高成本的 BBox 对应图、多图交错长文档、OCR 结构树。这类数据极其珍贵，是模型产生涌现能力（如看图做几何题）的催化剂。
+- **细粒度与交错数据（10%~20%）**：高成本的 BBox 对应图、多图交错长文档、OCR 结构树。这类数据有助于提升空间定位、文档理解和复杂图文推理能力。
 - **合成微调对话（10%）**：由 GPT-4V 生成的多轮多模态对话，用于将基础对齐能力转化为人类习惯的问答格式。
 
-### 11.3.3 “难负样本（Hard Negatives）”深度挖掘与极限生存生成策略
+### 11.3.3 难负样本（Hard Negatives）挖掘与质控策略
 
-在对比学习对齐（Contrastive Alignment）中，如果模型总是能轻易区分出“猫”和“狗”，它的能力提升就会遭遇边际递减效应瓶颈。必须人为制造地狱难度的干扰选项，逼迫模型寻找更细微、更本质的差别。
+在对比学习对齐（Contrastive Alignment）中，如果模型总是区分简单样本对（例如“猫”和“狗”），能力提升会很快进入边际递减阶段。难负样本的作用，是为模型提供语义接近但关键属性不同的样本对，使其学习更细粒度的视觉、文本和时序差异。
 
 **难负样本的五大核心挖掘手段：**
 
-1. **极小微差替换法（Subtle Replacement Mining）**：将正样本图片"一只蓝色的杯子放在木桌上"原样保留，从海量句库中找出只改变了一个关键修饰词的文本——"一只**黑色**的杯子放在木桌上"——将其作为负类。逼迫 Vision Encoder 死死关注画面里的颜色细节。
-2. **跨模态属性错位法（Cross-modal Attribute Swap）**：在图片级进行局部语义篡改。通过 Inpainting 模型将图片中的"红苹果"改写为"绿苹果"，同时保留原始正向文本。错位强迫 Cross-attention 层精确感知视觉区域与文字描述的绑定关系。
+1. **极小微差替换法（Subtle Replacement Mining）**：将正样本图片"一只蓝色的杯子放在木桌上"原样保留，从海量句库中找出只改变一个关键修饰词的文本——"一只**黑色**的杯子放在木桌上"——并将其作为负类，使 Vision Encoder 更关注颜色细节。
+2. **跨模态属性错位法（Cross-modal Attribute Swap）**：在图片级进行局部语义改写。通过 Inpainting 模型将图片中的"红苹果"改写为"绿苹果"，同时保留原始正向文本。错位样本促使 Cross-attention 层学习视觉区域与文字描述的绑定关系。
 3. **批内在线最难负样本挖掘法（In-Batch Online Hard Negative Mining, OHNM）** (Chen et al. 2020)：在每个训练批次内部动态计算所有样本两两之间的相似度，挑选出相似度最高但语义不匹配的样本对。OHNM 无需构建静态数据库，而是让模型实时决定"最有训练价值的困难样本"。
-4. **时序扰动法（Temporal Perturbation，适用于视频-文本）**：将视频字幕与相邻时间窗口（如前后 3 秒）的画面错位配对。例如正样本是「`<00:03-00:06>` 运动员起跑」，负样本则是文本错配到「`<00:10-00:13>` 运动员冲线」。这迫使模型学会严格的时间因果关联。
+4. **时序扰动法（Temporal Perturbation，适用于视频-文本）**：将视频字幕与相邻时间窗口（如前后 3 秒）的画面错位配对。例如正样本是「`<00:03-00:06>` 运动员起跑」，负样本则是文本错配到「`<00:10-00:13>` 运动员冲线」。这类样本用于强化模型对时间因果关系的辨别能力。
 5. **大模型合成难负样本法（LLM-Generated Synthetic Hard Negatives）**：调用 LLM 输入正向描述，要求生成"语义极相近但含关键事实错误"的对抗文本。相比词典替换，此法多样性高，是业界主流的规模化生产方式。
 
 **表11-2：五种难负样本挖掘策略对比**
@@ -142,71 +155,74 @@
 | 时序扰动 | 时间轴错位配对 | 片段级（视频） | 强化时序因果学习 | 需精准的时间戳标注 |
 | LLM 合成生成 | 大模型指令生成 | 多粒度 | 规模大、多样性高 | 存在假负例，需质检过滤 |
 
-## 11.4 质量评估体系：跨模态评测与严格的反向裁决闭环漏斗
+## 11.4 质量评估体系：跨模态评测与质量闭环
 
-如果辛辛苦苦耗资千万编排好的庞大融合数据对齐批次，没有任何指标就下放，那就无异于把黄金当废纸往熔炉里倒。跨模态数据的质量评估必须是一个多维度的防御体系，特别是要针对**幻觉（Hallucination）**建立探测雷达。
+跨模态融合数据通常具有较高的构建成本，因此不应在缺少质量指标的情况下直接进入训练。质量评估需要覆盖模态间映射、时序一致性、空间定位、幻觉风险和人工抽检等维度，尤其要针对**幻觉（Hallucination）**建立可追踪的检测机制。
 
 ### 11.4.1 跨模态评测指标映射体系
 
-跨模态评测不仅要看单一模态的质量，更要看模态之间的映射关系是否坚固。以下是工业界最核心的防线：
+跨模态评测不仅要看单一模态的质量，更要看模态之间的映射关系是否稳定。表11-3列出常见指标及其对应的治理动作。
 
-**表11-3：核心评价指标防线与严重误差来源映射表**
+**表11-3：核心评价指标、误差来源与治理动作映射表**
 
-| 高阶评估指标参数（Metric） | 物理含义与业务映射 | 失败阈值与致死级误差来源 | 工业防御救赎措施 |
+| 评估指标（Metric） | 物理含义与业务映射 | 风险阈值与误差来源 | 治理动作 |
 | :--- | :--- | :--- | :--- |
-| **跨模态重召回率（Cross-Modal R@1 / R@5）** | 输入复杂图/视频，用文本反向搜索时前5次精准捞起对应描述的概率。 | < 75% 说明 Object Level 坐标点或字典映射完全张冠李戴，大范围串片。 | 熔断训练！调用强视觉大模型重新洗涤全量 BBox。 |
-| **时序顺延对齐分数（Temporal Continuity Score）** | 音轨词序列在视频切片的发生顺序，是否和真实物理世界事件链匹配。 | 时空因果律逆转！大概率使用了低级的打散抽帧算法或遗失了全局时间ID。 | 强制加入绝对时间戳（Global Timestamps Constraint）。 |
-| **多模态幻觉率（MM-Hallucination Rate / CHAIR）** | 模型在描述图片时，生成了图片中根本不存在的物体或动作的概率。 | > 15% 说明训练数据中存在大量“弱相关文本”（如给埃菲尔铁塔配上面包文本）。 | 提升 CLIP Score 过滤阈值；引入强 LLM 进行文本重写纠偏。 |
-| **文本蕴含度冲突指数（Entailment Conflict Rate）** | 同一张图的十句人工描述，彼此间是否存在逻辑相悖。 | 重度外包数据注水。人工标注质检网形同虚设！ | 发起 HITL（Human-in-the-Loop）十倍惩罚重新抽检。 |
+| **跨模态召回率（Cross-Modal R@1 / R@5）** | 输入图像或视频后，用文本反向检索对应描述的命中概率。 | 指标显著下降通常说明对象级坐标或字典映射存在系统性错配。 | 暂停问题批次入训；重新抽检 BBox、Caption 和样本拼装链路。 |
+| **时序连续性分数（Temporal Continuity Score）** | 音轨、字幕和视频片段的发生顺序是否匹配真实事件链。 | 前后顺序颠倒通常来自抽帧、字幕对齐或全局时间戳丢失。 | 引入绝对时间戳约束（Global Timestamps Constraint）并回放抽检。 |
+| **多模态幻觉率（MM-Hallucination Rate / CHAIR）** | 模型描述图片时生成不存在物体或动作的概率。 | 高于业务阈值说明训练数据中存在较多弱相关文本或重标注漂移。 | 调整 CLIP/SigLIP 阈值，引入人工复核和文本重写纠偏。 |
+| **文本蕴含冲突率（Entailment Conflict Rate）** | 同一图像的多条描述之间是否存在逻辑冲突。 | 冲突率过高通常说明标注指南不一致或外包质检不足。 | 更新标注规范，按来源和标注员分层抽检，并回写问题样本库。 |
 
 ### 11.4.2 成本约束与对齐预算治理
 
-跨模态对齐的成本是惊人的。计算一亿对图文的 CLIP Score 约需几千美元的 GPU 算力，而运行千万级视频的 DTW 对齐则可能耗费数十万美元。数据工程师必须建立**成本核算模型**：在对象级对齐中，优先使用便宜的启发式规则过滤，将昂贵的 GPT-4V 或高维矩阵计算（如 CLIP/SigLIP）留到金字塔尖的 10% 核心数据上。盲目全量计算是对算力预算的极度浪费。
+跨模态对齐成本较高。以截至 2026-06 的示例性估算口径，计算一亿对图文的 CLIP Score 可能需要数千美元级 GPU 算力，千万级视频片段的 DTW 对齐则可能达到数十万美元级预算；实际成本取决于硬件单价、视频长度、分辨率、特征模型和并发策略。数据工程师必须建立**成本核算模型**：在对象级对齐中，优先使用低成本启发式规则过滤，将 GPT-4V 或高维矩阵计算（如 CLIP/SigLIP）留给高价值候选样本。盲目全量计算会使预算迅速失控。
 
-## 11.5 终章：真实千卡集群试炼中的失败模式与绝境补救
+## 11.5 匿名化复合案例与章节衔接
 
-作为本篇的收尾，以下三个真实失败案例揭示了跨模态对齐工程中最典型的错误模式，对数据工程师具有重要的警示意义。
+作为本篇的收尾，以下三个匿名化复合案例用于说明跨模态对齐工程中常见的错误模式。案例中的机构、规模、成本与结果均已做泛化处理，仅用于呈现风险类型和排查路径。
 
-### 11.5.1 案例一：医疗多模态问答中的部位张冠李戴（对象错位）
-在一家顶尖健康 AI 机构开展的基于长篇胸透 X 光片与主治医师医嘱文本的大对齐项目中，初期跑分极为完美。然而上线后遭到了严重的信任危机：模型居然开始指着患者左肺上的正常阴影说是晚期癌变区域！
-**根因与复盘**：数据录入时，工程师疏忽漏掉了对于“X光胶片物理翻转和镜像（Mirroring Data-Augmentation）”的绝对禁止设定！这引发了底层空间中左右颠倒的投射污染。此一战让该机构销毁了足足历时六个月耗费大量算力打磨的核验集。
+### 11.5.1 案例一：医疗多模态问答中的部位错配（匿名化复合案例）
+某医疗影像问答项目将胸部 X 光片与医嘱文本进行对齐训练，离线指标初期表现较好，但上线前抽检发现模型会把左肺区域的正常阴影错误解释为右肺病灶。
+**根因与复盘**：数据增强管线允许 X 光片进行水平翻转，却没有同步更新 BBox、左右方位文本和医学方向元数据。这导致对象级空间关系被系统性污染。修复方案包括禁用高风险镜像增强、补充 `orientation` 元数据校验，并对左右方位相关样本建立专项抽检集。
 
-### 11.5.2 案例二：安防长篇视频检索中的“时空穿梭”（片段错位）
-某前沿安防平台的大模型训练遭遇令人困惑的“穿梭幻听”。监控记录到一个歹徒翻墙逃逸，模型没有生成翻墙声，却诡异地输出了两小时之后审讯室里的嘈杂争吵人声。
-**根因与复盘**：在 11.2 节的片段级对齐环节，分布式处理工程师使用了存在缺陷的弱一致性数据库（NoSQL Eventual Consistency），导致超过 12,000 个监控录像的长音频因为极小的读写延迟发生了**一整格指针的高速位移偏移（Offset By One Bug）**！微弱的偏移导致所有事后音频全部嫁接到了提前一幕的视频上。
+### 11.5.2 案例二：长视频检索中的片段错位（匿名化复合案例）
+某长视频检索系统在训练后出现音画错配：画面记录的是人员跨越围栏的片段，模型却关联到数小时后室内谈话的音频内容。
+**根因与复盘**：在 11.2 节的片段级对齐环节，分布式处理流程使用了弱一致性元数据存储，导致超过 12,000 个视频片段的音频指针发生 Offset By One Bug。微小的索引位移使多个后续音频片段被接到错误画面上。修复方案是将关键时间戳写入强一致性存储，并在片段入库前执行音画相似度抽检。
 
-### 11.5.3 案例三：自动驾驶多模态大模型的致命幻觉（语义错配幻觉）
-某自动驾驶实验室训练出的 VLM（视觉语言模型），在看路况视频时，只要画面中出现红绿灯，无论红绿，模型输出的决策文本一律是“绿灯，加速通过”。
-**根因与复盘**：追溯训练数据发现，采购的自动驾驶图文数据集中，大量标注员为了赶进度，对所有带有红绿灯的交叉路口图片使用了同一个批量复制的文本模板：“车辆在绿灯路口正常行驶”。这导致模型在训练时，将“红绿灯的视觉特征”与“绿灯加速文本”建立了强烈的毒性捷径（Shortcut Learning）。修复方案是引入了严格的**跨模态幻觉探测器**，并重新生成了极高难度的难负样本（同一路口的红灯与绿灯对比），才纠正了这一致命错觉。
+### 11.5.3 案例三：自动驾驶路口样本的语义错配（匿名化复合案例）
+某自动驾驶视觉语言模型在路况视频评估中出现固定模板输出：只要画面中出现交通灯，模型就倾向于生成“绿灯，车辆正常通行”的文本。
+**根因与复盘**：追溯训练数据发现，外部采购的数据集中存在大量批量复制的路口描述模板，红灯、黄灯和绿灯样本均被标为“车辆在绿灯路口正常行驶”。这导致模型学习到错误捷径（Shortcut Learning）。修复方案是引入跨模态幻觉检测器，并重新构造同一路口红灯、黄灯、绿灯的难负样本对。
 
 ### 11.5.4 跨模态融合与对齐工程 Checklist
 
-在将你的多模态数据集推送给训练集群前，请务必核对：
+在将多模态数据集推送给训练集群前，建议逐项核对：
 - [ ] **对齐防泄漏**：是否确保数据增强（如翻转、裁剪）时，对应的文本描述（如左右关系）和 BBox 坐标同步更新了？
 - [ ] **时序锚点核验**：音视频片段切分后，是否抽检过绝对时间戳（Global Timestamps）没有发生偏移倒挂？
 - [ ] **负样本难度分布**：是否检查了 In-batch 负样本的相似度分布？阈值是否过高导致了真阳性被误杀（False Negatives）？
 - [ ] **格式哨兵完整性**：JSONL 里的占位符 `<IMG_TK>` 是否被错误地 HTML 转义了？是否每一段都带有 `<\|image_start\|>`？
 - [ ] **数据配比安全网**：训练包里是否保留了至少 20% 的纯文本高质语料以防止跨模态遗忘？
 
-### 11.5.5 第 3 篇完结寄语及前瞻：迈入对齐人类核心价值观的新领域
+### 11.5.5 第三篇小结与第四篇衔接
 
-回首这一路的漫长旅程。我们从最简单的图片清洗除水印起步，历经严重的海量视频时空打散对抗重组，最终在刚才用宏大的三层多模态金字塔对齐策略，成功结束了这场规模浩瀚异常、死伤无数的数字异构数据底座远征战役。至此，全套的数据工厂流水线已经被我们彻底组装完毕。所有流入那个极点深渊大模型嘴边的数据，均是这颗星球上经过最优结构化淬炼、最极尽对齐排版以及没有任何模态隔膜的顶尖智慧原料包。
+第三篇从图像清洗、图文语义过滤和重标注开始，进一步讨论 OCR 与文档结构化、音视频切片与时序对齐，最终在本章收束为对象级、片段级和文档级三层跨模态对齐框架。至此，多模态数据工程的关键问题已经从“样本是否干净”推进到“不同模态之间是否具有可验证的监督关系”。
 
-然而，感知能力的建立只是第一步。预训练完成的模型仍需要明确的指令引导和价値观对齐，才能真正服务于人类的实际需求。这正是**《第四篇：对齐与指令数据（Alignment and Instruction Data）》**将重点探讨的内容——从 Ch12 的 SFT 数据设计，到 RLAIF、PPO 与人类反馈系统的全链路工程实践。
+然而，感知能力的建立只是第一步。预训练完成的模型仍需要明确的指令引导、偏好反馈和价值观对齐，才能服务于真实用户任务。这正是**第四篇：对齐与指令数据（Alignment and Instruction Data）**将重点探讨的内容：从第12章的 SFT 数据设计，到 RLAIF、PPO 与人类反馈系统的全链路工程实践。
 
 
 
-## 11.6 附录：跨模态对齐分布式训练高频崩溃日志与排雷手册
+## 11.6 附录：跨模态对齐分布式训练高频错误日志示例与排查手册
 
-> 以下精选 5 类在万卡跨模态对齐预训练中真实发生的代表性崩溃场景，覆盖对齐 Loss 发散、BBox 坐标错位、负样本污染、DTW 内存溢出和多模 Token 混合格式错误五大核心链路。
+> 以下为匿名化错误日志示例，覆盖对齐 Loss 发散、BBox 坐标错位、负样本污染、DTW 内存溢出和多模 Token 混合格式错误五类核心链路。日志中的主机名、路径、批次号和指标均为示例性参数，不指向公开可复现事故。
 
 ---
 
 ### 11.6.1 Contrastive Loss 瞬间发散至 NaN [ERR_CROSS_MDL_FUSION_7X001]
 
-**[故障现象]**：在 42 个 Epoch 稳定训练后，导入最后一批含大量低质量视频语料的融合批次时，Contrastive Loss 在数秒内几何级暴涨，整个训练节点以 NaN 宕机。
+**[故障现象]**：在多个 Epoch 稳定训练后，导入一批低质量视频语料时，Contrastive Loss 快速升高，训练节点因 NaN 中断。
+
+代码清单11-2展示了对齐 Loss 发散的匿名化错误日志示例。
+
+**代码清单11-2：对齐 Loss 发散错误日志示例**
 
-**[堆栈快照]**:
 ```bash
 [WARNING] node-001.storage-backend.local:
 Infinity detected in temporal grounding cross-attention matrix!
@@ -226,7 +242,10 @@ Cross-Modal Feature Match Score dropped from 0.89 to 0.00000000003.
 
 **[故障现象]**：对象级（Object-level）对齐准确率指标 R@1 在某一数据批次导入后从 0.82 骤降至 0.31，推理时出现大规模左右空间方向错误（"左"说成"右"，"左肺病灶"标注到右肺）。
 
-**[堆栈快照]**:
+代码清单11-3展示了 BBox 坐标翻转的匿名化错误日志示例。
+
+**代码清单11-3：BBox 坐标翻转错误日志示例**
+
 ```bash
 [ERROR] grounding_eval_worker_05:
 Region match failure: predicted bbox [x1:680, y1:200, x2:920, y2:450],
@@ -245,12 +264,15 @@ Suspected data augmentation mirror flip applied AFTER bbox annotation.
 
 **[故障现象]**：在引入 Hard Negative Mining 后，Recall@5 不升反降，训练损失的方差异常增大，模型对近义词和语义相近句子的区分能力完全丧失。
 
-**[堆栈快照]**:
+代码清单11-4展示了难负样本污染的匿名化错误日志示例。
+
+**代码清单11-4：难负样本污染错误日志示例**
+
 ```bash
 [WARN] hard_negative_miner_worker_2:
 False negative rate in batch 3421: 38.7% (threshold: < 5%).
 Positive pairs incorrectly tagged as hard negatives: 8,240 / 21,300.
-CLIP cross-modal similarity threshold set too aggressively: 0.92 → too many true positives excluded.
+CLIP cross-modal similarity threshold set too aggressively: 0.92, too many true positives excluded.
 Contrastive loss variance: 4.82 (expected < 0.8). Training instability detected.
 ```
 
@@ -262,9 +284,12 @@ Contrastive loss variance: 4.82 (expected < 0.8). Training instability detected.
 
 ### 11.6.4 DTW 时间规整内存溢出导致片段级对齐管线停摆 [ERR_CROSS_MDL_DTW_OOM_004]
 
-**[故障现象]**：处理超过 90 秒的长视频片段时，DTW 对齐计算进程因内存耗尽被 OOM Killer 杀死，整个对齐管线卡死，积压数万条待处理任务。
+**[故障现象]**：处理超过 90 秒的长视频片段时，DTW 对齐计算进程因内存耗尽被 OOM Killer 终止，对齐管线暂停并积压大量待处理任务。
+
+代码清单11-5展示了 DTW 内存溢出的匿名化错误日志示例。
+
+**代码清单11-5：DTW 内存溢出错误日志示例**
 
-**[堆栈快照]**:
 ```bash
 [FATAL] dtw_alignment_worker_08: Killed (signal 9).
 DTW matrix allocation failed: requested 94.3 GB for sequence lengths (4500, 6200).
@@ -282,7 +307,10 @@ Queue depth at crash: 14,382 pending segments. Estimated loss: 890h of aligned a
 
 **[故障现象]**：训练进入多模 Token 混合批次后，模型 Embedding 层抛出索引越界，部分样本的图像占位符被误解析为文本 Token，导致 batch 级训练中断。
 
-**[堆栈快照]**:
+代码清单11-6展示了 Placeholder 解析失败的匿名化错误日志示例。
+
+**代码清单11-6：Placeholder 解析失败错误日志示例**
+
 ```bash
 [ERROR] multimodal_dataloader_worker_3:
 Token index 152104 out of vocabulary range (vocab_size=128256).
@@ -299,12 +327,14 @@ Affected batch: 256 samples. Training step 28,441 aborted.
 
 ## 11.6.6 高频错误速查表
 
+**表11-4：跨模态对齐高频错误类型与修复策略**
+
 | 错误代号 | 错误类型 | 核心触发条件 | 一句话修复策略 |
 | :--- | :--- | :--- | :--- |
-| ERR_CROSS_MDL_FUSION_7XXXX | Contrastive Loss → NaN | 噪声样本触发注意力零除法 | Feature Norm Clipping + 梯度裁剪 |
+| ERR_CROSS_MDL_FUSION_7XXXX | Contrastive Loss NaN | 噪声样本触发注意力零除法 | Feature Norm Clipping + 梯度裁剪 |
 | ERR_CROSS_MDL_OBJ_FLIP | BBox 坐标翻转 | 几何增强后未同步更新 BBox | Albumentations BboxParams 绑定变换 |
 | ERR_CROSS_MDL_HARD_NEG | 假负例污染 | Hard Negative 阈值过激 | 双阶段筛选 + 占比上限控制 |
-| ERR_CROSS_MDL_DTW_OOM | DTW OOM 崩溃 | 长片段 O(N×M) 矩阵爆内存 | 切片 + FastDTW 近似算法 |
+| ERR_CROSS_MDL_DTW_OOM | DTW OOM 中断 | 长片段 O(N×M) 矩阵超出内存上限 | 切片 + FastDTW 近似算法 |
 | ERR_CROSS_MDL_TOKEN_FMT | Placeholder 解析失败 | Placeholder 被 HTML 转义 | ensure_ascii=False + 入库 Linter |
 | ERR_CROSS_MDL_TEMPORAL | 时序因果倒置 | 数据库最终一致性写入偏移 | 强一致性存储 + 全局时间戳约束 |
 | ERR_CROSS_MDL_MIRROR | 医疗影像镜像污染 | 扫描仪物理输出镜像未校正 | orientation 元数据校验 + 方向固定 |
@@ -324,4 +354,3 @@ Salvador S, Chan P (2007) Toward Accurate Dynamic Time Warping in Linear Time an
 van den Oord A, Vinyals O, Kavukcuoglu K (2017) Neural Discrete Representation Learning (VQ-VAE). Advances in Neural Information Processing Systems 30.
 
 Wu Y, Chen K, Zhang T, Hui Y, Berg-Kirkpatrick T, Dubnov S (2023) Large-Scale Contrastive Language-Audio Pretraining with Feature Fusion and Keyword-to-Caption Augmentation (CLAP). In: IEEE International Conference on Acoustics, Speech and Signal Processing, pp 1-5.
-
diff --git a/docs/zh/part3/index.md b/docs/zh/part3/index.md
index c7e9b400..f35ddc98 100644
--- a/docs/zh/part3/index.md
+++ b/docs/zh/part3/index.md
@@ -2,7 +2,29 @@
 
 ## 本篇定位
 
-第三篇围绕图文、文档、视频、音频以及跨模态对齐展开，重点讨论多模态样本结构、数据清洗、视觉增强、标注对齐与融合训练的工程体系。
+第三篇围绕图文、文档、视频、音频以及跨模态对齐展开，讨论多模态样本结构、视觉与声学清洗、重标注、文档理解、时序切片、跨模态对齐与融合训练的工程体系。本篇承接第二篇的文本预训练流水线，将数据工程问题从一维文本序列扩展到图像、版面、时间轴和异构模态空间。
+
+多模态数据相较文本数据引入四类额外挑战。第一是对齐：文本、图像、音频和视频并不天然描述同一对象，必须通过语义、空间或时间锚点建立对应关系。第二是表示：视觉和声学信号需要经过 Patch、Feature、Token 或占位符机制才能进入语言模型训练接口。第三是评价：图像清晰度、OCR 可靠性、音画同步和跨模态语义一致性很难仅靠低成本文本指标判断。第四是成本：解码、重标注、OCR、ASR、向量打分和人工抽检都会显著提高预处理与训练前验证成本。
+
+本篇（第8至第11章）以图文对数据工程为起点，随后讨论重标注与文档理解，进一步展开视频与音频数据工程，最后收束到跨模态对齐与融合。读者应重点把握“单模态清洗并不等于跨模态监督成立”这一主线。
+
+## 本篇学习目标
+
+- 区分图文对、交错图文、文档截图、音视频片段和跨模态融合样本的工程差异。
+- 掌握图像质量过滤、语义对齐、重标注、OCR 增强和文档结构化的基本流程。
+- 理解视频切片、ASR、Diarization、音画同步和事件标注如何构成长时序样本。
+- 能够设计对象级、片段级和文档级跨模态对齐数据，并识别常见失败模式。
+- 能够从成本、合规、抽检和可追溯性角度评估多模态数据管线是否可进入训练。
+
+## 读者前置知识
+
+阅读本篇前，建议读者已经掌握第二篇关于文本预训练数据源、清洗去重、分词序列化和质量闭环的基本方法。若读者主要来自计算机视觉、语音或多媒体系统方向，可重点关注本篇如何把图像、音频和视频信号转化为训练接口可读取的 Token、Feature、JSONL Schema 和元数据约束。
+
+## 章节逻辑
+
+第8章建立静态图文样本的基础资产观，讨论图像清洗、CLIP/SigLIP 过滤、AnyRes 和数据混合。第9章进入细粒度监督生产，讨论 Re-captioning、OCR、版面结构和文档理解样本。第10章处理时间维度，讨论视频切片、音频转写、声学分离和时序对齐。第11章将前三章的单模态与双模态处理结果汇总为跨模态融合样本，重点讨论对齐层次、难负样本、配比和评估闭环。
+
+本篇向前承接第二篇的文本预训练管线，向后连接第四篇的指令对齐与偏好数据。换言之，第三篇负责解决“模型能否看见、听见并对齐不同模态”的问题；第四篇将在此基础上继续讨论“模型如何按照人类指令和偏好行动”的问题。
 
 ## 本篇目录
 
@@ -11,8 +33,4 @@
 - [第10章：视频与音频数据工程](ch10_video_audio.md)
 - [第11章：跨模态对齐与融合](ch11_cross_modal_alignment.md)
 
-## 建议阅读顺序
-
-- 先读第8章，理解图像与文本样本的基础资产构造。
-- 再读第9章和第10章，掌握文档、OCR、视频和音频样本的处理逻辑。
-- 最后读第11章，把跨模态对齐、融合训练和难负样本设计串成完整方案。
+建议按第8章至第11章顺序阅读。已有视觉语言模型经验的读者可以先读第11章理解跨模态对齐目标，再回读第8章、第9章与第10章，定位各类对齐信号的来源。
diff --git a/publishing/12_figures_tables_register.md b/publishing/12_figures_tables_register.md
new file mode 100644
index 00000000..b6f639d2
--- /dev/null
+++ b/publishing/12_figures_tables_register.md
@@ -0,0 +1,161 @@
+# 图表台账
+
+本文件用于统一管理全书插图、流程图、架构图、表格的编号、状态、来源与负责人。
+
+## 一、图表编号规则
+
+- 图编号：`图 章节号-序号`
+- 表编号：`表 章节号-序号`
+- 附录图表：`图 A-1`、`表 B-1`
+- 同一图表如果从线上素材改写，需标记“改绘”。
+
+## 二、图表状态定义
+
+- 待规划：还未决定是否保留
+- 待绘制：已经确定内容，尚未出草图
+- 草图完成：结构可评审，未定稿
+- 可出版：编号、标题、来源和清晰度都达标
+
+## 三、全书图表示例台账
+
+| 编号 | 类型 | 标题 | 所属章节 | 来源 | 负责人 | 状态 | 备注 |
+| --- | --- | --- | --- | --- | --- | --- | --- |
+| 图 1-1 | 图 | 大模型时代数据工程职责重构图 | 第 1 章 | 本书自绘：`docs/images/part1/data_engineering_roles_1775830393574.png` | B / F | 可出版 | 已在正文补来源与 alt text；交付前复核 300dpi/字号 |
+| 图 1-2 | 图 | 全书十四篇制生命周期地图 | 第 1 章 | 本书自绘：`docs/images/part1/data_lifecycle_map_1775830407042.png` | B / F | 可出版 | 已在正文补来源与 alt text；交付前复核 300dpi/字号 |
+| 表 1-1 | 表 | DeepMind 旧范式模型与新范式模型数据资源对比 | 第 1 章 | 本书整理，依据 Gopher / Chinchilla 论文 | B | 可出版 | 需在最终参考文献中保留对应论文 |
+| 表 1-2 | 表 | 大模型数据工程的三阶魔方：质量、规模与多样性成本约束基准矩阵 | 第 1 章 | 本书整理 | B | 可出版 | 已做出版风格降噪 |
+| 表 1-3 | 表 | 传统经验 AI 机器学习研发生命线 vs 大语言模型原生数据体系 | 第 1 章 | 本书整理 | B | 可出版 | 已做出版风格降噪 |
+| 表 1-4 | 表 | 六大 LLM 项目核心角色与数据接口职责定义表 | 第 1 章 | 本书整理 | B | 可出版 | SLA 数值为示例口径 |
+| 表 1-5 | 表 | LLM 数据工程师 vs 传统 ML 数据工程师能力边界对照表 | 第 1 章 | 本书整理 | B | 可出版 | 已修复重复表头 |
+| 表 1-6 | 表 | 各类型读者的章节优先级权重建议 | 第 1 章 | 本书整理 | B | 可出版 | 已同步 14 篇结构 |
+| 表 2-1 | 表 | LLM 数据四阶段质量目标演变矩阵 | 第 2 章 | 本书整理 | B | 可出版 | 需最终统一表题样式 |
+| 图 2-1 | 图 | 生命周期视角下的多维度质量分层架构 | 第 2 章 | 本书自绘：`docs/images/part1/data_quality_hierarchy_1775835516841.png` | B / F | 可出版 | 已在正文补来源与 alt text；交付前复核 300dpi/字号 |
+| 图 2-2 | 图 | 大模型数据缺陷与质量指标交叉映射图 | 第 2 章 | 本书自绘：`docs/images/part1/defect_metric_radar_1775835533937.png` | B / F | 可出版 | 已在正文补来源说明 |
+| 图 2-3 | 图 | 数据评分卡驱动的自动截断与治理流 | 第 2 章 | 本书自绘：`docs/images/part1/data_quality_gates_1775835548587.png` | B / F | 可出版 | 已在正文补来源与 alt text；交付前复核 300dpi/字号 |
+| 图 3-1 | 图 | AI 原生数据栈五层架构 | 第 3 章 | 本书自绘：`docs/images/part1/ai_data_stack_architecture.png` | B / F | 可出版 | 已在正文补来源与 alt text；交付前复核 300dpi/字号 |
+| 图 3-2 | 图 | 训练数据成本治理闭环图 | 第 3 章 | 本书自绘：`docs/images/part1/cost_governance_loop.png` | B / F | 可出版 | 已在正文补来源与 alt text；价格口径需随正文同步 |
+| 表 3-1 | 表 | Apache Spark vs Ray Data 核心特性对比 | 第 3 章 | 本书整理，依据 Spark / Ray 论文与工程实践 | B | 可出版 | 需最终统一表题样式 |
+| 表 3-2 | 表 | 数据湖表格式选型对比 | 第 3 章 | 本书整理 | B | 可出版 | 技术生态可能变化，交付前复核 |
+| 表 3-3 | 表 | 三类团队数据栈选型速查矩阵 | 第 3 章 | 本书整理 | B | 可出版 | 团队规模与周期为建议口径 |
+| 图 4-1 | 图 | 预训练数据源分层地图 | 第 4 章 | 本书自绘：`docs/images/part2/pretrain_data_source_map.png` | B / F | 可出版 | 已在正文补来源与 alt text；交付前复核 300dpi/字号 |
+| 表 4-1 | 表 | 数据源类型、许可与风险矩阵 | 第 4 章 | 本书整理 | B | 可出版 | 权属判断需随最终参考文献与法务口径复核 |
+| 表 4-2 | 表 | 数据配比策略与业务目标对应矩阵 | 第 4 章 | 本书整理 | B | 可出版 | 比例为工程示例口径 |
+| 图 4-2 | 图 | 数据采集与权属存证流程图 | 第 4 章 | 本书自绘：`docs/images/part2/data_ingestion_provenance_chain.png` | B / F | 可出版 | 已在正文补来源与 alt text；交付前复核 300dpi/字号 |
+| 图 5-1 | 图 | 清洗与去污染全景流程图 | 第 5 章 | 本书自绘：`docs/images/part2/cleaning_pipeline_overview.png` | B / F | 可出版 | 已在正文补来源与 alt text；交付前复核 300dpi/字号 |
+| 图 5-2 | 图 | 质量过滤漏斗与抽检闭环图 | 第 5 章 | 本书自绘：`docs/images/part2/quality_filter_funnel_loop.png` | B / F | 可出版 | 已在正文补来源与 alt text；交付前复核 300dpi/字号 |
+| 表 5-1 | 表 | 常见缺陷、检测方法与代价表 | 第 5 章 | 本书整理 | B | 可出版 | 需最终统一表题样式 |
+| 表 5-2 | 表 | 清洗动作对训练效果影响对照 | 第 5 章 | 本书整理 | B | 可出版 | 提升幅度已标注截至 2026-06 的示例口径 |
+| 表 5-3 | 表 | 轻量级清洗方案最小可行组合 | 第 5 章 | 本书整理 | B | 可出版 | 团队规模与数据量为建议口径 |
+| 图 6-1 | 图 | LLM 训练输入管道分层架构 | 第 6 章 | 本书自绘：`docs/images/part2/training_input_pipeline_layers.png` | B / F | 可出版 | 已在正文补来源与 alt text；交付前复核 300dpi/字号 |
+| 图 6-2 | 图 | 吞吐瓶颈诊断流程图 | 第 6 章 | 本书自绘：`docs/images/part2/io_bottleneck_diagnosis_flow.png` | B / F | 可出版 | 已在正文补来源与 alt text；交付前复核 300dpi/字号 |
+| 表 6-1 | 表 | 数据格式、压缩与访问模式对照表 | 第 6 章 | 本书整理 | B | 可出版 | 技术生态可能变化，交付前复核 |
+| 表 6-2 | 表 | 采样与混采策略收益对照表 | 第 6 章 | 本书整理 | B | 可出版 | 吞吐与成本数字已按估算示例处理 |
+| 图 7-1 | 图 | 数据运营飞轮图 | 第 7 章 | 本书自绘：`docs/images/part2/data_operations_flywheel.png` | B / F | 可出版 | 已在正文补来源与 alt text；交付前复核 300dpi/字号 |
+| 图 7-2 | 图 | 数据评估闭环图 | 第 7 章 | 本书自绘：`docs/images/part2/data_evaluation_loop.png` | B / F | 可出版 | 已在正文补来源与 alt text；交付前复核 300dpi/字号 |
+| 表 7-1 | 表 | 评估指标与治理动作映射表 | 第 7 章 | 本书整理 | B | 可出版 | 需最终统一表题样式 |
+| 表 7-2 | 表 | 版本迭代记录模板表 | 第 7 章 | 本书整理 | B | 可出版 | 模板字段为建议口径 |
+| 图 8-1 | 图 | 多模态图文数据工程全景图 | 第 8 章 | 本书自绘：`docs/images/part3/multimodal_data_panorama.png` | C / F | 可出版 | 已在正文补来源与 alt text；交付前复核 300dpi/字号 |
+| 图 8-2 | 图 | 图像语义对齐与过滤流程图 | 第 8 章 | 本书自绘：`docs/images/part3/image_semantic_alignment_flow.png` | C / F | 可出版 | 已在正文补来源与 alt text；交付前复核 300dpi/字号 |
+| 图 8-3 | 图 | AnyRes 动态多分辨率切割算法原理图 | 第 8 章 | 本书自绘：`docs/images/part3/anyres_dynamic_patching.png` | C / F | 可出版 | 已在正文补来源与 alt text；交付前复核 300dpi/字号 |
+| 表 8-1 | 表 | 图文样本类型、特征与适用任务表 | 第 8 章 | 本书整理 | C | 可出版 | Pair/Interleaved/Document Grounded 范式对照 |
+| 表 8-2 | 表 | 图像清洗策略与代价对照表 | 第 8 章 | 本书整理 | C | 可出版 | 阈值与成本需随终稿模型版本复核 |
+| 图 9-1 | 图 | 重标注与 OCR 双流线增强图 | 第 9 章 | 本书自绘：`docs/images/part3/recaptioning_ocr_pipeline.png` | C / F | 可出版 | 已在正文补来源与 alt text；交付前复核 300dpi/字号 |
+| 图 9-2 | 图 | 文档结构 Layout-to-Token 映射图 | 第 9 章 | 本书自绘：`docs/images/part3/document_structure_sample.png` | C / F | 可出版 | 已在正文补来源与 alt text；交付前复核 300dpi/字号 |
+| 表 9-1 | 表 | 重描述自动化生产梯队对比与优劣表 | 第 9 章 | 本书整理 | C | 可出版 | 成本与吞吐已标注截至 2026-06 的估算示例 |
+| 表 9-2 | 表 | 跨模态及高级文档识别 OCR 核心错误归因与修复阵列矩阵 | 第 9 章 | 本书整理 | C | 可出版 | 需最终统一表题样式 |
+| 图 10-1 | 图 | 音视频对齐分布式管线图 | 第 10 章 | 本书自绘：`docs/images/part3/av_sample_pipeline.png` | C / F | 可出版 | 已在正文补来源与 alt text；交付前复核 300dpi/字号 |
+| 图 10-2 | 图 | 自适应镜头边界检测与语义防泄漏架构图 | 第 10 章 | 本书自绘：`docs/images/part3/av_shot_boundary_hsv.png` | C / F | 可出版 | 已在正文补来源与 alt text；交付前复核 300dpi/字号 |
+| 图 10-3 | 图 | 大规模 ASR 提取与时间轴动态校准对比图 | 第 10 章 | 本书自绘：`docs/images/part3/asr_whisperx_comparison.png` | C / F | 可出版 | 已在正文补来源与 alt text；交付前复核 300dpi/字号 |
+| 图 10-4 | 图 | 跨模态时序校准与几何对齐架构图 | 第 10 章 | 本书自绘：`docs/images/part3/av_alignment_diagram.png` | C / F | 可出版 | 已在正文补来源与 alt text；交付前复核 300dpi/字号 |
+| 表 10-1 | 表 | 时序音视频数据缺陷类型与多层检测处置策略表 | 第 10 章 | 本书整理 | C | 可出版 | 需最终统一表题样式 |
+| 表 10-2 | 表 | 长时序音视频处理成本模型与降本策略 | 第 10 章 | 本书整理 | C | 可出版 | 成本占比已标注截至 2026-06 的估算示例 |
+| 表 10-3 | 表 | 音视频管线高频错误类型与修复策略 | 第 10 章 | 本书整理 | C | 可出版 | 错误日志为匿名化示例 |
+| 图 11-1 | 图 | 跨模态对齐的三级金字塔架构 | 第 11 章 | 本书自绘：`docs/images/part3/cross_modal_alignment_hierarchy.png` | C / F | 可出版 | 已在正文补来源与 alt text；交付前复核 300dpi/字号 |
+| 图 11-2 | 图 | 多模态融合样本设计图 | 第 11 章 | 本书自绘：`docs/images/part3/fusion_training_sample_design.png` | C / F | 可出版 | 已在正文补来源与 alt text；交付前复核 300dpi/字号 |
+| 表 11-1 | 表 | 三层异构对齐策略、成本特征与适用任务 | 第 11 章 | 本书整理 | C | 可出版 | 成本特征为工程示例口径 |
+| 表 11-2 | 表 | 五种难负样本挖掘策略对比 | 第 11 章 | 本书整理 | C | 可出版 | 需最终统一表题样式 |
+| 表 11-3 | 表 | 核心评价指标、误差来源与治理动作映射表 | 第 11 章 | 本书整理 | C | 可出版 | 需最终统一表题样式 |
+| 表 11-4 | 表 | 跨模态对齐高频错误类型与修复策略 | 第 11 章 | 本书整理 | C | 可出版 | 错误日志为匿名化示例 |
+| 图 12-1 | 图 | Synthetic Data Factory 流程图 | 第 12 章 | 新增 | D / F | 待绘制 | 必做 |
+| 图 13-1 | 图 | 偏好信号流转图 | 第 13 章 | 新增 | D / F | 待绘制 | 必做 |
+| 图 14-1 | 图 | 标注平台工作流图 | 第 14 章 | 新增 | D / F | 待绘制 | 必做 |
+| 图 15-1 | 图 | RAG 数据处理全景图升级版 | 第 15 章 | 改绘自 `docs/images/part5/图12_3` | E / F | 待绘制 | 样章核心图 |
+| 表 16-1 | 表 | 传统 RAG vs 视觉检索 RAG 对比表 | 第 16 章 | 新增 | E | 待绘制 | 必做 |
+| 图 17-1 | 图 | 线上反馈闭环图 | 第 17 章 | 新增 | E / F | 待绘制 | 必做 |
+| 图 18-1 | 图 | Mini-C4 案例流程图 | 第 18 章 | 改绘自 `docs/images/part6/图1_构建Mini_C4预训练集数据流水线图.png` | F | 待绘制 | |
+| 图 19-1 | 图 | 领域 SFT 数据工厂流程图 | 第 19 章 | 改绘自 `docs/images/part6/图2_构建垂直领域专家SFT数据流水线图.png` | F | 待绘制 | |
+| 图 20-1 | 图 | 财报多模态 RAG 总架构图 | 第 20 章 | 改绘自 `docs/images/part6/图6_多模态RAG企业财报助手数据流水线图.png` | F | 待绘制 | |
+
+## 四、第一篇图表交付清单
+
+| 图号 | 标题 | 文件路径 | 正文首次引用位置 | 来源 / 权限 | Alt text | 是否需高清源文件 |
+| --- | --- | --- | --- | --- | --- | --- |
+| 图 1-1 | 大模型时代数据工程职责重构图 | `docs/images/part1/data_engineering_roles_1775830393574.png` | `docs/zh/part1/ch01_data_change.md` §1.3.1 | 本书自绘；可随本书出版使用 | 大模型时代数据工程职责重构图，展示平台、数据、算法、标注、产品与合规角色之间的闭环接口 | 是；终稿前复核 300dpi、字号和矢量源 |
+| 图 1-2 | 全书十四篇制生命周期地图 | `docs/images/part1/data_lifecycle_map_1775830407042.png` | `docs/zh/part1/ch01_data_change.md` §1.4 | 本书自绘；可随本书出版使用 | 全书十四篇制生命周期地图，展示从总论、预训练、多模态、对齐、应用、平台、合规到项目实战的知识结构 | 是；终稿前复核 300dpi、字号和矢量源 |
+| 图 2-1 | 生命周期视角下的多维度质量分层架构 | `docs/images/part1/data_quality_hierarchy_1775835516841.png` | `docs/zh/part1/ch02_quality_framework.md` §2.2 | 本书自绘；可随本书出版使用 | 生命周期视角下的多维度质量分层架构，展示不同阶段质量指标权重从规模、多样性转向真实性、帮助性 | 是；终稿前复核 300dpi、字号和矢量源 |
+| 图 2-2 | 大模型数据缺陷与质量指标交叉映射图 | `docs/images/part1/defect_metric_radar_1775835533937.png` | `docs/zh/part1/ch02_quality_framework.md` §2.3 | 本书自绘；可随本书出版使用 | 大模型数据缺陷与质量指标交叉映射图，展示六类缺陷与准确度、一致性、多样性、覆盖度和可追溯性之间的关系 | 是；终稿前复核 300dpi、字号和矢量源 |
+| 图 2-3 | 数据评分卡驱动的自动截断与治理流 | `docs/images/part1/data_quality_gates_1775835548587.png` | `docs/zh/part1/ch02_quality_framework.md` §2.4 | 本书自绘；可随本书出版使用 | 数据评分卡驱动的自动截断与治理流，展示硬闸门、软闸门、人工复核和回滚动作 | 是；终稿前复核 300dpi、字号和矢量源 |
+| 图 3-1 | AI 原生数据栈五层架构 | `docs/images/part1/ai_data_stack_architecture.png` | `docs/zh/part1/ch03_data_stack.md` §3.2 | 本书自绘；可随本书出版使用 | AI 原生数据栈五层架构，展示采集接入、处理编排、存储索引、评测运营和治理安全层之间的数据流 | 是；终稿前复核 300dpi、字号和矢量源 |
+| 图 3-2 | 训练数据成本治理闭环图 | `docs/images/part1/cost_governance_loop.png` | `docs/zh/part1/ch03_data_stack.md` §3.3.3 | 本书自绘；可随本书出版使用 | 训练数据成本治理闭环图，展示预算规划、成本监控、ROI 评估、优化决策和预算复盘的循环 | 是；终稿前复核 300dpi、字号和矢量源 |
+
+## 五、第二篇图表交付清单
+
+| 图号 / 表号 | 标题 | 文件路径 | 正文首次引用位置 | 来源 / 权限 | Alt text | 是否需高清源文件 |
+| --- | --- | --- | --- | --- | --- | --- |
+| 图 4-1 | 预训练数据源分层地图 | `docs/images/part2/pretrain_data_source_map.png` | `docs/zh/part2/ch04_data_sources.md` §4.2 | 本书自绘；可随本书出版使用 | 预训练数据源分层地图，展示开放网页、论坛问答、百科、代码、学术论文、书籍、企业内部数据和用户反馈数据的质量与合规位置 | 是；终稿前复核 300dpi、字号和矢量源 |
+| 图 4-2 | 数据采集与权属存证流程图 | `docs/images/part2/data_ingestion_provenance_chain.png` | `docs/zh/part2/ch04_data_sources.md` §4.3.3 | 本书自绘；可随本书出版使用 | 数据采集与权属存证流程图，展示来源触达、采集、解析、清洗、入库和审计记录之间的链路 | 是；终稿前复核 300dpi、字号和矢量源 |
+| 表 4-1 | 数据源类型、许可与风险矩阵 | 正文表格 | `docs/zh/part2/ch04_data_sources.md` §4.2.2 | 本书整理；可随本书出版使用 | 不适用（正文表格） | 否 |
+| 表 4-2 | 数据配比策略与业务目标对应矩阵 | 正文表格 | `docs/zh/part2/ch04_data_sources.md` §4.2.3 | 本书整理；可随本书出版使用 | 不适用（正文表格） | 否 |
+| 图 5-1 | 清洗与去污染全景流程图 | `docs/images/part2/cleaning_pipeline_overview.png` | `docs/zh/part2/ch05_cleaning_dedup.md` §5.2 | 本书自绘；可随本书出版使用 | 清洗与去污染全景流程图，展示规则过滤、模型评分、去重、PII 脱敏、去污染和人工抽检的顺序关系 | 是；终稿前复核 300dpi、字号和矢量源 |
+| 图 5-2 | 质量过滤漏斗与抽检闭环图 | `docs/images/part2/quality_filter_funnel_loop.png` | `docs/zh/part2/ch05_cleaning_dedup.md` §5.6.2 | 本书自绘；可随本书出版使用 | 质量过滤漏斗与抽检闭环图，展示规则过滤、模型评分、去重、人工抽检和规则回写之间的循环关系 | 是；终稿前复核 300dpi、字号和矢量源 |
+| 表 5-1 | 常见缺陷、检测方法与代价表 | 正文表格 | `docs/zh/part2/ch05_cleaning_dedup.md` §5.7 | 本书整理；可随本书出版使用 | 不适用（正文表格） | 否 |
+| 表 5-2 | 清洗动作对训练效果影响对照 | 正文表格 | `docs/zh/part2/ch05_cleaning_dedup.md` §5.7 | 本书整理；可随本书出版使用 | 不适用（正文表格） | 否 |
+| 表 5-3 | 轻量级清洗方案最小可行组合 | 正文表格 | `docs/zh/part2/ch05_cleaning_dedup.md` §5.9.1 | 本书整理；可随本书出版使用 | 不适用（正文表格） | 否 |
+| 图 6-1 | LLM 训练输入管道分层架构 | `docs/images/part2/training_input_pipeline_layers.png` | `docs/zh/part2/ch06_tokenization_loading.md` §6.5 | 本书自绘；可随本书出版使用 | 训练输入管道分层图，展示分词、序列化、混采、Packing、DataLoader 和 GPU 馈送之间的顺序关系 | 是；终稿前复核 300dpi、字号和矢量源 |
+| 图 6-2 | 吞吐瓶颈诊断流程图 | `docs/images/part2/io_bottleneck_diagnosis_flow.png` | `docs/zh/part2/ch06_tokenization_loading.md` §6.4.2 | 本书自绘；可随本书出版使用 | 吞吐瓶颈诊断流程图，展示从 GPU 利用率异常到磁盘 I/O、CPU 预处理和 PCIe 传输排查的决策路径 | 是；终稿前复核 300dpi、字号和矢量源 |
+| 表 6-1 | 数据格式、压缩与访问模式对照表 | 正文表格 | `docs/zh/part2/ch06_tokenization_loading.md` §6.2.3 | 本书整理；可随本书出版使用 | 不适用（正文表格） | 否 |
+| 表 6-2 | 采样与混采策略收益对照表 | 正文表格 | `docs/zh/part2/ch06_tokenization_loading.md` §6.3.2 | 本书整理；可随本书出版使用 | 不适用（正文表格） | 否 |
+| 图 7-1 | 数据运营飞轮图 | `docs/images/part2/data_operations_flywheel.png` | `docs/zh/part2/ch07_data_operations.md` §7.1.3 | 本书自绘；可随本书出版使用 | 数据运营飞轮图，展示数据生产、模型评估、根因分析、规则回写和资产复用之间的循环关系 | 是；终稿前复核 300dpi、字号和矢量源 |
+| 图 7-2 | 数据评估闭环图 | `docs/images/part2/data_evaluation_loop.png` | `docs/zh/part2/ch07_data_operations.md` §7.4.1 | 本书自绘；可随本书出版使用 | 数据评估闭环图，展示抽样评估、指标异常、根因排查、治理动作和规则更新之间的闭环 | 是；终稿前复核 300dpi、字号和矢量源 |
+| 表 7-1 | 评估指标与治理动作映射表 | 正文表格 | `docs/zh/part2/ch07_data_operations.md` §7.2.4 | 本书整理；可随本书出版使用 | 不适用（正文表格） | 否 |
+| 表 7-2 | 版本迭代记录模板表 | 正文表格 | `docs/zh/part2/ch07_data_operations.md` §7.3.4 | 本书整理；可随本书出版使用 | 不适用（正文表格） | 否 |
+
+## 六、第三篇图表交付清单
+
+| 图号 / 表号 | 标题 | 文件路径 | 正文首次引用位置 | 来源 / 权限 | Alt text | 是否需高清源文件 |
+| --- | --- | --- | --- | --- | --- | --- |
+| 图 8-1 | 多模态图文数据工程全景图 | `docs/images/part3/multimodal_data_panorama.png` | `docs/zh/part3/ch08_multimodal_image.md` §8.1.3 | 本书自绘；可随本书出版使用 | 图文数据工程全景图，展示 DOM 抽取、图片下载、格式解析、过滤、语义对齐、重标注和序列拼装之间的流程 | 是；终稿前复核 300dpi、字号和矢量源 |
+| 图 8-2 | 图像语义对齐与过滤流程图 | `docs/images/part3/image_semantic_alignment_flow.png` | `docs/zh/part3/ch08_multimodal_image.md` §8.4.2 | 本书自绘；可随本书出版使用 | 图像语义对齐与过滤流程图，展示质量过滤、CLIP 打分、重标注、动态切分和训练池入库之间的路径 | 是；终稿前复核 300dpi、字号和矢量源 |
+| 图 8-3 | AnyRes 动态多分辨率切割算法原理图 | `docs/images/part3/anyres_dynamic_patching.png` | `docs/zh/part3/ch08_multimodal_image.md` §8.5.1 | 本书自绘；可随本书出版使用 | AnyRes 动态多分辨率切割算法原理图，展示全景图被切成局部块并与全局缩略图共同输入视觉编码器 | 是；终稿前复核 300dpi、字号和矢量源 |
+| 表 8-1 | 图文样本类型、特征与适用任务表 | 正文表格 | `docs/zh/part3/ch08_multimodal_image.md` §8.2.3 | 本书整理；可随本书出版使用 | 不适用（正文表格） | 否 |
+| 表 8-2 | 图像清洗策略与代价对照表 | 正文表格 | `docs/zh/part3/ch08_multimodal_image.md` §8.5.2 | 本书整理；可随本书出版使用 | 不适用（正文表格） | 否 |
+| 图 9-1 | 重标注与 OCR 双流线增强图 | `docs/images/part3/recaptioning_ocr_pipeline.png` | `docs/zh/part3/ch09_recaptioning_ocr.md` §9.2.2 | 本书自绘；可随本书出版使用 | 重标注与 OCR 双流线增强图，展示视觉重描述、OCR 结构提取、BBox 注入和混合监督格式之间的关系 | 是；终稿前复核 300dpi、字号和矢量源 |
+| 图 9-2 | 文档结构 Layout-to-Token 映射图 | `docs/images/part3/document_structure_sample.png` | `docs/zh/part3/ch09_recaptioning_ocr.md` §9.3.1 | 本书自绘；可随本书出版使用 | 文档结构 Layout-to-Token 映射图，展示文档页面被版面检测、OCR、公式解析和坐标标注转换为层级文本序列 | 是；终稿前复核 300dpi、字号和矢量源 |
+| 表 9-1 | 重描述自动化生产梯队对比与优劣表 | 正文表格 | `docs/zh/part3/ch09_recaptioning_ocr.md` §9.2.1 | 本书整理；可随本书出版使用 | 不适用（正文表格） | 否 |
+| 表 9-2 | 跨模态及高级文档识别 OCR 核心错误归因与修复阵列矩阵 | 正文表格 | `docs/zh/part3/ch09_recaptioning_ocr.md` §9.4.2 | 本书整理；可随本书出版使用 | 不适用（正文表格） | 否 |
+| 图 10-1 | 音视频对齐分布式管线图 | `docs/images/part3/av_sample_pipeline.png` | `docs/zh/part3/ch10_video_audio.md` §10.2 | 本书自绘；可随本书出版使用 | 音视频对齐分布式管线图，展示原始视频被拆分为视觉轨、音频轨和文本轨，并通过时间对齐引擎生成 JSONL 样本 | 是；终稿前复核 300dpi、字号和矢量源 |
+| 图 10-2 | 自适应镜头边界检测与语义防泄漏架构图 | `docs/images/part3/av_shot_boundary_hsv.png` | `docs/zh/part3/ch10_video_audio.md` §10.2.1 | 本书自绘；可随本书出版使用 | 自适应镜头边界检测图，展示 HSV 差分、光流差分和双阈值路由如何共同判断镜头切分点 | 是；终稿前复核 300dpi、字号和矢量源 |
+| 图 10-3 | 大规模 ASR 提取与时间轴动态校准对比图 | `docs/images/part3/asr_whisperx_comparison.png` | `docs/zh/part3/ch10_video_audio.md` §10.2.2 | 本书自绘；可随本书出版使用 | ASR 提取与时间轴校准对比图，展示传统 ASR 漂移、WhisperX 校准和词级时间戳对齐结果 | 是；终稿前复核 300dpi、字号和矢量源 |
+| 图 10-4 | 跨模态时序校准与几何对齐架构图 | `docs/images/part3/av_alignment_diagram.png` | `docs/zh/part3/ch10_video_audio.md` §10.2.3 | 本书自绘；可随本书出版使用 | 跨模态时序校准图，展示视觉帧、音频波形和文本 Token 如何通过同一时间轴锚点绑定 | 是；终稿前复核 300dpi、字号和矢量源 |
+| 表 10-1 | 时序音视频数据缺陷类型与多层检测处置策略表 | 正文表格 | `docs/zh/part3/ch10_video_audio.md` §10.3.2 | 本书整理；可随本书出版使用 | 不适用（正文表格） | 否 |
+| 表 10-2 | 长时序音视频处理成本模型与降本策略 | 正文表格 | `docs/zh/part3/ch10_video_audio.md` §10.4.3 | 本书整理；可随本书出版使用 | 不适用（正文表格） | 否 |
+| 表 10-3 | 音视频管线高频错误类型与修复策略 | 正文表格 | `docs/zh/part3/ch10_video_audio.md` §10.6.6 | 本书整理；可随本书出版使用 | 不适用（正文表格） | 否 |
+| 图 11-1 | 跨模态对齐的三级金字塔架构 | `docs/images/part3/cross_modal_alignment_hierarchy.png` | `docs/zh/part3/ch11_cross_modal_alignment.md` §11.2.2 | 本书自绘；可随本书出版使用 | 跨模态对齐三级金字塔，展示对象级、片段级和文档级对齐之间的层级关系 | 是；终稿前复核 300dpi、字号和矢量源 |
+| 图 11-2 | 多模态融合样本设计图 | `docs/images/part3/fusion_training_sample_design.png` | `docs/zh/part3/ch11_cross_modal_alignment.md` §11.3.1 | 本书自绘；可随本书出版使用 | 多模态融合样本设计图，展示图片、音频、文本池如何通过 JSONL 和 Placeholder 映射为统一训练样本 | 是；终稿前复核 300dpi、字号和矢量源 |
+| 表 11-1 | 三层异构对齐策略、成本特征与适用任务 | 正文表格 | `docs/zh/part3/ch11_cross_modal_alignment.md` §11.2.2 | 本书整理；可随本书出版使用 | 不适用（正文表格） | 否 |
+| 表 11-2 | 五种难负样本挖掘策略对比 | 正文表格 | `docs/zh/part3/ch11_cross_modal_alignment.md` §11.3.3 | 本书整理；可随本书出版使用 | 不适用（正文表格） | 否 |
+| 表 11-3 | 核心评价指标、误差来源与治理动作映射表 | 正文表格 | `docs/zh/part3/ch11_cross_modal_alignment.md` §11.4.1 | 本书整理；可随本书出版使用 | 不适用（正文表格） | 否 |
+| 表 11-4 | 跨模态对齐高频错误类型与修复策略 | 正文表格 | `docs/zh/part3/ch11_cross_modal_alignment.md` §11.6.6 | 本书整理；可随本书出版使用 | 不适用（正文表格） | 否 |
+
+## 七、图表交付要求
+
+- 每张图都要有唯一编号、标题和一句结论。
+- 每张图都要标明来源：新增、改绘、复用。
+- 复用线上图时，检查分辨率、字号和纸书排版可读性。
+- 表格标题要能独立表达结论，不依赖正文解释。
+
+## 八、维护规则
+
+- 图表编号由资料编辑统一维护。
+- 章节作者不能自行跳号。
+- 图表状态每周例会前更新一次。