查看原文
其他

ICLR 2024 | OCTAVIUS: 通过MoE缓解MLLM任务间的干扰

让你更懂AI PaperWeekly
2024-08-22


最近的研究表明,大型语言模型(LLM)可以通过指令微调将其零样本泛化能力扩展到多模态学习。但随着更多种模态和下游任务的引入,任务间的冲突和干扰可能会对模型的性能造成更严重的影响,即 tug-of-war(任务间互相竞争,可以类比拔河)问题。


例如,对于目标检测任务来说,模型的输出应该是一些物体框的坐标,而对于一般的问答任务来说,模型的输出是一段流畅的文字,因此这两种任务输出之间的差异很大。将这两种任务放在一起训练同一个模型,就会使模型的性能急剧下降。然而,这种现象在以前的工作中经常被忽视。


针对这一问题,来自上海人工智能实验室和北京航空航天大学的研究者们提出了一种新颖的可扩展框架,称为 OCTAVIUS,用于多模态大语言模型(MLLM)进行多模态学习的综合研究。


具体来说,该框架将著名的混合专家系统(MoE)和具有代表性的参数高效微调(PEFT)技术 LoRA 相结合,设计了一种新型的基于 LLM 的解码器,称为 LoRA-MoE,该设计能够为不同的下游任务自动分配不同的专家,以此来减轻任务之间的冲突。


在图像和点云模态的多个任务上,Octavius 获得了超过 20 个点的平均提升

论文链接:
https://arxiv.org/abs/2311.02684

项目链接:

https://openlamm.github.io/paper_list/Octavius

demo链接:

http://106.14.2.150:10006/



为何MoE在MLLM中能发挥如此重要的作用?

得益于参数高效微调(PEFT)技术,MLLM 仅需要在模型中添加少量可训练参数就可实现高效的模型训练。因此最近的 MLLM (例如 LAMM,  LLaMA-Adapter)可以有效地学习使用小规模有标签数据来解决下游任务,同时保持对话能力和对新场景的泛化性。


PEFT 虽然已被广泛应用于 LLM 的训练中,但是在使用时总会遇到 tug-of-war 的问题,即同时学习不同的任务可能会取消每个特定于任务的优化,并最终损害每个下游任务的性能。这个问题在 MLLM 中更为严重,特别是当涉及更多模态和任务,但只有少量优质的有标签数据可用时。


为了解决这个问题,本文提出了 LoRA-MoE,一个可以通过学习更多的 LoRA 模块来有效地参与更多的下游任务和更多的模态的基于 LLM 的解码器。与传统的 MoE 模型不同,我们采用简单而有效的 instance-based 的门路由方案,通过instance-level 的指令稀疏地激活独立的 LoRA 专家,并进一步获取特定于任务的知识,以更好地协调不同的任务。

基于上述内容,本文引入了一个新颖且通用的框架,称为 OCTAVIUS,利用来自 LAMM 和 ScanNet 的数据重新构造了一个指令跟随数据集来训练 MLLM。OCTAVIUS 可以有效解决各种 2D/3D 视觉和语言任务,包括但不限于 2D detection、2D caption、3D VQA 和 3D dense caption。本文进行了各种实验来验证我们设计的有效性和多功能性,在只增加少量可训练参数的情况下,将多个下游任务指标提高了约 20%。



OCTAVIUS的组成元素

2.1 多模态解码器(Multimodal Decoder)

尽管 LAMM 的原始数据集(LAMM v1)包含大量来自 MS-COCO 的图像,但缺乏足够的检测指令数据导致其在 PASCAL VOC 上的性能较差。为了克服这个问题,我们利用整个 COCO 数据集的检测标注和 GPT-API 生成的额外的检测指令作为补充,构建了一个名为 LAMM v2 的新数据集,以在检测任务上获得更强的泛化性能。


在 3D 模态上,由于其多样化的任务和注释类别,我们基于 ScanNet 构建了我们的 3D 指令调整数据集 Scan2Inst。


不同模态和任务之间的干扰是多模态和多任务学习中常见且关键的问题。虽然 MLLM 可以通过对所有任务采用相同的学习目标,即 next token prediction 来缓解这个问题,但仍然存在特定于任务的差异,限制了它们在各种下游任务中的潜力。


