ClassEval-Pro: A Cross-Domain Benchmark for Class-Level Code Generation

Aquí se presenta un resumen técnico detallado del artículo "ClassEval-Pro: A Benchmark Transversal para la Generación de Código a Nivel de Clase".

1. Enunciado del Problema

Aunque los Modelos de Lenguaje Grandes (LLM) han logrado un gran éxito en la síntesis de código a nivel de función (por ejemplo, HumanEval, MBPP) y en la modificación de código a nivel de repositorio (por ejemplo, SWE-bench), persiste una brecha crítica en la creación de código composicional. Esto se refiere a la capacidad de construir una clase completa y estructuralmente interna a partir de una especificación, lo cual requiere coordinar múltiples métodos, gestionar un estado compartido e integrar lógica a través de dominios.

Las evaluaciones existentes no abordan esto de manera efectiva porque:

• Las evaluaciones a nivel de función prueban la síntesis de lógica aislada.
• Las evaluaciones a nivel de repositorio se centran en modificar bases de código existentes.
• Las evaluaciones previas a nivel de clase (por ejemplo, ClassEval) dependen de una curación manual, lo que las hace difíciles de escalar, costosas y cada vez más susceptibles a la contaminación de datos (entrenamiento con datos de prueba) debido a su antigüedad (versión de 2023).

2. Metodología: Construcción de ClassEval-Pro

Los autores presentan ClassEval-Pro, una evaluación compuesta por 300 tareas a nivel de clase a través de 11 dominios. La construcción se basa en una pipeline totalmente automatizada y resistente a la contaminación en tres etapas:

A. Recolección y Estructuración de Datos (Etapa 1)

• Fuente: Repositorios de Python de GitHub actualizados después de enero de 2025 para garantizar que los datos sean posteriores a los cortes de entrenamiento actuales de los LLM.
• Dominios: Cubre 11 dominios (por ejemplo, Finanzas, Redes, Seguridad, Desarrollo de Juegos).
• Estrategia de Composición:
  • Intra-Dominio: Fusión de clases dentro del mismo dominio (por ejemplo, SinglyLinkedList + Stack).
  • Trans-Dominio: Fusión de clases de diferentes dominios (por ejemplo, SQLQueryBuilder + PlayerInventory) para forzar una gestión compleja del estado y restricciones de interfaz.
• Filtrado: Un análisis AST estricto asegura que el código sea autocontenido (solo biblioteca estándar), tenga 5 o más métodos y entre 40 y 800 líneas de código.

B. Generación y Filtrado de Pruebas (Etapa 2)

• Generación de Esqueleto: Un LLM genera un esqueleto de clase basado en el código fusionado.
• Generación de Suite de Pruebas: Un LLM genera casos de prueba que coinciden con el esqueleto.
• Validación: Un Ensemble de Jueces LLM (tres jueces independientes) evalúa la compatibilidad entre el esqueleto y la suite de pruebas. Solo los pares que reciben la puntuación máxima de al menos dos jueces proceden.

C. Generación y Verificación de Soluciones (Etapa 3)

• Solución de Referencia: Un LLM separado genera el código completo de la solución.
• Verificación de Ejecución: Las soluciones se ejecutan en un entorno aislado. Para ser incluidas en la evaluación, una tarea debe:
  1. Aprobar todas las pruebas.
  2. Alcanzar una cobertura de líneas >90%.
  3. Completarse dentro de un tiempo de espera de 60 segundos.
• Salida Final: Un conjunto de datos de esqueletos de clase, suites de pruebas y soluciones de referencia verificadas.

3. Diseño Experimental

• Modelos Evaluados: Cinco LLM de vanguardia (GPT-5.1, Gemini-2.5-Pro, Qwen3-480B, Qwen3-30B, Kimi-K2).
• Estrategias de Generación: Se probaron cinco enfoques distintos:
  1. Holístico: Generación en un solo paso de toda la clase.
  2. Incremental: Generación iterativa de métodos en orden de declaración.
  3. Composicional: Generación independiente de importaciones, definiciones de clase y cuerpos de métodos, seguida de ensamblaje.
  4. Top-Down: Generación primero de métodos de alto nivel, luego de las dependencias.
  5. Bottom-Up: Generación primero de dependencias de bajo nivel, luego de métodos de alto nivel.
