做多模态融合这几年我最大的感受就一句话论文越来越难追了。不是论文难读而是量大、题杂。尤其ICLR2024多模态相关的文章散落在十几个不同主题里有讲对齐的、讲生成的、讲模态缺失鲁棒性的还有一波直接把文本、图像、音频、视频全部token化之后丢进同一个Transformer里的。只按标题扫一遍等于没看想全看时间又不够。这篇文章记录的是我整理的一套筛选思路以及最终留下的22篇文章对应的源码获取路径。我把这22篇按“解决什么问题”分成了五类每一类怎么找、怎么复现、有哪些能迁移到自己任务里的技巧都会写到。适合正在入门多模态融合的读者也适合已经做了几年、想快速拓宽视野的研究者和工程师。1. 为什么说ICLR2024是看多模态融合最好的窗口1.1 多模态融合这些年到底在解决什么问题多模态融合听上去很高大上实际落到工程上就是一句话让模型从不止一种数据来源里拿信息再综合判断。文本、图像、音频、视频、传感器数据每一路都是模态。问题在于文本是离散符号图像是连续像素音频又是一维时序信号它们的特征空间完全不一样。直接拼在一起模型根本不知道该信谁、怎么平衡、什么时候该忽略哪一路。早期做法很粗暴最后一层特征concat起来过个全连接但这属于“物理拼接”没有真正建模模态之间的交互关系。到了现在多模态融合的难点早就不是“能不能拼”而是“怎么根据输入数据动态决定融合策略”“某个模态丢了或者有噪声还能不能用”“怎么用少得多的参数实现融合”。ICLR2024恰好把这几个问题都集中暴露出来了。多模态大模型的兴起让融合变成了基础能力不再只是某个子任务里的trick。很多工作开始从“架构设计”转向“训练策略和数据组织”。这才是真正有意思的地方同样的模型结构换一种对齐方式效果差一大截。换句话说融合这件事已经从“怎么搭网络”进化到“怎么设计学习信号”了。1.2 ICLR2024上多模态研究的三个明显趋势我把今年接收列表里的多模态相关文章粗扫了一遍明显感觉到三个趋势。第一个趋势是“任何模态都可以token化”。文本token化大家都熟图像patch化也成熟了今年大量工作在把音频、视频、甚至3D点云都切成离散token然后用统一序列模型处理。融合就从“设计跨模态模块”变成了“让模型在序列内部做交互”。好处是架构极简坏处是训练数据量和算力门槛直线上升。第二个趋势是“融合策略从静态走向动态”。以前融合策略是固定的图像特征和文本特征各占多少权重网络自己学但学完就固定。今年很多文章在做“根据输入内容动态决定融合路径”比如某个样本的图像信息量很低模型会倾向于少看图像、多看文本再比如遇到模态缺失模型能自动切到剩余模态上继续推理。这一点在真实场景里太重要了因为实际业务里丢模态是常态不是例外。第三个趋势是“评估维度变宽了”。以前的论文只要在某一两个benchmark上刷高准确率就行今年不少工作开始测OOD分布外泛化、模态缺失下的性能、融合的可解释性。这说明大伙儿已经意识到实验室数据集和真实环境差得太远融合模型要是换了个场景就崩那刷分意义不大。2. 我的筛选思路22篇清单是怎么来的2.1 筛论文不能看标题要看“解决什么问题”很多同学整理论文清单的习惯是从标题或者摘要里看到“multimodal fusion”就收进去但这样收下来的文章经常是一堆不相关的东西。有的论文题目里有“fusion”实际解决的是视觉问答的注意力机制有的文章标题没提“multimodal”做的却是跨模态蒸馏。我这次筛论文有一个固定动作拿到一篇文章先问三个问题。第一它定义的问题是什么是模态对齐、模态交互、模态缺失还是模态生成。第二它提出的方法能不能迁移到我的场景里。第三个问题最实际代码到底开不开源复现成本高不高。判断一篇论文值不值得进入清单我会把它放到“问题类别”里而不是“方法名”里。同样是Transformer架构一个在做鲁棒融合一个在做高效微调它们解决的问题完全不同。混在一起整理最后自己都看不明白。2.2 我设定的一票否决项代码不开源直接排除说句得罪人的话ICLR2024里有相当一部分论文是没有源码的。对研究者来说论文主要贡献是提出新idea不附源码可以理解。但对工程师和需要用这些方法落地的人来说没有源码就约等于零。这篇博文的标题说“附源码”我筛选时就设置了硬性指标必须在论文页面、作者主页或者GitHub上找到官方实现至少得有PyTorch代码。只有伪代码的不要只有流程图但数据库链接失效的不要代码仓库三天没更新的也会犹豫。这个标准会损失一些好工作但换来的是一张“能直接开车”的清单。你拿到手就能复现、能改、能跑自己的数据。这也是为什么最终只留下22篇——不是因为ICLR2024里好文章不够多而是符合“问题清晰、方法可迁移、代码可运行”三个条件的就是这么多。2.3 最终留下的22篇清单分布在往下拆之前先给一个总览表格。我把22篇分成了五类每一类解决一类问题也对应一类源码获取思路。类别篇数核心关注点适合谁动态融合与路由5根据输入动态决定融合哪些模态、用哪种融合权重做多模态推理、边缘端部署的同学统一模态建模6把文本、图像、音频、视频统一成相同格式处理想做多模态基础模型、多模态大模型对齐与表征学习4跨模态表征怎么拉近、怎么解耦做图文检索、跨模态迁移学习鲁棒性与缺失模态4模态缺失、噪声干扰下依然能正常工作做真实业务场景落地的工程团队高效融合与微调3用极少的参数量和算力实现融合实验室或公司算力受限的同学下面我会按类别展开讲清楚每一类里的典型方法思路、为什么值得看以及复现时要盯住哪些细节。3. 从这22篇里提炼出的融合新方法3.1 动态融合与路由不搞“一刀切”的融合策略做过多模态模型的都知道传统融合最大的问题就是“一刀切”。不管是文本开头还是图像开头模型都用同一套交叉注意力用同一组权重去融合。但实际上有些样本里图像信息丰富文本只是辅助反过来有些样本里文本已经能回答问题了图像反而是噪声。固定融合策略天然处理不了这种差异。今年这类文章的核心思路就一个字变。给模型加一个路由模块让它根据输入样本的特征来决定走哪条融合路径。具体方法上常见的有两种一种做法是对每个模态token计算一个信息量打分分数低的路直接砍掉减少计算量另一种做法是给模态交互模块设计多个“前馈专家”路由网络为每个token挑选最合适的专家来处理跨模态信息。这两种思路各有取舍从零训练路由网络会引入额外开销但换来的好处是模型在面对分布变化时更灵活。复现时要注意动态路由对batch内数据的分布特别敏感。如果batch里多数样本都是图像主导的路由网络很容易被带偏觉得文本不重要最后把文本模态完全忽略掉。建议前期把路由模块的学习率设得比主网络低一些或者给路由输出加一点温度参数让它在训练初期不那么“自信”。3.2 统一模态建模所有模态都变成token这一类是今年视觉比较猛的方向。思路非常直接把图像切成patch token把文本切成词token把音频切成帧token最后全部放进同一个序列模型里做自回归或者对比学习。融合的复杂度从“设计跨模态模块”变成了“设计好序列位置编码”和“训练数据配比”。这样做的好处是架构上极度统一不需要为每种模态单独设计融合模块。但你需要踩的坑也很明确。首先不同模态的token粒度不一样一个图像patch包含的信息量远大于一个词直接拼在一个序列里模型会天然偏向信息密度低的模态通常是文本训练时容易坍缩。其次不同模态的数据量不一样图文对数据好找音频文本对就少得多视频语言对更稀缺。如果训练时不做平衡采样模型最后学出来的“多模态”其实只是文本模型的附属品。实操建议是如果你打算在这个方向投入先别急着从零训练一个统一模型更实际的是用开源的统一模态预训练模型做基座在自己数据上做增量训练。今年开源出来的几个基座模型底座都足够扎实二次开发的性价比远高于自己造轮子。3.3 对齐与表征学习从“拉近距离”到“解耦”对比学习CLIP模式是跨模态对齐的主流范式核心就是把图文对映射到同一个向量空间正例拉近、负例推远。今年这个方向的新意主要集中在两点一是改进了负样本的组织方式不只用batch内样本做负样本而是引入难负样本挖掘和跨模态负样本融合让模型学会更精细的语义差异。二是开始强调“解耦”不满足于把所有信息揉进一个向量里而是把共同特征和模态特有特征分开建模。对我这种偏实用的人来说解耦比一味拉近更有价值。原因在于检索、去重、推荐这些任务里很多时候你想找的是“同一件事”的不同模态表达但又不希望因模态特有的细节比如图像的色彩风格、文本的措辞方式而干扰距离计算。把共同空间和特有空间分开之后你在共同空间里做检索鲁棒性会明显更好。复现这类工作时要特别关注温度系数和负样本数量。温度系数设小了模型会过于关注难负样本训练不稳设大了正负样本区分度又不够。我自己的经验是先冻结预训练好的backbone只训练对齐层和温度系数等loss曲线平稳了再解冻backbone做微调能省掉不少前期调参的痛苦。3.4 鲁棒性与缺失模态真实业务最需要的一类工作如果说前三类方法是在“锦上添花”那鲁棒性和缺失模态就是“雪中送炭”。真实业务里摄像头可能坏掉、语音可能被噪声盖住、用户上传的内容可能只包含文本没有图片。很多模型训练时没见过这种情况一到线上就被打得措手不及。这次清单里的相关工作核心策略可以分成三类。第一类是训练时随机 masking模拟模态缺失让模型学会“部分模态也能推断”。第二类是模态置信度建模给每路模态的输出估计一个不确定性分数融合时按置信度动态加权。第三类是用prompt机制环境变化时通过轻量指令来引导模型关注可用模态类似于多模态版的in-context learning。复现时第一类方法最省事且最值得自己动手试。你不需要换模型结构只需要在数据加载器里加一步以一定概率把某一路模态token替换成可学习的mask token。我实测下来随机mask比例设置在15%到25%之间效果比较微妙太高模型会过度依赖mask机制太低又起不到模拟缺失的作用。3.5 高效融合与微调小算力的生存之道最后一类对算力不充裕的团队非常重要。多模态大模型动不动就几十亿参数全量微调根本不现实。今年这个方向的工作主要探索的是能不能在冻结大部分参数的情况下只对融合模块做轻量调整目前看下来常用方案有低秩适配LoRA的跨模态版本、轻量融合适配器、以及用蒸馏的方式把大模型的融合能力迁移到小模型上。其中低秩适配在融合任务里的应用方式很巧妙不是简单在attention层加一个低秩旁路而是让旁路的输入同时接收不同模态的特征迫使低秩矩阵学到跨模态交互信息。这样做的好处是训练参数极少一般只有总参数的1%到3%但能起到接近全量微调的效果。我自己的经验是在应用到新业务场景时优先尝试这个方向。因为它对硬件要求最低单卡就能跑迭代速度也快。4. 源码获取与复现路径4.1 找源码的正确姿势很多读者拿到论文后第一反应是上GitHub搜论文标题但这样经常搜到第三方复现质量参差不齐。我更推荐按以下顺序找代码。第一打开论文在OpenReview的页面很多作者会在rebuttal里附上代码仓库地址或者在其他作者的提问下回复“Code will be released at ...”。第二去作者个人主页看很多知名研究组习惯在主页的Publications栏目里列出项目与代码地址。第三再看GitHub。GitHub上搜索也有技巧。如果你知道论文关键词搜“关键词 benchmark名称”比直接搜论文标题更有效。比如一篇论文在MSR-VTT上做视频文本检索技术关键词又是fusion那搜“msr-vtt fusion”往往会比搜论文标题更快命中官方仓库。拿到仓库之后不要急着clone下来就开跑。先看三样东西README里的环境依赖版本、requirements.txt或environment.yml、以及examples或scripts目录下有没有现成的训练脚本。这三个地方能快速判断这个仓库是“能跑”还是“仅供展示”。4.2 从克隆仓库到跑通训练我的固定动作我把复现一个多模态融合项目的基本流程拆成五个步骤这套流程帮我在不同仓库里避过不少坑。第一步单独建conda环境Python版本尽量用项目README指定的多模态项目经常用到不同版本的torch和cuda混用必出事。第二步先跑通项目自带的demo或者预测脚本哪怕是用预训练权重在样例数据上推理也要先确认模型能前向跑通再碰训练。第三步检查数据集的目录结构。多模态项目的数据加载器往往对文件组织方式很敏感原始数据下载下来必须严格按照代码里的data格式整理一个子目录名字不对都可能静默出错。第四步先不要修改模型结构用论文默认的超参数跑一次小规模实验确认loss在下降、评测指标能复现出接近论文结果的水平。第五步再开始做你自己的修改并且每次只改一个变量。这套流程听起来笨但能避免很多“以为自己改对了其实从第一步就错了”的尴尬局面。4.3 多模态训练的几个特殊注意点多模态训练和单模态训练相比有几个地方必须格外小心。第一模态采样策略。如果你的数据里图文对很多、音频文本对很少训练时没做balance模型会退化。我自己习惯的做法是在每个epoch里对稀缺模态做重复采样而不是简单调低频率能让模型看到足够多的跨模态组合。第二loss权重的设置。很多融合模型的总loss是分类loss、对比loss、生成loss的加权和这个权重最忌讳拍脑袋调。建议先从让每个loss的量级大致一致开始再根据验证集指标微调。第三batch size的影响。对比学习极度依赖batch size正负样本都在一个batch里batch太小负样本不足效果会肉眼可见地掉。如果你显存有限别硬撑大batch用梯度累积也能起到类似效果。5. 我踩过的坑和排查技巧5.1 几个高频问题速查现象可能原因我的解决办法训练loss是nan学习率过大或者多模态中间层数值溢出降低学习率同时检查是否有模态缺少归一化层只用了文本模态图像不起作用图像编码器没解冻或图像分支loss被文本分支淹没检查backbone梯度是否更新先单独冻结/解冻观察loss跨模态检索指标上不去负样本太简单模型没有挑战引入hard negative mining或者加大batch显存不够多模态输入序列过长缩短序列长度或者用gradient checkpointing某个模态的token在训练中逐渐消失位置编码和模态编码冲突检查不同模态token是否使用独立的位置embedding5.2 新手建议从一条最简单的跨模态任务开始如果你刚开始接触多模态融合最忌讳直接挑一个统一模态大模型开始复现。模型太大、数据太多、问题太复杂出任何bug都很难定位。更建议的做法是选一个图文检索或者图文分类任务比如经典的图文配对数据集用CLIP风格或简单的交叉注意力架构做一版把数据加载、模态编码、融合、评估这一整条链路跑通。链路通了之后再逐步加入更复杂的动态融合、模态缺失mask、参数高效微调这些高级玩法。5.3 进阶方向把这些方法挪到你的业务里对于有经验的研究者和工程师我的建议是不要只读清单里的文章而是把你自己的任务拿出来对照五类方法问一遍我的场景里有没有“模态动态选择”的需求有没有“某个模态偶尔缺失”的情况能不能把当前模型里最重的融合模块换成轻量适配器这种对照比多读二十篇论文管用得多。你自己业务里的特殊约束往往是比任何benchmark分数都重要的信噪比来源。整理这份22篇清单的过程比我读这22篇文章本身收获更大。因为你被迫给每一篇工作贴上“它在解决什么问题”的标签贴完之后整个领域的版图就清晰了。现在我在arXiv上看到任何新投稿都先问自己三个问题它属于哪一类问题它的方法能不能迁移到我的场景代码有没有放出来如果三个问题都有答案再决定要不要精读。这个方法比任何清单都管用也建议你们试试。
