多模态RAG技术全解：从共享嵌入到跨模态融合与评估

简介：一份聚焦多模态检索增强生成（Multimodal RAG）的综述型PDF，面向自然语言处理、计算机视觉及多模态学习方向的研究者和工程师。内容以《Ask in Any Modality》论文为主体，系统梳理多模态RAG的完整流程，包括查询预处理、共享嵌入编码、模态中心检索、相似性搜索、重排序、分数融合与注意力机制、反馈式迭代增强，以及思维链推理、来源归因和损失函数优化等生成阶段技术，同时涵盖数据集、指标、基准测试与多种应用场景。资源为单文件PDF（共1个文件），压缩包约8.4MB，适合作为领域入门导览或论文精读的辅助材料。版本经过更新，补充了第四章内容并采用更美观的Lapis主题，章节布局清晰，便于快速定位检索、融合、增强、生成四大技术模块；预览中还包含流程的数学化形式定义与代表性系统的条目化梳理，有助于边读边对照相关实现。目前已有517人学习浏览，适合希望快速建立多模态RAG整体认知的读者。

1. 多模态RAG为什么不是「LLM + CLIP」的简单加法？

给大语言模型接上一个视觉编码器，算不算多模态RAG？不少团队一开始都这么想，结果在评测集上翻了车。一份系统性综述把原因讲得很透：多模态RAG与单模态RAG的分水岭根本不在「能不能看图」，而在跨模态对齐。文本、图像、音频、视频要编码进同一个共享嵌入空间参与统一检索，检索结果要跨模态融合，生成阶段还得把不同模态的证据组织成连贯的推理链——这套流程在自然语言处理任务里每一步都比单模态多一层对齐代价。搞懂这层机制，才知道幻觉与过时知识问题为什么没有被「加个编码器」简单解决，也才看得懂后续那些模型在设计上的取舍。

2. 共享嵌入空间：为什么文本、图像、音频非要挤进同一个向量空间

2.1 综述给出的形式化定义，其实是理解全篇的钥匙

这份综述在引言部分给出了多模态RAG任务的数学化表达，看似只是符号定义，实际上是整篇文章后续所有技术的总纲。输入是一个多模态查询q，它可能是「一张图 + 一段话」的组合；语料库D中的每个文档d_i都和一种模态m_i关联，由对应模态的编码器φ_m处理，映射到一个共享的语义空间中，得到编码表示。所有编码表示的集合记作某个向量集合，而检索模型要评估每个编码文档表示与查询编码Q之间的相关性，写作评分函数s(Q, D_i)。

这里有两个细节值得停下来看。第一，「模态相关性阈值τ_m」是带模态下标的，意思是每个模态有自己独立的判定阈值，而不是统一用一个阈值切所有数据。这背后是一个很容易被忽略的现实：不同模态的检索分数分布差异极大，文本检索器打出的分数和图像相似度分数根本不在一个量纲上，统一阈值必然让某个模态永远过不了线。第二，评分函数被明确拆成两个角色——负责初步检索的粗粒度评分和负责对初步结果精细化筛选的细粒度评分。这对应了后续章节里的「先粗排再重排」结构，也就是说，多模态RAG从形式化定义开始就没有打算用一次检索解决所有问题。

生成阶段则把用户查询q和检索到的多模态文档一起作为上下文，交给生成模型输出最终的多模态响应。从这套形式化定义可以很自然地推导出，多模态RAG系统至少要回答三个问题：用什么空间统一表示、用什么策略检索、用什么机制融合。后面三章的展开，本质上都是对这三个问题的回答。

2.2 CLIP式对比学习：一个空间装所有模态的代价与收益

把文本和图像装进同一个向量空间，最经典的实现就是CLIP式的对比学习。图文对作为正样本，batch内的其他样本作为负样本，用InfoNCE损失拉近匹配的图文表示、推开不匹配的表示。训练完成后，一张图片和一个句子可以直接算余弦相似度，因为两个编码器的输出被对齐到了同一个语义空间。MuRAG、RA-CM3这类早期多模态检索增强系统，底层用的就是这么一套思路，将CLIP、BLIP等预训练模型的表示作为检索基础。

这个设计收益很直接：检索接口从「每模态一套特征」收敛成「一个向量一个点」，查询和文档可以在同一个索引里做相似性搜索。但代价是信息瓶颈。一张图经过视觉编码器得到的是一个或少数几个全局向量，图像里的物体空间关系、属性绑定细节、文字内容都可能被压缩掉；一段文本的词汇级语义也被平滑成了高维向量里的数值。也就是说，共享空间保证的是「可比较性」，牺牲的是「保真度」。这解释了为什么综述里后续会有查询预处理、重排序、文档布局理解这些补偿机制——它们都在试图把共享空间里丢掉的信息「找回来」。

