Resumen Técnico: DELULU – Una Métrica Multilingüe Verificada para la Detección de Alucinaciones en Código en Tareas de Relleno Intermedio

Enunciado del Problema

Los Modelos de Lenguaje Grandes (LLM) utilizados para la generación de código producen frecuentemente alucinaciones en tareas de Relleno Intermedio (FIM). Estas son completaciones que son sintácticamente válidas y semánticamente plausibles, pero fácticamente incorrectas, como métodos de API inventados, parámetros inválidos, variables no definidas o importaciones inexistentes. Aunque estos errores a menudo pasan una revisión de código superficial, introducen errores latentes en tiempo de ejecución que solo se manifiestan bajo condiciones de ejecución específicas.

Las métricas actuales para la generación de código (por ejemplo, HumanEval, MBPP) se centran principalmente en la generación a nivel de función a partir de especificaciones en lenguaje natural o carecen de verificación de ejecución para tareas FIM. Las métricas FIM existentes (por ejemplo, HumanEval Infilling, SAFIM) suelen ser exclusivas de Python, no distinguen entre tipos de errores y carecen de una verdad fundamental basada en ejecución para verificar que las alucinaciones realmente causen fallos en tiempo de ejecución. Además, no existe una evaluación sistemática de si los LLM de vanguardia pueden detectar estas alucinaciones de manera fiable al actuar como revisores de código.

Metodología: La Métrica DELULU

