RAG项目实战：PDF图文解析与OCR工具选型全指南

做RAG项目半年多，最让我意外的不是向量模型怎么选、也不是Prompt怎么写，而是最前端的PDF解析。

原因很简单：RAG效果差，大多数时候问题并不出在模型侧，而是文档在进向量库之前就已经“坏”了。一篇PDF如果解析出来是一坨乱序文本、表格关系断裂、扫描图片没被识别，后续无论是chunking还是embedding，都只是在给这堆坏数据做精致的包装。所以这篇继续写RAG数据导入与解析系列的第二篇，专门把图文解析和PDF工具选型这件事讲透，涉及OCR、多模态大模型、九种常用PDF解析工具对比，以及我实际项目中踩过的坑。

系列第一篇聊的是文本类数据的清洗与切分，这篇聚焦一个更烦人的场景：图片型PDF、扫描件、复杂表格、多栏排版、公式混排——这些才是知识库项目里真正吃时间的部分。

1. 文档解析在RAG管线里扮演的角色：先搞清楚问题出在哪一环

1.1 解析质量如何影响最终检索效果

先摆一个基本链路，几乎所有RAG项目都是这条线：

文档加载 → 内容解析 → 文本切块（chunking）→ 向量化 → 召回 → 排序 → 生成回答。

你很容易发现，大部分团队把精力投在向量模型微调、rerank选型、chunk size调参上，但很少有人认真检查第一步解析出来的原始文本长什么样。我见过很多项目，向量模型换了好几版，召回率纹丝不动，最后把解析结果打印出来一看：表格被拆成了一行行碎片，页眉页脚混在正文里，双栏PDF被当成单栏顺序读——这种数据喂给再好的向量模型也是白搭。

说个直观的测试数据。我拿同一批30篇技术文档做过对比：一份是PyMuPDF粗暴抽取的纯文本，一份是经过表格结构保留和版面还原的解析结果。在相同chunk策略、相同embedding模型的前提下，后者的Top-10命中率明显高于前者，部分长问句场景差距能达到一倍以上。原因不复杂：解析阶段丢失的表格关系和标题层级，在切块阶段是无法恢复的。检索模型再强，也无中生有不回来。

所以在RAG项目里，文档解析不是“能跑就行”的辅助环节，而是决定效果上限的前置条件。你把这一步做扎实，后面所有环节都会轻松很多。

1.2 常见的PDF数据形态：解析难度天生就不一样

PDF这个格式最大的问题是：它不是一个“真实”的文档格式，而是一个排版快照。同叫PDF，内部结构可能完全不同。我一般会把项目里遇到的PDF按数据形态分成四类，选型策略完全不一样。

第一类是文本型PDF。文件本身包含文字层，可以用工具直接抽取，比如大部分电子版说明书、论文、合同。这种最简单，解析基本不会出大问题。

第二类是图片型PDF。每一页其实是一张图，常见于扫描件、传真件、老书扫描版。这类必须走OCR，直接抽文本只能得到空字符串。

第三类是表格密集型PDF。财务报告、实验数据记录、合同明细，里面有大量行列结构。普通文本抽取会把表格拍扁，表头和内容的关系全部丢失，检索时就变成一堆无法对应意义的数字。

第四类是复杂图文混排。比如产品手册、教材、画册，多栏排版、图片嵌文字、页眉页脚、公式混排。这种是最难的，它需要版面分析能力，普通文本工具只能拿到阅读顺序错乱的文字流。

四类形态决定了四套工具路线。网上很多人问“RAG知识库能不能存图片”，本质上也绕不开这件事：图片本身没法直接进向量库跟文本一起检索，必须先通过OCR或多模态模型把图片内容转成文本描述、结构化记录，才有可能被召回。解析这一步做得好不好，直接决定那些“看起来能存图”的系统，到底是真能检索，还是只在索引里存了个寂寞。

2. OCR路线：传统OCR与多模态大模型各自的适用边界

2.1 传统OCR的能力边界与瓶颈

传统OCR经过多年发展已经非常成熟，代表性方案有开源的PaddleOCR、Tesseract，以及各家云厂商的OCR接口。它们做纯文本识别这件事是可靠的，比如身份证、票据、标准印刷体文章，识别准确率可以做到很高。

但传统OCR有两个绕不开的短板。

