OODEval: Evaluating Large Language Models on Object-Oriented Design

Este artículo presenta OODEval, un nuevo benchmark y métricas unificadas para evaluar la capacidad de diseño orientado a objetos de 29 modelos de lenguaje grande, revelando que, aunque algunos modelos alcanzan un rendimiento cercano al de estudiantes universitarios, aún presentan deficiencias semánticas significativas y están muy por debajo del nivel de los diseñadores humanos expertos.

Lo esencial

¡Claro que sí! Imagina que los Modelos de Lenguaje Grandes (LLMs), como los que usan ChatGPT o Gemini, son como estudiantes universitarios superdotados que han leído casi todos los libros de programación del mundo. Saben escribir código (como Python o Java) muy bien, pero en este estudio nos preguntamos: ¿Son capaces de diseñar la arquitectura completa de un edificio de software antes de poner un solo ladrillo?

Esa es la esencia del trabajo "OODEval". Aquí te lo explico como si fuera una historia, usando analogías sencillas.

1. El Problema: El Arquitecto que no dibuja planos

Hasta ahora, hemos evaluado a estos "estudiantes de IA" viendo si pueden escribir una línea de código correcta (como decir "hola mundo"). Pero en el mundo real del software, antes de programar, necesitas un Diseño Orientado a Objetos (OOD).

Imagina que quieres construir un hospital.

• Código: Es poner los ladrillos y encender las luces.
• Diseño (OOD): Es el plano arquitectónico. Define dónde van las habitaciones, cómo se conectan los pasillos, qué tipo de puertas hay y cómo se relacionan los médicos con los pacientes.

El problema es que nadie había creado un examen serio para ver si la IA sabe dibujar esos planos. Los exámenes anteriores eran como pedirle a la IA que escribiera una frase, no que diseñara un edificio entero.

2. La Solución: OODEval (El Nuevo Examen)

Los autores crearon OODEval, que es como un banco de exámenes de arquitectura de software.

• 50 Retos: Tienen 50 problemas diferentes, desde "diseña una cafetería sencilla" (nivel fácil) hasta "diseña un sistema de tráfico aéreo complejo" (nivel difícil).
• OODEval-Human (El Grupo de Control): Para saber si la IA es buena, necesitan compararla con humanos. Recopilaron 940 diseños hechos por estudiantes universitarios reales, calificados por sus profesores. Es como tener un "promedio de clase" para comparar.

3. La Regla del Juego: CLUE (El Ojo Clínico)

¿Cómo se califica un plano? No basta con que se vea bonito.

• Antes, usaban reglas simples (como contar palabras iguales), lo cual es como calificar un dibujo de un perro solo por si tiene cuatro patas, sin importar si las patas están en la cabeza.
• Aquí crearon CLUE (Evaluación Unificada de Similitud de Clases). Imagina que CLUE es un arquitecto inspector robot muy inteligente. No solo mira si los nombres son iguales, sino que entiende la semántica:
  • ¿El "médico" está conectado al "paciente" correctamente?
  • ¿La "agregación" (una parte de un todo) está bien definida?
  • ¿Los métodos (las acciones) tienen sentido?

Este "inspector robot" aprendió a calificar comparando sus notas con las de los profesores humanos, y ¡funciona muy bien!

4. Los Resultados: ¿Quién gana la carrera?

Evaluaron a 29 modelos de IA diferentes (desde los pequeños y rápidos hasta los gigantes) y los compararon con los estudiantes.

• La IA es excelente en la gramática, pero mala en el significado:

  • Analogía: La IA puede escribir un plano con la tinta perfecta, sin manchas, y todas las líneas rectas (100% correcto gramaticalmente). Pero a veces pone una cocina donde debería ir un baño, o conecta el ascensor con el techo en lugar de con los pisos.
  • Hallazgo: Son muy buenos escribiendo el "esqueleto" (clases y atributos), pero fallan mucho al definir qué hacen (métodos) y cómo se relacionan las cosas (relaciones).

• La IA vs. El Estudiante Promedio:

  • Los mejores modelos de IA hoy en día están al nivel de un estudiante universitario promedio. Pueden hacer un trabajo decente, pero no son expertos.
  • Sin embargo, están muy lejos de los mejores diseñadores humanos. Si el estudiante promedio saca un 8/10, la IA saca un 7.5, pero el experto humano saca un 9.9.

• El Campeón:

  • El modelo Qwen3-Coder-30B (un modelo de código especializado) fue el mejor.
  • Curiosamente, un modelo pequeño y local llamado Gemma3-4B-IT (que cabe en una computadora normal) superó a gigantes de pago como GPT-4o Mini. ¡Es como si un estudiante de bachillerato con una calculadora simple superara a un profesor con un superordenador en un examen específico!

