多模态RAG这个词今年在各种技术群里的出现频率快赶上智能体了。前两天做企业知识库的朋友跑来问我他们手上有一堆产品手册里面全是结构图、流程图和参表格本地部署的RAG系统只把文字抽了出来用户问故障排查图里的第二步到底是先断电还是先拔网线系统完全答不上来。这正是我最近一直在做的方向——把多模态能力接进RAG链路给LLM装上视觉之眼让图文混合文档真正变成可检索、可问答的知识。说白了纯文本RAG再好遇到图片、表格、图表、扫描件就会抓瞎。而当前多模态大模型视觉语言模型已经成熟到可以本地部署、甚至量化之后跑在消费级显卡上那我们完全可以把看图这件事拆成检索到图理解这张图两步让RAG的检索能力覆盖视觉信息。这篇文章我会把整个方案的选型、解析、索引、检索、问答链路以及我在真实业务文档上踩过的坑一次性讲清楚。1. 多模态RAG的设计思路为什么不是直接让LLM看图1.1 先理解传统RAG的边界在哪传统RAG本质上是给LLM配一个外部记忆库。文档被切成文本块embedding成向量存进向量数据库。用户提问时系统把问题向量化在库里做相似度检索找到最相关的几个文本块塞进提示词让LLM综合回答。这个链路对大段文字、结构化文本很有效但它有一个致命盲区切块和向量化都只发生在文本层面。PDF里的结构图、流程图Word里的表格截图论文里的实验数据曲线合同里的手写批注——这些信息在传统RAG里要么被丢弃要么被OCR成识别不准的文字片段结果就是用户问一个图里的问题系统要么答非所问要么干脆说知识库中没有相关内容。我见过最典型的案例是机器维修手册。手册里写着若指示灯闪烁请参照图3-2排查故障但图3-2在RAG系统里根本不存在或者被OCR成了一堆错乱的文字。用户问指示灯闪烁怎么办系统给出的回答是请参照图3-2——等于没答。这就是传统RAG的边界它根本不知道文档里有图更不知道图里画了什么。1.2 三条技术路线的对比与选型要给RAG装上视觉能力业界目前走的是三条路线我逐个说清楚它们各自的逻辑和适用场景。第一条路线是图片转文本。先用OCR加图像理解模型把图片里的内容翻译成文字描述再把这段描述当成普通文本块进入传统RAG链路。优点是改动最小检索、存储全部复用现有体系缺点也很明显视觉信息经过一次转译必然丢失细节流程图的分支逻辑、表格的层级结构、图表的坐标趋势转成文字后基本面目全非。这个方案只适合那种图文本身信息冗余不高的文档。第二条路线是多模态embedding。用CLIP、SigLIP这类图文对齐模型把图片直接编码成向量和文本向量一起入库。检索时用户问题可以被编码进同一个向量空间直接图文通吃。这条路在语义层面很干净问题在于CLIP类模型对细粒度视觉特征比如图里的具体数值、小字标注感知偏弱而且对中文场景、复杂版面效果不稳定。第三条路线是混合架构也是我现在主力使用的方案文档解析阶段把图片单独抽出来存成图片块文本切成文本块文本检索用稠密向量图片检索用视觉embedding检索结果通过融合排序合并最后把文本块对应图片一并喂给多模态LLM做生成。这条路最适配真实业务文档因为它保留了两类信息的原始形态坏处是实现工作量偏大需要自己搭不少胶水代码。从我的经验看如果你的文档里图片只是点缀用方案一就够了如果你做的是学术文献、医疗影像报告这类图即核心的文档直接上方案三别在方案二上浪费时间调参。1.3 多模态RAG适合谁、解决什么问题我在实际交付中总结最需要多模态RAG的场景有三类第一类是技术文档/产品手册大量结构图、电路图、安装示意图第二类是研究报告和论文实验结果、趋势图、对比表格是核心信息载体第三类是合同和档案扫描件既有排版信息又有签章、手写批注等非文本元素。这三类文档有一个共同点视觉信息不是辅料是主料。用户问第三季度哪个区域销量最高这类问题答案藏在柱状图里而不是正文里用户问这个型号的接线端子怎么接答案是电路图而不是文字段落。这些场景下传统RAG再怎么优化prompt、再怎么调切片策略都没用因为它根本没把视觉信息当成可检索的知识。所以如果你正在做RAG相关项目建议先盘点一下手头文档的图文比例。只有文字的文档把检索和生成做好就够了图文混合、图为核心的文档多模态RAG就不是锦上添花而是必需品。2. 核心链路实操从文档解析到向量索引构建2.1 文档解析多模态切块的第一步多模态RAG的地基在解析层这一层做不好后面检索和生成全是空中楼阁。常规的PDF解析库只能抽出文字流和图片文件根本不够用。我的方案是版面分析元素抽取两步走先用版面分析模型把每一页划分成文本块、标题、表格、图片、公式等区域再按区域把对应内容抽出来。版面分析我目前最常用的是PaddleOCR的PP-Structure系列它对中文文档的表格和图片识别比较扎实能输出每个元素在页面上的坐标和类型。另外RAGFlow里内置的DeepDoc也很顺手它能把PDF解析成带布局信息的Markdown图片会以独立元素保留还保留了页码和坐标。流程上我会把电子版PDF和扫描件分开处理电子版直接用解析库抽取文字和图片扫描件先走OCR拿到文本层再做版面分析。这块有一个关键点一定要强调表格必须单独处理。直接把表格图片丢给视觉embedding模型检索效果很差直接把表格转成纯文本又会丢失行列结构。我的做法是用表格识别模型把表格结构还原成Markdown格式把表头和行列关系保留下来同时把原表格截图也保存一份。这样查询涉及具体数值时走Markdown文本检索查询涉及表格整体布局时走图片检索两条路都通。2.2 图文切块策略把文档变成可检索的知识单元解析完成后得到的是文本块图片坐标所属页面的原始元素接下来要决定怎么切块。传统RAG里按固定字符数切块的做法在多模态场景下必须升级为语义块策略。我是这样设计的以版面分析结果为基准把每个标题下的段落作为一个文本chunk每一张图片单独作为一个image chunk但保存它的ID、所属页面、相邻文本引用关系。关键在图文绑定这一步——文档里文字往往会引用图片比如如图2-1所示我解析时会检测这种引用关系把图片和引用它的文本段落关联起来。这样检索阶段如果召回了一段文本可以顺着关联关系把对应图片也拉出来召回的是图片也能把上下文文本带上。这种绑定关系我用parent-child结构实现图片是parent引用它的段落是child反过来文本是parent被它引用的图是child。实际建索引时我会同时索引这三类数据纯文本chunk、图片chunk、图文组合chunk。组合chunk承载图围绕图的说明文字在检索阶段单独一条索引因为很多问题的答案需要图文共同决定。切块实践中我踩过最大的坑是过度切碎。有过一次把一页技术手册切成了七个文本chunk加两张图结果用户问一个综合问题时七个chunk全被召回但彼此之间缺少上下文衔接LLM生成的答案前言不搭后语。后面我改成以语义段落为最小单位一张图所属的说明段落尽量合并的策略效果明显好转。多模态场景下切块宁大勿小因为图片本身自带很强的上下文锚定能力不像纯文本那样需要精细切分来精确定位。2.3 向量化与索引如何让图片也能被搜索切块完成后进入向量化与索引环节。文本chunk我使用BGE-M3或者bge-large-zh这类中文场景表现稳定的embedding模型输出1024维向量图片chunk我使用视觉embedding模型实测下来SigLIP和BGE-Visualized效果较好尤其是中文图文检索场景BGE-Visualized比直接套用CLIP稳定不少。技术上有一个关键决策文本和图片要不要进同一个向量空间。我测试过把文本和图片都用同样的投影维度映射到统一空间直观上很优雅但实际检索效果并不理想——文本向量的语义空间和图片向量的视觉空间天然有偏差强行对齐反而互相干扰。我的最终方案是分开建索引文本向量和图片向量各自存储在独立的collection里查询时同一个query分别检索两个collection再用融合算法合并排序。向量库我用得最多的是Milvus2.x版本支持多collection、混合检索和标量过滤配合MinIO做图片对象的存储整体链路很顺。数据量不大也可以用Qdrant或者LanceDB部署更轻量。不过要提醒一句图片chunk的存储别直接用向量库存base64既浪费空间又拖慢检索正确做法是向量库里存图片路径或对象存储地址需要展示时再取。索引字段上我给每个chunk打上了document_id、page_num、element_type、caption等标量字段方便检索阶段做过滤也方便前端的引用溯源。这一点对问答系统尤其重要——用户看到答案时能定位到具体是哪一页的哪张图可信度直接上一个台阶。3. 检索与问答让LLM真正看见并提供答案3.1 检索阶段图文双路召回与融合排序多模态RAG的检索明显比纯文本复杂。同一个问题可能相关的是文本也可能是图还可能是图配套文字的组合。我的实践是用双路召回加融合排序。先说召回。用户查询先过一个轻量的query改写模块可以用小模型也可以直接让LLM做把口语化问题改写成更利于索引匹配的形式比如那个图里第二步到底先干嘛改写为故障排查图 第二步 操作顺序。改写后的query分别走文本向量检索和图片向量检索各取top20。同时这两个collection里都开了BM25稀疏检索目的是兜底专有名词和编号比如用户问图3-2靠稠密向量不一定能命中但BM25可以精确匹配图3-2这个字符串。召回完成后进入融合排序。我使用经典的RRFReciprocal Rank Fusion算法把多路召回的结果按排名倒数求和得到融合得分取top8作为最终候选。RRF的优势是不需要调权重对文本和图片这两路差异很大的检索结果比较鲁棒。之后我会加一个重排模型——纯文本候选走cross-encoder重排图片候选则用CLIP-style模型计算query和图片的相似度重排。如果项目有预算上CoPali这种基于VLM的文档检索重排模型效果还会更好但推理成本会明显增加。这里有一个我在迭代中优化过的细节检索结果必须保证图文比例不过度失衡。曾经出现过一次查询全是文本命中图片全被挤出top8导致用户问的问题明明有配图却拿不到图的情况。后面我在融合排序时加入一个最少图片数约束——top8里至少保留2张候选图片如果图片一路召回数量够的话。这个约束很糙但很有效大幅减少了答了但没图可引用的尴尬。3.2 上下文组装图片怎么喂给多模态LLM检索完不是把所有候选一股脑塞进prompt就行上下文组装直接决定问答质量。多模态LLM输入图片的方式有两类传图片URL/路径服务端模型会自己拉取或者把图片转成base64编码直接放进请求体。本地部署的Ollama、vLLM两种都支持云端API则各有差异实践中最稳妥的方式是查对应模型的接口文档。在prompt模板设计上我会把检索到的文本块和它们的引用关系整理成结构化上下文每张候选图片在上下文里有一个编号同时附带它的来源页码和截图文本也就是我们之前存的caption。Prompt里明确告诉模型以下是从知识库检索到的文本片段与图片回答时请综合这些信息如果使用了某张图片的内容请引用它的编号和页码。这样既能让模型准确引用来源也能在图文信息冲突时让模型优先参考图片内容。Prompt模板示意你是一名智能文档助手。请根据以下检索到的参考信息回答用户问题。 文本参考 [1]第3页当指示灯闪烁时请先断开电源然后检查连接线是否松动。 图片参考 [图A]第4页故障排查流程示意图 [图B]第5页接线端子示意图 回答要求 - 优先参考图片中的信息图片与文本不一致时以图片为准。 - 回答中若引用图片内容请用参见图A标注。 - 若参考信息不足以回答问题请明确说明知识库中无相关内容。 用户问题指示灯闪烁应该先做什么这一段组装逻辑是整个系统的承重墙太简略会让LLM发挥过度太详细又会挤占token。我建议在真实项目中多试几版找到自己领域文档的最佳模板结构。3.3 问答效果跨图推理与图表分析实战链路搭好后最激动人心的就是看效果。我用一份四十页的智能设备产品手册做过测试里面涵盖安装说明、电路图、参数表格和故障排查流程图。测试问题分三类纯文本问答、纯图片问答、图文混合问答。纯文本问答几乎没难度和传统RAG表现一致。真正体现多模态RAG价值的是后两类。比如用户问设备后盖的螺丝规格是什么这个问题对应的是产品规格表里的一行数据传统RAG很可能检索到一个含糊的段落回答请参考规格说明而我们系统能直接定位到表格图片的对应区域生成回答时引用表格截图用户一眼看到原表心里就踏实了。更有价值的是跨图推理。我提的问题是如果设备开机后网络指示灯不亮按照手册应该先检查哪个部件这个问题的答案分散在两张图里一张是网络指示灯说明图另一张是故障排查流程图。系统从两张图中分别提取信息综合出先检查网线连接状态再检查交换机端口指示灯这个答案并且分别引用了图A和图B。如果只靠文本这个答案根本拼不出来因为流程图的判断逻辑藏在图形分支里。图表问答是另一个惊喜场景。数据报告里的柱状图用户问去年四个季度哪个季度增长最快系统能读图得出答案并指出是第四季度还引用了图表原图。这类问题对视觉LLM来说本身不算难但难点在于从几十页报告里精准找到那张图这正是多模态RAG的看家本领。4. 工程落地经验数据评估、部署优化与避坑指南4.1 评估体系多模态RAG效果怎么量化衡量多模态RAG不能只靠感觉调优。我建议把RAGAS指标引入评估流程再针对多模态特性做一些扩展。基础指标沿用RAGAS三件套faithfulness忠实度衡量回答是否基于上下文、answer_relevancy答案相关性衡量回答是否切题、context_relevancy上下文相关性衡量检索回来的片段是否精准命中。多模态场景下我会额外加两个指标图片引用正确率回答中引用图片的编号是否和实际使用的图一致和图文一致性回答和图片内容是否矛盾。评估集用golden set的方式人工构建至少覆盖三类问题纯文本题、纯图片题、图文混合题。每类10到20条就够了关键是要覆盖真实用户会问的方式。我在实际项目里发现让业务方提供真实历史问题来构造评估集效果远好于自己拍脑袋编问题。评估跑起来后典型问题会暴露出来faithfulness低说明检索到的上下文不够或prompt引导不利图片引用正确率低说明图片检索的召回和排序有问题或者图文绑定关系没建好。这种指标定位问题的思路比我之前纯靠肉眼抽检高效得多。4.2 部署选型与成本控制本地模型还是云端API多模态RAG的部署选择比纯文本RAG更纠结因为视觉LLM对显存和带宽的要求远高于纯文本模型。本地部署方面我的经验是32G内存的Mac或24G显存的消费级显卡跑Qwen2.5-VL-7B或者MiniCPM-V 8B完全够用OllamavLLM都可以加载量化版本CLI和OpenAI兼容接口都有整合起来不费劲。如果文档量大、并发高建议上vLLM部署Qwen2.5-VL-72B这类大模型但显存至少需要48G以上成本就上去了。说实话7B量级的视觉LLM在表格和图标理解上的能力已经不错绝大多数企业知识库场景可以接受。云端API我常用的有几家GPT-4o、Claude系列、Gemini系列对复杂图表、公式、手写体的理解能力明显更强而且不用操心显存和部署。成本上按token计费一张普通图片进入上下文大约消耗数百到一千多token如果每次问答都带上5张图单次成本确实不低。我的建议是检索排序质量越高带进上下文的图越少成本越低。所以优化重点放在检索召回上而不是依赖大模型硬看堆图。在不涉及敏感数据的场景下云端API开发和本地部署的成本差异要自己算清楚。我见过不少项目前期用API做demo非常顺利一上生产就发现图片token消耗比文本高出一个量级被迫切回本地模型。建议架构层面就做一层模型接口抽象方便在API和本地模型之间无缝切换。4.3 常见问题速查表与避坑技巧多模态RAG踩坑经验整理成一张速查表基本覆盖我见过的绝大多数问题问题现象可能原因排查与解决图片从未被检索到图片未建立索引、视觉embedding模型不匹配检查解析输出是否包含图片换用中文效果更好的视觉embedding模型回答正确但引用图片编号错误检索结果中图文关联关系错乱检查parent-child绑定逻辑重点看跨页图片引用LLM忽略图片只看文本prompt中图片说明不足或图片不在模型可见范围内调整prompt明确告知存在图片及图片编号检查API是否传图成功OCR乱码导致检索不到扫描件原本质量差或用了通用OCR模型使用文档级OCR模型或对图像做预处理去噪、纠偏图文内容矛盾回答不可信检索回的文本与图片来自不同章节增加文档级分组约束确保同一文档内检索不跨文档混搭图片召回太多挤压文本空间融合排序未做图文比例控制在RRF排序后加入最少文本/最少图片约束图大导致token爆炸原图分辨率太高对图片做压缩/缩放/分块处理长图按区域切分再编码还有一个我自己反复踩过的坑图片在向量化之前没有做预处理。PDF解析出来的图片很多自带大块白色边框分辨率虚高直接进入视觉embedding不仅浪费存储检索效果还差。我在解析流水线里加了一步集中处理去除白边、统一压缩到合理分辨率一般长边1024以内、必要时做轻微增强。这一步对检索效果的提升比换模型还明显。5. 工具选型全景常用框架与模型组合盘点5.1 开源框架怎么选LlamaIndex、LangChain还是RAGFlow多模态RAG的工程链路比较长完全自己写胶水代码也可以但用开源框架能省不少事。我按实际使用体验排个序RAGFlow对多模态文档的解析和切块支持最完整内置了DeepDoc对中文文档版面分析和表格还原效果不错而且自带一个可运行的Web UI适合快速看效果。LlamaIndex的多模态支持最灵活文档里也提供了一些多模态reader和retriever的示例适合有定制需求的场景。LangChain的组件生态最齐全但多模态相关的文档相对较散需要自己拼装理解。我现在的做法是混合使用RAGFlow负责解析和初步切块把处理结果导出为标准JSON检索与问答链路自己用Python实现核心的检索、排序、prompt组装逻辑控制在几百行代码内。这样既享受了框架的解析红利又保留了核心链路的可定制性。不要为了用框架而用框架尤其是涉及多模态框架的默认配置往往比较老需要自己调。5.2 模型组合推荐从轻量到旗舰的搭配方案视觉embedding模型方面轻量方案用CLIP系列开源模型即可但在中文场景我更推荐BGE-Visualized它在中文文档检索上的表现明显好于CLIP重排阶段如果预算允许可以试ColPali它对整页PDF的视觉检索非常强把一页文档当作一张图来做检索在图文混排场景效果显著。多模态问答LLM方面我列一个组合表方便参考场景推荐方案备注本地开发调试Ollama Qwen2.5-VL-7B部署简单资源占用可控本地生产/隐私敏感vLLM Qwen2.5-VL-32B或InternVL2.5需要多卡或大显存推理速度稳定海外云APIGPT-4o / Claude复杂图表理解最强中文场景云APIQwen-VL-Max / GLM-4V-Plus中文语义理解好成本比海外API低这里顺便提一下热词里常常出现的多模态微调如果现有开源模型在特定文档类型上表现不够好可以用LoRA做低成本微调只训练一部分参数也就是常说的最小微调单位思路——多数情况下微调视觉编码器的部分层就够了不必全量微调。但在RAG链路里模型的微调优先级远低于检索质量的优化建议先把检索练扎实再考虑微调。5.3 数据流全景从一个PDF到一次完整问答把前面的模块串起来一条完整的数据流是这样的文档进入解析服务通过版面分析抽出文本块、表格块、图片块图片去白边压缩后存入对象存储文本块向量化后存入Milvus文本collection图片块经视觉embedding后存入图片collection都打上document_id、page_num等标量标签用户提问时query改写模块先改写然后双路召回RRF融合排序重排模块精排最后图文上下文组装成prompt交给多模态LLM生成回答。这套数据流的每个环节都可以单独替换组件这很重要。今天用Milvus明天想换Qdrant只需要改一下向量库的初始化代码今天用Qwen2.5-VL明天想换GPT-4o只需要改一下LLM调用接口。模块之间用标准JSON传递中间结果接口字段定义清楚整个系统就非常好迭代。6. 实战调优记录我的三个关键优化心得6.1 检索质量上不去先检查解析而不是模型这是我最想强调的一条。有段时间图片检索的准确率始终在六成徘徊我以为是CLIP模型能力不够换了好几个视觉embedding模型都没用。最后排查发现问题出在解析阶段——PDF里大量图片被解析成了带白边的整页截图图片内容本身只占画面的一半视觉embedding自然只能提取到无意义的背景特征。解决方式就是前面提到的图片预处理用图像边缘检测裁剪掉白边再缩放到合适分辨率。就这么一个步骤图片检索准确率从六成直接拉到八成五。所以调优时先确认输入模型的图片是不是干净的、聚焦内容的图片再考虑模型替换和参数调整。6.2 信息密度高的文档用agentic路由动态决定检索策略标准的多模态RAG是一次检索、一次生成但我在处理设备手册这种图文交叉非常密集的文档时发现一个问题用户提问往往需要多轮检索。比如配好网络后设备还是连不上是怎么回事第一次检索到的图文可能只覆盖配网步骤没覆盖故障排查需要基于第一轮的内容判断还缺什么再补一次针对性检索。我参考了Agentic RAG的思路在问答链路里加了一个轻量的路由模块LLM先看问题判断是否需要走多次检索如果需要就规划子查询分别检索文本和图片然后汇总多轮检索结果再生成。这种动态规划的方式在信息密度高的专业文档上效果非常显著代价是延迟和token消耗都上涨了需要根据业务场景做取舍。如果只是做科普类图文知识库一次性检索已经足够。6.3 知识库管理版本更新后怎么保证图文同步最后一个实战心得是关于知识库更新的。多模态知识库比纯文本知识库更容易出现版本不一致文档更新后文本重新索引了但图片还是旧版的导致检索结果图文矛盾。我在系统里加了一个文档版本号机制文本块和图片块都带上version字段更新知识库时按文档整体重建索引旧版本的全部删除新版本的原子写入。查询时也默认只查询最新版本彻底杜绝图文不同步的问题。这套多模态RAG方案落地之后我最大的体会是瓶颈往往不在模型而在从文档里把视觉信息完整地提取出来并和文本建立正确的上下文关联这一环。多模态大模型的能力已经足够强缺的是一个能把恰到好处的图准确送进模型视野的检索系统。我做过的所有项目里凡是解析和切块做得扎实的问答效果都远超预期凡是急于上模型、忽略底层链路的后期都要花几倍时间返工。最后再分享一个小技巧项目启动时别急着搭完整系统。找一份最有代表性的业务文档手工标注出它包含的所有图片、表格和关键文本结构用这份金标准清单去验证你的解析、检索、问答链路。链路通到位再自动化扩展否则你只会在错误的通道上越跑越远。