索引 · 2022 起
数据加载
把 PDF、Word、网页和扫描件解析成统一的正文、结构元素与来源元数据，再交给切块和索引。
要解决的问题
原始文档格式各异，表格、标题、页码和版面关系容易在抽取时丢失；错误文本进入索引后会持续污染召回与回答。
相对前一代的变化
早期流程常把文件直接转成纯文本。面向 RAG 的加载器会识别标题、段落、列表、表格和图片说明，并保留页码、来源等可追溯元数据。
做法
按文件类型选择解析器，经过格式识别、文本与版面抽取、OCR、元素分类和元数据标准化，输出统一文档对象。复杂 PDF 通常需要在快速解析、高分辨率版面分析和纯 OCR 之间选择。
局限
解析效果强烈依赖文档类型和扫描质量；表格、公式、双栏版式仍需抽样检查。通用加载器也无法替代领域清洗、权限过滤和增量同步。
在链路中的位置
位于 RAG 数据管道最前端，在切块、嵌入和索引之前；它决定后续系统实际能看见什么。
详解
「详解」根据 Datawhale《All-in-RAG》 的 数据加载：文档加载器与 Unstructured 改写，有删节和重组，未包含原教程的代码、图片和练习。原教程与本节详解均按 CC BY-NC-SA 4.0 许可提供：使用时需署名并标明修改，不得用于商业目的，再次改编须以相同许可共享。
加载要同时交出正文、结构和出处
数据加载是索引之前的抽取、转换和装载。它把 PDF、Word、网页、Markdown 和扫描件变成程序能继续处理的对象。只抽出一大段纯文本并不够，因为后面的切块、过滤和引用都需要知道这段文字从哪一页、哪一节、哪一个元素来。
- 解析：按文件类型提取文字，必要时对扫描页做 OCR。
- 抽取元数据：保留文件名、页码、标题层级、作者和来源地址。
- 统一结构：把正文和元数据装进同一种文档对象，供切块与入库使用。
按文档形态选加载器
纯文本可以用轻量加载器。混合目录需要能按扩展名分派的目录加载器。网页要处理导航、脚本和正文抽取。科研 PDF、合同和报表则要在版面、表格和 OCR 之间做选择。没有一个加载器对所有文件都最好。
- Unstructured 用统一接口处理多种格式，并能区分标题、正文、列表、表格和页眉页脚。
- PyMuPDF4LLM、Marker 更偏向把 PDF 转成 Markdown。
- LlamaParse、Docling、MinerU 面向版面复杂或需要更高解析精度的文档。
- 扫描件和表格很多时，PaddleOCR、MinerU 往往比通用的自动解析更合适。
先看解析出了哪些元素
Unstructured 的 partition 会按文件类型转到对应解析器。输出不是一个字符串，而是一组元素。元素类别包括标题、叙述文字、列表项、表格、图片、公式、页眉、页脚、代码和页码。分块时产生的复合元素，则是若干连续元素被合成的一块。
策略会明显改变结果。fast 追求速度，hi_res 做更细的版面分析，ocr_only 假设文字主要来自图像。正式入库前应抽几份代表性文档，数一数元素类型，并人工看表格有没有串列、双栏有没有读错行、页眉页脚有没有混进正文。
错误会从这里流进整个系统
加载阶段丢掉的表格、读错的数字和混入的页眉，都会被切块、嵌入并反复检索到。后面的重排序只能在这些文本里选择，不能把已经丢失的原貌找回来。因此加载规则要和切块规则一起定：哪些元素保留，哪些元素只作为元数据，哪些文档需要人工复核。