Resumen Técnico: Convertido, No Equivalente: Evaluación de la Conversión de Bases de Código mediante Equivalencia Observacional

Declaración del Problema

Los avances recientes en agentes de codificación han permitido que actúen como colaboradores a escala de base de código, capaces de navegar proyectos, editar archivos y realizar mantenimiento de software a gran escala. Sin embargo, ha surgido una debilidad crítica: los agentes confían en exceso en sus propias rutinas de validación local. En el contexto de la conversión de bases de código (por ejemplo, migrar de PyTorch a JAX), los agentes a menudo declaran éxito basándose en comprobaciones superficiales —como un punto de entrada ejecutable, una pérdida finita o validez sintáctica—, violando al mismo tiempo los contratos semánticos de los que realmente dependen los usuarios.

Los métodos de evaluación anteriores para la conversión de bases de código son en gran medida impulsados por resultados, comparando el éxito final de la tarea o los artefactos del estado final bajo evaluadores ocultos. Este enfoque es inestable para la conversión que preserva la semántica, ya que los resultados observables pueden ser escasos en relación con el espacio de implementación. Dos bases de código con contratos internos muy diferentes pueden producir pérdidas forward casi idénticas en un solo lote, mientras divergen drásticamente en gradientes, estados del optimizador o dinámicas de entrenamiento a corto plazo. En consecuencia, las comparaciones basadas únicamente en resultados corren el riesgo de recompensar acuerdos accidentales en sondas superficiales, mientras fallan en detectar fallos semánticos.

Metodología: T2J-Bench

Para abordar esta brecha de evaluación, los autores presentan T2J-Bench, una evaluación que reformula la conversión de bases de código como transferencia bajo un contrato de equivalencia fijo. En lugar de preguntar si una base de código convertida simplemente se ejecuta, T2J-Bench verifica si la base de código convertida se comporta como la original bajo un conjunto fijo de pruebas acotadas derivadas de la fuente.

Marco Central

La evaluación opera mediante un proceso de verificación ordenado en tres etapas. Una base de código candidata debe superar cada etapa secuencialmente para ser considerada exitosa:

1. Especificación (Admisibilidad de Interfaz): Verifica que la base de código convertida exponga la misma interfaz de entrenamiento que la fuente. Esto incluye verificar árboles de parámetros, esquemas de lotes, puntos de entrada públicos y la capacidad de construir un entorno de ejecución sin errores.
2. Numérica (Salidas Forward y Tensores): Compara artefactos específicos calculados durante pruebas acotadas. Esto incluye salidas forward, pérdidas, gradientes y tensores específicos del objetivo (por ejemplo, log-probabilidades de política para DPO, salidas de valor para PPO). Las comparaciones utilizan tolerancias estrictas para error absoluto/relativo, similitud coseno y divergencia KL.
3. Conductual (Dinámicas a Corto Plazo): Indaga si el acuerdo numérico local es suficiente para preservar las dinámicas de entrenamiento a corto plazo bajo semillas fijas. Esto implica reproducir algunos pasos de entrenamiento para asegurar que las actualizaciones del optimizador, los cálculos de recompensa y las interacciones con el modelo de referencia produzcan trayectorias consistentes con la fuente.

Configuración Experimental

• Tarea: Convertir bases de código completas de entrenamiento en PyTorch para SFT (Ajuste Fino Supervisado), DPO (Optimización Directa de Preferencias) y PPO (Optimización de Política Proximal) a JAX.
• Conjunto de Datos: 45 puntos de datos que cubren 15 familias de modelos (por ejemplo, variantes de LLaMA, Mistral, Qwen) con restricciones de tamaño (<7 mil millones de parámetros) y configuraciones acotadas.
• Protocolo de Evaluación:
  • Líneas Base Controladas: Modelos de vanguardia (por ejemplo, Claude Opus 4.7, Gemini 3.1 Pro, Qwen3 Coder) evaluados utilizando un andamiaje multiagente independiente del modelo central implementado internamente.
  • Agentes Nativos: Sistemas completos de agentes de codificación (por ejemplo, Claude Code, Codex) evaluados en sus interfaces nativas.
  • Restricciones: Se utiliza un "prompt de restricción mínima" ($p^\star$) para fijar la interfaz de entrenamiento sin filtrar los detalles internos del evaluador. El verificador permanece externo y fijo.

