简介一份聚焦多模态检索增强生成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页面当作图像理解支持「找到包含某段文字的页面」这种细粒度需求。把检索器按模态拆分而不是所有模态共用一个检索器是因为共享空间里的跨模态距离并不可靠。一个文本查询和一个图像文档的余弦相似度并不能稳定地反映语义相关性——不同模态的编码器可能在训练数据上对齐得不完美导致某些语义区域里「地图没对上」。模态中心检索相当于先把检索限定在同构数据里用模态内更成熟的相似性度量把问题缩小再在融合阶段处理跨模态关系。实际系统中「通用向量检索 各模态专用召回」并行运行、结果合并是比只用一个共享索引稳妥得多的工程结构。下表整理了常见检索策略与适用场景检索策略代表方法适用场景文本中心BM25、MiniLM专有名词、长文本语义匹配视觉中心EchoSight、ImgRet以图搜图、视觉相似内容视频中心MV-Adapter视频片段、动作理解文档布局ColPali、ColQwen2页面级细粒度信息定位高效检索MIPS、HNSW、IVF十亿级语料库在线检索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_heads8): super().__init__() self.cross_attn nn.MultiheadAttention(hidden_dim, num_heads, batch_firstTrue) 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_maskNone): # text_tokens: [B, T, D] 文本编码器输出 # vision_tokens: [B, V, D] 视觉编码器输出的patch特征 context torch.cat([text_tokens, vision_tokens], dim1) attended, _ self.cross_attn( context, context, context, key_padding_maskvision_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, temperature0.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 评估指标怎么选从RecallK到CLIP Score各有各的盲区评估多模态RAG需要分层看指标。检索阶段RecallK比常规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系统的级联影响。这些基准没有一个是全能的选指标的第一原则是「和你要优化的业务目标对齐」。下表整理了主要指标与考察维度阶段指标核心机制主要盲区检索RecallK前K个结果中相关文档比例不考虑结果排序质量检索MRR第一个相关结果的排名倒数只关注首个相关项文本生成BLEUn-gram精确率长度惩罚同义替换、语义等价文本生成METEOR同义词、词干、块惩罚依赖词汇资源图像描述CIDErTF-IDF加权n-gram余弦忽略语义结构图像描述SPICE场景图语义命题匹配场景图解析误差语义对齐BERTScore词向量贪心匹配上下文长度受限图文对齐CLIP ScoreCLIP模型图文相似度空间布局、属性绑定不敏感5.4 常见踩坑四件我见过的翻车小事现象1多模态分数融合后某种模态在最终结果里永远不占优。原因不同模态检索器的分数分布差异太大BM25的分数量级远高于CLIP相似度直接相加实际只用了文本信号。解决先对每个模态的分数做分布归一化再用验证集学习融合权重必要时加一个校准层把分数转换成可比概率。现象2CLIP Score看着很高人工评估却觉得生成结果很别扭。原因CLIP对空间位置关系、属性绑定这些细粒度语义不敏感两张图风格相似但布局完全不同CLIP分数可能一样高。解决交叉使用SPICE和BERTScore做语义层面核对重点任务再加人工评估样本不要单独依赖CLIP Score做上线决策。现象3负样本挖太狠对比学习训练直接震荡。原因硬负样本难度的分布不均加上温度系数设得太低难样本的梯度被过度放大模型在几个困难样本上反复摆动。解决采用课程式负样本策略先让模型区分简单负样本再逐步引入硬负样本同时把温度系数从稍高值逐步下调。现象4OCR错误对RAG结果产生级联影响但评测时完全没发现。原因常规多模态基准的数据大多是干净文本真实场景里PDF文档的OCR错误率不低检索器把错误识别出的内容当成正确文本直接污染下游生成。解决用OHRBench这类OCR影响基准评估级联误差在检索链路里加入OCR置信度信号低置信段的文本结果执行降权。6. 设计取舍共享空间还是模态专用空间以及这个问题的真正解法把这条链路看完整会发现所有系统级选择都落在一个根本取舍上共享嵌入空间带来统一接口却牺牲了模态内的保真度模态专用空间保住了检索精度又让跨模态比较失去了公共基准。综述梳理的多种策略其实都在这个光谱上找位置。CLIP式共享空间适合「先广撒网再精排」的粗检索阶段ColPali式token级匹配适合「要精确定位页面元素」的文档场景BM25这类词项匹配则始终是文本召回的高性价比补充。没有一种空间设置能同时满足所有需求所以优秀系统的形态往往是「多个空间共存、按环节分工」。我一般会这么理解共享空间解决「能不能找到」模态专用空间解决「找得准不准」融合机制解决「找到之后怎么综合用」。三个问题对应三种设计强行用一个空间贯穿全链路必然在某一个环节吃亏。与其争论哪种空间更优不如先想清楚当前场景最薄弱的是哪一环。至于训练层面联合优化的冲突也很现实检索器的目标是表示对齐生成器的目标是文本流畅两者方向不一致时只调损失权重只是表面和解。不加约束的联合微调会让模型潮汕性能全面下降而冻结编码器只做轻量适配往往更稳。真实的做法是用验证集反向选择「微调哪一层、冻结哪一层」而不是迷信某一种训练配方。这份综述给到一个很实用的指引把要用的数据集、指标和基准对照着列出来先弄清数据集规模与模态构成再选能覆盖你任务需求的评估方案。多模态RAG的开放性挑战——未见过的模态组合、数据稀缺模态里的检索与生成——也都要在空间和融合机制的设计层面提前留好扩展位。从那以后我每搭一套多模态检索系统第一件事就是画一张「空间拓扑图」哪些模块共享同一个嵌入空间哪些在各自模态内做粗筛融合发生在第几层评估指标覆盖了哪几个维度的错误。流程完整走一遍翻车率确实降下来不少。希望帮到你。本文还有配套的精品资源点击获取
