ChartMoE:ICLR 2025 口头报告,探索面向下游任务的多样化对齐 MoE 表征与知识

ICLR 2025 Oral 论文 ChartMoE 提出一种新颖的 MoE 训练方法,通过多样化对齐任务增强模型对图表的理解,同时缓解通用知识遗忘。

原文标题:ICLR 2025 Oral IDEA联合清华北大提出ChartMoE:探究下游任务中多样化对齐MoE的表征和知识

原文作者:数据派THU

冷月清谈:

清华北大等机构联合提出的 ChartMoE 成功入选 ICLR 2025 口头报告。该研究着眼于 MoE 架构在下游任务中的应用,并非单纯追求扩大模型容量,而是旨在通过对齐任务增强模型对图表的理解能力,并尽可能减少对通用知识的遗忘。ChartMoE 创新性地利用多样化的对齐任务初始化 MoE 专家,以此增大专家间的差异性,使模型能够学习到更全面的视觉表征。该模型通过多阶段图文对齐,将图表转换为 Table、JSON、Python Code 等多种结构化文本格式,从而训练 MoE Connector。实验结果表明,这种多样化对齐方式能够有效提高 MLLM 的图表理解能力,并在不引入通用数据的情况下,减少模型对通用知识的遗忘。此外,研究团队还对 ChartMoE 的表征进行了可视化分析,并探讨了 MoE 结构在下游任务中的表现。

怜星夜思:

1、ChartMoE 通过将图表转换为 Table、JSON、Python Code 等多种结构化文本格式进行训练,这种方式的优势是什么?是否存在局限性?
2、文章提到 MoE 结构本身就带有一定的正则作用,可以缓解下游领域模型在通用任务上遗忘。你认为除了文章中提到的原因外,还有哪些因素可能导致这种现象?
3、ChartMoE 在专家选择分布上,发现模型倾向于选择通用专家和最富含信息的 Code 专家。这说明了什么?对于未来的模型设计,你有什么启发?

原文内容

来源:人工智能前沿讲习‍‍‍‍‍‍‍‍‍‍‍‍
本文共2600字,建议阅读10分钟
在不使用通用领域数据的情况下,在通用领域中遗忘更少,可能是做下游领域 MLLM 更关注的事情。


最近,全球 AI 和机器学习顶会 ICLR 2025 公布了论文录取结果:由 IDEA、清华大学、北京大学、香港科技大学(广州)联合团队提出的 ChartMoE 成功入选 Oral (口头报告) 论文。据了解,本届大会共收到 11672 篇论文,被选中做 Oral Presentation(口头报告)的比例约为 1.8%

  • 论文链接:
  • https://arxiv.org/abs/2409.03277
  • 代码链接:
  • https://github.com/IDEA-FinAI/ChartMoE
  • 模型链接:
  • https://huggingface.co/IDEA-FinAI/chartmoe
  • 数据链接:https://huggingface.co/datasets/Coobiw/ChartMoE-Data

研究动机与主要贡献:
  • 不同于现阶段使用 MoE 架构的原始动机,ChartMoE 的目标不是扩展模型的容量,而是探究 MoE 这种 Sparse 结构在下游任务上的应用,通过对齐任务来增强模型对图表的理解能力,同时保持在其他通用任务上的性能。
  • 不同于之前依赖 ramdom 或 co-upcycle 初始化的方法,ChartMoE 利用多样的对齐任务进行专家初始化。这种方法加大了专家间的异质性,使 ChartMoE 可以学习到更全面的视觉表征,展现出显著的解释性。

ChartMoE 是一个以 InternLM-XComposer2 模型为训练起点、引入 MoE Connector 结构的多模态大语言模型,具有先进的图表理解、图表重绘、图表编辑、重要部分高亮、转换图表类型等能力。ChartMoE 为图表(Chart)这种独特于自然图像的输入,设计了多阶段的图文对齐方式,每一个阶段产物都是 MoE Connector 中的一个专家,这样的训练方式和模型设计不仅能获得更全面的视觉表征、显著提高 MLLM 的图表理解能力,还可以在不加入通用数据的情景下,减少模型对通用知识的遗忘。

多阶段对齐训练的 MoE

  • 通用 MLLM,如 LLaVA,他们的 training recipe 通常分为两个阶段,第一个阶段使用图文对(image-text pair)训练 MLP Connector,第二阶段 SFT 训练 MLP Connector + LLM。
  • 这种范式可以很自然的迁移到 Chart MLLM 中,如:ACL24 的 ChartAst,使用成对的 Chart-Table 进行第一阶段的图文对齐。

