LegacyTranslate: LLM-based Multi-Agent Method for Legacy Code Translation

1. El Problema

La modernización de sistemas heredados (legacy) a gran escala sigue siendo un desafío crítico en entornos empresariales, especialmente en sectores como el financiero. El caso de estudio se centra en la migración de aproximadamente 2.5 millones de líneas de código PL/SQL a Java dentro de una institución financiera europea.

Los principales obstáculos identificados son:

• Dependencias de Arquitectura y API: El código migrado no solo debe ser sintácticamente correcto, sino que debe integrarse con bibliotecas compartidas, APIs internas y convenciones arquitectónicas específicas de la empresa.
• Fallo de los LLMs Estándar: La aplicación directa de Modelos de Lenguaje Grande (LLMs) para traducción de código suele generar resultados que son sintácticamente válidos pero que no se compilan ni pasan las pruebas de integración en el marco de producción real.
• Falta de Benchmarks Realistas: La mayoría de las evaluaciones existentes se centran en pares de lenguajes populares (ej. Python-C++) y en unidades de código pequeñas, ignorando las restricciones de frameworks empresariales y lenguajes de nicho como PL/SQL.

2. Metodología: LegacyTranslate

Los autores proponen LegacyTranslate, un marco de trabajo basado en agentes múltiples coordinados por LLMs. En lugar de un solo prompt, el proceso se descompone en tres etapas secuenciales, donde cada agente aborda un aspecto específico del desafío de traducción:

A. Agente de Traducción Inicial (Initial Translation Agent)

• Función: Genera la primera versión del código Java a partir del PL/SQL.
• Mecanismo: Utiliza recuperación aumentada por generación (RAG). Un recuperador identifica pares semánticamente similares (PL/SQL $\to$ Java) de un conjunto de referencia y los inyecta en el prompt del LLM como ejemplos in-context (few-shot).
• Objetivo: Producir un borrador inicial que capture la lógica de negocio, aunque aún pueda carecer de alineación con las APIs específicas.

B. Agente de Aterrizaje de API (API Grounding Agent)

• Función: Alinea el código generado con las bibliotecas y APIs internas de la empresa.
• Mecanismo:
  1. Se construye una base de conocimientos de API curada a partir de las bibliotecas Java existentes (extrayendo clases, firmas, cuerpos y ubicaciones).
  2. Si el código falla al compilar, este agente utiliza el LLM para seleccionar una lista corta de APIs relevantes de la base de conocimientos que podrían solucionar los errores o completar la lógica faltante.
• Objetivo: Garantizar que el código utilice las interfaces correctas definidas por la arquitectura objetivo.

C. Agente de Refinamiento (Refinement Agent)

• Función: Corrige iterativamente el código hasta que sea ejecutable.
• Mecanismo: Opera en un bucle de retroalimentación. Toma el código actual, los errores del compilador y las sugerencias de APIs seleccionadas por el agente anterior. Re-prompta al LLM para generar una versión corregida.
• Criterio de parada: El bucle continúa hasta que el código se compila exitosamente, pasan todas las pruebas de unidad o se alcanza un criterio de terminación predefinido.

3. Contribuciones Clave

1. Marco Multi-Agente para Migración Empresarial: Propuesta de una arquitectura de tres agentes diseñada específicamente para traducir código heredado a entornos modernos con restricciones de API estrictas.
2. Evidencia de la Necesidad de "Grounding" de API: Demostración empírica de que sin una alineación explícita con las APIs internas, el código generado por LLMs rara vez se compila en entornos de producción, a pesar de ser sintácticamente válido.
3. Evaluación Exhaustiva: Análisis del impacto de la selección del modelo LLM y del recuperador en la calidad de la traducción, utilizando un conjunto de datos real de un proyecto de modernización activo.

4. Resultados Experimentales

Los experimentos se realizaron sobre un conjunto de datos interno de 68 pares alineados PL/SQL-Java, con pruebas de unidad reales.

• Rendimiento General: El sistema completo (LegacyTranslate) logró una tasa de compilación del 52.9% y una tasa de aprobación de pruebas del 33.8%.
• Comparación con Baselines:
  • Solo LLM (sin ejemplos ni APIs): 0% de compilación y 0% de pruebas aprobadas. El código generado era genérico y no compatible con el framework.
  • LLM + Ejemplos Aleatorios: Mejoró la validez estructural (98.5%), pero la tasa de compilación apenas subió al 1.5%, demostrando que los ejemplos aleatorios no enseñan los patrones de la API.
  • LegacyTranslate (sin agentes de API/Refinamiento): El Agente de Traducción Inicial por sí solo logró un 45.6% de compilación y 30.9% de pruebas.
  • Impacto de los Agentes Adicionales: La adición del Agente de Grounding de API y el Agente de Refinamiento aportó un 8% adicional en compilación y un 3% adicional en pruebas, confirmando que cada agente contribuye significativamente a la calidad final.
• Selección de Modelos:
  • El modelo Qwen2.5-14B fue el más efectivo.
  • Modelos más pequeños (7B-13B) fallaron consistentemente en generar código compilable, indicando que la capacidad del modelo es decisiva para manejar las restricciones del framework y los prompts largos.
  • El recuperador SFR-Mistral (con vectores de 4096 dimensiones) superó a otros modelos de recuperación, destacando la importancia de la calidad de los ejemplos recuperados.

5. Significado e Implicaciones

Este trabajo es significativo porque cierra la brecha entre la investigación académica sobre traducción de código y la realidad de la ingeniería de software empresarial.

• Validación Práctica: Demuestra que la migración automatizada de sistemas heredados es viable a escala industrial si se implementan mecanismos de verificación y alineación con APIs.
• Guía para Equipos: Proporciona una hoja de ruta clara: no basta con usar un LLM potente; se requiere un flujo de trabajo multi-agente que incluya recuperación de ejemplos relevantes, grounding en APIs específicas y refinamiento iterativo basado en errores de compilación.
• Limitaciones y Futuro: El estudio resalta la falta de conjuntos de datos públicos realistas para PL/SQL-Java y sugiere que futuras investigaciones deben enfocarse en crear benchmarks más robustos y extender el marco a otros pares de lenguajes de migración.