Resumen Técnico: STEP-KTODER

Planteamiento del Problema

Si bien la supervisión de procesos —proporcionar retroalimentación sobre los pasos intermedios de razonamiento— ha mejorado significamente el razonamiento matemático en los Grandes Modelos de Lenguaje (LLMs), su aplicación a la generación de código sigue siendo poco explorada. En los dominios matemáticos, los pasos se definen naturalmente como cadenas de pensamiento. En la generación de código, sin embargo, no existe una noción estándar de un "paso". Los objetivos de supervisión pueden variar ampliamente (líneas, trazas de razonamiento o estados del programa), lo que crea ambigüedad en qué etiquetar y optimizar.

Los métodos actuales de optimización de preferencias, como la Optimización de Preferencia Directa (DPO) y la Optimización de Kahneman–Tversky (KTO), operan típicamente a nivel de resultado, tratando un programa completo como una única unidad de retroalimentación. Esta señal gruesa no logra distinguir entre componentes correctos e incorrectos dentro de un programa parcialmente exitoso. Por ejemplo, un programa que es mayormente correcto pero falla en un caso de borde estrecho es etiquetado enteramente como "indeseable", ocultando qué funciones específicas contribuyeron al éxito o al fracaso. Esta falta de granularidad limita la capacidad de reforzar el código localmente correcto mientras se penalizan componentes fallidos específicos.

Metodología: STEP-KTODER

Los autores proponen STEP-KTODER, un marco para la optimización de preferencias de código que define los "pasos" como funciones a nivel de módulo en programas de funciones múltiples descompuestos. El método combina la supervisión de procesos a nivel de función con la retroalimentación a nivel de resultado utilizando un pipeline de etiquetado basado en la ejecución.

1. Pipeline de Construcción de Datos

El marco depende de un proceso automático de construcción de datos que consta de cuatro etapas:

• Descomposición de Referencia: Un modelo de código fuerte con ajuste de instrucciones reescribe las soluciones de referencia en programas descompuestos de múltiples funciones, preservando la interfaz y el comportamiento originales. Solo se conservan las reescrituras que pasan la suite de pruebas original.
• Generación de Pruebas Unitarias a Nivel de Función: Para cada función descompuesta, el modelo genera pruebas unitarias dirigidas que cubren la interfaz de la función y sus casos de borde. Estas pruebas son validadas mediante la ejecución contra la implementación de referencia; solo se conservan las pruebas que pasan y contienen aserciones no triviales.
• Generación de Candidatos On-Policy: El modelo objetivo genera completaciones candidatas rellenando esqueletos de funciones (donde los cuerpos de las funciones han sido reemplazados por pass) derivados de las referencias descompuestas.
• Etiquetado:
  • Etiqueta de Resultado ($o$): Determinada por si el programa candidato completo pasa la suite de pruebas proporcionada para el conjunto de datos.
  • Etiquetas de Paso ($z$): Determinadas mediante la ejecución de cada función candidata contra sus pruebas unitarias generadas. Una etiqueta de $1$ indica corrección local, $0$ indica fallo, y $\emptyset$ indica que no había una prueba válida disponible.

2. Función Objetivo

STEP-KTODER extiende KTO introduciendo un objetivo conjunto que combina la supervisión a nivel de resultado y a nivel de paso.

• KTO a Nivel de Resultado: Utiliza la pérdida KTO estándar ($L_{out}$) basada en la deseabilidad binaria del programa completo.
• KTO a Nivel de Paso: Define una pérdida por paso ($L_{step}$) sobre los tokens de funciones individuales. Para cada función $s_i$, se calcula un log-ratio local y se aplica una función de valor basada en la etiqueta de paso $z_i$.
• Objetivo Conjunto: La pérdida final es $L_{STEP-KTODER} = L_{out} + \lambda_{step} L_{step}$.

Crucialmente, el marco emplea etiquetas que preservan el conflicto. Retiene ejemplos de entrenamiento donde la etiqueta de resultado ($o$) y las etiquetas de paso ($z$) discrepan (por ejemplo, un programa que pasa la suite de pruebas global pero contiene una función localmente fallida). Estos conflictos proporcionan señales de entrenamiento únicas que los métodos de solo resultado no pueden capturar, permitiendo que el modelo aprenda que componentes específicos pueden ser correctos incluso si el todo falla, o viceversa.

3. Fiabilidad de las Etiquetas

