快速摘要： UltraData 是由清华大学自然语言处理实验室、面壁智能与 OpenBMB 社区联合推出的开源数据治理平台，核心思路是将大模型训练数据划分为 L0（原始）→ L1（过滤）→ L2（精筛）→ L3（合成增强）→ L4（编排）五个层级，配合全链路工具进行系统化处理。 平台一次性开源了 2.4T Tokens 的高质量数据以及 4 款数据治理工具，其中 UltraData-Math 是目前规模最大的开源 L3 数学合成数据集，在 MATH、GSM8K 等基准上全面超越同类开源数据。实验证明，按 L1→L2→L3 分级训练比一锅端混合训练平均提升 1.49 个百分点。往下看，莫潇羽@无忆研习社会带你逐层拆解每个层级的原理、工具用法和实操路径。
一、为什么需要"数据分级治理"？
回顾人工智能的发展脉络，我们大致经历了四个阶段——符号学习、有监督学习、无监督学习、反馈学习。在这些阶段中，主流范式一直是"数据驱动学习"（Data-Driven Learning），简单来说就是"数据越多，模型越强"。早期的 GPT-3 用了约 300B Tokens 的训练数据，而 Llama 2 将这个数字提升到了 2T Tokens，最新一代的模型甚至动辄使用 10T 级别以上的训练数据。这种"数据规模驱动模型能力"的路线在过去几年取得了巨大成功。
但这条路正在遇到瓶颈。
过去几年，大模型训练对公开数据的消耗速度远超数据产出速度。Common Crawl 是目前最大的公开网页爬取项目，每月都会产出一个新的快照，但真正高质量、无噪声、适合训练的内容占比其实非常有限。据估算，整个互联网的高质量文本数据总量大约在数十万亿 Tokens 的量级，而大模型训练对数据的消耗已经逼近这个上限。当公开数据资源逐渐逼近枯竭点时，"靠量取胜"的粗放路线已经走不通了。
与此同时，大模型的训练流程也在分化，整个训练周期已经不再是"一股脑喂数据就完事了"的简单过程。预训练阶段需要海量通用数据来注入世界知识，让模型建立起对语言和世界的基本理解；微调阶段（SFT）需要高质量的指令对齐数据，教会模型按照人类指令行事；强化学习阶段（RL）又需要精心标注的偏好反馈数据，让模型学会判断什么是"好回答"什么是"坏回答"。更进一步，近期流行的 Mid-Training（中期训练）阶段还需要特定领域的高密度知识数据来注入专业能力。不同阶段对数据的质量、数量、分布特征有完全不同的要求——用同一套数据"一刀切"地喂给所有阶段，效率极低。
此外还有一个经常被忽视的问题：成本控制。数据治理不是免费的，使用大模型打标一条数据可能需要零点几分钱，看起来不多，但乘以数十亿条数据之后就是一笔巨大的开支。如何在有限的预算内最大化数据治理的收益，是每一个做大模型的团队都必须面对的现实问题。
于是，一种新的范式正在浮现：数据-模型协同演进（Data-Model Co-Evolution）。模型能力增强后，反过来帮助筛选和生成更高质量的数据；高质量数据又进一步优化模型——形成正向循环。
UltraData 的 L0-L4 分级治理体系，正是为这种新范式而设计的。 它的核心理念可以概括为三句话：
- 从"粗放式规模扩张"转向"精细化数据治理"，挖掘存量数据的深层价值
- 根据模型训练的不同阶段，构建差异化的数据供给策略
- 在治理成本与模型收益之间找到动态平衡——前期用轻量方法、后期用精细方法，把好钢用在刀刃上
莫潇羽在这里要特别提醒一点：这套体系不是"一次性清洗完就完了"的静态流水线，而是一个可以随着模型迭代不断演进的动态系统。你的模型变强了，就可以用更强的模型去做 L2 精筛和 L3 合成，产出更好的数据再喂回去。这种"飞轮效应"才是它最有价值的地方。
二、L0-L4 五级数据体系：逐层拆解
接下来，莫潇羽@无忆研习社带你逐层拆解这五个层级的定义、处理方式和应用场景。理解了这五层，你就理解了 UltraData 的整个逻辑框架。
2.1 L0 — 原始数据（Raw Data）
定义： 未经任何实质性处理的初始数据，通常是 PB 级别的规模。
典型来源： Common Crawl 网页快照、PDF 文档、学术论文原始文件等。
数据特征： 包含大量噪声（广告、导航栏、乱码）、重复内容、格式不统一。这些数据不能直接用于训练，但它们是整个治理流程的"原矿石"。
处理重点： L0 层的核心工作是解析（Parsing）。这一步看似简单，实则直接决定了后续所有层级的数据质量上限。想象一下，如果解析阶段把一段完整的证明过程丢失了一半，或者把一个关键公式解析成了乱码，那无论后面做多么精细的筛选和合成，都无法挽回这个损失。
对于网页数据，解析的主要挑战在于 HTML 结构的多样性。不同网站的页面结构差异巨大，正文内容可能嵌套在各种不同层级的 div、article、section 标签中，而广告、导航栏、页脚、评论区等非正文内容又需要被准确地过滤掉。现有的通用解析工具（如 trafilatura、readability）虽然能处理大部分常见页面，但在遇到复杂布局或专业内容（特别是包含数学公式的页面）时，表现往往不尽如人意。
对于数学内容，挑战更大。互联网上的数学公式使用了多种渲染标准：MathML 是 W3C 推荐的标准格式，但很多网站使用 KaTeX 或 MathJax 来渲染 LaTeX 公式，还有一些老旧网站使用 AsciiMath 格式。这些格式在 HTML 源代码中的表示方式完全不同，一个通用的文本提取工具很可能会把精心排版的公式提取成一堆无意义的字符。
UltraData 在 L0 层提供了 UltraData-Parser 工具。以数学场景为例，团队基于 magic-html 开发了 UltraData-Math-Parser，它的特点是结合了 w3m 布局保留渲染和多级回退策略——也就是说，当一种解析方式失败时，会自动尝试下一种，确保尽可能多地保留原始数学公式的完整性。具体的回退链路大致如下：首先尝试直接提取 LaTeX 源码（如果页面使用 MathJax/KaTeX 渲染），如果失败则尝试将 MathML 标签转换为 LaTeX，再失败则尝试解析 AsciiMath 格式，最后使用 w3m 的文本渲染作为兜底方案。这种多级回退的设计保证了在各种极端情况下都能尽量保留有效信息。
为什么解析这么重要？团队做了一组对比实验：在 MiniCPM-1.2B 上使用 100B Tokens 训练，UltraData-Math-Parser 在 MATH 数据集上拿到了 28.72 分，而常用的 trafilatura 只有 28.08 分，magic-html 更是低至 26.58 分。也就是说，光是把解析做好，就能在下游任务上带来将近 2 个百分点的提升。
如果你自己有一批网页数据需要处理，可以这样使用：
# 加载 DCAD-2000 多语言数据集示例
from datasets import load_dataset
# 加载英文子集
data = load_dataset("openbmb/DCAD-2000", name="eng_Latn", split="train")
# 查看数据结构
print(data[0])对于数学场景，UltraData-Math-Parser 的在线 Demo 已经部署在 HuggingFace Spaces 上，你可以直接在浏览器里粘贴一段包含数学公式的网页 HTML，观察解析效果，无需本地部署。
2.2 L1 — 过滤数据（Filtered Data）
定义： 经过启发式规则过滤和去重处理后的基础清洗数据。
处理方式： 这一层主要依赖规则驱动的方法，成本低、速度快，适合大规模批量处理。启发式规则的核心思想是：虽然我们无法用简单规则判断一篇文档的"语义质量"，但我们可以判断它是否明显"不正常"。一篇正常的文章不会有 80% 的字符都是特殊符号，也不会只有三个词然后重复了一百遍。通过这些"排除法"，可以快速且廉价地淘汰大量明显低质的文档。
具体操作包括：
- 启发式规则过滤： 去除长度异常（过短或过长）的文档、特殊字符比例过高的文档、重复词比例过高的文档等。比如一个典型的规则组合可能是：文档词数少于 50 或大于 100000 则过滤，字符重复率超过 30% 则过滤，特殊字符占比超过 20% 则过滤。这些阈值需要根据你的数据源特点来调整，没有放之四海而皆准的标准。
- 文档级去重： 使用 MinHash（最小哈希）等算法在文档层面进行近似去重。MinHash 的基本原理是将每篇文档转化为一个固定长度的"指纹"（signature），然后通过比较指纹的相似度来判断两篇文档是否高度相似。相比逐字比对，这种方法的计算效率高出几个数量级，可以在合理时间内处理数十亿篇文档。通常把 Jaccard 相似度阈值设为 0.8 左右，即两篇文档的内容有 80% 以上重叠就认为是重复。
- 语言识别： 使用语言检测工具（如 fastText 的 LID 模型）标注每篇文档的语言，过滤掉语言识别置信度过低的文档。这一步的主要目的是去除乱码、混合语言或机器翻译质量极差的内容。在多语言数据集中，语言识别的准确性尤其重要——如果一篇中文文档被错误地标注为日文并混入了日文数据子集，对模型训练就会产生干扰。
- 敏感内容过滤： 去除包含不良信息的文档，这在构建公开可用的训练数据集时尤其重要。
数据特征： 格式基本规范，但语义质量参差不齐——有些文档虽然格式合规，但内容质量并不高（比如灌水论坛帖子、低质量博客、自动生成的 SEO 页面）。L1 数据可以理解为"去掉了明显的垃圾，但还没有挑出真正的好东西"。
代表数据集： FineWeb、DCAD-2000。
以 DCAD-2000 为例，这是 OpenBMB 社区构建的一个大规模多语言语料库，覆盖了 2282 种语言和 159 种文字系统，包含 86.3 亿篇文档，总量达 46.72TB。它的一大创新点是把数据清洗任务重新定义为异常检测问题——对每篇文档提取 8 个统计特征（词数、字符重复率、词重复率、特殊字符比例、停用词比例、敏感词比例、语言识别分数、困惑度分数），然后用孤立森林（Isolation Forest）等异常检测算法自动识别和移除低质量内容。这种方法比固定阈值的传统方法更适合多语言场景，因为不同语言的文档特征分布差异很大，一套固定阈值很难通用。
UltraData 在 L1 层提供了 UltraData-Cleaner 工具，支持动态组合各种启发式规则过滤算子和去重算子。你可以根据自己的数据特点灵活配置清洗流水线。
2.3 L2 — 精筛数据（Selected Data）
定义： 通过模型打分和标签标注筛选出的高信息密度数据。
处理方式： 这一层开始引入模型驱动的方法，这也是从 L1 到 L2 最本质的区别。启发式规则只能判断"这篇文档是不是垃圾"，而模型驱动的方法可以判断"这篇文档的质量有多高"。
这里涉及到一个关键的技术问题：为什么不直接用大模型来过滤整个语料库？原因很简单——成本。假设你有 100 亿篇文档需要过滤，每篇文档用 GPT-4 级别的大模型处理一次大约需要零点几分钱（取决于文档长度），算下来总成本可能高达数百万甚至上千万元。这个成本对大多数团队来说是不可接受的。
所以 UltraData 采用了一种更聪明的策略——"蒸馏过滤"。具体流程通常是：
- 种子数据标注： 先用能力较强的大模型（如 GPT-4 级别）对一批种子样本打质量分。种子样本的数量通常在几千到几万条，这个规模下的标注成本是可控的。
- 轻量分类器蒸馏： 把大模型的打分结果蒸馏到一个轻量级的 Embedding 分类器。"蒸馏"这个概念在深度学习中很常见，简单来说就是用大模型的输出作为"软标签"来训练一个小模型，让小模型学会模仿大模型的判断。这里的小模型通常是 BERT 级别的文本编码器加一个简单的分类头，参数量只有几亿甚至几千万，推理速度比大模型快上百倍。
- 全量过滤： 用这个轻量分类器对整个 L1 语料库进行高效打分，筛选出高质量子集。由于分类器本身非常轻量，在 GPU 上可以达到每秒处理数千甚至上万篇文档的速度，处理 100 亿篇文档可能只需要几天时间。
这种"先用大模型标注小样本、再蒸馏成小模型做大规模过滤"的策略，在成本和效果之间找到了很好的平衡。这也是目前业界比较通用的做法——包括 FineWeb-edu、Nemotron-CC 等知名开源数据集，都采用了类似的技术路线。
种子数据的选择至关重要。 如果你的种子数据不够多样化，或者标注的质量维度不够全面，蒸馏出来的分类器可能会有偏差。比如如果种子数据都是学术论文风格的文本，分类器可能会倾向于给所有学术风格的文本打高分，而忽略了一些质量同样很高但风格不同的内容（比如优质的技术博客或教程）。UltraData 在这方面的建议是，种子数据要尽量覆盖你目标语料库中的各种文档类型和风格。
数据特征： 领域明确、逻辑连贯、信息密度高，对模型能力的提升贡献显著。
代表数据集： Ultra-FineWeb、FineWeb-edu。
Ultra-FineWeb 是 OpenBMB 社区产出的一个高质量英文预训练数据集，在 HuggingFace 上累计下载超过 40 万次，曾连续两周登顶 HuggingFace Datasets Trending 榜单。它的最新版本 Ultra-FineWeb-en-v1.4 包含了 2.2T Tokens 的全量开源数据，构建在 FineWeb-v1.4 的基础上，纳入了 2024 年 4 月至 2025 年 6 月的 CommonCrawl 最新快照，确保知识的时效性。
UltraData 在 L2 层提供了 UltraData-Selector 工具，支持通过模型打标筛选高价值样本。在实际操作中，你需要准备一小批高质量种子数据（通常几千到几万条），让大模型对它们打分，然后用这些打分结果训练你自己的质量分类器。
下面是一个使用 Ultra-FineWeb 分类器的简化示例：
# Ultra-FineWeb 质量分类器使用示例
from transformers import AutoTokenizer, AutoModelForSequenceClassification
import torch
# 加载 Ultra-FineWeb 分类器
model_name = "openbmb/Ultra-FineWeb-classifier"
tokenizer = AutoTokenizer.from_pretrained(model_name)
model = AutoModelForSequenceClassification.from_pretrained(model_name)
# 对文本进行质量打分
text = "这里是你要评估质量的文本内容..."
inputs = tokenizer(text, return_tensors="pt", truncation=True, max_length=512)
with torch.no_grad():
outputs = model(**inputs)
score = outputs.logits.softmax(dim=-1)
print(f"质量得分: {score}")2.4 L3 — 合成与增强数据（Refined Data）
定义： 经过改写、合成、人工标注等深度处理的结构化数据。
这是整个分级体系中质量最高、成本也最高的一层。L3 数据的特点是语义清晰、结构完整、推理链条可追溯。
处理方式： UltraData 在 L3 层提供了 UltraData-Generator 工具，支持多种形式的数据生成：
- 问答改写： 把非结构化的知识文本改写为问答对格式
- 多人对话生成： 将知识点组织成多轮师生对话或讨论形式
- 多风格重写： 把同一内容用不同写作风格（学术、通俗、教材）重新表达
- 知识支撑教材生成： 以原始知识为基础，生成结构化的教学材料
以数学场景为例，UltraData-Math-Generator 会把 L2 层筛选出的高质量数学文本，改写为包含详细推理步骤的问答对、多轮讨论、结构化教材等多种形式。这样做的好处是，模型在训练时不仅能学到数学知识本身，还能学到如何组织和表达数学推理过程。
数据特征： 语义清晰、质量优异，适配 Mid-Training（中期训练）、SFT（监督微调）、RL（强化学习）等高阶训练阶段。
代表数据集： UltraChat、UltraFeedback、UltraData-Math-L3。
这里要特别说一下 UltraChat 和 UltraFeedback 这两个数据集在开源社区的影响力。根据 HuggingFace 的统计，UltraChat 被全球 500 多个模型使用过，在使用量排名中位列第 7；UltraFeedback 更是被 1000 多个模型使用，排名第 4。这说明高质量 L3 数据的价值已经得到了广泛验证。
2.5 L4 — 编排数据（Organized Data）
定义： 经过整理、可信校验和统一编排的有序数据。
数据特征： 结构清晰、可检索、可溯源，直接支持 RAG（检索增强生成）等应用场景。
代表数据集： Wikidata 知识图谱、UltraData-Arxiv 学术论文库等。
L4 层的重点不是"提升质量"，而是"组织结构"。经过前面四层处理的数据已经足够高质量了，L4 要做的是把这些数据按照统一的格式和结构进行编排，使其可以被高效地检索和引用。这一步的重要性在 RAG 应用中体现得最为明显：当用户提出一个问题时，系统需要快速从海量知识库中检索出最相关的内容，然后交给大模型生成回答。如果知识库的数据没有经过良好的编排，检索效果就会大打折扣。
具体来说，L4 层的编排工作包括以下几个方面：统一数据格式（比如把所有文档转换为统一的 JSON Schema），构建索引结构（比如为文档添加标题、摘要、关键词等元数据），进行可信校验（比如检查文档中引用的数据来源是否可靠），以及建立文档之间的关联关系（比如标注引用关系、主题分类等）。这些工作看似琐碎，但对于下游应用的效果至关重要。
UltraData 在 L4 层提供了 UltraData-Organizer 工具，用于构建结构化知识库并进行可信校验。如果你在做 RAG 系统，L4 层的数据可以直接作为你的知识库底座。
值得一提的是，L0-L4 这五个层级并不是严格的线性流程。 在实际操作中，你完全可以根据需要跳过某些层级或反复迭代。比如如果你的原始数据已经是结构化的（如 Wikidata），可以跳过 L0-L1 直接从 L2 开始；如果你发现 L3 合成的数据质量不够理想，可以回到 L2 重新调整种子数据的选择。灵活运用比机械照搬更重要。
三、分级治理的实验验证：数据确实有优劣之分
"分级有没有用"这个问题，莫潇羽@无忆研习社觉得光说理论没有说服力，还是要看实验数据。UltraData 团队在这方面做了非常充分的验证，而且实验设计很有参考价值——他们提出了一种"快速验证策略"，可以在有限的计算预算内快速判断数据质量，这对于资源有限的团队特别有借鉴意义。
3.1 L1 vs L2 vs L3：逐级提升
团队在英文网页、中文网页、数学、代码四个领域选择了 L1 到 L3 的代表性数据，在 MiniCPM-1.2B 模型上分别采样 10B Tokens 进行训练和评测。
为什么选 MiniCPM-1.2B 做验证？ 这是面壁智能与清华大学联合开发的一个端侧小语言模型，只有 12 亿非词嵌入参数。它采用了深而窄的网络架构（相比同规模模型使用了更多层但每层更窄），加上共享输入输出层等效率优化技巧，在公开评测中表现可以媲美 Mistral-7B 甚至超越 Llama2-13B。用它做数据质量验证有三个好处：一是训练成本可控，10B Tokens 的训练在单机多卡上可以在几天内完成；二是模型足够敏感，数据质量的微小差异都能在评测结果中体现出来；三是它的训练策略（WSD 学习率调度器）使得训练过程非常稳定，减少了因训练不稳定导致的评测噪声。
为什么选 10B Tokens？ 这是一个精心选择的"甜点"——既足够让模型学到数据的主要特征，又不会因为训练过久而让不同数据源之间的差异被稀释。如果你也想做类似的数据质量验证，10B Tokens 是一个很好的起点。
实验结果非常清晰：在所有四个领域中，L3 数据训练的模型 > L2 数据训练的模型 > L1 数据训练的模型。这个严格的层级关系没有例外。
下面是一个简化的实验对比示意（基于论文数据整理）：
数据层级 英文网页 中文网页 数学 代码
─────────────────────────────────────────────
L1 基准线 基准线 基准线 基准线
L2 ↑ 提升 ↑ 提升 ↑ 提升 ↑ 提升
L3 ↑↑ 显著 ↑↑ 显著 ↑↑ 显著 ↑↑ 显著这意味着，即使在训练预算受限（10B Tokens）的验证设置下，分级治理依然能产生清晰且稳定的性能提升信号。对于资源有限的团队来说，这是个好消息——你不需要海量数据，只要数据质量足够高，就能获得显著的模型提升。
3.2 混合训练 vs 分级训练：怎么喂数据也有讲究
除了验证"数据质量有差异"，团队还进一步验证了"数据使用顺序是否重要"。这个问题在实践中非常关键——假设你手头同时有 L1、L2、L3 的数据，是应该把它们混在一起喂给模型，还是应该按照某种顺序分阶段喂？
他们设计了两组对比实验，都在 MiniCPM-1.2B 上从头训练 120B Tokens，混合了四个领域的数据（50% 英文网页 + 25% 中文网页 + 7% 数学 + 18% 代码）。这个数据配比反映了一个通用大模型的典型训练需求——以英文为主，中文次之，再加上一定比例的数学和代码来增强推理和编程能力。
两种策略的具体设置如下：
- 混合训练（Mix Training）： 把 L1、L2、L3 数据按 1:1:1 的比例混在一起，形成一个统一的数据池，然后在这个池子里随机采样训练 120B Tokens。这种方式的好处是简单——不需要额外的调度逻辑，坏处是模型从第一步开始就同时接触到了低质量和高质量的数据。
- 分级训练（Tiered Training）： 分三个阶段，先用 40B Tokens 的 L1 数据训练，再用 40B Tokens 的 L2 数据训练，最后用 40B Tokens 的 L3 数据训练。这种方式模拟了"先打基础、再精进"的学习路径——先用大量基础数据让模型建立初步的语言理解能力，然后逐步引入更高质量的数据来提升模型的深层能力。
结果如何？分级训练在整体平均性能上比混合训练高出 1.49 个百分点，并且在英文、中文、数学、代码四个领域全面胜出。不要小看这 1.49 个百分点——在大模型评测的语境下，这已经是一个相当显著的提升了，特别是考虑到两种策略使用的总数据量完全相同，差异纯粹来自于数据的组织方式。
更有趣的是训练过程中的动态表现。在训练前期（前 40B Tokens），两种策略的性能曲线几乎重合，都从约 24.7pp 提升到约 28.3pp。这很好理解——在训练的早期阶段，模型还在学习最基础的语言规律（比如常见词组、语法结构），这些基础知识在 L1 和混合数据中都大量存在，所以差异不大。
差距出现在训练后期——分级训练策略在后期引入了 L2 和 L3 的高质量数据，性能从 28.35pp 持续上升到 31.66pp，增幅达 3.31pp。而混合训练的增长明显放缓，同期仅从 28.26pp 提升到 30.17pp，增幅只有 1.91pp。也就是说，分级训练在后半程的学习效率比混合训练高出了约 70%。
这个结果的实践意义非常明确：在训练后期喂入高质量数据的效果，远好于从头到尾都混着喂。 这其实和人类的学习过程很像——你不会在刚学数学的时候就去读研究生的课本，而是先从加减乘除开始，逐步过渡到代数、几何、微积分。模型训练也是一样，先用"粗粮"打好基础，再用"细粮"提升深层能力。
莫潇羽在无忆研习社的日常实践中也观察到类似的规律——做任何事情都有"先粗后细"的节奏，模型训练也不例外。如果你的训练预算有限，一个实用的策略是：在训练的最后 10-20% 使用你能获得的最高质量数据，往往能获得超出预期的性能提升。
四、UltraData-Math：数学领域的深度实践
前面讲的是通用框架，下面我们聚焦到一个具体的垂直领域——数学，来看看 UltraData 的分级治理体系是怎么在实际场景中落地的。
4.1 数学数据为什么特别难处理？
数学数据的处理和普通文本有着天壤之别，莫潇羽在这里详细解释一下它的几个独特挑战：
- 公式解析极易出错： 网页上的数学公式格式五花八门，MathML、KaTeX、AsciiMath、纯文本公式混杂在一起。不同的网站使用不同的渲染引擎，同一个公式在 HTML 源代码中的表示可能完全不同。举个例子，一个简单的求和公式 (\sum_{i=1}^{n} x_i)，在 MathML 中可能是一堆嵌套的 XML 标签，在 KaTeX 中是一行 LaTeX 命令，在 AsciiMath 中又是另一种语法。如果解析工具不能正确识别和转换这些格式，一个积分号可能变成乱码或方块字符，整段推理就失去了意义。更严重的是，公式解析错误往往是"静默"的——它不会报错，只是悄悄地把公式变成了错误的文本，你如果不逐条人工检查，根本发现不了。
- 推理链完整性至关重要： 数学内容不同于普通文本，它的价值高度依赖于推理链条的完整性。一个数学证明如果中间步骤丢失了，后续的所有内容不仅没有学习价值，还可能误导模型学到错误的推理模式。比如一个证明从"由条件A可得B"直接跳到"因此可得D"，模型可能会学会这种"跳步推理"的坏习惯。因此在数据处理时，必须特别关注内容的连续性和完整性。
- 知识密度极高且结构复杂： 数学文本通常信息密度很高，一篇论文中可能包含多个独立的定理和证明，它们之间既有逻辑依赖关系，又各自独立成章。如何将这些高度压缩的知识拆解为模型可以有效学习的单元，同时不破坏知识之间的内在联系，是一个非平凡的工程问题。
- 符号系统的特殊性： 数学使用了大量的专用符号和记号惯例，同一个符号在不同上下文中可能有完全不同的含义。比如 (f) 既可以表示一个函数，也可以表示频率或力，具体含义取决于语境。模型需要从高质量的数据中学习这种上下文相关的符号理解能力。
4.2 各层级的具体操作
UltraData-Math 团队针对这些挑战，在每个层级都做了专门的设计：
L0 层 — 数学解析器（UltraData-Math-Parser）
基于 magic-html 开发，核心创新是"多级回退策略"：
解析优先级：
1. 尝试直接解析 LaTeX 格式
2. 如果失败，尝试将 MathML 转换为 LaTeX
3. 如果还失败，尝试将 KaTeX 转换为 LaTeX
4. 最后尝试将 AsciiMath 转换为 LaTeX
5. 使用 w3m 布局保留渲染作为兜底这种策略确保了即使面对最复杂的网页公式，也能尽可能地保留完整的数学语义。
L1 层 — 启