第一个短板是版面理解能力弱。它擅长逐字逐行识别文字，但不太理解“这行文字属于表格的表头还是正文”“这一栏在页面左侧还是右侧”“标题和它的级联关系是什么”。很多OCR工具虽然也带版面分析模块，但实际效果只能做到大致分块，面对复杂排版时，输出顺序经常是乱的。这直接影响RAG里的chunking——如果段落顺序错了，语义上下文就断了。

第二个短板是多语种和特殊内容支持参差不齐。我遇到过实际案例：用某个OCR pipeline识别一份包含韩文的文档，结果韩文部分全部变成乱码方块。原因通常是模型语言包没覆盖韩文字符集，或者输入图片分辨率太低导致字符细节丢失。传统OCR处理拉丁语系和中文问题不大，但遇到泰文、韩文、阿拉伯文这些非拉丁语系，必须确认模型是否真的支持，不要只看文档宣传。这个坑很隐蔽，因为项目初期测试文档往往全是中文和英文，等正式上线换了一批多语种文档就突然出问题。

传统OCR还有一个结构化输出方面的短板：技术调研中的数学公式、图表数据，OCR只能输出近似文本，公式结构基本会丢。论文、专利这类以公式和符号为主的文档，传统OCR不是好选择。

2.2 多模态大模型解析PDF的思路与优劣势

多模态大模型加入之后，PDF解析的格局发生了明显变化。思路其实很直接：先把PDF每一页渲染成高分辨率图片，然后让视觉语言模型（比如GPT-4o、Claude系列、Qwen-VL、InternVL这类）看图，并要求它输出Markdown或JSON格式的完整内容。

这个路线解决了两件传统OCR很难做的事情。

一是版面顺序理解。多模态模型经过海量图文数据的训练，能够理解“这是一个两栏布局，左边先读，右边再读”“这是表格，表头是这几列”“这是图表注释”等复杂结构。实测下来，对复杂版面的还原能力明显优于传统OCR。要求模型输出Markdown时，表格会保留为表格语法，标题层级也会保留，这些信息对后续chunking非常有价值。

二是语义理解辅助识别。比如一张模糊的扫描件，传统OCR会因为字形不清晰而误判，但多模态模型可以结合上下文语义“猜”出正确内容。遇到图片里的图表，它甚至能直接生成一份结构化的数据描述。这已经不只是OCR了，更像“看文档”和“转述文档”的结合。

但多模态路线也有很明显的代价。

首先是慢。一次页面级解析少则几秒，复杂页面可能几十秒。批量导入几百页文档时，耗时是分钟甚至小时级别的，比传统OCR慢一个数量级没问题。

其次是贵。按Token或按页计费，同样体量的文档，成本可能是传统OCR的十几倍到几十倍。上规模之前务必先算账。

再一个是幻觉风险。多模态模型在生成Markdown时，偶尔会“脑补”一些不存在的文字内容，尤其是低分辨率图片里的模糊小字。它不会老老实实说看不清，而是会结合上下文编一个合理的内容出来。这在财务合同、法律文书这种场景是致命的。所以多模态解析结果一定要做抽检，我吃过这个亏，后面会细说。

2.3 按文档类型、预算、速度三维度做选型

传统OCR和多模态大模型不是替代关系，更像是各司其职的两套工具。我的选型逻辑是这样的：

落到实际决策上，我通常用三个问题来判断：

第一，文档是扫描件多还是电子版多？扫描件数量大的项目，成本压力是首要考虑，优先传统OCR。只有少量高价值扫描件，才值得让多模态模型出马。

第二，文档结构复不复杂？如果文档包含大量双栏排版、嵌套表格、图文混排，多模态模型几乎是一步到位。传统OCR做完还得花大量时间做版面后处理，得不偿失。

第三，预算和时效能不能接受？如果项目要求快速导入、低成本运行，就老老实实用传统OCR配合版面检测；如果是知识库质量优先的精品项目，多模态路径再贵也值得。

还有一种常见做法是混合路由：先用轻量工具判断文档属于哪一类，简单的纯文本PDF直接走文本抽取，扫描件走传统OCR，复杂版面或重要表格走多模态。这套方案我后面会给出完整管线设计。

3. 九种PDF解析工具逐项拆解与横向对比

把工具选型独立拿出来讲，是因为这个环节的信息密度最大，而且选错工具的代价在项目后期才显现。我把项目里实际用过、调研过的PDF解析工具按定位分成五类：文本抽取类、表格专用类、RAG专用解析器、扫描件OCR方案、公式专项方案。

3.1 文本抽取类：PyMuPDF、pdfplumber、pypdf

