★ FEATURED ARTICLE 做RAG项目最让人上火的环节是什么如果有人说是Embedding调参我还能理解但根据我自己接手过的几个知识库项目真正能把人逼疯的永远是数据导入前那道解析关卡尤其是PDF和图片。文本型PDF还算有救一旦遇到扫描件、拍歪的合同照片、带跨页表格的年度报表你写好的清洗规则全部失效检索出来的内容经常是缺字、乱码、顺序颠倒。这篇是RAG数据导入与解析全攻略系列的第二篇上篇我们把纯文本和Markdown类数据的清洗讲完了这篇集中解决图文与PDF解析。核心就三件事OCR怎么选、多模态大模型什么时候用、以及市面上常见的九种PDF解析工具该怎么挑。适用对象是正在搭RAG知识库、做文档问答、或者做内容私有化检索的工程师。1. 先给PDF和图片分分类你的解析方案会跟着形态走很多人在解析PDF时一上来就选工具结果工具换了一堆还是解析不好。我的建议是先别急着抄代码拿几份真实文档看一眼给它们分个类。分类维度很粗暴页面上到底有没有可复制的文字层以及版面里是单栏还是多栏、有没有跨页表格。1.1 文本型PDF有文字层但未必好拿文本型PDF一般由Word、LaTeX或网页打印生成页面里每个字符都有对应的文本坐标。理论上用PyMuPDF一句page.get_text()就能拿到全文但实际项目中坑不少。最典型的问题是字体编码。某些PDF为了兼容特殊字体会嵌入只有内部映射的编码get_text()返回的可能是乱码或空白。这时候你得去读PDF的字体对象和CMap或者干脆放弃这一页用渲染成图片再OCR来兜底。我在一个政府公开文件项目里就遇到过文件看着是纯文字复制到记事本全变成方框最后用OCR解决了。另外文本型PDF不一定有正确的阅读顺序。双栏排版、页眉页脚、脚注浮层提取出来的文本经常是左栏一段、右栏一段交错出现。所以后续我得用坐标信息做排序和版面归并这部分在第4章工具选型里会具体展开。1.2 扫描件/图片型PDF必须走OCR或视觉模型扫描件本质上是图片集合PDF里没有文字层或者只有一层透明的假文字层。这种文件只能通过OCR或视觉模型把图像转成文本。常见来源是传真件、老旧档案、手机拍摄的实体文件。这类文件最让人头疼的不是识别不出字而是识别出来的文本没有结构。原文里明明有标题、段落、表格、批注OCR只给你的是一串连续的token流。你把它直接切块丢进向量库检索时经常匹配到错位的内容。所以扫描件解析不能只做字符识别还得做版面分析至少要能把标题、正文、表格单元区分开。这也是为什么我更推荐带版面恢复能力的OCR方案比如后面会讲到的PP-Structure、Surya或Marker。1.3 混合型与复杂版面真正的硬骨头实战里大量PDF是混合形态一半页面有文字层一半页面是扫描图片或者一页里有文字、有图表、有表格、有页眉页脚。最典型的就是券商研报、产品手册、招股书。这种文档的价值恰恰藏在复杂的版式里。表格数据如果只提取成凌乱的纯文本RAG在回答某年营收是多少时就会答非所问。正确做法是用版面识别把页面划分成不同区域再按区域类型走不同管线文字区走文本提取、图表区生成描述、表格区用表格识别模型转成Markdown或HTML。后面第5章的实战流水线就是按这个思路搭的。2. OCR选型Tesseract、PaddleOCR和云OCR的分工OCR这个领域开源和商业方案都很多。每次有人让我推荐最好的OCR我都得反问你的文档主要是中文还是西文是印刷体还是手写体有没有表格要不要保留版面这些问题的答案比任何一个单一指标都重要。2.1 三套方案的实测差异先说Tesseract。它是HP实验室开源的老牌引擎社区生态成熟支持语言多但它在中文场景的识别精度、表格支持、复杂背景抗干扰上已经明显落后。我拿一批清晰的中文扫描件对比过Tesseract在规范宋体上的单字准确率约85%-90%一旦遇到行内公式、下划线或印章错字和漏字率立刻上升。适合的场景是西文文档、简单印刷体、对精度要求不高的批量处理。再说PaddleOCR百度开源目前在中英文、表格、版面分析上优势明显。它自带方向分类器、文本检测、文本识别三个模块还提供了PP-Structure做版面分析和表格还原。对国内RAG项目来说PaddleOCR基本是首选开源方案。我实测一份夹杂手写批注的表格扫描件PaddleOCR的表格还原准确度在90%上下基本可以直接进下游解析。云OCR指的是百度、腾讯、阿里这类在线接口。优点是模型更新快、支持票据、证件、手写等垂直场景缺点是数据出境、费用、并发限制。如果文档涉及敏感业务数据我不建议直接传云端。但如果只是几百份临时授权文件云OCR的效率和精度确实比自建要好。2.2 图像预处理比换引擎更划算很多人OCR效果差第一反应是换引擎其实大部分问题出在前置图像质量上。同样的PaddleOCR原图方向歪5度识别率可能就下降20%。预处理几个常用动作用OpenCV做灰度化、二值化去掉彩色背景对检测的干扰。透视校正尤其针对手机拍摄件用四点变换把页面拉正。提高渲染分辨率。PDF转图片时PyMuPDF的pixmap分辨率建议至少200dpi扫描件我通常用300dpi。分辨率不够小字号直接糊掉。去噪和去线但不建议过度有些表格识别需要保留框线。import cv2 import numpy as np def preprocess_image(img_path): img cv2.imread(img_path) gray cv2.cvtColor(img, cv2.COLOR_BGR2GRAY) # 简单二值化 _, binary cv2.threshold(gray, 0, 255, cv2.THRESH_BINARY cv2.THRESH_OTSU) return binary这步做完再进OCR效果往往比换一个更高级的识别引擎更明显。2.3 一个直接可以改的PaddleOCR流程PaddleOCR的接口不同版本有差异。我这里给一个2.x/3.x时代比较通用的思路具体跑了要看你装的版本。# 安装 pip install paddlepaddle paddleocrfrom paddleocr import PaddleOCR # langch 表示中文模型 ocr PaddleOCR( langch, use_doc_orientation_classifyTrue, # 方向分类 use_doc_unwarpingTrue, # 弯曲矫正 use_textline_orientationTrue # 文本行方向 ) result ocr.predict(scan_page.png) for res in result: # 新版返回结果通常带rec_texts、rec_scores、dt_polys for text, score in zip(res[rec_texts], res[rec_scores]): if score 0.6: continue print(text)注意PaddleOCR 3.x把很多参数挪到了TextDetection、TextRecognition里建议直接看官方文档再调。核心点是一次调用同时拿到检测框坐标和文本后续可以按坐标做版面排序。如果你只想要纯文本忽略坐标也没问题但如果要恢复多栏结构坐标就非常重要。2.4 云OCR什么时候才是正解云OCR的价值在于省事。自建PaddleOCR虽然不用花钱但要处理依赖环境、GPU、模型更新、并发能力。对非技术团队或一次性需求云OCR反而更划算。比如做一个企业内部合同问答系统合同量不大上传到云OCR识别字段拿JSON结构化结果一天就能上线。我自己的建议是划分三条线批量大、数据敏感、要长期迭代的走自建PaddleOCR或基于它的二次开发清晰且量小的西文文档Tesseract够用需要识别手写、发票、特定版式的再考虑云OCR而且尽量做数据脱敏。3. 多模态大模型OCR的上限在这里被突破OCR再强碰到复杂图表、拍照歪斜严重、手写批注混排的情况也会麻爪。多模态大模型可以直接把图片看成结构化内容这给RAG数据导入打开了一条完全不同路径。3.1 适合多模态模型处理的文档类型我目前用到多模态模型的主要是四类复杂表格比如合并单元格、斜线表头、跨页重复表头传统工具容易拆错视觉模型能直接理解表格语义。图表与截图折线图、柱状图、流程图OCR识别不了图形含义多模态模型可以生成一段文字描述让后续检索能命中2023年营收增长趋势这类语义。手写批注与印章合同里的手写备注、增值税发票上的印章字迹模糊但人类能猜模型也能猜及格。严重畸变的扫描件透视变形、折叠阴影传统OCR预处理后仍然残破大模型反而能靠上下文推断。典型开源/闭源组合包括GPT-4o系列、Qwen-VL系列、InternVL、MiniCPM-V等。如果数据敏感本地部署至少要有70B以上参数的模型才谈得上复杂版面理解效果和延迟都需要做取舍。3.2 提示词设计决定输出质量让多模态模型读PDF页面提示词不能只写提取文本。我项目里常用的一种提示词模板是你是一个文档解析引擎。请逐页分析图片输出严格JSON { page: 页码, blocks: [ {type: title|paragraph|table|chart|header|footer|image, content: 该区块的完整文本表格用Markdown格式, description: 如果type为chart或image用一句话说明图表表达了什么} ] } 要求 1. 不要补充原文没有的信息。 2. 识别不出的字符用[?]标记不要猜测。 3. block顺序必须符合阅读顺序。关键是强制JSON格式、强制区块类型、强制未知则标记能显著减少模型编造字段的问题。实际使用中发现模型偶尔会漏掉页脚或脚注所以抽查和阈值过滤还是不能省。3.3 成本控制和混合策略多模态模型不是免费的午餐。单页截图动不动消耗上千tokens批量处理几百页文档费用比OCR高一个数量级。更重要的是延迟本地部署的视觉模型单页推理可能要几秒到十几秒不适合高吞吐场景。我用的策略是分级路由先用快速OCR和规则判断页面复杂程度普通页面走轻量管线只有当检测到表格、图表、低置信度等情况才把页面发给多模态模型。这样可以兼顾成本和质量。比如先跑一遍PaddleOCR如果行数超过50且存在长度异常的表格框就标记为疑似复杂版面再送多模态。3.4 多模态输出如何入库RAG多模态模型输出的JSON不能直接怼进向量库。我的处理方式是先按block类型拆成节点title节点保留作为后续父子块的元数据table块里的Markdown转成带结构的分行文本每行一个chunk太小一般整个表格作为一个chunkchart或image块则保留description作为可检索文本同时把原图路径放进metadata。# 伪代码把多模态JSON转成检索单元 for block in vis_result[blocks]: if block[type] in (table, paragraph, chart): chunks.append({ text: block[content] or block[description], metadata: {page: page, type: block[type]} })这样既保住了语义检索能力也保留了原文档的位置信息后面做引用溯源会方便很多。4. 九种PDF解析工具横向对比与选择建议市面上PDF解析工具非常多但真正适合RAG数据管线的不多。我按轻量文本提取、表格专项、智能文档解析、深度学习转Markdown四个梯队挑九种常用工具做了对比。4.1 九种工具一表看清工具定位核心能力适合场景主要局限pypdf / PyPDF2轻量文本提取合并、拆分、简单get_text快速抽取纯文本PDF无版面分析复杂排版易乱序PyMuPDF (fitz)综合PDF处理文本、坐标、渲染图片、搜索文本坐标PDF转图片表格语义提取能力弱PDFMiner.six底层布局解析字符坐标、版面对象需要精细坐标控制的文本上手慢API较底层pdfplumber表格/字符提取精确字符框、表格线识别规则表格、数据抽取复杂合并单元格支持一般Camelot表格专项lattice/stream双模式提取规整表格转DataFrame依赖PDFMinerOpenCV跨界表格易断Unstructured智能文档解析分区block、集成LangChainRAG预处理流水线中文复杂版面效果不稳LlamaParse托管解析服务表格/版面结构化输出复杂文档、长文档云端解析数据出域按量付费MarkerPDF转Markdown深度学习版面检测OCR高质量转换、保留结构消费较高需要GPUMinerUPDF转Markdown版面/公式/表格识别学术论文、技术文档中文模型体积大部署较重4.2 轻量文本派pypdf / PyMuPDF / PDFMiner.six如果你只是想把干净的PDF变成纯文本pypdf足够。它代码量最小几行就能提取全文但别指望它帮你处理双栏。PyMuPDF是我的默认选择因为它除了文本还能拿到每个词块的坐标和字体信息这些信息在做版面还原时太有用了。比如判断标题直接看字体大小是否明显大于正文。PDFMiner.six更底层暴露了完整的布局对象。它适合需要精细控制的情况比如以字符级坐标重建表格。但学习曲线陡现在大部分项目我都用PyMuPDF只有在需要读取CMap或处理怪异字体时才翻PDFMiner。4.3 表格专项派pdfplumber / Camelotpdfplumber在字符精度上很优秀能拿到每个字符的bbox适合从发票、明细表里抽字段。它的extract_table()对有线表格效果稳定我在做财报数据抽取时第一选择就是它。Camelot的强项是知道哪些线属于表格。它有两种模式lattice依赖表格线适合有线框的规整表格stream依赖空白分隔适合没有完整线框的表格。但它依赖OpenCV的形态学处理对模糊扫描件效果一般。如果表格跨页Camelot会把两个页面的表格当成两个独立对象后续需要自己拼接。4.4 智能Document派Unstructured / LlamaParseUnstructured是LangChain生态里很常用的分区工具能把PDF划分成Title、NarrativeText、Table等块并自带清洗函数。它的中文效果不如英文但好处是能直接对接RAG框架省去很多胶水代码。LlamaParse是托管服务专门针对复杂版面做结构化输出表格会转成Markdown。它对常见业务文档的鲁棒性不错遇到超宽表格、多栏混排也基本能保持顺序。代价是数据要经过第三方且按页计费。我通常拿它做人力补充——本地管线解析不了的疑难文档统一发过去当第二通道。4.5 深度学习转Markdown派Marker / MinerUMarker把PDF渲染成图片后用检测模型识别版面再OCR文本最终输出Markdown。它输出的结构非常干净标题、列表、表格都能保留甚至能处理公式。缺点是好的效果依赖GPUCPU推理慢到没法用。MinerUOpenDataLab旗下在主攻学术论文和应用文档内置了公式识别模块对中文支持比Marker好。实际测试一份中文技术手册MinerU转出的Markdown层级基本不用改就能用。但部署体积大模型权重好几个G生产环境要考虑资源和初始化时间。这九个工具不是互相取代的关系而是要按文档类型组合使用。我的准则是先试PyMuPDF快速判断是否有文字层干净文本直接提取表格密集的用pdfplumber或Camelot扫描件和复杂版面交给Marker/MinerU或多模态模型。5. 一套完整实战流水线从混合目录到RAG文本块前面讲了很多选型和原理这一章给一套我实际在用的流水线。它解决的核心问题是一个目录下什么文档都有。5.1 先做文件路由判断该走哪条解析链路路由逻辑不复杂关键是别把所有文件都当成同一类。我的做法是先判断扩展名再判断PDF是否有文字层。import fitz def route_pdf(file_path): doc fitz.open(file_path) total_text for page in doc: total_text page.get_text() if len(total_text.strip()) 20: return scan_image # 无文字层走OCR/视觉 # 有文字层但含表格/多栏需要坐标级处理 return text_pdf这里阈值20是我拍脑袋定的你可以根据实际语料调整。重点是一旦判定为scan_image后续就不该再走PyMuPDF文本提取直接渲染成图片进OCR。5.2 解析、后处理与元数据保留文本型PDF解析后别急着入库。后处理三步我必做按阅读顺序重排文本块用坐标排序而不是依赖PDF内部顺序。识别标题层级PyMuPDF里文字块带size和flags把连续两行相同字号且字号大于正文的字块标记为标题。表格转Markdown方便LLM理解也方便DuckDB这类工具查询。元数据也很重要。我会给每个chunk记上source_file、page_num、chunk_typetitle/paragraph/table/chart、heading_path。这样到了RAG阶段既能做引用溯源也能实现按章节过滤的混合检索。5.3 切块策略别把表格和标题切碎了很多人切块只按固定字符数导致一个表格被拦腰截断检索时语义完全丢失。我更推荐先按文档结构分块标题块、段落块、表格块、图表描述块分开。表格块除非特别长否则整个作为一个chunk段落块按200-500字、重叠50字去切。def split_by_structure(blocks, max_chars500, overlap50): # 按title/paragraph/table分类 # 段落可继续切分表格、标题保持整体 ...实践中这样切下来的chunk召回准确率比纯字符切块高不少。原因很简单LLM回答表格问题时更希望拿到完整上下文而不是只能在半个表格上瞎猜。5.4 入库验证用召回测试反推解析质量解析质量好不好别靠肉眼。我一般建一个简单的评测集拿20-50个真实问题每个问题标记正确答案所在页码然后跑一遍RAG检索看前5个召回chunk是否包含正确答案。解析质量差时召回率会惨不忍睹解析质量提升后召回率会立竿见影。一个不起眼但很实用的检查项是把入库文本里的特殊字符统计一下比如\uFFFD、乱码方框、连续重复标点。这些往往是OCR或编码转换失败的表征直接按数量排序找最脏的几份文档即可。6. 我的避坑清单这些问题几乎每个项目都会遇到最后分享几个我真实踩过、且反复出现的坑。如果你能避开能省下大量调试时间。6.1 有文字层但是假文字层有些PDF自带OCR文字层但内容质量极差甚至和图像错位。我之前处理一份扫描合同PyMuPDF提取出的文字层全是数字和字母混排明显是旧OCR工具留下的垃圾。判断方法很简单把文字层和渲染出的图片叠在一起对比或者直接用置信度过滤。更省事的做法是凡是来源不可信的PDF都不要轻信文字层做一次快速OCR对比再决定。6.2 表格跨页与表格错位跨页表格是文档解析里的老大难。解决方案没有银弹我的办法是先用关键词或表格线判断上一页最后一行是否是表格尾部如果是就把跨页部分拼接到同一个chunk。Python里的做法是记录每个表格块coordinates跨页时若上一页底部区域和下一页顶部区域都存在表格线或相同表头则视为同一表格。实现大约几十行但能显著提升财报类问答的准确率。6.3 OCR重复符号与串行OCR输出经常出现、。。这类重复标点以及竖排文字、页边距噪声被串进正文。清洗时写一个正则去重规则import re text re.sub(r([。、])\1, r\1, text)还可以根据坐标过滤掉页眉页脚。很多扫描件页眉是第1页共5页检索词里出现第X页很干扰相关性。按固定区域裁剪后气味会干净很多。6.4 图片不放文字描述等于白放如果你直接把图片文件塞进RAG向量库Embedding模型只把图片当成一个文件名字符串基本检索不到。我的做法是用多模态模型给每张图片生成一句话描述再和图片路径一起入库。例如一张三相电路图描述成三相交流电路原理图包含电源、变压器、负载连接示意。这样用文字就能命中图片后续展示时再引用原图。如果检索需求真的必须用图片搜图片那就得引入CLIP这类多模态向量模型在工作流上是另一套方案。文本和图表混排的页面尤其要注意图表描述必须和所属章节标题绑定。这样用户问第四章的架构图时RAG能定位到第四章的文字上下文再顺藤摸瓜找到图片。我在实际项目里最大的体会是图文与PDF解析没有一招鲜的工具组合一切都要回到你的文档长什么样、问题会怎么问这两个基本问题上。每个坑背后都有一份具体文档在等着你先分类、再路由、后清洗比盲目堆模型可靠得多。
阅读完成 · 觉得有帮助？