5. ¿Qué afecta el rendimiento? (Los "Villanos" del diseño)

El estudio descubrió qué hace que la IA se equivoque más:

• Complejidad: Cuantos más "habitaciones" (clases) y "pasillos" (relaciones) tenga el diseño, peor le va a la IA.
• Lectura difícil: Si las instrucciones del problema están escritas en un lenguaje muy complicado, la IA se pierde.
• Tipos de relaciones: A la IA le cuesta mucho entender la "herencia" (cuando una clase es un tipo especial de otra), como confundir a un "perro" con un "animal".

6. ¿Por qué nos importa esto? (Lecciones para el futuro)

1. Para los Desarrolladores: No confíes ciegamente en la IA para diseñar sistemas complejos. Úsala como un asistente que te da un borrador, pero siempre revisa los planos tú mismo.
2. Para las Universidades: ¡Cuidado! Como la IA puede hacer el trabajo de un estudiante promedio, los profesores deben cambiar sus exámenes. En lugar de pedir "diseña un sistema", deben pedir "explica por qué diseñaste así" o hacer exámenes en vivo. La IA puede hacer el trabajo sucio, pero no puede "pensar" como un ingeniero.
3. Para el Futuro: Necesitamos entrenar a estas IAs para que entiendan mejor las "relaciones" y los "métodos", no solo la estructura básica.

En resumen

Este paper nos dice que la IA en diseño de software es como un aprendiz muy rápido y con buena caligrafía, pero que a veces no entiende la lógica de la construcción. Ha dado un gran salto, pero aún necesita aprender a pensar como un arquitecto experto, no solo como un redactor de planos. Y lo mejor de todo: ¡ahora tenemos una regla y un examen para medir su progreso!

Resumen técnico

Resumen Técnico: OODEval

1. El Problema

A pesar de los avances significativos de los Modelos de Lenguaje Grande (LLMs) en tareas de ingeniería de software, la evaluación actual se centra predominantemente en la generación de código a nivel de sintaxis (ej. completar funciones) y en la gestión de calidad. Existe una brecha crítica en la evaluación de las capacidades de los LLMs en la fase de diseño de software, específicamente en el Diseño Orientado a Objetos (OOD).

Las limitaciones principales que impiden una evaluación rigurosa en este dominio son:

• Falta de benchmarks estandarizados: La mayoría de los estudios anteriores se basan en casos de estudio aislados o conjuntos de datos no públicos, simples o presentados como imágenes (no procesables automáticamente).
• Ausencia de métricas automáticas adecuadas: Las métricas tradicionales (como BLEU) fallan al capturar la estructura topológica y la semántica de los diagramas de clases. Las métricas basadas en embeddings (como BertScore) capturan la semántica general pero ignoran detalles finos como atributos, métodos y relaciones específicas.
• Desconocimiento del rendimiento real: No se sabe con certeza cómo se comparan los LLMs con diseñadores humanos (estudiantes universitarios) en tareas complejas de diseño, ni qué factores (tamaño del modelo, tipo de entrenamiento) influyen en su éxito.

2. Metodología

Los autores proponen un marco de evaluación integral que consta de tres pilares fundamentales:

A. Construcción de Benchmarks (OODEval y OODEval-Human)

• OODEval: Un conjunto de datos manual de 50 tareas de diseño orientado a objetos, que van desde requisitos en lenguaje natural hasta diagramas de clases en formato PlantUML. Las tareas están estratificadas en tres niveles de dificultad (simple, moderado, difícil) basados en métricas como número de clases, métodos, relaciones y legibilidad del texto (Flesch-Kincaid).
• OODEval-Human: El primer benchmark con calificación humana. Contiene 940 soluciones enviadas por estudiantes de pregrado para 4 de las tareas de OODEval, junto con las calificaciones de los instructores. Esto permite comparar directamente el rendimiento de los LLMs con el de humanos y validar las nuevas métricas.

B. Nueva Métrica de Evaluación: CLUE (Class Likeness Unified Evaluation)
Para superar las limitaciones de las métricas existentes, se propone CLUE, un conjunto de métricas automáticas que evalúan la similitud estructural y semántica entre un diagrama de referencia y uno candidato.

• Enfoque: Utiliza el modelo CodeBERT para generar embeddings semánticos y el algoritmo de Hungría para encontrar la correspondencia óptima entre elementos (clases, atributos, métodos, relaciones).
• Granularidad: CLUE evalúa globalmente el diagrama y localmente sus componentes (clue-class, clue-attribute, clue-method, clue-relation).
• Validación: Se optimizaron los pesos de CLUE mediante optimización bayesiana para maximizar la correlación con las calificaciones humanas en OODEval-Human, logrando una correlación de Pearson de 0.59, superando significativamente a BLEU, CodeBERTScore y NINHS.

