多模态 RAG 这两年从论文里走出来落到实际项目里的速度比我预想中快得多。但真正动手做过的人都知道纯文本 RAG 那一套切块-向量化-召回的流程一旦碰上 PDF 里的表格、扫描件里的印章、产品手册里的示意图立刻就露怯了。我最近集中啃了一批多模态 RAG 方向的论文同时在自己的知识库项目里做了几轮验证发现文档解析和视觉检索这两块才是决定多模态 RAG 能不能真正跑起来的关键。这篇就把我读论文和踩坑的完整思路摊开讲从为什么纯文本方案会失效到文档结构化解析怎么做再到视觉检索的召回策略怎么设计最后聊聊多模态统一处理这个方向目前的真实水位。适合已经做过基础 RAG、想往多模态方向推进的开发者也适合正在选型文档解析工具的技术负责人。1. 纯文本 RAG 撞上多模态文档时到底哪里崩了1.1 一个真实场景暴露的召回断层我拿自己手头的一份设备采购合同做测试这份 PDF 有 40 多页里面夹杂着报价表格、技术参数对照表、还有几页扫描件形式的资质证明。用最常规的文本 RAG 流程处理PyPDF2 抽文本、按 512 token 切块、bge 系列模型做 embedding、存进向量库。然后我问了一个问题第三页报价表里型号 A 的单价和总价分别是多少结果召回回来的片段全是正文里的描述性文字报价表的内容要么被抽成了一堆错位的数字要么干脆整块丢失。原因很直接PDF 里的表格在底层是一堆带坐标的文本片段PyPDF2 按阅读顺序拼接时行列关系完全被打乱。原本型号 | 单价 | 数量 | 总价的二维结构被压成了一维的字符串流语义彻底丢失。这不是个例。我后来统计了一下在包含表格、图表、扫描件的真实业务文档里纯文本抽取的语义完整率大概只有 60% 到 70%。剩下那 30% 多恰恰是信息密度最高、用户最常问的部分。这就是纯文本 RAG 在多模态文档面前的第一个断层结构信息在解析阶段就丢了后面再强的 embedding 模型也救不回来。1.2 切块策略对多模态内容的天然不友好第二个断层出在切块环节。文本 RAG 的切块逻辑默认相邻文本语义连续所以按固定长度或按段落切都还算合理。但多模态文档里一张图、一个表格和它上下文的正文之间语义关系是引用而非延续。举个具体的例子正文写着各型号技术参数详见下表紧接着是一个跨页的大表格。按固定长度切块这句话很可能和表格的前几行被切进同一个 chunk而表格的后半部分落到下一个 chunk。检索时用户问型号 B 的功耗是多少命中的 chunk 里可能只有表头没有数据行或者只有数据行没有表头模型拿到这种残缺上下文回答质量可想而知。我在论文里看到过一组对比实验数据同一份多模态文档用朴素定长切块和用结构感知切块在表格类问题上的召回命中率差了将近 25 个百分点。这个差距在 demo 阶段可能感觉不明显但上了生产环境用户问十个问题有三个答不上来体验就崩了。1.3 视觉信息在文本管道里的彻底蒸发第三个断层最隐蔽也最致命图表、流程图、示意图里的视觉信息在纯文本管道里是零保留的。一份产品手册里的架构图可能包含了整个系统最核心的信息但文本抽取只能拿到图注那一行字。用户问这个系统的数据流向是怎样的文本 RAG 只能干瞪眼。我试过用 OCR 去补但 OCR 只能识别图里的文字识别不了箭头方向、模块层级、连线关系这些真正的结构信息。一张流程图 OCR 出来就是一堆散落的词反而可能干扰检索。这就是为什么多模态 RAG 必须引入视觉检索这条独立通路而不能指望 OCR 把一切都文本化。这里有个容易踩的坑很多人觉得OCR 一下不就都变成文本了吗实际上 OCR 解决的是图里有字的问题解决不了图本身在表达什么的问题。这两件事在多模态 RAG 里需要两套不同的处理逻辑。2. 文档结构化解析把 PDF 还原成有层级的知识2.1 为什么页码、章节、段落这三层结构必须保留我在做文档解析方案选型时给自己定了一条硬标准解析结果必须能还原出页码、章节、段落这三层结构。为什么是这三层因为它们直接对应了 RAG 里最关键的三个能力。页码对应的是溯源能力。用户问到一个具体数据系统得能告诉他这个信息在第 12 页否则在合同、标书这类场景里答案没有出处就等于没有可信度。章节对应的是上下文边界。一个章节内部的语义是内聚的跨章节的内容强行拼在一起做 embedding只会稀释语义。段落对应的是最小检索单元。段落是语义相对完整的最小单位比固定长度切块合理得多。我对比过几种解析方案。PyPDF2 和 pdfplumber 这类纯文本抽取工具页码能拿到但章节和段落基本靠猜。Marker 这类基于深度学习的文档解析工具能输出 Markdown 格式标题层级、表格、列表都能识别页码信息也能通过元数据保留。实测下来Marker 在学术论文和规范文档上的解析质量明显更好尤其是它对公式和表格的处理比传统工具高出一个档次。2.2 表格解析从二维结构到可检索文本的转换表格是文档解析里最难啃的骨头。我总结了一下表格解析要解决三个层次的问题识别表格边界、还原单元格结构、转换成可检索的文本表示。识别表格边界传统方法靠线条检测但现在的文档很多是无框表格只能靠文本对齐关系来推断。Marker 和类似的工具用的是视觉布局分析结合的方式对无框表格的识别率比纯规则方法高不少。还原单元格结构核心是处理合并单元格和跨页表格。跨页表格尤其麻烦一个表格被分成两页解析时如果不做合并检索时就会拿到半截数据。转换成可检索文本这一步我的经验是不要简单地把表格拍平成单元格1 单元格2 单元格3而要保留行列语义。我常用的做法是转成 Markdown 表格或者转成列名: 值的键值对形式。比如报价表转成型号: A, 单价: 1200, 数量: 50, 总价: 60000 型号: B, 单价: 980, 数量: 30, 总价: 29400这种表示方式embedding 模型能更好地理解单元格之间的关系检索型号 A 的总价时命中率明显更高。我实测过同样的表格拍平表示和键值对表示在表格类问题上的召回命中率差了大概 18 个百分点。2.3 扫描件与 OCR什么时候该用、什么时候该绕开扫描件是另一个绕不开的场景。我的原则是能拿到原生文本的绝不走 OCR只有纯图片扫描件才启用 OCR 兜底。原因很简单OCR 一定会引入错误尤其是数字和专有名词一个数字识别错整个答案就废了。OCR 工具选型上Tesseract 是经典选择安装包成熟、支持语言多但对复杂版面的识别率一般。Umi-OCR 这类本地识别工具在中文场景下表现更好还支持竖排文本的阅读顺序开关处理古籍或特殊排版时很有用。RapidOCR 基于 ONNX本地推理速度快适合对隐私敏感、不想把文档传到云端的场景。我踩过的一个坑是早期我图省事对所有 PDF 都先跑一遍 OCR结果原生文本 PDF 被 OCR 一处理反而引入了不少识别错误检索质量不升反降。后来改成先检测 PDF 是否含文本层有文本层就直接抽取没有才走 OCR整体质量立刻上来了。判断 PDF 是否含文本层可以用 pdfplumber 或 PyMuPDF 读取第一页看提取出的文本长度。如果长度接近零基本可以判定是扫描件。3. 视觉检索让图片和图表也能被搜到3.1 CLIP 类模型做视觉 embedding 的实际效果视觉检索的核心思路是用 CLIP 这类多模态模型把图片编码成向量和文本向量放进同一个语义空间这样用户用文字提问也能召回相关的图片。听起来很美好实际用起来有几个细节决定成败。第一个细节是图片的粒度。一份文档里的图片有的是整页扫描有的是一个小图标有的是复杂图表。如果整页扫描直接编码向量里混杂了太多无关信息检索精度会下降。我的做法是先做版面分析把图片区域切出来再对每个区域单独编码。对于复杂图表还会额外用 OCR 提取图内文字和视觉向量做融合。第二个细节是CLIP 模型的选择。原版 CLIP 在通用场景下表现不错但在专业文档比如工程图纸、医学影像上zero-shot 能力会明显下降。我试过用中文 CLIP 变体在中文文档场景下比原版好一些。如果预算允许用领域数据做微调效果提升最明显但这需要标注数据成本不低。第三个细节是视觉向量和文本向量的融合方式。简单粗暴的做法是两路召回后直接合并但这样容易出现一路主导的情况。我比较推荐的是加权融合根据查询类型动态调整权重。用户问这个图里有什么视觉权重高一些用户问这个参数是多少文本权重高一些。3.2 图文混合召回的排序策略多模态 RAG 的召回阶段最麻烦的是排序。文本召回和视觉召回各自返回一批结果怎么合并成一个合理的排序列表直接决定了最终答案的质量。我试过几种策略。最简单的是分数归一化后加权求和但文本相似度和视觉相似度的分布差异很大直接加权效果一般。后来改用倒数排名融合RRF不依赖原始分数只看排名鲁棒性好很多。具体做法是文本召回结果按排名给分视觉召回结果也按排名给分两路分数相加得到最终排序。还有一种更精细的做法是引入一个轻量的重排序模型把查询、文本片段、图片描述一起输入让模型判断相关性。这种方式效果最好但延迟也最高。我的经验是对延迟敏感的场景用 RRF对质量敏感的场景用重排序中间地带可以先用 RRF 粗排再对 top-k 用重排序精排。3.3 视觉检索在合同、标书场景的落地验证我在合同和标书场景做了一轮视觉检索的验证。这类文档的特点是表格多、印章多、扫描件多而且用户的问题往往很具体比如乙方盖章页在哪一页、技术参数表里第三行是什么。纯文本 RAG 在这类问题上基本无能为力因为印章是图片表格结构在文本抽取时已经丢失。引入视觉检索后乙方盖章页这类问题可以通过印章区域的视觉特征召回技术参数表第三行可以通过表格区域的视觉定位加上 OCR 文本联合召回。实测下来在 50 个合同类问题的测试集上纯文本 RAG 的准确率大概 52%加入视觉检索后提升到 78%。提升主要来自表格类问题和图片定位类问题。这个数据让我确信视觉检索不是锦上添花而是多模态 RAG 的必备能力。4. 多模态统一处理论文里的思路和工程上的取舍4.1 统一表征 vs 分路处理的两条路线读这批论文时我发现多模态 RAG 在架构上分成两条明显不同的路线。一条是统一表征路线用一个大模型把文本、图片、表格都编码到同一个语义空间检索时只走一路。另一条是分路处理路线文本走文本管道图片走视觉管道最后在召回层做融合。统一表征路线理论上更优雅检索逻辑简单但工程上挑战很大。首先能同时处理好文本和视觉的编码模型不多效果好的往往参数量巨大推理成本高。其次统一表征对训练数据要求极高没有大规模高质量的多模态对齐数据效果很难保证。分路处理路线工程上更可控每一路都可以独立优化、独立替换。缺点是融合逻辑需要精心设计否则两路召回的结果可能互相干扰。我目前的项目选的是分路处理主要考虑是团队对文本管道已经很熟视觉管道可以逐步迭代风险可控。4.2 Agentic RAG 在多模态场景的适配Agentic RAG 是最近很热的方向核心思路是让 Agent 根据问题类型动态决定调用哪些检索工具。放到多模态场景里这个思路特别合适。因为多模态文档的问题类型差异很大有的只需要文本检索有的需要视觉检索有的需要两者结合。我设计的一个简化版 Agentic 流程是这样的用户提问后先用一个轻量分类器判断问题类型。如果是参数是多少这类事实型问题走文本检索如果是这个图长什么样这类视觉型问题走视觉检索如果是对比表格里 A 和 B这类混合型问题两路都走再做融合。这个流程比固定管道灵活很多实测在混合型问题上的准确率提升明显。代价是增加了一次分类调用延迟略有上升。我的做法是把分类器做得很轻用规则加小模型结合把额外延迟控制在 100ms 以内。4.3 多模态数据集与评测bird1445 这类基准怎么用做多模态 RAG评测是个大问题。纯文本 RAG 有成熟的评测集但多模态场景下公开的高质量评测集不多。bird1445 这类数据集在文本到 SQL 场景下很有名但直接拿来评多模态 RAG 并不合适因为它的任务定义和检索场景差异很大。我的做法是自建评测集。从真实业务文档里抽 100 到 200 个问题覆盖文本型、表格型、图片型、混合型四类每类问题都标注标准答案和应召回的文档位置。这个评测集不大但足够指导迭代。每次调整解析策略或召回策略都跑一遍评测集看各类问题的准确率变化。自建评测集的关键是问题要真实。我见过一些团队用生成的假问题做评测结果模型在假问题上表现很好一到真实场景就崩。真实问题的表述往往更口语、更模糊甚至带错别字这些才是模型真正要面对的。5. 工程落地中的性能与成本平衡5.1 解析阶段的耗时分布与优化文档解析是整个管道里最耗时的一环。我统计过一份 50 页 PDF 的解析耗时纯文本抽取大概 2 秒表格识别 8 秒图片切分和编码 15 秒OCR 兜底 20 秒。加起来接近 45 秒如果文档量大这个耗时是灾难性的。优化的思路有几个。第一是并行化文本抽取、表格识别、图片处理这三块互不依赖可以并行跑实测能把总耗时压到 20 秒左右。第二是增量解析文档更新时只重新解析变化的页面而不是整份重跑。第三是缓存解析结果按文档哈希缓存同一份文档不重复解析。还有一个容易被忽略的点解析精度和速度的权衡。高精度的表格识别模型往往很慢如果文档里表格不多可以用快速模型先跑一遍只对检测到表格的区域用高精度模型。这种分级策略能把平均耗时降下来不少。5.2 向量存储与检索的延迟控制多模态 RAG 的向量存储比纯文本复杂因为要同时存文本向量和视觉向量。我的做法是用支持多向量字段的向量库文本和视觉向量存在同一条记录的不同字段里检索时按需查询对应字段。检索延迟主要受三个因素影响向量维度、索引类型、top-k 大小。视觉向量维度通常比文本向量高检索更慢。我的经验是视觉向量可以用 PCA 降维到 512 维左右精度损失很小但检索速度提升明显。索引类型上HNSW 比 IVF 快但内存占用高需要根据数据量权衡。top-k 的选择也有讲究。多模态场景下我一般文本召回取 top-20视觉召回取 top-10融合后取 top-5 送给生成模型。这个配置是在准确率和延迟之间反复调出来的不同场景可能需要微调。5.3 生成阶段的上下文组织召回回来的内容怎么组织成 prompt对最终答案质量影响很大。多模态场景下上下文里可能同时有文本片段、表格、图片描述。我的组织原则是按相关性排序同类内容聚在一起每类内容加明确的类型标记。比如 prompt 里会这样组织[文本片段 1] ... [表格] 型号: A, 单价: 1200 ... [图片描述] 第 12 页包含一张系统架构图图中显示...类型标记很重要它让生成模型知道每段内容的性质避免把表格数据当正文理解。我实测过加类型标记和不加在表格类问题上的答案准确率差了大概 12 个百分点。还有一个细节是上下文长度控制。多模态内容往往很占 token如果不加控制很容易超出模型上下文窗口。我的做法是给每类内容设 token 上限超出部分按相关性截断。文本片段优先保留表格保留完整行图片描述保留关键信息。6. 几个我踩过的坑和对应的解法6.1 表格跨页导致的召回残缺前面提过跨页表格的问题这里展开讲一下我的解法。跨页表格的本质是同一个逻辑表格被物理分成了两页解析时如果不做合并就会产生两个残缺的表格。我的解法是在解析阶段做表格连续性检测。具体做法是解析完一页后检查页面底部是否有未闭合的表格如果有记录表格的列结构下一页解析时如果检测到列结构匹配的表格就自动合并。这个逻辑实现起来不复杂但能解决很大一类问题。合并后的表格在存储时我会额外记录一个跨页标记检索时如果命中跨页表格会把完整表格一起返回而不是只返回命中的那一部分。这个细节对答案完整性很重要。6.2 OCR 识别数字错误的连锁反应OCR 识别数字出错是我踩过最痛的坑。一份报价单OCR 把1200识别成1208用户问总价模型算出来就是错的而且错得毫无痕迹。我的解法有三层。第一层是数字校验对 OCR 出来的数字做合理性检查比如单价乘以数量是否等于总价不等就标记为可疑。第二层是多引擎交叉验证对关键数字用两个不同的 OCR 引擎识别结果不一致就人工复核。第三层是原文保留OCR 结果旁边保留原始图片区域用户质疑时可以对照。这三层做完数字错误率从最初的 3% 左右降到了 0.5% 以下。虽然不能完全消除但已经可以接受了。6.3 视觉向量和文本向量空间不对齐分路处理路线的一个隐患是文本向量和视觉向量不在同一个空间融合时容易出现一路主导。我早期就遇到过这个问题视觉召回的分数普遍偏高导致文本召回的结果被压制。解法是做分数校准。具体做法是分别统计文本召回和视觉召回在验证集上的分数分布然后做归一化让两路分数落在可比的区间。更精细的做法是用一个小的校准模型学习两路分数到最终相关性的映射。我用的是简单的分位数归一化效果已经够用。还有一个技巧是动态权重。根据查询里是否包含视觉相关词汇如图、表、示意动态调整两路权重。这个规则很简单但实测有效。7. 我对多模态 RAG 当前水位的一点判断啃完这批论文加上自己项目的验证我对多模态 RAG 的现状有几个比较明确的判断。文档解析这块工具链已经相对成熟Marker 这类工具能解决大部分结构化文档的解析问题。真正的难点在扫描件和复杂版面OCR 的精度仍然是瓶颈尤其是数字和专有名词。我的建议是能拿到原生文本的绝不走 OCR必须走 OCR 的场景一定要加校验层。视觉检索这块CLIP 类模型提供了可用的基础能力但 zero-shot 效果在专业领域会打折扣。如果业务场景固定用领域数据微调视觉编码器收益很明显。检索策略上RRF 融合是性价比最高的选择重排序适合对质量要求极高的场景。多模态统一处理这个方向论文里的思路很吸引人但工程落地还有距离。统一表征对模型和数据的要求太高短期内分路处理仍是更务实的选择。Agentic RAG 的思路在多模态场景下很有前景让 Agent 动态选择检索通路比固定管道灵活得多。最后说个我自己的体会多模态 RAG 的复杂度主要来自不确定性。文本 RAG 的管道是确定的输入文本输出向量中间没有意外。多模态 RAG 里解析可能出错、OCR 可能出错、视觉编码可能不准每一环都有不确定性。工程上要做的不是消除所有不确定性而是让不确定性可控、可观测、可回退。把每一环的错误率量化出来把关键环节加上校验和兜底比追求单点极致更重要。