💬 NLP

A Data-Efficient Path to Multilingual LLMs: Language Expansion via Post-training PARAM $\Delta$ Integration into Upcycled MoE

本論文は、\method と呼ばれるデータ効率に優れた手法を導入し、これは密なモデルを専門家混合アーキテクチャへとアップサイクルし、事後学習パラメータデルタを統合して多言語能力を拡張するものであり、これにより高コストな継続的事前学習や複雑なアライメントを必要とせず、新たな言語の習得と元モデルの能力の維持を効果的に両立させる。

原著者： Hao Zhou, Tianhao Li, Zhijun Wang, Shuaijie She, Linjuan Wu, Hao-Ran Wei, Baosong Yang, Jiajun Chen, Shujian Huang

公開日 2026-05-19

📖 1 分で読めます☕ さくっと読める

CC BY 4.0

原著者： Hao Zhou, Tianhao Li, Zhijun Wang, Shuaijie She, Linjuan Wu, Hao-Ran Wei, Baosong Yang, Jiajun Chen, Shujian Huang

原論文は CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/) でライセンスされています。 ✨ これは以下の論文のAI生成解説です。著者が執筆または承認したものではありません。技術的な正確性については原論文を参照してください。免責事項の全文を読む

以下は、論文「DeltaMoE: A Data-Efficient Path to Multilingual LLMs」の解説を、平易な言葉と創造的な比喩を用いて行ったものです。

大きな問題：「バイリンガルのシェフ」のジレンマ

世界クラスのシェフ（大規模言語モデル）が、英語料理の調理に長けていると想像してください。彼はその分野で驚くほど上手です。さて、このシェフにハンガリー語、セルビア語、ベンガル語の料理も学んでほしいとします。

これを行う従来の方法は、シェフを長期間にわたって巨大な調理学校へ送ることです（これを「継続的事前学習」と呼びます）。そこで彼らは、これらの新しい言語で書かれた何千冊もの料理本を勉強します。しかし、ここに落とし穴があります。

「忘れっぽい」シェフ： 新しい言語に熱心に勉強しすぎると、元の英語のレシピを忘れ始めてしまう可能性があります。
「希釈された」シェフ： 慎重に、古い英語の知識と新しい知識を優しく混ぜ合わせようとすると、結果としてどちらの料理も並み以下になってしまいます。英語を忘れることはありませんが、新しい言語の料理もあまり上手にはなりません。

これが論文で論じられている「トレードオフ」です。新しい言語を上手に学ぶか、既存のスキルを完璧に保つか、どちらかを選ばなければなりません。両方を手に入れることはめったにありません。

解決策：DeltaMoE（「専門化されたキッチン」アプローチ）

著者たちは、シェフの脳全体を再訓練して賢くしようとするのではなく、シェフに「専門化されたキッチンアップグレード」を与えるという新しい手法、DeltaMoEを提案しています。

その仕組みは、以下の 3 つの簡単なステップで行われます。

ステップ 1：「専門家混合（Mixture of Experts）」キッチンを作る（アップサイクル）

シェフのキッチンが拡張されると想像してください。すべてが行われる 1 つの大きなカウンターではなく、専門家混合（MoE）キッチンが建設されます。

元のカウンター（凍結された専門家）： シェフは元の英語のカウンターをそのままの状態に保ちます。それをロックします。ここには何も変化しません。これにより、英語のレシピを忘れることが決してありません。
新しいカウンター（学習可能な専門家）： 新しい言語（ハンガリー語、セルビア語、ベンガル語）のために、3 つの全く新しいカウンターが建設されます。
ヘッドウェイター（ルーター）： 賢いヘッドウェイターが雇われます。顧客が英語料理を注文すると、ウェイターは彼らを元のカウンターへ送ります。顧客がハンガリー語料理を注文すると、ウェイターは彼らをハンガリー語カウンターへ送ります。

シェフは新しいカウンターでのみ学習します。元のカウンターは凍結されたままなので、英語のスキルは完璧に保持されます。

ステップ 2：「デルタ」の接ぎ木（魔法の転送）

さて、新しいカウンターは料理を作るのが上手になりましたが、顧客に丁寧に話しかけたり、複雑な指示に従ったりする方法は知りません（これを「アライメント」と呼びます）。通常、これを学ぶには数ヶ月の訓練が必要です。

論文の巧妙なトリックは、デルタマージです。

