这道题其实是在问,当大模型需要引用的不只是文字,还有图片、视频、音频这些信息时,[[检索增强生成]]要怎么做。传统RAG只处理文本,但真实世界的信息是[[多模态]]的。所以多模态RAG的核心就是让模型能“看见”并引用这些非文本数据。
先说边界。多模态RAG不是万能的。如果业务场景里用户只问纯文本问题,比如“退货流程是什么”,那传统文本RAG就够了。但一旦涉及到“这个商品长什么样”、“帮我找一张和这个类似的图”,或者“这个CT影像对应什么诊断”,就必须上多模态。落地时往往不是二选一,而是文本RAG和多模态RAG一起上,根据输入类型路由到不同的检索通道。
核心组件其实就三块:多模态编码器、跨模态检索器、多模态生成器。编码器负责把不同模态的数据映射到统一的向量空间,最典型的就是[[CLIP]],它让文本和图像在同一个空间里可比。检索器在这个统一空间里做相似度搜索,找到相关的图文片段。生成器则是一个能理解多模态输入的大模型,比如LLaVA或Qwen-VL,它接收检索结果和用户问题,生成最终回答。
这里有个大坑:跨模态语义对齐。说白了,怎么让“一只黑猫”的文本描述和一张黑猫的图片在向量空间里距离足够近。训练数据如果不够好,或者模态差异太大,比如音频和视频,对齐就很难。我上线前一定会用一批人工标注的query去测召回质量,看看图文是否真的匹配。另一个坑是索引构建:图像怎么切分?视频关键帧怎么抽?音频怎么分片?这些都得根据具体模态和数据特点来设计,没有通用方案。
举个例子,电商智能导购。用户上传一张穿搭图,想找类似的商品。系统先对图片做编码,在[[向量库]]里检索相似商品图,同时检索对应的详情文本。然后多模态大模型结合这些信息,生成搭配建议。这里常见失败场景是:用户上传的图背景复杂,模型可能只关注了背景而非衣服本身。所以我会在检索前加一层物体检测,先定位主体区域再编码。
说到检索,其实还有一个延伸问题:多模态检索的排序怎么做?图文混排时,单纯靠向量距离不够,通常需要二次[[重排]],比如用[[Cross-Encoder]]对图文对做更精细的匹配。但重排的计算成本很高,所以要做级联策略。
最后说说我的判断。多模态RAG的落地前提是数据质量和索引成本可控。如果业务里多模态数据量巨大,比如上亿张图,索引构建和更新就是个大工程。我会更倾向于先用纯文本RAG兜底,对多模态查询做降级处理,比如用图片的文本描述替代原图检索。等基础设施成熟了再逐步上线多模态。说到底,多模态RAG的本质是把“检索”从文本知识库扩展到多模态世界,但工程上永远要在效果和成本之间做取舍。