RAG知识库文档解析实战：OCR选型与多模态大模型应用指南

做RAG项目做得多了，慢慢会发现一个现象：多数知识库效果不好，问题根本不在模型，而在最前面的数据导入解析。文本型PDF还好，顶多抽出来有点乱码；一旦遇到扫描件、图片截图、图文混排、财报表格，检索质量就直线往下掉。这个系列第二篇，专门把图文和PDF解析这件事拆开聊：OCR怎么选、多模态大模型什么时候上、市面上常见的PDF解析工具到底哪几个值得用。内容偏实战，适合正在搭RAG知识库的开发者、做文档智能处理的技术人员，也适合企业内部文档量大的团队做选型参考。

1. 解析环节决定RAG效果的上限：先想清楚卡点在哪

1.1 RAG的瓶颈不在生成，在“读不读得进”

先说一个被很多人低估的事实。RAG的整体链路是：文档导入 → 解析 → 切分 → 向量化 → 检索 → 生成。大家费尽心思调prompt、换大模型，但真正决定检索质量上限的，其实是解析和切分这两步。因为后端的向量化、检索、生成，全都建立在解析出来的文本之上。解析环节把信息丢了，后面做得再花哨也无法补救。

拿扫描件举例。一份PDF如果本身是图片格式，直接抽取文本拿到的是空字符串。那问题来了，向量化空文本能有什么效果？什么都检索不出来。再比如图文混排的PDF，如果只按纯文本抽取，文字顺序是乱了还是缺了，根本没人知道，结果就是索引里的内容和原文档对不上，用户问一个精确问题，召回的全是噪音。

我习惯把这个环节比作图书馆编目。书再多，如果每本书的目录和索引是错的，再厉害的管理员也找不到正确的书。RAG项目里，解析就是把“书”变成“可检索的卡片”这一步，卡片质量差，检索系统再先进都是白搭。

所以做RAG第一件事，不是急着选模型和向量库，而是先把文档类型摸清楚：哪些是文本型PDF，哪些是扫描件，哪些是含复杂表格和图片的文档。类型决定了解析方案，解析方案决定了下游能不能检索到。

1.2 知识库形态怎么选：非结构化、结构化还是知识图谱

聊到解析，就顺便把知识库形态的区分讲清楚，因为很多人在这一步就开始混淆。热词里能看到“KG知识库”“RAG知识库和结构化知识库区分”这类问题，说明大家在选型阶段确实容易卡住。

• 非结构化知识库：文档、PDF、PPT、图片转出来的文本，格式自由、版面多样，靠向量化之后做相似度检索。这是RAG最主流的应用场景，处理的就是我们正在聊的这些文档。
• 结构化知识库：数据库表、JSON、CSV这类有明确字段的数据。它们适合精确查询、统计聚合，不适合做语义检索。解析表格类PDF时，抽出来的内容如果还想保持结构，就适合落到这类形态里。
• 知识图谱（KG）：强调实体和关系，比如“张三—就职于—某公司”，适合多跳推理、关系问答。但它需要提前建模和抽取实体关系，建设成本比RAG高不少。

解析环节和这三种形态都有交集：同一份PDF，纯文本段落可以走非结构化RAG，表格可以抽成结构化数据，重要实体可以顺带进了知识图谱。所以先不要纠结“到底用哪个”，而是要问“这份文档主要承载什么信息，下游任务需要什么形态”。RAG虽然主打非结构化场景，但表格数据结构化之后，经常能补足RAG在精确查询上的短板，两个一起用并不冲突。

2. OCR工具选型与调参：从图片到可检索文本

2.1 OCR技术链路：为什么机器还是会认错字

OCR（光学字符识别）不是简单的“拍照翻译”，而是一条技术链路。拆开来看，大概有五个环节：

• 图像预处理：灰度化、二值化、去噪、倾斜校正，目的是把复杂背景变成干净的黑白字。
• 版面分析：找出图片里哪些区域是标题、正文、表格、图片，这一步决定了识别的顺序和结构。
• 文字检测：定位每一行、每一个字块的位置，最常用的算法思路是检测文本包围框。
• 文字识别：把检测出来的字块转成字符序列，这一步现在主流是CRNN或者Transformer类模型，PaddleOCR用的PP-OCR系列就是典型。
• 后处理：用词典、语言模型纠错，把“0”和“O”、“1”和“l”这类容易混淆的字符修正回来。