2.3 查询预处理：原始多模态查询为什么不适合直接检索

用户输入的多模态查询往往不能直接用。比如用户给一张产品图加一句「这个牌子的同系列还有哪些」，如果直接把图像特征和文本拼起来去检索，大概率召回一堆无关图片。综述里提到的查询预处理阶段，做的就是让查询更适合后续处理：把图转换为文本描述（image captioning）、把文本查询改写为检索友好形式、消除歧义、甚至把多跳问题拆解成若干子查询分别检索。

这里最容易被低估的是子查询分解。Dyn-VQA这类动态检索基准会构造需要多跳推理的问题，问题里既包含图像证据又有文本知识，比如「图上这个人穿的外套品牌，在哪些场合被推荐过」。如果不把「识别外套品牌」和「检索品牌推荐场景」拆成两个子查询，第一次检索就不知道该拿图像去匹配还是拿文本去匹配。不少实现的做法是先用一个轻量的多模态模型判断「这个查询缺什么信息」，再决定是否触发二次检索。查询预处理本质上是把「用户意图到检索入口」的鸿沟补上，这也是多模态RAG比单模态RAG更依赖预处理的原因——单模态下查询和文档同构，跳过了这一层往往也能跑，多模态下直接检索的结果几乎必然劣化。

2.4 共享空间的隐藏缺陷：信息瓶颈决定上层策略

共享空间带来的另一个问题是细粒度定位能力不足。精确到「页面里第三段第二行的数字」这种需求，用全局向量检索几乎不可能达成，因为全局向量已经把位置信息抹平了。于是文档检索领域出现了ColPali、ColQwen2这类做法——干脆不在全局向量层面对齐，而是把页面图像切分成视觉patch，让视觉语言模型为每个patch生成向量，检索时以token级别做交互匹配。这相当于绕开了共享空间的信息瓶颈，用更细粒度的表示去换精度。

把这一点想清楚，就能理解整套多模态RAG的设计逻辑：共享空间负责「找到可能相关的候选」，模态内的专用表示负责「确认相关性」，重排序和融合负责「综合决策」。空间统一是第一步，但绝不能是最后一步。搞懂了这种分层补偿的思维，后面看检索策略和融合机制时就不会觉得它们是零散技巧，而是对同一个缺陷的连续修补。

3. 检索策略：MIPS、模态中心检索与重排序，怎么让检索又准又快

3.1 MIPS与近似搜索：为什么向量检索必须走内积这条路

多模态查询编码成向量后，检索任务变成了在一个巨大的向量集合里找到与查询最相似的k个向量。Laion-5B这种规模的语料库有数十亿条图文对，精确线性扫描的代价在在线服务里不可接受，于是最大内积搜索及其近似变体成了标配。MIPS的思路是把「内积最大」作为检索优化目标；当编码器输出经过归一化后，内积等价于余弦相似度，所以实际部署时经常看到「归一化 + 内积 + 近似最近邻索引」这一套组合。

近似索引的典型手段包括HNSW（层级可导航小世界图）和IVF（倒排文件）。HNSW把向量组织成多层图结构，检索从高层粗粒度出发，逐层下探，只检查路径附近的节点；IVF先用聚类粗分桶，检索时只在最相关的几个桶里做精确搜索。MuRAG、RA-CM3这类系统的实现对具体索引结构各有选择，但共同点是都用了近似的MIPS变体来保证检索延迟可控。这里有一个容易踩的误区：近似索引的快是牺牲召回换来的，索引的M参数（每节点连接数）和efSearch（搜索时检查的候选数）直接影响延迟与精度的平衡，调索引参数本质上是在和业务指标做交换，而不是什么「默认值一劳永逸」。

3.2 模态中心检索：先按模态分类，再各自精查

综述梳理的检索策略分为文本中心、视觉中心、视频中心、文档布局理解几大类。文本中心检索用BM25、MiniLM这类模型处理文本模态，BM25处理专有名词和关键词召回，MiniLM做语义匹配；视觉中心检索有EchoSight、ImgRet、iRAG、MV-Adapter等方法，基于图像特征匹配找相似视觉内容；视频中心检索需要处理时间维度的特征，比如对视频片段做时空编码后再检索；文档布局理解则用ColPali这类模型把PDF页面当作图像理解，支持「找到包含某段文字的页面」这种细粒度需求。

