把一份几十页的产品手册、一堆扫描合同、几十页会议 PPT以及同事随手拍的白板照片全部丢进同一个知识库然后让问答系统不仅能引用里面的话还能看懂流程图、表格和截图里的关键信息最后给出带页码和出处依据的回答——这就是多模态 RAG 工作流要解决的事。它不是简单粗暴地把图片“塞”进向量库就完事而是从文档解析、版面分析、图像理解、多模态索引到召回排序和答案生成的一整条链路。很多团队做 RAG 做到一半会发现纯文本检索很顺一旦文档里混着图召回质量立刻崩。图片里明明写了“红色指示灯闪烁对应电源故障”用户用自然语言问“设备红灯闪是什么问题”文本检索却一个字都匹配不到。这不是模型不行而是工作流设计里少了多模态这一层。这篇文章面向两类人一类是做企业内部知识库、客服问答、文档助手正被“图文混排文档”折磨的开发者另一类是刚接触 RAG想知道多模态方案和水有多深的技术选型者。我会把这套工作流拆成六个部分讲清楚单模态为什么不够、整体管线怎么搭、文档解析和分块怎么做、索引怎么建、召回排序怎么调、最后怎么验证效果。1. 为什么单独拎出“多模态”这条线单模态RAG的瓶颈1.1 你现在的RAG只做了一半标准的 RAG 流程大家都很熟把文档切成文本块用嵌入模型转成向量用户提问时做相似度检索拿回 top-k 块塞进大模型生成答案。这套流程处理纯文本没问题但真实文档几乎都是图文混排的。我见过很多项目在评估阶段就发现答案答非所问或者直接说“资料中没有提到”。一查索引发现关键答案其实在文档某张截图里。传统文本抽取流程把图片区域当作空白丢弃或者只留下 OCR 出来的一堆文字碎片没有标题、没有段落结构、没有上下文。用户问的是图形的语义比如“这张拓扑图里哪台交换机是核心节点”文本检索根本无从下手。1.2 多模态不是“让AI能看图”而是信息不丢失多模态 RAG 的核心价值不是让模型拥有视觉能力而是保证知识库里的信息在“切块—向量化—检索—生成”全链路中不丢失。图片里包含的信息通常分几类图片上的文字比如截图里的按钮名称、报错信息、图表坐标轴的标签图片的结构关系比如流程图里框与框的连线、组织结构图的层级关系图片的视觉语义比如“绿灯亮代表运行正常”“左上角的指示灯是电源”表格的二维结构比如哪些单元格属于同一行、哪一列是数值。如果只用一种文本抽取方案以上四类信息至少丢掉一半。多模态 RAG 的思路就是把这些信息用不同的处理手段分别提出来再在同一个索引和检索体系里统一使用。1.3 适用场景和反模式适合做的场景企业产品手册问答、招标文档审查、医疗影像报告解读结合文本报告和影像截图、课堂讲义问答、会议纪要加白板照片的知识库。这类场景的共同点是“文档里存在不可替代的视觉信息”答案要是不看图根本说不清。不适合做的场景也要说清楚如果文档基本是纯文本图片只是装饰或者业务对图片的实时性要求极高比如监控视频帧流那多模态 RAG 并不是最优解。硬件成本、解析耗时、存储开销都会翻几倍而且视觉模型调用在长文档批量处理时并不便宜。先把场景和收益想清楚再动手这个项目才值得做。2. 多模态RAG工作流的整体管线设计2.1 从文件进来那一刻开始分层多模态 RAG 和单模态 RAG 的第一步相同都是文件接入但从文件接入之后就分叉了。完整管线大致是这样文件接入PDF、Word、PPT、图片、扫描件、网页文档解析版面检测、OCR、表格还原、标题层级识别多模态分块生成文本块、图片块、表格块并建立块之间的关联关系内容增强对图片生成文字描述对表格生成摘要对 OCR 文本做纠错向量化文本块用文本嵌入模型图片块用视觉嵌入模型或统一多模态嵌入模型索引构建向量索引 关键词索引 元数据过滤字段检索召回多路并行召回文本、图片、表格各自召回候选排序融合重排序、按块类型加权、置信度过滤上下文合成把相关文本、图片描述、原图按 token 限制拼装答案生成使用纯文本大模型或多模态大模型生成带引用的回答。这个流程里最容易被忽略的是第 3 和第 4 步。很多人以为把 PDF 按页转成图片再用视觉模型一次性处理就好。实际上如果没有区域级的分块检索时就无法定位到“某一页的左上角那张图”只能整页返回命中精度很差。2.2 两种主流路线密集提取 vs 粗粒度挂载我在实际工程里见过两类主流做法各有取舍。第一类是密集提取路线文档解析阶段把所有图片、表格、公式区域单独抠出来做成独立的索引块。图片块包含原图路径、OCR 文本、图像描述、来源坐标和页码表格块包含还原出的 Markdown 表格和原始表格截图。检索阶段这些块和文本块地位平等。优点是召回精确用户问“图里的接线方式”可以直接命中图片块缺点是解析链路复杂图片块如果太多索引体积和检索耗时会明显上升。第二类是粗粒度挂载路线不做密集抠图而是把图片和它所在的段落绑定为一个超级块。比如一个第五章的段落包含正文文字和一张插图整体作为一个索引单元。检索时用文本向量匹配需要回答时把整块内容包括图片一起喂给多模态模型。优点是实现简单不容易漏上下文缺点是图片的位置和语义可能不够紧检索精度受限。选哪条路线我建议从“最终回答是否需要展示原图”来反推。如果问答系统要把原图作为答案的一部分展示给用户那必须走密集提取因为只有独立图片块才能准确定位和返回。如果只是让助手参考图里的信息、最终输出纯文字总结那粗粒度挂载可以省掉很多工作量。2.3 工作流设计的关键决策点在动手搭之前有几个决策点必须提前定不然后面返工的成本很高。分块粒度图片是按整图建块还是把图里的子区域比如流程图中的每个框再拆一般建议按“语义完整”为准整图建块是最稳妥的起步方案。图片是否裁剪保存密集提取路线必须把抠出来的图片保存为独立文件或者至少保存坐标方便后续展示。是否使用视觉模型生成描述强烈建议做这是性价比最高的一步。是否做表格结构还原如果文档里表格占比高必须做否则表格块就是废块。是否结合关键词检索建议加多模态向量对精确数字、型号、人名匹配并不擅长BM25 类关键词检索能补位。生成模型是否多模态如果已经有支持图像输入的多模态大模型可以在生成阶段直接传原图否则只能传 OCR 文本和图像描述。这些决策没有标准答案但底线是每一种类型的块都必须有结构化的元数据方便后面单独调试。3. 文档解析与分块策略图片、表格、PDF、PPT怎么处理3.1 解析管线不要从OCR开始先从布局开始很多人处理 PDF 的第一反应是整页 OCR。这个做法风险很大。OCR 会把页面上的文字按坐标顺序吐出来但完全不理解“哪段文字对应哪张图”也不理解“这个框是标题还是正文”。正确做法是先用版面布局模型把页面切分成不同区域。模型通常会输出若干区域每个区域带类型和坐标框例如“标题”“正文”“图片”“表格”“页眉页脚”。拿到这些区域之后再对图片区域做 OCR 和图像理解对表格区域做表格结构识别。举个例子一份设备安装手册的某一页左侧是结构图右侧是文字说明。布局检测之后左侧图片区可以被单独提取右侧文字区按段落切块。如果反过来先用 OCR你得到的是文字说明和图片里标注的数字混在一起的一堆无序文本检索效果很难好。3.2 图片处理的四个层次图片绝不是“转成文字”就完事。我按信息保真度把图片处理分成四个层次实际项目里可以按需选择原图保留必须做。原图用于展示、溯源也是多模态模型输入的原材料。OCR 文字提取把图片内出现的所有文字提取出来包括图注、坐标轴、标注框里的文本。这一步解决“图上写了什么”。图像语义描述用一个视觉语言模型看完整张图生成一段自然语言描述例如“该图展示系统架构分为三层上层是应用服务中间是消息队列下层是数据库”。这一步解决“这张图表达什么意思”。向量化图像经过视觉编码器得到向量用于图文跨模态检索。这一步解决“用户用一句自然语言能不能匹配到这张图”。四个层次应该在索引字段里各占一席。OCR 文本和图像描述都作为可检索文本原图路径作为展示字段图像向量作为辅助召回信号。3.3 表格解析是最容易翻车的地方表格识别是最容易让多模态 RAG 翻车的部分。PDF 里的表格本质上是坐标线条和文字的堆叠没有真正的行和列结构。如果用文本切块的方式处理一个完整表格很可能被切成几十个碎片检索时间一长召回结果完全不可用。我的经验是两步走第一步用表格结构识别模型把表格还原成单元格坐标再转成 Markdown 或 HTML 格式。第二步把还原出来的文本表格和原始表格渲染截图一起保存为表格块。这样既保留了语义结构又保留了视觉版式。表格块和普通文本块在检索时要有不同的待遇。表格的检索关键词往往包含列名、数字范围、单位、表头信息分块时要保持整表完整不要强行按 token 切割。如果表格特别长至少也要按“表头若干行”为一个语义单元并且反复带上表头信息。3.4 分块参数的实操建议分块参数没有银弹只能给一组我常用的起点普通文本块512 到 1024 token重叠 100 到 150 token图片块整图作为一个块单个块内包含 OCR 文本、描述文本、原图路径、图片类型表格块一个表格尽量作为一个块如果超大按行组拆但每组重复表头代码块如果文档包含代码按函数或代码段切不要按行切。每个块的元数据字段建议固定为来源文件名、文件版本、页码、块类型、布局区域坐标、所属章节路径、OCR置信度、生成时间。这些字段在后续重排和过滤时非常关键。比如用户追问“在第六章里找”可以直接用元数据过滤如果 OCR 置信度太低也可以通过阈值把它从候选中剔除。4. 向量化与索引构建文本向量、图像向量、混合检索4.1 文本向量和图像向量要不要进同一个向量空间这是多模态 RAG 选型里一个绕不开的问题。目前有三条路线路线一用同一个多模态嵌入模型把文本和图像同时编码到同一向量空间。好处是用户查询文本可以直接和图片向量计算相似度天然支持跨模态检索。坏处是模型选择面窄维度固定更新成本高。路线二文本和图像各用各的编码模型分别建索引检索时两路召回再合并。好处是可以灵活替换模型坏处是要处理两种向量之间的分数不可比问题还要设计合并逻辑。路线三把图片先转成文本描述只建文本索引。这是最简单的方式效果往往比我预期的好。坏处是图片里很多微妙的视觉细节会丢失比如按钮间距、颜色、边框状态。我的建议是起步阶段先走路线三把所有图片的语义描述转成文本混入文本索引。等验证了场景确实需要“以图搜图”或“图文联合检索”再上路线一或路线二。不要一上来就追求复杂的多模态向量。4.2 图像描述是“穷人版多模态”但真管用给每张图片生成一段高质量描述是多模态 RAG 里性价比最高的一笔投入。描述不要泛泛地说“这是一张图”而是要把图里和业务相关的关键信息写清楚。举例来说针对一张设备状态面板截图生成描述时应该包含面板的整体布局、每个指示灯的颜色和位置、对应的文字标签、以及可能的含义。这样的描述和用户的提问“设备红色指示灯闪烁是正常吗”就有很高的文本相似度检索系统不需要真正理解图像内容也能命中。实际操作中我会同时保存两份描述一份是简短的“图注型描述”用于快速召回另一份是详细的“像素级描述”用于生成阶段给大模型补充上下文。如果预算有限至少保证第一份描述是结构化的像“图中从左到右依次是……其中第三个是……颜色为……”。4.3 混合检索的排序合并多模态 RAG 强烈建议做混合检索也就是向量检索 关键词检索并行。向量擅长语义匹配关键词擅长精确匹配型号、编号、品牌词。比如用户问“AK-300 型号的安装孔距是多少”向量可能因为语义太近召回一堆不相关内容关键词能直接拉住具体型号。多路召回之后要合并排序。最简单的做法是加权融合比如最终得分 0.6 × 向量相似度 0.3 × 关键词得分 0.1 × 元数据匹配得分。但要注意不同检索源的分数分布完全不同直接加权前必须先做归一化或者把每路结果都转成排名序号再融合。还有一个实操细节向量检索不能只取一个索引。图片块的描述文本和文本块的正文往往是两套文本如果它们混在同一索引里检索向量分布会互相干扰。稳妥的做法是给文本块和图片描述块各建一个索引或者至少在向量字段上打类型标签召回时分别限制各类型的数量。4.4 索引更新与去重文档更新时最头疼的问题就是重复和过期。一个文档改了两版旧版本块还留在索引里回答时可能同时引用新旧内容产生矛盾。建议以“文件版本”为索引单元。每处理一个新文档给这个文档分配一个全局唯一的文档ID和版本ID所有块都记录这两个字段。更新时先按文档ID删除所有旧块再写入新块。删除操作要有幂等性避免重复跑任务时把索引插两遍。另外图片块去重也不能忽略。同一张图片在 PPT 和 PDF 里可能会出现多次视觉特征高度相似。可以在图片入库时计算一个感知哈希如果哈希接近保留清晰度高的那一条并把其他位置的引用信息合并进元数据。5. 检索排序与多模态融合召回之后怎么办5.1 召回不等于答案重排决定质量第一次召回通常会拉回 20 到 50 个候选块但真正有用的可能只有两三个。如果直接把 top-k 塞给生成模型不仅浪费 token还容易引入干扰信息。重排这一步必须做。对于文本块可以用一个交叉编码器模型把查询和候选块拼接后打分比单塔向量相似度准得多。对于图片块不能直接用交叉编码器打分因为输入不是纯文本。我的做法是把图片块里面的“OCR 文本 图像描述”拼成一段文本再让交叉编码器打分。这样图片块和文本块在重排阶段就统一到了同一套打分逻辑上。5.2 跨模态置信度校准这里有一个多数人都会踩的坑不同来源的分数完全不可比。OCR 输出置信度 0.95 的文本图像描述模型输出的得分可能是 0.7交叉编码器输出可能是 0.1 到 0.9 的 logits它们根本不是同一个量纲。所以不能只依赖模型分数还要在业务层做硬规则。我从实践中总结出的校准策略设置类型底线表格块必须包含至少 3 个单元格否则过滤OCR 置信度过滤低置信度的图片块不进入最终候选类型配额最终给生成模型的上下文里文本块最多 N 个图片块最多 M 个防止某种类型霸屏人工反馈回传把用户点击、点赞、踩过的回答作为重排模型微调样本这是最有效的长期优化路径。5.3 上下文窗口怎么塞多模态内容生成阶段的输入组装是很多人会忽略的信息丢失重灾区。如果生成模型是纯文本模型那就只能把图片的 OCR 文本、图像描述、表格 Markdown 拼进去原图没法用。这时要注意控制总量不要贪多恨不得二十个块全塞进去。一旦上下文太长模型会把关键信息淹没在无关内容里。如果生成模型支持图像输入组装方式又不一样。多模态模型的对话消息里图像是一个独立的内容类型和文字消息并列。实际操作中我通常只选择 2 到 3 张最关键的图片传入并且每张图片都用文字标注一下来源位置比如“参考图片来自第 3 页左上角”。这样模型既能看图又能知道图在原始文档里的位置。5.4 幻觉与引用控制多模态 RAG 的幻觉问题比单模态更隐蔽。文本模型面对一张无法真正看到的图时很容易根据描述文本脑补细节。比如图像描述只写了“图中有一个红色指示灯”模型却回答“红色指示灯表示温度过高”这个结论不一定有依据。我处理这个问题的方式是双管齐下。第一在提示词里明确要求“只能依据给定材料回答如果材料中没有明确说明必须说信息不足”。第二要求回答逐条列出依据引用格式可以是“[来源文件第X页块类型图片]”。这样用户能点击溯源系统也能在评测时自动检查引用是否存在于真实输入中。6. 生成阶段与评测如何验证工作流有效性6.1 评测指标不能只看回答是否流畅多模态 RAG 如果只看“回答是否流畅”会掉进严重的评测陷阱。回答流畅不代表检索正确更不代表图片信息被正确使用。我建议至少盯住五个指标。召回命中率标准答案里提到的依据块是否出现在检索返回的候选块里。这是最底层指标如果这里失败后面全是空谈。引用准确率模型回答中列出的每个来源是否真的包含支持该句结论的内容。这比召回率高一个层次可以防止模型瞎编来源。答案忠实度把答案和给定材料交给裁判模型打分判断是否出现了材料之外的信息。多模态场景下尤其要检查图片细节有没有被错误脑补。视觉依赖度评测集中有多少问题属于“必须看图才能回答”系统对这类问题的成功率是多少。这个指标能直接反应多模态改造的价值。端到端任务成功率不问具体某一步而是模拟真实用户完整走一遍问答流程看最终答案是否让用户满意。这是业务方最关心的指标。6.2 构建一份“多模态评测集”没有评测集的 RAG 改造都是自嗨。我建议从真实业务文档里挑 100 到 200 个问题覆盖文本、图片、表格三种类型组成专属评测集。针对每个问题除了写标准答案还要标注“期望依据类型”。比如问题“设备面板上哪个灯表示电源正常”期望依据类型图片区域 OCR是否必须原图展示是允许的回答内容“右上角绿色指示灯常亮表示电源正常”标注完这些字段之后每次工作流改动都能精确看到“图片类问题有没有变好”“表格类问题有没有变坏”。有了这份评测集很多争论都可以直接量化。6.3 分模块调试先分开看再合起来多模态 RAG 链路长出了问题最难定位。所以我一直坚持模块化调试不给中间状态留黑盒。当发现一个回答不对先判断问题出在哪一层。手段是打印每一层的中间结果解析层打印版面区域列表、OCR 文本、表格结构索引层打印每类块数量和向量字段内容检索层打印每路召回命中和分数重排层打印最终送入生成的候选块列表生成层打印完整的 prompt 消息内容。哪个环节的预期状态不对就修哪里。一个真实案例某次问答系统总是答不出图片里的型号信息。我以为图像描述没写全后来打印检索结果才发现图片块的描述文本生成了但索引更新任务跑挂了根本没有写入向量库。只看最终答案永远查不到这里。6.4 常见失败模式与对策最后把我在多模态 RAG 项目里遇到最多的失败模式整理成一张表做踩坑参考。失败现象根本原因对策图片块检索不到图片描述太泛或未写入索引用结构化描述模板检查索引更新任务表格答案残缺表格被拆成多个碎片整表建块保留 Markdown 和截图双格式回答里出现图中没有的细节模型根据描述脑补限制只能使用给定材料加入不确定性提示图片块总是排在前面向量分数未归一化对分数做归一化按类型配额控制上下文爆掉图片原图占用大量 token控制传入图片数量图片压缩或降分辨率文档更新后答案新旧矛盾旧块未清理按文档版本做全量替换删除旧版本块用户找不到答案来源回答没有引用编号生成时强制加入来源列表我在实际操作中的体会是多模态 RAG 工作流真正难的从来不是某一个模型有多强而是文件解析、分块、索引、检索、生成这五个环节的衔接是否够稳。每次改一个参数都要回归一次评测集看整体曲线是向上还是向下。把各个模块的日志和中间结果留好遇到问题可以先按环节缩小范围再去调具体模型和阈值这条路虽然不性感但最可靠。最后再分享一个小技巧先拿 30 到 50 份有代表性的文档把全链路跑通再做 500 份以上的批量扩充。小批量调试时还能人工看中间结果大批量一上很多隐藏问题就会迅速放大。