Sintesi Tecnica: Framework di Migrazione del Codice basato su LLM con Fine-tuning

Problematica

La migrazione di sistemi di gestione di database (DBMS) su larga scala da Oracle a PostgreSQL è una sfida complessa e interdisciplinare che va ben oltre la semplice conversione della sintassi. Gli autori identificano diverse barriere critiche:

• Disparità Semantiche e Strutturali: Esistono differenze significative tra Oracle PL/SQL e PostgreSQL PL/pgSQL per quanto riguarda la sintassi, i tipi di dati, il comportamento dei cursori e le strategie di ottimizzazione delle query.
• Scala e Dipendenza: I codebase di grandi dimensioni contengono spesso centinaia di migliaia di file interdipendenti, rendendo difficile l'analisi e la trasformazione automatizzate.
• Limitazioni degli Strumenti Esistenti: Gli strumenti tradizionali basati su regole (ad esempio, AWS Schema Conversion Tool, Ora2PG) faticano nell'analisi contestuale profonda, nel SQL dinamico, nei trigger complessi e nella gestione delle eccezioni, risultando spesso in traduzioni incomplete o in un "semantic drift" (deriva semantica).
• Limitazioni degli LLM: Sebbene i Large Language Models (LLM) mostrino potenziale, essi soffrono frequentemente di errori sistematici come la deriva semantica, discrepanze nelle chiamate API e mappature inconsistenti delle strutture di controllo quando applicati direttamente senza un adattamento specifico per il dominio.

Il problema scientifico centrale è la mancanza di un framework unificato e iterativo che equilibri il fine-tuning con il prompt engineering per garantire l'integrità semantica, minimizzare i rischi architettonici e raggiungere un'alta fedeltà nella migrazione di librerie di codice massicce ed eterogenee.

Metodologia

La soluzione proposta è un framework iterativo e scalabile che integra l'IA Generativa (GAI) con tecniche tradizionali di ingegneria del software. La metodologia si articola attorno ad alcune componenti chiave:

1. Razionale del Fine-tuning a Due Stadi

Gli autori rifiutano un singolo evento di apprendimento olistico a favore di una pipeline di instruction tuning a due stadi:

• Stadio 1 (Allineamento Sintattico): Il modello viene addestrato su un dataset che accoppia il codice con descrizioni in linguaggio naturale (<Codice> : <Descrizione>). Questa fase si concentra sull'apprendimento dei pattern strutturali, delle sfumature del dialetto, delle firme dei tipi e delle regole di scope di sia Oracle che PostgreSQL, senza eseguire una conversione diretta.
• Stadio 2 (Comportamento di Trasformazione): Il modello viene sottoposto a fine-tuning su coppie di trasformazione diretta (<Codice Oracle> : <Codice PostgreSQL>). Questo stadio sposta il modello dalla comprensione sintattica alla conversione della logica procedurale, garantendo la preservazione semantica durante la trasformazione di blocchi, cursori ed eccezioni.

2. Motore di Profilazione delle Caratteristiche del Codice Ibrido (HCFPE)

Per gestire l'eterogeneità del codebase, l'HCFPE annota il corpus con metadati sulle feature SQL (marcatori sintattici, strutture di flusso, operatori specifici del dialetto). Ciò converte il codice non strutturato in una rappresentazione strutturata, consentendo la creazione di dataset stratificati (piccoli, medi, grandi) e garantendo che i dati di addestramento riflettano accuratamente la distribuzione di feature come RMAN, SQL*Plus e PL/SQL.

3. Architetture della Knowledge Base e RAG

Il framework impiega la Retrieval Augmented Generation (RAG) con due strategie distinte:

• Strategia A (Knowledge Base Ibrida): Utilizza tre database vettoriali separati per il codice Oracle, la documentazione di PostgreSQL e le regole di trasformazione derivate da esperti (SME). Ciò consente all'LLM di triangolare il contesto, applicando regole deterministiche e documentazione sintattica autorevole insieme a esempi di codice.
• Strategia B (Knowledge Base Unificata): Utilizza un singolo database vettoriale contenente solo coppie di trasformazione diretta "Oracle-PostgreSQL". Questo testa la capacità del modello di generalizzare basandosi esclusivamente sugli esempi, senza l'imposizione esplicita di regole.

4. Human-in-the-Loop e Correzione degli Errori

Il framework incorpora una logica di iterazione a ciclo chiuso:

• Valutazione: Gli output sono valutati tramite metriche NLP (Recall, BLEU, ChrF) e validatori strutturali (controllori di sintassi, analizzatori statici).
• Analisi degli Errori: Gli errori vengono categorizzati in gruppi di sintassi, semantica, struttura e funzione.
• Feedback degli SME: Gli esperti del settore (SME) intervengono solo su campioni ambigui o complessi. Il loro feedback viene utilizzato per espandere il dataset e raffinare le annotazioni.
• Stima del Dataset: Un meccanismo matematico calcola una metrica "Gap" ($GAP_{Feature}$) per ogni feature SQL. Questa metrica combina la rappresentazione del dataset ($GAP_{Dict}$) e la qualità del modello ($GAP_{Quality}$) per dare priorità automaticamente alle feature che richiedono campioni di addestramento aggiuntivi per l'iterazione successiva.