为了解决 tug-of-war 的问题,本文提出了一个基于 instance-based 的门路由策略的统一解码器。与 LLM 中基于 token 的门不同,我们为 MLLM 设计了一种简单但有效的路由策略,将下游任务分配给独立专家以获取基于单个 instance 的特定知识,称为基于 instance 的门。


多模态指令中输入的问题 会极大地影响 MLLM 生成的回答,因此我们将这些问题作为输入来预测每个专家的路由分数。然后,我们根据每个 instance 的路由分数来稀疏得激活部分专家来生成回答。


在这项工作中,LoRA 模块被视为 MLLM 中的专家,将基于 instance 的门与它相结合以减轻多模态学习产生的干扰,命名为 LoRA-MoE。通过将语言模型 中每个投影层中的 LoRA 替换为一组独立的 LoRA 专家 ,我们可以预测 token 值如下:

2.2 多模态编码器

2.2.1 图像编码器

对于图像输入,我们使用预先训练的 CLIP 视觉编码器提取和语言对齐的视觉特征,然后使用一个可训练线性层来对齐视觉特征和文本特征的维度。

2.2.2 点云编码器

传统的 3D 方法经常使用 3D CNN 或者 Transformers 作为特征提取器来处理稀疏的点云特征,然而,它们仍然保留了大量低密度信息的背景点,这可能会混淆 MLLM 中后续的语言模型,从而忽略场景中的关键元素。为了解决这些问题,我们提出了 Object-As-Scene 模块作为我们的点云编码器,专用于语言对齐的场景级 3D 表示生成。该模块可以分解成以下三个部分:


1. 感兴趣区域提取:给定 3D 点云场景,采用预先训练的对象检测器从场景中提取候选的 RoIs(感兴趣区域)。


2. 特征对齐:参考类似 ULIP 的对比学习方法,将第一步提取出的区域级点云特征和对应的图片与文本特征对齐,预训练一个 Point-Bert 作为点云编码器。


3. 特征聚合:使用一组可学习的 query 从得到的区域级点云特征里自适应聚合相关特征。



OCTAVIUS 有多厉害

虽然我们使用 MoE 的模型在某些任务上的表现与在单一模态上微调的模型相比有一些差距,但是总的来说,和之前的模型相比,我们的模型在大部分 2D 任务和 3D 任务上都表现出了更优越的性能,尤其是在目标检测以及标题生成任务上有了显著提升,并且将下游任务指标平均提高了约 20%。



结语

本项工作提出了一个统一的多模态框架 OCTAVIUS,能够有效地编码不同模态的视觉输入,以理解跨多种模态的各种任务。通过将 MoE 应用到 Lora 上,OCTAVIUS 大幅缓解了多模态大模型在多任务学习中的 tug-of-war 问题,并在下游任务上获得了更好的性能。



更多阅读



#投 稿 通 道#

 让你的文字被更多人看到 



如何才能让更多的优质内容以更短路径到达读者群体,缩短读者寻找优质内容的成本呢?答案就是:你不认识的人。


总有一些你不认识的人,知道你想知道的东西。PaperWeekly 或许可以成为一座桥梁,促使不同背景、不同方向的学者和学术灵感相互碰撞,迸发出更多的可能性。 


PaperWeekly 鼓励高校实验室或个人,在我们的平台上分享各类优质内容,可以是最新论文解读,也可以是学术热点剖析科研心得竞赛经验讲解等。我们的目的只有一个,让知识真正流动起来。


📝 稿件基本要求:

• 文章确系个人原创作品,未曾在公开渠道发表,如为其他平台已发表或待发表的文章,请明确标注 

• 稿件建议以 markdown 格式撰写,文中配图以附件形式发送,要求图片清晰,无版权问题

• PaperWeekly 尊重原作者署名权,并将为每篇被采纳的原创首发稿件,提供业内具有竞争力稿酬,具体依据文章阅读量和文章质量阶梯制结算


📬 投稿通道:

• 投稿邮箱:hr@paperweekly.site 

• 来稿请备注即时联系方式(微信),以便我们在稿件选用的第一时间联系作者

• 您也可以直接添加小编微信(pwbot02)快速投稿,备注:姓名-投稿


△长按添加PaperWeekly小编



🔍


现在,在「知乎」也能找到我们了

进入知乎首页搜索「PaperWeekly」

点击「关注」订阅我们的专栏吧


·
·

修改于
继续滑动看下一个
PaperWeekly
向上滑动看下一个

您可能也对以下帖子感兴趣

文章有问题?点此查看未经处理的缓存