多模态融合最新创新方法汇总ICLR2024这22篇我是怎么筛选、研读和复现的多模态融合这几年几乎是论文界的顶流尤其是ICLR2024放榜之后图像、文本、音频、视频、点云这些模态之间的交互方式越来越激进。对比两三年前那种“把CLIP特征和BERT特征拼一起塞进MLP”的做法2024年的文章明显更注重融合的动态性、鲁棒性以及和生成模型的协同很多好的工作都开源了源码这对我们这种想快速跟进的从业者来说太关键了。这篇内容我打算换个角度来聊。不简单罗列论文标题而是把我在阅读和复现这一批多模态融合论文时的整体思路、重点方向、源码研读路线以及实际遇到的坑都整理出来。文章针对的是有一定深度学习基础、但对多模态融合这个方向还比较陌生的朋友。如果你打算把多模态融合作为研究方向或者想找几个ICLR2024的开源项目练手跑通整套流程这篇内容应该能帮你省下不少时间。在开始之前先交代一个背景。我筛选ICLR2024文章时并不是把所有带“multi-modal”关键词的都抓过来而是会先做一个“方向过滤”。因为同一词条下可能既有纯理论推导也有偏系统设计的还有偏评测基准的。对于大部分研究和工程应用来说真正值得精读和复现的其实集中在三类一类是模态对齐和表示学习一类是统一生成框架一类是鲁棒性和模态缺失处理。下面我就按这套逻辑来展开。1. 多模态融合的技术演进为什么2024年的方法和以前不一样1.1 从“融合特征”到“融合语义”先说一个最容易被新手误解的点。很多人一看到“多模态融合”第一反应就是“把两种特征向量拼起来”这种思路在2019年左右确实有不少文章在做但现在基本走不通了。原因是简单的特征拼接完全没有考虑模态之间的语义对齐问题。我用一个生活化的例子来说明。你在公司开会同时看PPT上的文字和听同事的讲解这两个信息源描述的是同一件事但它们的“粒度”和“结构”完全不同。PPT上的文字是压缩过的、跳跃的要点语音是连续的、带语气的表述。如果你只是把PPT文字的特征向量和语音的特征向量拼在一起模型根本不知道该对应哪一部分结果就是融合了个寂寞。ICLR2024这批文章之所以值得关注是因为它们开始从“怎么把特征拼起来”转向“怎么让不同模态的语义在统一的表示空间里对齐”。比如有些工作会用对比学习的方式拉近图像区域和文本片段之间的距离有些工作会用交叉注意力机制在Transformer层内部做动态对齐还有些工作直接借用大语言模型的思维链能力去“描述”图像内容然后做文本推理。这些策略的共同点都是从“数据驱动”的角度来解决对齐问题而不是靠人工设计规则。另外真正的语义融合通常还需要处理“孔位对齐”的问题。图像里某个局部区域可能对应文本里的“左上角那块红色区域”但如果文本里根本没有这个描述这个区域就变成了“未对齐信息”。如何处理这部分噪声也是ICLR2024多篇文章关注的重点。1.2 主流技术范式的变迁把时间线拉长来看多模态融合大概经历了四个阶段。第一个阶段是“前端拼接”也就是把各个模态的特征在输入层直接concat这个方法简单但效果有限因为模态间的异构性太大。第二个阶段是“后端融合”每个模态先各自处理最后在决策层加权投票或做逻辑回归代表性方法有早期的集成学习思路。第三个阶段是“特征级融合”引入注意力机制和跨模态Transformer让模型自己决定在哪一层、哪个token之间建立联系这类工作从2021年开始慢慢成为主流。第四个阶段也就是ICLR2024这批文章所处的时期开始强调“统一表示”和“双向生成”。“统一表示”你可以理解成让所有模态都映射到同一种离散token序列上就像把所有语言都翻译成同一种世界语然后扔进同一个Transformer。这样做的优势很明显模型只需要处理一种序列类型结构设计可以全部复用。不过代价也很明显离散化会丢失细节信息尤其是图像和音频这种高分辨率信号量化粒度粗了之后信息损失非常严重。“双向生成”则是另一个大方向。以前的融合模型往往是单向的比如“图像-文本”就只做图像到文本的caption或者只做文本到图像的生成。但2024年的很多文章开始做“任意模态到任意模态”的转换——输入图像输出音频输入文本加音频输出视频甚至输入一部分缺失模态也能补全另一部分。这种框架和扩散模型结合得特别紧密我后面会详细讲。1.3 选型指标我判断一篇论文值不值得复现的三个维度论文数量年年涨如果每一篇都精读再复现时间肯定不够。我的筛选逻辑是三个维度的加权效果提升幅度、可复现性、训练成本。效果提升幅度最好判断。如果文章在同规模参数下比之前SOTA提升超过两个点并且提升主要来自方法本身而不是靠堆数据和算力那值得细看。如果一个模型提升很大但训练数据增加了5倍那参考价值就要打折因为你很难在自己环境里复制这个条件。可复现性取决于文章结构是否清晰、有没有提供官方源码、依赖的库版本是否合理。我遇到很多文章声称开源结果点进GitHub只有README没有代码或者代码依赖了内部工具库根本跑不起来。这类文章即使创新点再亮眼如果作者不愿意把边缘情况处理好工程上直接采用的压力会非常大。训练成本也很关键。一批ICLR2024的文章动不动就上几十块A100这对个人研究者或者小团队基本不具备复现条件。当然不是说不能看而是看的时候要分清“理想实验”和“可落地方法”。我最喜欢的是那些在小规模数据集上也能跑出趋势性结果的文章这类工作往往能说明方法本身的有效性而不只是算力堆积。2. ICLR2024 多模态融合方向重点文章拆解2.1 跨模态对齐与表示学习这届ICLR在“对齐”这件事上较真了跨模态对齐一直是我自己最关注的方向因为几乎所有下游任务都离不开它。ICLR2024的这个方向整体给我的感觉是“比例感更好了”。不再执着于一个大的对比损失拉近所有正样本对而是更多策略性地做局部对齐、多层次对齐和自监督对齐。有一篇我印象很深的文章把对比学习中的负样本挖掘方式做了重构。传统的CLIP式训练对负样本的处理是“批次内随机采样”也就是把当前batch里的其他样本当作负样本。但这种做法的问题是如果负样本太难比如图像里本来就有相似的物体模型会学到很多错误的排除逻辑如果负样本太简单模型又容易“走捷径”。那篇文章提出的方案是在特征空间中维护一个动态更新的“原型库”每个类别对应一个可学习的原型向量负样本的采样范围从“当前批次”扩展到了“整个历史特征空间”同时用在线聚类的方式实时更新原型。这样做的好处是负样本的质量更稳定模型不至于被某几个异常batch带偏。源码我专门去读过结构比我想象中清爽全部代码加配置文件不到两千行很适合作为对比学习方向入门阅读。还有一篇做“细粒度异步对齐”的。传统方法往往假设两个模态的所有token在时间上或空间上是一一对应的比如视频里第10帧对应文本里第3个词但这种假设并不总是成立。那篇文章的核心思路是放弃“全对齐”的强假设改用一种soft对齐的方式让模型自己学习每个图像区域和文本token之间的匹配概率同时允许部分token“悬空”。这个思路虽然在结构上没有太大革新但它澄清了一个重要问题——真实的跨模态数据往往是弱对齐、有噪声的强行对齐反而会伤害泛化能力。在这个方向里我要特别提醒的一点是跨模态对齐的文章通常评测指标特别敏感。比如同样的模型在COCO上提升1个点可能换个数据集就成了负优化。所以看这类文章不能只看他们报告的数字要看他们做了多少组消融、在几个数据集上有正向结果、基线设置得是否公平。如果一篇文章只在单一数据集上有效我一般不太敢往自己的框架里搬。2.2 多模态统一生成框架用扩散模型重构融合方式如果说对齐是“理解”那生成就是“表达”。ICLR2024在生成方向上的文章明显比前两年多而且大部分都和扩散模型有关。扩散模型天然适合做多模态融合的一个原因是它有很强的条件控制能力。你可以在推理的时候把文本、图像、音频都作为条件输入到同一个去噪网络里在反向扩散的每一步逐步融合这些条件。有一篇比较激进的文章提出了“任意到任意”的生成框架输入可以是图像、文本、音频、甚至姿态序列的任意组合输出也是任意模态的组合。这套系统不是靠一个单独的融合模块而是把所有模态都离散化到同一个token词汇表然后用一个统一的Transformer做自回归生成。这个想法很漂亮但实际训练时对数据配比和数据量要求极高。作者在论文里也承认某些模态组合的生成效果之所以偏弱是因为他们收集的配对数据不够而不是模型结构不行。也有把扩散模型和语义对齐结合起来的工作。比如在扩散过程中引入一个跨模态注意力层让每个图像patch在去噪时能“看到”相关的文本片段。很多做“文本-图像”生成的人可能觉得这不就是Stable Diffusion的ControlNet思路吗。但区别在于ControlNet是冻结基座模型只在旁边加一个可训练分支这篇文章是把跨模态注意力直接融进UNet的主干层训练时全量微调。效果确实更好但训练成本也水涨船高我在时效性有限的情况下会用梯度检查点来缓解显存压力。对于这个方向我的体会是源码复现的难度往往不在模型本身而在预处理管线。图像要裁剪、文本要token化、音频要抽log-mel谱这些预处理代码如果不统一读起来会异常痛苦。我后来学乖了拿到这种项目先不看模型定义把手写的数据预处理脚本和dataloader先过一遍搞清楚每个样本从原始文件到进入模型的完整格式再回头读forward函数会轻松很多。2.3 模态缺失、噪声与鲁棒性真实场景里最容易踩的坑ICLR2024还有一个方向很值得从业者关注就是鲁棒性问题。现实中绝大多数多模态数据都不是“完整无缺”的。摄像头可能被遮挡麦克风可能损坏某段文本可能被截断。如果模型只在完整数据上训练部署时遇到缺失模态效果会断崖式下降。有一篇文章的方法是“随机模态丢弃”的改进版。以前大家在做模态丢弃时就是随机让某个模态的输入置零或mask掉然后强迫模型从剩下的模态中去预测。这篇文章发现这种方式虽然简单有效但会让模型学到一个“偷懒”的策略既然模态会随机消失我就干脆只依赖最可靠的那个模态其他模态爱来不来反正你不来我也不会吃亏。这样一来多模态融合就退化成了单模态模型融合带来的收益完全没体现出来。那篇文章提出的解法是“模态可信度条件推理”——在训练时根据当前模态的噪声程度动态调整融合权重而不是让模型自己去学一个隐式的置信度。推理时如果某个模态被遮挡模型能明确知道“这个模态不可靠应该降低它的权重”不容易被残缺特征带偏。我看完觉得这个思路在工业场景有很强的应用价值因为你不可能保证线上输入永远像测试集一样干净。另一个方向是模态补全。文章思路是借助生成模型来“补全”缺失的模态。比如有图像有文本但缺音频那就用图像和文本生成一段伪音频特征再拿它去做下游任务。这个思路理论上很合理但有一个问题生成的特征是带噪声的如果生成模型本身质量一般补全引入的噪声可能比缺失模态本身的损失还大。所以这类方法的效果非常依赖底层的生成模型质量复现时要特别留意。2.4 22篇划重点清单我的筛选记录下面这个表格是我在筛选ICLR2024论文时的记忆锚点不是完整列表但基本覆盖了值得关注的方向。具体标题你可以按“方向ICLR2024关键词”在OpenReview里搜到。方向论文关注点我的记忆锚点源码情况跨模态对比学习负样本挖掘策略、原型库更新动态原型 在线聚类源码结构清爽GitHub已开源依赖较少细粒度对齐图像区域与文本token的软匹配允许部分token悬空不强制全对齐官方代码已放出适合练手统一生成任意模态到任意模态的自回归生成全模态离散化 统一token词表训练成本高需多卡环境扩散条件融合跨模态注意力融入UNet主干全量微调效果上限高源码完整显存压力大鲁棒模态融合动态模态置信度机制防止模型退化成单模态工业部署参考价值高模态补全用生成模型恢复缺失模态依赖底层生成模型质量复现门槛较高模态Token化图像连续特征转为离散token与LLM直接对接推理灵活有几篇近期开源可参考多模态评测模拟真实场景的鲁棒评测集传统指标会掩盖鲁棒性问题数据集已放出跨模态检索图文/音视频匹配的统一框架检索粒度从全局到局部源码较完整高效微调用LoRA方式做多模态适配冻结底座低资源也能微调很推荐先跑这个表格里这些方向不是孤立的真实项目会同时涉及多个。我在复现的时候通常会先把一个方向跑通再考虑叠加其他模块。别试图一次性把所有论文的方法全塞进一个模型那只会让调试变成地狱。3. 源码研读路线拿到开源项目后我按什么顺序看代码3.1 第一步看目录结构和README很多人拿到一个GitHub项目第一件事就是pip install -r requirements.txt然后开始训练我不建议这么做。一个多模态项目能不能复现很多时候在训练之前就已经注定了。我会先看README里的“快速开始”和“复现结果”部分。如果README里没有给复现的指标范围比如“改哪个参数能接近论文效果”那多半意味着作者自己也没有稳定复现的条件这类项目我通常降低优先级。然后看目录结构。一个规范的多模态项目目录里至少要包含configs、data、model、trainer、utils这几个模块。如果所有代码都堆在几个几千行的超大文件里虽然也能跑但阅读和维护成本会高很多想在此基础上做改进会很痛苦。再看依赖。requirements.txt或environment.yml里的包版本如果和当前环境差异过大可能会触发一堆兼容性问题。我习惯先创建一个干净的conda环境严格按照依赖文件安装而不是在现有环境里硬塞新版包踩过的坑会少很多。3.2 第二步从dataloader开始而不是从model开始很多朋友拿到代码先去看模型的forward函数看半天也没看出所以然。我的经验反过来先从dataloader入手。因为多模态项目里数据是怎么被加载、预处理、组织成batch的决定了模型输入的真实格式。图像可能被resize到什么尺寸文本被tokenize成多长音频采样率是多少这些信息全部藏在dataset类里。弄清楚了每个batch里每个字段的形状再去看模型里那些张量操作思路就自然打通了。有一个典型例子某项目在README里说喂进去的是“视频-文本对”但实际dataloader是把视频的每一帧单独抽出来后和文本做对齐batch维度对应的是帧而不是视频。如果你没看dataloader直接去看模型可能会误以为模型一次处理一整段视频实际上模型处理的是单帧加文本的静态图文对。这两个理解之间的误差非常大会影响你后续所有调优判断。3.3 第三步看损失函数怎么算模型结构只是骨架损失函数才是灵魂。多模态融合领域尤其如此因为大部分创新点落在“如何拉近模态间距离”或“如何分配模态权重”上而不在某个卷积核或注意力头里。我会在代码里搜索loss相关的定义先分辨一下训练用的是哪几种损失组合有没有对比损失有没有重建损失有没有额外的正则项各项损失的权重是多少Loss的权重往往是最容易被忽略却又最关键的超参数因为它直接决定了模型优化的重心。对比损失里温度系数是特别值得一看的参数。我见过很多复现效果不好的案例其实都是温度系数设置不合理导致的。负责的人会把温度系数设置成可学习参数随着训练动态调整而有些项目的温度系数直接写死成0.07如果不开学习率调整就会导致训练不稳。3.4 第四步确定评测指标和评测脚本评测脚本是最后一块拼图。有些项目训练代码和评测代码分离训练完模型后需要单独跑一个evaluate.py生成结果。我会在训练前先把评测脚本跑通拿随机权重试一遍确认输出格式和指标计算方式没问题再训练。这个习惯帮我避免过一次大坑。之前有个项目训练跑了三天评测时发现评测脚本里的数据预处理和训练时不一致导致指标根本不准确。如果早一点先评测一遍就不会浪费那么长时间。4. 实操复现步骤与关键参数调整记录4.1 环境搭建Mamba、CUDA和PyTorch版本统一关于环境我推荐用Mamba而不是裸用conda装包速度快很多。多模态项目里经常要装torchvision、torchaudio、transformers、decord这类包依赖又多又杂包管理器的速度直接影响心情。CUDA方面尽量用和服务器驱动匹配的版本。当服务器驱动不支持PyTorch默认版本要求的CUDA时直接装对应CUDA版本的PyTorch wheel包即可。我不建议在conda环境里单独配一个cuDNN很容易把系统里的软链接搞乱。我一般会先跑一段简单代码确认GPU可用和自动混合精度支持配置好环境再开始拉项目。4.2 配置文件的修改数据路径、batch size和梯度累计多模态项目的配置文件通常用YAML或JSON里面最重要的是数据路径和batch size。数据路径一定要改成你自己的绝对路径这是复现过程中最容易出现低级错误的地方。Batch size的调整需要结合显存来定。假设你手头是一张24G显存的显卡原始代码是在8张80G的A100上训练的那batch size必须大幅缩小。很多人看到batch_size64就直接照抄结果一跑就OOM。我的做法是先把batch size降到4跑一个step确认显存占用然后再逐次往上调。如果batch size调小后模型效果明显变差可以开启梯度累计把“多次小步”累加成“一次大步”。逻辑上等价于增大batch size但要注意BatchNorm层的统计量仍会受影响因此batch size也不能无脑缩小尽量维持在4以上效果比较稳。4.3 训练超参数的调整顺序先学习率再损失权重训练过程中超参数调整是有优先级顺序的。我踩过很多次坑之后总结出一套固定的顺序先调学习率再调损失权重最后才考虑模型结构改动。学习率方面多模态模型因为存在多个子模块比如图像编码器、文本编码器、融合层对学习率的敏感度不一样。比较常见的做法是给底层的预训练编码器一个较小的学习率比如1e-5给上层的融合模块一个较大的学习率比如1e-4也就是分层学习率策略。如果项目代码里没有实现分层学习率我建议自己手动加这个改动对稳定训练帮助很大。损失权重方面我的建议是每次只改动一个权重观察两三个epoch再动下一个。因为多模态训练的指标波动本来就大如果你同时改了三个权重出现效果下降根本说不清是哪个改动导致的。4.4 半精度训练和梯度检查点的开启多模态模型显存开销大是常态。我每次拿到新项目第一件事就是确认能不能开自动混合精度。大部分情况下一开就能省接近一半显存而且对最终指标的影响通常在可接受范围内。梯度检查点是另一个有效工具。它的原理是在前向传播时把中间激活值丢掉反向传播时再重新计算一遍。这让显存占用大幅降低但代价是训练速度变慢因为相当于多算了一遍前向。如果显存只差一点点就够用我会优先开梯度检查点而不是继续往下调batch size。一个实用的经验是自动混合精度、梯度检查点、梯度累计这三个手段配合使用通常能把一个只能跑batch size2的模型救到batch size8而最终效果基本能维持原来的水平。5. 复现过程中遇到的高频问题与排查思路5.1 显存不够不只是换小batch size这么简单显存不够是多模态项目复现里最高频的问题。但很多人一遇到就急着把batch size调小结果模型不收敛或者效果奇差然后又来怀疑方法本身有问题。正确的处理顺序应该是先开自动混合精度再考虑梯度检查点然后是梯度累计最后才是缩小batch size。如果前三个手段都用完还是放不下那就要重新评估模型结构比如LLM层或者Transformer层能用LoRA就先做低秩适配冻结掉大部分参数省下来的显存效果立竿见影。还有一个小技巧把图像分辨率降下来。很多多模态模型的输入尺寸被设计成224或者336但实际任务并不需要那么高的分辨率。如果在你的场景里图像细节不是核心信息试一下降到160甚至128显存占用会明显下降。5.2 训练不收敛问题大概率在损失函数和数据对齐多模态训练不收敛我通常会先怀疑三件事。第一件事是数据对齐是否出错了。多模态数据配对非常容易出错比如视频抽帧后和文本标注错位了或者音频特征和视频帧的时间戳没对上。这类错误不会有报错提醒但会表现为loss剧烈震荡或模型效果极差。我的排查方式是找几个batch的数据出来可视化把图像、文本、音频特征都打印出来人工检查对齐是否正确。第二件事是学习率是否过大。多模态模型的优化面通常比单模态模型更复杂因为不同模态的收敛速度不一样。如果学习率太大容易出现一种模态主导了梯度另一种模态始终学不进去导致整体loss下了几个epoch就卡住不动。这时候调小学习率往往会有奇效。第三件事是损失函数各分支的数值尺度差太多了。比如图像重建损失的数值可能在100这个量级而文本对比损失在0.1这个量级两者相加时大数值把梯度全部抢走了小数值的损失就形同虚设。我的处理方式是先把各项损失打印出来看尺度再做归一化或调整权重。5.3 模型效果不升反降检查你的对比学习温度系数对比学习是多模态融合中最常用的训练范式之一但温度系数这个超参数经常被忽略。温度系数过小模型会把注意力过度集中在少数困难负样本上训练不稳定温度系数过大负样本之间的差异又被抹平模型学不到有区分度的表示。我习惯先按论文给的默认值跑如果不想用可学习的温度系数就固定在一个合理的范围比如0.05到0.2之间然后做小范围搜索。搜索时可以每隔几个epoch记录一次验证集指标不需要完整跑完训练。另外要检查的是对比损失的负样本来源。如果代码里负样本只来自当前batch内部batch size很小的时候负样本数量也少模型很容易在一个小范围内过拟合到“假阴性”上。解决办法是适当扩大batch size或使用一个队列来缓存历史特征作为额外负样本。5.4 评测指标与论文差距过大先核对评测协议复现结果跟论文有差距是最让人沮丧的但大多数时候不是代码有bug而是评测协议不一致。多模态领域的评测协议比单模态更细碎比如图文检索里是拿整个测试集做检索还是拿固定的query集合文本到图像和图像到文本两个方向是否分别报告结果recallK的K取多少这些细节都会显著影响最终数字。我建议拿到项目后先把官方的评测脚本完整读一遍搞清楚数据集的划分方式、预处理逻辑和指标计算逻辑再和论文方法部分对比。很多时候差距就来自一个不经意的细节比如是否在评测时用了上下文学习或者是否用到了测试集统计信息做归一化。如果评测协议核对完依然有差距也不用慌张。先把差距量化出来比如是差1个点还是差10个点。差1个点可能只是随机种子的波动差10个点就要怀疑实现细节了可以逐步简化模型去除一些辅助模块确认每个模块的实际贡献是否和论文消融一致。5.5 常见问题速查表现象常见原因我的处理方式训练刚开始就OOM输入尺寸过大/样本太大先确认数据形状再考虑梯度检查点和半精度Loss震荡剧烈学习率过大或数据对齐错位可视化一批数据确认对齐正确后下调学习率效果始终低于论文评测协议不一致逐行核对评测脚本与论文描述模型退化到单模态随机模态丢弃策略不合理加入模态置信度机制或改进遮罩策略多卡训练速度不升反降数据加载成为瓶颈增大DataLoader的worker数量或缓存预处理结果生成效果模糊量化粒度太粗考虑用连续特征混合表示代替纯离散token显存够但训练极慢梯度检查点开在浅层模块只为高显存模块开启其他位置关闭6. 从论文到工程落地我的一些扩展思考6.1 用Scaling Law的思路评估“值不值得上车”每次看到多模态融合的新方法我第一反应不是“这方法好厉害”而是“这个方法在数据规模和模型规模变化时会不会更厉害”。如果某个方法在小规模实验上提升明显但换大数据集和大模型后提升就消失了那大概率这个方法的创新点没有触及核心瓶颈。我习惯用局部结论做验证先用小模型加小数据集复现文章的主要结论如果趋势和文章一致再考虑扩大规模。ICLR2024很多论文在报告实验时会放出小规模数据的消融这部分恰恰是我最看重的信息。6.2 模态权重和数据配比才是“隐藏”的性能瓶颈我复现了这么多项目之后越来越觉得模态融合的真正瓶颈往往不是模型结构而是数据配比。比如你训练一个图文音三模态模型如果图文数据占了90%音频数据只占了5%模型会天然“瞧不起”音频这个模态最终表现就是音频相关任务掉点。这个问题在ICLR2024的文章里开始被正式讨论了有几篇专门研究了多模态训练时的数据配比和模态平衡问题。我自己在实践中也验证过哪怕模型结构不变仅把音频数据的占比从5%提到20%音频相关下游任务的指标就能提升不少。这个效果甚至比换一个更复杂的融合模块来得更明显。6.3 后续可以扩展的方向轻量化、增量学习与边缘部署如果你看完了ICLR2024这批文章并且复现了其中一两个项目下一步可以考虑怎么把它们往真实产品里迁移。我目前比较看好的扩展方向有三个。一个是模型轻量化。多模态大模型动辄几B参数在服务端部署成本很高在边缘设备上更是不要想。我建议重点关注LoRA、模型蒸馏、量化感知训练这类技术看能不能在不伤太多精度的情况下把模型压到可部署的规模。另一个是增量学习。真实业务场景里模态的类别、数据的分布都会随时间变化。如果一个多模态模型不能增量更新每次都要全量重训工程成本完全不可接受。未来的研究重点会逐渐从“在固定数据集上刷分”转移到“在动态环境里持续进化”。最后是边缘部署。端侧设备算力和内存都有限多模态模型的推理延迟必须控制得很低。这涉及结构剪枝、算子融合、缓存策略等一系列工程问题也是我在后续实践中最感兴趣的部分。我个人在实际操作中最深的感受是多模态融合这个方向创意重要但把创意变成能稳定运行的代码更重要。ICLR2024这批文章里真正对工业界产生影响的未必是排名最靠前的那几篇而是那些把代码细节处理得极好、让后来者能轻松复现和二次开发的工作。所以选一篇源码质量高的文章踏踏实实跑通它、理解它、再改造它比泛泛地读二十篇摘要要有用得多。希望你也能在这22篇文章里找到属于你的切入点。