顧客との会話やルール遵守の達人であるが、英語しか話さない別の有名なシェフ（事前学習済みの「インストラクト」モデル）がいると想像してください。
新しいカウンターをゼロから教えるのではなく、著者たちは有名なシェフと元のベースとの間の「差（デルタ）」を取り出します。これは付箋に書かれた「丁寧さのレシピ」と考えてください。
この付箋を新しいカウンターに貼り付けます。新しいカウンターは元のものと同じ「生地」から作られているため、この「丁寧さのレシピ」は即座に機能します。

結果： 新しいカウンターは、高価でデータ集約的な訓練プロセスを経ることなく、ハンガリー語の料理を作りながら丁寧に対応できるようになります。

なぜこれが古い方法よりも優れているのか

この論文では、他の手法と比較してこの方法をテストし、以下の結果を得ました。

トレードオフの解消：
- 古い方法 A（平均化）： 古いスキルと新しいスキルを混ぜようとしました。結果：シェフは英語が下手になり、新しい言語でも並み程度の出来になりました。
- 古い方法 B（直接デルタ）： 新しいスキルを単に上に貼り付けようとしました。結果：シェフは新しい言語では素晴らしいものの、英語の話し方を忘れてしまいました。
- DeltaMoE： シェフは英語が非常に上手（元のカウンターが凍結されているため）であり、新しい言語でも非常に上手（新しいカウンターがそれらを学び、「丁寧さ」の接ぎ木を受けたため）です。
データ効率：
- 他の手法は、モデルに新しい言語でどのように丁寧に対応するかを教えるために、何百万もの例が必要です。
- DeltaMoE は、既存のモデルからそれを「接ぎ木」することで、この能力を無料で獲得します。これにより、膨大な時間と計算リソースが節約されます。
スケーラビリティ：
- 著者たちは、言語を 3 つから 8 つのようにさらに追加しても、システムが崩壊しないことを示しました。ヘッドウェイター（ルーター）は単に注文を正しいカウンターへ送ることを学び、システムは安定したままです。

結論

DeltaMoEは、熟練したシェフに専門的でモジュール化されたキッチンを与えるようなものです。

彼らはコアスキルを保護するために、元の作業スペースをそのままに保ちます。
新しい言語のための新しい作業スペースを追加します。
再訓練なしで「顧客サービススキル」を新しい作業スペースへ即座に転送します。

これにより、AI モデルは元の知性を失うことなく、また膨大な量の新しいデータを必要とすることなく、多くの新しい言語を流暢かつ丁寧に話せるようになります。

技術概要：DeltaMoE – 多言語 LLM へのデータ効率化の道筋

1. 問題提起

大規模言語モデル（LLM）を新しい言語に拡張する現在のプロセスは、リソース集約的です。標準的なパイプラインは、大規模な多言語コーパスを用いた継続的事前学習（CPT）に続き、複雑なポストトレーニングアライメント段階（例：SFT および RL）を経るものです。このアプローチは、元の能力の破滅的忘却を防ぐための広範なデータ再生を要し、アライメントには大量の高品質な指示データが必要です。

最近の「データフリー」マージ技術は、CPT 強化モデルと既存のインストラクトモデルを融合させることでアライメント段階を迂回しようと試みています。しかし、これらの手法は重要なトレードオフに直面しています：

線形平均（モデルスープ）： 新たに獲得した言語知識を希釈し、拡張された言語での gains を制限します。
デルタマージ： パラメータ変更を直接適用すると、モデルの元の言語能力の破滅的忘却を引き起こすことがよくあります。

核心的な課題は、モデルの元の性能を犠牲にすることなく、新しい言語とアライメント能力を効率的に獲得することです。

2. 手法：DeltaMoE

著者らは、上記のトレードオフを解決するために、密なモデルをミクスチャー・オブ・エキスパート（MoE）アーキテクチャへアップサイクルする 2 段階のフレームワークDeltaMoEを提案します。

ステージ 1：スパースアップサイクルによる継続的事前学習

密なベースモデルは、元のフィードフォワードネットワーク（FFN）の深いコピーを「エキスパート」として作成することで、MoE アーキテクチャに変換されます。

アーキテクチャ： モデルは $N$ 個のエキスパートとルーターから構成されます。元のパラメータ（特に 0 番目のエキスパート）は凍結され、元の言語知識のための専用リポジトリとして機能します。
トレーニング： 新しい言語データを用いた CPT 中、新たに追加された拡張エキスパートとルーターのみが更新されます。
目的： モデルは、エキスパート間の効率的なトークン分配を確保するロードバランシング損失（LLB）を使用しながら、次のトークン予測（NTP）損失を最小化します。これにより、元の知識は維持されたまま、新しい言語はアクティブなエキスパートによって学習されます。

