先说个有意思的现象搜索框里“rag知识库能存储图片嘛”这个问题被问了无数遍但大多数人的困惑点其实不在向量库而在更靠前的解析环节。图片当然能存进知识库但真正进Embedding和检索链路的是图片解析后的文本或结构化描述而不是像素矩阵本身。这个认知不清会让整个RAG项目的资料接入阶段就埋下隐患。这篇文章是RAG数据导入与解析系列的第二篇上一篇聊完纯文本数据的清洗和分块这次集中解决两块硬骨头一是图片内容的解析二是PDF这种“容器型”文档的解析。文章会覆盖OCR与多模态大模型两条图文解析路线的差异也会把市面上常用的九种PDF解析工具逐个拉出来横向对比最后给出一套可以直接照抄的自动路由导入链路和排坑记录。如果你正在做一个涉及扫描件、合同、论文、产品手册的知识库项目这篇应该能帮你少走不少弯路。1. RAG管线里的图文数据到底卡在哪一步1.1 知识库能存图片但存的不是“图片”RAG的核心机制是向量检索而向量检索的质量取决于Embedding模型对内容的语义表达能力。如果直接把图片的二进制数据或像素矩阵扔进Embedding模型得到的向量几乎不携带业务语义检索出来的结果自然没法用。虽然市面上有CLIP、SigLIP这类多模态Embedding模型但它们对文本和图片的语义对齐能力有限主流RAG框架和向量库对多模态检索的支持也远没有纯文本检索成熟工程上落地成本很高。所以在实际项目里几乎所有人都采用同一条路径图片先解析成文本文本再分块、Embedding、入库。搞清楚这个前提再回头看“知识库能不能存图片”这个问题结论就很明确——能存但存进去的是解析出来的内容和描述。图片本身最多作为附件保留在元数据里供前端展示和溯源用。这也意味着图文解析是整个RAG项目里离业务语义最近、最值得投入的一环。图片里如果有一句话被OCR漏掉或者一个表格被解析散架后面分块再精细、向量模型再先进也都难以补救。1.2 PDF是容器不是单一文件格式很多新手会把PDF当成一种“文本文件”直接用某个库一把梭提取文本结果发现有的PDF提取出来是空的有的全是乱码有的格式完全错乱。原因很简单PDF是一种容器格式内部可以混装多种内容对象。一份PDF里可以同时存在文字层、嵌入字体、矢量图形、位图图片、表格线条、注释、书签、表单域。更麻烦的是同一份PDF的不同页可能是完全不同的东西——前两页是扫描图片第三页是Word导出的文字版第四页是CAD打印的矢量图。哪怕同一页里也可能左边是清晰文字右边是一张带文字的截图。这种复杂性决定了没有任何一款工具能包办所有PDF。选型时必须在“提取文字层”和“走图像OCR”两条路线之间做判断甚至同一份文档要混合使用两种策略。这也是为什么PDF解析工具多如牛毛但每个工具都有明确短板的原因。1.3 解析质量直接决定RAG上限RAG项目的效果瓶颈很多时候不在模型参数、不在Prompt调优而在于喂进去的文本本身就是残缺的。我用一个例子说明某合同扫描件里关键条款写在一个表格中如果用常规PDF文本提取表格结构被完全打散条款内容变成了一串没有边界的文字分块时上半句和下半句被切到两个块里检索时问“违约金的计算方式”返回的块只有半句话。这种问题靠后面的检索优化根本救不回来。所以图文解析的产出物不能是简单的“把字提出来”而应该是保留标题层级、段落边界、表格结构、阅读顺序的结构化文本。常见的做法是统一输出为Markdown或带层级标签的JSON让后续的文本分块器能感知文档结构而不是面对一坨打散的字符流。2. OCR与多模态大模型两条图文解析路线的真实边界2.1 OCR路线成熟、便宜但拿到的只是“字符流”OCR光学字符识别是这个领域最成熟的方案。PaddleOCR、Tesseract、百度OCR、阿里OCR都属于这一类。它们的核心能力是把图片里的文字区域识别成可编辑文本部分OCR还附带版面分析能力能识别标题、段落、表格的粗略位置。OCR路线的优势非常明显速度快、成本低、可本地部署。PaddleOCR在中文场景的识别精度相当能打而且是开源免费一张普通发票的识别耗时通常在毫秒级到秒级跑在普通CPU上就能完成任务。对于纯扫描件、截图、拍摄照片这类内容OCR是性价比最高的选择。但OCR路线的天花板也很清晰它拿到的本质上是“字符流”不是“结构”。即便带版面分析OCR对复杂表格、跨栏排版、图文混排的理解仍然有限。表格里的单元格归并、表头层级、文字阅读顺序常常会被OCR破坏。另外一个隐藏问题是语言覆盖——PaddleOCR默认中文模型很强但如果文档里有韩文、日文混合或者少数民族语言缺模型的情况下就会直接识别失败甚至输出乱码。这一块后面排坑章节会专门展开。2.2 多模态大模型路线能看懂版式但成本和速度要想清楚多模态大模型GPT-4o、Qwen-VL、InternVL等是近两年图文解析的新变量。它们和OCR最大的区别是模型不仅能识别文字还能理解版式逻辑和语义。给一张复杂的合同首页多模态模型能输出带标题层级和表格结构的Markdown给一张产品功能截图它能理解哪部分是小标题、哪部分是正文、哪部分是注释。这种能力在解析复杂图文混排、表格嵌套、票据、论文首页时优势非常明显。我实测过一份带复杂表格的论文PDFPaddleOCR把表格内容全部打散成一行行文本而Qwen-VL直接输出了规整的Markdown表格后续分块完全不用额外处理。代价同样明显慢、贵、上下文有限。多模态模型的推理耗时远高于OCR批量处理几百页文档时成本要精打细算同时大模型的输入窗口有限一个长PDF往往要拆成多页分次解析然后再拼接这个拼接过程如果不注意容易丢内容或产生重复。所以多模态路线适合“重度文档、精度优先”的场景不适合“海量文档、成本敏感”的场景。2.3 选型不是二选一混合策略与判断标准做了几个项目之后我的体会是图文解析极少需要“纯OCR”或“纯多模态大模型”走到底更实用的做法是混合策略。一个比较通用的判断标准是文档里文字密度高、结构简单合同正文、报纸文章、纯扫描页——用OCR就够文档里表格复杂、图文混排、版式有强逻辑论文、产品手册、报表截图——用多模态大模型或OCR叠加LLM后处理。此外还有一类场景是OCR先做初筛、再用LLM做结构化提取例如OCR识别出整页文字后用Prompt让LLM按字段抽取出合同编号、甲方、乙方、金额、日期。对比维度OCR路线多模态大模型路线解析速度快批量友好慢页级推理单页成本低可本地免费高按Token或按次计费中文识别强强表格结构理解弱易散架强能输出Markdown版式与阅读顺序依赖版面分析模型自然理解多语言覆盖依赖语言模型包容易漏配模型本身覆盖广部署难度低PaddleOCR一键装高大显存或走API这里要特别提醒混合策略不是“OCR一把梭再扔给LLM”而是要根据页面复杂度动态决定。最简单的落地方式是把所有页面先走一遍OCR统计每页的文本密度和表格线数量如果某页文本量极低、图片占比极高再单独走多模态模型。这样既控制成本又保证复杂页面的解析质量。3. 九种PDF解析工具横评选型表与场景判断3.1 先看总表再按场景对号入座PDF解析工具多到让人眼花但真正被高频使用的就那么几款。我把它们分为三类掌管不同场景文本层提取类、表格提取类、图像OCR类再加上几个新锐的深度学习解析工具。先给一张总表再逐个说人话。工具类型核心能力明显短板pypdfPyPDF2文本层提取合并拆分、文本抽取、元数据读取复杂排版、表格、扫描件无能为力PyMuPDFfitz文本层提取极快文本图片注释全量读取表格结构不感知pdfplumber文本层坐标表格区域识别、字符坐标定位扫描件需搭配OCR速度一般Camelot表格专用基于线框的表格精确还原无线表格识别差依赖Ghostscriptpdf2image OCR图像OCR扫描件/图片型PDF全页识别版面结构弱需后处理OCRmyPDF图像OCR扫描PDF转可搜索PDF本质是OCR前端不做语义理解Unstructured解析全家桶多格式统一接口自带分块依赖重版本兼容问题多Marker深度学习解析高质量版面还原为Markdown模型大速度慢显存要求高MinerU深度学习解析公式、表格、双栏版面综合解析部署门槛偏高资源消耗大3.2 工具逐个说优点、短板、适用场景pypdf纯Python实现适合做PDF的合并、拆分、旋转、加密解密和简单文本提取。它的extract_text()在干净的文字版PDF上表现稳定但不要指望它处理复杂排版。我通常用它做PDF的预处理比如把一个几百页的PDF按目录先拆成多个独立文件再用其他工具精解析。PyMuPDFfitz这是我用下来速度最快的文本层提取库。它的C语言绑定让页面文本读取速度比pypdf快一个量级而且除了文本还能提取图片、矩形框、链接和注释。在处理数字原生的PDF由Word、LaTeX导出时用它提取文本几乎是首选。缺点是它只认文字层不认图片里的字对表格也没有结构感知。pdfplumber它的强项是字符级别的坐标定位。你可以拿到每个字符的坐标、字体大小、行宽等细节并基于这套坐标自定义规则还原表格。对带明显线条的规整表格pdfplumber的识别效果很好。但它的速度偏慢处理上百页文档时能明显感觉到卡顿。Camelot表格专项选手。它通过分析页面的线条结构还原表格单元格对有线表格的还原精度很高输出还很方便。Camelot有两个模式lattice依赖表格线stream依靠文本相对位置。它的硬伤有两个一是无线表格基本抓瞎二是需要系统里装Ghostscript环境配置麻烦。pdf2image OCR这不是单一工具而是组合方案——先用pdf2image把PDF每页转成PNG图片再交给OCR引擎识别。对扫描件和图片型PDF来说这是最直接的路。PaddleOCR是这套组合里我最常用的OCR引擎中文识别率高还支持方向分类可以处理旋转扫描件。OCRmyPDF它的定位是“把扫描PDF变成带文字层的可搜索PDF”。本质上它是在PDF每一页的底层偷偷叠加一层透明文本让原本只能图片预览的文件可以被搜索、复制。这个中间产物非常实用我常常把它当作质量追溯的“中间格式”保留下来方便人工校验解析结果。Unstructured野心很大的解析全家桶目标是统一处理PDF、Word、HTML、PPT等多种格式输出结构化文档并内置了分块逻辑。它的好处是接口统一一个函数就能完成“加载分区分块”写项目时开发效率很高。坑也明显依赖包极多版本升级频繁不同版本之间结果差异大锁定版本后最好别随便升。Marker基于深度学习模型的PDF解析工具能把PDF还原成接近原始排版质量的Markdown对标题层级、列表、粗体斜体的还原都做得不错。论文、网页导出的PDF用它解析效果很好。但模型体积大首次推理要加载不少资源CPU上跑速度很感人建议有GPU再考虑。MinerU这个工具中文名叫“解析利器”是开源社区里热度很高的新秀。它对公式、表格、双栏版面、阅读顺序都有专门的模型处理解析教科书、论文这类学术文档效果突出。MinerU提供的magic-pdf命令行工具封装得不错一条命令就能完成单篇解析。缺点是部署有门槛Python环境和模型下载要先折腾一阵资源占用也偏高。3.3 特别提醒在线转换工具与敏感文档聊工具选型时必须插一句市面上大量“PDF转Word”“PDF在线转换”网站虽然方便但不适合处理敏感文档。合同、发票、内部报告这类文件一旦上传到第三方服务器就脱离了你的控制。做RAG知识库的手里往往有一堆业务核心资料安全和隐私是第一位的。我的习惯是本地优先能本地跑的工具就本地跑PaddleOCR、PyMuPDF、MinerU都能离线使用。只有本地实在跑不动的超大模型推理比如用多模态大模型精解析才通过API走云端而且事先要把可直接识别的隐私字段脱敏或单独审批。这一条建议虽然老套但踩过坑的人都懂它的价值。4. 实战组装按文件特征自动路由的PDF→知识库导入链路4.1 第一步探测文件特征不做无脑解析一份资料进来不应直接丢给某个工具而是先探明它的底细。我通常会做三个层面的探测文件类型、是否含文字层、图片占比。这三个结果决定了后续走哪条解析管线。文件类型好理解PDF、图片PNG/JPG、Word各走各的路。关键是PDF内部的探测——用pypdf或PyMuPDF抽取每页文字如果某一页能抽到足够多的文字说明这页有文字层可以直接走文本提取如果几乎抽不到文字说明是图片型页面需要走OCR或图像解析。from pypdf import PdfReader def detect_pdf_style(pdf_path, threshold50): reader PdfReader(pdf_path) styles {text_pages: 0, image_pages: 0, total_pages: len(reader.pages)} for page in reader.pages: try: text page.extract_text() or except Exception: text if len(text.strip()) threshold: styles[text_pages] 1 else: styles[image_pages] 1 return styles这个函数按页统计文字量超过阈值就认为是文字页否则是图片页。如果一个PDF里两种页面都有那就按页切分、分别走不同解析器最后再合并结果。4.2 第二步按路由结果调用不同解析器探测完成之后接下来就是组装解析管线。我目前最常用的一条本地管线长这样文字页用PyMuPDF提取全文图片页用pdf2image转成图片再交给PaddleOCR最终所有页统一输出为Markdown。下面是一段简化但可运行的核心逻辑基本能应付大部分混合型PDFimport fitz from pdf2image import convert_from_path from paddleocr import PaddleOCR ocr PaddleOCR(use_angle_clsTrue, langch) def parse_mixed_pdf(pdf_path, dpi180): doc fitz.open(pdf_path) output_parts [] for page_index, page in enumerate(doc): text page.get_text().strip() if len(text) 50: output_parts.append(f## 第{page_index 1}页\n\n{text}) else: images convert_from_path(pdf_path, first_pagepage_index 1, last_pagepage_index 1, dpidpi) img images[0] result ocr.ocr(img, clsTrue) page_text [] if result and result[0]: for line in result[0]: page_text.append(line[1][0]) output_parts.append(f## 第{page_index 1}页\n\n \n.join(page_text)) return \n\n.join(output_parts)代码逻辑不复杂逐页判断文字层有文字的直接提取没文字的OCR。这里有一个参数值得注意dpi180是pdf2image转图时的分辨率。DPI太低小字会糊OCR准确率直线下降DPI太高图片体积膨胀处理速度变慢。实测下来180到220是一个很好的平衡区间。如果你手里的PDF是学术论文这类版式复杂的建议直接上MinerU它对公式、表格、双栏的处理比“PyMuPDFOCR”的简易方案高一个级别。我的经验是把MinerU当作“复杂文档专用通道”和通用管线并存由路由层统一调度。4.3 第三步统一输出Markdown再做结构化分块不管走哪条管线最终产物统一成Markdown的好处非常多。Markdown天然表达标题层级、列表、表格、代码块而这些恰好是文本分块器最需要的结构信息。后续切分时可以基于#和##识别章节边界基于表格行做细粒度切块比面对一坨纯文本要优雅得多。我给自己定过一个统一的解析产物规范每页一个二级标题段落之间空行表格用标准Markdown表格语法图片在原文出现的位置保留占位标注类似[图片-第3页]方便溯源。这样设计之后后面的分块环节只需要做一件事读入Markdown按标题层级递归切块。import re def markdown_to_blocks(md_text, max_chars800): lines md_text.split(\n) blocks [] current_block [] current_len 0 for line in lines: if re.match(r^## , line) and current_block: blocks.append(\n.join(current_block)) current_block [] current_len 0 current_block.append(line) current_len len(line) if current_len max_chars: blocks.append(\n.join(current_block)) current_block [] current_len 0 if current_block: blocks.append(\n.join(current_block)) return blocks这套简单的切块逻辑严格以标题为边界块与块之间不会把章节内容切开。如果业务上需要更精细的语义切分可以把Markdown转成JSON再按段落和表格行动态组装成不同粒度的块。5. 排坑实录韩文识别失败、扫描件乱码、表格散架与文件格式报错5.1 PaddleOCR识别不了韩文先查语言模型聊到OCR排坑最常见的疑问就是“PaddleOCR识别不了韩文/日文请问怎么设置”。我见过不少人在用PaddleOCR做多语言识别时直接翻车怎么调参数都没用。这里要先弄明白PaddleOCR的语言机制。PaddleOCR的识别能力是分语言模型打包的不是装一个包就自带全球语言。要用韩文识别必须在初始化时指定langkorean并且要确认模型列表里有对应的韩文识别模型。如果只是把lang参数改了但模型没下载、没配置识别结果自然就是空或乱码。from paddleocr import PaddleOCR # 韩文需要在运行时单独下载对应模型 ocr PaddleOCR(use_angle_clsTrue, langkorean)踩坑点在于PaddleOCR首次运行会尝试自动下载模型这个下载过程依赖网络环境模型文件较大时容易中途失败而且失败后不会给出明确报错只会默默识别失败。解决方案是手动到官方模型库下载对应语言的检测、分类、识别模型放到~/.paddleocr/whl/目录下对应位置再初始化就不会触发自动下载。识别之前最好先准备一张纯韩文的测试图跑一遍确认模型真的加载成功再进入批量管线。5.2 Tesseract中文乱码语言包与字符集问题Tesseract是老牌OCR引擎但中文用户直接用它处理中文文档时经常遇到一个结果识别出来的中文全是乱码或者干脆显示方块。原因也很朴素——Tesseract默认只装英文语言包没有中文语言数据。处理方式是在安装时额外下载chi_sim语言包。Windows安装包可以勾选中文语言组件Linux下可以单独安装tesseract-ocr-chi-sim包。指定语言时用langchi_simeng可以同时识别中英文。另外Tesseract对图片质量异常敏感低分辨率、有噪点的扫描件直接丢给它准确率会跌到没法用的程度。我很少在正式RAG管线里用Tesseract处理中文它的英文、数字、印刷体识别还行中文场景PaddleOCR是更省心的选择。5.3 百度OCR返回file format error二进制传参的坑很多人调用百度OCR等云服务时会看到类似error_msg: file format error的报错。这个错误看起来像是文件格式不被支持但实际排查下来八成是请求参数里传图片的方式不对。百度OCR的接口要求图片要么传base64编码后的字符串要么传图片的URL。如果你直接把本地文件的二进制内容塞进请求体或者base64编码时没有去掉换行符、直接把整个bytes对象往里扔服务端就会报文件格式错误。一个稳健的处理姿势是读取文件、做base64编码、把字节串转成字符串、去掉换行符再放进请求参数。import base64 import requests with open(invoice.jpg, rb) as f: img_base64 base64.b64encode(f.read()).decode(utf-8) resp requests.post( https://api.example.com/ocr, json{image: img_base64}, headers{Content-Type: application/json}, ).json()这里有个容易忽略的细节有些图片本身没问题但因为扫描后保存成了CMYK格式或16位深的PNG云端OCR服务不支持也会报文件格式错误。遇到这种情况最省事的办法是先用Pillow把图片统一转成RGB模式的JPEG或8位PNG再走API基本能消掉这类报错。5.4 表格散架与图片型PDF的连锁问题表格散架是RAG图文解析里最隐蔽的坑。表面看OCR识别出的每行文字都对但表格原本的“字段名——值”对应关系被彻底打断了。比如一份发票OCR输出的是连续几行文本金额、税率、税额的位置关系全部丢失分块之后检索“这张发票的税率是多少”返回的块里根本没有完整的信息对。应对思路无非两条线上表格清晰、有线框的用Camelot或pdfplumber按坐标提取表格复杂或无线框的直接把整页图片交给多模态大模型输出Markdown表格。如果必须用OCR至少要在后处理阶段根据字符坐标做行合并和单元格拼接而不是直接把OCR的每一行当作独立文本。图片型PDF的另一个连锁痛点是页数爆炸。一本几百页的扫描书每页都是一张大图OCR一张张跑下来不仅耗时还容易在中间页出现内存压力。我的做法是把PDF先按页拆成多个小批次每批20-30页分批OCR、分批写盘最后再合并。这样既避免一次性加载过多图片导致内存溢出也方便在出错时定位到具体批次重新跑。最后的几点体会图文解析在RAG项目里是最容易翻车、但也是最值得投入精力的环节。我见过太多团队把大量时间花在调Embedding模型和Prompt上却忽略了资料接入阶段“Garbage in, garbage out”的铁律。实际上一个文档解析管线的合理程度对最终检索效果的影响远大于你对检索代码的微调。我在实际项目中沉淀了一个小技巧始终保留一个“可搜索PDF”中间产物。用OCRmyPDF这类工具把扫描PDF转成带透明文字层的版本一方面方便人工用PDF阅读器搜索核对另一方面遇到解析质量争议时可以直接定位到原始页面做对比省去了重新翻原始文件的尴尬。这个习惯在批量导入大量扫描件时尤其有用。最后想说的是工具选型没有银弹不同文档类型、不同业务场景下的最优解差异很大。最稳妥的做法是搭一套多通道路由管线让文件特征自己决定走哪条解析路径而不是试图用一把锤子敲所有的钉子。这篇文章里的方案都是我踩过坑、也验证过能落地的路线你可以根据自己的硬件条件和数据特征做裁剪但有一点别省解析结果一定要保留结构和溯源信息。这一步做扎实了后面的RAG整个链路都会轻松很多。