El artículo enfatiza que las etiquetas basadas en la ejecución son esenciales. Los autores probaron reemplazar las etiquetas de paso basadas en la ejecución con anotaciones de "LLM-como-juez" (usando GPT-5.4 mini). Aunque el LLM mostró una concordancia general moderada (73.2%), exhibió un sesgo sistemático: sobrepredijo los fallos, identificando correctamente el 94.1% de las funciones fallidas pero solo el 52.2% de las exitosas. Este sesgo corrompió las etiquetas positivas de paso necesarias para el entrenamiento, provocando un rendimiento degradado, particularmente en benchmarks más difíciles.

Contribuciones Clave

1. Marco STEP-KTODER: Una instanciación de KTO paso a paso específica para código que define los pasos como funciones independientemente testeables, cerrando la brecha entre la supervisión de procesos y la generación de código.
2. Pipeline de Datos Automático: Un pipeline que descompone soluciones, genera pruebas unitarias a nivel de función y deriva etiquetas de paso basadas en la ejecución, permitiendo una supervisión de grano fino sin anotación manual.
3. Validación Empírica: Experimentos que demuestran que las etiquetas basadas en la ejecución son superiores a los juicios de LLM para la supervisión de pasos y que preservar los conflictos de etiquetas locales/globales es crítico para el rendimiento.

Resultados Experimentales

El método fue evaluado en HumanEval(+), MBPP(+), BigCodeBench y LiveCodeBench utilizando modelos ajustados por instrucciones (Qwen2.5-Coder y DeepSeek-Coder).

• Ganancias de Rendimiento: STEP-KTODER superó consistentemente a KTO y DPO de solo resultado, observándose las mejoras más significativas en los benchmarks más difíciles.
  • En Qwen2.5-Coder-1.5B, mejoró sobre KTO en un +11.5% en BigCodeBench Hard y un +7.7% en LiveCodeBench.
  • En Qwen2.5-Coder-3B, las ganancias fueron de +11.3% en BigCodeBench Hard y +9.5% en LiveCodeBench.
  • En DeepSeek-Coder-6.7B, logró una ganancia de +4.9% sobre KTO en BigCodeBench Hard.
• Comparación con Target-DPO: Aunque Target-DPO también apunta a fallos localizados, STEP-KTODER logró resultados superiores en los benchmarks más difíciles (por ejemplo, una mejora de +18.5% sobre Target-DPO en BigCodeBench Hard para el modelo de 3B) utilizando significativamente menos muestras de entrenamiento (aprox. 11,400 frente a 59,000 pares).
• Estudios de Ablación:
  • Preservación de Conflictos: Enmascarar los conflictos (eliminar ejemplos donde $o \neq z$) redujo el rendimiento a los niveles de KTO, confirmando que estos desajustes proporcionan señales de entrenamiento esenciales.
  • Fuente de la Etiqueta: Reemplazar las etiquetas basadas en la ejecución con anotaciones de LLM-como-juez causó caídas sustanciales en el rendimiento (por ejemplo, -25.8% en BigCodeBench Hard), validando la necesidad de la retroalimentación basada en la ejecución.

Significado y Reivindicaciones

El artículo afirma que STEP-KTODER ofrece un camino práctico hacia la supervisión de procesos para la generación de código aprovechando la modularidad natural de los programas. Al definir los pasos como funciones y supervisarlos mediante la ejecución, el método proporciona retroalimentación localizada que refuerza los componentes correctos y penaliza fallos específicos, una capacidad ausente en la supervisión de solo resultado.

Los autores destacan que la efectividad del método depende fuertemente de dos factores:

1. Fiabilidad basada en la ejecución: Las pruebas unitarias automatizadas proporcionan la verdad fundamental necesaria para las etiquetas de paso, mientras que los jueces LLM introducen sesgos sistemáticos que degradan el aprendizaje.
2. Preservación de conflictos: La capacidad de aprender de ejemplos donde la corrección local y el éxito global divergen es un diferenciador clave de la optimización de preferencias estándar.

El trabajo sugiere que la retroalimentación de ejecución a nivel de función es un mecanismo viable y efectivo para alinear modelos de código, particularmente para tareas complejas donde la retroalimentación de grano grueso es insuficiente. Los autores señalan limitaciones respecto al requisito de que las soluciones sean descomponibles en funciones testeables y el costo de ingeniería de generar candidatos on-policy para nuevos modelos.