💻 computer science

Customizing an LLM for Enterprise Software Engineering

Questo documento presenta Gemini for Google (GfG), un modello linguistico di grandi dimensioni specializzato adattato all'ecosistema interno di ingegneria del software di Google attraverso un processo completo end-to-end di curatela dei dati e mid-training, che ha migliorato significativamente l'efficienza degli sviluppatori e la qualità del codice in uno studio su larga scala, fornendo al contempo un progetto replicabile per la personalizzazione dei modelli aziendali.

Autori originali: Aditya Kini, Satish Chandra, Milad Hashemi, Saksham Thakur, Aditya Pandey, Vincent Nguyen, Marc Brockschmidt, Franjo Ivančić, Danny Tarlow, Parthasarathy Ranganathan, Petros Maniatis, Ahmed Omran, Zah

Pubblicato 2026-05-21

📖 5 min di lettura🧠 Approfondimento

CC BY 4.0

Autori originali: Aditya Kini, Satish Chandra, Milad Hashemi, Saksham Thakur, Aditya Pandey, Vincent Nguyen, Marc Brockschmidt, Franjo Ivančić, Danny Tarlow, Parthasarathy Ranganathan, Petros Maniatis, Ahmed Omran, Zaheer Abbas, Anita Gergely, Martin Sevenich, Gufeng Zhang, Amy Hua, Alexander Frömmgen

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 avere uno chef brillante e di livello mondiale (il modello AI originale). Questo chef può cucinare quasi tutto: pasta italiana, dolci francesi o sushi giapponese. È stato addestrato su ogni libro di ricette presente nella biblioteca pubblica.