• Métricas: La métrica principal es Pass@k (Éxito Total a Nivel de Clase), con un análisis secundario sobre el éxito a nivel de método y el éxito parcial.

4. Resultados Clave

A. Dificultad de la Evaluación y Poder Discriminativo

• Dificultad: Las tareas de ClassEval-Pro son significativamente más difíciles que las evaluaciones anteriores, con jerarquías de dependencias más profundas (alcanzando un máximo de 3 capas frente a 1-2 en ClassEval) y una mayor diversidad semántica.
• Brecha de Rendimiento: El mejor modelo (Qwen3-480B) logró solo un 45.6% de Pass@1 (Éxito Total a Nivel de Clase). La brecha entre los modelos más fuertes y los más débiles fue de 17.7 puntos porcentuales, confirmando la capacidad de la evaluación para discriminar entre modelos de vanguardia.

B. Interacción Estrategia-Modelo

• Enfoques Estructurados Ayudan a Modelos Débiles: Para GPT-5.1, la estrategia Bottom-Up mejoró el Pass@1 en 9.4 puntos (de 27.9% a 37.3%) en comparación con el enfoque Holístico.
• La Generación Composicional Falla: La estrategia "Composicional" (generar partes de forma aislada) provocó un colapso del rendimiento, bajando hasta un 1.3% para Gemini-2.5-Pro. Esto resalta la dificultad de reensamblar fragmentos aislados en una clase coherente.
• Top-Down para Modelos Fuertes: Modelos más fuertes como Gemini-2.5-Pro se beneficiaron ligeramente de la planificación Top-Down, lo que sugiere que la planificación explícita de alto nivel ayuda a la consistencia global.

C. Análisis de Errores (Basado en 500 Fallos Anotados Manualmente)

• Errores Dominantes:
  • Errores Lógicos (56.2%): Implementaciones semánticamente incorrectas (por ejemplo, casos límite omitidos, tipos de excepción incorrectos).
  • Errores de Dependencia (38.0%): Fallos en la gestión del estado compartido, firmas de métodos o importaciones (por ejemplo, falta de import os).
  • Errores de Sintaxis: Despreciables (0.6%).
• Cuello de Botella Principal: El modo de fallo primario no es la formación del código, sino la coordinación entre métodos. Los modelos a menudo generan métodos individualmente correctos que no funcionan juntos debido a una gestión inconsistente del estado o interfaces rotas.

5. Contribuciones Clave

1. Evaluación ClassEval-Pro: Una evaluación escalable y transversal de 300 tareas diseñada específicamente para evaluar la creación de código composicional, yendo más allá de la síntesis de funciones aisladas.
2. Pipeline de Construcción Automatizada: Una pipeline novedosa y resistente a la contaminación que combina la fusión de código basada en AST, Ensembles de Jueces LLM y verificación estricta de ejecución para generar tareas de alta calidad y del mundo real sin curación manual.
3. Insights Diagnósticos: Identificación de la coordinación entre métodos como el principal cuello de botella en la generación a nivel de clase. El estudio revela que, aunque los modelos pueden escribir métodos locales, luchan con la consistencia global de la clase, la gestión del estado compartido y la coordinación de dependencias.

6. Significado

• Realismo: Al utilizar código de GitHub posterior a 2025 y composición trans-dominio, ClassEval-Pro ofrece una evaluación más realista de las capacidades de los LLM para tareas de ingeniería de software que las evaluaciones sintéticas a nivel de función.
• Futuras Direcciones: Los hallazgos sugieren que las futuras mejoras de los LLM para la generación de código deben centrarse menos en la sintaxis y más en el razonamiento arquitectónico, la gestión del estado y la coordinación de dependencias.
• Guía de Estrategia: Los resultados indican que las estrategias de generación deben adaptarse a las capacidades del modelo; la descomposición estructurada ayuda a los modelos más débiles, mientras que los enfoques holísticos o Top-Down pueden convenir mejor a los modelos más fuertes.

Los autores han hecho de código abierto la evaluación, la pipeline y los scripts de evaluación para facilitar la investigación adicional en esta área desatendida de la generación de código.