💬 NLP

FPMoE: A Sparse Mixture-of-Experts Approach to Functional Code Generation

FPMoE 是一个轻量级开源代码生成模型，它利用包含专用专家与共享专家的稀疏混合专家架构，克服了现有模型在函数式编程语言中的局限性，在 Haskell、OCaml 和 Scala 上实现了卓越性能，同时仅以 30 亿活跃参数即可匹配规模大得多的模型。

原作者： Loc Pham, Lang Hong Nguyet Anh, Thanh Le-Cong

发布于 2026-05-28

📖 1 分钟阅读☕ 轻松阅读

CC BY 4.0

原作者： Loc Pham, Lang Hong Nguyet Anh, Thanh Le-Cong

原始论文采用 CC BY 4.0 许可（http://creativecommons.org/licenses/by/4.0/）。 ✨ 这是对下方论文的AI生成解释。它不是由作者撰写或认可的。如需技术准确性，请参阅原始论文。阅读完整免责声明

想象一下，你正在尝试教导一支人工智能助手团队如何使用函数式编程语言（如 Haskell、OCaml 和 Scala）编写代码。这些语言就像一种特定的数学方言：它们非常逻辑化、严格，并且与大多数计算机和人工智能所熟悉的“命令式”语言（如 Python 或 Java）截然不同。

这篇题为FPMoE的论文指出，当前的人工智能模型在这种特定方言上表现糟糕。以下是使用日常类比对问题、解决方案及其原理的简明拆解。

问题：“一刀切”与“专家”的两难困境

研究人员尝试了两种标准的修复 AI 的方法，但都失败了：

“专家”方法（按语言微调）：
- 理念： 训练一个 AI 专门负责 Haskell，另一个专门负责 OCaml，第三个专门负责 Scala。
- 失败原因： 这就像雇佣了三位只懂得烹饪一道特定菜肴的独立厨师。他们在那道菜上变得非常擅长，却忘记了适用于所有菜肴的烹饪通用规则（例如热量如何影响食材）。他们忽略了大局。
“通才”方法（多语言微调）：
- 理念： 在一个 AI 上同时混合训练这三种语言。
- 失败原因： 这就像将三种不同的英语方言同时塞进一个人的大脑。这个人会感到困惑，混淆规则。最终写出的代码看起来像是一种杂乱的混合体，无法在三种语言中的任何一种听起来自然。这被称为“跨语言干扰”。

解决方案："FPMoE"团队

作者创建了一个名为FPMoE（函数式编程混合专家）的新模型。不要把它想象成一个巨大的大脑，而要想象成一个由专家组成的专门团队在同一个办公室里协同工作。

该团队由四名成员组成：

三位语言专家（路由专家）：
- 有一位专家仅致力于 Haskell，一位仅致力于 OCaml，还有一位仅致力于 Scala。
- 他们如何工作： 当 AI 需要编写 Haskell 代码时，一位“经理”（称为路由器）会将任务仅发送给 Haskell 专家。这确保了 AI 不会意外混入 OCaml 的规则。这解决了“混淆”问题。
一位通用导师（共享专家）：
- 这是第四位专家，无论使用哪种语言，他/她始终处于激活状态。
- 他们做什么： 这位专家精通函数式编程的深层共享逻辑（例如“单子推理”，这是一种花哨的说法，意指“如何在逻辑链条中处理复杂步骤”）。
- 为何重要： 尽管专家们精通各自的特定语言，但他们可能会忘记函数式逻辑的通用规则。通用导师始终在那里轻声提醒：“记住，在函数式编程中，我们不改变事物；我们转换它们。”这确保了代码遵循正确的风格，而不仅仅是正确的语法。

为何这很重要

论文声称这种“团队方法”是效率的魔法：

小而强大： FPMoE 模型在执行任务时，每次仅“唤醒”约30 亿个参数（神经元）。
超越巨头： 尽管规模较小，但其表现与拥有 140 亿甚至 300 亿参数的庞大模型一样出色。
类比： 想象一个由三位专家和一位导师组成的小型、高度有序的团队，解决谜题的速度与一个由 30 人组成的庞大、混乱的人群一样快。

结果

在名为FPEval（测试 AI 编写函数式代码能力的基准测试）上进行测试时：

更高的准确率： FPMoE 编写的代码实际可运行的频率远高于之前的方法。
更好的风格： 它编写的代码不仅通过了测试，而且看起来就像是由人类函数式程序员编写的（避免了“命令式”习惯）。
效率： 它仅使用了大型模型所需计算资源的一小部分就取得了这些成果。

局限性（不足之处）

论文诚实地说明了该模型目前无法做到的事情：

固定团队： 该团队是硬编码为恰好三种语言（Haskell、OCaml、Scala）的。如果你想添加第四种语言（如 Clojure），你不能只是“雇佣”一位新专家；你必须从头重建整个团队。
内存： 尽管模型在任何时刻仅使用少量的脑力，但整个团队的知识必须一次性加载到计算机内存中，这对某些计算机来说可能负担较重。

总结

FPMoE 通过阻止 AI 试图成为一个困惑的通才，解决了 AI 在函数式编程方面挣扎的问题。相反，它赋予 AI 一个专门的团队：三位完美掌握各自特定语言的专家，以及一位确保他们都遵循函数式逻辑核心规则的导师。这使得一个小模型能够发挥出远超其体量的实力。

技术摘要：FPMoE——面向函数式代码生成的稀疏混合专家方法

1. 问题陈述

尽管大语言模型（LLMs）在代码生成领域取得了快速进展，但 Haskell、OCaml 和 Scala 等函数式编程语言（FPLs）仍长期未被充分探索。现有的前沿模型在函数式编程语言上的表现显著差于 Java 等命令式语言，生成的代码往往功能正确，却违背了惯用的函数式风格（例如，未能使用 Monad 或保持引用透明性）。

