「把这些 PDF 变成一个能问答的知识库」听起来是个简单需求，做起来却是 RAG 里最容易翻车的环节。原因在于 PDF 是个「打印格式」——它描述的是「这些字符画在页面的什么位置」，而不是「这段内容的逻辑结构是什么」。人眼看着是整齐的表格和分栏，程序读出来可能是一堆位置错乱的字符碎片。
所以「AI 读懂 PDF」的关键不在最后问答那一步，而在前面「怎么把 PDF 变成干净、带结构的文本」。这篇文章按四个阶段拆解全流程，每个阶段讲清坑在哪、工具怎么选。
PDF 处理的难点不在问答，而在前置的「解析」——把打印格式还原成有结构的文本。
先分清：你的 PDF 是哪一种
处理策略完全取决于 PDF 类型，动手前必须先判断：
- 文本型 PDF：由 Word、排版软件导出，文字是可选中、可复制的真实文本层。处理相对简单；
- 扫描型 PDF：纸质文档扫描或拍照生成，本质是一张张图片，没有文本层，必须先 OCR 才能拿到文字；
- 混合型：一份文档里既有文本页又有扫描页/图片(最常见也最麻烦)。
判断方法很简单：用 PDF 阅读器试着选中文字，选得中就是文本层，选不中就是扫描件。一批文档里往往两种都有，处理管线要能自动识别、分别对待。
阶段一：拿到文本
文本型：直接提取
用 PDF 解析库(pdfplumber、PyMuPDF/pymupdf 等)直接抽取文本层。这一步快且准，但要注意：抽出来的文本顺序未必是阅读顺序(见阶段二)。
扫描型：OCR
没有文本层，只能 OCR。选择从轻到重：
- 开源 OCR：Tesseract 是老牌选择，中文需装对应语言包，对清晰印刷体够用，对复杂排版和手写吃力；PaddleOCR 等在中文和版面分析上通常更强；
- 云 OCR 服务：各大云厂商的文档识别 API，精度高、带版面分析，按量付费，适合量大或质量要求高的场景；
- 多模态大模型直接读图：把页面当图片直接交给多模态模型「看」，它能同时完成识别和理解，对复杂版面、表格、图文混排效果往往最好——这是近两年兴起的新路线，代价是成本和延迟更高。
混合型要先按页判断有无文本层，有则提取、无则 OCR，别整份用一种方法。
先判断 PDF 类型再选方法：文本型直接提取，扫描型走 OCR，混合型按页分流。
阶段二：保住结构(最容易被忽略，却最关键)
拿到文字只是第一步，PDF 处理真正的坑在结构丢失。三个高频问题：
- 多栏排版顺序错乱：双栏 PDF 直接提取，常把左栏第一行接右栏第一行，读出来语义全乱。需要版面分析先识别栏目区块，再按正确阅读顺序拼接；
- 表格被拍平：一个价格表提取出来变成一串连续数字，行列关系全丢。这样的内容进了知识库，检索再准也答不对。表格要专门识别并转成 Markdown 表格或「字段：值」句式；
- 标题层级丢失：PDF 里的「大标题」只是「更大的字」，没有语义层级。丢了层级，就没法给每个片段标注「它属于哪一章哪一节」，而这个元数据对检索至关重要。
应对上，除了传统解析库的表格/版面功能，现在有一类文档智能解析工具(如各类 document parsing 服务和开源方案)专门做这件事：输入 PDF，输出带标题层级、表格结构、阅读顺序的结构化结果(常为 Markdown 或 JSON)。对表格多、版面复杂的文档，用这类工具往往比自己拼解析逻辑省事得多，值得优先评估。
衡量这一步做得好不好，有个简单办法：随机抽几页，把解析结果和原 PDF 对照——表格对得上吗？标题层级在吗？栏目顺序对吗？这一步不过关，后面全白搭。
阶段三：切分与入库
拿到干净、带结构的文本后，就回到了标准 RAG 流程。PDF 场景下切分尤其要利用好前面保住的结构：
- 按结构切，别硬切：用阶段二拿到的标题层级切分，每块对应一个完整小节，并把「文档名 > 章节」路径写进元数据。具体尺寸和策略见《RAG 文档切分怎么做》;
- 表格单独成块：一张表作为一个独立 chunk，别被拦腰切断；必要时给表格配一句自然语言描述再入库，提升可检索性；
- 保留页码来源：入库时记录每个片段来自第几页，问答时能给出「答案出自第 X 页」的溯源，这是 PDF 问答很受欢迎的能力；
- 图片处理：如果图里有关键信息，用多模态模型给图生成文字描述再入库，否则检索会完全忽略图片内容。
之后向量化、存入向量数据库、混合检索、重排，和普通 RAG 无异，参考本站的 RAG 系列文章。
阶段二保住的标题层级和表格结构，在切分阶段直接转化为更高的检索质量。
阶段四：问答
到这一步，PDF 已经变成了普通的知识库，问答质量取决于前三步的数据质量和检索配置，而非「AI 读 PDF 的能力」。如果问答答不准，别急着换模型，回头查：
- 是不是表格/多栏在阶段二就解析错了？
- 是不是切分把关键信息切碎了？
- 是不是检索没召回对(考虑加 Hybrid Search 和 Rerank)?
PDF 问答的绝大多数问题，根子都在解析和切分，而不在最后的生成。 这也是本文花大力气讲前三步的原因。
适用人群与方案选择
适合要做文档知识库、合同/研报/手册问答、企业资料检索的开发者。按投入选方案：
| 需求 | 建议方案 |
|---|---|
| 少量文本型 PDF，快速验证 | pdfplumber/PyMuPDF 直接提取 + 标准 RAG |
| 有扫描件，中文为主 | PaddleOCR / 云 OCR + 文档解析工具 |
| 表格密集、版面复杂 | 文档智能解析服务，或多模态模型直读 |
| 不想自己搭 | Dify、FastGPT 等平台内置了 PDF 解析，上传即用，适合非重度定制场景 |
从简到繁，先用最轻的方案跑通，发现解析质量不够再逐步升级，别一上来就上最重的多模态直读(贵且慢)。
常见问题
Q：直接把整个 PDF 丢给长上下文模型，不做 RAG 行不行？ A：单份不太大的文档可以，省去搭建成本。但对扫描件仍要先 OCR，且长上下文有信噪比和成本问题(见《长上下文模型真的更强吗》)。文档多、要来源、要复用时，还是 RAG 更合适。
Q：为什么我的 PDF 表格问答总是错？ A：几乎可以肯定是解析阶段表格被拍平了。抽查解析结果验证，把表格专门转成 Markdown 或「字段：值」结构再入库，这是 PDF 问答最值得投入的一处优化。
Q：多模态模型直接读 PDF 是不是最省事？ A：效果常常最好，尤其复杂版面，但成本和延迟高，大批量处理不经济。务实做法：普通页用传统解析，难解析的复杂页/表格页才交给多模态模型，按需混用。
小结
「AI 读懂 PDF」的真相是：能不能读懂，九成取决于你有没有把 PDF 干净地转成带结构的文本。四个阶段——先分类型、再拿文本(文本层提取或 OCR)、然后保住结构(表格、多栏、标题层级)、最后切分入库问答。把力气花在前三步，尤其是常被忽略的「保住结构」，你的 PDF 问答质量会甩开那些「直接提取硬塞」的做法一大截。