5. Pipeline Sperimentali

Lo studio valuta quattro pipeline distinte:

1. Conversione Diretta: Conversione basata su prompt standard senza contesto esterno.
2. Conversione Consapevole della Storia (History-Aware): Incorpora i chunk generati precedentemente come contesto per mantenere la coerenza dello stato.
3. RAG Strategia A: Recupera un contesto eterogeneo (regole, documentazione, codice).
4. RAG Strategia B: Recupera solo coppie di esempi di trasformazione.

Risultati Chiave

Lo studio ha valutato molteplici modelli (Qwen32B, Qwen7B, varianti di GPT-4) contro lo strumento tradizionale Ora2PG su un dataset di oltre 1.800 file stratificati per dimensione.

• Superiorità degli LLM con Fine-tuning: Il modello Qwen32B sottoposto a fine-tuning (Qwen32B-ft2) ha superato costantemente tutti gli altri candidati e lo strumento Ora2PG. Nella pipeline di Conversione Diretta, ha raggiunto un'efficienza di conversione dei file del 74,57%, rispetto al 49,66% di Ora2PG.
• Riduzione degli Errori: Il fine-tuning ha ridotto significativamente i tassi di errore sintattico (SER). Il modello Qwen32B-ft2 ha prodotto il minor numero di file contenenti errori (205) e il minor conteggio totale di errori (3.554) nella pipeline di conversione, mentre i modelli base e gli LLM più piccoli hanno accumulato volumi di errore significativamente più alti.
• Copertura delle Feature: I modelli con fine-tuning hanno dimostrato una superiore allineamento con le distribuzioni attese delle feature di PostgreSQL. Ad esempio, Qwen32B-ft2 ha raggiunto il 72,3% di copertura per CORE_SQL e il 69,1% per la conversione da PL/SQL a PL/pgSQL, mentre Ora2PG ha mostrato una sostanziale perdita di informazioni (ad esempio, il 47,5% di copertura PL/SQL) e una sottoproduzione sistematica della logica procedurale.
• Impatto del RAG: Sebbene il RAG abbia fornito benefici aggiuntivi, la pipeline history-aware e la conversione diretta con modelli fine-tuned hanno prodotto i risultati più stabili. La Strategia A (Ibrida) ha offerto robustezza per le feature complesse, mentre la Strategia B ha mostrato prestazioni elevate quando erano disponibili dataset di coppia di alta qualità.
• Impatto Economico: Gli autori stimano che un singolo ciclo di fine-tuning abbia permesso la migrazione automatica di circa 27.690 file in più rispetto a quanto farebbe Ora2PG. Ciò si traduce in una riduzione di circa 9 mensilità di lavoro manuale di un esperto (SME) per un codebase di 100.000 file.

Significato e Rivendicazioni

Il documento sostiene di fornire una base metodologica per la migrazione di database su larga scala che affronta il divario tra l'automazione basata su regole e la complessità semantica dei moderni codebase.

• Controllo Qualità Iterativo: Il contributo primario è il meccanismo di "stima del dataset basato sul GAP", che trasforma la migrazione da un compito di ingegneria statico a un loop di ottimizzazione guidato dai dati. Ciò consente un'espansione mirata del dataset, assicurando che i miglioramenti del modello siano guidati da deficit di prestazione specifici piuttosto che da un accumulo cieco di dati.
• Scalabilità: Il framework è progettato per gestire librerie di livello enterprise (100.000+ file) scomponendo la qualità della migrazione in metriche a livello di feature, prevenendo la crescita esponenziale del carico di lavoro manuale associato ai metodi tradizionali.
• Approccio Ibrido: Lo studio valida che una combinazione di fine-tuning a due stadi (per la competenza strutturale) e RAG (per l'ancoraggio contestuale) produce risultati superiori rispetto a uno qualsiasi dei due approcci presi singolarmente o agli strumenti tradizionali basati su regole.
• Viabilità Economica: Quantificando la riduzione dell'impegno manuale, il paper sostiene che la migrazione basata su LLM non è solo tecnicamente fattibile, ma anche economicamente vantaggiosa, offrendo un rapido ROI anche con una modesta preparazione iniziale del dataset (30.000 campioni di addestramento preparati in sei sprint).

Gli autori concludono che, sebbene la validazione a livello di esecuzione rimanga un obiettivo futuro, il framework proposto stabilisce con successo un approccio scalabile, preciso ed economicamente sostenibile per la modernizzazione dei database aziendali.