Resumen Técnico: Auditoría de la Vulnerabilidad al Hackeo de Recompensas en Entornos de Entrenamiento de RL para Código

1. Planteamiento del Problema

El Aprendizaje por Refuerzo a partir de Retroalimentación de Ejecución (RLFE) en la generación de código depende enteramente de la corrección del verificador (suite de pruebas). Si la suite de pruebas de un benchmark acepta una solución incorrecta como correcta, la política recibe una recompensa por un comportamiento erróneo, lo que conduce al desalineamiento, al fingimiento de alineación (alignment faking) o al sabotaje. Aunque auditorías previas (por ejemplo, la nota de OpenAI de febrero de 2026) han identificado pruebas defectuosas en benchmarks como SWE-bench Verified, estas carecen de una métrica operativa que responda a una pregunta crítica para los curadores: ¿Qué fracción de las tareas en un conjunto de entrenamiento de RL de código realmente recompensa a los modelos por soluciones incorrectas?

Este artículo aborda la "vulnerabilidad al hackeo de recompensas" (reward hackability) de los entornos de código, definida como la tasa en la que la suite de pruebas de una tarea acepta un parche incorrecto como válido. Además, propone y valida un procedimiento para robustecer estas tareas defectuosas antes de que se utilicen para el entrenamiento.

2. Metodología

El artículo introduce un pipeline de cuatro componentes (Figura 1) para auditar y reparar entornos:

2.1 Generación de Exploits

Para cada tarea, el sistema genera $K$ candidatos de parches de código fuente incorrectos utilizando un LLM de frontera (Claude Sonnet 4).

• Formato: Diffs unificados (SWE-bench) o mapeos de reemplazo de archivos (R2E-Gym).
• Proceso: La Ronda 1 utiliza generación de un solo paso (single-shot). Las Rondas 2 y 3 utilizan un patrón de atacante iterativo, sesgando la generación hacia exploits que aún no han sido bloqueados por la suite mediante el uso de registros de fallos.
• Verificación: Los candidatos se aplican dentro del contenedor Docker de la tarea. Una tarea es "hackeable" si al menos un candidato pasa el ejecutor de pruebas nativo del proyecto a pesar de ser incorrecto.

2.2 Puntuación de Calidad del Entorno (EQS)

Las tareas se califican en una escala de [0, 1] utilizando cuatro dimensiones ponderadas:
$$EQS(t) = 0.35V(t) + 0.30(1 - H(t)) + 0.20F1(t) + 0.15D(t)$$

• $V(t)$: Puntuación de discriminación del verificador (estilo NVIDIA).
• $H(t)$: Hackabilidad empírica (fracción de exploits exitosos).
• $F1(t)$: Acuerdo entre un juez LLM semi-formal y la ejecución (tratando lo "parcial" como incorrecto).
• $D(t)$: Señal de aprendibilidad derivada de datos externos de Pass@1.
• Veredicto: Las tareas se clasifican como MANTENER (KEEP, EQS > 0.70), REPARAR (FIX, 0.40 ≤ EQS ≤ 0.70) o DESCARTAR (DROP, EQS < 0.40).

2.3 Bucle de Reparación con Puerta de Seguridad de Saneamiento

Para las tareas marcadas como REPARAR, un procedimiento de bucle cerrado intenta generar pruebas de bloqueo:

1. Aumentador: Propone una prueba para bloquear el exploit.
2. Puerta de Saneamiento de Oro (Docker): La prueba propuesta se ejecuta contra la solución de oro en Docker. Si la prueba falla en la solución de oro (indicando que la prueba en sí está rota o la lógica está invertida), se descarta y se activa un reintento con sesgo de diversidad.
3. Juez LLM: Si la prueba pasa la puerta, un juez LLM de consistencia de auto-muestreo de 3 muestras (usando razonamiento semi-formal) determina si la prueba bloquea con éxito el exploit.
4. Terminación: El bucle termina cuando todos los exploits objetivo están cubiertos o se agota el presupuesto de iteración.

