如果你最近在搭RAG检索增强生成项目大概率已经经历过这种诡异阶段文档明明传进去了向量库里也建了索引但问一个问题模型答出来的内容不是张冠李戴就是“找不到相关信息”。我一开始怀疑是Embedding模型选得不对是分块策略太粗糙后来把源头扒了个遍才发现问题出在最不起眼的数据解析环节——尤其是PDF和图片类内容解析出来的文本本身就是乱的。这也是我为什么把数据导入与解析这个主题拆成一个系列来讲上一篇聊的是文本类数据的清洗和规范化这一篇专门怼图文和PDF解析覆盖OCR、多模态大模型两条技术路线外加九种PDF工具的实测选型希望能帮你少走点弯路。1. RAG数据处理里图文PDF为什么一直是最容易翻车的环节1.1 解析质量直接决定检索质量的一句话逻辑很多团队在搭RAG的时候把技术重心全放在向量数据库选型、Embedding模型微调、Prompt模板设计上对最前面的“数据解析”环节反而非常随意。我见过不少项目数据源是几百份带表格的财务报告、扫描版合同、图文混杂的行业白皮书结果负责导入的同学直接用PyPDF2的extract_text()跑了一遍出来一堆没有段落顺序的碎文本就往向量库里塞。等到查询阶段用户问“公司前三季度的营收结构变化”系统反馈回来的片段是某一页表格里被拆碎的单元格文本既不完整也缺少上下文最终生成答案自然没法看。道理其实很朴素RAG的上限由检索质量决定检索质量的上限由入库文档的解析质量决定。Embedding模型再强也救不回来一段语义已经被打散的文本。PDF这种格式本身就不是为了“提取文本”设计的它记录的是页面布局和坐标你拿到的“文本”只是从坐标层里抠出来的副产品。图文混排、扫描件、多栏排版、表格嵌套每一个都是解析环节的独立坑点。这个系列我坚持从数据导入讲起就是因为在实战里它决定了下游所有环节的天花板。1.2 三类最容易让RAG崩掉的PDF形态我在实际项目里遇到的PDF文档基本可以分成三类每一类的处理方式完全不同混在一起批量处理一定会出问题。第一类是纯文本型PDF页面里有真实文本层可以直接提取。这类文档通常由Word、LaTeX、HTML打印生成文字选中复制没问题解析的重点在于保持段落顺序、标题层级和表格结构。第二类是扫描件或图片型PDF页面本质是图片没有任何文本层必须走OCR流程。合同、老书、传真件、部分政府公开文件都在这一类。如果解析方案里没有OCR步骤这类文档在向量库里基本是隐形数据检索时永远命不中。第三类是混合型PDF也叫双层PDF底层是扫描图片顶层叠加了一层OCR生成的透明文本。这种文档看起来能复制文字但文本层往往带有坐标噪声、重复内容或者识别错误直接提取很容易拿到一份“看似正常、实则错位”的数据。很多人都是在跑完整条RAG链路之后才发现数据源头分类没做白白浪费了大量调试时间。下一篇也会反复强调一个原则在导入阶段先做文档形态探测再决定走哪条解析路径不要一上来就写一个统一的解析函数。1.3 我踩过的一个典型案例解析错位导致检索效果断崖式下跌说一个我自己踩过的坑。之前做一个行业法规库的RAG项目数据源里有一批PDF是扫描后经过OCR生成的按当时的判断这类文档应该直接走OCR路线。但团队里有人图省事直接用了pdftotext命令行工具批量提取提取结果肉眼扫过去没什么大问题段落、标题看着都还在就按这个结果做了切片入库。结果测试阶段问“某条款关于行政处罚的时效规定”系统返回的内容经常是半句话加一句无关的序言而且引用页码还不稳定。后来把原始PDF调出来逐页对照才发现这套OCR文本层存在明显的纵横坐标错位本来应该属于表格第二行的内容在文本层里被拼到了第一行后面。由于这个问题是“局部性”的肉眼抽查很难发现等进了向量库经过Embedding之后语义被进一步扩散排查起来非常痛苦。从那以后我在数据导入流程里强制加了两步文档形态分类和解析结果抽样核验。这两步看起来费时间但能在问题扩大化之前就把它拦住比后面排查快十倍都不止。2. 图文解析的两种路线传统OCR与多模态大模型的真实差异2.1 OCR传统流程拆解检测、识别、后处理三步走传统的OCR技术路线拆开来看其实是一个流水线每一步都有独立的优化目标混在一起只会互相干扰。第一步是版面分析与文字检测这个阶段要做两件事找出图片里的文字区域并且标记出每行文字的坐标框bounding box。常见做法是用目标检测或者分割模型比如PaddleOCR里的DB文本检测算法它对弯曲文字、倾斜文字、低光照条件下的文字都有不错的召回率。在这个阶段输出是若干个坐标框而不是文字本身。第二步是文字识别把检测出来的文字区域图像送入识别模型输出对应的文字序列。识别模型通常基于CRNN、Attention或者Transformer结构PaddleOCR的SVTR系列就是典型代表。对中文场景来说这一步的难点主要在于生僻字、手写体和特殊符号模型的训练数据规模直接决定了它的上限。第三步是后处理与结构化因为OCR输出的只是“字”没有段落、没有表格结构还需要根据坐标信息重新聚合成段落、识别表格的单元格边界、恢复阅读顺序。这一步最容易被忽略但恰恰是RAG场景里最关键的。同一个表格有的工具能输出一行一行的单元格文本有的工具会把单元格内容按坐标胡乱拼接。嵌入向量之后前者能精确命中“某列对应的值”后者就只能提供一段语义混乱的噪声。2.2 主流开源OCR引擎的取舍PaddleOCR与Tesseract在传统OCR路线上我实际用得最多的两个开源方案是PaddleOCR和Tesseract两者定位差异很大。Tesseract是老牌OCR引擎由惠普实验室诞生后来交给Google维护。它的优点在于轻量、跨平台、支持语言极多超过100种装一个语言包就能跑。但它在中文场景和复杂版式上表现一般尤其是中文表格、竖排文字、带背景噪点的扫描件识别精度明显不够用。个人建议是应对英文文档、白底黑字的规整扫描件Tesseract仍然可用涉及中文或版式复杂的慎重考虑。PaddleOCR是百度开源的中文OCR工具链对中文场景做了大量针对性优化内置文本检测、方向分类、文字识别三个模型还额外提供表格结构识别模型。我实测下来普通中文打印体的识别准确率接近商用水平而且在表格识别上有专门的解决方案可以直接输出HTML格式的表格结构。它的缺点是依赖库较多部署体积偏大CPU推理速度比Tesseract慢一些但配合GPU加速后完全能接受。如果走开源路线做扫描件PDF的RAG入库我的默认推荐是PaddleOCR配合它的PP-Structure套件可以把版面分析、表格识别、文字读取一次跑完。当然它也不是万能的遇到手写体和低分辨率老照片仍然需要人工介入或者引入下一节讲的深度视觉模型。2.3 多模态大模型在图文解析上的优势与风险近年来多模态大模型视觉语言模型为图文解析提供了一条完全不同的技术路线。它不再走“检测文字框—识别文字—重组结构”的流水线而是直接把整页PDF渲染成图片交给模型让它理解整页内容后输出Markdown、HTML或者JSON。这条路线的优势非常明显。第一它天然理解版面语义能够区分标题、正文、页眉页脚、图片注释而不是机械地依靠坐标判断。第二它能够处理传统OCR很难搞定的复杂场景比如一个跨页的表格、带合并单元格的报表、图文混排的杂志页面。第三它输出的是结构化内容而不是一堆坐标框加字符串解析结果可以直接用于分块和Embedding。但风险同样存在。首当其冲的是幻觉问题视觉语言模型在“看”一页版面时可能为了输出连贯的Markdown而脑补出原文没有的文字这种错误比OCR识别错字要隐蔽得多也危险得多。其次是成本与延迟高分辨率页面的推理时间通常在几秒到十几秒如果文档有几百页批处理的时间和费用都会非常可观。最后是数据安全问题把内部合同、涉密资料传給第三方云端API对很多企业来说是不可接受的。我的建议是内部数据优先用本地模型或者开源方案外部公开数据可以放心使用云端API所有数据即便走了云端也不要直接对接生产环境。2.4 我的混合策略本地工具链做主力多模态做兜底在真实项目里我不会把全部数据压在某一条路线上而是用一套混合策略。默认流程是先用传统工具链做快速解析比如用PyMuPDF提取文本层对没有文本层的页面再用PaddleOCR兜底。对这一轮解析结果做质量打分凡是被检测到“文本密度异常”“表格坐标错位”“段落顺序混乱”的页面单独抽出来送到多模态模型做第二次解析。这样既控制了成本和延迟又能把复杂的边缘case交给能力更强的模型处理。具体打分规则可以很朴素检测每个页面的文本长度是否显著低于正常值表格单元格数量是否异常页面内文本块是否有大面积重叠。出现这些特征时说明传统工具已经处理不动了交给多模态模型往往能救命。这个策略跑下来整体解析成本能降低一半以上同时保证了解析质量的底线。3. PDF解析工具选型九种工具逐一拆解3.1 文本型PDF的常规武器PyPDF2、pdfplumber、pdfminer.six先聊三个最基础的文本提取工具它们处理的对象是“有文本层的PDF”。PyPDF2以及它的新版本pypdf是我最早接触的库API很简单两三行代码就能把一整个PDF的文本抽出来。但它的问题也非常突出提取出来的文本基本不保留布局和顺序多栏文档会左右栏混排标题和正文的层级关系完全丢失。在RAG场景里它只适合做快速预览、获取元信息、或者对简单单栏文档做应急处理不适合作为正式解析方案。pyPDF 代码示例from pypdf import PdfReader reader PdfReader(sample.pdf) for page in reader.pages: text page.extract_text() print(text)pdfplumber是上一代工具里我最常用的一个它基于pdfminer.six封装提供了更友好的API尤其擅长提取文本坐标和表格。它的extract_table()方法对规则表格的识别相当准确配合page.to_image()可视化调试能够快速定位解析问题。但它也有短板处理多栏复杂版面时仍然会有顺序错乱当PDF页面超过几十页解析速度明显下降。适合做中小规模文档的精细解析不适合做全库批处理。import pdfplumber with pdfplumber.open(sample.pdf) as pdf: page pdf.pages[0] text page.extract_text() tables page.extract_tables()pdfminer.six是pdfplumber的底层依赖胜在可定制性极高能拿到每个字符的精确坐标、字体信息也可以通过自定义布局分析算法重建段落顺序。代价是API层级低上手成本高你需要自己写不少胶水代码。适合对解析精细度有极端要求的场景比如需要精确还原公文版面、或者需要处理复杂的读序逻辑。性能同样不突出。3.2 表格与版式向工具PyMuPDF、Camelot、tabula-pyPyMuPDFfitz是我现在批量处理PDF的第一选择没有之一。它是MuPDF的Python绑定底层是C语言实现的解析引擎速度非常快比pdfplumber快一个数量级。它提供page.get_text(dict)方法可以一次性拿回页面里所有文本块block、行line、字符span的坐标和内容这意味着你可以自己决定如何重组这些块而不是被动接受库的默认顺序。它还内置了将PDF页面渲染成图片的功能方便做可视化质检、把页面图传给多模态模型。import fitz doc fitz.open(sample.pdf) for page in doc: blocks page.get_text(dict)[blocks] for block in blocks: if lines in block: for line in block[lines]: text .join(span[text] for span in line[spans]) print(text)Camelot是专攻表格提取的工具它有两种模式lattice模式依赖表格线条来定位单元格适用于有明确边框的表格stream模式通过文本坐标推测行列适用于没有边框的表格。实测下来lattice模式对规范表格的提取效果相当好能输出近乎完美的表格结构。但它强依赖环境里的Ghostscript安装配置时会踩一些坑处理无边框或复杂嵌套表格时表现一般需要配合模式选择和参数调优。camelot read -p lattice -f table.pdf -o output.csvtabula-py是对Java开源项目tabula-java的Python封装底子很稳API设计也比Camelot简单。它对规则表格的抽取效果不错但不擅长处理版式复杂的PDF。另外它依赖Java运行环境部署时容易因为Java版本不匹配出问题。在RAG场景里如果数据源比较规整比如银行流水、库存报表tabula-py可以胜任但遇到杂志扫描版、手写表格还是直接绕开比较好。3.3 AI时代的解析工具LlamaParse、Marker、Unstructured传统工具链再强面对高度复杂的版面还是力不从心。这一节的三款工具已经开始把深度学习引入到PDF解析流程里对RAG场景的适配度非常高。LlamaParse是LlamaIndex团队推出的托管解析服务专为大模型知识库设计。你上传PDF它返回结构化的Markdown表格、标题、段落被整理得清清楚楚。我看过不少行业测评它对复杂表格的处理能力明显优于本地开源方案而且直接输出Markdown这一点很友好省去了大量的版式重组工作。代价是它是一个托管API文档内容会被发送到外部服务对数据敏感的场景不太合适。同为闭源方向它的定价是按页计算大规模批量导入时需要先算好预算。Marker是一款本地开源的PDF转Markdown工具基于深度学习做了版面分析和表格识别对标题、列表、表格、代码块的还原度非常高。它默认还会把公式用LaTeX格式输出这对学术论文类PDF非常有用。实测下来Marker对复杂版式的处理在这个类别里是最好的之一配合GPU加速后解析速度也能接受。如果你是技术团队可以考虑用Marker作为主力解析引擎输出Markdown后直接做切片。marker_single sample.pdf --output_dir ./outputUnstructured严格说是一个文档处理框架而不是单纯的解析库。它的核心能力是“分区”partitioning可以把PDF分割成标题、正文、表格、图片等不同元素并返回包含类型、文本、坐标、关联元数据的结构化对象。它和LangChain、LlamaIndex的集成做得很好几乎可以直接挂进RAG流水线。但它的表格提取能力相对普通复杂表格交给它处理容易被拆成零散的文本块。适合作为数据接入层的统一入口再配合其他工具做具体内容的精细解析。from unstructured.partition.pdf import partition_pdf elements partition_pdf(sample.pdf, strategyhi_res) for element in elements: print(element.category, element.text)3.4 一张表看透九种工具的定位工具文本提取表格处理扫描件OCR复杂版式批量速度集成难度适合场景PyPDF2/pypdf能用差不支持差中低快速预览、简单文本pdfplumber精细较好不支持中慢低中小文档精细解析pdfminer.six精细差不支持中慢高自定义版式重建PyMuPDF快且可控一般不支持较好极快低批量解析主力Camelot不适用强规则表不支持中中中带边框表格提取tabula-py不适用较好不支持中中中需Java规整表格提取LlamaParse强强内置强快托管低对数据脱敏要求低的项目Marker强强内置很强中需GPU中本地高质量通用解析Unstructured一般一般可选中中低分块、接入LangChain管道这张表是我对这九种工具的直观感受不代表所有场景的绝对结论。选择工具时先明确自己的核心矛盾是“速度”“精细度”“表格准确率”还是“数据隐私”再对照找答案会比迎面扑上来就编程高效得多。4. 从单页测试到全量入库一套可复用的实战流程4.1 先探测文档类型再决定解析路径批量导入PDF的第一件事不是直接调用某个解析库而是先写一个文档类型探测函数。判断逻辑很简单用PyMuPDF尝试从每一页提取文本统计整篇文档的总字符数。如果总字符数很低比如单页平均不足50个字符基本可以认定是扫描件如果某些页有文本、某些页没有那就是混合文档如果文本量正常但存在大量重复文本模式很可能碰到了双层PDF。这一步说起来简单却能避免后面的解析结果混乱。我见过太多项目把自己的扫描件数据交给纯文本工具去跑最后入库的结果全是空字符串也有把双层PDF同时跑了两遍OCR导致向量库里全是重复文本。import fitz def detect_pdf_type(path): doc fitz.open(path) total_chars 0 per_page_chars [] for page in doc: text page.get_text(text).strip() char_count len(text) per_page_chars.append(char_count) total_chars char_count if total_chars 200: return scan zero_text_pages sum(1 for c in per_page_chars if c 20) if zero_text_pages len(doc) * 0.3: return mixed return text4.2 分流处理文本型、扫描件、复杂表格各走各的路探测完类型之后就把文档分流到三条处理流水线里。文本型文档直接用PyMuPDF解析把每个页面拆成结构化文本块记录每块的坐标、字体大小和阅读顺序。这个过程我会额外做一步把字体大于正文的块标记为标题把坐标位于页面边界的文本块标记为页眉页脚并在入库时丢掉保证后续切片不会被“第X页”“公司内部资料”这类信息污染。扫描件文档走PaddleOCR路线。流程是先把页面渲染成高分辨率图片然后调用PP-Structure输出Markdown格式的结构化内容。注意渲染分辨率至少要150dpi否则小字号文字识别率会显著下降。这一步的输出结果和文本型文档一样统一成一个包含正文、标题、表格的JSON结构。复杂表格文档单独走Camelot或者Marker。如果表格有明确边框Camelot的lattice模式效果很好如果版式复杂、有无框线和合并单元格用Marker做整体版面分析更稳妥。处理完的表格不要直接转成文本塞进切片器而是保留为结构化的列表或者HTML表格后续Embedding阶段可以针对表格做专门的序列化。4.3 缓存解析结果与断点续跑批量导入不重复造轮子批量跑解析的时候最容易忽略的是“幂等性”。一个文档解析失败修改了参数重新跑结果前面的几百个已解析文档也被重复处理了一遍白白浪费时间。我的做法是在流水线里加一个简单的缓存层对每个文档计算SHA1哈希以哈希为文件名把解析结果存成JSON。每次解析任务开始时先检查缓存目录如果已经存在对应哈希的结果文件就直接复用。这样即使中途宕机、参数调整、单页重试都不会导致大规模重复计算。配合日志系统记下每个文档的解析状态、耗时和异常信息批量导入的可观测性就基本齐了。4.4 质量抽检与失败样本回收入库前的最后一关全量解析跑完之后不能直接入库得先做质量抽检。我的建议是按文档类型分层抽样每类至少抽5%的页面人工肉眼核对原图与解析文本的对应关系。这里强烈推荐用PyMuPDF的页面渲染功能把原始页面转成PNG图再用pdfplumber的可视化能力把提取出的文本块坐标画到图上一眼就能看出文本是不是错位、表格有没有串列。如果抽检发现问题把对应页面重新走一遍多模态大模型解析或者调整工具参数后重跑只处理失败样本不用全部推翻重来。这一步看起来繁琐但对于RAG项目而言入库数据质量直接决定最终应用效果投入的时间完全值得。4.5 入库前的最后一步保留原文与元数据解析结果的最终存储结构我建议至少包含三部分清洗后的结构化文本、对应的源文件路径与页码、原始页面渲染图路径。很多团队只存了文本丢掉了原文引用信息结果做文档问答时无法给出可靠的溯源依据产品说服力大打折扣。保留源文件和页面图还能在后续抽检、重解析、标注数据集时提供底气。5. 这些年在PDF解析上踩过的坑以及我现在的推荐组合5.1 常见坑合集双层PDF、跨页表格、文本重复双层PDF重复文本这是非常隐蔽的问题。扫描件底层是图片顶层有OCR透明文本层直接用文本工具提取时会把顶层的识别文本拿到手。但这个文本层可能是机器自动生成的里面往往是重复字符、错位内容和底层图片内容并不完全一致。如果这时候再做一次OCR等于把“错误文本”又识别一遍结果自然雪上加霜。我的判断方法是检测提取出的文本中是否存在大量相邻重复、坐标重叠的内容一旦发现就只保留一条解析路径并把顶层文本与OCR结果做一次相似度比对取置信度更高的一方。跨页表格被拆成两个表很常见的坑。一份财务报表在一个页面的末尾开始下一页面继续很多工具会把它当成两个独立表格处理。进入Embedding后同一个表的语义被切开查询“一季度总资产”时只能命中后半张表丢失表头信息。我现在会在解析层面对表格做“跨页合并”检测到上一页最后一行和下一页第一行具有相同的表头结构或列数时把它们拼接成同一个表格对象再交给下游。文本乱序问题即便是PyMuPDF提取文本时坐标排序逻辑如果没写对多栏文档的读取顺序也会乱。正确做法是以文本块block的左上角Y坐标为主序、X坐标为辅序先按区块排序再处理栏内阅读顺序而不是直接遍历坐标列表。5.2 我现在的推荐组合对于大部分RAG项目我目前的主力组合是“PyMuPDF PaddleOCR Marker”。文本型文档交给PyMuPDF快速提取扫描件交给PaddleOCR做中文识别和表格还原复杂版面交给Marker出Markdown最后再统一转成一套标准JSON结构入库。如果是数据敏感度不那么高的项目我会用LlamaParse替代Marker作为兜底理由很简单——托管API省心解析质量也确实顶得住。这个组合不是一步到位的。最早我尝试过纯PyMuPDF跑全量结果扫描件废了一半后来又在全量数据上跑了PaddleOCR速度太慢还经常把双层PDF识别出重复文本被折腾得不行。经过几个项目的实战调整才逐渐收敛成现在这套混合方案的形态。5.3 后续可以怎么扩展解析环节稳定之后再往下走就是分块策略和Embedding优化了。这部分内容我后面会继续整理但有一点现在就可以说解析效果直接影响分块质量如果你在分块阶段发现“同一主题的内容散落在不同的块里”先别急着调分块算法回头检查一下解析工具的输出顺序和表格处理逻辑。很多时候问题不在分块而在解析层的文本已经失去了语义连续性。数据解析在整个RAG链路里看起来是最底层、最不起眼的活儿但它决定了你上层所有优化能不能生效。我现在接手任何RAG项目都会先让团队把数据导入阶段的文档类型统计和解析结果抽检补上再谈模型选型和向量库调优。