An Iterative Test-and-Repair Framework for Competitive Code Generation

Resumen Técnico: FixAudit

1. El Problema

Aunque los Modelos de Lenguaje Grandes (LLMs) han avanzado significativamente en la generación de código, la programación competitiva sigue siendo un desafío crítico. Los problemas de este tipo tienen restricciones lógicas estrictas donde un modelo puede generar un programa que pasa las pruebas públicas (ejemplos de muestra) pero falla en las pruebas privadas ocultas que determinan la corrección real.

Los enfoques actuales tienen limitaciones importantes:

• Métodos basados en RL (aprendizaje por refuerzo) tradicionales: Se centran solo en optimizar la política de generación de código usando pruebas fijas. No generan nuevas pruebas durante la inferencia, lo que limita la capacidad de escalar en tiempo de prueba (test-time scaling).
• CURE (State-of-the-Art anterior): Entrena un modelo único que actúa como "Codificador" y "Probador". Sin embargo, tiene dos fallos críticos:
  1. El Probador genera pruebas ciegamente basándose solo en la descripción del problema, sin leer el código candidato. Esto impide detectar errores específicos de la implementación.
  2. El Codificador genera candidatos desde cero en cada intento. No aprende a reparar un programa existente basándose en un fallo, desperdiciando la lógica correcta que ya estaba presente.

2. Metodología: FixAudit

Los autores proponen FixAudit, un nuevo marco que aborda la generación de código desde una perspectiva diferente: en lugar de generar muchos candidatos desde cero, se parte de un candidato inicial y se mejora iterativamente mediante un ciclo dirigido de prueba y reparación.

El marco entrena un único modelo compartido con dos roles especializados a través de cuatro etapas:

• Etapa A: Ajuste Fino Supervisado (SFT) Alineado a la Ejecución

  • Objetivo: Dotar al modelo de capacidad de razonamiento de ejecución.
  • Tareas:
    1. Predicción de salida de programa: Dado un código y una entrada, predecir la salida.
    2. Derivación de especificación a salida: Dada solo la descripción del problema y una entrada, deducir la salida correcta.
  • Importancia: Esto permite al agente "Reparador" entender por qué falla un programa y al agente "Auditor" generar casos de prueba válidos.

• Etapa B: RL del Reparador (Round-1 Repair)

  • Rol: El Reparador (Fixer).
  • Proceso: Recibe el código candidato defectuoso, la especificación y una prueba pública que falló. Genera una versión reparada.
  • Recompensa: Se otorga recompensa solo si el programa pasa la prueba fallida y no rompe ninguna prueba que ya pasaba (principio de "no hacer daño" o regresión). Esto enseña al modelo a preservar la lógica correcta y solo modificar la lógica defectuosa.

• Etapa C: RL del Auditor (Generación de Pruebas Reveladoras de Errores)

  • Rol: El Auditor.
  • Proceso: A diferencia del Probador de CURE, el Auditor lee el código candidato reparado junto con la especificación. Genera nuevos casos de prueba (entrada + salida esperada) diseñados específicamente para exponer errores latentes que las pruebas públicas no cubren.
  • Recompensa: Se recompensa si la prueba es válida (la salida esperada coincide con la solución de referencia) y si el candidato reparado falla en ella. Se utiliza un shaping de recompensa auxiliar para fomentar pruebas que rompan múltiples candidatos incorrectos.

• Etapa D: RL del Reparador (Round-2 Refinement)

  • Proceso: El Reparador se reentrena utilizando las nuevas pruebas adversarias generadas por el Auditor.
  • Mecanismo: La prueba del Auditor actúa como una "pista" sobre un posible error lógico. El Reparador no está obligado a pasar esa prueba específica (ya que el Auditor puede equivocarse), sino que debe usarla para refinar la solución y pasar las pruebas ocultas reales.
  • Recompensa: Basada en cuántas pruebas ocultas adicionales pasa la nueva versión en comparación con la anterior.

Algoritmo de Optimización: Todas las etapas de RL utilizan DAPO (Optimización de Política Desacoplada y Dinámica), que permite actualizaciones de política más grandes para resultados exitosos raros (como una reparación correcta) y evita que el modelo se estreche prematuramente.

3. Contribuciones Clave

1. Nueva Perspectiva: Tratar la generación de código competitivo como un proceso continuo de depuración dirigido (prueba y reparación) centrado en la solución candidata actual, en lugar de una selección entre múltiples candidatos generados desde cero.
2. Marco FixAudit: Un pipeline de entrenamiento de cuatro etapas que combina SFT para razonamiento de ejecución y RL para entrenar agentes especializados (Reparador y Auditor) que trabajan en un bucle cerrado.
3. Capacidad de Lectura de Código: El Auditor lee el código candidato para generar pruebas dirigidas, superando la limitación de los métodos anteriores que generan pruebas ciegamente.
4. Mecanismo de Reparación Localizada: El Reparador aprende a corregir errores específicos sin descartar la lógica correcta existente.

4. Resultados Experimentales

El marco se evaluó en tres benchmarks de programación competitiva: APPS, CodeContests y xCodeEval, utilizando un modelo base Qwen2.5-Coder-7B.

• Rendimiento General: FixAudit logró un Pass@1 promedio de 30.40% y un AvgPassRatio promedio de 56.77%.
• Comparación con Modelos Mayores (Zero-Shot): FixAudit (7B) superó al modelo Qwen2.5-Coder-32B en configuración zero-shot, mejorando el Pass@1 en un 24.9% y el AvgPassRatio en un 40.5%. También superó a GPT-4o-mini en un 46.6% en Pass@1.
• Comparación con Baselines del Mismo Tamaño:
  • Superó a Specine (agente basado en prompts) en un 36.8% de Pass@1.
  • Superó a CURE (RL con generador y probador) en un 35.1% de Pass@1.
• Eficiencia de Iteraciones: FixAudit alcanza un rendimiento superior con menos iteraciones. Una sola iteración completa de prueba y reparación de FixAudit supera el rendimiento final de Specine y CURE en todos los benchmarks. Esto demuestra que el enfoque de refinamiento incremental es más eficiente que regenerar desde cero o muestrear candidatos independientes.

5. Significado e Impacto

El trabajo demuestra que la eficacia en la generación de código no depende únicamente del tamaño del modelo, sino de la arquitectura del proceso de inferencia y entrenamiento.

• Razonamiento de Ejecución: La capacidad de simular y entender la ejecución del código es fundamental para la depuración y la generación de pruebas útiles.
• Bucle Cerrado: La combinación de un agente que lee el código para generar pruebas (Auditor) y otro que repara el código basándose en esas pruebas (Reparador) crea un ciclo de retroalimentación mucho más potente que los enfoques actuales.
• Escalabilidad: El método permite que modelos más pequeños (7B) superen a modelos comerciales mucho más grandes (32B, GPT-4o) en tareas complejas de lógica, ofreciendo una ruta viable para sistemas de generación de código más eficientes y accesibles.

En conclusión, FixAudit establece un nuevo estándar en la generación de código competitivo al transformar el problema de "generar y seleccionar" en uno de "diagnosticar y reparar" iterativo, logrando una precisión superior con un uso más eficiente de los recursos computacionales.