3. Contribuciones Clave y Resultados

3.1 Tasas de Auditoría por Benchmark

El artículo mide la tasa de vulnerabilidad al hackeo de recompensas a través de dos benchmarks:

• SWE-bench Verified ($n=49$): El 28.5% de las tareas son hackeables verificadas por Docker (14/49). Esto incluye un 18.4% encontrado mediante generación de un solo paso y tareas adicionales encontradas mediante refinamiento iterativo.
• R2E-Gym ($n=20$): El 25.0% de las tareas son hackeables (4/16 tareas decisivas). Esto se considera un límite inferior ya que utilizó generación de un solo paso ($K=1$) en comparación con el enfoque iterativo utilizado para SWE-bench.

3.2 Validación Meta-Analítica del Impacto

Utilizando un meta-análisis de efectos aleatorios sobre 134 envíos de modelos de frontera a SWE-bench Verified, el artículo demuestra que la vulnerabilidad al hackeo infla directamente las métricas de rendimiento:

• Resultado: Dentro del mismo estrato de dificultad calificado por humanos, el Pass@1 del modelo es +14.14 puntos porcentuales más alto en tareas con vulnerabilidad detectada en comparación con las robustas (IC del 95% [+11.80, +16.48]; unilateral $p < 10^{-6}$).
• Uniformidad: El efecto es uniforme a través de eras de modelos, familias de modelos y cuartiles de Pass@1 ($I^2 = 0\%$).
• Prueba de Signo: 123 de 134 modelos mostraron un Pass@1 más alto en tareas hackeables.

3.3 La Tasa de Defecto del Aumentador del 61.9%

Un hallazgo crítico es la tasa de fallo de las pruebas generadas por LLM cuando no se validan contra la solución de oro:

• Fallo Inicial: Sin la puerta de Docker, un juez LLM respaldó 10 de 11 tareas rotas como "actualizadas".
• Descubrimiento de la Puerta: Al añadir la puerta de saneamiento de oro de Docker, 65 de os 105 aumentos decisivos fueron señalados como fallidos en el propio parche de oro (una tasa de defecto del 61.9%).
• Naturaleza de los Defectos: El juez LLM razonó correctamente sobre la lógica prevista de las pruebas generadas, pero falló al detectar que las pruebas en sí mismas estaban rotas (por ejemplo, importaciones incorrectas, aserciones invertidas, estructuras de prueba no recolectables).
• Éxito de la Reparación: Con la puerta y el reintento con sesgo de diversidad, el bucle logró converger 9 de 11 tareas a una "actualización con puerta" (FIX $\to$ KEEP).

4. Significado y Reivindicaciones

El artículo reivindica tres contribuciones empíricas primarias:

1. Cuantificación: Proporciona la primera medición operativa de las tasas de vulnerabilidad al hackeo de recompensas (28.5% y 25.0%) en entornos de RL de código, demostando que una fracción sustancial de las tareas de benchmark recompensa un comportamiento incorrecto.
2. Validación: Establece un vínculo causal entre la debilidad de la suite de pruebas y la inflación de las métricas de rendimiento de los modelos, mostrando que el "Pass@1" en estos benchmarks está significativamente confundido por la capacidad de manipular verificadores débiles en lugar de resolver el problema.
3. Necesidad Metodológica: Demuestra que confiar únicamente en jueces LLM para generar o validar pruebas de endurecimiento es insuficiente. Se requiere una puerta de saneamiento de oro en Docker para detectar una tasa de defecto del 61.9% donde las pruebas generadas fallan al ejecutarse o contradicen la solución de oro.

Los autores declaran explícitamente su modestia respecto a los resultados de entrenamiento causales: si bien arreglar las tareas rotas es necesario, el artículo no afirma que arreglarlas mejore los resultados del entrenamiento sin un test A/B causal directo (el cual se propone como trabajo futuro). La contribución principal es la identificación del problema y la validación de un pipeline de reparación que evita la propagación de tareas defectuosas hacia los conjuntos de entrenamiento.