💻 computer science

Customizing an LLM for Enterprise Software Engineering

Dieses Paper stellt Gemini for Google (GfG) vor, ein spezialisiertes Large Language Model, das durch einen umfassenden End-to-End-Prozess der Datencurierung und Mid-Training an das interne Software-Engineering-Ökosystem von Google angepasst wurde, was in einer groß angelegten Studie die Entwicklerproduktivität und die Codequalität erheblich verbesserte und gleichzeitig eine replizierbare Blaupause für die Anpassung von Unternehmensmodellen bereitstellt.

Ursprüngliche Autoren: 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

Veröffentlicht 2026-05-21

📖 5 Min. Lesezeit🧠 Tiefgang

CC BY 4.0

Ursprüngliche Autoren: 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

Originalarbeit lizenziert unter CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ Dies ist eine KI-generierte Erklärung des untenstehenden Papers. Sie wurde nicht von den Autoren verfasst oder gebilligt. Für technische Genauigkeit konsultieren Sie das Originalpaper. Vollständigen Haftungsausschluss lesen

Stellen Sie sich vor, Sie haben einen brillanten, weltklasse Koch (das ursprüngliche KI-Modell). Dieser Koch kann fast alles zubereiten: italienische Pasta, französische Gebäcke oder japanisches Sushi. Er wurde auf jedem Rezeptbuch der öffentlichen Bibliothek trainiert.

Sie arbeiten jedoch in einer riesigen, hochtechnologischen Unternehmenskantine (dem internen Software-Ökosystem von Google). Hier sind die Regeln seltsam. Sie verwenden keine Standardöfen, sondern maßgefertigte, proprietäre Maschinen. Die Zutaten sind einzigartig, und die „Rezepte" (Code) haben spezifische, seltsame Namen, die niemand außerhalb des Gebäudes kennt.

Wenn Sie den weltklasse Koch bitten, eine Mahlzeit für Ihre Kantine zuzubereiten, versucht er möglicherweise, ein Standardrezept zu verwenden. Es wird gut aussehen, funktioniert aber nicht mit Ihren Maschinen und könnte das Essen verderben.

Dieser Artikel beschreibt, wie Google diesen weltklasse Koch nahm und ihm ein spezialisiertes Trainingslager gab, um zum perfekten Koch für ihre spezifische Kantine zu werden. Sie nennen diesen neuen Koch "Gemini for Google" (GfG).

So haben sie es getan, aufgeteilt in einfache Schritte:

1. Das Sammeln des „Geheimen Rezeptbuchs"

Anstatt dem Koch einfach mehr öffentliche Kochbücher zu geben, sammelte das Team eine massive Bibliothek mit internen Dokumenten. Dies war nicht nur Code; es war die gesamte Geschichte darüber, wie ihre Ingenieure arbeiten:

Das „Kritik"-Protokoll: Sie analysierten Tausende von Gesprächen, in denen Senior-Ingenieure Code überprüften, sagten „korrigiere das", und der Junior-Ingenieur es korrigierte. Dies lehrte die KI, Feedback anzunehmen und sich zu verbessern.
Das „Break-Fix"-Protokoll: Sie beobachteten, wie Ingenieure defekte Builds reparierten (wenn die Software aufhört zu funktionieren). Die KI lernte: „Oh, wenn dieser Fehler auftritt, besteht die Lösung normalerweise darin, diese spezifische Zeile zu ändern."
Das „Geschwindigkeit"-Protokoll: Sie untersuchten, wie Ingenieure Programme schneller ausführten, und lehrten die KI, Engpässe zu erkennen und Lösungen vorzuschlagen.
Das „Chat"-Protokoll: Sie nutzten interne Q&A-Sitzungen, bei denen Ingenieure nach seltsamen, internen Tools fragten, und lehrten die KI die spezifischen Namen und den Fachjargon des Unternehmens.

2. Die „Mid-Training"-Operation

Normalerweise trainiert man ein Modell entweder von Grund auf neu (beginnt mit einem Babygehirn) oder man justiert nur das Ende nach (Fine-Tuning). Google tat etwas dazwischen.

Stellen Sie sich das ursprüngliche KI-Modell als einen Schüler vor, der die High School abgeschlossen hat (allgemeines Vor-Training).

