多模态 RAG 架构设计

这道题其实是在问一个很实际的问题：当你的输入既有图片又有文字时，怎么让[[RAG]]系统真正理解它们之间的关系，而不是简单把图片转成文字再走老路。我先说一个核心判断，[[多模态]]RAG的本质不是把图片塞进文本RAG，而是解决跨模态对齐和检索的问题。

早期做法，很多人管它叫伪多模态，流程就是图片进来先做 [[OCR]] 或者生成 caption，把图像信息转成文本，然后走传统文本 RAG。这个方案好处是快，现成的文本检索管线直接复用，但问题也很明显，信息损耗严重，比如一张图表里的趋势、颜色、布局，这些视觉信息很难用文字精确描述，图文对齐很弱。我见过不少项目一开始用这个，结果召回率上不去，后来都换了。

现在主流是真多模态RAG，我重点说三个有代表性的框架。先看 ColPali，它的核心是延迟交互加视觉token级编码，说白了就是不用OCR，直接把文档页面当图片处理，通过视觉编码器生成token，然后和query做交互计算相似度。这个方案在文档理解场景特别强，比如发票、合同、研报，因为它保留了原图的版面信息，不会因为OCR丢字或者排版错乱。再看 Qwen-VL-RAG，它走的是统一多模态 [[Embedding]] 路线，图文联合表征，而且在中文场景有优化，电商搜索里商品图加详情页联合检索效果不错。还要看 LlamaIndex 的多模态模块，工程上最成熟，支持多向量空间加 [[Rerank]]，灵活度高，适合需要快速迭代的项目。

架构上差别主要在两层。Embedding层，有的方案冻结视觉编码器比如 [[CLIP]] 或 SigLIP，再加个投影层对齐，训练成本低，但上限有限；有的端到端训练，像ColPali用ViT加Transformer，效果好但数据量和算力要求高。检索策略上，早期融合是图文拼一起统一编码，晚期融合是分别检索再加权融合。我的经验是，如果图文关系紧密比如图文混排的文档，早期融合更优；如果图文相对独立比如商品图和文字描述，晚期融合灵活性更高，还能单独调优。

落地时怎么选？我一般这么判断。追求效果上限，比如医疗影像加报告跨模态查询，直接上端到端多模态Embedding，但前提是你得有足够的标注数据，不然容易过拟合。快速落地，比如电商搜索，可以用伪多模态加CLIP再加Rerank，先跑通再优化。成本敏感的场景，比如中小公司内部知识库，视觉caption加文本RAG就够了，别一上来就搞复杂的。

这里有个坑，很多人以为多模态RAG能解决所有图文问题，其实 前提是图文之间有强相关性。比如一张产品图和它的参数表，这是强相关；但一张风景图和一段无关的描述，强行做多模态检索反而引入噪声。上线前我会特别关注召回率，尤其是不同模态的权重怎么调，用 [[Hybrid Search]] 把向量和关键词结合起来，避免纯向量检索在冷门词上翻车。

另外，有一个方向我最近在关注，就是多模态RAG里的重排序怎么做。现在大部分方案还是用简单的加权融合，但其实可以用一个小的跨模态 [[Cross-Encoder]] 做二次排序，效果提升明显，不过会增加延迟。这块我还没完全想好怎么平衡，面试官您怎么看？

所以整体上，我更倾向于把多模态RAG看成一套组合拳，不是单一框架包打天下。文档智能用ColPali，电商搜索用Qwen-VL-RAG加LlamaIndex管线，具体选型得看数据、成本、效果要求。最关键的是，永远别指望一个方案解决所有问题，实际落地往往是多个方案拼接，加上容错兜底。