技術的サマリー：FPMoE – 関数型コード生成のためのスパース混合専門家アプローチ

1. 問題定義

コード生成における大規模言語モデル（LLM）の急速な進展にもかかわらず、Haskell、OCaml、Scala などの関数型プログラミング言語（FPL）は慢性的に十分に研究されていません。既存の最先端モデルは、Java などの命令型言語と比較して FPL において著しく低い性能を示し、機能的には正しいが、関数型スタイルの慣習（例えば、モナドの使用や参照透過性の欠如）に違反するコードを生成することがよくあります。

本論文は構造的なデータ不均衡を特定しています：FPL 開発者コミュニティは小さく、主流の言語に比べて桁違いに少ないオープンソースコードを生成しています。その結果、前学習データの拡張だけでは性能格差を埋めるのに不十分です。

著者らは微調整を解決策として調査しましたが、標準的なアプローチには 2 つの明確な失敗モードが存在することを見つけました：

1. 言語別微調整： 各言語ごとに個別のモデルを学習させることは、言語横断的に一般化する共有された関数型抽象（例えば、モナド推論）を捉え損ないます。
2. 多言語微調整： 複数の言語の混合データで単一の密モデルを学習させることは、言語間の干渉を引き起こし、個々の言語（特に OCaml）の性能を低下させます。

核心的な課題は、言語固有の専門性と、共有された言語横断的な一般化を同時に維持することです。

2. 手法

著者らは、スパース混合専門家（MoE）アーキテクチャに基づいた軽量なオープンソースのコード生成モデルFPMoEを提案します。学習パイプラインは 3 つの段階で構成されます：

2.1 データ収集と前処理

• コーパス： データは CodeParrot の GitHub クロールと OCaml コーパスから収集され、Haskell、Scala、OCaml のリポジトリでフィルタリングされます。
• フィルタリング： 行長が過度に長いファイル（自動生成コード/ミニファイ済みコード）は破棄されます。
• 重複排除： リポジトリレベルで実行され、構造的完全性を維持します。
• 汚染除去： FPEval テストセットで見つかった部分文字列を含む学習データを除外する N-gram フィルタリングを行います。
• シーケンス構築： 学習シーケンスは、リポジトリ内の依存関係や長距離の文脈を維持するために、ファイルレベルではなくリポジトリレベル（リポジトリ内のすべてのソースファイルを連結）で構築されます。

2.2 専門家前学習

ベースモデル上で 2 つの並列教師あり微調整（SFT）実行が行われます：

1. 言語別 SFT： ベースモデルを 3 つの言語コーパスそれぞれで独立して微調整し、3 つの専門化されたチェックポイントを生成します。
2. 多言語 SFT： 3 つのコーパスのすべてを合わせた集合で別のインスタンスを微調整します。これは密なベースラインとして、および共有専門家の初期化として機能します。

2.3 共同 MoE 微調整

最終モデルは、トランスフォーマーバックボーンのフィードフォワードネットワーク（FFN）サブレイヤーを専用のMoE-FFN ブロックに置き換えることで構成されます：

• ルーティング専門家： 3 つの専門家（$E_1, E_2, E_3$）は言語別チェックポイントから初期化されます。軽量なルーターは Top-K 選択（K=2）を使用して、トークンを適切な言語専門家に配信します。
• 共有専門家： 4 つ目の専門家（$E_{shared}$）は、ルーティングの決定に関わらず常にアクティブです。これは言語横断的な関数型パターン（例えば、タイプ指向プログラミング）を符号化するために、多言語チェックポイントから初期化されます。
• 学習目的： 組み立てられたモデルは、ルーティングの崩壊を防ぐための補助的な負荷分散損失を強化した因果言語モデル化目的を用いて、結合コーパス上で共同学習されます。

3. 主要な貢献

1. 問題分析： 標準的な微調整戦略（言語別対多言語）が、密モデルでは同時に解決できない相補的な失敗モードを示すという実証的証明。
2. モデルアーキテクチャ（FPMoE）： 言語アイデンティティをルーティングのための帰納的バイアスとして明示的に組み込んだスパース MoE アーキテクチャの導入。以前のデータ駆動型の MoE アプローチ（Mixtral、DeepSeekMoE など）とは異なり、FPMoE は言語固有の知識でルーティング専門家を初期化し、言語横断的な抽象を捉えるために専用の常時アクティブな共有専門家を採用します。
3. 評価と分析： 機能的な正しさを超えて、FPViolation（慣習的スタイルへの準拠）を評価します。アーキテクチャの利益を、言語整合ルーティングと共有専門家の貢献に分解する制御されたアブレーション研究を提供します。

4. 実験結果

実験は、Haskell、OCaml、Scala における 721 タスクからなるFPEvalベンチマークで行われました。

• 密ベースラインとの性能比較： FPMoE は、密微調整ベースラインを大幅に上回ります。
  • FPMoE-Qwen2.5-4x1.5B-A3B（アクティブパラメータ 3B）は、Pass@1 スコアで Haskell 7.37%、OCaml 6.8%、Scala 13.31% を達成しました。これは、対応する密な 1.5B モデルに対して 5〜11 倍の改善を表します。
  • FPMoE-Qwen2.5-4x3B-A6B（アクティブパラメータ 6B）は、Haskell 11.00%、OCaml 12.34%、Scala 21.08% を達成しました。
• パラメータ効率： 6B アクティブパラメータの FPMoE モデルは、DeepSeek-Coder-6.7B や Qwen2.5-Coder-14B といったはるかに大きな密モデルと同等かそれ以上の性能を発揮し、それらのパラメータの半分未満しかアクティブにしません。また、OCaml と Scala において GPT-3.5 を上回ります。
• 慣習性： FPMoE は、テストに合格するが関数型原則に違反する命令型スタイルのコードを生成することが多い、より大きな最先端モデルと比較して、正しさと関数型スタイルへの準拠（より低い FPViolation 率）の間のより良いバランスを示します。

アブレーション研究の知見

• 共有専門家の初期化： 共有専門家を多言語コーパスから初期化すること（設定 A）は決定的です。一般ベースモデルから初期化すること（設定 B）や、それを凍結すること（設定 C）は性能低下を招き、場合によっては密ベースラインを下回ります。
• 共有専門家の必要性： 共有専門家を除去すること（設定 D）は性能を低下させ、それが言語横断的な抽象を捉える役割を果たしていることを確認します。
• 言語整合ルーティング： 言語固有のウォームアップを除去すること（設定 E）は、特に OCaml で著しい性能低下を引き起こし、ルーターが帰納的バイアスなしにデータからのみ専門性を発見できないことを証明します。

5. 意義と主張

本論文は、ターゲットを絞ったアーキテクチャの専門化が、蛮力的なデータ拡張よりも関数型コード生成へのより原理的な道を提供すると主張しています。著者らは以下を論じています：

• FPL データエコシステムは構造的に小さく、大規模な前学習のみを支えるために急速に成長する可能性は低いです。
• より大きなコーパスで学習された最先端モデルは依然として高い慣習違反率を示しており、データ拡張だけでは問題が解決しないことを示唆しています。
• FPMoE の設計は、言語固有の構文（ルーティング専門家を通じて）と共有された関数型ロジック（共有専門家を通じて）を分離することで、利用可能な FPL トークンを効果的に活用します。

著者らは FPMoE を関数型プログラミングへの参入障壁を下げることへの一歩として位置付けていますが、サポートされる言語の固定セット、推論中の潜在的なメモリフットプリントの問題、学習データの鮮度などの限界も認識しています。