💻 computer science

Leveraging LLMs for Multi-File DSL Code Generation: An Industrial Case Study

Questo caso di studio industriale presso BMW dimostra che il fine-tuning di LLM orientati al codice con una rappresentazione JSON strutturata e che preserva i percorsi delle gerarchie dei repository supera significativamente il prompting di base e l'apprendimento one-shot nella generazione di artefatti DSL multi-file accurati che guidano la generazione di codice a valle.

Autori originali: Sivajeet Chand, Kevin Nguyen, Peter Kuntz, Alexander Pretschner

Pubblicato 2026-04-28

📖 5 min di lettura🧠 Approfondimento

CC BY 4.0

Autori originali: Sivajeet Chand, Kevin Nguyen, Peter Kuntz, Alexander Pretschner

Articolo originale sotto licenza CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ Questa è una spiegazione generata dall'IA dell'articolo qui sotto. Non è stata scritta né approvata dagli autori. Per precisione tecnica, consulta l'articolo originale. Leggi il disclaimer completo

Immagina di essere un architetto capo che lavora per una gigantesca azienda edile (BMW). Il tuo lavoro consiste nel progettare nuovi edifici (configurazioni di mercato) per diverse città.

Nel vecchio modo di operare, dovevi scrivere manualmente ogni singola pianta, schema elettrico e diagramma idraulico su fogli separati. Se volevi aggiungere una nuova finestra alla cucina, dovevi ricordare di aggiornare il piano elettrico, il piano idraulico e il piano strutturale, tutti perfettamente sincronizzati. Se mancava anche un solo dettaglio minuscolo, l'intero edificio non poteva essere costruito e la squadra di costruzione (il generatore di codice) rimaneva bloccata.

Questo documento riguarda l'insegnare a un assistente robot superintelligente (un Modello Linguistico su larga scala, o LLM) a svolgere questa burocrazia manuale per te. Ma c'è un problema: il robot non ha mai visto le tue piante specifiche prima d'ora e deve aggiornare più documenti interconnessi contemporaneamente basandosi su una sola frase di istruzioni da parte tua.

Ecco come i ricercatori hanno insegnato al robot a farlo:

1. Il Problema: L'Enigma "Un'Istruzione, Molti File"

Di solito, l'IA è brava a scrivere una singola storia o un singolo pezzo di codice. Ma in questa azienda, una singola richiesta come "Aggiungi un nuovo tipo di prestito per il mercato tedesco" richiede di modificare file in cinque cartelle diverse. Se il robot modifica il file principale ma dimentica di aggiornare il file che elenca tutti i tipi di prestito, l'intero sistema si rompe.

2. La Soluzione: Appiattire la Libreria

Per aiutare il robot a comprendere l'intero progetto in una sola volta, i ricercatori non gli hanno fornito file per file. Invece, hanno preso l'intera "libreria" di piante (la struttura delle cartelle) e l'hanno appiattita in un unico libro gigante e organizzato (un singolo documento JSON).

L'Analogia: Immagina di prendere una scrivania disordinata con 20 cartelle diverse e di stendere ogni singola pagina su un unico tavolo gigante, ma mantenendole in file ordinati in modo da sapere quale pagina appartiene a quale cartella. Ora, il robot può guardare l'intero tavolo tutto insieme e dire: "Ok, vedo dove devono andare le modifiche".

3. L'Addestramento: Tre Modi per Insegnare al Robot

I ricercatori hanno provato tre modi diversi per insegnare a questo robot questo lavoro specifico:

