Resumen Técnico: Evaluación de la Mejora de Código con Retroalimentación Progresiva, Adaptativa e Interactiva

1. Planteamiento del Problema

La evaluación actual de los Modelos de Lenguaje de Gran Escala (LLM) para la generación de código y la reparación automática de programas (APR) depende en gran medida de métricas binarias de aprobado/reprobado determinadas por suites de pruebas. Los autores argumentan que este enfoque es tosco y engañoso por varias razones:

• Esparcidad de la Información: Un resultado binario ignora el progreso parcial, tratando igual una solución que corrige un caso de borde que una que falla en todas las pruebas.
• Inflación del Rendimiento: Las suites de pruebas débiles pueden permitir que los modelos aprueben mediante ediciones superficiales que corrigen fallos reportados pero introducen regresiones sutiles.
• Negligencia de las Trayectorias de Refinamiento: En flujos de trabajo iterativos donde los modelos refinan el código basándose en retroalimentación (errores de compilación, trazas de ejecución o diagnósticos), la evaluación típicamente solo considera el resultado final. Esto no logra capturar si un modelo utiliza la retroalimentación de manera efectiva, si generaliza las reparaciones o si mantiene el comportamiento previamente correcto.
• Variabilidad No Controlada de la Retroalimentación: Los benchmarks interactivos existentes suelen carecer de control sobre la retroalimentación proporcionada. La capacidad informativa de la retroalimentación (por ejemplo, revelar la causa raíz frente a un síntoma vago) puede variar drásticamente entre ejecuciones, lo que dificulta distinguir entre la capacidad del modelo y la calidad de la retroalimentación.

El artículo postula que evaluar la capacidad de un modelo para realizar progreso mediante el refinamiento guiado por retroalimentación ofrece una medida más detallada y fiel de la utilidad en el mundo real que las tasas estáticas de aprobado/reprobado.

2. Metodología: PAIR-BENCH

Para abordar estas limitaciones, los autores introducen PAIR-BENCH, un benchmark progresivo y adaptativo para evaluar la mejora de código. La innovación central es un protocolo de Sugerencias Progresivas (Progressive Hinting) que controla la retroalimentación a lo largo de dos dimensiones:

A. Componentes Principales

1. Constructor de Escenarios (Control de la Región de Fallo):
   • Los casos de prueba fallidos ocultos se agrupan en escenarios de fallo basados en una "firma de fallo" que comprende:
     • Traza de ejecución de referencia (líneas de código fuente ejecutadas).
     • Forma estructural de la salida esperada (output shape).
     • Tipo de fallo candidato (p. ej., tiempo de espera agotado, valor incorrecto).
   • Esto agrupa comportamientos incorrectos relacionados, permitiendo que el benchmark se dirija a regiones específicas del espacio de fallo en lugar de a casos de prueba arbitrarios.
2. Generador de Sugerencias (Control de la Profundidad de la Sugerencia):
   • Inspirado en la Teoría de Respuesta al Ítem (IRT) y el andamiaje educativo, las sugerencias se generan en uno de los seis niveles de informatividad creciente:
     • L1 (Síntoma): Solo el comportamiento incorrecto observado.
     • L2 (Patrón de Entrada): La condición de entrada que expone el fallo.
     • L3 (Seguimiento de Estado): El estado o la lógica faltante que la solución no logra preservar.
     • L4 (Localización de la Falla): Regiones de código sospechosas.
     • L5 (Corrección Conceptual): Invariantes o razonamientos faltantes.
     • L6 (Dirección de la Reparación): Guía de implementación concreta sin código.
   • Un modelo de retroalimentación (separado del modelo candidato) genera las sugerencias restringidas por estos niveles para evitar la filtración de información.
3. Política Adaptativa:
   • Progresiva: El benchmark itera a través de distintos escenarios de fallo, priorizando aquellos con la mayor cobertura de pruebas fallidas.
   • Adaptativa: La profundidad de la sugerencia se ajusta según el rendimiento del modelo. Si un modelo repara un escenario usando una sugerencia superficial, el siguiente escenario comienza con una sugerencia más débil (desvanecimiento de la asistencia). Si el modelo falla, la profundidad de la sugerencia aumenta (escalada de guía).
4. Evaluador de Trayectoria:
   • En lugar de una única puntuación binaria, el benchmark rastrea la trayectoria de reparación a través de los turnos, midiendo el progreso en cada paso.

B. Métricas de Evaluación

El artículo propone un conjunto de métricas centradas en el progreso:

• Tasa de Reparación Inicial: Capacidad de reparación sin ayuda.
• Éxito de Reparación Dirigida (TRS): Capacidad de reparar el escenario específico descrito por la sugerencia.
• Ganancia de Reparación Amplia (BRG): Generalización de la reparación a otros fallos no sugeridos.
• Preservación de Comportamiento (BP): Capacidad de evitar la introducción de regresiones en pruebas que anteriormente pasaban.
• Tasa de Monotonicidad de Progreso (PMR): Frecuencia de tasas de aprobación no decrecientes a través de los turnos.
• Eficiencia de la Sugerencia (HE): El nivel de sugerencia requerido para cerrar un escenario (niveles más bajos indican una mayor capacidad diagnóstica).
• Cierre de Brecha: La fracción de la oportunidad de reparación restante que se cierra.
• Turnos para Reparar: Velocidad de convergencia entre las instancias reparadas con éxito.