C. Estudio Empírico
Se evaluaron 29 LLMs diversos (incluyendo series Llama, CodeLlama, Gemma, Qwen, DeepSeek y GPT) en las 50 tareas de OODEval. El estudio abordó cinco preguntas de investigación (RQs):

1. Correctitud general.
2. Comparación con humanos.
3. Análisis de dimensiones del modelo (tamaño, especialización, fine-tuning).
4. Análisis de características de la tarea.
5. Análisis de casos de fallo (bad cases).

3. Contribuciones Clave

1. OODEval Benchmark: Un dataset público, manual y diverso de 50 tareas de OOD con múltiples niveles de dificultad.
2. OODEval-Human Dataset: Un conjunto de datos único con soluciones humanas y calificaciones, esencial para la validación de métricas y la comparación LLM-Humano.
3. Métricas CLUE: Una nueva familia de métricas automáticas que integran estructura y semántica, validadas como altamente correlacionadas con la evaluación humana.
4. Estudio Empírico Exhaustivo: La primera evaluación a gran escala de 29 LLMs en tareas de diseño OOD, proporcionando insights sobre sus fortalezas, debilidades y patrones de error.

4. Resultados Principales

• Sintaxis vs. Semántica: Los LLMs muestran una alta corrección sintáctica (Pass@1 > 80% para la mayoría), pero sufren deficiencias significativas en la corrección semántica. La puntuación CLUE es consistentemente >10% menor que la sintáctica.
• Debilidades Específicas: Los modelos tienen dificultades notables en la generación de métodos y relaciones entre clases, especialmente en tareas difíciles. La generación de nombres de clases y atributos es más robusta.
• Rendimiento de Modelos:
  • Qwen3-Coder-30B obtuvo el mejor rendimiento general, equilibrando todas las dimensiones.
  • Modelos locales como Llama3.1-70B-IT y Gemma3-IT (incluso la versión de 4B) compiten o superan a modelos cerrados como GPT-4o-mini.
  • Los modelos Code-specific (entrenados en código) superan consistentemente a los modelos de propósito general.
  • El Instruction Tuning mejora drásticamente el rendimiento, mientras que la capacidad de "razonamiento" (RLMs) no mostró ventajas claras en esta tarea.
• Comparación Humano-LLM:
  • El promedio de los LLMs está muy por debajo del promedio de los estudiantes universitarios.
  • Sin embargo, los mejores LLMs (top-tier) alcanzan un rendimiento cercano al promedio humano (diferencia <5%), aunque siguen muy por debajo del rendimiento de los humanos expertos (los mejores estudiantes).
• Factores de Influencia:
  • El rendimiento disminuye a medida que aumenta el número de clases, métodos y relaciones, y la complejidad de las relaciones de generalización.
  • La legibilidad del texto de los requisitos impacta negativamente en la extracción de métodos.
• Modos de Fallo Comunes: Los errores más frecuentes son omisión de palabras clave, clases faltantes, relaciones faltantes y omisión de métodos. Los modelos como DeepSeek y GPT series muestran una diversidad de errores menor.

5. Significado e Implicaciones

• Para la Investigación y Desarrollo: Se establece un estándar para evaluar el diseño de software con IA. Se sugiere que el futuro de los LLMs en OOD requiere un enfoque en la comprensión semántica de relaciones y métodos, y el uso de modelos grandes especializados en código con fine-tuning.
• Para la Selección de Modelos:
  • Para despliegue local con recursos: Qwen3-Coder-30B.
  • Para recursos limitados: Gemma3-4B-IT (excelente relación costo-rendimiento).
  • Para producción en la nube: DeepSeek-R1 (alto rendimiento y bajo costo).
• Para la Educación en Ingeniería de Software:
  • Riesgo Académico: Dado que los LLMs más avanzados pueden igualar el rendimiento promedio de un estudiante, existe un riesgo alto de plagio y deshonestidad académica en asignaciones de diseño. Se recomienda evaluar procesos (defensas orales, demostraciones) en lugar de solo el producto final.
  • Oportunidad Educativa: Los docentes deben guiar el uso responsable de la IA para fomentar el pensamiento crítico y la exploración de diseños, transformando la herramienta de riesgo en un apoyo para el aprendizaje.

En conclusión, OODEval cierra la brecha en la evaluación de LLMs para el diseño de software, revelando que, aunque la tecnología ha avanzado hasta niveles competentes para tareas promedio, aún requiere mejoras significativas en la complejidad semántica y estructural para igualar a los expertos humanos.