把检索器按模态拆分，而不是所有模态共用一个检索器，是因为共享空间里的跨模态距离并不可靠。一个文本查询和一个图像文档的余弦相似度，并不能稳定地反映语义相关性——不同模态的编码器可能在训练数据上对齐得不完美，导致某些语义区域里「地图没对上」。模态中心检索相当于先把检索限定在同构数据里，用模态内更成熟的相似性度量把问题缩小，再在融合阶段处理跨模态关系。实际系统中「通用向量检索 + 各模态专用召回」并行运行、结果合并，是比只用一个共享索引稳妥得多的工程结构。

下表整理了常见检索策略与适用场景：

3.3 重排序：粗筛之后为什么还要精排

粗检索阶段的目标是快速召回足够多的候选，K值通常会设置得比较大，因为粗排模型要快，打分质量必然粗糙。但top-K大了，噪声比例也随之上升，直接把这些候选塞给生成模型，会让模型面对大量无关信息，生成质量反而下降。重排序阶段的作用就是把初步检索结果重新排序，剔除低相关项，把最符合需求的文档顶到前面。

实现精排的常见路线有：用多模态相似性度量重新计算相关性，比如把查询和文档分别编码后，用一个更强的跨模态模型打分；用交叉编码器对「查询-文档」对直接输出相关性分数——不同于双塔式编码器把查询和文档分开编码再做点积，交叉编码器让两个输入在同一个Transformer里交互，精度更高但计算量大，只能放在重排阶段对少量候选跑。综述里还提到统计方法校准、硬负挖掘过滤、共识过滤等机制，核心目标一致：减少「看似相关但实际无用」的迷惑项。硬负挖掘的思路是主动把「很难区分、容易被误判为相关」的样本加进训练集，迫使重排模型学会更精细的区分；共识过滤则是多个打分通道对结果一致性做交叉验证，一致性低的文档降权。

3.4 迭代增强检索：把反馈变成闭环

单次检索很难一步到位，尤其是涉及多跳推理或知识组合的查询。综述把增强技术阶段单独列出，强调带有反馈机制的迭代检索：根据前一次检索的结果做反馈调整，再发起下一轮检索，逐步优化给生成模型的输入。这个环节的具体实现分两种风格——自适应检索根据查询复杂度决定检索次数，简单查询一步到位，复杂查询自动触发多轮检索；迭代检索则每轮都吸收上一轮的结果，把高置信片段改写进下一轮查询。

类比伪相关反馈，迭代检索的直观版本是：第一轮检索返回一批文档后，从文档里抽取关键实体、时间、关系等要素，重构成新的查询向量再次检索。IRAM、OMG-QA都有类似的多步细化机制。但闭环检索有一个必须警惕的代价——错误累积。如果第一轮检索结果本身就偏，基于它重构的查询会进一步带偏第二轮。实际工程里要给这个循环设置最大轮数和收敛条件，比如「连续两轮结果重叠率超过一定比例就停止」，防止系统在错误方向上越走越远。这把「多模态RAG调的是检索链路，不是调单个模型」这个观点体现得很充分。

4. 融合机制：分数融合、交叉注意力与统一投影，跨模态信息怎么汇合

4.1 分数融合：第一坑是不同模态的分数不在一个量纲

检索阶段往往并行跑多个模态检索器，每个检索器返回自己的相关性分数。融合机制要解决的第一个问题就是：这些分数怎么合并成最终的相关性判断。直接相加是最直观但也最容易翻车的做法——BM25的分数可能从0到十几，CLIP相似度通常在-1到1之间，前者量级大得多，直接相加等于把视觉判断彻底淹没。这也是为什么综述里单独强调「分数融合和对齐」：融合之前必须先对齐。

常见的修正路线有三条。第一是归一化，对每个模态的分数分布做min-max或z-score变换，把分数拉到同一尺度再加权相加；第二是校准，用统计方法估计每个模态分数的先验分布，把分数转换为概率化表示再融合；第三是用更强的模型替代显式融合规则，比如交叉编码器直接读「查询+多模态文档」，让模型端到端输出一个统一分数。第三条路线之所以有效，是因为它把「哪个模态更可信」的决策也交给了模型，而不是人为定死。综述里提到的CLIP分数融合也是同理，把图文相似度作为其中一个跨模态信号参与综合打分，融合权重甚至可以由验证集上的表现反向学习。