理解了链路，你就知道OCR识别结果为什么偶尔有错：背景脏、字太密、倾斜角度大、字体罕见，任何一个环节处理不好都会影响最终结果。生活里最直观的例子是网盘图片搜索，表面上看“搜一下就能找出图片里的字”，底层跑的就是这条链路；效果好不好，完全取决于图片质量和算法鲁棒性。

做RAG解析时，OCR输出的不只是文字，最好还能带上坐标框。后面做版面重建、保留阅读顺序、甚至做多模态模型预处理时，这个坐标信息非常值钱。

2.2 主流OCR工具怎么选：开源、商业与专业公式工具

OCR工具选择非常多，但实际做文档解析，值得认真评估的就那么几类。列个表看得更清楚：

如果你是个人开发者或者中小团队，我建议优先试PaddleOCR。它有几个优点：中文识别效果好、可完全离线部署、自带版面分析方向分类，而且项目更新频繁。配合Python就能批量处理扫描PDF，成本几乎为零。

Tesseract则更适合英文或者多语言小任务，它虽然历史悠久，但中文识别能力相比PaddleOCR差一截，遇到复杂版面更容易翻车。如果只是识别几张英文图片，Tesseract够用；如果是做知识库，我不推荐。

商业云OCR适合预算充足、需要高精度的场景。比如合同、发票、身份证这类关键信息提取，商用API的识别准确率和版式模板确实强，但要注意隐私和成本，大批量离线解析还得靠开源方案兜底。

2.3 实操要点与避坑：识别率不是自动来的

OCR不是装个库就能直接用的，实际跑下来有几个细节直接影响效果。

第一，扫描件分辨率至少调到300DPI。低于这个值，小字号文字识别时笔画已经糊了，再好的模型也无力回天。如果是图片PDF，可以在PDF渲染图片时用pix = page.get_pixmap(dpi=300)来保证清晰度。文字太小的时候，可以在OCR前先放大图片，实测放大两倍后识别正确率能明显提升。

第二，带倾斜角的页面先做透视矫正。手机拍的文档、扫描歪的页面，不做矫正会导致检测框对不齐，识别结果断行错乱。PaddleOCR里有一个use_angle_cls参数用来做方向分类，开起来能处理一些旋转场景，但大角度倾斜最好还是先用图像处理矫正。

第三，中文识别先确认语言包装好了。有朋友在Mac上跑OCR，识别英文没问题，中文全是乱码，折腾半天发现是缺中文字体库。Windows上装福昕这类PDF编辑器，如果中文识别不生效，大概率是OCR语言包没装完整，常见的就是ocr-zh-cn.fzip缺失或路径不对。这类语言包问题坑得很隐蔽，排查时先确认对应语种的语言包已经安装。

还有个容易踩的坑：很多人在网上搜“PHP OCR识别验证码”“C# OCR PDF”之类的关键字，拿文档OCR引擎去处理验证码。这两类任务的技术思路完全不同，验证码追求的是防机器识别，文档OCR追求的是高准确率，拿文档工具去识别验证码，效果差还容易被误用。文档解析就别往验证码方向想，专心做知识库就好。

实操下来我的经验是：纯白背景、规整排版的黑白合同或者文字页，PaddleOCR默认参数就能有不错的准确率；彩色背景、艺术字体、复杂表格这类页面，必须配合版面分析，甚至还得上多模态模型人工兜底。

3. 多模态大模型补位：看图和理解版面不再是难题

3.1 多模态模型能解决哪些OCR解决不了的事

OCR只能把图里的文字“抠”出来，但不理解语义。一份PDF里如果既有文字又有图表，OCR把文字抽出来没问题，但图表趋势、公式结构、表格语义它都无从下手。这时候多模态大模型就派上用场了。

多模态大模型的核心能力是“看图说话”。它能把一张完整页面图片输入进去，然后输出结构化的Markdown或者JSON。好处是：标题层级能保留、表格能还原成真正的表格、公式能转成LaTeX、流程图和图示能被描述出来。跟OCR+后处理规则那条路相比，多模态模型省掉了大量版面恢复的工作。

