Resumen Técnico: Más allá de la tasa de aprobación: Una evaluación multilingüe y basada en la ejecución de los LLM de código abiertos

Declaración del Problema

Las evaluaciones actuales de los Modelos de Lenguaje Extensos (LLM) para la generación de código dependen frecuentemente de benchmarks compactos de un solo lenguaje y de tasas de aprobación agregadas (por ejemplo, pass@1). Los autores argumentan que estos resúmenes oscurecen dimensiones críticas del rendimiento del modelo, incluyendo la variabilidad entre lenguajes de programación, familias de problemas, niveles de dificultad y modos de falla específicos. Además, los benchmarks estándar a menudo no logran distinguir entre la corrección funcional y la mantenibilidad del código (calidad estática), y no capturan adecuadamente la naturaleza de los fallos (por ejemplo, errores sintácticos frente a semánticos). Este estudio aborda esta brecha proponiendo una evaluación a gran escala, basada en la ejecución, que preserva el flujo completo de generación a ejecución para revelar las compensaciones ocultas por las tablas de clasificación de métrica única.

Metodología

Construcción del Corpus

Los autores construyeron un benchmark utilizando 2,707 problemas de LeetCode gratuitos (no premium) para asegurar la reproducibilidad. El corpus abarca 12 lenguajes de programación: C, C++, C#, Go, Java, JavaScript, PHP, Python, Ruby, Scala, Swift y TypeScript.

• Escala: El estudio generó 325,343 trabajos de problema–modelo–lenguaje.
• Modelos: Se evaluaron nueve LLM de instrucción de código, accesibles abiertamente o de pesos abiertos, incluyendo Yi-Coder-9B-Chat, Qwen2.5-Coder-14B-Instruct, Gemma-2-27B-IT, DeepSeek-Coder-V2-Lite-Instruct, Codestral-22B-v0.1, Phi-4, Meta-Llama-3.1-8B-Instruct, Granite-3.1-8B-Instruct y Stable-Code-Instruct-3B.
• Preservación de Datos: Cada trabajo conserva el prompt, la respuesta bruta del modelo, el código extraído, el resultado de ejecución oficial de LeetCode y las señales de análisis estático.

Pipeline de Ejecución

1. Prompting: Se generaron prompts específicos para cada par problema–lenguaje.
2. Inferencia: Una cola de trabajos respaldada por un servidor distribuido gestionó la inferencia a través de modelos locales (alojados en LM Studio) para manejar la escala de más de 300,000 trabajos. Los errores operativos (red, tiempos de espera) se distinguieron de los fallos del modelo y se gestionaron mediante reintentos.
3. Extracción de Código: El post-procesamiento extrajo bloques de código de las respuestas del modelo (específicamente secciones de triples comillas) para servir como candidaturas de envío.
4. Evaluación: Un script de automatización en Python utilizó Selenium para enviar el código extraído al juez oficial de LeetCode. Los resultados se recuperaron vía GraphQL, capturando estados como Accepted (Aceptado), Wrong Answer (Respuesta Incorrecta), Compile Error (Error de Compilación), Runtime Error (Error de Ejecución), Time Limit Exceeded (Tiempo Límite Excedido) y Memory Limit Exceeded (Límite de Memoria Excedido).
5. Selección de Métricas: Para cada trabajo, se seleccionó la mejor entrega basándose en la mayor ratio de corrección, luego en el estado de aceptado, y finalmente en la marca de tiempo.
6. Análisis Estático: El estudio realizó análisis estático (linting) en los artefactos de código aceptados utilizando ast-grep y herramientas de estilo Pylint para medir la calidad del código, la complejidad y la adherencia a las convenciones.

Contribuciones Clave

1. Archivo a Gran Escala: La construcción de un archivo de ejecución reproducible que cubre 2,707 problemas, 12 lenguajes y 9 modelos, conteniendo más de 325,000 trabajos de ejecución.
2. Evaluación Multidimensional: Un marco de evaluación que va más allá de los puntajes agregados para analizar el rendimiento a través de la media de corrección, la cobertura de problemas aceptados, cortes de dificultad, cortes de lenguaje, categorías de temas, resultados comparativos directos (head-to-head) y composición de fallos.
3. Análisis Conjunto Funcional y Estático: Un análisis simultáneo de la corrección funcional y la calidad estática, demostrando que el éxito de ejecución y las señales orientadas a la mantenibilidad pueden divergir significablemente.

Resultados Experimentales

