💻 computer science

Customizing an LLM for Enterprise Software Engineering

Dit artikel introduceert Gemini for Google (GfG), een gespecialiseerd groot taalmodel dat is aangepast voor het interne software-engineering-ecosysteem van Google via een uitgebreid end-to-end proces van datacuratie en mid-training, wat in een grootschalige studie aanzienlijk de ontwikkelaarsefficiëntie en codekwaliteit verbeterde en tegelijkertijd een reproduceerbaar blauwdruk biedt voor het aanpassen van modellen voor ondernemingen.

Oorspronkelijke auteurs: 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

Gepubliceerd 2026-05-21

📖 5 min leestijd🧠 Diepgaand

CC BY 4.0

Oorspronkelijke auteurs: 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

Oorspronkelijk artikel gelicentieerd onder CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ Dit is een AI-gegenereerde uitleg van het onderstaande artikel. Het is niet geschreven of goedgekeurd door de auteurs. Raadpleeg het oorspronkelijke artikel voor technische nauwkeurigheid. Lees de volledige disclaimer

Stel je een briljante, wereldklasse chef voor (het originele AI-model). Deze chef kan bijna alles koken: Italiaanse pasta, Franse gebakjes of Japanse sushi. Ze is getraind op elk receptenboek in de openbare bibliotheek.

Je werkt echter in een enorme, high-tech bedrijfskantine (het interne software-ecosysteem van Google). Hier zijn de regels vreemd. Je gebruikt geen standaardovens; je gebruikt op maat gebouwde, propriëtaire machines. De ingrediënten zijn uniek en de "recepten" (code) hebben specifieke, vreemde namen die niemand buiten het gebouw kent.

Als je de wereldklasse chef vraagt een maaltijd te bereiden voor je kantine, probeert ze misschien een standaardrecept te gebruiken. Het ziet er goed uit, maar het werkt niet met je machines en het kan het eten bederven.

Dit artikel beschrijft hoe Google die wereldklasse chef een gespecialiseerde trainingskamp gaf om de perfecte chef te worden voor hun specifieke kantine. Ze noemen deze nieuwe chef "Gemini for Google" (GfG).

Hier is hoe ze dat deden, opgesplitst in eenvoudige stappen:

1. Het verzamelen van het "Geheime Receptenboek"

In plaats van de chef gewoon meer openbare kookboeken te geven, verzamelde het team een enorme bibliotheek met interne documenten. Dit was niet alleen code; het was de volledige geschiedenis van hoe hun ingenieurs werken:

Het "Critique"-logboek: Ze keken naar duizenden gesprekken waarin senior ingenieurs code beoordeelden, zeiden "fix dit", en de junior-ingenieur het oploste. Dit leerde de AI hoe ze feedback moet accepteren en verbeteren.
Het "Break-Fix"-logboek: Ze keken hoe ingenieurs gebroken builds oplosten (wanneer de software stopt met werken). De AI leerde: "Oh, wanneer deze foutmelding verschijnt, is de oplossing meestal om deze specifieke regel te wijzigen."
Het "Speed"-logboek: Ze bestudeerden hoe ingenieurs programma's sneller lieten draaien, waardoor de AI leerde om trage plekken te herkennen en oplossingen voor te stellen.
Het "Chat"-logboek: Ze gebruikten interne Q&A-sessies waarin ingenieurs vragen stelden over vreemde, interne tools, waardoor de AI de specifieke namen en jargon van het bedrijf leerde.

2. De "Mid-Training" Operatie

Normaal gesproken train je een model van scratch (begin met een babybrein) of pas je alleen het einde aan (fine-tuning). Google deed iets in het midden.

Zie het originele AI-model als een student die de middelbare school heeft afgerond (algemene pre-training).