该论文指出了一种结构性的数据不平衡：函数式编程开发者社区规模较小，其产生的开源代码量比主流语言少几个数量级。因此，仅靠扩大预训练数据规模不足以缩小性能差距。

作者研究了微调作为解决方案，但发现标准方法存在两种截然不同的失效模式：

按语言微调：为每种语言单独训练模型，无法捕捉跨语言通用的函数式抽象（例如 Monad 推理）。
多语言微调：在混合语言语料上训练单个稠密模型，会引入跨语言干扰，降低各语言（尤其是 OCaml）的性能。

核心挑战在于如何同时保留语言特定的专业化能力与跨语言的通用泛化能力。

2. 方法论

作者提出了 FPMoE，这是一个基于稀疏混合专家（MoE）架构构建的轻量级开源代码生成模型。训练流程包含三个阶段：

2.1 数据收集与预处理

语料库：数据源自 CodeParrot GitHub 爬取数据和 OCaml 语料库，筛选出 Haskell、Scala 和 OCaml 仓库。
过滤：剔除行长过长的文件（自动生成的或混淆压缩的代码）。
去重：在仓库级别进行去重，以保持结构完整性。
去污染：通过 N-gram 过滤，排除训练数据中包含 FPEval 测试集中子串的内容。
序列构建：训练序列在仓库级别构建（拼接仓库中的所有源文件），而非文件级别，以保留仓库内的依赖关系和长程上下文。

2.2 专家预训练

在基础模型上并行执行两次监督微调（SFT）：

特定语言 SFT：基础模型分别在三个语言语料上独立微调，生成三个专业化检查点。
混合语言 SFT：单独实例在所有三个语料的并集上进行微调。这既作为稠密基线，也作为共享专家的初始化来源。

2.3 联合 MoE 微调

最终模型通过将 Transformer 骨干网络中的前馈网络（FFN）子层替换为专用的 MoE-FFN 块来组装：

路由专家：三个专家（ $E_1, E_2, E_3$ ）从特定语言检查点初始化。轻量级路由器使用 Top-K 选择（K=2）将 Token 分发给相应的语言专家。
共享专家：第四个专家（ $E_{shared}$ ）始终激活，无论路由决策如何。它从混合语言检查点初始化，以编码跨语言的函数式模式（例如类型导向编程）。
训练目标：组装后的模型在联合语料上进行联合训练，采用因果语言建模目标，并辅以辅助负载均衡损失以防止路由坍塌。

3. 主要贡献

问题分析：实证表明，标准微调策略（按语言 vs. 多语言）表现出互补的失效模式，无法通过稠密模型同时解决。
模型架构（FPMoE）：引入了一种稀疏 MoE 架构，明确将语言身份作为路由的归纳偏置。与以往的数据驱动 MoE 方法（如 Mixtral、DeepSeekMoE）不同，FPMoE 使用特定语言知识初始化路由专家，并采用专用的、始终激活的共享专家来捕捉跨语言抽象。
评估与分析：除了功能正确性外，作者还评估了FPViolation（对惯用风格的遵循程度）。他们提供了受控的消融研究，将架构带来的增益分解为语言对齐路由和共享专家的贡献。

4. 实验结果

实验在 FPEval 基准上进行（涵盖 Haskell、OCaml 和 Scala 的 721 个任务）。

性能与稠密基线对比：FPMoE 显著优于稠密微调基线。
- FPMoE-Qwen2.5-4x1.5B-A3B（30 亿激活参数）的 Pass@1 得分为：Haskell 7.37%，OCaml 6.8%，Scala 13.31%。这比其对应的 15 亿参数稠密模型提高了 5–11 倍。
- FPMoE-Qwen2.5-4x3B-A6B（60 亿激活参数）的得分为：Haskell 11.00%，OCaml 12.34%，Scala 21.08%。
参数效率：60 亿激活参数的 FPMoE 模型匹配或超越了更大的稠密模型，包括 DeepSeek-Coder-6.7B 和 Qwen2.5-Coder-14B，而其激活参数不到后者的一半。它还在 OCaml 和 Scala 上超越了 GPT-3.5。
惯用性：与更大的前沿模型相比，FPMoE 在正确性与遵循函数式风格之间取得了更好的平衡（FPViolation 率更低），后者常生成通过测试但违背函数式原则的命令式风格代码。

消融研究结果

共享专家初始化：从混合语言语料初始化共享专家（配置 A）至关重要。从通用基础模型初始化（配置 B）或冻结它（配置 C）会导致性能下降，有时甚至低于稠密基线。
共享专家的必要性：移除共享专家（配置 D）会降低性能，证实了其在捕捉跨语言抽象中的作用。
语言对齐路由：移除特定语言的预热（配置 E）会导致性能显著下降，特别是在 OCaml 上，证明路由器无法在没有归纳偏置的情况下仅凭数据发现专业化能力。

5. 意义与主张

该论文主张，针对性的架构专业化比暴力数据扩展为函数式代码生成提供了更原则性的路径。作者认为：

函数式编程语言的数据生态系统在结构上规模较小，不太可能增长到足以仅靠大规模预训练来支持。
在更大语料上训练的前沿模型仍表现出高比例的惯用性违规，表明仅靠数据扩展无法解决问题。
FPMoE 的设计通过将特定语言语法（通过路由专家）与共享函数式逻辑（通过共享专家）分离，有效地利用了可用的函数式编程语言 Token。

作者将 FPMoE 定位为降低函数式编程入门门槛的一步，但也承认了局限性，例如支持的语言集合固定、推理期间潜在的内存占用问题以及训练数据的时效性。