2026年这一拨多模态模型的能力已经有很大提升，一些旗舰模型甚至能做到“整页PDF渲染成图片直接理解”，还能理解文档里逻辑顺序。对RAG来说，这意味着以前需要写很多代码去做版面分析的任务，现在可以丢给模型一次性完成。这非常适合复杂的图文混排、PPT转PDF、广告页、包含大量图表的研究报告。

3.2 实操：把PDF页面交给多模态模型的完整流程

用多模态模型解析PDF，实操思路不复杂，核心是“先把PDF变成图，再把图变成干净文本”。具体流程：

第一步，用PyMuPDF把每一页渲染成高清图片，DPI设置到200以上，避免小字看不清。 第二步，将图片交给多模态大模型的接口，提示词里明确要求输出格式。 第三步，将返回结果按页保存为Markdown文本，再进入RAG切分和向量化。

import fitz doc = fitz.open("complex_report.pdf") for page_no in range(len(doc)): page = doc[page_no] pix = page.get_pixmap(dpi=200) pix.save(f"page_{page_no+1}.png")

提示词可以参考下面这段：

请把这张图片解析为规范的Markdown格式： - 保留原有标题层级，用#号表示 - 表格用Markdown表格还原，不要省略列 - 公式用LaTeX格式并放在$...$之间 - 保持原文档的阅读顺序 - 不要添加任何解释，直接输出Markdown内容

实测下来，一份普通的财报PDF，如果表格错乱得厉害，用传统pdfplumber抽表格容易把多行合并、列错位，而多模态模型能直接把四列、多行的表格还原成结构正确的Markdown表格。这个能力对RAG的帮助很大，因为结构化文本向量化之后，检索“某季度营业收入”这类问题，召回效果比纯文本碎片好得多。

3.3 什么时候用OCR，什么时候直接上多模态模型

多模态模型好用，但也不是所有场景都应该用。

成本和效率是选型时要考虑的关键变量。OCR在本地批量跑，几乎是零边际成本，处理几千页文档也不心疼。多模态模型按token计费，整本PDF全量送进去，费用不低，而且响应时间不可控。所以我的习惯是：先用OCR把容易处理的页面消化掉，遇到版面特别乱的页面，或者OCR结果质量分很低的页面，再送多模态模型兜底。混合方案跑下来，比无脑全量多模态能省三成以上成本，输出质量也更好。

实践中还有一个细节：多模态模型对单张图片的分辨率有限制。页面图片过大时，模型可能无法完整读取细节，解决办法是先做切片（比如把页面切成上下两半），或者用OCR先定位坐标，局部截图再放大给模型。这一步是纯工程经验，不试一次发现不了。

4. 九种PDF解析工具选型：从文本抽取到版面重建

4.1 先分清PDF解析的三个层次

PDF解析工具看着眼花缭乱，其实本质上是三个层次的工作，别混在一起选。

• 纯文本抽取：从文本型PDF里提取文字，适合论文、电子书、文档扫描后带文字层的PDF。
• 版面结构化：识别标题、段落、表格、图片的位置关系，把文档拆成有逻辑的元素，适合图文混排文档和RAG切分。
• 视觉理解：把PDF页面当成图片来处理，用OCR或多模态模型理解，适合扫描件、图片型PDF。

选工具前先判断你的PDF属于哪个类型。文本层完整的PDF硬用OCR处理，等于多花时间还降低精度；扫描版PDF只用文本抽取工具，什么都拿不到。工具选错，后面全是白费。

4.2 九种工具逐个说：用法、代码和适用场景

1. PyMuPDF（fitz）

速度极快的PDF处理库，既能抽文本，也能把页面渲染成图片。我常用它做“先检测PDF有没有文本层”的前置操作。提取文本简单到令人发指：

import fitz doc = fitz.open("document.pdf") for page in doc: text = page.get_text("text") if text.strip(): print(text)

如果页面上get_text()返回空字符串，那基本可以断定这页是扫描图片，需要走OCR。另外，get_pixmap(dpi=300)渲染出来的图片是后续多模态模型和OCR的输入源，一个库解决两件事。

2. pdfplumber

基于PDFMiner封装，能提取带坐标的文本，还能抽表格。特点是保留了每个字符的位置信息，这对恢复阅读顺序、提取表格都很有用。

import pdfplumber with pdfplumber.open("table.pdf") as pdf: page = pdf.pages[0] table = page.extract_table() for row in table: print(row)

