企业官网建设流程全解析

做多模态融合这几年，我最大的感受就一句话：论文越来越难追了。不是论文难读，而是量大、题杂。尤其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篇分成了五类，每一类解决一类问题，也对应一类源码获取思路。

下面我会按类别展开，讲清楚每一类里的典型方法思路、为什么值得看，以及复现时要盯住哪些细节。

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 几个高频问题速查

5.2 新手建议：从一条最简单的跨模态任务开始

如果你刚开始接触多模态融合，最忌讳直接挑一个统一模态大模型开始复现。模型太大、数据太多、问题太复杂，出任何bug都很难定位。更建议的做法是选一个图文检索或者图文分类任务，比如经典的图文配对数据集，用CLIP风格或简单的交叉注意力架构做一版，把数据加载、模态编码、融合、评估这一整条链路跑通。链路通了之后，再逐步加入更复杂的动态融合、模态缺失mask、参数高效微调这些高级玩法。

5.3 进阶方向：把这些方法挪到你的业务里

对于有经验的研究者和工程师，我的建议是不要只读清单里的文章，而是把你自己的任务拿出来，对照五类方法问一遍：我的场景里有没有“模态动态选择”的需求？有没有“某个模态偶尔缺失”的情况？能不能把当前模型里最重的融合模块换成轻量适配器？这种对照比多读二十篇论文管用得多。你自己业务里的特殊约束，往往是比任何benchmark分数都重要的信噪比来源。

整理这份22篇清单的过程，比我读这22篇文章本身收获更大。因为你被迫给每一篇工作贴上“它在解决什么问题”的标签，贴完之后，整个领域的版图就清晰了。现在我在arXiv上看到任何新投稿，都先问自己三个问题：它属于哪一类问题？它的方法能不能迁移到我的场景？代码有没有放出来？如果三个问题都有答案，再决定要不要精读。这个方法比任何清单都管用，也建议你们试试。