PyMuPDF（fitz）是我用得最多、也最推荐优先尝试的库。它最大的优势是快，处理一份几百页的PDF只需要几秒到十几秒。接口也很全，既能提取文本，也能按页渲染成图片，还能拿到每个文本块的位置坐标。做文本型PDF解析，它基本是首选。缺点也有：它对表格的理解很弱，框线表格在get_text()输出里会被拍扁；另外它直接抽取的内容默认按页内元素顺序输出，双栏版面经常左右混读。

pdfplumber是另一个非常出色的文本抽取工具，底层基于pdfminer.six，但做了很多易用性封装。它保留了每个字符的精确坐标，可以基于坐标做自定义的版面还原。比如你想按列切分、按区域提取，用pdfplumber写规则非常灵活。它还有一个extract_table()方法可以直接抽取有线表格，对付简单表格很好用。缺点是速度比PyMuPDF慢不少，文档页数多的时候等待感明显。

pypdf（原PyPDF2）更轻量，适合做PDF的合并、拆分、加密解密、简单文本提取。它的文本抽取质量不如前两者，碰到复杂PDF经常出现内容缺失或乱序。所以我一般只把它当作PDF处理小工具库，很少用它做RAG解析主链路。

3.2 表格专用类：Camelot、Tabula

表格是PDF解析里的重灾区，文本抽取工具很难有效处理，于是有了专用工具。

Camelot基于OpenCV检测表格的框线，对“有线表格”还原能力非常强。它能把表格抽出来并转换成DataFrame或CSV，行列关系完整。这对财务报告、实验数据这类场景几乎是最优解。但它的前提是表格必须有清晰的框线。遇到无线表格（只有空格对齐的那种），Camelot基本无能为力。另外它对扫描件也无效，必须搭配OCR先把表格变成可检测的线图。

Tabula是同类的表格抽取工具，基于Java实现，PyPI上有对应的tabula-py封装。它的使用体验比Camelot更简单，直接给PDF路径和页码范围就能抽出表格，对规则表格的识别效果稳定。但它同样依赖表格线的清晰程度，复杂嵌套表格处理能力一般。

这两个工具的定位很明确：当文档里表格占比很高、且结构规整时，专门走一步表格抽取，比让通用解析器处理要可靠得多。

3.3 RAG专用解析器：Unstructured、LlamaParse

Unstructured是专门为RAG场景设计的文档解析框架，支持PDF、DOCX、HTML、PPT等常用格式。它最大的特点是把文档解析成一系列带元数据的数据块（Element），每个块带有文档类型（标题、正文、表格、图片等）和位置信息。这些块的输出形式天然适合后续的chunking和向量化。它的partition_pdf()函数支持策略参数，可以走纯文本抽取，也可以配合OCR，甚至支持调用多模态模型做深度解析。我建议做RAG项目的同学优先把Unstructured用起来，它省去了大量自己写版面分析的功夫。

LlamaParse是LlamaIndex出品的云端解析服务。它把复杂文档上传到云端解析，返回带结构的Markdown或JSON。对复杂表格、图文混排的处理效果非常惊艳，很多文档直接返回一个干净整齐的Markdown，标题层级、表格结构全都在。但它是收费服务，需要联网上传文档。文档敏感、网络受限或成本敏感的项目要谨慎评估。我的使用建议是：把它当作解析管线的最高级“后手”，只负责处理那些本地工具搞不定的疑难杂症，而不是全量文档都丢给它。

3.4 扫描件OCR方案：pdf2image + PaddleOCR

扫描件PDF没有文本层，必须把页面转成图片再OCR。最常用的组合是pdf2image + PaddleOCR。

pdf2image把PDF页面转成PIL图片，关键参数是DPI。这里有个容易被忽略的细节：默认150DPI对很多小字文档是不够的。我做测试时，同样的文档150DPI下OCR错误率明显偏高，调到200-300DPI之后识别准确率显著提升。代价是渲染变慢、图片变大，所以要按实际文档字体大小来平衡。

PaddleOCR是国产OCR引擎中综合体验很好的一个，中文识别准确率很高，支持多语种，带了文本检测、方向分类和识别三个模型。它还有关键的版面分析能力，可以区分段落、标题、表格等区域，这比单纯输出文本框坐标强很多。不过它的多语种支持要显式指定，处理韩文、日文、泰文时一定要把语言配置对，否则就是“识别了一堆看不见的字符”。

3.5 公式专项方案：Mathpix