注意：分数融合的权重不是一成不变的。某个问答场景里文本证据更关键，另一个场景里图像证据更关键。固定权重的系统面对任务切换时会出现明显性能抖动，务必要准备一套在验证集上自动调权的机制。

4.2 跨注意力融合：让模型自己决定看哪路信息

分数融合是在「检索结果层面」做决策，而基于注意力的融合是在「表示层面」做决策。综述里提到的跨注意力机制，让模型动态加权不同模态的交互，核心操作是把文本token和视觉token放进同一个序列，让每个token通过注意力机制看到其他模态的信息。最小实现可以用PyTorch写出来：

import torch import torch.nn as nn class CrossModalFusion(nn.Module): def __init__(self, hidden_dim, num_heads=8): super().__init__() self.cross_attn = nn.MultiheadAttention(hidden_dim, num_heads, batch_first=True) self.norm = nn.LayerNorm(hidden_dim) self.ffn = nn.Sequential( nn.Linear(hidden_dim, hidden_dim * 4), nn.GELU(), nn.Linear(hidden_dim * 4, hidden_dim), ) def forward(self, text_tokens, vision_tokens, vision_padding_mask=None): # text_tokens: [B, T, D] 文本编码器输出 # vision_tokens: [B, V, D] 视觉编码器输出的patch特征 context = torch.cat([text_tokens, vision_tokens], dim=1) attended, _ = self.cross_attn( context, context, context, key_padding_mask=vision_padding_mask ) attended = self.norm(context + attended) return self.ffn(attended)

这段代码的逻辑是：把文本token序列与视觉patch token序列拼接成同一个序列后，让注意力机制的Q、K、V都来自这个拼接序列。于是每个文本token在计算注意力时，会自然地「看」到所有视觉patch并分配权重，视觉patch也一样能参考文本token。key_padding_mask用来屏蔽掉视觉特征中无效的padding位置，避免模型把填充向量当成真实信息。norm和残差连接是标准的Transformer结构，保证深层梯度稳定；后面的FFN给融合后的表示提供非线性变换能力。

理解这段代码，就理解了为什么跨注意力比简单拼接更适用：简单拼接把「对齐」任务丢给下游生成模型自学，模型容量被浪费在模态对齐上；跨注意力则用专门的注意力层完成对齐，同时还能按查询内容动态调整模态权重——查「颜色」时视觉token权重高，查「品牌历史」时文本token权重高。视频文本对齐、多模态数据融合这些任务采用跨注意力，看中的正是这种动态加权能力。

4.3 统一框架与投影：把异构输入整理成同构表示

跨注意力融合是「模型内部」的融合，统一框架和投影则是「系统层面」的融合。综述提到的统一框架思路，是先把多模态输入整合成一种连贯的表示，再送入后续生成；投影操作把不同模态数据映射到同一空间。层次交叉链的做法是分组分层地做融合——先让同模态内部的信息充分交互，再做模态间的交叉融合，避免一开始就把所有token混在一起导致注意力分散；迭代集成则反复执行融合操作，每轮更新一次融合表示，让信息在多次交互中逐步逼近完整语义。

统一格式的价值不只体现在模型效果好，还体现在存储和可解释性上。多模态数据统一成同一种中间表示后，离线索引可以集中管理，不再为每个模态维护一套独立的检索结构；推理阶段也能追踪「哪部分表示来自文本、哪部分来自图像」，为来源归因打下基础。一个自然的延伸是把视觉特征通过线性投影映射到文本embedding空间——这样做的好处是生成模型只需要处理它最熟悉的文本表示，视觉信息以「附带向量」的形式参与生成，很多多模态大模型的实现都走了这条路。

4.4 生成阶段怎么衔接：上下文学习、思维链推理与来源归因

检索和融合做得再好，最终都要落到生成质量上。综述梳理的生成技术里，上下文学习把检索到的内容当作少样本示例，让模型参照示例格式组织回答，在多模态场景下还能借用示例的图文结构；思维链推理把复杂问题分解成小步骤，先识别图像里的实体，再结合外部知识做推理，每一步都有明确的依据。多模态RAG比单模态RAG更需要思维链，因为跨模态的证据链天然更长——「识别实体→检索知识→组合推理→生成回答」每一步都可能出错，拆开做能定位错误来源。