ステージ 2：MoE モデルマージ（デルタ統合）

MoE ベースモデルが新しい言語でトレーニングされると、アライメント能力が欠如しています。高価なポストトレーニングの代わりに、著者らはよくアライメントされた密なインストラクトモデルからのパラメータデルタ（ $\Delta_{post}$ ）を移植します。

デルタ計算： $\Delta_{post} = \theta_{post-trained} - \theta_{base}$ は、インストラクトモデルのトレーニング中に獲得されたアライメント知識を表します。
コンポーネント別移植：
- 共有パラメータ： 密モデルと MoE アーキテクチャの両方に共通する層（例：Attention、Embeddings）に対して、デルタは直接適用されます。
- エキスパートパラメータ： FFN 層に対して、密モデルの FFN 重みから単一の FFN 固有のデルタが計算されます。このデルタは、MoE アーキテクチャ内のすべてのエキスパートに均一に適用されます。
根拠： この戦略は、すべてのエキスパートが同じ基盤構造を継承するものとして扱い、凍結またはトレーニングされたエキスパートに格納された特定の言語知識を希釈することなく、アライメント知識をすべてのエキスパートにブロードキャストすることを可能にします。

3. 主要な貢献

新規フレームワーク： DeltaMoEの導入。MoE アップサイクルと洗練されたデルタマージ戦略を統合し、重厚なポストトレーニング手順なしで言語を拡張し、アライメント能力を獲得します。
トレードオフの解決： この手法は、知識獲得（新しいエキスパート経由）と知識保持（凍結エキスパート経由）およびアライメント転送（デルタ移植経由）を効果的に分離し、能力拡張と元の性能の維持との間の対立を解決します。
汎用性： このアプローチは、異なるベースモデル（Qwen2.5-7B、LLaMA-3.1-8B）および異なるアライメントデルタ源（標準インストラクト、Tulu3 SFT）で検証され、堅牢性を示しています。

4. 実験結果

Qwen2.5-7B および LLaMA-3.1-8B をハンガリー語、セルビア語、ベンガル語に拡張する実験が実施され、データ、FLOPs、パラメータ数が一致したベースラインと比較評価されました。

拡張言語における性能： DeltaMoE は最先端（SOTA）の性能を達成し、比較可能なパラメータを持つ他のデルタベース手法よりも拡張言語の平均スコアを1.7 ポイント向上させました。
元の能力の保持： 顕著な忘却を引き起こした密デルタマージとは異なり、DeltaMoE は元の言語性能を保持し、保持指標において密デルタベースラインを1.5 ポイント上回りました。
効率性： 密ベースラインが MoE トレーニングの FLOPs に一致させるために CPT データの 2 倍でトレーニングされた場合でも、DeltaMoE は拡張言語の性能において顕著なリード（約 1.94 ポイント）を維持しました。
アブレーション研究：
- マージ戦略： MoE アーキテクチャ内での線形平均はトレードオフを解決できず、デルタマージアプローチの必要性を確認しました。
- ルーターチューニング： 最小限のデータ再生戦略（0.15B トークン）とルーターチューニングの組み合わせにより、DeltaMoE は知識保持において密平均ベースラインを上回ることができました。
- スケーラビリティ： トレーニング可能なエキスパートの数を 3 以上増やしても、得られる利益はほとんどなく、複数の拡張言語に対しては 3 つのトレーニング可能エキスパートで十分であることを示唆しています。

5. 意義と主張

本論文は、DeltaMoE が既存の LLM の多言語アライメントを拡張するための実用的かつスケーラブルな道筋を提供すると主張しています。密モデルを MoE アーキテクチャへアップサイクルし、アライメントデルタを移植することで、この手法は：

新しい言語に対する大規模な指示データセットや複雑な RL アライメント段階の必要性を排除します。
現在のマージ技術に内在する「忘却対学習」のジレンマを解決します。
密トレーニングデータのスケールアップに比べて計算オーバーヘッドを大幅に削減しながら優れた性能を達成する、データ効率の高い代替手段を提供します。

著者らは限界を認め、評価された言語が世界の言語的多様性を完全に代表しているわけではないこと、および MoE アーキテクチャは推論中に密モデルと比較して無視できない計算オーバーヘッドをもたらすことを指摘しています。しかし、このフレームワークは、効率的な多言語拡張のための堅牢な解決策として提示されています。