Het Probleem: Als je ze direct geavanceerd bedrijfsrecht leert, kunnen ze vergeten hoe ze basiswiskunde doen of een simpel essay schrijven. Dit heet "catastrophic forgetting" (catastrofaal vergeten).
De Oplossing: In plaats van helemaal aan het einde van de middelbare school te beginnen, gingen ze terug naar het derde jaar van de student. Ze namen de student, gaven hen het "Geheime Receptenboek" (de interne data) en lieten hen hun opleiding vanaf dat punt voortzetten. Zo behield de student hun algemene intelligentie maar leerde ze de specifieke bedrijfsregels.

3. De Resultaten: Een Slimmere Assistent

Ze testten deze nieuwe "Gemini for Google" tegen de standaardversie met 29.000 ingenieurs. De resultaten waren als het vergelijken van een algemene GPS met een die elke afkorting in jouw specifieke stad kent:

Minder Hin- en Hergewerk: Wanneer ingenieurs om hulp vroegen, had de standaard AI ongeveer 23% meer conversatierondes nodig om het werk goed te krijgen. De gespecialiseerde AI kreeg het vaker in één keer goed.
Beter Code-Overleven: Code geschreven door de gespecialiseerde AI had 17% meer kans om de beoordelingsprocedure te doorstaan en daadwerkelijk in het eindproduct te worden gebruikt. Het werd minder vaak afgewezen of bedorven.
Wereldse Overwinningen:
- De "Time Travel" Migratie: Ze gebruikten de AI om een tien jaar oud systeem te updaten naar een nieuw systeem. Het deed 80% van het werk automatisch, waardoor de tijd werd gehalveerd.
- De "Smart Paste": Wanneer een ingenieur code van het ene bestand naar het andere kopieerde, corrigeerde de AI automatisch de imports en variabele namen zodat het direct werkte, wat duizenden toetsaanslagen bespaarde.

4. Wat Ze Leerden (De Lessen)

Het artikel benadrukt drie grote lessen voor iedereen die dit probeert:

Meer Data Is Niet Altijd Beter: Gewoon alles op de AI gooien kan haar verwarren. Ze moesten zorgvuldig de juiste mix van data kiezen, anders zou de AI de verkeerde gewoonten leren (zoals te veel praten terwijl ze gewoon moet handelen).
Vecht Niet Tegen het Formaat: Ze leerden dat het makkelijker is om hun interne data te laten lijken op de oorspronkelijke trainingsstijl van de AI, in plaats van de AI te dwingen een nieuw, vreemd formaat te leren.
Echte Tests Zijn Belangrijk: Je kunt de AI niet zomaar testen op een meerkeuzetoets. Je moet kijken hoe het in de echte wereld werkt. Heeft de ingenieur de code daadwerkelijk geaccepteerd? Heeft het de beoordeling doorstaan? Dat is de echte score.

De Conclusie

Dit artikel gaat niet over het uitvinden van een nieuw type brein. Het gaat over het nemen van een zeer slim, algemeen doelbrein en het een gespecialiseerde stage geven binnen een specifiek bedrijf. Door het de eigen geschiedenis, fouten en successen van het bedrijf te voeden, creëerden ze een AI die niet alleen "code kent"—maar hun code, hun tools en hun manier van werken kent.

Technische Samenvatting: Het Aanpassen van een LLM voor Enterprise Software Engineering

Probleemstelling