Mathpix 是数学公式识别的标杆工具。它能把PDF或图片中的公式转成LaTeX，对论文、数学教材、理工科资料的价值极大。但它有两个门槛：一是收费，而且价格不低；二是它对普通正文的识别能力一般，术业有专攻。我的建议是：文档里大量公式的项目才值得引入，普通商业文档完全用不上，公式少的PDF也不必为偶尔一两个公式单独上这套。

3.6 九种工具对比总表与选型路径

把上面九个工具放到一张表里，选型时直接对照：

选型路径我一般用三步走：先确认文档有没有文本层（用PyMuPDF一行代码检测）；有文本层的，再确认表格占比，多走Camelot或pdfplumber，少用pdfplumber/PyMuPDF直接抽；没有文本层的，先pdf2image渲染，再用PaddleOCR做整体识别。只有个别特别复杂的页面，再交给多模态模型或LlamaParse专项处理。

4. 一个可落地的混合解析管线设计

4.1 管线设计总思路：分诊路由，各取所长

单一工具打天下的方案我基本不推荐，因为现实中的PDF太杂。我做RAG数据导入时，落地的是一个分诊路由式的解析管线，整体思路是“先体检，再分流，最后汇聚成统一格式”。

体检阶段只做一件事：用PyMuPDF读取每一页的文本量，判断哪些页有文本层、哪些页是图片。这个阶段极其廉价，但信息量很大。

分流阶段按文档形态决定处理路径：

• 文本量充足的页，走PyMuPDF或pdfplumber做文本抽取；
• 文本量几乎为零的页，认定为扫描件，走pdf2image + PaddleOCR；
• 页面包含大段表格区域，用版面分析定位后交给Camelot抽取；
• 个别复杂版面页，人工或规则触发多模态模型兜底处理。

汇聚阶段把三路结果统一转成带元数据的数据块结构，进入后续切块和向量化。

4.2 从文档检测到结构化输出的落地步骤

这条管线按步骤拆解大概是这样的：

第一步，文档体检。用PyMuPDF遍历全部页面，提取每页文本字符数和图片数量，输出一个页面清单。这个清单直接决定后续路由策略。

第二步，路由判断。写一个简单的规则函数：字符数大于某个阈值（比如每页200字符）的页走文本抽取；字符数极低的页走OCR；夹杂在两种状态之间的页标记为“待确认”。

第三步，文本路由处理。对文本页用pdfplumber按坐标提取内容块。这里有一个关键操作：用页面的列坐标判断是否为双栏版面。如果检测到左右两栏都有密集文本，就按坐标切分后左栏先读、右栏后读，避免大段文字顺序错乱。

第四步，扫描件处理。pdf2image渲染时把DPI调到200以上，PaddleOCR开启版面分析，输出按区域排序的文本块。版面分析结果里要留意表格区域，表格区域不要简单当成普通文本输出，尽量走表格识别流程。

第五步，统一输出格式。所有路径的结果最终统一转成类似这样的JSON结构：

{ "page_number": 12, "layout": "two_column", "blocks": [ { "type": "heading", "level": 2, "text": "系统架构总览" }, { "type": "paragraph", "text": "系统分为数据层、服务层和展示层三部分……" }, { "type": "table", "headers": ["模块", "功能", "依赖"], "rows": [ ["数据层", "数据采集", "Kafka"], ["服务层", "业务逻辑", "Spring"] ] } ] }

这个结构出来之后，后续的chunking策略会好做很多。我的经验是：尽量不要在解析阶段就把文档压成一段平铺的纯文本，哪怕暂时用不到，也保留结构信息。结构信息在RAG里的价值会随着项目推进越来越明显，比如按标题层级做chunk切分、按表格块做结构化召回。

4.3 与Chunking的衔接：解析输出直接决定切块质量

很多人把解析和切块当成两个独立环节，这个认知在项目初期没问题，但上线后你会发现，解析输出的结构直接决定了切块的边界。

举个例子，一份技术手册，解析后保留了“1级标题-2级标题-正文段落-表格”的层级结构，chunking时就可以按层级语义切块：每个chunk包含完整的标题路径，检索时能准确知道内容在文档里的位置，召回片段天然携带上下文。反过来，如果解析输出是平铺文本，chunking就只能按固定长度硬切，经常把一个完整表格或者逻辑段落拦腰截断。检索出来的内容要么有头无尾，要么跟前面断开的句子拼接，用户看到的回答质量很低。

所以我在设计解析管线时，所有输出都强制保留三条元数据：页面位置、版面类型（正文/表格/标题/图片说明）、层级路径。这三条信息在召回后拼装答案时非常有用。具体到RAG里就是：解析输出的结构化程度，决定了你是“机器切肉”还是“人工分档”。