Il "Partire da Zero" (Zero-Shot): Hanno semplicemente dato al robot l'istruzione e il libro appiattito dicendo: "Risolvi".
- Risultato: Il robot era bravo a mantenere le pagine nell'ordine giusto, ma spesso inventava dettagli errati o mancava connessioni minuscole. Era come uno studente che conosce l'alfabeto ma non ha ancora imparato la grammatica.
L'"Esempio" (One-Shot): Hanno dato al robot l'istruzione, il libro, più un esempio di un lavoro precedente svolto correttamente. "Ecco come abbiamo aggiunto una finestra l'ultima volta; fallo così."
- Risultato: Questo ha aiutato il robot a ottenere la struttura giusta (le pagine sono rimaste nelle cartelle giuste), ma ha ancora faticato con i dettagli specifici e complicati della nuova richiesta.
Il "Corso Intensivo" (Fine-Tuning): Hanno preso il robot e gli hanno mostrato centinaia di esempi di piante "Prima" e "Dopo". Non glieli hanno solo mostrati; hanno aggiustato il cervello interno del robot (usando una tecnica chiamata QLoRA) in modo che apprendesse le regole specifiche delle piante di questa azienda.
- Risultato: Questo è stato il vincitore. Il robot è diventato un esperto. Poteva guardare una richiesta e produrre un set di modifiche perfettamente sincronizzato su tutti i file.

4. I Risultati: Ha Funzionato?

I ricercatori hanno testato il robot con compiti reali e hanno fatto controllare il lavoro da esperti umani.

Struttura: Il robot fine-tuned era quasi perfetto nel mantenere i file nelle cartelle giuste e nel non inventare cartelle finte. Ha ottenuto un punteggio perfetto (1.0) nel mantenere la "forma" del progetto corretta.
Dettagli: Era molto bravo sul contenuto effettivo, ottenendo circa il 66% delle modifiche esattamente corrette e l'84% delle modifiche "abbastanza vicine" da essere utili.
La Realtà del "Quasi": Il robot era così bravo che quando falliva, era solitamente solo un piccolo errore di battitura o un numero sbagliato, non un file mancante. Era come uno chef che cucina un pasto perfetto ma usa per sbaglio il sale invece dello zucchero. La struttura era giusta; il sapore era solo leggermente sbagliato.

5. Cosa Hanno Detto gli Esperti Umani

I ricercatori hanno chiesto a quattro architetti senior (sviluppatori) di revisionare il lavoro del robot.

Verdetto: L'hanno amato. Gli hanno dato voti alti per leggibilità e struttura.
Risparmio di Tempo: Hanno stimato che per progetti piccoli e semplici, il robot avrebbe potuto risparmiare loro dal 40% all'80% del loro tempo. Tuttavia, per progetti massicci e complessi, il robot era ancora un "aiutante" che necessitava di un umano per ricontrollare i dettagli finali.
Il Problema: Il robot a volte si confondeva su quale tipo specifico di componente utilizzare in uno scenario complesso, richiedendo un intervento umano per una rapida correzione.

La Conclusione

Questo documento dimostra che puoi insegnare a un'IA a gestire progetti complessi con più file se:

Organizzi i file in un singolo formato facile da leggere.
Le dai un "corso intensivo" specifico (fine-tuning) sulle tue regole specifiche.

Non sostituirà ancora gli architetti umani, ma può svolgere il lavoro pesante di stendere le piante, risparmiando loro ore di lavoro tedioso e permettendo loro di concentrarsi sulle parti creative.

1. Enunciato del Problema

Il paper affronta la sfida di utilizzare i Modelli Linguistici su Grande Scala (LLM) per generare e modificare Linguaggi Specifici di Dominio (DSL) a scala di repository in un contesto industriale.

Contesto: BMW Financial Services utilizza un DSL personalizzato basato su Xtext per generare codice Java/TypeScript a valle. Questo DSL funge da fonte autorevole per le configurazioni specifiche di mercato.
La Sfida: Attualmente, gli sviluppatori scrivono e aggiornano manualmente i file DSL. Una singola istruzione in linguaggio naturale (NL) richiede spesso modifiche coordinate su più file e cartelle (ad esempio, aggiungere un attributo in un livello richiede aggiornamenti nei livelli correlati).
Limitazioni degli LLM Attuali: Sebbene gli LLM performino bene su codice generico, la loro applicabilità ai DSL aziendali è poco esplorata. Gli ostacoli principali includono:
- Dipendenze multi-file: Mantenere la coerenza attraverso una struttura di cartelle partendo da un singolo prompt.
- Sintassi Rigida: I DSL hanno grammatiche rigide; errori minori compromettono la generazione del codice a valle.
- Limiti del Contesto: Generare uno stato completo del progetto (più file) spesso supera le finestre di contesto standard.
- Difficoltà di Valutazione: Le metriche standard (come BLEU) non riescono a catturare la fedeltà strutturale o la correttezza delle modifiche in cambiamenti a scala di repository.

