1. 为什么图文与 PDF 解析是 RAG 系统最容易被低估的环节做过 RAG 项目的人大多有个共同体会向量库选型、检索策略、重排序模型这些上层建筑讨论得热火朝天但真正让系统效果拉胯的往往是数据导入这一层。尤其是当你的知识库里混进了扫描件、产品手册、财报 PDF、带表格的技术文档、甚至带公式的学术论文时纯文本抽取那一套就直接歇菜了。我前后搭过三套不同规模的 RAG 知识库从个人文档助手到企业内部制度问答踩得最狠的坑几乎都集中在 PDF 解析这一段。一份 200 页的产品手册用普通工具抽出来是一堆乱码加错位的表格一份扫描版合同文字层根本不存在不做 OCR 就是空白一份带流程图的运维手册图里的关键信息全丢了检索时用户问那个流程图里第三步是什么直接答不上来。这些问题不是靠换个 embedding 模型能解决的根子就在解析环节。这篇是RAG 数据导入与解析系列的第二篇专门聊图文和 PDF 这两块硬骨头。核心要解决三件事第一扫描件和图片里的文字怎么可靠地提取出来OCR 路线第二图表、公式、版面结构这些非纯文本信息怎么保留多模态大模型路线第三市面上九种主流 PDF 解析工具到底该怎么选各自的适用边界在哪。适合正在搭 RAG 知识库、被 PDF 折磨过的工程师也适合刚入门想少走弯路的朋友。我会把每种方案的原理、实操代码、参数选择、踩坑经验都摊开讲尽量让你看完就能直接抄作业。先说一个贯穿全文的判断没有万能工具只有匹配场景的组合拳。你不可能指望一个工具同时搞定高清扫描件、复杂表格、多栏排版和公式识别正确的做法是先对文档做分类再针对每一类走不同的解析管线。这个思路后面会反复出现。2. 图文解析的两条技术路线传统 OCR 与多模态大模型2.1 传统 OCR 路线的能力边界与适用场景传统 OCR 的本质是检测文字区域 识别字符它输出的是纯文本流对版面结构的理解非常有限。这条路线成熟、便宜、速度快但有几个硬伤你得心里有数。第一个硬伤是版面丢失。OCR 引擎通常按行或按块返回文字多栏排版的 PDF 被 OCR 之后左右栏的文字可能被交错拼接读起来前言不搭后语。表格更惨行列关系直接塌缩成一串文字原本某产品 2024 年 Q3 营收 1.2 亿这种结构化信息变成产品 2024 Q3 营收 1.2 亿散落在不同行检索时语义完全对不上。第二个硬伤是对图像质量极度敏感。倾斜、阴影、低分辨率、手写体、艺术字任何一个因素都能让识别率断崖式下跌。我实测过一批手机拍的问卷照片正面光照均匀的识别率能到 95% 以上稍微有点反光或者角度偏一点直接掉到 70% 以下而且错的地方往往是关键字段比如金额、日期。第三个硬伤是语言和字体覆盖。热词里有人提到OCR 代码识别不了韩文这就是典型的语言包问题。PaddleOCR 默认加载的是中英文模型要识别韩文得显式指定韩文识别模型否则它会把韩文字符当成乱码或者直接跳过。类似的问题在日文、阿拉伯文、以及各种特殊字体上都会出现。那传统 OCR 还有没有价值当然有。纯文字扫描件、票据、身份证、验证码这类场景传统 OCR 依然是最优解因为快、准、成本低。关键是你要清楚它的边界别拿它去啃复杂版面。2.2 多模态大模型路线让模型看懂而不只是认出多模态大模型比如能同时处理图像和文本的模型带来的最大变化是它不再把图片当成待识别的字符集合而是当成需要理解的内容。你给它一张财报截图它不只是把字读出来还能告诉你这是一张利润表第一列是项目名称第二列是本期金额第三列是上期金额其中营业收入同比增长了 15%。这条路线的优势非常明显版面理解、表格结构还原、图表语义描述、公式识别它都能干。对于 RAG 来说这意味着你可以把一张复杂的图表转成一段结构清晰的文字描述再去做 embedding检索命中率会高出一大截。但代价也很实在。第一是成本多模态模型的调用费用远高于传统 OCR一张图几毛钱到几块钱不等文档量大起来账单很吓人。第二是速度单张图的推理时间通常是秒级批量处理几千页文档得有耐心。第三是稳定性大模型会有幻觉偶尔会脑补出图里根本没有的内容这在财务、法律这类严谨场景里是致命的。所以我的建议是多模态大模型用在高价值、低数量的文档上比如核心制度文件、关键合同、重要图表海量的普通文档还是走传统 OCR 或者规则解析把成本压下来。2.3 两条路线怎么选一张决策表说清楚维度传统 OCR多模态大模型输入类型纯文字扫描件、票据、验证码复杂版面、表格、图表、公式输出形式纯文本流结构化文本 语义描述单页成本极低本地部署近乎为零较高按调用量计费处理速度快毫秒到秒级慢秒级到十秒级版面还原差好幻觉风险无有需校验适合场景大批量简单文档小批量高价值文档实操中的常见做法是混合管线先用轻量工具判断文档类型有没有文字层、是不是扫描件、版面复杂度如何再路由到不同的解析器。这个思路在后面的工具选型里会具体展开。3. 九种 PDF 解析工具选型实战3.1 工具选型的三个核心判断维度在列具体工具之前先明确选型的判断标准不然容易陷入哪个火用哪个的误区。我一般看三个维度。第一是文档类型适配度。你的 PDF 是原生电子版有文字层还是扫描版纯图片是单栏还是多栏有没有复杂表格和公式原生电子版用规则解析工具就够了扫描版必须上 OCR复杂版面得上版面分析或者多模态。第二是输出结构质量。好的解析工具应该输出带层级结构的 Markdown 或 JSON保留标题、段落、列表、表格的语义。如果只输出一坨纯文本后面还得自己写规则去切分工作量翻倍。第三是部署与成本。本地部署的工具比如开源的没有调用费用但要考虑硬件和维护成本云服务省心但有按量计费数据敏感的场景还得考虑合规。3.2 九种工具逐一拆解与适用边界下面这九种是我实际用过或者深度评估过的覆盖了从轻量到重量、从开源到商用的主要类型。我不按排名列按适用场景来分组说。第一类原生电子版 PDF 的快速抽取PyMuPDF也叫 fitz是我处理原生 PDF 的首选。它速度快、依赖少、能拿到文字、图片、坐标、字体信息。对于有文字层的 PDF几行代码就能把全文抽出来。缺点是它不做版面理解多栏文档抽出来顺序会乱表格也还原不了。适合做预处理和快速验证。pdfplumber 在表格抽取上比 PyMuPDF 强不少它能识别表格的线条和单元格边界输出结构化的表格数据。我处理财报里的数据表基本都用它。缺点是速度慢大文档处理起来有点磨人。PyPDF2现在叫 pypdf是最基础的库功能有限主要用来做页面操作和简单文本抽取。现在新项目我基本不用了除非只是想把 PDF 拆页或者合并。第二类扫描件 OCR 解析PaddleOCR 是国内用得最多的开源 OCR 方案中文识别效果好支持多语言记得显式指定语言模型有版面分析能力。热词里那个识别不了韩文的问题就是因为没指定韩文模型。它的 PP-Structure 模块能做版面分析和表格识别对 RAG 很友好。Tesseract 是老牌开源 OCR语言包丰富但中文识别效果不如 PaddleOCR版面分析能力也弱。适合英文文档或者对精度要求不高的场景。第三类复杂版面与结构化解析MinerU原 PDF-Extract-Kit是这两年很火的开源方案专门针对学术论文和复杂版面能识别公式、表格、图片输出 Markdown。对科研类 RAG 知识库非常合适。Marker 是另一个开源选手基于深度学习模型做版面分析和文字识别输出质量高但显存占用大需要 GPU。Unstructured 是一个文档处理框架支持 PDF、Word、HTML 等多种格式能输出带元素类型标题、正文、表格的结构化数据。它的定位是通用文档 ETL适合做统一的数据导入管线。第四类多模态大模型解析这一类没有固定工具名指的是调用多模态大模型 API 来做解析。适合高价值文档能输出语义化的描述。成本高需要做结果校验。第五类商用 PDF 编辑器/解析服务像福昕、搜狗 PDF 编辑器这类工具主要面向人工编辑场景OCR 语言包需要单独下载热词里提到的 ocr-zh-cn.fzip 就是福昕的中文语言包。它们不太适合做自动化批量解析但在人工校对环节有用。3.3 工具组合的推荐配置基于上面的分析我给两套推荐配置。轻量方案个人/小团队PyMuPDF 做原生 PDF 抽取 PaddleOCR 做扫描件 OCR pdfplumber 处理表格。全本地部署零调用成本适合文档量不大、预算有限的场景。进阶方案企业/大批量Unstructured 做统一入口和类型路由 MinerU 处理复杂版面 多模态大模型处理高价值文档。这套组合覆盖全面但需要一定的工程投入和 GPU 资源。4. 从零搭建图文与 PDF 解析管线4.1 环境准备与依赖安装先把基础环境搭起来。我习惯用 conda 建独立环境避免依赖冲突。conda create -n rag-parse python3.10 -y conda activate rag-parse # 基础 PDF 处理 pip install pymupdf pdfplumber pypdf # OCR 方案 pip install paddlepaddle paddleocr # 如果有 GPU装 GPU 版本 # pip install paddlepaddle-gpu paddleocr # 复杂版面解析 pip install magic-pdf[full] # MinerU 的包名 # 通用文档处理 pip install unstructuredPaddleOCR 第一次运行会自动下载模型国内网络可能慢可以提前配置模型下载源。MinerU 对显存有要求建议至少 8G 显存纯 CPU 也能跑但很慢。4.2 文档类型自动识别与路由这是整个管线的第一道关卡判断文档该走哪条解析路线。核心逻辑是先看有没有文字层再看版面复杂度。import fitz # PyMuPDF def analyze_pdf(pdf_path): 分析 PDF 类型返回路由建议 doc fitz.open(pdf_path) total_pages len(doc) text_pages 0 total_chars 0 for page in doc: text page.get_text().strip() if len(text) 50: # 有实质文字内容 text_pages 1 total_chars len(text) doc.close() text_ratio text_pages / total_pages if total_pages 0 else 0 avg_chars total_chars / text_pages if text_pages 0 else 0 if text_ratio 0.8 and avg_chars 200: return native # 原生电子版走规则解析 elif text_ratio 0.2: return scanned # 扫描件走 OCR else: return mixed # 混合型逐页判断这个判断逻辑的关键参数是text_ratio和avg_chars。阈值不是死的我一般把文字层比例 0.8 作为原生文档的门槛低于 0.2 判定为扫描件。中间地带就是混合型需要逐页处理。实测下来这套判断对绝大多数文档都准偶尔有误判的比如文字层是乱码的伪原生 PDF可以在后续环节加校验。4.3 原生 PDF 的高质量文本抽取原生 PDF 用 PyMuPDF 抽取但要注意保留结构。直接get_text()拿到的是纯文本标题和正文混在一起。更好的做法是用get_text(dict)拿到带字体、字号、坐标的块信息再根据字号大小判断标题层级。def extract_native_pdf(pdf_path): doc fitz.open(pdf_path) result [] for page_num, page in enumerate(doc): blocks page.get_text(dict)[blocks] for block in blocks: if block.get(type) ! 0: # 跳过图片块 continue for line in block.get(lines, []): for span in line.get(spans, []): text span[text].strip() if not text: continue font_size span[size] # 根据字号判断层级字号大的当标题 if font_size 16: level # elif font_size 13: level ## else: level result.append({ page: page_num 1, text: text, size: font_size, level: level }) doc.close() return result字号阈值16 和 13需要根据具体文档调整不同模板的标题字号不一样。我的经验是先抽几页看看字号分布再定阈值。这个方法的局限是遇到用加粗而非字号区分标题的文档会失效那种情况得结合字体名比如是否包含 Bold来判断。4.4 扫描件的 OCR 解析与多语言处理扫描件走 PaddleOCR。针对热词里提到的韩文识别问题关键是初始化时指定语言。from paddleocr import PaddleOCR # 中文文档 ocr_zh PaddleOCR(use_angle_clsTrue, langch) # 韩文文档 ocr_ko PaddleOCR(use_angle_clsTrue, langkorean) # 英文文档 ocr_en PaddleOCR(use_angle_clsTrue, langen) def ocr_image(img_path, langch): ocr PaddleOCR(use_angle_clsTrue, langlang) result ocr.ocr(img_path, clsTrue) texts [] for line in result[0]: text line[1][0] confidence line[1][1] if confidence 0.7: # 过滤低置信度结果 texts.append(text) return \n.join(texts)use_angle_clsTrue会启用方向分类能处理旋转的文本对扫描件很有用。置信度阈值 0.7 是我常用的过滤线低于这个值的识别结果错误率明显偏高宁可丢掉也别污染知识库。对于 PDF 扫描件得先把每页转成图片再 OCR。PyMuPDF 可以直接渲染页面为图片def pdf_to_images(pdf_path, dpi200): doc fitz.open(pdf_path) images [] for page in doc: # dpi 越高越清晰但处理越慢 pix page.get_pixmap(dpidpi) img_bytes pix.tobytes(png) images.append(img_bytes) doc.close() return imagesDPI 的选择是个权衡。200 是常用值清晰度和速度平衡得不错扫描质量差的文档可以提到 300但处理时间会明显增加。低于 150 的话小字容易糊识别率下降。4.5 复杂版面与表格的结构化还原表格是 RAG 解析里最头疼的部分。pdfplumber 的表格抽取能力不错但需要调参。import pdfplumber def extract_tables(pdf_path): tables [] with pdfplumber.open(pdf_path) as pdf: for page in pdf.pages: page_tables page.extract_tables({ vertical_strategy: lines, horizontal_strategy: lines, snap_tolerance: 3, join_tolerance: 3, }) for table in page_tables: # 转成 Markdown 表格方便后续 embedding md_table to_markdown(table) tables.append(md_table) return tables def to_markdown(table): if not table or not table[0]: return header | | .join(str(c or ) for c in table[0]) | separator | | .join([---] * len(table[0])) | rows [] for row in table[1:]: rows.append(| | .join(str(c or ) for c in row) |) return \n.join([header, separator] rows)vertical_strategy和horizontal_strategy设为lines表示按表格线识别适合有边框的表格。没有边框的表格得改成text策略靠文字对齐来推断准确率会低一些。snap_tolerance和join_tolerance是容差参数表格线不规整时可以适当调大。把表格转成 Markdown 是个很实用的技巧因为 Markdown 表格保留了行列结构embedding 之后检索某产品某季度的营收这类问题命中率会高很多。相比之下纯文本流里的表格数据基本检索不出来。4.6 多模态大模型处理高价值文档对于图表、公式、复杂版面这类传统工具搞不定的内容上多模态大模型。核心思路是把页面渲染成图片连同提示词一起发给模型让它输出结构化的 Markdown。import base64 def multimodal_parse(image_bytes, client): img_b64 base64.b64encode(image_bytes).decode() prompt 请将这张文档图片转换为结构化的 Markdown 格式。 要求 1. 保留标题层级用 # ## ### 表示 2. 表格用 Markdown 表格还原保持行列对应 3. 图表用文字描述其内容和关键数据 4. 公式用 LaTeX 表示 5. 不要添加图片中不存在的内容 response client.chat.completions.create( modelyour-multimodal-model, messages[{ role: user, content: [ {type: text, text: prompt}, {type: image_url, image_url: {url: fdata:image/png;base64,{img_b64}}} ] }] ) return response.choices[0].message.content提示词里那句不要添加图片中不存在的内容很重要能一定程度上抑制幻觉。但即便如此关键数据还是得做校验尤其是数字。我的做法是把多模态输出的数字和传统 OCR 的结果做交叉比对不一致的标记出来人工复核。4.7 解析结果的清洗与分块解析完不等于能直接入库还得清洗和分块。清洗主要处理 OCR 噪声乱码、多余空格、断行、页眉页脚、页码这些干扰内容。分块则决定了后续检索的粒度。import re def clean_text(text): # 去掉连续空白 text re.sub(r\s, , text) # 去掉常见页眉页脚模式 text re.sub(r第\s*\d\s*页, , text) text re.sub(rPage\s*\d, , text) # 修复被 OCR 拆断的英文单词 text re.sub(r(\w)-\s(\w), r\1\2, text) return text.strip() def chunk_by_structure(elements, max_chunk_size500): 按结构分块标题作为分块边界 chunks [] current {title: , content: []} for elem in elements: if elem[level]: # 是标题 if current[content]: chunks.append(current) current {title: elem[text], content: []} else: current[content].append(elem[text]) # 内容过长时切分 if sum(len(c) for c in current[content]) max_chunk_size: chunks.append(current) current {title: current[title], content: []} if current[content]: chunks.append(current) return chunks按结构分块比固定长度分块效果好很多因为标题天然是语义边界。每个 chunk 带上所属标题作为上下文检索时语义更完整。max_chunk_size设 500 字左右是个经验值太大检索不精准太小语义不完整。5. 常见问题与排查技巧实录5.1 OCR 识别率低的排查思路OCR 识别率低是最常见的问题排查要按顺序来。先看图像质量把页面渲染的 DPI 提上去试试很多时候就是分辨率不够。再看语言设置中文文档用了英文模型、韩文文档没指定韩文模型都会导致识别失败。然后看预处理倾斜的图片先做纠偏有阴影的先做二值化PaddleOCR 内置了部分预处理但效果有限必要时用 OpenCV 自己处理。还有一个容易被忽略的点是字体。某些 PDF 用了特殊嵌入字体渲染出来是正常的但 OCR 引擎没见过这种字形识别率就低。这种情况只能换引擎或者上多模态。5.2 表格解析错位的典型原因表格解析错位通常有三个原因。一是表格没有边框线靠文字对齐推断行列时容易串行解决办法是调大容差参数或者改用多模态。二是单元格内有换行pdfplumber 会把一个单元格拆成多行需要在后处理时合并。三是跨页表格表格被分到两页需要识别并拼接。跨页表格的处理比较麻烦我的做法是检测页面顶部和底部是否有表格线有的话尝试和相邻页拼接。5.3 多模态大模型幻觉的识别与抑制多模态幻觉的表现是输出里出现了图里没有的内容或者数字被改了。识别方法是交叉验证用传统 OCR 的结果做对照重点核对数字、专有名词。抑制方法除了提示词约束还可以要求模型对不确定的内容标注不确定或者分两次调用取一致结果。但最靠谱的还是关键字段人工复核别全指望模型。5.4 常见问题速查表问题现象可能原因排查方向OCR 输出乱码语言模型不匹配检查 lang 参数识别率突然下降图像 DPI 过低提高渲染 DPI 到 300表格行列错位无边框或单元格换行调容差或换多模态多栏文字交错版面分析缺失用带版面分析的工具多模态输出幻觉模型脑补交叉验证 人工复核处理速度极慢纯 CPU 跑深度学习模型上 GPU 或换轻量方案公式识别成乱码工具不支持公式用 MinerU 或多模态5.5 几个我踩过的坑第一个坑是盲目追求高 DPI。有次为了提升识别率把 DPI 拉到 600结果处理时间翻了四倍识别率只提升了不到 2 个百分点。后来发现 200 到 300 是性价比最高的区间再高收益递减严重。第二个坑是忽略 PDF 的加密和权限。有些 PDF 设了复制限制PyMuPDF 直接抽会报错或者抽出来是空的。这种情况得先检查文档权限必要时用有权限的账号重新导出。第三个坑是分块时把表格切碎。早期我用固定长度分块一个表格被切成好几段检索时只能命中半张表。后来改成表格整体作为一个 chunk问题就解决了。表格、代码块、公式这类结构化内容分块时一定要保持完整。第四个坑是没做解析结果的抽样校验。批量处理几千页文档总有一些页面解析失败或者质量很差如果不抽样检查这些脏数据会悄悄污染知识库等到检索效果差的时候再回头查成本就高了。我的做法是每批随机抽 5% 人工看一眼发现问题及时调整管线。6. 管线性能优化与批量处理建议6.1 并行化与缓存策略文档量大起来串行处理会慢到无法接受。我的做法是按文档类型分组原生 PDF 用多进程并行CPU 密集OCR 和深度学习模型用 GPU 批处理。PyMuPDF 的抽取是 CPU 密集型的用multiprocessing能线性提速PaddleOCR 和 MinerU 走 GPU靠批处理提升吞吐。缓存也很关键。解析结果按文件哈希缓存同一个文件重复处理时直接读缓存。开发调试阶段这个能省大量时间因为调分块策略时不用反复跑解析。6.2 质量监控与增量更新生产环境的解析管线得有质量监控。我一般记录几个指标解析成功率、平均每页字符数、OCR 平均置信度、表格识别数量。这些指标突然异常就说明有问题。增量更新则是只处理新增或修改的文档靠文件哈希和修改时间判断避免全量重跑。6.3 不同规模场景的配置建议个人用几十到几百份文档轻量方案足够本地跑跑就行。团队用几千到几万份建议上 GPU 服务器把 OCR 和复杂版面解析集中处理。企业级几十万份以上得考虑分布式处理和任务队列把解析、清洗、分块、入库拆成独立服务各自扩容。我个人在实际操作中的体会是解析管线的投入产出比在 RAG 项目里被严重低估了。大家愿意花时间调检索和重排却不愿意在数据导入上多花两天结果就是垃圾进垃圾出。把解析这一层做扎实后面很多检索不准的问题会自然消失。最后分享一个小技巧建一个解析质量样本集挑几十份有代表性的文档各种类型、各种质量每次调整管线都拿它跑一遍对比效果比盲目调参靠谱得多。