夜雨聆风你可能听过这个说法：做 RAG，就是把文档切成块，往向量数据库里一存，检索出来喂给模型。
听起来很简单。
但真正做过的人都知道，第一步就把很多人卡住了——
文件格式那么多（PDF、Word、PPT、Excel、图片……），里面的内容有标题、有段落、有表格、有图表、有页眉页脚。AI 怎么知道哪些是正文、哪些是注释、哪些是页码？
这一步，叫做文档解析。
它是 RAG 流水线里最容易被低估的环节，也是决定知识库质量的第一关。
RAG系列·第1篇：文档解析——喂给AI的知识库，不是直接丢文件就行
目录
1. 文档解析，到底在做什么 1.1 一个不准确的类比 1.2 文档解析的定义 1.3 为什么直接复制文字不够用 2. 文档解析的核心步骤 步骤一：布局分析（Layout Analysis） 步骤二：阅读顺序还原 步骤三：内容提取 步骤四：结构化输出 3. 文档解析 vs OCR vs 多模态大模型 3.1 三种技术的核心原理 3.2 一张图说明三者的关系 3.3 实践中三者的真实关系 3.4 适用场景对比 4. 实际工作流：三者怎么配合 5. 选型建议：什么时候用什么 6. 主流工具推荐 7. 一句话总结
1. 文档解析，到底在做什么
1.1 一个不准确的类比
想象你有一本书，想让 AI 理解它的内容。
最笨的做法：把整本书扫描成一张张图片，扔给模型看。
聪明一点的做法：把书里的文字提取出来。
但更聪明的是：不仅提取文字，还要理解书的结构——哪是章节标题，哪是一级内容，哪是图表说明，哪是引用注释。
第三种做法，就是文档解析在做的事情。
1.2 文档解析的定义
文档解析：从原始文档中，识别并提取出具有语义意义的结构化片段，并将其转化为大模型可以理解的格式。
这句话有三个关键词：
原始文档——可能是 PDF、Word、PPT、Excel，甚至是一张截图。注意，并非所有 PDF 都有文字层——某些设计软件导出或加密的 PDF，底层只有图像信息，看起来是文档，实际上文字不可选中、不可复制，这种"假PDF"本质上就是图片。
结构化语义片段——不是把文字全部打成一团，而是识别出：
这段文字是什么类型的（标题、正文、表格、列表） 这段文字和其他内容是什么关系（段落包含关系、引用关系）
大模型可理解的格式——通常指 Markdown、JSON 或纯文本块，加上必要的元信息（这段在第几页、属于哪个章节）。
1.3 为什么直接复制文字不够用
很多人会问：PDF 直接复制文字不行吗？
不行。原因很现实：
原始 PDF 文字："第三章 RAG 技术详解3.1 什么是 RAGRAG（Retrieval-Augmented Generation）是一种结合检索和生成的..."复制出来的效果：
丢失了标题和正文的层级关系 丢失了段落之间的逻辑边界 丢失了页眉页脚的噪音 丢失了表格和图表里的信息
好的文档解析后：
{"type": "heading","level": 1,"text": "第三章 RAG 技术详解"}{"type": "heading","level": 2,"text": "3.1 什么是 RAG"}{"type": "paragraph","text": "RAG（Retrieval-Augmented Generation）是一种...","page": 1}{"type": "table","headers": ["技术名称", "优缺点", "适用场景"],"rows": [...]}2. 文档解析的核心步骤
一个完整的文档解析流程，包含以下四个步骤：
步骤一：布局分析（Layout Analysis）
识别文档的视觉结构——哪块是文字、哪块是表格、哪块是图片、哪块是页眉页脚。
这一步决定了你能不能把"噪音"和"正文"区分开。
传统方法：用规则（PDF 里固定位置通常是页眉页脚）。
现代方法：用布局检测模型（深度学习），识别文档里每个区域的类型，准确率高得多。
步骤二：阅读顺序还原
把二维页面上的元素，按照正确的阅读顺序串起来。
为什么这步很重要？
这取决于 PDF 是怎么生成的：
数字生成的 PDF（Word/WPS/浏览器直接导出）：文字流顺序通常就是阅读顺序，不乱，解析起来相对容易。
扫描件或图片转的 PDF：没有文字流信息，靠 OCR 提取后再靠算法推断阅读顺序，这时候多栏排版和跨页表格就容易顺序错乱。
一个三栏 PDF 页面：左边栏 | 中间栏 | 右边栏物理存储顺序可能是：左边栏第1段 → 中间栏第1段 → 右边栏第1段 → 左边栏第2段...阅读顺序应该是：左边栏第1段 → 左边栏第2段 → 中间栏第1段 → 中间栏第2段...步骤三：内容提取
针对不同类型的内容，用不同的提取策略：
文字区域 → OCR 或 PDF 文本提取表格区域 → 表格识别（保留行列结构）图片区域 → 提取图片，供后续多模态处理公式区域 → LaTeX 或文本化步骤四：结构化输出
把提取的内容，按照语义关系组织成模型友好的格式：
# 第三章 RAG 技术详解## 3.1 什么是 RAGRAG（Retrieval-Augmented Generation）是一种...## 3.2 RAG 的核心组件RAG 系统包含以下核心组件...| 组件 | 作用 ||------|------|| 检索器 | 从知识库中找到相关内容 || 生成器 | 根据检索结果生成回答 |动手试一下：用 PyMuPDF 解析一份 PDF
上面讲的都是原理，下面用一段真实代码感受一下文档解析的过程。这里用 PyMuPDF（也叫 fitz），它是 Python 中最常用的 PDF 解析库之一：
import fitz # pip install PyMuPDFdefparse_pdf(pdf_path):"""解析 PDF，提取每页的文字和表格信息""" doc = fitz.open(pdf_path) pages = []for page_num, page in enumerate(doc, start=1):# 提取文字（带格式信息） text_blocks = page.get_text("dict")["blocks"] page_content = []for block in text_blocks:if block["type"] == 0: # 文字块 lines = [span["text"] for line in block["lines"]for span in line["spans"]] page_content.append({"type": "text","content": " ".join(lines),"bbox": block["bbox"] # 位置信息：用于判断页眉页脚 })elif block["type"] == 1: # 图片块 page_content.append({"type": "image","bbox": block["bbox"] }) pages.append({"page": page_num,"content": page_content })return pages# 使用示例result = parse_pdf("product_manual.pdf")for page in result: print(f"\n=== 第 {page['page']} 页 ===")for block in page["content"]:if block["type"] == "text": print(f" [文字] {block['content'][:80]}...")elif block["type"] == "image": print(f" [图片] 位置: {block['bbox']}")这段代码做了什么？
fitz.open() | |
get_text("dict") | |
block["type"] | |
bbox |
这是文档解析的最基础实现。实际生产中，你会用 Unstructured、LlamaParse 等工具，它们内部已经集成了更强大的布局分析模型和 OCR 引擎，不需要从零写起。但理解这个基本流程，能帮你选对工具、看懂工具输出。
3. 文档解析 vs OCR vs 多模态大模型
这三个东西，都是"识别原始文件信息"的方式，但原理不同、适用场景不同。
很多人容易混淆，或者认为"有了多模态大模型，OCR 和文档解析就不用了"。
这个理解是错的。
3.1 三种技术的核心原理
| OCR | |||
| 文档解析 | |||
| 多模态大模型 |
3.2 一张图说明三者的关系
原始文件 │ ├── 有文本层的PDF/Word/Excel │ │ │ └── 文档解析（布局分析+内容提取+结构化）→ 结构化块 │ ├── 无文本层的文件 │ （扫描件/图片/某些导出的PDF） │ │ │ └── OCR（提取文字）→ 纯文本 │ │ │ └── 文档解析（识别结构）→ 结构化块 │ └── 复杂视觉内容 （图表、示意图、流程图） │ └── 多模态大模型（理解图像语义）→ 文字描述3.3 实践中三者的真实关系
上面这张图是按输入类型区分的，逻辑上清晰，但在实践中，它们并不是独立的三个工具各行其道，而是分层嵌套的关系。
大多数成熟的文档解析工具，内部已经集成了 OCR 引擎。当你丢进去一份扫描件 PDF，它会：
先在内部调 OCR 引擎做文字提取（OCR 层） 再做布局分析，识别区域类型（解析层） 最后还原阅读顺序，生成结构化输出（输出层）
所以你的实际工作流往往是：
扫描件 PDF → 工具内部：OCR引擎提取文字 → 布局模型分析结构 → 阅读顺序还原 → 结构化块 → 你得到的：可以直接用的结构化内容你看不到 OCR 的调用过程，但它在背后工作。
这就是为什么前面表格里写着"文档解析的输入是 PDF/Word/图片"——它能处理图片，正是因为内部集成了 OCR。
3.4 适用场景对比
OCR 的适用场景：
手写文件识别（发票、表格、手写笔记） 老旧扫描件的文字提取 截图里的文字识别 纯文字图片（没有复杂排版）
最佳拍档：OCR + 文档解析扫描件 → OCR提取文字 → 文档解析识别结构文档解析的适用场景：
结构化文档（论文、合同、报告） 多栏排版文档（报纸、杂志） 跨页表格 目录、章节层级需要保留的文档
最佳拍档：文档解析 + 后续处理PDF → 文档解析 → 语义分块 → 向量检索多模态大模型的适用场景：
图表理解（柱状图、折线图、饼图表达的是什么） 示意图、流程图理解（这个架构图里的组件是什么关系） 复杂排版（OCR 识别不出的内容，多模态模型能理解上下文） 图片问答（给一张截图，问这个界面里有什么按钮）
不过要注意：多模态模型擅长的是概括性理解，而不是精确提取。
多模态模型擅长的：✓ 图表概括："这张图是产品的月度销售趋势图"✓ 流程图理解："这个架构图展示了三层架构：前端、服务层、数据层"✓ 截图问答："这个界面右上角的按钮是什么功能"多模态模型不擅长的：✗ 精确读取图表数值："2026年3月的销售额是 12,847 元"✗ 还原表格结构："第三行第二列的值是 XXX"✗ 多页文档的连贯理解（上下文窗口再大也有极限）如果需要精确的结构化数据提取（比如表格里的具体数值），多模态大模型目前不如专门的 OCR + 结构化解析方案可靠。所以应该是：多模态做语义理解，专门的引擎做精确提取，两者组合使用。
最佳拍档：多模态模型 + 文档解析复杂 PDF → 文档解析（文字+结构） + 多模态模型（图表+图片） → 合并输出4. 实际工作流：三者怎么配合
举一个真实场景：处理一份产品说明书 PDF。
这份 PDF 包含：
封面（图片） 目录（文字） 章节正文（多栏排版） 多个数据表格 多个产品架构图
方案一：只用 OCR（面对是扫描件或纯图片）
扫描件 PDF → OCR → 纯文字结果：文字倒是提取出来了，但：- 没有层级信息，目录和正文混在一起- 表格结构丢了（行列对不上）- 图片里的内容完全丢失- 多栏排版顺序混乱方案二：处理数字 PDF（只用文档解析，不需 OCR）
有文字层的 PDF → 文档解析 → 结构化块（文字+表格+图片位置）图片位置 → OCR → 图片里的文字结果：结构保留了，图片里的文字也识别了但：图表里的语义信息（"这张图说明了什么"）还是丢失方案三：完整方案——不同内容用不同手段
PDF → 文档解析 → 结构化块 │ ├── 文字区域 → 直接使用 ├── 表格区域 → 结构化提取 └── 图片/图表区域 → 多模态模型理解 → 文字描述最终输出：{"text_blocks": [...],"tables": [...],"image_descriptions": ["图1展示了产品架构，包含前端层、服务层、数据层...","图2是用户使用流程，从登录到下单到支付..." ]}三种技术配合，才能拿到最完整的知识库内容。
5. 选型建议：什么时候用什么
6. 主流工具推荐
文档解析目前没有一站式完美方案，以下是实践中常用的组合：
文档解析工具：
Unstructured：开源，支持多种文件格式，社区活跃，适合快速原型 LlamaParse：由 LlamaIndex 团队出品，对复杂 PDF 效果好 Marker：开源，支持 PDF 转 Markdown，效果不错 国产：庖丁科技 PDFlux、达观数据：对中文文档支持更好
OCR 工具：
PaddleOCR：百度开源，中文识别效果好，免费 Tesseract：老牌开源，英文为主 腾讯云 OCR / 阿里云 OCR：付费 API，中文和表格识别强
多模态模型：
GPT-4o / Claude 3.5：效果最好，成本最高 Gemini 1.5：上下文窗口大，适合处理大量图片 国产：通义千问 VL、智谱 GLM-4V：成本低，效果够用
7. 一句话总结
文档解析、OCR、多模态大模型，是处理原始文件信息的三种不同层次的手段——OCR 解决"有没有文字层"，文档解析解决"结构清不清楚"，多模态模型解决"图能不能看懂"。在实践中，好用的文档解析工具内部已经集成了 OCR，你无需刻意"选择"而是"组合"使用。
构建 RAG 知识库时，先搞清你的文档属于哪种类型，再决定用什么手段。多模态做语义理解，专用引擎做精确提取，彼此配合才是最优解。
不是贵的就好，也不是新的就强，适合文档类型的才是对的。
下一篇预告：分块策略——把文档切成什么形状，直接决定RAG效果 · RAG系列第2篇