2. Metodologia

Gli autori hanno sviluppato una pipeline end-to-end che include la costruzione del dataset, la rappresentazione del compito, l'adattamento del modello e un framework di valutazione specializzato.

A. Rappresentazione del Compito: Linearizzazione

Per abilitare la generazione di una risposta singola per un repository multi-file, gli autori hanno linearizzato l'intera gerarchia delle cartelle DSL in un unico documento JSON strutturato.

Struttura: Le cartelle sono oggetti JSON annidati, i file sono chiavi e i contenuti dei file sono valori stringa (che preservano le nuove righe).
Input/Output: Il modello riceve una coppia (Istruzione, JSON di Contesto) e genera un (JSON Target) che rappresenta lo stato completamente aggiornato del progetto.
Vantaggio: Ciò permette all'LLM di operare a livello di "radice del progetto", apprendendo le dipendenze tra file in un singolo passaggio di generazione.

B. Costruzione del Dataset

Fonte: Un dataset proprietario e anonimizzato costruito manualmente da esperti DSL (non esiste alcun dataset pubblico per questo DSL).
Dimensione: 774 esempi di addestramento e 105 esempi di valutazione tenuti da parte.
Operazioni: Tre famiglie di compiti: (1) Creare un nuovo mercato, (2) Aggiungere funzionalità (attributi/prodotti), (3) Eliminare funzionalità.
Varianti: Include varianti "contesto completo" (intero progetto) e "contesto minimo" (solo file rilevanti) per testare la riduzione del rumore.
Divisione: Divisione accurata per prevenire la fuoriuscita di dati tra le varianti delle istruzioni.

C. Selezione e Adattamento del Modello

Lo studio ha valutato due LLM per codice open-source, istruiti con istruzioni (7B parametri): Qwen2.5-Coder e DeepSeek-Coder. Sono state testate tre configurazioni:

Zero-Shot (Baseline): Istruzione grezza + contesto linearizzato.
Apprendimento In-Context One-Shot (ICL): Aggiunta di un riepilogo delle regole grammaticali del DSL e di un esempio dimostrativo.
Fine-Tuning Efficiente in Parametri (PEFT): Utilizzo di QLoRA (quantizzazione a 4 bit) con rango $r=16$ per addestrare finemente i modelli sul dataset proprietario.

D. Framework di Valutazione

Gli autori hanno introdotto una strategia di valutazione ibrida che combina metriche standard con misure specifiche per il compito:

Metriche Standard: Corrispondenza Esatta (EM), BLEU, Controllo JSON valido.
Metriche Personalizzate:
- Somiglianza delle Modifiche: Si concentra solo sulle righe che sono state effettivamente modificate (ignorando il contesto invariato), utilizzando la distanza di Levenshtein a livello di token per penalizzare gli errori nelle modifiche.
- Fedeltà Strutturale: Misura la precisione/recall/F1 dell'albero di cartelle/file generato rispetto all'obiettivo, assicurando che non vi siano file spurii o mancanti.
Validazione:
- Accettazione della Catena di Strumenti: Esecuzione del DSL generato attraverso il generatore DSL-to-code esistente per verificare errori di compilazione/build.
- Valutazione Umana: Sondaggio tra 4 sviluppatori DSL senior che hanno valutato qualità, utilità e risparmio di tempo.

3. Contributi Chiave

Caso di Studio Industriale: Primo rapporto dettagliato sull'applicazione degli LLM alla generazione di DSL multi-file a scala di repository in un ambiente aziendale ad alto rischio (BMW).
Linearizzazione Strutturata: Un metodo innovativo per codificare gerarchie complesse di cartelle in un singolo input/output JSON, abilitando la generazione alla radice del progetto e l'apprendimento delle dipendenze tra file.
Valutazione Specifica per il Compito: Un framework che va oltre la sovrapposizione testuale per misurare la correttezza delle modifiche (somiglianza delle modifiche) e la fedeltà strutturale, critici per i DSL.
Confronto Empirico: Un confronto rigoroso tra Zero-shot, One-shot ICL e fine-tuning QLoRA, dimostrando che il fine-tuning è essenziale per la correttezza rigorosa in questo dominio.

