Resumen Técnico: FPMoE – Un Enfoque de Mezcla de Expertos Escasa para la Generación de Código Funcional

1. Declaración del Problema

A pesar de los rápidos avances en los Modelos de Lenguaje Grandes (LLM) para la generación de código, los lenguajes de programación funcional (FPL) como Haskell, OCaml y Scala siguen siendo crónicamente poco explorados. Los modelos de vanguardia existentes desempeñan significativamente peor en FPL en comparación con lenguajes imperativos como Java, generando a menudo código que es funcionalmente correcto pero que viola el estilo funcional idiomático (por ejemplo, no utilizando mónadas o transparencia referencial).

El documento identifica un desequilibrio estructural en los datos: la comunidad de desarrolladores de FPL es pequeña, produciendo órdenes de magnitud menos código de código abierto que los lenguajes principales. En consecuencia, escalar únicamente los datos de pre-entrenamiento es insuficiente para cerrar la brecha de rendimiento.

Los autores investigan el ajuste fino como remedio, pero encuentran dos modos de fallo distintos en los enfoques estándar:

1. Ajuste fino por lenguaje: Entrenar modelos separados para cada lenguaje no logra capturar abstracciones funcionales compartidas (por ejemplo, razonamiento monádico) que se generalizan entre lenguajes.
2. Ajuste fino multilingüe: Entrenar un único modelo denso sobre una mezcla de lenguajes introduce interferencia entre lenguajes, degradando el rendimiento en lenguajes individuales (particularmente en OCaml).

El desafío central es preservar simultáneamente la especialización específica de cada lenguaje y la generalización compartida entre lenguajes.

2. Metodología

Los autores proponen FPMoE, un modelo ligero y de código abierto para la generación de código basado en una arquitectura de Mezcla de Expertos (MoE) escasa. La tubería de entrenamiento consta de tres etapas:

2.1 Recopilación y Preprocesamiento de Datos

• Corpus: Los datos se obtienen del rastreo de GitHub de CodeParrot y del Corpus de OCaml, filtrados para repositorios de Haskell, Scala y OCaml.
• Filtrado: Se descartan archivos con longitudes de línea excesivas (código generado automáticamente/minificado).
• Deduplicación: Se realiza a nivel de repositorio para mantener la integridad estructural.
• Descontaminación: El filtrado de n-gramas excluye datos de entrenamiento que contienen subcadenas encontradas en el conjunto de pruebas FPEval.
• Construcción de Secuencias: Las secuencias de entrenamiento se construyen a nivel de repositorio (concatenando todos los archivos fuente en un repositorio) en lugar de a nivel de archivo, para preservar las dependencias intra-repositorio y el contexto de largo alcance.

2.2 Pre-entrenamiento de Expertos

Se realizan dos ejecuciones paralelas de ajuste fino supervisado (SFT) sobre un modelo base:

1. SFT específico por lenguaje: El modelo base se ajusta fino independientemente en cada uno de los tres corpus de lenguajes, creando tres puntos de control especializados.
2. SFT multilingüe mixto: Una instancia separada se ajusta fino sobre la unión de los tres corpus. Esto sirve tanto como línea base densa como inicialización para el experto compartido.

2.3 Ajuste Fino Conjunto MoE

El modelo final se ensambla reemplazando las subcapas de la Red de Alimentación Adelante (FFN) del núcleo transformador con un bloque MoE-FFN especializado:

• Expertos Enrutados: Tres expertos ($E_1, E_2, E_3$) se inicializan a partir de los puntos de control específicos por lenguaje. Un enrutador ligero utiliza selección Top-K (K=2) para despachar tokens al experto de lenguaje apropiado.
• Experto Compartido: Un cuarto experto ($E_{shared}$) está siempre activo, independientemente de la decisión de enrutamiento. Se inicializa a partir del punto de control multilingüe mixto para codificar patrones funcionales entre lenguajes (por ejemplo, programación dirigida por tipos).
• Objetivo de Entrenamiento: El modelo ensamblado se entrena conjuntamente sobre el corpus combinado utilizando un objetivo de modelado de lenguaje causal aumentado con una pérdida auxiliar de equilibrio de carga para prevenir el colapso del enrutamiento.

3. Contribuciones Clave