3. Evaluación Empírica

Los autores instanciaron PAIR-BENCH utilizando 440 instancias de mejora de código derivadas de envíos de Python de Codeforces (específicamente veredictos de "Wrong Answer"). Evaluaron ocho modelos de lenguaje de última generación (incluyendo DeepSeek V3.2, Gemini 2.5 Flash Lite, Qwen3, GPT-4o-mini, Llama 3.3, etc.) utilizando un modelo de retroalimentación controlado (GPT-OSS 120B).

Hallazgos Clave

• Diferenciación de Modelos: Las métricas binarias a menudo fallan al distinguir modelos de manera efectiva. PAIR-BENCH reveló diferencias significativas en cómo los modelos utilizan la retroalimentación. DeepSeek V3.2 emergió como el modelo más fuerte, ocupando el primer lugar en la mayoría de las métricas, incluyendo una alta Tasa de Reparación Inicial, Éxito de Reparación Dirigida y Eficiencia de la Sugerencia.
• Utilidad de la Retroalimentación: Los modelos se benefician significativamente de las sugerencias controladas. Por ejemplo, Gemini 2.5 Flash Lite mejoró su Tasa de Reparación Final de ~78% (sin sugerencias en múltiples turnos) a ~95% (retroalimentación controlada), demostando que las ganancias son impulsadas por sugerencias relevantes para la reparación, no solo por la repetición de prompts.
• Reparación Diagnóstica vs. Dependiente: Los modelos más fuertes (p. ej., DeepSeek) a menudo resolvieron escenarios con sugerencias superficiales (L1–L2), indicando fuertes capacidades diagnósticas. Los modelos más débiles requirieron sugerencias más profundas (L5–L6) o no lograron resolver los escenarios, resaltando una dependencia de la guía explícita.
• Estabilidad: La retroalimentación controlada produjo resultados de evaluación significativamente más estables que la retroalimentación "Vanilla" (no controlada). La desviación estándar en las tasas de reparación y las tasas de reparación final disminuyó aproximadamente un 78–84% al usar el protocolo controlado, y la estabilidad de clasificación (Kendall's $\tau$) mejoró de 0.905 a 0.982.
• Compromisos (Trade-offs): Una alta Eficiencia de la Sugerencia (necesitar menos ayuda) no siempre se correlacionó con una alta Tasa de Reparación Final o estabilidad. Por ejemplo, Qwen mostró una fuerte preservación y monotonicidad, pero requirió más turnos para converger en comparación con Gemini.

4. Contribuciones Clave

1. PAIR-BENCH: Un nuevo paradigma de benchmark progresivo y adaptativo para evaluar la mejora de código, disponible con datos y código.
2. Métricas Centradas en el Progreso: Un conjunto de métricas diseñadas para medir la mejora de código interactiva más allá de la corrección final, capturando la trayectoria, la estabilidad y la generalización.
3. Protocolo de Retroalimentación Interactiva Controlada: La introducción de Sugerencias Progresivas, un protocolo estructurado que controla conjuntamente las regiones de fallo (mediante la agrupación de escenarios) y la profundidad de la sugerencia (mediante una escala de 6 niveles) para calibrar la dificultad de la retroalimentación a las capacidades del modelo.
4. Estudio Empírico: Una evaluación exhaustiva de múltiples LLM de última generación demostrando que los rankings y las capacidades de los modelos varían significativamente dependiendo de la dimensión de la mejora de código que se esté midiendo.

5. Significado y Reivindicaciones

El artículo afirma que PAIR-BENCH proporciona una evaluación más fiel de las capacidades de mejora de código de los LLM al ir más allá de los resultados binarios dispersos. Su importancia radica en:

• Revelar Capacidades Ocultas: Distingue entre modelos que simplemente "aprueban" mediante ediciones superficiales y aquellos que demuestran un razonamiento diagnóstico genuino y un refinamiento estable.
• Estandarizar la Retroalimentación: Al controlar la región de fallo y la profundidad de la sugerencia, elimina la variabilidad de la retroalimentación no estructurada, permitiendo comparaciones más justas de las capacidades de razonamiento de los modelos.
• Capturar la Trayectoria de Refinamiento: Reconoce que la mejora de código es un proceso iterativo, midiendo no solo el destino (aprobado final) sino el camino tomado (progreso, estabilidad y eficiencia).

Los autores concluyen que la reparación interactiva efectiva depende de múltiples dimensiones —corrección final, reparación dirigida, mejora progresiva, estabilidad y eficiencia de la sugerencia— y que PAIR-BENCH es necesario para evaluar estas dimensiones de manera holística. Se señala como trabajo futuro la extensión del proceso adaptativo al nivel de la pregunta (variando la dificultad del problema).