Los autores presentan DELULU, una métrica multilingüe verificada que comprende 1.951 muestras FIM en 7 lenguajes de programación (Python, Java, TypeScript, Go, Rust, C#, C++) y 4 categorías de alucinación. La métrica se construye mediante un pipeline adversarial riguroso de cinco etapas diseñado para garantizar dificultad, corrección y verificación de ejecución:

1. Generación de Alucinaciones: Utilizando CLAUDE SONNET como único generador, el sistema crea variantes "alucinadas" de completaciones óptimas extraídas de repositorios reales de GitHub. El generador está restringido a modificar exactamente un elemento (nombre de método, parámetro, variable o importación) mientras mantiene el resto del código idéntico, asegurando que la alucinación sea plausible e indistinguible del código real en la superficie.
2. Evaluación por Jueces de Múltiples Modelos: Cuatro LLM de vanguardia diversos (GPT-5.1, GPT-5.2, GPT-5.2-CODEX, GLM-4.7) evalúan independientemente los pares.
3. Muestreo Adversarial Iterativo: El pipeline analiza los desacuerdos de los jueces y utiliza agrupación basada en incrustaciones para extraer nuevos ejemplos de código semánticamente similares que se asemejen a los modos de fallo de los jueces. Este bucle se ejecuta durante tres iteraciones, exponiendo progresivamente muestras más difíciles a medida que disminuye la precisión de los jueces con el tiempo.
4. Selección Basada en Dificultad: Las muestras se puntúan según su capacidad para engañar a los jueces. Solo se retienen las muestras lo suficientemente difíciles como para engañar al menos a un juez (o causar un rechazo excesivo de código óptimo).
5. Verificación de Ejecución Basada en Docker: Este es el diferenciador crítico. Cada muestra se empaqueta en un contenedor Docker autocontenido.
   • La completación óptima debe compilarse y ejecutarse sin errores.
   • La completación alucinada debe producir un error de tiempo de ejecución específico y verificable correspondiente a su categoría:
     • Método: AttributeError
     • Parámetro: TypeError
     • Variable no definida: NameError
     • Importación: ImportError
   • Un bucle de corrección asistido por CLAUDE SONNET resuelve problemas de dependencias para asegurar el éxito de la verificación.
6. Revisión por Expertos Humanos: Un panel de tres expertos humanos revisa las muestras verificadas por Docker para eliminar sesgos residuales, casos triviales o errores de etiquetado, resultando en el conjunto de datos final de 1.951 muestras.

Contribuciones Clave

1. Taxonomía de Alucinaciones de Cuatro Categorías: Una taxonomía estructurada donde cada categoría (Método, Parámetro, Variable no definida, Importación) se mapea a una clase distinta y verificable de error en tiempo de ejecución, permitiendo una verdad fundamental basada en ejecución.
2. Pipeline de Curación Adversarial: Un proceso novedoso de cinco etapas que empareja código del mundo real con contrapartes alucinadas, filtra casos triviales mediante sondeo de múltiples modelos y asegura la verificación basada en ejecución.
3. Conjunto de Datos Multilingüe Verificado por Ejecución: 1.951 muestras en 7 idiomas, cada una empaquetada como un contenedor Docker autocontenido con tres modos de invocación (verificar óptimo, verificar alucinado, verificar parche).
4. Evaluación Exhaustiva: Una evaluación de 11 modelos FIM de peso abierto de 5 familias (Qwen2.5-Coder, CodeLlama, DeepSeek-Coder-V2, StarCoder2) que abarcan desde 0.5B hasta 32B parámetros.
5. Estudio de Detección por Jueces de Vanguardia: Una evaluación de 8 LLM de vanguardia actuando como revisores de código para detectar alucinaciones, revelando brechas significativas en las capacidades de detección.

Resultados

Rendimiento de Generación

• Límites de Escalado: El modelo más fuerte, Qwen2.5-Coder-32B, logró solo un 84.5% de pass@1 en los 950 contextos FIM únicos. Esto indica que incluso con 32B parámetros, los modelos fallan en aproximadamente uno de cada siete contextos únicos.
• Consistencia Transversal de Familias: La dificultad es intrínseca a la tarea, no específica de una familia de modelos. Ningún modelo transversal superó una Similitud de Edición de 0.77. Incluso el mejor modelo transversal (DeepSeek-Coder-V2-Lite-Instruct) quedó por detrás del mejor modelo Qwen en 1.8 puntos de pass@1.
• Tipos de Alucinación: Las alucinaciones de importación fueron consistentemente la categoría más difícil en todos los tamaños de modelo e idiomas (por ejemplo, 77.1% de pass@1 para Qwen-32B en importaciones frente a >85% en otros tipos), lo que sugiere que detectar importaciones falsas requiere conocimiento específico del ecosistema y no solo la finalización de patrones locales.
• Ajuste por Instrucciones: El ajuste por instrucciones mejoró significativamente el comportamiento de "detener" (Coincidencia Exacta), pero tuvo un impacto mínimo en el conocimiento subyacente necesario para evitar alucinar identificadores (la Similitud de Edición y CodeBLEU permanecieron similares entre los modelos base y los de instrucción).

Rendimiento de Detección

• Detección No Resuelta: Incluso el modelo juez más fuerte, Claude-4.5-Opus, logró solo un 92.1% de precisión en ambos correctos (aceptar correctamente el óptimo y rechazar el alucinado).
• Brecha de Detección: Los jueces más pequeños tuvieron un rendimiento significativamente peor (por ejemplo, GPT-4o-mini con 52.3%), estableciendo un rango de capacidad de 40 puntos.
• Cuello de Botella de Importación: La detección de alucinaciones de importación siguió siendo la tarea más difícil para todos los jueces (83.4% para Opus), confirmando que distinguir entre nombres de paquetes reales y falsos es una brecha de capacidad persistente.
• Falsos Negativos: El principal cuello de botella para los jueces fue rechazar las completaciones alucinadas, no aceptar las óptimas.

Significado y Afirmaciones

El artículo afirma que DELULU aborda una brecha crítica en la evaluación de código al proporcionar la primera métrica que ofrece simultáneamente:

1. Categorización sistemática de alucinaciones con tipos detallados.
2. Cobertura multilingüe más allá de Python.
3. Verificación basada en ejecución que asegura que las alucinaciones produzcan errores reales en tiempo de ejecución.
4. Calibración de dificultad adversarial que garantiza que la métrica sea genuinamente desafiante.

Los autores enfatizan que la dificultad expuesta por DELULU es intrínseca a la tarea y no específica de la familia, como lo demuestran las tasas de fallo consistentes en diversas arquitecturas de modelos. Los resultados sugieren que simplemente escalar los parámetros del modelo es insuficiente para resolver la alucinación de código; es probable que sean necesarias intervenciones dirigidas, como la curación de datos de entrenamiento y el ajuste fino estilo verificador.

El artículo posiciona a DELULU no solo como una métrica de generación, sino como una herramienta reutilizable para evaluar modelos de revisión de código y verificadores, destacando que la capacidad de detectar alucinaciones es actualmente un problema no resuelto incluso para los modelos de vanguardia. La métrica se publica como un artefacto solo para pruebas para evitar la contaminación, y los autores desalientan explícitamente el ajuste fino sobre el conjunto de datos.