Enterprise softwareontwikkeling is een continu evolutionair proces dat incrementele toevoegingen, architecturale revisies en strenge onderhoud binnen propriëtaire ecosystemen omvat. Hoewel geavanceerde Large Language Models (LLM's) uitblinken in het genereren van groenvelddcode voor algoritmische uitdagingen, missen ze vaak blootstelling aan de unieke data-distributies van grote organisaties—specifiek interne bibliotheken, architecturale patronen en domeinspecifieke talen.

Standaard benaderingen om deze kloof te overbruggen, zoals Retrieval-Augmented Generation (RAG) of low-rank adaptatie (LoRA), vertonen beperkingen. RAG-resultaten zijn gemengd en afhankelijk van de kwaliteit van de ophaaloperatie, terwijl LoRA de representatieve capaciteit mist voor domeinaanpassing op grote schaal op corpora met biljoenen tokens. Het trainen van modellen vanaf nul op enterprise-data is vaak onbetaalbaar duur en tijdrovend. Bijgevolg is er behoefte aan een methodologie die fundamentele modellen specialiseert in het begrijpen van specifieke enterprise-semantiek, zonder hun algemene redeneervermogen te offeren.

Methodologie

De auteurs introduceren Gemini for Google (GfG), een gespecialiseerde aanpassing van het Gemini-fundamentele model, ontworpen voor het interne software-engineeringecosysteem van Google. Het ontwikkelingsproces volgt een blauwdruk in vier fasen:

1. Data Cureren

Het team heeft een propriëtair dataset van een biljoen tokens samengesteld dat diverse artefacten uit de softwareontwikkelingslevenscyclus vastlegt. De data is gecategoriseerd in zes primaire domeinen om distincte supervisie-signalen te bieden:

Change-Generation: Code-reviewdata (initiële code, opmerkingen, definitieve code) om "critique-and-refine"-dialogen te modelleren.
Knowledge: Interne technische documentatie, API-referenties, ontwerpdocumenten en Q&A-repositories.
Issues and Fixes: Data over bugfixes, buildfouten en testmislukkingen. Een belangrijke bijdrage is de Build Fixing dataset, die fijnmazige IDE-instrumentatie gebruikt om ontwikkelaarsessies te reconstrueren, codeveranderingen identificerend die een build van mislukking naar succes overbrengen.
Code Generation: Code geschreven door ontwikkelaars in diverse formaten (bijv. Fill-in-the-Middle) om aanvullingstaken te ondersteunen.
Logs and Performance: Productiemetadata, efficiëntie-aanpassingen en gedistribueerde traceerdata (bijv. Dapper) om het model te leren over runtime-gedrag en prestatie-anti-patronen.
Activity Timelines: Grofkorrelige workflowdata die toolgebruik en zoekpatronen in kaart brengt.

2. Data Formatting

Om heterogene taken te verwerken, hebben de auteurs specifieke data-representaties ontworpen:

Instruction-Guided Code Editing: Codeveranderingen modelleren als een diff ( $\Delta$ ) gegeven een originele codefragment en een instructie.
Automated Program Repair (APR): Compilerfouten of statische analysewaarschuwingen behandelen als "automatische reviewopmerkingen" om menselijke en machine-feedback te verenigen.
Context-Aware Infilling (FIM): Prefix-Middle-Suffix-formaten gebruiken om het vermogen van het model te verbeteren om code binnen bestaande bestanden te genereren.
Multi-Turn Agentic Trajectories: Latente ontwikkelingspaden reconstrueren (bijv. met ReAct-frameworks) om iteratief probleemoplossen vast te leggen.

3. Mid-Training Intervention

In plaats van vanaf nul te trainen of alleen post-training toe te passen, pasten de auteurs een mid-training intervention toe. Deze strategie takelt af van een fundamenteel checkpoint (voordat de definitieve convergentiefase van het basismodel) en injecteert het samengestelde enterprise-dataset. Deze aanpak behoudt algemene redeneervermogens terwijl diepe domeinkennis wordt ingebracht.

Twee modelvarianten werden getraind: Gemini-Flash (geoptimaliseerd voor low-latency code-aanvulling) en Gemini-Pro (geoptimaliseerd voor complex redeneren en refactoring).
Om catastrophic forgetting te mitigeren, gebruikten de auteurs Data Replay (het mengen van originele pre-training data in de enterprise-mengeling) en Mid-training intervention (vertakken vanaf een eerdere checkpoint in plaats van de laatste).

4. Post-Training

Na de mid-training onderging het model Supervised Fine-Tuning (SFT) met behulp van hoogwaardige interne datasets afgeleid van crowdsourced validatie en geanonimiseerde interactielogs. Deze fase optimaliseerde het model voor downstream-toepassingen zoals code-transformatie, migraties en NL2SQL.

Belangrijkste Bijdragen

Framework voor Enterprise Adaptatie: Een uitgebreide blauwdruk voor het bouwen van specialistische fundamentele modellen uit interne engineeringdata, die data-cureren, trainingsdynamiek en implementatie omvat.
Mid-Training Intervention Strategy: Een nieuwe aanpak om de kloof te overbruggen tussen algemene pre-training en post-training, waardoor modelgewichten effectief worden aangepast voor een specifiek ecosysteem terwijl algemene intelligentie behouden blijft.
Enterprise-Scale Evaluation: Een grote, blinde A/B-studie met 29.000 ontwikkelaars die het praktische nut van het aangepaste model aantoont.

Resultaten

Offline Evaluatie

Coding Benchmarks: GfG presteerde beter dan de baseline Gemini 2.5 Pro op de meeste coding benchmarks, inclusief een verbetering van 13% op het Aider "Edit Block"-formaat en een verbetering van 5% op SWE-bench Verified.
General Reasoning: Ondanks de injectie van een biljoen tokens, behield GfG de prestaties op niet-coding benchmarks (bijv. ARC AGI, GradQA, MMMU-Pro) of verbeterde deze, wat bevestigt dat fundamentele intelligentie en multimodaal redeneren behouden bleven.

Online Evaluatie (A/B Study)

In een blinde, gerandomiseerde experiment met 29.000 ontwikkelaars presteerde GfG significant beter dan de baseline:

Efficiency: Verminderde het gemiddelde aantal conversatie-iteraties per beurt met 23,1% en de beurtlatentie met 8,9%.
Quality: Verhoogde de hunk-acceptatiegraad met 4,5% en de code-lijnacceptatie met 4,5%.
Impact: Verhoogde de code-inzendingspercentages met 11–14% en verbeterde de code survival rate (persistentie van geaccepteerde code in definitieve inzendingen) met 16,8%.

Industriële Case Studies

Het model werd ingezet in verschillende hoogwaardige scenario's:

Migrations: Succesvolle migratie van legacy codebases (bijv. 32-bit naar 64-bit ID's, JUnit3 naar JUnit4), waardoor de handmatige inspanning met 50% werd verminderd en in sommige gevallen 80% van de codeveranderingen werd geschreven.
Code Efficiency: Het "Efficient Code Optimizer" (ECO)-systeem synthetiseerde optimalisatie-patches, wat naar schatting 500.000 genormaliseerde CPU-kernen per kwartaal opleverde.
In-IDE Assistance: Functies zoals "Smart Paste" en "Transform Code" behaalden hoge adoptiepercentages (respectievelijk 45% en 70% acceptatie), waardoor ontwikkelaars duizenden toetsaanslagen bespaarden en meer dan 1% van alle geproduceerde code voor hun rekening namen.

Betekenis en Geleerde Lessen

Het artikel stelt dat deze methodologie een repliceerbaar pad biedt voor organisaties om het volledige potentieel van hun interne engineeringdata te ontsluiten. De auteurs benadrukken dat "meer data beter is" geen universele regel is; zorgvuldige data-samenstelling is vereist om negatieve transfer te voorkomen (bijv. verbaal redeneersporen die toolgebruik verstoren). Bovendien is het afstemmen van interne dataformaten op de pre-training-distributie van het basismodel cruciaal om "syntax shock" en regressie te minimaliseren.

Het werk concludeert dat directe specialisatie van fundamentele modellen via mid-training en full-parameter fine-tuning een haalbare en effectieve strategie is voor het creëren van enterprise-experts die het volledige spectrum van ontwikkelingstaken kunnen aanpakken, van onderhoud tot architecturale evolutie, zonder de onbetaalbare kosten van training vanaf nul.