遇到简单的表格，用extract_table()直接拿数据。它内部靠线条定位单元格，网格线清晰的表格识别精度不错，无线表格就勉为其难了。

3. PDFMiner.six

PDF文本抽取的底层库，pdfplumber就是建立在它之上。直接用它相对底层，但胜在可以通过API拿到字符级坐标。如果要做精细的版面重建，比如把文本按坐标排回原来的顺序，PDFMiner值得研究。

from pdfminer.high_level import extract_text text = extract_text("sample.pdf") print(text)

4. pypdf

轻量级的PDF处理库，主打合并、拆分、旋转、加密这类操作，文本抽取能力简单够用。大型RAG项目里，pypdf适合做文档预处理而不是核心解析。比如把一本几百页的书按章节拆成多个PDF文件，它比PyMuPDF更直观。

5. Camelot

专门做表格抽取的库，底层用了OpenCV来做网格线检测，擅长处理有线表格。它支持lattice（格子线）和stream（流式）两种模式，前者适合有线表格，后者适合无线但按行排布的数据。

python -m camelot "table.pdf" --output table.csv --format csv

实测下来，密集财报里的有线表格用Camelot的lattice模式，抽取效果比pdfplumber稳定不少。但Camelot对PDF的编码和版本比较敏感，偶尔会失败，需要换工具兜底。

6. Tabula

Java写的表格提取工具，需要本地安装Java环境，能用Python调用。适合把PDF表格直接转换成DataFrame。如果你本身做数据分析，Tabula很顺手；但如果你追求纯Python部署、不想碰Java，建议还是用Camelot或pdfplumber。

7. PaddleOCR

前面详细讲过。在PDF场景里，它不仅能做OCR，还自带版面分析方向分类。扫描版PDF用PaddleOCR识别文字后，再配合坐标信息还原页面结构，是RAG项目里最常用的开源方案。

from paddleocr import PaddleOCR ocr = PaddleOCR(use_angle_cls=True, lang="ch") result = ocr.ocr("scan_page.png") for res in result: if res: print(res[1][0]) # 识别文本

8. Unstructured

专门为非结构化数据解析而生的库，在RAG圈子里很受关注。它的核心是partition_pdf，能把PDF按语义拆成标题、正文、表格、图片等元素，而不是单纯吐出一大坨文本。

from unstructured.partition.pdf import partition_pdf elements = partition_pdf("mixed.pdf") for element in elements: print(element.category, element.text)

用这个库，切分和向量化的前置工作会被大幅简化，因为它已经帮你把文档结构抽出来了。配合LangChain这类RAG框架使用，是当前比较主流的技术路线。

9. MarkItDown

微软开源的文件转Markdown工具，支持PDF、Word、PPT、Excel等格式。它的核心思路是把文档转成规范的Markdown，标题、列表、表格都有对应结构。对RAG来说，Markdown本身就是很理想的中间格式，切分时可以按标题和列表做语义切分。

from markitdown import MarkItDown md = MarkItDown() result = md.convert("report.pdf") print(result.text_content)

这个工具在“图文混排文档转RAG格式”的场景里表现不错，输出内容干净，省掉很多清洗工作。

4.3 九种工具选型速查表

4.4 按文档类型反向选工具

工具再全，也要落到场景里。给几个常见组合建议。

文本型论文PDF：PyMuPDF抽全文最快，干净文档一次拿到纯文本。如果页面有双栏，再进行双栏切分，别直接读成“从左列中段跳到右列中段”的混乱顺序。

扫描合同：直接PaddleOCR。合同一般无复杂颜色，黑白扫描件识别稳定，输出文本按页拼接即可。如果有印章遮挡文字，需要人工抽检补救。

带表格的财报：先pdfplumber或Camelot抽表格，表格区域单独处理，正文用PyMuPDF抽取。表格数据抽取出来后，建议按结构化数据保存，别混在文本里向量化。

图文混排的PPT转PDF：MarkItDown或多模态模型都行。MarkItDown能保留标题和列表结构，多模态模型则能理解图里的逻辑，具体看你对成本还是精度的偏好。

5. 一套可复用的PDF导入解析流程与问题排查

5.1 一个能直接跑的解析流水线

把前面的工具串起来，就是一个能直接上手的PDF导入解析流水线。核心逻辑围绕文档类型判断来走：有文本层就抽文本，没文本层就走OCR，OCR结果差再上多模态模型兜底。

