做 RAG 项目的人大概率都遇到过这样的尴尬文档库辛辛苦苦爬完了结果一查里面全是扫描件、盖章单据、带表格的 PDF 和花花绿绿的配图。直接丢给文本提取器吐出来的是乱码丢给 embedding 模型图片直接变成无意义的占位符狠一点上 OCR结果表格结构全丢检索回来的答案根本对不上号。这篇就是来解决这个问题的。作为 RAG 数据导入与解析系列的第二篇我把“图文内容怎么进知识库”这件事拆开聊透。我会讲清楚两条主线一是图片和扫描件怎么解析——传统 OCR 和现在流行的多模态大模型各有什么适用边界二是 PDF 解析工具的选型逻辑——我实测过一批主流方案最后会给出九种工具的优缺点和适用场景。全文基于我做过的真实项目该给的参数、该避的坑、该抄的作业都会交代清楚。1. 先搞清楚你的文档到底卡在哪一层很多人在数据导入阶段就翻车不是因为工具不行而是连自己要解析的内容属于什么类型都没想清楚。RAG 的数据源可以按解析难度粗略分几层每一层的处理策略完全不同。1.1 四层解析难度模型我一般把待解析的文档分成四层第一层纯文本型 PDF 或网页文字层完整直接提取即可这属于“白送分”。第二层带版式的 PDF有分栏、页眉页脚、表格文字层虽然存在但提取逻辑要考虑阅读顺序和结构还原。第三层扫描型 PDF 和图片只有图像没有文字层必须走 OCR 或视觉模型解析。第四层内容里掺杂大量图表、公式、票据、手写体普通 OCR 搞不定需要具备版面理解能力的专业模型或工具组合。在动手选工具之前我建议你先抽样 20 到 50 个代表性文件跑一遍简单的文本层检测用pypdf直接抽取文本如果抽出来的字数接近总页数乘以每页平均字数的水平说明至少有一层文本可用如果抽出来几十个字甚至空白那基本锁定是扫描件或纯图片。这一步的价值在帮你提前判断后面所有工具选型和策略设计都不会跑偏。1.2 解析失败往往不是模型问题而是前置策略问题我见过不少团队在 OCR 和模型上反复调优效果始终上不去最后发现根因是路线错了。举个例子一个合同文档库里前面十几页是扫描件后面几页是电子签章页。有人直接上多模态大模型整本解析每页都要走视觉推理慢且贵效果还不稳定。更合理的做法是先把文档按页切分逐页检测文字层覆盖率分类路由——有文本层的走快速提取没有的才走 OCR 或视觉模型。我把这种思路叫“先分类、后解析”。这不仅省时间省预算更关键的是它能让你对不同质量的输入分别做阈值设置。比如扫描件允许一定的字错误率纯文本页则要求高保真提取。分类路由的思路会贯穿全文所有方案。2. 图片解析OCR 与多模态大模型的分工与选型图片解析是 RAG 导入里最容易被低估的一环。实际项目里图片往往不是简单的“有没有字”的问题而是“字在什么位置、什么版式、什么背景下”的问题。处理图片本质上是在做“版面理解”而不是“文字抠取”。2.1 传统 OCR 的适用场景与局限传统 OCR 这些年进化得非常快以 PaddleOCR、Tesseract、商用云 OCR 为代表。它们各自有鲜明的优缺点工具擅长场景明显的短板推荐度PaddleOCR中文、印刷体、标准票据、轻量部署复杂版面、表格结构还原弱开源首选Tesseract英文、多语言基础识别中文版式理解弱需大量调参备选百度/腾讯云 OCR营业执照、身份证、手写体、高精度识别有成本和数据外传顾虑商用场景搜狗OCR等桌面工具单张图片、低频率需求不适合批量自动化日常辅助传统 OCR 的真正问题有三个一是丢版面。识别出来的文字是一个一个“块”块与块之间的关联关系、表格行列属性、阅读顺序需要你自己用坐标信息重建。很多工具导出的是带bbox坐标的 JSON但后续重建版面的工程量不小。二是抗干扰能力有限。深色背景、印章文字叠压、艺术字体、斜排文字识别率会明显下降。印章叠字这个问题我实测过 PaddleOCR 和多家云 OCR在合同类文档上普遍识别得七零八落。三是和 RAG 检索的目标冲突。RAG 要的是语义单元而不是文字流。OCR 结果如果只是大段吐字出来没有结构后续拆分和向量化效果会很差。所以单纯上 OCR 并不能解决 RAG 的问题它必须搭配版面后处理。2.2 多模态大模型图片解析的“新解法”多模态大模型比如 Qwen-VL、GPT-4o、Claude 等视觉版本给图片解析带来的是一种范式改变。它们不只是从图片里抠文字而是能理解整张图的语义结构这是一个表格表头是什么哪几行是数据这是一个产品示意图箭头指向哪里旁边的标注对应什么内容。用多模态大模型解析图片的核心优势有三个直接输出结构化文本可以要求它输出 Markdown 表格、JSON 结构甚至是带语义的摘要。抗干扰强印章叠字、背景纹理、复杂版面视觉理解模型通常比传统 OCR 更稳健。自带语义解析结果可以直接作为 RAG 的 chunk 输入几乎不用再做二次清洗。当然也有代价速度慢、成本高。一张复杂图片可能耗时十几秒甚至更久token 费用随图片复杂度和模型规格上升明显。2.3 我的实战选型策略分级调用我的做法是建一个图片解析的“分级路由”简单图片、文字清晰、无表格用 PaddleOCR 或云 OCR 快速识别便宜且速度快。中等复杂度图片、有表格或简单版面先用传统 OCR 抽字再配合规则或小模型重建结构。复杂图片、票据稠密、版面混乱、需要上下文推理上多模态大模型一次性生成结构化输出。这个分级策略在实际项目里能省下 60% 左右的算力成本。有人问为什么不全部走多模态大模型核心原因是贵和慢。在每天要解析几万张图片的场景下全部走视觉模型要么预算爆炸要么延迟不可接受。补充一个参数参考我用 Qwen-VL 系列模型做表格图片解析时单图分辨率尽量保持 1024 以上温度调到接近 0指令里明确要求“按原表格结构输出 Markdown”效果要比默认参数稳得多。3. PDF 解析工具九选一实测体验与选型建议PDF 解析是 RAG 数据导入的重头戏。工具选错了要么解析得支离破碎要么在表格上彻底翻车。我梳理了当前主流的九种方案按使用场景分成三类轻量文本提取、重结构还原、商用与全能型。3.1 轻量文本提取类pypdf / pdfplumber / pdfminer.sixpypdf是原来的 PyPDF2 的继任者胜在极简几行代码就能把文本抽出来。优点是安装轻、依赖少、处理简单的文字型 PDF 非常快。缺点也很明显面对复杂版式它的输出顺序经常是乱的表格直接变一坨文字。pdfplumber是我个人最常用的工具之一。它把页面上的每个字符、线条、矩形都提取成带坐标的对象可以精确地按坐标重建布局。尤其适合处理有明确框线结构的表格能拿到表格的行列坐标再配合规则拼出结构化的二维数据。缺点是大文件处理速度偏慢内存占用高。pdfminer.six是底层解析库LTTextBox、LTFigure 这些对象层级可以让你精细控制布局分析。它的优势是灵活几乎每个解析环节都可以定制劣势是 API 偏底层开发效率不高。这三个工具都属于“要自己动手做后处理”的范畴适合文档结构相对规整、工程师愿意花时间调规则的项目。3.2 重结构还原类PyMuPDF / Camelot / MarkerPyMuPDFfitz是我在多数项目里的首选底座。它支持把每一页渲染成高清图片可以精确切割区域并导出还自带轻量文本提取功能。很多复杂的图片型 PDF我会先用 PyMuPDF 把页面渲染成 PNG再把图片交给 OCR 或多模态模型去解析。这种“PDF 转图片再转认知”的路线绕开了 PDF 内部文本层的各种兼容性问题。Camelot专注表格提取。它有两种模式Lattice 模式针对有框线的表格准确率非常高Stream 模式针对无框线、靠空白对齐的表格效果波动较大。Camelot 的强项是输出结构化表格数据非常适合财报、单据类 PDF。但它依赖 Ghostscript部署时容易被环境问题绊住。Marker是我近两年用下来最惊艳的开源项目之一。它能把 PDF 完整转换为 Markdown自动识别标题、段落、表格、图片引用同时生成对应的文本块级别的坐标信息。效果接近我理想中的“RAG 预处理神器”。它对运行环境要求不低最好有 GPU且大文件处理速度仍然偏慢但输出质量确实对得起算力开销。3.3 商用与 RAG 专用型Unstructured / LlamaParse / Adobe Extract APIUnstructured是 RAG 生态里被提及最多的工具。它的核心价值不是“解析”而是“把解析结果按 RAG 的需求切成元素块”比如 Title、NarrativeText、Table 这些类型还内置了表格提取和 OCR 支持。缺点是框架层级多部分模块抽象程度高一旦行为不符合预期排查成本略高。LlamaParse是 LlamaIndex 同门的云端解析服务支持解析复杂表格、嵌入图片和扫描件输出 Markdown。它在英文场景效果优秀中文场景我实测有波动但如果你的文档是英文财报、论文这个工具能省很多事。Adobe Extract API是 Adobe PDF 服务家族的 API 产品对版式还原和表格识别非常精准是工业界商用效果最好的封闭方案之一。缺点是收费、闭环生态也不太好做细粒度定制。下表是九种工具的一句话总结工具最佳场景不要用于pypdf快速抽文本、文字层完整表格、扫描件pdfplumber规整表格、坐标级布局分析超大文件、复杂嵌套版式pdfminer.six底层布局定制、科研级控制快速原型PyMuPDF页面渲染、区域裁剪、多模态配合结构化文本输出Camelot纯表格提取、财务单据无框线复杂排版Marker整本转 Markdown、RAG 高质量预处理弱机器上的批量任务UnstructuredRAG 生态内做文档元素切分追求极致表格精度LlamaParse英文复杂文档、云端快速集成中文复杂排版、成本敏感场景Adobe Extract API商业级版式还原、表格高精度预算有限、需深度定制3.4 选型决策树选型其实可以浓缩成几个问题文档有没有文字层没有就直接考虑 PyMuPDF 渲染图片 多模态或 OCR。表格重要吗重要就优先看 Camelot、Marker、Adobe Extract API。需要和 RAG 生态深度集成吗要就选 Unstructured能省掉大量清洗环节。预算和技术能力如何开源组合拳 PyMuPDF PaddleOCR Marker 通常够用且可控。有朋友问能不能只用一个工具解决所有问题。我的答案很明确不能迷信单一工具。真实文档千奇百怪一套组合策略远胜一个全能工具。我的默认组合是 PyMuPDF 负责渲染和文本提取Marker 负责整本高质量转换表格和复杂页面用多模态模型兜底这一套组合在中文合同、英文论文、财报场景都跑得很稳。4. 解析结果如何接入 RAG 流水线解析只是第一步解析完的文本怎么进入向量库、怎么保证检索质量是整个链路里更考验细节的环节。4.1 从解析结果到 Chunk 的关键处理解析输出通常要先做三件事清洗。去掉页眉页脚、页码、页眉横线、乱码字符。这一步看似无关紧要实际上对 embedding 效果影响很大。页眉页脚混入正文会导致 chunk 语义偏移尤其是页码这种高频无意义 token会稀释向量权重。切分。按语义单元切而不是按固定字数硬切。Marker 或 Unstructured 输出的块类型正好可以作为切分边界。表格通常单独成一个 chunk图片说明和正文分开。固定 512 字切分适合纯文本但对表格和图文混排是灾难。结构化补全。给每个 chunk 带上元数据比如来源文件名、页码、所属章节、文档类型。这不仅是追溯需要还能在检索时做基于元数据的过滤提升准确率。4.2 表格和 OCR 结果的“二次向量化”表格进 RAG 一直是个老大难。直接丢 Markdown 表格文本进去embedding 模型经常抓不住行列语义。我的做法是对表格做两次处理第一次把表格转成自然语言的描述比如“2023年Q2营收为3.2亿同比增长15%”这个描述会被向量化用于语义检索。第二次保留一份原始表格的结构化数据比如 JSON作为检索命中的“附件证据”。用户提问时先召回自然语言描述再联动附上原始表格效果要比单纯检索表格文本好很多。同理OCR 出来的结果如果只是文字流我也建议尽量做结构化重构后再入库。比如合同的结构是“甲方、乙方、金额、期限”OCR 识别后应该把这些字段映射成结构化键值而不是一段乱字。4.3 数据质量验证的四个指标RAG 的检索效果和入库质量强相关。我每次搭完解析流程都会跑一组质量验证覆盖率所有文档是否都被成功解析解析失败比例是否在可控范围准确率抽样对比原文和解析结果尤其是数字、金额、专有名词OCR 场景下错误率是否超标结构完整度表格行列是否对齐段落顺序是否正确大文档是否被错误切断检索命中率拿一批测试问题做召回验证看答案能否回回到正确的 chunk 上。这四个指标我会做成自动化的流水线每次数据更新后自动跑一轮一旦指标下跌就定位到是哪个环节出了问题。没有这一步后面的 RAG 效果再差你都不知道该从哪里排查。5. 常见问题与排查技巧实录把我在真实项目里踩过的坑整理成速查表这些都属于“文档里不会写、但实操一定会遇到”的问题。现象根因解决方案PDF 提取出来是乱码字体编码非标准缺嵌入字体改 PyMuPDF 渲染成图片后走 OCR 或视觉模型中文 OCR 准确率低未加载中文语言包PaddleOCR 默认支持中文Tesseract 需显式指定 chi_sim表格提取串行错位无框线表格用 Lattice 模式误判换 Camelot Stream 模式或用多模态模型重建多模态解析超时单图分辨率过大、模型输入限制先压缩到合适分辨率分块处理复杂版面扫描 PDF 整本解析慢每页都走 OCR无差别处理先检测文本层覆盖率分类路由只在无文本层页面走 OCR嵌入图片被直接丢弃解析工具默认忽略图片对象用 PyMuPDF 单独提取图片对象送 OCR 或视觉模型chunk 切分切断表格按固定字数切分不考虑语义边界表格单独成块配合自然语言描述二次向量化解析结果与原文对不上页码、页眉混入正文清洗阶段按坐标规则过滤页眉页脚再单独强调一个我在工程上反复遇到的坑多模态模型做 OCR 时如果把整页 A4 扫描件压缩到很小的分辨率复杂小字会糊成一团识别率骤降。我处理扫描件时的经验是先检测原始 DPI物理尺寸和文字密度的关系再决定缩放比例。单页 A4 扫描件通常保持 1024 到 1536 像素的宽度比较稳妥再低的清晰度省下来的成本都会变成返工成本。另一个容易被忽略的问题是格式间的边界 case。比如 PDF 里嵌入了扫描页面和文本页交错的情况很多工具会误判整本都是扫描件导致无谓的算力消耗。我采用的策略是按页分类统计每页字符数超过阈值判断为文本页否则进入 OCR 队列。这个过程对整本 PDF 按页拆分后做并行决策效率提升非常明显。工具链本身的工程细节也值得注意。PyMuPDF 渲染页面时matrix参数决定输出图片的分辨率默认值是 72 DPI输出很模糊我一般设置 2.5 到 3 倍缩放让渲染图保持 200 DPI 左右的清晰度。Camelot 解析表格之前必须确认 Ghostscript 是否正常安装否则会出现解不开或超时的神秘错误。Marker 跑大文档时建议按章节拆分后再处理避免内存溢出和排队过久。6. 最后分享一点个人心得做 RAG 数据导入和解析大部分时间其实不是在和算法作斗争而是在和各种奇奇怪怪的文档作斗争。不同客户、不同行业的文档千奇百怪你很难找到一套万年不变的配置所以“先分类、后解析、再验证”这个三步套路比任何单个工具都重要。我个人的体会是千万不要把解析这一步当成可一次性完成的离线任务。真实场景里文档库每周都在变今天新增几份扫描合同明天补一批带复杂表格的财报解析流程必须具备良好的可观测性和模块化设计。每类文档的解析结果好坏应该有独立的日志和评价指标而不是黑箱式地一股脑灌进向量库。最后再分享一个小技巧如果你做的是中文场景请特别关注表格型 PDF。中英文表格的排版习惯差异很大中文表格经常出现合并单元格、竖排表头、大段备注文字这对所有解析工具都是考验。我在遇到这种文档时通常会把它直接交给多模态大模型做结构化输出再人工抽检几页确认质量。实践证明这类“重难点文档单独特殊处理”的策略远比在通用工具上反复调参来得靠谱。 
长河君 · 2026/10/29 7:35:11 · 阅读 1.2k RAG图文解析指南：OCR与多模态大模型选型及PDF工具实测
做 RAG 项目的人大概率都遇到过这样的尴尬文档库辛辛苦苦爬完了结果一查里面全是扫描件、盖章单据、带表格的 PDF 和花花绿绿的配图。直接丢给文本提取器吐出来的是乱码丢给 embedding 模型图片直接变成无意义的占位符狠一点上 OCR结果表格结构全丢检索回来的答案根本对不上号。这篇就是来解决这个问题的。作为 RAG 数据导入与解析系列的第二篇我把“图文内容怎么进知识库”这件事拆开聊透。我会讲清楚两条主线一是图片和扫描件怎么解析——传统 OCR 和现在流行的多模态大模型各有什么适用边界二是 PDF 解析工具的选型逻辑——我实测过一批主流方案最后会给出九种工具的优缺点和适用场景。全文基于我做过的真实项目该给的参数、该避的坑、该抄的作业都会交代清楚。1. 先搞清楚你的文档到底卡在哪一层很多人在数据导入阶段就翻车不是因为工具不行而是连自己要解析的内容属于什么类型都没想清楚。RAG 的数据源可以按解析难度粗略分几层每一层的处理策略完全不同。1.1 四层解析难度模型我一般把待解析的文档分成四层第一层纯文本型 PDF 或网页文字层完整直接提取即可这属于“白送分”。第二层带版式的 PDF有分栏、页眉页脚、表格文字层虽然存在但提取逻辑要考虑阅读顺序和结构还原。第三层扫描型 PDF 和图片只有图像没有文字层必须走 OCR 或视觉模型解析。第四层内容里掺杂大量图表、公式、票据、手写体普通 OCR 搞不定需要具备版面理解能力的专业模型或工具组合。在动手选工具之前我建议你先抽样 20 到 50 个代表性文件跑一遍简单的文本层检测用pypdf直接抽取文本如果抽出来的字数接近总页数乘以每页平均字数的水平说明至少有一层文本可用如果抽出来几十个字甚至空白那基本锁定是扫描件或纯图片。这一步的价值在帮你提前判断后面所有工具选型和策略设计都不会跑偏。1.2 解析失败往往不是模型问题而是前置策略问题我见过不少团队在 OCR 和模型上反复调优效果始终上不去最后发现根因是路线错了。举个例子一个合同文档库里前面十几页是扫描件后面几页是电子签章页。有人直接上多模态大模型整本解析每页都要走视觉推理慢且贵效果还不稳定。更合理的做法是先把文档按页切分逐页检测文字层覆盖率分类路由——有文本层的走快速提取没有的才走 OCR 或视觉模型。我把这种思路叫“先分类、后解析”。这不仅省时间省预算更关键的是它能让你对不同质量的输入分别做阈值设置。比如扫描件允许一定的字错误率纯文本页则要求高保真提取。分类路由的思路会贯穿全文所有方案。2. 图片解析OCR 与多模态大模型的分工与选型图片解析是 RAG 导入里最容易被低估的一环。实际项目里图片往往不是简单的“有没有字”的问题而是“字在什么位置、什么版式、什么背景下”的问题。处理图片本质上是在做“版面理解”而不是“文字抠取”。2.1 传统 OCR 的适用场景与局限传统 OCR 这些年进化得非常快以 PaddleOCR、Tesseract、商用云 OCR 为代表。它们各自有鲜明的优缺点工具擅长场景明显的短板推荐度PaddleOCR中文、印刷体、标准票据、轻量部署复杂版面、表格结构还原弱开源首选Tesseract英文、多语言基础识别中文版式理解弱需大量调参备选百度/腾讯云 OCR营业执照、身份证、手写体、高精度识别有成本和数据外传顾虑商用场景搜狗OCR等桌面工具单张图片、低频率需求不适合批量自动化日常辅助传统 OCR 的真正问题有三个一是丢版面。识别出来的文字是一个一个“块”块与块之间的关联关系、表格行列属性、阅读顺序需要你自己用坐标信息重建。很多工具导出的是带bbox坐标的 JSON但后续重建版面的工程量不小。二是抗干扰能力有限。深色背景、印章文字叠压、艺术字体、斜排文字识别率会明显下降。印章叠字这个问题我实测过 PaddleOCR 和多家云 OCR在合同类文档上普遍识别得七零八落。三是和 RAG 检索的目标冲突。RAG 要的是语义单元而不是文字流。OCR 结果如果只是大段吐字出来没有结构后续拆分和向量化效果会很差。所以单纯上 OCR 并不能解决 RAG 的问题它必须搭配版面后处理。2.2 多模态大模型图片解析的“新解法”多模态大模型比如 Qwen-VL、GPT-4o、Claude 等视觉版本给图片解析带来的是一种范式改变。它们不只是从图片里抠文字而是能理解整张图的语义结构这是一个表格表头是什么哪几行是数据这是一个产品示意图箭头指向哪里旁边的标注对应什么内容。用多模态大模型解析图片的核心优势有三个直接输出结构化文本可以要求它输出 Markdown 表格、JSON 结构甚至是带语义的摘要。抗干扰强印章叠字、背景纹理、复杂版面视觉理解模型通常比传统 OCR 更稳健。自带语义解析结果可以直接作为 RAG 的 chunk 输入几乎不用再做二次清洗。当然也有代价速度慢、成本高。一张复杂图片可能耗时十几秒甚至更久token 费用随图片复杂度和模型规格上升明显。2.3 我的实战选型策略分级调用我的做法是建一个图片解析的“分级路由”简单图片、文字清晰、无表格用 PaddleOCR 或云 OCR 快速识别便宜且速度快。中等复杂度图片、有表格或简单版面先用传统 OCR 抽字再配合规则或小模型重建结构。复杂图片、票据稠密、版面混乱、需要上下文推理上多模态大模型一次性生成结构化输出。这个分级策略在实际项目里能省下 60% 左右的算力成本。有人问为什么不全部走多模态大模型核心原因是贵和慢。在每天要解析几万张图片的场景下全部走视觉模型要么预算爆炸要么延迟不可接受。补充一个参数参考我用 Qwen-VL 系列模型做表格图片解析时单图分辨率尽量保持 1024 以上温度调到接近 0指令里明确要求“按原表格结构输出 Markdown”效果要比默认参数稳得多。3. PDF 解析工具九选一实测体验与选型建议PDF 解析是 RAG 数据导入的重头戏。工具选错了要么解析得支离破碎要么在表格上彻底翻车。我梳理了当前主流的九种方案按使用场景分成三类轻量文本提取、重结构还原、商用与全能型。3.1 轻量文本提取类pypdf / pdfplumber / pdfminer.sixpypdf是原来的 PyPDF2 的继任者胜在极简几行代码就能把文本抽出来。优点是安装轻、依赖少、处理简单的文字型 PDF 非常快。缺点也很明显面对复杂版式它的输出顺序经常是乱的表格直接变一坨文字。pdfplumber是我个人最常用的工具之一。它把页面上的每个字符、线条、矩形都提取成带坐标的对象可以精确地按坐标重建布局。尤其适合处理有明确框线结构的表格能拿到表格的行列坐标再配合规则拼出结构化的二维数据。缺点是大文件处理速度偏慢内存占用高。pdfminer.six是底层解析库LTTextBox、LTFigure 这些对象层级可以让你精细控制布局分析。它的优势是灵活几乎每个解析环节都可以定制劣势是 API 偏底层开发效率不高。这三个工具都属于“要自己动手做后处理”的范畴适合文档结构相对规整、工程师愿意花时间调规则的项目。3.2 重结构还原类PyMuPDF / Camelot / MarkerPyMuPDFfitz是我在多数项目里的首选底座。它支持把每一页渲染成高清图片可以精确切割区域并导出还自带轻量文本提取功能。很多复杂的图片型 PDF我会先用 PyMuPDF 把页面渲染成 PNG再把图片交给 OCR 或多模态模型去解析。这种“PDF 转图片再转认知”的路线绕开了 PDF 内部文本层的各种兼容性问题。Camelot专注表格提取。它有两种模式Lattice 模式针对有框线的表格准确率非常高Stream 模式针对无框线、靠空白对齐的表格效果波动较大。Camelot 的强项是输出结构化表格数据非常适合财报、单据类 PDF。但它依赖 Ghostscript部署时容易被环境问题绊住。Marker是我近两年用下来最惊艳的开源项目之一。它能把 PDF 完整转换为 Markdown自动识别标题、段落、表格、图片引用同时生成对应的文本块级别的坐标信息。效果接近我理想中的“RAG 预处理神器”。它对运行环境要求不低最好有 GPU且大文件处理速度仍然偏慢但输出质量确实对得起算力开销。3.3 商用与 RAG 专用型Unstructured / LlamaParse / Adobe Extract APIUnstructured是 RAG 生态里被提及最多的工具。它的核心价值不是“解析”而是“把解析结果按 RAG 的需求切成元素块”比如 Title、NarrativeText、Table 这些类型还内置了表格提取和 OCR 支持。缺点是框架层级多部分模块抽象程度高一旦行为不符合预期排查成本略高。LlamaParse是 LlamaIndex 同门的云端解析服务支持解析复杂表格、嵌入图片和扫描件输出 Markdown。它在英文场景效果优秀中文场景我实测有波动但如果你的文档是英文财报、论文这个工具能省很多事。Adobe Extract API是 Adobe PDF 服务家族的 API 产品对版式还原和表格识别非常精准是工业界商用效果最好的封闭方案之一。缺点是收费、闭环生态也不太好做细粒度定制。下表是九种工具的一句话总结工具最佳场景不要用于pypdf快速抽文本、文字层完整表格、扫描件pdfplumber规整表格、坐标级布局分析超大文件、复杂嵌套版式pdfminer.six底层布局定制、科研级控制快速原型PyMuPDF页面渲染、区域裁剪、多模态配合结构化文本输出Camelot纯表格提取、财务单据无框线复杂排版Marker整本转 Markdown、RAG 高质量预处理弱机器上的批量任务UnstructuredRAG 生态内做文档元素切分追求极致表格精度LlamaParse英文复杂文档、云端快速集成中文复杂排版、成本敏感场景Adobe Extract API商业级版式还原、表格高精度预算有限、需深度定制3.4 选型决策树选型其实可以浓缩成几个问题文档有没有文字层没有就直接考虑 PyMuPDF 渲染图片 多模态或 OCR。表格重要吗重要就优先看 Camelot、Marker、Adobe Extract API。需要和 RAG 生态深度集成吗要就选 Unstructured能省掉大量清洗环节。预算和技术能力如何开源组合拳 PyMuPDF PaddleOCR Marker 通常够用且可控。有朋友问能不能只用一个工具解决所有问题。我的答案很明确不能迷信单一工具。真实文档千奇百怪一套组合策略远胜一个全能工具。我的默认组合是 PyMuPDF 负责渲染和文本提取Marker 负责整本高质量转换表格和复杂页面用多模态模型兜底这一套组合在中文合同、英文论文、财报场景都跑得很稳。4. 解析结果如何接入 RAG 流水线解析只是第一步解析完的文本怎么进入向量库、怎么保证检索质量是整个链路里更考验细节的环节。4.1 从解析结果到 Chunk 的关键处理解析输出通常要先做三件事清洗。去掉页眉页脚、页码、页眉横线、乱码字符。这一步看似无关紧要实际上对 embedding 效果影响很大。页眉页脚混入正文会导致 chunk 语义偏移尤其是页码这种高频无意义 token会稀释向量权重。切分。按语义单元切而不是按固定字数硬切。Marker 或 Unstructured 输出的块类型正好可以作为切分边界。表格通常单独成一个 chunk图片说明和正文分开。固定 512 字切分适合纯文本但对表格和图文混排是灾难。结构化补全。给每个 chunk 带上元数据比如来源文件名、页码、所属章节、文档类型。这不仅是追溯需要还能在检索时做基于元数据的过滤提升准确率。4.2 表格和 OCR 结果的“二次向量化”表格进 RAG 一直是个老大难。直接丢 Markdown 表格文本进去embedding 模型经常抓不住行列语义。我的做法是对表格做两次处理第一次把表格转成自然语言的描述比如“2023年Q2营收为3.2亿同比增长15%”这个描述会被向量化用于语义检索。第二次保留一份原始表格的结构化数据比如 JSON作为检索命中的“附件证据”。用户提问时先召回自然语言描述再联动附上原始表格效果要比单纯检索表格文本好很多。同理OCR 出来的结果如果只是文字流我也建议尽量做结构化重构后再入库。比如合同的结构是“甲方、乙方、金额、期限”OCR 识别后应该把这些字段映射成结构化键值而不是一段乱字。4.3 数据质量验证的四个指标RAG 的检索效果和入库质量强相关。我每次搭完解析流程都会跑一组质量验证覆盖率所有文档是否都被成功解析解析失败比例是否在可控范围准确率抽样对比原文和解析结果尤其是数字、金额、专有名词OCR 场景下错误率是否超标结构完整度表格行列是否对齐段落顺序是否正确大文档是否被错误切断检索命中率拿一批测试问题做召回验证看答案能否回回到正确的 chunk 上。这四个指标我会做成自动化的流水线每次数据更新后自动跑一轮一旦指标下跌就定位到是哪个环节出了问题。没有这一步后面的 RAG 效果再差你都不知道该从哪里排查。5. 常见问题与排查技巧实录把我在真实项目里踩过的坑整理成速查表这些都属于“文档里不会写、但实操一定会遇到”的问题。现象根因解决方案PDF 提取出来是乱码字体编码非标准缺嵌入字体改 PyMuPDF 渲染成图片后走 OCR 或视觉模型中文 OCR 准确率低未加载中文语言包PaddleOCR 默认支持中文Tesseract 需显式指定 chi_sim表格提取串行错位无框线表格用 Lattice 模式误判换 Camelot Stream 模式或用多模态模型重建多模态解析超时单图分辨率过大、模型输入限制先压缩到合适分辨率分块处理复杂版面扫描 PDF 整本解析慢每页都走 OCR无差别处理先检测文本层覆盖率分类路由只在无文本层页面走 OCR嵌入图片被直接丢弃解析工具默认忽略图片对象用 PyMuPDF 单独提取图片对象送 OCR 或视觉模型chunk 切分切断表格按固定字数切分不考虑语义边界表格单独成块配合自然语言描述二次向量化解析结果与原文对不上页码、页眉混入正文清洗阶段按坐标规则过滤页眉页脚再单独强调一个我在工程上反复遇到的坑多模态模型做 OCR 时如果把整页 A4 扫描件压缩到很小的分辨率复杂小字会糊成一团识别率骤降。我处理扫描件时的经验是先检测原始 DPI物理尺寸和文字密度的关系再决定缩放比例。单页 A4 扫描件通常保持 1024 到 1536 像素的宽度比较稳妥再低的清晰度省下来的成本都会变成返工成本。另一个容易被忽略的问题是格式间的边界 case。比如 PDF 里嵌入了扫描页面和文本页交错的情况很多工具会误判整本都是扫描件导致无谓的算力消耗。我采用的策略是按页分类统计每页字符数超过阈值判断为文本页否则进入 OCR 队列。这个过程对整本 PDF 按页拆分后做并行决策效率提升非常明显。工具链本身的工程细节也值得注意。PyMuPDF 渲染页面时matrix参数决定输出图片的分辨率默认值是 72 DPI输出很模糊我一般设置 2.5 到 3 倍缩放让渲染图保持 200 DPI 左右的清晰度。Camelot 解析表格之前必须确认 Ghostscript 是否正常安装否则会出现解不开或超时的神秘错误。Marker 跑大文档时建议按章节拆分后再处理避免内存溢出和排队过久。6. 最后分享一点个人心得做 RAG 数据导入和解析大部分时间其实不是在和算法作斗争而是在和各种奇奇怪怪的文档作斗争。不同客户、不同行业的文档千奇百怪你很难找到一套万年不变的配置所以“先分类、后解析、再验证”这个三步套路比任何单个工具都重要。我个人的体会是千万不要把解析这一步当成可一次性完成的离线任务。真实场景里文档库每周都在变今天新增几份扫描合同明天补一批带复杂表格的财报解析流程必须具备良好的可观测性和模块化设计。每类文档的解析结果好坏应该有独立的日志和评价指标而不是黑箱式地一股脑灌进向量库。最后再分享一个小技巧如果你做的是中文场景请特别关注表格型 PDF。中英文表格的排版习惯差异很大中文表格经常出现合并单元格、竖排表头、大段备注文字这对所有解析工具都是考验。我在遇到这种文档时通常会把它直接交给多模态大模型做结构化输出再人工抽检几页确认质量。实践证明这类“重难点文档单独特殊处理”的策略远比在通用工具上反复调参来得靠谱。