1. Análisis del Problema: Una demostración empírica de que las estrategias estándar de ajuste fino (por lenguaje frente a multilingüe) exhiben modos de fallo complementarios que no pueden resolverse simultáneamente mediante modelos densos.
2. Arquitectura del Modelo (FPMoE): La introducción de una arquitectura MoE escasa que incorpora explícitamente la identidad del lenguaje como un sesgo inductivo para el enrutamiento. A diferencia de enfoques MoE basados en datos previos (por ejemplo, Mixtral, DeepSeekMoE), FPMoE inicializa los expertos enrutados con conocimiento específico de cada lenguaje y emplea un experto compartido dedicado y siempre activo para capturar abstracciones entre lenguajes.
3. Evaluación y Análisis: Más allá de la corrección funcional, los autores evalúan la ViolaciónFP (adherencia al estilo idiomático). Proporcionan un estudio de ablación controlado que descompone las ganancias de la arquitectura en contribuciones del enrutamiento alineado con el lenguaje y del experto compartido.

4. Resultados Experimentales

Los experimentos se realizaron en el punto de referencia FPEval (721 tareas en Haskell, OCaml y Scala).

• Rendimiento frente a Líneas Base Densas: FPMoE supera sustancialmente a las líneas base ajustadas finamente densas.
  • El FPMoE-Qwen2.5-4x1.5B-A3B (3B de parámetros activos) logra puntuaciones Pass@1 de 7.37% (Haskell), 6.8% (OCaml) y 13.31% (Scala). Esto representa una mejora de 5 a 11 veces sobre su contraparte densa de 1.5B.
  • El FPMoE-Qwen2.5-4x3B-A6B (6B de parámetros activos) logra 11.00% (Haskell), 12.34% (OCaml) y 21.08% (Scala).
• Eficiencia de Parámetros: El modelo FPMoE de 6B de parámetros activos iguala o supera a modelos densos mucho más grandes, incluidos DeepSeek-Coder-6.7B y Qwen2.5-Coder-14B, activando menos de la mitad de sus parámetros. También supera a GPT-3.5 en OCaml y Scala.
• Idiomaticidad: FPMoE demuestra un mejor equilibrio entre corrección y adherencia al estilo funcional (tasas más bajas de ViolaciónFP) en comparación con modelos de vanguardia más grandes, que a menudo generan código de estilo imperativo que pasa las pruebas pero viola principios funcionales.

Hallazgos del Estudio de Ablación

• Inicialización del Experto Compartido: Inicializar el experto compartido a partir de un corpus multilingüe mixto (Configuración A) es crítico. Inicializarlo a partir de un modelo base general (Configuración B) o congelarlo (Configuración C) resulta en caídas de rendimiento, a veces por debajo de las líneas base densas.
• Necesidad del Experto Compartido: Eliminar el experto compartido (Configuración D) reduce el rendimiento, confirmando su papel en la captura de abstracciones entre lenguajes.
• Enrutamiento Alineado con el Lenguaje: Eliminar la calibración específica por lenguaje (Configuración E) causa una caída significativa en el rendimiento, particularmente en OCaml, demostrando que el enrutador no puede descubrir la especialización puramente a partir de datos sin el sesgo inductivo.

5. Significado y Afirmaciones

El documento afirma que la especialización arquitectónica dirigida ofrece un camino más principista para la generación de código funcional que el escalado de datos a fuerza bruta. Los autores argumentan que:

• El ecosistema de datos de FPL es estructuralmente pequeño y es poco probable que crezca lo suficientemente rápido como para apoyar únicamente el pre-entrenamiento masivo.
• Los modelos de vanguardia entrenados en corpus más grandes aún exhiben altas tasas de violaciones idiomáticas, lo que sugiere que el escalado de datos por sí solo no resuelve el problema.
• El diseño de FPMoE utiliza eficazmente los tokens de FPL disponibles separando la sintaxis específica de cada lenguaje (mediante expertos enrutados) de la lógica funcional compartida (mediante el experto compartido).

Los autores posicionan a FPMoE como un paso hacia la reducción de la barrera de entrada para la programación funcional, aunque reconocen limitaciones como el conjunto fijo de lenguajes soportados, posibles problemas de huella de memoria durante la inferencia y la recencia de los datos de entrenamiento.