import fitz from paddleocr import PaddleOCR ocr = PaddleOCR(use_angle_cls=True, lang="ch") doc = fitz.open("sample.pdf") for page_no, page in enumerate(doc): text = page.get_text("text") if text.strip(): print(f"[Page {page_no+1}] Text layer found") # 直接使用文本，进入清洗和切分 else: print(f"[Page {page_no+1}] Scanned page, run OCR") pix = page.get_pixmap(dpi=300) pix.save(f"temp/page_{page_no+1}.png") # 送到OCR，得到文本后同样进入清洗

这段代码在Mac和Linux上都能跑，Python环境装好依赖即可，完全本地离线运行。跑完之后，解析出来的文本需要统一清洗：去掉页眉页脚、页码、多余换行，再进入切分和向量化流程。

5.2 实测中常见的问题与排查实录

解析过程中会遇到各种问题，我把踩过的坑整理一下，方便查表对照。

页面全是空白，但PDF能打开

很大概率是扫描版，没有文本层。先get_text()验证，确认空白再走OCR。很多人第一反应是代码问题，折腾半天才发现文档本身是图片。

中文乱码

两种情况：文本型PDF缺字体嵌入，或者OCR语言包没装。文本型PDF的乱码通常没法通过工具解决，只能放弃文本抽取改用OCR/多模态；OCR语言包问题则好处理，重新安装对应语言包即可。

表格解析错位

不同工具对表格的支持差异大。有线表格优先Camelot，无线表格优先pdfplumber的extract_table，或者多模态模型。我实际遇到过一个奇怪的表格，pdfplumber抽出来多了一列空值，Camelot却完全正确，所以多备两个工具交叉验证是常态。

多栏PDF阅读顺序错乱

双栏论文如果不做版面分析，解析出来的文本是一段左栏接一段右栏再接左栏，很容易乱。解决思路是拿坐标信息按x坐标排序，先按栏切分再按列读取。PaddleOCR的版面分析模型也可以识别出栏位，然后再按区块顺序取文本。

公式变成乱码

PDF里的公式在文本抽取时经常变成一行符号或者压根丢失。轻量场景用Mathpix处理公式图片，批量场景建议直接上多模态模型输出LaTeX。公式类文档对RAG来说是硬骨头，文本检索本来就不擅长，建议单独建索引。

大文件内存爆炸

几百页的高清扫描PDF同时渲染，内存会顶不住。处理方法很简单：按页处理，用一代一代处理完马上释放，不要把所有页面一次性渲染完再跑OCR。

表格和正文混在一起没法切分

Unstructured最适合这个场景，它能按元素类型输出表格、标题、段落，切分的时候可以按元素边界来做。如果不用Unstructured，就得自己根据坐标框先判断哪些区域属于表格，再单独提取，代码量会大不少。

5.3 解析之后的清洗与切分才是重头戏

很多人以为解析完就万事大吉，直接往向量库里灌，结果问答质量差又找不到原因。其实解析结果只是原材料，清洗和切分决定最终效果。

清洗建议做三件事：删除页眉页脚、页码和脚本标注；把断行合并成完整段落；过滤掉隐约可见的OCR噪声（比如页码数字混进正文）。清洗环节看似简单，但对向量化效果影响非常大，页眉页脚全是重复文本，会让向量检索把这些重复内容当成重点，真正的正文反而被淹没。

切分策略也不能只顾固定字符数。固定按500字切分最省事，但遇到表格、代码块、长段落，很容易把语义割裂。更合理的做法是：先按标题层级和段落边界切，太长的段落再按语义或句子边界补充切分，确保每个块内主题连贯。

图片内容不要直接丢弃。RAG场景里，文档里的图片、图表往往承载关键信息，可以把图片单独保存、单独向量化，并在文本块里保留图片的引用标记。后续检索到文本时，可以同时把相关图片带出来，这对多模态问答很有帮助。

我做解析环节最大的体会是：别指望一个工具解决所有PDF。文档类型多样，工具就有多样，必须组合使用。手上一套混合方案，按类型分流、按质量把关，才是稳定可靠的常态。解析结果一定要保留坐标和元数据，后面做检索排序、引用溯源，全靠这些细节撑起来。下一篇我会接着讲切分与向量化的实操细节，到时候会直接从这套解析流程产出的数据格式继续往下走。