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

1. Il Problema

La modernizzazione di grandi sistemi legacy rimane una sfida critica per le aziende, in particolare nei settori finanziari dove si devono migrare milioni di righe di codice (es. da PL/SQL a Java).

• Limiti degli approcci attuali: L'applicazione diretta dei Large Language Models (LLM) per la traduzione del codice spesso produce output sintatticamente validi ma che non compilano o non si integrano con i framework architetturali esistenti.
• Il divario contestuale: I benchmark accademici si concentrano su traduzioni a livello di funzione tra linguaggi popolari (es. Python-C++), ignorando i vincoli specifici del settore, come l'uso di librerie condivise, API interne e convenzioni architetturali proprietarie.
• Il caso di studio: Il paper affronta la migrazione di circa 2,5 milioni di righe di codice PL/SQL in un'architettura Java moderna presso un'istituzione finanziaria europea. Il codice sorgente è privo di documentazione coerente e deve conformarsi rigorosamente a un set di API interne.

2. Metodologia: LegacyTranslate

Gli autori propongono LegacyTranslate, un framework multi-agente basato su LLM progettato per la traduzione di codice legacy consapevole delle API. Il sistema non si affida a un singolo prompt, ma suddivide il compito in tre agenti coordinati che lavorano in sequenza iterativa:

A. Agente di Traduzione Iniziale (Initial Translation Agent)

• Funzione: Genera la prima bozza di codice Java partendo dal frammento PL/SQL.
• Tecnica: Utilizza il Retrieval-Augmented Generation (RAG). Un retriever identifica coppie PL/SQL→Java semanticamente simili da un set di riferimento e le inserisce nel prompt come esempi few-shot (in-context learning) per guidare l'LLM.
• Output: Un codice Java iniziale che può essere sintatticamente corretto ma non ancora allineato alle API specifiche o privo di errori di compilazione.

B. Agente di Grounding delle API (API Grounding Agent)

• Funzione: Allinea il codice generato con le librerie aziendali esistenti.
• Tecnica: Analizza gli errori di compilazione o le lacune logiche e interroga una Knowledge Base delle API (costruita tramite analisi statica delle librerie Java condivise, contenente firme, corpi e descrizioni delle API).
• Output: Una lista selezionata di API rilevanti necessarie per correggere il codice e rispettare l'architettura target.

C. Agente di Rifinitura (Refinement Agent)

• Funzione: Corregge iterativamente il codice fino alla sua validità.
• Tecnica: Utilizza un ciclo di feedback che combina:
  1. Il codice corrente.
  2. Gli errori del compilatore e i fallimenti dei test unitari.
  3. Le API selezionate dall'agente precedente.
• Processo: L'agente ripropone questi dati all'LLM per generare una versione migliorata. Il ciclo continua finché il codice non compila e passa i test, o fino al raggiungimento di un criterio di terminazione.

3. Contributi Chiave

1. Framework Multi-Agente: Introduzione di LegacyTranslate, che dimostra come decomporre il compito di traduzione in fasi specializzate (traduzione, grounding, raffinamento) migliori significativamente i risultati rispetto all'uso di un singolo LLM.
2. Importanza del Grounding delle API: Dimostrazione empirica che senza un grounding esplicito sulle API interne, il codice generato dagli LLM raramente compila in ambienti di produzione reali.
3. Valutazione su Dati Reali: Fornitura di una valutazione su un dataset interno reale (68 coppie PL/SQL-Java con test unitari eseguiti nel framework di produzione), colmando il gap tra benchmark accademici e scenari industriali.
4. Analisi delle Capacità del Modello: Evidenziazione del fatto che la capacità del modello (dimensione e specializzazione) e la qualità del retriever sono fattori decisivi per il successo della migrazione.

4. Risultati Sperimentali

Gli esperimenti sono stati condotti utilizzando Qwen2.5-Coder-14B come LLM principale e SFR-Mistral come retriever.

• Confronto con Baseline:

  • LLM-only (senza esempi o API): 0% di codice compilabile e 0% di test superati. Il codice generato è generico e non rispetta i vincoli architetturali.
  • LLM + Esempi Casuali: Migliora la validità strutturale (98,5%), ma la compilazione rimane quasi nulla (1,5%), dimostrando che gli esempi non pertinenti non aiutano a imparare i pattern specifici.
  • LegacyTranslate (Sistema Completo): Raggiunge un 52,9% di tasso di compilazione e un 33,8% di tasso di superamento dei test.

• Contributo dei Singoli Agenti:

  • L'agente di traduzione iniziale da solo ottiene il 45,6% di compilazione e 30,9% di test superati.
  • L'aggiunta dell'Agente di Grounding e dell'Agente di Rifinitura porta un miglioramento aggiuntivo di circa 8 punti percentuali nella compilazione e 3 punti nei test.

• Impatto del Modello e del Retriever:

  • L'uso di un retriever ad alta dimensionalità (SFR-Mistral con vettori 4096) ha superato tutti gli altri modelli di recupero.
  • Modelli più piccoli (es. Qwen2.5-7B, CodeLlama-13B) hanno fallito nel generare codice compilabile, sottolineando la necessità di modelli di grandi dimensioni per gestire prompt contestuali complessi.

5. Significato e Conclusioni

Il paper fornisce linee guida pratiche per i team che intendono utilizzare l'IA per la migrazione del codice legacy:

• Non basta la traduzione sintattica: Per la migrazione enterprise, la semplice traduzione del linguaggio non è sufficiente; è fondamentale l'integrazione con le API aziendali.
• Architettura Multi-Agente: Un approccio modulare che separa la traduzione, la selezione delle API e la correzione degli errori è superiore all'uso di un singolo prompt monolitico.
• Scalabilità: Sebbene il focus sia su PL/SQL→Java, il framework è generalizzabile ad altri scenari di migrazione linguistica in ambienti enterprise.

In sintesi, LegacyTranslate dimostra che è possibile automatizzare con successo la modernizzazione di sistemi legacy complessi, a patto di integrare l'LLM con meccanismi di recupero delle API e cicli di raffinamento basati sul feedback del compilatore.