Resultados Clave

La evaluación de 355 intentos ciegos de conversión arroja cuatro hallazgos centrales:

1. La Conversión de Bases de Código Está Lejos de Estar Resuelta: A pesar de altas tasas de aprobación en la etapa inicial de Especificación (hasta un 91.1%), la tasa de aprobación final de extremo a extremo para los sistemas más fuertes es solo del 26.7–28.9% en @1. El principal cuello de botella es preservar la equivalencia numérica y las dinámicas de entrenamiento, no meramente producir código ejecutable.
2. El Presupuesto Computacional es un Remedio Débil: Aumentar el presupuesto de inferencia (conteo de tokens) produce rendimientos decrecientes. Una dispersión de 4.7 veces en el costo de tokens por intento resulta en solo una dispersión de 2.2 veces en la tasa de aprobación general. Los sistemas que gastan más tokens a menudo se involucran en investigaciones repetidas o autovalidación verbosa sin mejorar la calidad final de la conversión.
3. Sobreconfianza Sistemática: Cada sistema evaluado sobreestima significativamente su propio éxito. La brecha entre las tasas de aprobación autoinformadas (a menudo >90%) y las tasas de aprobación medidas por el evaluador (0–29%) oscila entre 66.6 y 97.8 puntos porcentuales. Los agentes tienden a verificar que los artefactos existen y están bien formados (por ejemplo, "la pérdida es un escalar finito"), pero fallan al verificar que estos artefactos coincidan con la semántica de la fuente.
4. Los Modos de Fallo están Desalineados con el Contrato: Los fallos más difíciles provienen de la autovalidación desalineada con el contrato en lugar de una fuerza limitada del modelo central. Los patrones de fallo comunes incluyen:
   • Errores de Costura: Confusión de tipos en el límite JAX/PyTorch (por ejemplo, pasar numpy.ndarray a una capa de incrustación de PyTorch).
   • Sustitución Semántica: Devolver la pérdida del método DPO en la ranura forward_loss, satisfaciendo pruebas de humo locales pero violando el contrato específico requerido por el evaluador.
   • Divergencia de Gradientes/Estados: Coincidir en los pasos forward pero fallar al preservar las normas de los gradientes o las actualizaciones del estado del optimizador.

Significado y Afirmaciones

El artículo afirma que T2J-Bench proporciona un cambio necesario de la evaluación impulsada por resultados a la evaluación impulsada por contratos. Al descomponer la verificación en etapas de Especificación, Numérica y Conductual, la evaluación evita la indecidibilidad de la equivalencia absoluta de bases de código, manteniéndose al mismo tiempo discriminativa entre diferentes modelos y sistemas de agentes.

Los autores argumentan que en el régimen actual de conversión de bases de código:

• La escalada del modelo central por sí sola es insuficiente: La brecha entre los mejores y los peores modelos es pequeña en comparación con la brecha entre la autovalidación y la verificación externa.
• La autovalidación es el principal cuello de botella: Los agentes fallan no porque no puedan calcular los valores correctos, sino porque sus bucles de validación internos tratan "artefactos bien formados" como equivalentes a "artefactos semánticamente correctos".
• Las mejoras futuras requieren alineación externa: Cerrar la brecha requiere que los agentes internalicen un bucle de comparación con la fuente en lugar de depender de pruebas de humo autoconsistentes. La evaluación sirve como un andamiaje de diagnóstico para identificar estas desalineaciones.

El artículo concluye que, aunque T2J-Bench se instaura en la conversión de PyTorch a JAX, su marco de contratos de equivalencia fijos y verificación escalonada ofrece un enfoque generalizable para evaluar transformaciones de bases de código que preservan la semántica.