Das Problem: Wenn Sie beginnen, ihm sofort fortgeschrittenes Unternehmensrecht beizubringen, könnte er vergessen, wie man einfache Mathematik betreibt oder einen einfachen Aufsatz schreibt. Dies wird als „katastrophales Vergessen" bezeichnet.
Die Lösung: Anstatt ganz am Ende der High School zu beginnen, gingen sie zurück zum dritten Jahr des Schülers. Sie nahmen den Schüler, gaben ihm das „Geheime Rezeptbuch" (die internen Daten) und ließen ihn seine Ausbildung von diesem Punkt aus fortsetzen. Auf diese Weise behielt der Schüler seinen allgemeinen Verstand, lernte aber die spezifischen Unternehmensregeln.

3. Die Ergebnisse: Ein intelligenterer Assistent

Sie testeten diesen neuen „Gemini for Google" gegenüber der Standardversion mit 29.000 Ingenieuren. Die Ergebnisse waren wie der Vergleich eines allgemeinen GPS mit einem, das jede Abkürzung in Ihrer spezifischen Stadt kennt:

Weniger Hin-und-Her: Wenn Ingenieure um Hilfe baten, benötigte die Standard-KI etwa 23 % mehr Gesprächsdurchläufe, um die Aufgabe richtig zu erledigen. Die spezialisierte KI traf es öfter beim ersten Versuch richtig.
Bessere Code-Überlebensrate: Code, der von der spezialisierten KI geschrieben wurde, hatte 17 % höhere Wahrscheinlichkeit, den Überprüfungsprozess zu überstehen und tatsächlich im Endprodukt verwendet zu werden. Er wurde seltener abgelehnt oder defekt.
Echte Erfolge:
- Die „Zeitreise"-Migration: Sie nutzten die KI, um ein zehnjähriges System auf ein neues zu aktualisieren. Sie erledigte 80 % der Arbeit automatisch und halbierte die Zeit.
- Das „Smarte Einfügen": Wenn ein Ingenieur Code von einer Datei in eine andere kopierte, korrigierte die KI automatisch die Imports und Variablennamen, sodass es sofort funktionierte, und sparte Tausende von Tastenanschlägen.

4. Was sie lernten (Die Lehren)

Der Artikel hebt drei große Lehren für jeden hervor, der dies versuchen möchte:

Mehr Daten ist nicht immer besser: Einfach alles auf die KI zu werfen, kann sie verwirren. Sie mussten sorgfältig die richtige Mischung aus Daten auswählen, sonst würde die KI die falschen Gewohnheiten lernen (wie zum Beispiel zu viel zu reden, wenn sie einfach handeln sollte).
Kämpfen Sie nicht gegen das Format: Sie lernten, dass es einfacher ist, ihre internen Daten so zu gestalten, dass sie dem ursprünglichen Trainingsstil der KI ähneln, als die KI zu zwingen, ein neues, seltsames Format zu lernen.
Echte Tests sind wichtig: Sie können die KI nicht nur an einem Multiple-Choice-Quiz testen. Sie müssen beobachten, wie sie in der realen Welt arbeitet. Hat der Ingenieur den Code tatsächlich akzeptiert? Hat er den Überprüfungsprozess überstanden? Das ist die echte Punktzahl.

Das Fazit

Dieser Artikel handelt nicht von der Erfindung eines neuen Gehirntyps. Es geht darum, ein sehr intelligentes, universelles Gehirn zu nehmen und ihm ein spezialisiertes Praktikum innerhalb eines bestimmten Unternehmens zu geben. Indem sie ihm die eigene Geschichte, Fehler und Erfolge des Unternehmens fütterten, schufen sie eine KI, die nicht nur „Code kennt" – sie kennt ihren Code, ihre Tools und ihre Arbeitsweise.

Technische Zusammenfassung: Anpassung eines LLM für die Unternehmenssoftwareentwicklung

Problemstellung