然而,Table 这种结构化文本格式,其中仅包含了每个数据点的数值,以及 xy 轴的含义等信息,几乎不保留视觉元素信息,如:颜色、图表类型、图形元素的相对关系等。所以,ChartMoE 希望采用更多样、更全面的对齐方式,将 Chart 转译成三种结构化文本格式:Table、JSON、Python Code

我们以开源数据集(ChartQA、PlotQA、ChartY)中的表格数据作为起始点,为每个图表类型人为定义了 JSON 键,通过 random 生成、GPT 生成等方式为每个键填上对应的值,从而构建出 JSON 数据。此后可以将 JSON 中的键值对填入到每个图表类型预定义好的代码模板中得到 Python 代码来生成图表,从而构成 (Chart, Table, JSON, Code) 四元组,通过这种方式,采集了约 900k 数据,称为 ChartMoE-Align。

获取到数据后,ChartMoE 采用 chart-to-table、chart-to-json、chart-to-code 三种方式进行图文对齐,每个任务分别训练一个独立的 MLP Connector,拼上初始的通用 MLLM 中的 MLP Connector,再加上一个随机初始化的 learnable router,就可以构成一个亟待吃下 SFT 数据的 MoE Connector,即:Diversely Aligned MoE

对比 Diversely Aligned MoE 与 Random 初始化、Co-Upcycle 初始化(即把通用 Connector 复制 N 份)的 Training Loss,我们发现,Diversely Aligned MoE 能够有更低的初始 loss(因为已经更好地学到了对齐到后续 LLM 的 chart 表征),以及整体更平滑的训练曲线

Training Recipes

ChartMoE 训练分为三个阶段:

  • 多阶段对齐(数据:ChartMoE-Align,Table 500k + JSON 200k + Code 100k),仅训练 MLP Connector,最后拼成 MoE Connector。
  • 广泛学习高质量知识(使用 MMC-Instruct 数据集,包含很多 Chart 相关的任务,如:Chart Summarization),训练 MoE Connector(尤其是 Learnable Router,亟待学习)以及 LLM Lora。
  • Chart 领域 SFT(ChartQA + ChartGemma):训练 MoE Connector 以及 LLM Lora;
  • PoT(Program-of-Thought):即输出 python 代码来解决问题,可以让模型将计算交给代码,提高解题准确率,如:一个利润柱状图,问最高利润和最低利润差多少,就会输出代码:

  • profits = [5, 7, 9, 1, 11, -3]
    print (max (profits) - min (profits))
    

ChartMoE 表征可视化

按每个 Visual Patch Token 选择的专家序号进行可视化,观察 Visual Patch 的 Top-1 的专家选择分布:

  • 背景 tokens 倾向于选择通用通用专家,也说明通用专家选择占比非常高。
  • 数据点、图像元素、图像元素间的 interaction(如第一行第四列的 graph 图的 edges)非常倾向于选择 code 专家(尽管 chart-to-code 数据中并没有包含这种 graph 图表)。
  • 标题、xy 轴标注、xy 轴刻度、图例等文本信息,倾向于选择 table/JSON 专家。
  • 类似的现象也可以泛化到通用场景,尽管我们整个 training 中完全没有包含这样的数据。

ChartMoE 专家分布可视化

我们分析了完全让模型自由学习,不加入 MoE balance loss 下的专家选择分布,和上文所述符合,模型倾向于选择通用专家和最富含信息的 Code 专家 Random 初始化、Co-Upcycle 初始化、加入 balance loss 的 Diversely-Aligned 初始化,我们均有进行专家选择分布的分析,以及严格控制变量下的 ChartQA 性能比较:

尽管前三者都会获得更均衡的专家分布,但性能是不如完全不加 balance loss 自由学习 Divesely-Aligned MoE 的,可能是因为:

  1. 对于视觉信息,本就是分类不均衡的,信息相对少的背景 tokens 占全部视觉 tokens 的大多数。
  2. balance loss 本身目的并非在于性能的提升,而是专家选择更均衡后,配合专家并行 (Expert Parallel) 技术,可以提高训练 / 推理的效率。

我们额外分析了最终的 ChartMoE checkpoint,强行固定选择某个专家的性能:

可以看到,和专家选择分布基本保持一致,模型自己最知道哪个专家能获得好性能了。

ChartMoE Performance(Chart & 通用)

这里想先 show 一下通用领域,因为 chart 领域的 sota 在进行了细粒度的多样化对齐后,相对来说更加可以预见。在不使用通用领域数据的情况下,在通用领域中遗忘更少,可能是做下游领域 MLLM 更关注的事情。这会让我们有更好的预期:比如加入通用数据后,通用能力不掉!