5. 解析质量如何评估与兜底：避免脏数据进入向量库

5.1 质检指标怎么定才不流于形式

解析管线跑完，不能直接信任结果就入库，必须先做质量评估。我见过太多项目跳过这一步，结果向量库里全是乱序和丢失的内容。

我实际使用的质检指标有四个，各有各的用途。

第一个是文本提取率。用PyMuPDF统计原始文本层的字符数，跟解析结果对比，如果解析输出字符数远低于原始文本层，说明抽取过程丢内容了。提取率低于90%的页面要标记出来重新处理。

第二个是乱码率。统计解析文本中“�”这类替换字符或异常字符的比例。乱码率高的页面通常走错了路线，比如文本型PDF被错误地走了OCR，或者OCR语言配置错误。

第三个是表格结构完整率。对有表格的页面，人工抽检时重点看：表头是否保留？行数是否和原表一致？单元格内容是否错位？表格问题是最隐蔽的，因为文本内容还在，但关系全变了。

第四个是版面顺序正确率。抽检双栏页面和多模块页面，确认解析输出的阅读顺序和原文一致。这个指标直接决定上下文的连贯性。

实际操作中，我建议至少按文档总量的1%-5%做人工抽检，并且抽检目标要偏向复杂页面，不要只挑简单的看。第一次上线一个数据集时，我甚至会把抽检比例拉到10%以上，等把解析参数调稳了再慢慢降下来。

5.2 失败重试与人工修正机制

再好的管线也有解析不了的文件。我习惯在解析流程里预设三层兜底，避免一条路走到黑。

第一层是规则自愈。比如某页OCR结果字符数异常低，自动降低渲染DPI策略换成更高DPI重新渲染一次；或者某页表格抽取结果行列数对不上，自动退回用结构定位后多模态模型识别。

第二层是降级路由。如果当前工具连续失败，自动降级到能力更强的工具。本地文本抽取失败 → 降级到OCR；OCR结果乱码率高 → 降级到多模态模型单页精读。虽然成本上升，但至少不会因为个别页面卡住整个批量任务。

第三层是人工介入队列。所有反复失败或质检不通过的页面，汇集到一个待处理队列，以页面截图形式展示给人工，由人手动补充正确内容。这种页面占比通常很小，人工处理成本完全可控。

这套兜底机制的价值在于：解析管线的目标不是追求单次成功率100%，而是保证最终入库数据质量达标。有些页面解析工具就是处理不了，让人工花十秒补一下，比调半天参数划算得多。

5.3 高风险文档类型与特殊处理清单

基于实际项目经验，有几类文档建议在解析前就做好预案，它们单独出现还好，混在批量数据中最容易出问题。

加密和受限PDF是最常见的一类。带打开密码或编辑权限限制的PDF，必须先做解密处理，否则后续所有工具都会报错或只拿到空白输出。而且很多加密PDF表面上能打开，但文本层是空的，这种要提前识别。

多栏混排文档也很麻烦。报纸、画册、产品手册，左右两栏甚至三栏混排，如果不做栏切分，解析结果就是A栏前几句和B栏前几句交错出现。我的处理方案是：在解析管线里加一个版面方向检测，发现文字块分布呈明显多列模式时，强制启用按列切割逻辑。

页眉页脚污染是容易被忽视的问题。很多扫描件每一页顶部有标题、底部有页码，如果不去除，它们会被当成正常文本进入向量库。最直接的后果是检索时大量返回页码和重复标题，相关内容反而排不上来。处理方式是在OCR后按坐标规则过滤顶部和底部固定区域。

还有一个非常典型的坑：伪PDF。有些文档扩展名是.pdf，但内部其实是一堆图片嵌入，或者干脆是HTML打印出来的，结构完全不标准。用云OCR服务上传这种文件时，经常被报“file format error”。解决办法是传输前做格式校验，用PyMuPDF随机抽几页检查文本层和页面结构，不符合标准PDF特征的，先转成标准PDF再走后续流程。

6. 实测中踩过的坑与典型排查路径

6.1 几个高频问题：乱码、版面断裂、OCR识别失败

做PDF解析避不开坑，我把项目里真实碰到的高频问题汇总一下，按出现频率排序。

乱码和替换字符。这个出现频率最高，常见原因是语言包缺失或者编码判断错误。我遇到过一次整页泰文全部识别成方块字，检查半天发现是PaddleOCR的语言参数没有指定泰文。处理方法是在OCR前先做语言检测，根据检测结果动态切换识别模型。

