A framework for assessing the capabilities of code generation of constraint domain-specific languages with large language models

Questo articolo propone un framework generico per valutare le capacità dei modelli linguistici di grandi dimensioni nella generazione di codice per linguaggi specifici di dominio (DSL) basati su vincoli, come OCL e Alloy, dimostrando che, sebbene le prestazioni siano inferiori rispetto a linguaggi generici come Python, tecniche come la riparazione del codice e tentativi multipli possono migliorare significativamente i risultati.

L'essenziale

Immagina di avere un cuoco robot (l'Intelligenza Artificiale o LLM) incredibilmente talentuoso. Questo robot ha cucinato milioni di piatti (codici) in cucine famose come quella della "Python" (la cucina più famosa al mondo), imparando a memoria ogni ricetta.

Tuttavia, il problema sorge quando gli chiedi di cucinare un piatto molto specifico e raro, come una ricetta tradizionale di un piccolo villaggio che nessuno conosce bene (le linguaggi di dominio specifico o DSL, come OCL e Alloy). Il robot, non avendo mai visto queste ricette, tende a sbagliare: usa ingredienti sbagliati, dimentica passaggi o crea piatti che non hanno senso.

Gli autori di questo paper, David, Lola e Robert, hanno deciso di costruire un manuale di ispezione della cucina (un framework) per capire quanto è bravo questo robot quando cucina queste ricette rare, e come possiamo aiutarlo a fare meglio.

Ecco come funziona il loro sistema, spiegato con metafore semplici:

1. Il Problema: Il Robot si perde nelle ricette rare

Quando il robot cucina per la cucina "Python", è un genio. Ma quando deve scrivere regole per sistemi complessi (come dire: "in un'assicurazione, un incidente deve coinvolgere esattamente due auto"), si confonde.

• Perché? Perché ha visto poche ricette di quel tipo durante il suo apprendimento.
• La sfida: Deve capire non solo la ricetta, ma anche il contesto (il modello del dominio). È come se gli chiedessimo di scrivere una regola per un gioco di carte che non ha mai visto, basandosi solo su una descrizione a parole.

2. La Soluzione: Il "Manuale di Ispezione" (Il Framework)

Gli autori hanno creato un sistema per testare il robot in modo scientifico. Immagina una catena di montaggio con quattro stazioni di controllo:

• Stazione A: La Preparazione dell'Ordine (Prompting)
  Qui decidiamo come dare l'ordine al robot. Possiamo dirgli: "Ecco la ricetta, cucinala" (semplice) oppure "Ecco la ricetta, spiegami prima gli ingredienti, poi cucinala" (più complesso). Hanno provato 9 modi diversi di dare l'ordine per vedere quale funziona meglio.

  • Metafora: È come decidere se dare al cuoco una ricetta scritta su un foglio stropicciato o su un libro di cucina illustrato.

• Stazione B: La Cottura (Generazione del Codice)
  Il robot prova a cucinare. A volte, invece di cucinare una volta sola, gli facciamo provare 3 volte (tentativi multipli). Se la prima volta brucia il piatto, proviamo di nuovo.

  • Scoperta: Far provare il robot più volte aumenta le chance che il piatto venga buono.

• Stazione C: Il Controllo di Forma (Well-formedness)
  Prima di assaggiare, controlliamo se il piatto è "presentabile". Il robot ha usato le forchette giuste? Ha scritto le parole nel modo corretto? Se il robot ha scritto "cucina" invece di "cuocere", il piatto viene scartato subito.

  • Il Riparatore: Se il piatto è bruttino ma salvabile, lo diamo al robot con un messaggio: "Ehi, hai dimenticato il sale, riprova!". Il robot prova a sistemarlo una sola volta.

• Stazione D: Il Controllo di Gusto (Correttezza)
  Ora assaggiamo. Il piatto fa quello che doveva fare? Se la ricetta diceva "due auto", il piatto contiene davvero due auto?

  • Qui usano un giudice robot (un altro LLM) che assaggia il piatto e dice: "Buono" o "Cattivo". Hanno scoperto che questo giudice robot è abbastanza bravo, anche se non perfetto come un umano.

3. Cosa hanno scoperto? (I Risultati)

Dopo aver fatto cucinare al robot quasi 100.000 piatti (esperimenti), ecco le loro conclusioni principali:

• La cucina conta più del cuoco: Se chiedi al robot di cucinare in "Python", viene quasi sempre bene. Se chiedi di cucinare in "OCL" o "Alloy" (le ricette rare), spesso sbaglia. Il robot ha bisogno di aver visto molte ricette di quel tipo specifico per imparare.
• Il modo di dare l'ordine non è tutto: Cambiare il modo in cui scrivi la richiesta (il "prompt") ha un impatto minimo. Non serve scrivere un romanzo per ottenere un buon risultato; spesso una richiesta semplice basta, purché il robot conosca già la ricetta.
• La pazienza paga: Far provare il robot più volte (tentativi multipli) e fargli riparare gli errori è la strategia vincente. È come dire a un bambino: "Se sbagli, riprova e correggi". Il risultato finale è molto migliore.
• Tutto insieme o uno alla volta? È meglio dare al robot un blocco di ricette da cucinare tutte insieme (stesso contesto) piuttosto che una alla volta. Se gli dai una ricetta alla volta, potrebbe dimenticare come ha chiamato gli ingredienti nella ricetta precedente, creando confusione.

In sintesi

Questo paper ci dice che l'Intelligenza Artificiale è un ottimo assistente, ma non è magica. Per farla funzionare bene con linguaggi di programmazione speciali e rari, non serve complicare le istruzioni. Basta:

1. Scegliere un modello (robot) che conosca già quel tipo di cucina.
2. Farlo provare più volte.
3. Lasciare che corregga i suoi errori.

È un manuale pratico per chiunque voglia usare l'AI per scrivere codice, specialmente quando si tratta di regole complesse e specifiche, evitando di farsi ingannare da un robot che sembra intelligente ma che, senza la giusta guida, rischia di cucinare un disastro.

Sommario tecnico

Ecco una sintesi tecnica dettagliata del paper in italiano, strutturata secondo le sezioni richieste.

Titolo del Paper

Un framework per la valutazione delle capacità di generazione di codice dei linguaggi di dominio specifico (DSL) vincolati con i Large Language Models (LLM)

1. Il Problema

I Large Language Models (LLM) hanno dimostrato grandi capacità nella generazione di codice per linguaggi di programmazione general-purpose (GPL) come Python, Java o C#, grazie alla vastità dei dati di addestramento disponibili. Tuttavia, le loro prestazioni crollano significativamente quando si tratta di linguaggi di dominio specifico (DSL), in particolare quelli orientati alla definizione di vincoli e query formali come OCL (Object Constraint Language) e Alloy.

Le sfide specifiche per questi linguaggi includono:

• Risorse limitate: La scarsità di esempi di codice pubblici rende difficile per gli LLM apprendere sintassi e semantica precise.
• Dipendenza dal contesto: La generazione di vincoli richiede la gestione simultanea del modello di dominio (lo schema) e del vincolo stesso, un compito complesso per i modelli.
• Natura dichiarativa: A differenza dei linguaggi procedurali, i vincoli non sono sempre eseguibili direttamente ma devono essere verificati o testati contro campioni positivi e negativi.
• Globalità dei vincoli: I vincoli sono spesso globali e interagiscono tra loro, rendendo difficile trattarli in isolamento senza causare effetti collaterali indesiderati.

Attualmente manca un framework sistematico per valutare e confrontare le strategie di generazione del codice per questi linguaggi, rendendo difficile per gli sviluppatori scegliere l'approccio ottimale.

2. Metodologia

Gli autori propongono un framework modulare e altamente configurabile per valutare la generazione di codice basata su LLM. Il framework è progettato per essere indipendente dal modello e dal linguaggio, supportando sia GPL che DSL.

Architettura del Framework

Il processo è suddiviso in quattro fasi principali (illustrate nel diagramma di flusso del paper):

1. Costruzione del Prompt (A): Il sistema genera prompt utilizzando diversi template che combinano:
   • Descrizione del dominio (testuale o formale).
   • Modello di dominio (es. PlantUML o testo).
   • Tecniche di augmentazione: Richiesta di spiegare il modello o generare il modello stesso prima del task di codifica.
   • Strategie di consegna: Invio in batch (tutti i task insieme), sequenziale concatenato o isolato (un task alla volta).
2. Generazione ed Estrazione (B): L'LLM genera il codice. Il sistema supporta multipli tentativi (k tentativi) per lo stesso task per aumentare la probabilità di successo.
3. Verifica della Correttezza Sintattica (Well-formedness) (C): Il codice generato viene validato tramite parser o compilatori specifici del linguaggio. Se fallisce, viene attivato un processo di riparazione del codice (Code Repair) in un singolo passaggio: l'errore e il messaggio di errore vengono inviati all'LLM per generare una versione corretta.
4. Verifica della Correttezza Semantica (Correctness) (D): Il codice ben formato viene testato per verificare se soddisfa la specifica funzionale.
   • Per Python: Esecuzione di unit test.
   • Per OCL/Alloy: Utilizzo di strumenti specifici (USE OCL, Alloy Analyzer) o valutazione tramite LLM-as-a-Judge (un LLM valuta se il codice rispetta la specifica naturale).

Metriche di Valutazione

• Accuracy (Pass@1): Percentuale di codice corretto al primo tentativo.
• Pass@k: Probabilità che almeno uno dei k tentativi generati sia corretto.

3. Contributi Chiave

Il paper apporta tre contributi principali al campo della generazione di codice con LLM:

1. Framework di Valutazione Modulare: Un sistema flessibile che permette di parametrizzare tutte le decisioni del processo (template del prompt, scelta dell'LLM, uso di riparazione, numero di tentativi), consentendo confronti sistematici tra diverse configurazioni.
2. Studio Comparativo su DSL Vincolati: Un'analisi approfondita delle sfide specifiche di OCL e Alloy, confrontate con Python, arricchendo i dataset esistenti con dati sintetici (descrizioni di dominio generate da LLM).
3. Esperimenti su Larga Scala: Esecuzione di oltre 98.000 task di generazione di codice esplorando tutte le possibili configurazioni (9 template di prompt, 4 LLM, 3 linguaggi, strategie di consegna e riparazione) per identificare le migliori pratiche.

4. Risultati Sperimentali

Gli esperimenti sono stati condotti su quattro LLM (GPT-4o, GPT-4o-mini, DeepSeek Coder 6.7B, Llama 3.1) e tre linguaggi (Python, OCL, Alloy).

• Impatto del Linguaggio: Python ottiene prestazioni nettamente superiori sia per la correttezza sintattica che semantica. OCL e Alloy mostrano tassi di fallimento più alti nella well-formedness e nella correttezza, a causa della scarsità di dati di addestramento e della complessità dei vincoli.
• Impatto dell'LLM: I modelli proprietari (GPT-4o) superano significativamente i modelli open-source (DeepSeek, Llama 3.1) per i DSL. I modelli open-source hanno spesso difficoltà a generare codice sintatticamente valido per OCL/Alloy, rendendoli poco pratici per questi task senza ulteriore addestramento.
• Prompt Engineering: L'analisi statistica (Chi-quadro) mostra che, in molti casi, la scelta del template del prompt ha un impatto minimo o non significativo sulla qualità finale, specialmente quando il modello conosce già il linguaggio. Non esiste un template "migliore" universale; le differenze sono spesso legate a combinazioni specifiche linguaggio-LLM.
• Strategia di Consegna: L'invio in batch (tutti i vincoli insieme) è generalmente preferibile all'invio isolato, poiché riduce il rischio di incoerenze nel modello di dominio tra diversi vincoli generati separatamente.
• Riparazione e Multipli Tentativi:
  • Aumentare il numero di tentativi (k) migliora linearmente la probabilità di successo (Pass@k), sebbene con rendimenti decrescenti.
  • La riparazione del codice (Code Repair) aumenta la correttezza del 10-20%.
  • La strategia ottimale è la combinazione di multipli tentativi + riparazione, che massimizza la qualità del codice, sebbene comporti un costo computazionale più elevato.

5. Significato e Implicazioni

Questo lavoro è fondamentale per l'adozione degli LLM nell'ingegneria del software formale e nei sistemi critici dove i vincoli sono essenziali.

• Guida Pratica: Fornisce linee guida concrete per gli sviluppatori (es. "Prioritizzare modelli con conoscenza pregressa del linguaggio", "Usare tentativi multipli e riparazione", "Evitare prompt engineering eccessivo se il modello è competente").
• Validazione dell'Automazione: Dimostra che l'approccio "LLM-as-a-Judge" è una valida alternativa alla valutazione manuale per scalare gli esperimenti, pur con una discrepanza del 15-30% rispetto agli esperti umani (accettabile in contesti di generazione di codice complessa).
• Sostenibilità: Identifica che per i DSL a risorse limitate, la scelta del modello è più critica dell'ottimizzazione del prompt.
• Riproducibilità: Il framework e i dati sono resi disponibili open-source, permettendo alla comunità di estendere la valutazione ad altri linguaggi e strategie (es. RAG, fine-tuning).

In conclusione, il paper stabilisce che mentre gli LLM sono promettenti per i DSL vincolati, la loro efficacia dipende fortemente dalla scelta del modello e dall'uso di strategie di recupero (tentativi multipli e riparazione), piuttosto che da complesse ingegnerizzazioni del prompt.