面试题 · 多模态
搜索「检索」匹配到口述回答，相关段落已展开。查看匹配内容 ↓
请解释伪多模态RAG与真正多模态RAG在实现方式上的差异，并分析两者在信息保留、推理能力和系统复杂度方面的优劣。
伪多模态RAG（文本桥接方案）
真正多模态RAG（统一编码方案）
| 维度 | 伪多模态 | 真正多模态 |
|---|
按学习路线查看教程、项目和面试题。
| 信息保留 | ❌ 损失严重：空间布局、颜色、纹理、细微视觉特征全部丢弃；图表结构变形 | ✅ 完整保留：像素级信息直达生成端 |
| 推理能力 | 弱：只能做"图中有什么"的浅层问答；无法回答"这个设计为什么好看" | 强：支持视觉推理、空间关系、风格分析等深层理解 |
| 系统复杂度 | 低：链路简单，成熟工具多，调试成本低 | 高：需多模态Embedding服务、大显存、跨模态对齐难题 |
实际落地中，常见折中方案：用轻量多模态模型打标构建文本索引，检索后召回原图送入强多模态LLM——兼顾检索效率与生成质量。
建议掌握主流多模态RAG框架如LangChain、LlamaIndex，理解其数据处理流程与跨模态对齐机制。
场景切入
假设你在做电商客服的文档问答，用户上传了一张商品实物图问“这个和官网描述一致吗”，你是直接拿图片去检索，还是先转成文字再检索？两种做法在效果和实现上差别大吗？
层层追问
RAG 你肯定熟悉，那如果查询里既有文本又有图片，你会怎么处理？……如果只是先把图片转成文字再检索，那和真正的多模态 RAG 有什么区别？……你觉得这两种方案在信息保留和推理能力上具体差在哪？
直球架构
请解释伪多模态RAG和真正多模态RAG在实现方式上的本质差异，然后从信息保留、推理能力和系统复杂度三个维度对比它们的优劣，最后给出选型建议。
这道题其实是在问，当我们想让[[RAG]]理解图片的时候，到底是走一条捷径，还是硬着头皮做真正的[[多模态]]融合。说白了，伪多模态就是把图片强行转成文字，再走传统的文本检索；真正多模态呢，是让图片和文本在一个共享的向量空间里去匹配。
先讲伪多模态，它的做法很直接：图片进来，先走[[OCR]]提取文字，或者用GPT-4V这种模型生成一段描述，然后把这些文本丢进普通的[[Vector Database]]去检索。它的本质是，输入是多模态的，但检索环节已经退化成了单模态。 好处是系统复杂度极低，现成的文本RAG框架、工具链都能直接用，调试成本也很低。但代价是信息损失非常严重。你想，一张图的空间布局、颜色、纹理、细微的视觉特征，全部被丢弃了。比如一张电商的商品海报，它可能用红底金字的对比来突出促销感，但转成文本后就只剩下“红色背景，金色文字”这种抽象描述，那种视觉冲击力完全没了。所以伪多模态只适合文字为主的场景，比如扫描的PDF文档、合同、发票，这类东西核心信息本来就在文字里。
再来看真正多模态，它走的是另一条路：用[[CLIP]]、LLaVA这类Multimodal编码器，把图片和文本统一映射到同一个向量空间，检索的时候直接拿图像块去匹配。它的核心优势是信息完整保留，像素级别的细节都能直达生成端。 比如你问一张设计图“为什么这个布局看起来舒服”，真正多模态能感知到元素的对齐、留白、色彩搭配，而伪多模态只能根据描述文本瞎猜。但代价是系统复杂度高很多。你需要部署多模态[[Embedding]]服务，这通常需要大显存的GPU，而且跨模态对齐本身是个难题，训练和调优都比纯文本复杂。
但实际落地，很少有场景是纯一边倒的。边界划分很清楚：伪多模态适合快速POC、成本敏感、以文字为主的文档问答；真正多模态适合电商商品图分析、医学影像、设计类问答，任何需要“看懂”而不仅是“读出”的场景。 真正的工程经验是，我常常会做一个折中方案：先用一个轻量的多模态模型（比如CLIP）给图片打标签，构建文本索引做快速检索，检索到候选之后再召回原始图片，送入一个强的多模态LLM做最终生成。这样既保证了检索效率，又保留了图片的原始信息用于推理。
这里有个坑必须提一下：如果场景是图表分析，伪多模态几乎必跪。 比如一张折线图，OCR只能读出坐标轴上的数字，但趋势、拐点、异常点这些视觉信息全丢了，你问“哪个月销量突然下降”，它根本答不对。反过来，真正多模态如果上线，要特别关注延迟和召回质量。多模态编码的向量维度通常很高，检索耗时可能翻倍，而且如果图片质量差、分辨率低，编码器可能提取不到有效特征，召回率反而下降。所以上线前我会用一批典型的query去回放，对比Recall@K，确保延迟和准确率都能接受。
另外，真正多模态还有一个容易被忽略的问题：多模态Embedding的存储和检索成本。CLIP这种模型的向量维度通常是512或768，但一些更大的模型可能到1024以上，这对[[HNSW]]索引的内存消耗压力很大。我最近在关注用[[Product Quantization]]做量化压缩，能在召回率损失1%以内把内存减半，这个方向挺有前景的。
所以整体上，我更倾向于把伪多模态看作一个快速验证的起点，真正多模态是最终目标，但中间那个折中方案才是大多数业务落地的常态。