版面断裂。一份产品手册，PDF里是双栏排版，解析出来A栏一段话读到一半突然跳去读B栏，再跳回A栏后半句。这种问题的根源是纯文本抽取不包含版面顺序信息。排查的时候先看解析结果是否有“左右横跳”特征，确认后换pdfplumber按坐标切列，或者走多模态模型逐页还原。

表格拍扁。一个项目里财务数据表格全部被解析成了连续文本，数字全在但对应关系全乱。这个问题的特征很明显：检索时能搜到数字词，但句子读不通。修复方式是引入Camelot做表格专用抽取，再把表格结果单独分块存入。

伪PDF导致的OCR报错。云OCR上传一份PDF直接被拒，返回file format error。拆分排查后发现问题不是OCR侧，而是文档本身有图片嵌套导致PDF结构不规范。我后续在导入流程最前面加了一步格式体检，遇到非标准PDF先做格式转换，报错率明显下降。

6.2 一次完整的问题排查链路：从检索失败到定位解析层

只列问题不给排查思路帮助不大，我拆一个真实排查案例出来。

背景是一套合同知识库，用户反馈：问“某份合同里关于违约责任的具体金额”，系统答不上来，即使答上来了数字也是错的。

我首先会拉取这条检索请求的日志，看召回的文档片段到底是什么。结果发现：相关合同页面根本没进入召回列表。这说明问题可能出在向量化或召回阶段，但也可能从根本上就没被正确解析。

下一步，用关键词直接搜原始向量库，看能不能匹配到“违约责任”这四个字。如果连关键词都匹配不到，说明内容压根没有入库，或者入库的文本已经变形了。我查了之后发现，库里确实有这个页面，但里面的“违约责任”被解析成了“违约 责任”——中间多了换行符和一个错位字符。这属于解析环节的字符拼接问题，导致向量化时被当成两个词处理，检索匹配失败。

再深挖一层，发现这个合同中违约责任条款是一个嵌套表格，而我的解析管线当时用的是纯文本抽取，表格内容被拍扁了，单元格间的换行全部混进文本里。这就是典型的表格型PDF走了错误路由。

修复路径很清晰：把该文档重新映射到表格处理流程，用Camelot抽取表格，按单元格分块生成结构化chunk，再重新灌库。验证环节用原问题重新检索，这次能召回精确的违约责任金额，问答结果正确。

这个排查过程里最耗时的一步不是修复，而是准确定位问题发生在哪一层。这也是为什么我反复强调解析输出的结构化日志很重要——如果解析端每页都留下处理方式、字符数、异常标记的日志，排查时只需几步就能定位。反之就只能人肉翻看原始文本，效率天差地别。

6.3 性能与成本：批量导入时如何控制节奏

最后聊一个工程细节，批量导入大批PDF时，性能和成本怎么平衡。

混合解析管线里，最贵的环节是多模态模型调用，最慢的环节是OCR渲染识别。我实测的节奏策略是：

• 文本型PDF可以激进并发，PyMuPDF本身是CPU密集，配合多进程能快速跑完；
• 扫描件OCR建议控制并发数，避免把服务器CPU打满，也避免OCR服务端限流报错；
• 多模态模型调用务必加并发限制和退避重试，同类请求频率过高会被限流，反而拖慢整体进度。

缓存策略也很值得做。文档内容哈希作为缓存key，如果一个文件之前解析过且没变化，直接读缓存结果。实际项目中，同一份PDF被多次重复导入的场景非常多，缓存能节省大量重复解析成本。我甚至会把中间过程也缓存，比如渲染后的页面图片、OCR的中间文本，这样后续调整参数时不需要从头再跑一遍。

成本控制上，最佳实践是“分级投入”：能便宜解决的绝不用贵的，只有少数复杂页面才动用多模态。按我的经验，走混合路由后，需要多模态模型处理的页面通常占全量文档的5%-15%，成本压力完全可接受。

做RAG这一年多，我越来越确认一个观点：数据导入与解析是整个RAG链路里性价比最高、也最容易被低估的环节。调模型花几周，效果提升可能只有几个点；把解析做好，换来的是整个系统的质量基线拔高，而且是肉眼可见的那种改变。每次新项目启动，我都会先让团队花几天时间把文档体检和解析管线搭起来，后续所有环节都会顺畅很多。如果你正被RAG效果问题折磨，不妨先回去看看第一批PDF文档到底被解析成了什么样。