我认为通用领域遗忘更少有两个原因:

  1. (显而易见)插入了通用专家,尽管通用专家也更新了。

  2. (可能更本质)MoE Connector 的结构,由于 learnable router 的存在,通用专家的更新相比普通的 MLP Connector 是更少的(比如有些 token 可能确实没选到通用专家,它就不会对通用专家的更新产生贡献),某种程度上,可以认为 MoE Connector 这种 sparse 结构本身就带有一定的正则作用

通用领域

我们选择了 MME 和 MMBench 两个比较有代表性的通用领域的 benchmark,比较了 baseline(InternLM-XComposer2)、用 chart 数据 directly SFT、以及 ChartMoE 的性能,可以看到,Directly SFT 模型在通用领域掉点严重,ChartMoE 几乎不会掉性能,且在有些细分领域上还有增点

Chart 领域

对于 Chart 领域,我们选择了 ChartQA、ChartBench(主要是无数值标注的 Chart)、ChartFC&ChartCheck(Fact Checking 任务,回答支持或不支持),在这些 Benchmark 上,ChartMoE 都能达到非常好的性能,尤其是相对初始的 baseline 模型(InternLM-XComposer2)提升非常显著。

Conclusion

在 ChartMoE 这个工作中,我们探索了通用 MLLM 使用 MoE 这种 sparse 的结构后在下游任务上的表现:

  1. 从 Representation 角度:专家异质化的 MoE 可以获得更加多样、更加全面的视觉表征,从而在下游任务上达到更好的性能。
  2. 从 Knowledge 角度:MoE 这种 Sparse 结构,可以等价于加入了适量的正则项,既能显著提高下游任务性能,也能缓解下游领域模型在通用任务上遗忘。

ChartMoE 是一个抛砖引玉的工作,我们相信后续也会有更多工作去探索下游任务中 Sparse 结构的表现!

编辑:黄继彦



关于我们

数据派THU作为数据科学类公众号,背靠清华大学大数据研究中心,分享前沿数据科学与大数据技术创新研究动态、持续传播数据科学知识,努力建设数据人才聚集平台、打造中国大数据最强集团军。




新浪微博:@数据派THU

微信视频号:数据派THU

今日头条:数据派THU

我认为 MoE 结构可以看作是一种“知识隔离”机制。不同的专家专注于不同的任务或知识领域,避免了所有知识都混杂在一个模型中,从而减少了相互干扰。此外,MoE 的路由机制也可能起到作用,只有与当前任务相关的专家才会被激活,降低了无关知识的干扰。

这表明通用知识仍然是重要的基础,而 Code 专家能够提供更强的推理和计算能力。未来的模型设计可以考虑更有效地融合通用知识和领域知识,同时加强模型的推理能力。另外,如何更好地平衡不同专家之间的选择频率,避免某些专家被过度使用或利用不足,也是一个值得研究的问题。

优势在于能够从不同角度对图表信息进行编码,迫使模型学习更全面的表征。Table 提供结构化数据,JSON 提供键值对信息,Code 更是提供了生成图表的能力。 局限性在于构建这些数据对可能需要大量的人工定义和生成,成本较高,且可能引入人为偏差。

我倒是觉得,这反映了数据集中可能存在的问题。会不会是 ChartMoE-Align 数据集中,Code 数据的信息密度更高,或者说 Code 数据的质量更高,导致模型更倾向于选择 Code 专家?如果能提高其他类型数据的质量,是不是就能让模型更均衡地利用不同的专家了?

说明通用专家是“基本盘”,code专家是“发动机”。以后的模型可以考虑把通用能力和专业能力解耦,让模型在通用知识的基础上,更加灵活地调用专业知识。 另外,启发就是别强行干预模型的选择,要相信模型自己知道哪个专家最靠谱!

我感觉这个思路很赞!相当于把图表信息拆解成不同维度的数据,让模型从不同侧面去学习。不过,会不会因为引入了太多结构化信息,反而忽略了图表本身的视觉特征呢?比如颜色、形状这些,如果模型过度依赖结构化数据,会不会在面对一些视觉干扰较强的图表时表现不佳?

这就像给模型提供了不同语言的“翻译”,让它从多个角度理解图表。Table 像是“摘要”,JSON 像是“目录”,Code 像是“制作说明书”。好处是理解更全面,坏处是准备这些“翻译”挺费功夫的,而且翻译质量直接影响模型的学习效果。

这就像是团队合作,每个人负责不同的模块,修改一个模块的代码不太会影响其他的模块。这样在chart领域进行了修改,其他通用领域不太会受到影响。当然也可能存在一种情况,就是所谓的『涌现』特性,MoE的结构能够让模型具备更加强大的能力,从而减少遗忘。

其实我有个疑问,会不会是因为 MoE 结构增加了模型的参数量,从而提高了模型的容量,使得模型能够记住更多的知识,而不是因为所谓的“正则作用”?毕竟,参数量上去了,记忆能力自然会增强嘛。