来源归因则是另一个被低估的环节。输出结论文档里标注「哪些内容来自检索到的哪篇文档」，一方面增强可追溯性，另一方面也给用户判断可信度提供了依据。对于医疗、法律、金融这类不能把模型当黑匣子用的场景，来源归因几乎是上线的前提。综述里提到的指令调整则是对生成组件做微调，让模型更适应特定应用的任务格式。到这里可以看出，多模态RAG的完整链路是「检索找证据、融合组证据、生成用证据、归因还证据」，四段缺一环，系统的可靠性就会出现明显短板。

5. 多模态RAG训练与评估避坑：损失函数、鲁棒性和指标陷阱

5.1 对齐损失与生成损失：联合训练的战与和

多模态RAG的训练核心是两路损失共同作用：对比学习损失让查询和文档在共享空间里对齐，生成损失保证模型能基于检索上下文输出正确内容。InfoNCE是对比学习最常用的损失形式，一个简洁实现如下：

def info_nce(query_emb, doc_emb, temperature=0.07): # query_emb: [B, D] 查询编码 # doc_emb: [B, D] 文档编码（同一共享空间） query_emb = F.normalize(query_emb, dim=-1) doc_emb = F.normalize(doc_emb, dim=-1) logits = query_emb @ doc_emb.T / temperature labels = torch.arange(query_emb.size(0)) return F.cross_entropy(logits, labels)

这个实现里，矩阵乘法得到的是batch内每个查询与所有文档的相似度，对角线上的位置是正样本对，其他位置全部是负样本。除以temperature控制的是分布的锐利程度：温度越低，logits的差异被放大，负样本的梯度贡献越强；温度越高，分布越平滑，难负样本的惩罚被稀释。训练多模态对齐时，如果batch内负样本质量参差，temperature就需要小心调——设太低，简单负样本主导梯度，模型学不到细粒度区分；设太高，难负样本干扰训练，表示长期不收敛。

生成部分的训练则回归到标准的交叉熵损失，图像生成环节还会用到生成对抗网络或扩散模型对应损失。综述提到的eCLIP损失、Mixup策略等，本质上都是对对比学习目标的修正：eCLIP在CLIP目标之外增加额外约束，Mixup通过样本插值增强多样性。联合训练时，对齐损失和生成损失直接相加会带来一个常见问题——两个损失量纲不同，梯度方向可能冲突。实践中常见做法是先冻结编码器只训生成，再用低秩适配器以很小的学习率联合微调，让检索表示在保持对齐的同时适应生成目标。

5.2 鲁棒性与噪声管理：多模态世界的脏数据才是常态

多模态训练数据的噪声比纯文本严重得多。LAION-400M这类数据是从互联网大规模爬取得到的，图文错配、描述不完整、概念混淆的情况比例不低。如果模型在这种数据上直接训练，会把「随机共现」误学成「语义关联」。综述提到的鲁棒性增强手段里，注入无关结果是一种主动干预——在训练时故意加入图文不匹配的负样本，让模型学会拒绝低相关性输入；知识蒸馏用高置信教师模型的输出引导训练；基于超图的知识聚合则把样本之间的高阶关系组织成超图结构，增强表示的判别性。

模态特定偏差是另一个隐藏风险。多模态数据里文本和图像的「信息量」往往不对等，模型的注意力容易被更易处理的模态吸引，比如拿到图文对后只依赖文本而忽视图像，或者反过来只被图片的显著性区域带偏。检测这种偏差的方法是做模态消融实验——分别屏蔽文本和视觉输入，看模型表现掉多少。如果屏蔽视觉后效果几乎不降，说明模型基本在「盲答」，视觉通道根本没被有效利用。

5.3 评估指标怎么选：从Recall@K到CLIP Score，各有各的盲区

评估多模态RAG需要分层看指标。检索阶段，Recall@K比常规Recall更受青睐，因为它只关注前K个结果里有多少真正相关的文档，K的取值取决于下游生成能容忍多少噪声；MRR则衡量第一个相关结果的排名位置，适合「只要第一答案」的场景。生成阶段，文本指标里BLEU强调n-gram精确率和长度惩罚，ROUGE侧重召回，ROUGE-L基于最长公共子序列计算；METEOR额外考虑同义词匹配、词干匹配和词序块惩罚，通常比BLEU更接近人工判断。