Rendimiento de los Modelos y Clasificaciones

• Corrección Media: Yi-Coder-9B-Chat logró la mayor corrección media (23.64%), seguido de Qwen2.5-Coder-14B-Instruct y Gemma-2-27B-IT. Sin embargo, todos los modelos permanecen muy por debajo de la línea base de aceptación humana del 57.2%.
• Cobertura de Problemas: Qwen2.5-Coder-14B-Instruct demostró la cobertura más amplia de problemas aceptados (77.1%), indicando que puede resolver una variedad más amplia de problemas distintos, incluso si su corrección promedio por trabajo es ligeramente inferior a la de Yi-Coder.
• Cortes de Dificultad: Las clasificaciones dependen de los cortes. Yi-Coder lidera en problemas fáciles y medios, mientras que Qwen2.5-Coder-14B-Instruct tiene el mejor desempeño en problemas difíciles.
• Cortes de Lenguaje: La calidad del modelo no es invariante al lenguaje. Yi-Coder es más fuerte en objetivos compilados/scripting convencionales (C++, Java, Python), Qwen es competitivo en C#, JavaScript, Ruby, Swift y TypeScript, y Gemma es más fuerte en Go y Scala.
• Cortes de Temas: Las clasificaciones varían según el tema. Por ejemplo, Yi-Coder es consistentemente fuerte en temas de alta frecuencia como arreglos y cadenas, mientras que Qwen lidera en categorías algorítmicas específicas.

Análisis de Fallos

• Modo de Fallo Dominante: Los errores de compilación representan el 63.25% de las mejores entregas no aceptadas. Esto indica que la mayoría de los fallos ocurren antes de que la corrección semántica pueda ser probada.
• Desplazamiento de Fallos: Los modelos más fuertes tienden a reducir la proporción de errores de compilación, exponiendo relativamente más casos de error de ejecución o de respuesta incorrecta.
• Corrección Parcial: El archivo muestra que los casos de respuesta incorrecta están concentrados en el grupo de cero por ciento de casos de prueba superados, con evidencia limitada de éxito de "casi acierto" intermedio.

Calidad Estática vs. Corrección Funcional

• Divergencia: La corrección funcional y la limpieza estática miden propiedades diferentes. Stable-Code-Instruct-3B logró la puntuación de calidad estructural más fuerte a pesar de tener el desempeño funcional más débil.
• Tasas de Paso de Lint: Gemma-2-27B-IT logró la mayor tasa de paso de lint en todos los lenguajes. Por el contrario, Qwen, a pesar de su fuerte desempeño de ejecución, pasó las reglas de lint con menos frecuencia.
• Tipos de Problemas: La carga del análisis estático está dominada por advertencias (141,376 hallazgos) y convenciones (45,537 hallazgos) más que por errores críticos. Los problemas de convención comunes incluyen using-namespace-std (48% de los hallazgos de convención) e importaciones de comodines. Los hallazgos de refactorización fueron raros (402 en total).

Significancia y Reivindicaciones

El artículo afirma que su significancia radica en demostrar que la evaluación multilingüe y de preservación de artefactos revela las compensaciones ocultas por las tablas de clasificación de un solo lenguaje o de una sola métrica.

• No hay un único mejor modelo: El "mejor" modelo depende enteramente del objetivo descendente. Si el objetivo es la corrección promedio, se prefiere Yi-Coder-9B-Chat; si el objetivo es la cobertura de problemas distintos o el éxito en tareas difíciles, Qwen2.5-Coder-14B-Instruct es superior; si el objetivo es minimizar la carga de revisión mediante código limpio, Gemma-2-27B-IT o Stable-Code-Instruct-3B pueden ser preferibles.
• Brechas de Fiabilidad: El estudio destaca que los modelos abiertos actuales están lejos de la fiabilidad de nivel humano, siendo los errores de compilación la barrera principal para la ejecución.
• Rigor de Evaluación: Los autores argumentan que la evaluación de los modelos de código debe preservar la ejecución, la cobertura de lenguaje, los modos de fallo y las señales de calidad. Confiar en una sola puntuación colapsa las dimensiones de rendimiento que son críticas para el despliegue práctico, como si un modelo produce código mantenible o si falla debido a la sintaxis en lugar de la lógica.

El artículo concluye que evaluar los LLM de generación de código requiere un cambio de identificar un único "ganador" a comprender cómo y por qué tienen éxito o fallan a través de diversos contextos de programación.