用 Docling 处理 RAG 文档,原来这么简单

发布时间:2026/7/31 17:33:40
用 Docling 处理 RAG 文档,原来这么简单 用 Docling 处理 RAG 文档原来这么简单做 RAG 知识库时我们经常需要导入 PDF、DOCX、PPTX 等文档。很多人会认为只要把文档中的文字提取出来再进行切分和向量化就可以放进知识库了。但问题是文字被提取出来不代表文档已经被正确解析。一份 PDF 不只有文字还可能包含标题、段落、表格、图片、页眉页脚和多栏排版。如果这些结构在解析时被打乱后续的文本切分和检索也会受到影响。这正是 Docling 要解决的问题。一、PDF 能读取为什么还不能直接用于 RAGPDF 更像是一种“页面展示格式”。它关注的是文字和图片应该显示在页面的什么位置并不一定按照我们阅读文章的顺序保存内容。因此使用简单的文本提取方式处理复杂 PDF 时可能出现这些情况标题和正文混在一起双栏内容的阅读顺序错乱表格被拆成零散文本页眉、页脚和页码混入正文扫描版 PDF 无法直接提取文字。这些问题看起来只是“排版乱了”实际上会继续影响后面的文本切分和检索。RAG 的文档处理不只是把文字读出来还要尽量保留文字原本的结构和顺序。二、Docling 是什么Docling 是一个开源的文档解析与转换工具。它可以读取 PDF、DOCX、PPTX、XLSX、HTML、图片等多种格式并将文档转换成统一的结构化内容。可以把 Docling 理解成一名“文档整理员”找出文档中的文字判断哪些是标题、正文、列表和表格恢复内容的阅读顺序将处理结果转换成 Markdown、JSON 等格式。Docling 解析完成后会生成一个统一的文档对象DoclingDocument。这个对象不仅保存文档中的文字还可以保存标题层级、表格、图片、页面位置和来源信息等结构。因此Docling 和普通文本提取工具最大的区别是普通工具更关注“提取了哪些文字”Docling 更关注“这些文字在文档中是什么结构”。需要注意的是Docling 不是大模型也不是向量数据库更不是完整的 RAG 框架。它主要负责原始文档进入 RAG 之前的解析和转换工作。三、Docling 是怎样处理一份文档的Docling 处理文档的过程可以简单概括为四步。1. 读取文档首先读取 PDF、DOCX 等原始文件并根据文件格式选择对应的处理方式。2. 分析页面内容对于 PDF 等复杂文档Docling 会分析页面布局尝试识别标题正文列表表格图片代码和公式内容的阅读顺序。在 Docling 内部这些文档元素通常会带有对应的英文标识也就是 DocItemLabel文档内容常见英文标识文档标题title章节标题section_header正文段落text部分格式也可能是paragraph列表项list_item表格table图片picture代码code公式formula需要注意一级标题和二级标题并不是两个不同的标签。它们通常都属于 section_header再通过 level1、level2 等层级信息进行区分。3. 生成结构化文档识别完成后Docling 会把结果整理成统一的DoclingDocument。可以把它理解成下面这种结构文档DoclingDocument ├── 文档标题title ├── 一级标题一section_headerlevel1 │ ├── 正文段落text │ ├── 列表项list_item │ └── 表格table └── 一级标题二section_headerlevel1 └── 二级标题section_headerlevel2 ├── 图片picture ├── 代码code └── 公式formula这里展示的是一种便于理解的简化结构。实际解析结果会根据原始文档的内容和排版发生变化。4. 导出处理结果最后可以把文档导出为 Markdown、JSON、HTML 或纯文本等格式。对于 RAG 入门场景Markdown 是一种比较直观的选择。因为它可以清楚地表示标题、列表和表格也方便后续进行文本切分。整个过程可以概括为原始文档 ↓ 读取内容 ↓ 识别布局与结构 ↓ 生成 DoclingDocument ↓ 导出 Markdown 或转换为 LangChain Document四、用 Docling 解析一份 PDFDocling 的基础使用并不复杂。1. 安装 DoclingpipinstalldoclingDocling 支持 Windows、Linux 和 macOS。第一次处理 PDF 时默认可能会自动下载所需模型因此需要保证当前环境能够正常访问网络。2. 解析并保存为 Markdown假设当前目录下有一份名为设备操作手册.pdf的文件可以使用下面的代码进行解析frompathlibimportPathfromdocling.document_converterimportDocumentConverter# 原始文档和输出文件sourcePath(设备操作手册.pdf)outputPath(设备操作手册.md)# 创建转换器并解析文档converterDocumentConverter()documentconverter.convert(source).document# 导出并保存为 Markdownmarkdown_contentdocument.export_to_markdown()output.write_text(markdown_content,encodingutf-8)print(f解析完成{output})这段代码主要做了三件事DocumentConverter()创建文档转换器convert()读取并解析原始文档export_to_markdown()将解析结果转换成 Markdown。最终会在当前目录生成设备操作手册.md打开这个 Markdown 文件就可以直接查看 Docling 识别出的标题、正文、列表和表格结构。3. 转换为 LangChain 的 Document 对象如果后面要接入 LangChain可以使用 Docling 官方提供的DoclingLoader不需要先手动保存 Markdown再重新读取。先安装对应的集成包pipinstalllangchain-docling然后加载 PDFfromlangchain_docling.loaderimportDoclingLoader,ExportType loaderDoclingLoader(file_path设备操作手册.pdf,export_typeExportType.DOC_CHUNKS,)documentsloader.load()print(type(documents[0]))print(documents[0].page_content)print(documents[0].metadata)loader.load()返回的是一个 LangChainDocument列表。每个Document主要包含两部分page_content当前文档块的文本内容metadata来源、标题、页码等元数据。这里使用的 ExportType.DOC_CHUNKS 会把文档处理成多个文本块每个文本块对应一个 LangChain Document更适合后续向量化和检索。如果希望整份文件只生成一个 LangChain Document可以改为export_typeExportType.MARKDOWN五、Docling 处理前后有什么区别例如原本的一条故障记录是故障代码E01 故障原因电源异常 处理方法检查供电线路使用简单的文本提取方式后内容可能变成E01 检查供电线路 页码 12 电源异常文字基本都被提取出来了但原本的阅读顺序和字段关系已经被打乱。经过 Docling 解析后内容更可能保持为结构清晰的形式故障代码E01 故障原因电源异常 处理方法检查供电线路如果原始内容是一张表格Docling 还可以将其导出为类似下面的 Markdown| 故障代码 | 故障原因 | 处理方法 | | --- | --- | --- | | E01 | 电源异常 | 检查供电线路 |所以Docling 的价值并不是让文档中的文字变多而是尽量保留标题、段落、表格以及内容之间原本的结构关系。六、为什么解析后的内容更适合 RAG在 RAG 知识库中文档通常要经过下面几个步骤文档解析 ↓ 文本切分 ↓ 向量化 ↓ 检索 ↓ 大模型生成答案文档解析是整个流程的起点。如果一条故障记录在解析时已经被打乱后续切分时可能变成两个不完整的文本块文本块一E01电源异常 文本块二检查供电线路当用户询问E01 故障应该怎么处理检索系统可能只找到“E01电源异常”却没有同时找到对应的处理方法。如果 Docling 保留了完整的内容结构后续切分时就更容易获得完整信息故障代码E01 故障原因电源异常 处理方法检查供电线路这样可以为后续的向量化和检索提供质量更好的输入数据。因此更准确的说法不是“使用 Docling 就一定能提高 RAG 准确率”而是Docling 可以改善文档解析质量为后续文本切分和检索打好基础。七、总结做 RAG 时很多人会把注意力放在大模型、Embedding 模型和向量数据库上却容易忽略最前面的文档解析。但一份 PDF 能够打开、能够复制文字并不代表它已经适合直接切分和检索。Docling 所做的事情就是把面向人阅读的复杂文档转换成结构更加清晰、方便程序处理的数据。它的核心流程并不复杂读取文档 ↓ 识别布局和结构 ↓ 生成 DoclingDocument ↓ 导出 Markdown 或 LangChain DocumentDocling 不负责向量检索也不负责生成答案。它更像是连接原始文档和 RAG 知识库之间的一名“文档整理员”。