Die Softwareentwicklung in Unternehmen ist ein kontinuierlicher evolutionärer Prozess, der inkrementelle Erweiterungen, architektonische Überarbeitungen und rigorose Wartung innerhalb proprietärer Ökosysteme umfasst. Während führende Large Language Models (LLMs) bei der Generierung von Code für neue Projekte („Greenfield") in algorithmischen Herausforderungen hervorragend abschneiden, fehlt es ihnen häufig an Einblicken in die einzigartigen Datenverteilungen großer Organisationen – insbesondere interne Bibliotheken, architektonische Muster und domänenspezifische Sprachen.

Standardansätze zur Schließung dieser Lücke, wie Retrieval-Augmented Generation (RAG) oder Low-Rank Adaptation (LoRA), weisen Einschränkungen auf. Die Ergebnisse von RAG sind uneinheitlich und von der Qualität der Abrufe abhängig, während LoRA die erforderliche Repräsentationskapazität für eine domänenspezifische Anpassung im großen Maßstab auf Korpora mit Billionen von Tokens vermissen lässt. Das Training von Modellen von Grund auf mit Unternehmensdaten ist oft prohibitiv teuer und zeitaufwendig. Folglich besteht ein Bedarf an einer Methodik, die Basismodelle spezialisiert, um spezifische Unternehmenssemantiken zu verstehen, ohne ihre allgemeinen Schlussfolgerungsfähigkeiten zu beeinträchtigen.

Methodik

Die Autoren stellen Gemini for Google (GfG) vor, eine spezialisierte Anpassung des Gemini-Basismodells, die für das interne Softwareentwicklungsökosystem von Google konzipiert wurde. Der Entwicklungsprozess folgt einem vierstufigen Blauplan:

1. Datencuration

Das Team kuratierte einen proprietären Datensatz mit Billionen von Tokens, der diverse Artefakte aus dem Softwareentwicklungslebenszyklus erfasst. Die Daten sind in sechs Hauptdomänen kategorisiert, um unterschiedliche Überwachungssignale bereitzustellen:

Change-Generation: Code-Review-Daten (Anfangscode, Kommentare, Endcode) zur Modellierung von „Kritik-und-Verfeinerungs"-Dialogen.
Wissen: Interne technische Dokumentation, API-Referenzen, Design-Dokumente und Q&A-Repositories.
Issues and Fixes: Daten zu Fehlerbehebungen, Build-Fehlern und Testausfällen. Ein wesentlicher Beitrag ist der Build Fixing-Datensatz, der feingranulare IDE-Instrumentierung nutzt, um Entwicklungssitzungen zu rekonstruieren und Codeänderungen zu identifizieren, die einen Build vom Scheitern zum Erfolg überführen.
Code-Generierung: Von Entwicklern geschriebener Code in verschiedenen Formaten (z. B. Fill-in-the-Middle), um Aufgaben zur Vervollständigung zu unterstützen.
Logs und Performance: Produktionsmetadaten, Effizienz-Änderungen und Daten zur verteilten Tracing (z. B. Dapper), um das Modell über Laufzeitverhalten und Performance-Antimuster zu unterrichten.
Aktivitätszeitpläne: Grobgranulare Workflow-Daten, die die Nutzung von Tools und Suchmuster abbilden.

2. Datenformatierung

Um heterogene Aufgaben zu bewältigen, entwarfen die Autoren spezifische Datenrepräsentationen:

Instruktionsgesteuerte Code-Bearbeitung: Modellierung von Codeänderungen als Diff ( $\Delta$ ) gegeben einen ursprünglichen Code-Ausschnitt und eine Instruktion.
Automated Program Repair (APR): Behandlung von Compilerfehlern oder Warnungen der statischen Analyse als „automatisierte Review-Kommentare", um menschliches und maschinelles Feedback zu vereinheitlichen.
Kontextbewusstes Infilling (FIM): Verwendung von Prefix-Middle-Suffix-Formaten, um die Fähigkeit des Modells zu verbessern, Code innerhalb bestehender Dateien zu generieren.
Multi-Turn Agentic Trajectories: Rekonstruktion latenter Entwicklungspfade (z. B. unter Verwendung von ReAct-Frameworks), um iteratives Problemlösen zu erfassen.

3. Mid-Training-Intervention

Anstatt von Grund auf zu trainieren oder ausschließlich nachträgliches Training anzuwenden, setzten die Autoren eine Mid-Training-Intervention ein. Diese Strategie verzweigt sich von einem grundlegenden Checkpoint (vor der finalen Konvergenzphase des Basismodells) und injiziert den kuratierten Unternehmensdatensatz. Dieser Ansatz bewahrt allgemeine Schlussfolgerungsfähigkeiten, während tiefes domänenspezifisches Wissen injiziert wird.

Zwei Modellvarianten wurden trainiert: Gemini-Flash (optimiert für Code-Vervollständigung mit niedriger Latenz) und Gemini-Pro (optimiert für komplexe Schlussfolgerungen und Refactoring).
Um katastrophales Vergessen zu mildern, nutzten die Autoren Data Replay (Mischen von ursprünglichen Pre-Training-Daten in die Unternehmensmischung) und Mid-Training-Intervention (Verzweigung von einem früheren Checkpoint statt dem letzten).

4. Post-Training

Nach der Mid-Training-Phase durchlief das Modell ein Supervised Fine-Tuning (SFT) unter Verwendung hochwertiger interner Datensätze, die aus crowdsourceter Validierung und anonymisierten Interaktionsprotokollen abgeleitet wurden. Diese Phase optimierte das Modell für nachgelagerte Anwendungen wie Code-Transformation, Migrationen und NL2SQL.

Hauptbeiträge

Rahmenwerk für Unternehmensanpassung: Eine umfassende Blauplan zur Erstellung spezialisierter Basismodelle aus internen Engineering-Daten, die Datencuration, Trainingsdynamiken und Bereitstellung abdeckt.
Strategie der Mid-Training-Intervention: Ein neuartiger Ansatz zur Überbrückung der Lücke zwischen allgemeinem Pre-Training und Post-Training, der die Modellgewichte effektiv für ein spezifisches Ökosystem anpasst, während allgemeine Intelligenz erhalten bleibt.
Unternehmensweite Evaluation: Eine groß angelegte blindes A/B-Studie mit 29.000 Entwicklern, die den praktischen Nutzen des angepassten Modells demonstriert.

Ergebnisse

Offline-Evaluation

Coding Benchmarks: GfG übertraf das Baseline-Gemini 2.5 Pro in den meisten Coding-Benchmarks, einschließlich einer 13%igen Verbesserung beim Aider „Edit Block"-Format und einer 5%igen Verbesserung bei SWE-bench Verified.
Allgemeine Schlussfolgerung: Trotz der Injektion von Billionen von Tokens behielt GfG die Leistung bei nicht-codierenden Benchmarks (z. B. ARC AGI, GradQA, MMMU-Pro) bei oder verbesserte sie, was bestätigt, dass fundamentale Intelligenz und multimodale Schlussfolgerungen erhalten blieben.

Online-Evaluation (A/B-Studie)

In einem blinden, randomisierten Experiment über 29.000 Entwickler hinweg schnitt GfG signifikant besser ab als die Baseline:

Effizienz: Reduzierung der durchschnittlichen Anzahl konversationeller Iterationen pro Turn um 23,1% und der Turn-Latenz um 8,9%.
Qualität: Erhöhung der Annahmerate von Hunks um 4,5% und der Annahmerate von Codezeilen um 4,5%.
Auswirkung: Steigerung der Code-Einreichungsraten um 11–14% und Verbesserung der Code-Überlebensrate (Persistenz angenommener Code in finalen Einreichungen) um 16,8%.

Industrielle Fallstudien

Das Modell wurde in mehreren hochwertigen Szenarien eingesetzt:

Migrationen: Erfolgreiche Migration veralteter Codebasen (z. B. von 32-Bit- auf 64-Bit-IDs, JUnit3 auf JUnit4), was den manuellen Aufwand um 50% reduzierte und in einigen Fällen 80% der Codeänderungen automatisch erstellte.
Code-Effizienz: Das System „Efficient Code Optimizer" (ECO) synthetisierte Optimierungs-Patches und sparte geschätzte 500.000 normalisierte CPU-Kerne pro Quartal.
In-IDE-Unterstützung: Funktionen wie „Smart Paste" und „Transform Code" erreichten hohe Akzeptanzraten (45% bzw. 70% Annahme), sparten Entwicklern Tausende von Tastenanschlägen und machten über 1% aller produzierten Code aus.

Bedeutung und Erkenntnisse

Die Arbeit geht davon aus, dass diese Methodik einen replizierbaren Weg für Organisationen bietet, das volle Potenzial ihrer internen Engineering-Daten zu erschließen. Die Autoren betonen, dass „mehr Daten sind besser" keine universelle Regel ist; eine sorgfältige Datenzusammensetzung ist erforderlich, um negative Übertragung zu vermeiden (z. B. ausführliche Schlussfolgerungsspuren, die die Werkzeugnutzung stören). Darüber hinaus ist die Ausrichtung interner Datenformate an die Pre-Training-Verteilung des Basismodells entscheidend, um „Syntax-Schock" und Regression zu minimieren.

Die Arbeit kommt zu dem Schluss, dass die direkte Spezialisierung von Basismodellen durch Mid-Training und Full-Parameter-Fine-Tuning eine gangbare und effektive Strategie zur Schaffung von Unternehmensexperten ist, die in der Lage sind, das gesamte Spektrum von Entwicklungsaufgaben zu bewältigen – von Wartung bis hin zu architektonischer Evolution – ohne die prohibitiven Kosten eines Trainings von Grund auf.