Tuttavia, tu lavori in una mensa aziendale massiccia e ad alta tecnologia (l'ecosistema software interno di Google). Qui, le regole sono strane. Non usi forni standard; usi macchine proprietarie costruite su misura. Gli ingredienti sono unici e le "ricette" (codice) hanno nomi specifici e bizzarri che nessuno al di fuori dell'edificio conosce.

Se chiedi allo chef di livello mondiale di preparare un pasto per la tua mensa, potrebbe provare a usare una ricetta standard. Sembrerà buono, ma non funzionerà con le tue macchine e potrebbe rovinare il cibo.

Questo documento descrive come Google ha preso quello chef di livello mondiale e gli ha fornito un campo di addestramento specializzato per diventare lo chef perfetto per la loro mensa specifica. Chiamano questo nuovo chef "Gemini for Google" (GfG).

Ecco come l'hanno fatto, suddiviso in passaggi semplici:

1. Raccolta del "Libro delle Ricette Segrete"

Invece di dare allo chef semplicemente più libri di cucina pubblici, il team ha raccolto un'enorme biblioteca di documenti interni. Non si trattava solo di codice; era l'intera storia di come i loro ingegneri lavorano:

Il registro delle "Critiche": Hanno esaminato migliaia di conversazioni in cui ingegneri senior revisionavano il codice, dicevano "correggi questo" e l'ingegnere junior lo correggeva. Questo ha insegnato all'AI ad accettare feedback e migliorare.
Il registro "Rottura-Riparazione": Hanno osservato come gli ingegneri riparavano le build rotte (quando il software smette di funzionare). L'AI ha imparato: "Oh, quando appare questo errore, la soluzione è solitamente modificare questa riga specifica".
Il registro della "Velocità": Hanno studiato come gli ingegneri rendevano i programmi più veloci, insegnando all'AI a individuare i colli di bottiglia e suggerire correzioni.
Il registro della "Chat": Hanno utilizzato sessioni interne di domande e risposte in cui gli ingegneri chiedevano informazioni su strumenti interni strani, insegnando all'AI i nomi specifici e il gergo aziendale.

2. La "Chirurgia" di Addestramento Intermedio

Di solito, o addestri un modello da zero (inizi con un cervello da neonato) o modifichi solo la fine (fine-tuning). Google ha fatto qualcosa di intermedio.

Pensa all'AI originale come a uno studente che ha finito le superiori (pre-addestramento generale).

Il Problema: Se inizi semplicemente a insegnare loro diritto societario avanzato immediatamente, potrebbero dimenticare come fare matematica di base o scrivere un semplice saggio. Questo è chiamato "dimenticanza catastrofica".
La Soluzione: Invece di ricominciare dall'ultimo anno di scuola superiore, sono tornati al terzo anno dello studente. Hanno preso lo studente, gli hanno dato il "Libro delle Ricette Segrete" (i dati interni) e gli hanno permesso di continuare la sua istruzione da quel punto. In questo modo, lo studente ha mantenuto la sua intelligenza generale ma ha imparato le regole aziendali specifiche.

3. I Risultati: Un Assistente Più Intelligente

Hanno testato questo nuovo "Gemini for Google" rispetto alla versione standard con 29.000 ingegneri. I risultati erano come confrontare un GPS generico con uno che conosce ogni scorciatoia nella tua città specifica:

Meno Scambi: Quando gli ingegneri chiedevano aiuto, l'AI standard richiedeva circa il 23% in più di scambi di conversazione per fare il lavoro correttamente. L'AI specializzata otteneva il risultato giusto al primo tentativo più spesso.
Migliore Sopravvivenza del Codice: Il codice scritto dall'AI specializzata aveva il 17% di probabilità in più di sopravvivere al processo di revisione e di essere effettivamente utilizzato nel prodotto finale. Era meno probabile che venisse respinto o rotto.
Vittorie nel Mondo Reale:
- La Migrazione "Viaggio nel Tempo": Hanno usato l'AI per aggiornare un sistema vecchio di un decennio a uno nuovo. Ha svolto l'80% del lavoro automaticamente, dimezzando i tempi.
- L'"Incollamento Intelligente": Quando un ingegnere copiava codice da un file all'altro, l'AI correggeva automaticamente gli import e i nomi delle variabili in modo che funzionasse immediatamente, risparmiando migliaia di battute.

4. Cosa Hanno Imparato (Le Lezioni)

Il documento evidenzia tre grandi lezioni per chiunque cerchi di fare questo:

Più Dati Non Sono Sempre Meglio: Lanciare tutto all'AI può confonderla. Hanno dovuto scegliere attentamente il mix giusto di dati, altrimenti l'AI avrebbe imparato abitudini sbagliate (come parlare troppo quando dovrebbe solo agire).
Non Combattere il Formato: Hanno imparato che è più facile adattare i loro dati interni per assomigliare allo stile di addestramento originale dell'AI, piuttosto che forzare l'AI a imparare un nuovo formato strano.
I Test Reali Contano: Non puoi testare l'AI solo con un quiz a scelta multipla. Devi osservarla lavorare nel mondo reale. L'ingegnere ha effettivamente accettato il codice? Ha superato la revisione? Questo è il vero punteggio.

La Conclusione

Questo documento non riguarda l'invenzione di un nuovo tipo di cervello. Riguarda prendere un cervello molto intelligente e generico e offrirgli un tirocinio specializzato all'interno di una specifica azienda. Alimentandolo con la storia, gli errori e i successi della propria azienda, hanno creato un'AI che non si limita a "conoscere il codice": conosce il loro codice, i loro strumenti e il loro modo di lavorare.

Riepilogo Tecnico: Personalizzazione di un LLM per l'Ingegneria del Software Aziendale

Enunciato del Problema

Lo sviluppo di software aziendale è un processo evolutivo continuo che coinvolge aggiunte incrementali, revisioni architetturali e manutenzione rigorosa all'interno di ecosistemi proprietari. Sebbene i modelli linguistici su larga scala (LLM) all'avanguardia eccellano nella generazione di codice per nuovi progetti (greenfield) per sfide algoritmiche, spesso mancano di esposizione alle distribuzioni di dati uniche delle grandi organizzazioni, in particolare librerie interne, pattern architetturali e linguaggi specifici di dominio.

Gli approcci standard per colmare questo divario, come la Generazione Aumentata dal Recupero (RAG) o l'adattamento a basso rango (LoRA), presentano limitazioni. I risultati della RAG sono misti e dipendenti dalla qualità del recupero, mentre LoRA manca della capacità rappresentativa necessaria per l'adattamento di dominio su larga scala su corpora di trilioni di token. Addestrare modelli da zero su dati aziendali è spesso proibitivamente costoso e dispendioso in termini di tempo. Di conseguenza, c'è la necessità di una metodologia che specializzi i modelli fondazione per comprendere le semantica aziendali specifiche senza sacrificare le loro capacità di ragionamento generale.

Metodologia

Gli autori introducono Gemini for Google (GfG), un adattamento specializzato del modello fondazione Gemini progettato per l'ecosistema interno di ingegneria del software di Google. Il processo di sviluppo segue un piano in quattro fasi:

1. Curazione dei Dati

Il team ha curato un dataset proprietario di trilioni di token che cattura artefatti diversificati dal ciclo di vita dello sviluppo software. I dati sono categorizzati in sei domini principali per fornire segnali di supervisione distinti:

Generazione di Modifiche: Dati di revisione del codice (codice iniziale, commenti, codice finale) per modellare dialoghi di "critica e raffinamento".
Conoscenza: Documentazione tecnica interna, riferimenti API, documenti di progettazione e repository di domande e risposte.
Problemi e Correzioni: Dati su correzioni di bug, errori di build e fallimenti dei test. Un contributo chiave è il dataset di Correzione delle Build, che utilizza strumentazione IDE granulare per ricostruire le sessioni degli sviluppatori, identificando le modifiche al codice che portano una build dal fallimento al successo.
Generazione di Codice: Codice scritto dagli sviluppatori in vari formati (ad es. Compilazione nel Mezzo) per supportare i compiti di completamento.
Log e Prestazioni: Metadati di produzione, modifiche per l'efficienza e dati di tracciamento distribuito (ad es. Dapper) per insegnare al modello i comportamenti di runtime e gli anti-pattern delle prestazioni.
Cronologie delle Attività: Dati di flusso di lavoro a grana grossa che mappano l'uso degli strumenti e i pattern di ricerca.

2. Formattazione dei Dati

Per gestire compiti eterogenei, gli autori hanno progettato rappresentazioni dati specifiche:

Modifica del Codice Guidata da Istruzioni: Modellare le modifiche al codice come una diff ( $\Delta$ ) dato un frammento di codice originale e un'istruzione.
Riparazione Automatica dei Programmi (APR): Trattare gli errori del compilatore o gli avvisi dell'analisi statica come "commenti di revisione automatizzati" per unificare il feedback umano e quello della macchina.
Compilazione Consapevole del Contesto (FIM): Utilizzare formati Prefisso-Mezzo-Suffisso per migliorare la capacità del modello di generare codice all'interno di file esistenti.
Traiettorie Agentiche Multi-Turno: Ricostruire percorsi di sviluppo latenti (ad es. utilizzando framework ReAct) per catturare la risoluzione iterativa dei problemi.

3. Intervento di Mid-Training

Invece di addestrare da zero o applicare solo il post-training, gli autori hanno impiegato un intervento di mid-training. Questa strategia si dirama da un checkpoint fondamentale (prima della fase finale di convergenza del modello base) e inietta il dataset aziendale curato. Questo approccio preserva le capacità di ragionamento generale mentre inietta conoscenze di dominio profonde.

Sono stati addestrati due varianti di modello: Gemini-Flash (ottimizzato per il completamento del codice a bassa latenza) e Gemini-Pro (ottimizzato per il ragionamento complesso e il refactoring).
Per mitigare la dimenticanza catastrofica, gli autori hanno utilizzato il Data Replay (mescolando i dati di pre-training originali nel mix aziendale) e l'Intervento di mid-training (diramandosi da un checkpoint precedente piuttosto che da quello finale).

4. Post-Training

Dopo il mid-training, il modello ha subito un Fine-Tuning Supervisionato (SFT) utilizzando dataset interni di alta qualità derivati da validazione crowdsourced e log di interazione anonimizzati. Questa fase ha ottimizzato il modello per applicazioni downstream come trasformazione del codice, migrazioni e NL2SQL.

Contributi Chiave

Quadro per l'Adattamento Aziendale: Un piano completo per costruire modelli fondazione specialisti da dati di ingegneria interni, che copre la curazione dei dati, le dinamiche di addestramento e il deployment.
Strategia di Intervento di Mid-Training: Un approccio innovativo per colmare il divario tra pre-training generale e post-training, adattando efficacemente i pesi del modello per un ecosistema specifico mantenendo l'intelligenza generale.
Valutazione su Scala Aziendale: Un ampio studio cieco A/B che coinvolge 29.000 sviluppatori, dimostrando l'utilità pratica del modello personalizzato.

Risultati

Valutazione Offline

Benchmark di Coding: GfG ha superato il baseline Gemini 2.5 Pro nella maggior parte dei benchmark di coding, inclusi un miglioramento del 13% sul formato "Edit Block" di Aider e un miglioramento del 5% su SWE-bench Verified.
Ragionamento Generale: Nonostante l'iniezione di trilioni di token, GfG ha mantenuto o migliorato le prestazioni su benchmark non legati al coding (ad es. ARC AGI, GradQA, MMMU-Pro), confermando che l'intelligenza fondamentale e il ragionamento multimodale sono stati preservati.

Valutazione Online (Studio A/B)

In un esperimento cieco e randomizzato su 29.000 sviluppatori, GfG ha superato significativamente il baseline:

Efficienza: Ha ridotto il numero medio di iterazioni conversazionali per turno del 23,1% e la latenza di turno dell'8,9%.
Qualità: Ha aumentato il tasso di accettazione degli hunk del 4,5% e l'accettazione delle righe di codice del 4,5%.
Impatto: Ha aumentato i tassi di invio del codice dell'11–14% e migliorato il tasso di sopravvivenza del codice (persistenza del codice accettato negli invii finali) del 16,8%.

Casi Studio Industriali

Il modello è stato distribuito in diversi scenari ad alto valore:

Migrazioni: Ha migrato con successo codebase legacy (ad es. da ID a 32 bit a 64 bit, da JUnit3 a JUnit4), riducendo lo sforzo manuale del 50% e scrivendo l'80% delle modifiche al codice in alcuni casi.
Efficienza del Codice: Il sistema "Ottimizzatore di Codice Efficiente" (ECO) ha sintetizzato patch di ottimizzazione, risparmiando un stimato 500.000 core CPU normalizzati per trimestre.
Assistenza in IDE: Funzionalità come "Incolla Intelligente" e "Trasforma Codice" hanno raggiunto alti tassi di adozione (45% e 70% di accettazione, rispettivamente), risparmiando agli sviluppatori migliaia di battiture e rappresentando oltre l'1% di tutto il codice prodotto.

Significato e Lezioni Apprese

Il documento sostiene che questa metodologia offre un percorso replicabile per le organizzazioni per sbloccare il pieno potenziale dei propri dati di ingegneria interni. Gli autori sottolineano che "più dati sono meglio" non è una regola universale; è necessaria una composizione attenta dei dati per evitare un trasferimento negativo (ad es. tracce di ragionamento verboso che interferiscono con l'uso degli strumenti). Inoltre, allineare i formati dei dati interni alla distribuzione di pre-training del modello base è cruciale per minimizzare lo "shock sintattico" e la regressione.

Il lavoro conclude che la specializzazione diretta dei modelli fondazione tramite mid-training e fine-tuning a parametri completi è una strategia vitale ed efficace per creare esperti aziendali capaci di affrontare l'intero spettro dei compiti di sviluppo, dalla manutenzione all'evoluzione architetturale, senza i costi proibitivi dell'addestramento da zero.