4. Risultati

Lo studio ha valutato i modelli sul set tenuto da parte utilizzando le metriche definite.

RQ1 (Fattibilità): I modelli di base (Zero-shot) hanno prodotto strutture JSON valide ma hanno fallito nella correttezza rigorosa (Corrispondenza Esatta: Qwen 0.076, DeepSeek 0.371). Hanno potuto formattare l'output ma hanno faticato con le dipendenze semantiche.
RQ2 (Impatto dell'Adattamento):
- One-Shot ICL: Ha migliorato significativamente la correttezza strutturale (specialmente per Qwen, passando da 0.663 a 0.958) ma ha avuto un impatto limitato sulla corrispondenza esatta o sulla correttezza delle modifiche complesse.
- Fine-Tuning (QLoRA): Ha fornito i guadagni più significativi.
  - DeepSeek-FT: Ha raggiunto una Corrispondenza Esatta di 0.657, una Somiglianza delle Modifiche di 0.841 e una Fedeltà Strutturale di 1.000.
  - Qwen-FT: Ha raggiunto una Corrispondenza Esatta di 0.629, una Somiglianza delle Modifiche di 0.834 e una Fedeltà Strutturale di 0.990.
- Insight Chiave: Il fine-tuning era necessario per padroneggiare le dipendenze tra file e le semantiche DSL. L'ICL ha aiutato con la formattazione ma non con la logica profonda.
RQ3 (Utilità per gli Sviluppatori):
- Revisione Umana: Gli sviluppatori senior hanno valutato altamente le uscite fine-tuned (Media 4.50/5), in particolare per la Fedeltà Strutturale e la Leggibilità (5.00/5).
- Utilità: Valutata 4.50/5. Gli sviluppatori hanno stimato un risparmio di tempo del 40–80% per la creazione di nuovi mercati (bootstrapping), sebbene i risparmi diminuiscano per mercati grandi e complessi che richiedono correzioni manuali.
- Validazione della Catena di Strumenti: Il generatore ha elaborato con successo le operazioni "Crea" e "Elimina" (100% di successo) ma ha avuto un successo inferiore (75%) per le operazioni "Aggiungi" a causa di tipi di attributo allucinati o violazioni di regole.

5. Significato e Implicazioni

Fattibilità da NL a DSL: Lo studio dimostra che, con un adeguato adattamento (fine-tuning) e rappresentazione del contesto (linearizzazione), gli LLM possono generare in modo affidabile set di modifiche DSL complessi e multi-file da linguaggio naturale.
Il Fine-Tuning è Critico: Per i DSL aziendali con grammatiche rigide e dipendenze tra file, l'apprendimento in contesto è insufficiente per compiti ad alta precisione; è necessario un fine-tuning efficiente in parametri per raggiungere un'accuratezza di livello produttivo.
Cambiamento nella Valutazione: Le metriche standard come BLEU sono fuorvianti per i cambiamenti a scala di repository. Le metriche proposte "Somiglianza delle Modifiche" e "Fedeltà Strutturale" sono essenziali per valutare l'utilità effettiva del codice generato.
Percorso di Implementazione: Sebbene altamente efficace per il boilerplate e il bootstrapping dei mercati, l'adozione completa richiede l'integrazione di sistemi di sicurezza automatizzati (ad esempio, decoding consapevole della grammatica o loop di feedback del generatore) per intercettare i rimanenti errori semantici "quasi mancati", in particolare nelle operazioni "Aggiungi".

In conclusione, questo paper fornisce una guida per integrare gli LLM nei flussi di lavoro di ingegneria del software industriale che coinvolgono DSL, dimostrando che la combinazione di contesto linearizzato e fine-tuning può automatizzare significativamente la generazione di codice a scala di repository mantenendo l'integrità strutturale.