图像描述场景要用专门指标。CIDEr把句子视为文档，用TF-IDF加权n-gram向量计算余弦相似度，能区分常见词和关键信息词；SPICE则把描述解析成场景图，提取对象、属性、关系三类语义命题，通过命题重叠度评估——它比CIDEr更接近语义层面，因为两个句子用词完全不同但描述同一场景时，SPICE依然能识别匹配。语义对齐层面，BERTScore用预训练语言模型为候选词和参考词做贪心匹配，缓解同义替换带来的误判；CLIP Score则直接计算生成图像与文本的CLIP相似度，适合评估图文对齐程度。

基准方面，M2RAG把文本指标和多模态指标联合评估，MRAG-Bench聚焦视觉推理，Dyn-VQA测试动态检索和多跳推理，TriviaQA和Natural Questions测知识密集型检索，Counterfactual VQA测对对抗性输入的鲁棒性，OHRBench专门研究OCR错误对RAG系统的级联影响。这些基准没有一个是全能的，选指标的第一原则是「和你要优化的业务目标对齐」。

下表整理了主要指标与考察维度：

5.4 常见踩坑：四件我见过的翻车小事

现象1：多模态分数融合后，某种模态在最终结果里永远不占优。原因：不同模态检索器的分数分布差异太大，BM25的分数量级远高于CLIP相似度，直接相加实际只用了文本信号。解决：先对每个模态的分数做分布归一化，再用验证集学习融合权重，必要时加一个校准层把分数转换成可比概率。

现象2：CLIP Score看着很高，人工评估却觉得生成结果很别扭。原因：CLIP对空间位置关系、属性绑定这些细粒度语义不敏感，两张图风格相似但布局完全不同，CLIP分数可能一样高。解决：交叉使用SPICE和BERTScore做语义层面核对，重点任务再加人工评估样本，不要单独依赖CLIP Score做上线决策。

现象3：负样本挖太狠，对比学习训练直接震荡。原因：硬负样本难度的分布不均，加上温度系数设得太低，难样本的梯度被过度放大，模型在几个困难样本上反复摆动。解决：采用课程式负样本策略，先让模型区分简单负样本，再逐步引入硬负样本，同时把温度系数从稍高值逐步下调。

现象4：OCR错误对RAG结果产生级联影响，但评测时完全没发现。原因：常规多模态基准的数据大多是干净文本，真实场景里PDF文档的OCR错误率不低，检索器把错误识别出的内容当成正确文本，直接污染下游生成。解决：用OHRBench这类OCR影响基准评估级联误差，在检索链路里加入OCR置信度信号，低置信段的文本结果执行降权。

6. 设计取舍：共享空间还是模态专用空间，以及这个问题的真正解法

把这条链路看完整，会发现所有系统级选择都落在一个根本取舍上：共享嵌入空间带来统一接口，却牺牲了模态内的保真度；模态专用空间保住了检索精度，又让跨模态比较失去了公共基准。综述梳理的多种策略，其实都在这个光谱上找位置。CLIP式共享空间适合「先广撒网再精排」的粗检索阶段，ColPali式token级匹配适合「要精确定位页面元素」的文档场景，BM25这类词项匹配则始终是文本召回的高性价比补充。没有一种空间设置能同时满足所有需求，所以优秀系统的形态往往是「多个空间共存、按环节分工」。

我一般会这么理解：共享空间解决「能不能找到」，模态专用空间解决「找得准不准」，融合机制解决「找到之后怎么综合用」。三个问题对应三种设计，强行用一个空间贯穿全链路，必然在某一个环节吃亏。与其争论哪种空间更优，不如先想清楚当前场景最薄弱的是哪一环。

至于训练层面，联合优化的冲突也很现实：检索器的目标是表示对齐，生成器的目标是文本流畅，两者方向不一致时，只调损失权重只是表面和解。不加约束的联合微调会让模型潮汕性能全面下降，而冻结编码器只做轻量适配往往更稳。真实的做法是用验证集反向选择「微调哪一层、冻结哪一层」，而不是迷信某一种训练配方。

这份综述给到一个很实用的指引：把要用的数据集、指标和基准对照着列出来，先弄清数据集规模与模态构成，再选能覆盖你任务需求的评估方案。多模态RAG的开放性挑战——未见过的模态组合、数据稀缺模态里的检索与生成——也都要在空间和融合机制的设计层面提前留好扩展位。从那以后，我每搭一套多模态检索系统，第一件事就是画一张「空间拓扑图」：哪些模块共享同一个嵌入空间，哪些在各自模态内做粗筛，融合发生在第几层，评估指标覆盖了哪几个维度的错误。流程完整走一遍，翻车率确实降下来不少。希望帮到你。

本文还有配套的精品资源，点击获取