做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做完还得花大量时间做版面后处理得不偿失。第三预算和时效能不能接受如果项目要求快速导入、低成本运行就老老实实用传统OCR配合版面检测如果是知识库质量优先的精品项目多模态路径再贵也值得。还有一种常见做法是混合路由先用轻量工具判断文档属于哪一类简单的纯文本PDF直接走文本抽取扫描件走传统OCR复杂版面或重要表格走多模态。这套方案我后面会给出完整管线设计。3. 九种PDF解析工具逐项拆解与横向对比把工具选型独立拿出来讲是因为这个环节的信息密度最大而且选错工具的代价在项目后期才显现。我把项目里实际用过、调研过的PDF解析工具按定位分成五类文本抽取类、表格专用类、RAG专用解析器、扫描件OCR方案、公式专项方案。3.1 文本抽取类PyMuPDF、pdfplumber、pypdfPyMuPDFfitz是我用得最多、也最推荐优先尝试的库。它最大的优势是快处理一份几百页的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、LlamaParseUnstructured是专门为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 公式专项方案MathpixMathpix 是数学公式识别的标杆工具。它能把PDF或图片中的公式转成LaTeX对论文、数学教材、理工科资料的价值极大。但它有两个门槛一是收费而且价格不低二是它对普通正文的识别能力一般术业有专攻。我的建议是文档里大量公式的项目才值得引入普通商业文档完全用不上公式少的PDF也不必为偶尔一两个公式单独上这套。3.6 九种工具对比总表与选型路径把上面九个工具放到一张表里选型时直接对照工具最佳场景明显短板开源PyMuPDF文本型PDF快速抽取、图文渲染表格结构、复杂版面是pdfplumber需按坐标还原版面的文本PDF速度较慢是pypdfPDF合并拆分、简单文本提取复杂解析能力弱是Camelot有线表格抽取无线表格无效、扫描件无效是Tabula规则表格快速抽取复杂表格处理有限是UnstructuredRAG通用解析框架复杂版面需调参配合其他工具是LlamaParse复杂文档云端深度解析收费、需要联网、数据外发否pdf2imagePaddleOCR扫描件、中文识别依赖渲染DPI、多语种需配置是Mathpix数学公式转LaTeX贵、不适合通用文本否选型路径我一般用三步走先确认文档有没有文本层用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重新渲染一次或者某页表格抽取结果行列数对不上自动退回用结构定位后多模态模型识别。第二层是降级路由。如果当前工具连续失败自动降级到能力更强的工具。本地文本抽取失败 → 降级到OCROCR结果乱码率高 → 降级到多模态模型单页精读。虽然成本上升但至少不会因为个别页面卡住整个批量任务。第三层是人工介入队列。所有反复失败或质检不通过的页面汇集到一个待处理队列以页面截图形式展示给人工由人手动补充正确内容。这种页面占比通常很小人工处理成本完全可控。这套兜底机制的价值在于解析管线的目标不是追求单次成功率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文档到底被解析成了什么样。