Google-Transkript: Jeff Dean über die Spezialisierung von Inferenz-Hardware und sich selbst verbessernde KI-Systeme
Y Combinator Startup School 2026, 20. September 2026
Sind KI-Modelle bereits Junior-Ingenieure?
Diana Hu: Gut. Sollen wir anfangen, Jeff?
Jeff Dean: Klar. Klingt gut.
Diana Hu: Gut. Jeff, herzlich willkommen. Und nochmals vielen Dank, dass Sie hier sind. Vor allem, da ich mir gerade eine Erkältung eingefangen habe, danke, dass Sie hier sind.
Jeff Dean: Ja, ich fürchte, ich habe meine Stimme verloren. Normalerweise klinge ich nicht ganz so, aber wir machen das Beste daraus.
Diana Hu: Sie haben also MapReduce, Bigtable, TensorFlow, die TPU und Gemini entwickelt. Wir könnten eine ganze Stunde mit all den Dingen verbringen, die Sie getan haben, aber was ich so schätze, ist, dass Sie öffentlich nach wie vor mutige Prognosen wagen. Letztes Jahr im Mai 2025 auf der AI Ascent sagten Sie, dass KI auf dem Niveau eines Junior-Ingenieurs ist. Das ist etwa ein Jahr her. Wie nah sind wir an dieser Prognose?
Jeff Dean: Ja, ich habe den Eindruck, dass die Modelle bei agentenbasierten, länger laufenden Programmieraufgaben deutlich besser geworden sind. Es scheint ziemlich klar zu sein, dass sie mittlerweile tatsächlich ein beachtliches Leistungsvermögen besitzen. Je nachdem, wie genau man einen Junior-Ingenieur definiert, trifft das Zitat wohl ziemlich ins Schwarze, würde ich sagen.
Diana Hu: Was haben Sie bei dieser Prognose unterschätzt?
Jeff Dean: Ich denke, die Fähigkeit, immer komplexere Aufgaben zu bewältigen, ist schneller gewachsen, als ich dachtte. Außerdem bin ich der Meinung, dass diese agentenbasierten Systeme neben dem Programmieren auch in anderen Bereichen richtig aufblühen. Ich glaube, das wird ein wichtiger Trend für die Zukunft sein.
Diana Hu: Nennen Sie uns noch eine gewagte Prognose. Was wird Ihrer Meinung nach das Thema der Ausgabe 2027 sein?
KI-Systeme, die sich selbst verbessern
Jeff Dean: Ich denke, wir werden eine viel stärkere Automatisierung von ML-Systemen erleben. Im Grunde geht es darum, ML-Systeme dazu zu bringen, ihre Fähigkeiten zu verbessern, indem sie zahlreiche Experimente durchführen, Probleme in Teilprobleme zerlegen, diese Teilprobleme in einer engen, automatisierten Experimentierschleife ausführen, die Ergebnisse zusammenführen und aus dieser vollautomatischen Problemzerlegung und automatischen Experimentierung schließlich ein verbessertes System hervorbringen. Das wird höchst spannend werden. Ich denke, das gilt nicht nur für ML, sondern auch für andere Wissenschafts- und Ingenieurbereiche. Im Grunde kann man heutzutage in jedem Bereich, in dem es ein messbares Ziel gibt, enorme Fortschritte erzielen.
Diana Hu: Gehen wir nun ein wenig in der Geschichte zurück. Noch im Jahr 2001 lief die Google-Suche auf Festplatten.
Jeff Dean: Jau.
Diana Hu: Und Sie und Sanjay haben nachgerechnet und festgestellt, dass der gesamte Suchindex irgendwann in den RAM aller Computer passen würde, die Sie damals betrieben. Sie haben diese radikale Erkenntnis gewonnen und im Grunde innerhalb weniger Tage zusammen mit Sanjay eine völlig neue Suchversion in die Produktion gebracht, die im Arbeitsspeicher statt auf Festplatten lief. Das war der ausschlaggebende Punkt dafür, dass die Google-Suche so unglaublich schnell wurde. Geschichte neigt dazu, sich neu zu mischen. Was ist der „Es passt alles in den Arbeitsspeicher“-Moment im Jahr 2026, über den jeder in diesem Raum jetzt nachdenken und den er konzipieren sollte?
Der Google-Suchdurchbruch, der alles veränderte
Jeff Dean: Ja, es ist ein wenig anders, aber ich denke, wir werden immer mehr leistungsstarke und energieeffiziente Inferenz-Hardware-Systeme sehen. Mittlerweile begreift jeder, dass die Inferenz der Schlüssel dazu ist, diese agentenbasierten Systeme immer mehr Menschen zugänglich zu machen, dass Latenz von entscheidender Bedeutung ist und dass die Spezialisierung der Hardware ein wesentlicher Hebel ist, um energieeffizientere und latenzärmere Lösungen zu schaffen als universell einsetzbare Rechengeräte wie etwa GPUs oder TPUs. Jeder hier ist es gewohnt, auf Antworten von Modellen zu warten. Warten macht keinen Spaß.
Diana Hu: Höchstgeschwindigkeit. Sie meinen also: Was wäre, wenn wir nicht mehr warten müssten?
Jeff Dean: Ja. Stellen Sie sich vor, was Sie mit etwas anfangen könnten, bei dem die Latenz um das Fünfzigfache besser ist.
KI-Agenten werden wochenlang laufen
Diana Hu: Ein interessanter Gedanke. Was ist nun eine Annahme, die vielleicht 6.000 Menschen in diesem Raum über KI hegen, die jedoch bereits falsch ist?
Jeff Dean: Das ist eine gute Frage. Ein Punkt ist vermutlich, dass sich die Leute nicht ganz im Klaren darüber sind, wie gut es möglich ist, agentenbasierte Systeme einzusetzen, die nicht nur eine oder zwei Stunden an einem relevanten Problem arbeiten, sondern die – in bestimmten Problemdomänen und mit extrem leistungsstarken Basismodellen – tage- oder wochenlang laufen und wirklich hochkomplexe Aufgaben erledigen können. Einige fangen an, erste Anzeichen dafür zu sehen, aber ich glaube nicht, dass das jeder verinnerlicht hat. Das wird eine ziemlich große Sache.
Diana Hu: Was ist eine konkrete Aufgabe, die Sie haben laufen lassen, die sich über Wochen erstreckt hat? Worum ging es dabei? Was haben Sie den Agenten aufgetragen zu lösen?
Jeff Dean: Man kann Agenten losschicken, um komplett neue Softwareversionen in anderen Programmiersprachen zu implementieren, die möglicherweise bessere Sicherheits- oder Leistungseigenschaften aufweisen, und das können sie dann auf ziemlich ernsthafte Weise tatsächlich umsetzen.
Die Notizzettel-Mathematik, die zu TPUs führte
Diana Hu: Das ist ziemlich cool. Wofür Sie ebenfalls sehr bekannt sind, ist Ihre Fähigkeit zur Notizzettel-Mathematik [Napkin Math]. Klingt lustig. Eine Anekdote über Sie besagt, dass Sie 2013, als die Spracherkennung bei Google zu funktionieren begann, überschlugen, dass sich die Serverflotte von Google verdoppeln müsste, wenn jeder Google-Nutzer sein Smartphone in die Hand nimmt, damit spricht und das Spracherkennungssystem täglich nur drei Minuten lang nutzt – was allein für die Sprachübersetzung extrem kostspielig geworden wäre.
Jeff Dean: Ja.
Diana Hu: Und stattdessen haben Sie im Grunde einen eigenen Chip gebaut, was die Entstehungsgeschichte der TPU war.
Jeff Dean: Ja. Wir sahen damals bei den auf Deep Learning basierenden Sprachmodellen, die wir trainierten, qualitativ wirklich hervorragende Ergebnisse, aber sie waren im Vergleich zum alten System rechenintensiv. Sie halbierten jedoch die Fehlerrate. Das entsprach in etwa 20 Jahren Fortschritten in der Spracherkennung innerhalb von nur wenigen Monaten Herumtüftelns am Modell, dessen leichter Skalierung und besserer Daten. Wir fingen also an, uns Sorgen zu machen, dass die Leute die Spracherkennung noch mehr nutzen würden, falls sie so gut funktioniert. Diese Überschlagsrechnung auf der Serviette drehte sich im Grunde darum. Was passiert, wenn die Leute Spracherkennung vermehrt zum Diktieren von E-Mails, zum Sprechen mit dem Telefon oder für Ähnliches nutzen? Es stellte sich heraus, dass wir eine bessere Lösung brauchten als den damaligen Betrieb auf CPUs. Also entwickelten wir TPUs, die extrem spezialisiert sind auf im Wesentlichen niedrigpräzise, dichte lineare Algebra – das Herzstück nahezu aller modernen Algorithmen des maschinellen Lernens, die wir heute nutzen. Wenn man einen spezialisierten Chip für niedrigpräzise dichte lineare Algebra baut, der sonst nichts anderes kann, erweist sich das als äußerst nützlich für die KI-Inferenz, auch wenn er weder Chrome noch Word ausführen kann. Ein paar Jahre später brachte das einen Chip hervor, der 30- bis 80-mal energieeffizienter war als die CPUs und GPUs jener Tage, und das bei einer weitaus geringeren Latenz, die um das 20- bis 30-Fache niedriger lag.
Diana Hu: Was absolut unglaublich ist – welch ein Fundament die TPU heute geworden ist. Es gab schlicht keine Möglichkeit vorauszusehen, dass die TPU einmal eine solche Basis für die Transformer-Architektur bilden würde, die erst lange nach Ihrer Erfindung der TPU entwickelt wurde.
Jeff Dean: Ja, das ist im Grunde der Grund, warum wir ein universelles System für lineare Algebra gebaut haben, was eine TPU im Kern ja ist. Wir wussten, dass sich ML-Algorithmen noch weiterentwickeln würden und man nicht überanpassen durfte; man musste jedoch stark genug spezialisieren, um die dramatischen Leistungsvorteile sehr großer Multipliziereinheiten zu erzielen. Wir konnten Hochgeschwindigkeitsspeicher einsetzen. Wir konnten High-Speed-Interconnects für spätere TPUs bereitstellen, die viele, viele Chips effizient für dasselbe Problem zusammenkombinierten. Wir haben diese Einheiten im Laufe vieler, vieler Generationen kontinuierlich skaliert und ihre Leistung verbessert.
Wie man bahnbrechende Ideen findet
Diana Hu: Unglaubliche Notizzettel-Mathematik. Servietten sind nützlich. Was wäre nun eine gute Notizzettel-Mathematik, die jeder hier, der ein künftiger Gründer sein möchte, noch heute Abend anstellen sollte, um potenziell etwas so Wirkungsvolles wie die TPU zu bauen?
Jeff Dean: Das ist immer schwer zu sagen. Überlegen Sie sich, welche Probleme Sie in dem Bereich sehen, über den Sie nachdenken, wo es Engpässe gibt, und ob es völlig andere Lösungsansätze für einige dieser Probleme gibt, die Ihnen eine um eine oder zwei Größenordnungen bessere Leistung, Leistungsfähigkeit oder was auch immer einbringen würden. Denn wenn man ein Problem manchmal kritisch beäugt und sich nicht unbedingt daran klammert, wie dieses Problem heute gelöst wird, sondern wie man es von Grund auf neu („First Principles“) lösen würde, kommt man auf richtig gute Ideen, an die andere vielleicht nicht denken.
Das neue mentale Modell des KI-Ingenieurs
Diana Hu: Das ist ein guter Tipp. Für alle hier Anwesenden, die es nicht wissen: Jeff hat vor Jahren eine sehr berühmte Liste namens „Latency Numbers Every Computer Scientist Should Know“ verfasst. Das sind Zahlen darüber, wie lange beispielsweise ein Cache-Fehlversuch, ein Festplattenzugriff oder ein Netzwerkpaket braucht, um etwa von Kalifornien in die Niederlande zu reisen, sowie viele weitere Kennzahlen rund um verteilte Systeme und Systemtechnik. Sie wurde oft ausgedruckt und ist zur Bibel für viele Ingenieure verteilter Systeme geworden. Wenn wir nun einen Zeitsprung machen: Diese Liste ist reif für ein Update. Geben wir der Sache eine KI-Edition für das Jahr 2026.
Jeff Dean: Wenn man betrachtet, was heutzutage in KI-Systemen wichtig ist, möchte man Dinge wissen wie die Bandbreite zwischen dem Hauptspeichersystem auf Ihrem Beschleuniger und dem On-Chip-Speicher bis hin zur Multipliziereinheit. Man möchte wissen, wie viel Energie eine einzelne Multiplikationsoperation verbraucht. Wie hoch ist die Interconnect-Bandbreite zwischen Chips und wie viele Chips kann man mit dieser Bandbreite verbinden? Wenn man diesen Bereich verlässt: Wie stark bricht die Netzwerkbandbreite ein, wenn man mit 10.000 Chips anstelle von 500 kommunizieren muss? Ich denke, das sind alles extrem wichtige Kennzahlen, die man kennen muss, und sie beeinflussen maßgeblich, wie man an die Lösung bestimmter Problemstellungen herangeht.
Diana Hu: Eine interessante Sache, über die Sie meines Wissens gesprochen haben, ist, dass die Maßeinheit, in der Sie heutzutage alles messen, die Energie ist.
Jeff Dean: Ja.
Diana Hu: Sie wiesen darauf hin, dass eine Berechnung oder mathematische Operation etwa ein Pikojoule kostet, das Bewegen von Daten und die Daten-Ein- und Ausgabe (I/O) jedoch das Tausendfache davon.
Jeff Dean: Ja. Allein das Heranschaffen aus dem HBM [High Bandwidth Memory] auf einem Beschleuniger in den Prozessor, damit dieser tatsächlich damit rechnen kann.
Warum KI in Wahrheit ein Energieproblem ist
Diana Hu: Genau. Diese Diskrepanz bestimmt still und leise, welche Produkte möglich sind und wie diese KI-Algorithmen aufgebaut sind. Was sind typische Probleme, die Gründer hartnäckig als Modellprobleme bezeichnen, bei denen es sich in Wirklichkeit aber um Energie- oder Daten-I/O-Probleme handelt?
Jeff Dean: Das von Ihnen genannte Beispiel mit dem tausendfachen Unterschied zwischen dem Bewegen von Daten und der tatsächlichen Berechnung im Hinblick auf den Energieverbrauch ist ziemlich signifikant, und es prägt viele Aspekte dessen, was wir beim maschinellen Lernen tun. Denn gäbe es diesen tausendfachen Unterschied nicht, müsste man kein Batching betreiben. Man muss jedoch Batches aus vielen Beispielen oder vielen Tokens gleichzeitig bilden, um diesen Datentransport zu amortisieren, damit man keine tausendfache Verlangsamung hinnehmen muss, sondern stattdessen einen Energieaufwand von „1.000 geteilt durch die Batch-Größe“ bezahlt. Für extrem niedrige Latenzen ist Batching allerdings nicht sonderlich gut geeignet. Solche Faktoren und die Energie hinter verschiedenen Entscheidungen bezüglich der von uns verwendeten Computer-Hardware beeinflussen eine Vielzahl von Entscheidungen beim Aufbau übergeordneter Systeme.
Diana Hu: Ein ganz konkretes Beispiel ist schlicht die Art und Weise, wie das Training von Modellen durchgeführt wird. Da gibt es das gesamte Konzept der Batch-Bildung von Datensätzen und des Durchlaufens von Epochen. Das wird von Leuten vielleicht fälschlicherweise als Modellproblem angesehen, ist aber in Wahrheit ein System- und Daten-I/O-Problem, oder?
Jeff Dean: Ja. Man muss Batches zusammenstellen, um eine bessere Effizienz der Hardware zu erreichen. Im Idealfall würde man ein Training mit einer Batch-Größe von 1 durchführen, aber das ist unter Effizienzgesichtspunkten nicht so gut. Deshalb verwenden die Leute heutzutage ziemlich große Batches.
Diana Hu: Sie sind dafür bekannt, dass Sie sich für eine lange Woche oder ein Wochenende zurückziehen und mit einer genialen Lösung aufwarten. Gibt es so etwas wie den sich für ein paar Wochen einschließenden Jeff Dean, der das Training mit einer Batch-Größe von 1 realisiert?
Jeff Dean: Ich habe in letzter Zeit eher über Inferenz nachgedacht. Die Inferenz ist ein ziemlich interessantes Problem, weil man dabei eine sehr geringe Latenz anstrebt. Beim Training braucht man nicht unbedingt eine unglaublich niedrige Latenz. Ich denke, es gibt noch viel Spielraum, um Hardware stärker für die Inferenz zu spezialisieren, als wir das heute tun.
Diana Hu: Was sind einige dieser interessanten Aspekte rund um die Inferenz, über die Sie intensiv nachdenken?
Jeff Dean: Einfach der Versuch, die Datenbewegung zu minimieren, über extrem niedrigpräzise Operationen nachzudenken und vielleicht nicht mehr Hunderte verschiedener Präzisionstypen zu unterstützen. Wenn man das Gefühl hat, eine gute Antwort darauf zu haben, welche Präzision man benötigt, baut man diese eben fest in die Hardware ein und sonst kaum etwas.
Diana Hu: Was zu einer Kernanalogie führt, die ich von berühmten Informatikern gehört habe: Im Grunde ist der gesamte Prozess der KI ein großes Komprimierungsproblem. Damit die Daten verlustbehaftet komprimiert und anschließend wiederhergestellt werden können, muss man sie im Grunde verstehen.
Jeff Dean: Wenn man die Daten wirklich versteht, sollte man in der Lage sein, sie hervorragend zu komprimieren.
Diana Hu: Und die Transformer-Architektur hat sich nun als einer der Wege erwiesen, die dabei extrem gut funktionieren.
Jeff Dean: Ja, das funktioniert bisher ziemlich gut. Gnadvolle Arbeit meiner Kollegen.
Context Engineering ist die nächste Grenze
Diana Hu: Ja. Zoomen wir nun etwas heraus. KI-Fortschritt bedeutete früher schlicht bessere Modelle. Man hatte mehr Daten, trainierte Modelle mit größeren Parametern. Doch im vergangenen Jahr oder so dreht sich zunehmend alles um das Modell herum. Nicht nur Modellgröße, Parameteranzahl oder mehr Daten – es geht um alles, was Retrieval, Tools, Speicher, Agenten-Werkzeuge angeht, und das Ganze verschmilzt vielleicht zu dem, was die Leute als Context Engineering bezeichnen, richtig?
Jeff Dean: Ja. Das Modell ist im Grunde nur ein Baustein dessen, was man eigentlich anstrebt: den Bau eines Gesamtsystems, das hochinteressante Probleme lösen kann. Dazu gehört ein Modell, das weiß, wie man verschiedene Tools einsetzt. Es weiß vielleicht, wie man relevante Informationen abruft, verfügt eventuell über eine Historie an Informationen, die es für vergangene Probleme abgerufen hat, und kann Informationen in den Kontext des Modells einbetten. Das Schöne daran ist, dass diese Informationen für das Modell extrem klar sind – ganz im Gegensatz zu den Trainingsdaten, mit denen das Modell trainiert wurde, wo im Grunde Billionen von Tokens zu einer Suppe aus Hunderten von Milliarden oder Billionen Parametern zusammengerührt sind. Das ist alles weitaus diffuser als der tatsächliche Kontext, den das Modell für dieses spezifische Problem oder diesen Anwendungsfall direkt vor Augen hat.
Jeff Dean: Wenn man dann noch versteht, welche Tools zur Verfügung stehen, welche davon dem Modell bei der nächsten Phase des Problems helfen werden, wie man ein Problem in eine Sequenz von Tool-Aufrufen zerlegt, vielleicht verschiedene Lösungsansätze ausprobiert, um zu sehen, was funktioniert, und das Ganze bewerten kann – das ist diese gesamte Orchestrierung komplexer Agenten- und Multi-Agenten-Systeme, die meiner Ansicht nach immer wichtiger werden wird. Super spannende Zeiten, würde ich sagen.
Diana Hu: Das Schöne an diesem konkreten Problembereich ist die Tatsache, dass das eigentlich jeder in diesem Raum tun kann. Früher benötigte man zum Trainieren eines Modells unvorstellbare Ressourcen, einen unermesslichen Zugang zu GPUs und Daten. Beim Context Engineering hingegen kann das jeder hier selbst machen. Man benötigt lediglich den API-Zugang zu etwas wie Gemini und arbeitet dann an seinem eigenen Setup für das eigene Retrieval, die eigenen Tool-Aufrufe und so weiter. Was sind einige Tipps für alle hier Anwesenden? Wie wird man besser und wie wird man außergewöhnlich gut im Context Engineering?
Jeff Dean: Ein hervorragender Weg besteht darin, diese Modelle, Frameworks [Harnesses] und Tools zu nutzen, um zu versuchen, Probleme zu lösen, und dabei manchmal direkt zu sehen, wo die Modelle scheitern. Oftmals kann man das Modell dazu bringen, besser zu funktionieren und bei solchen Problemen erfolgreich zu sein, indem man nicht etwa die Modellparameter anpasst – was von außen schwer möglich ist –, sondern indem man bessere Richtlinien für das Modell erstellt oder dem Modell Fähigkeiten („Skills“) beibringt, damit es weiß, wie es verschiedene Tools einsetzen kann, die für die Lösung dieser speziellen Problemklasse unglaublich nützlich sind. Wenn man das tut, landet man in einer Art selbstverbessernden Setup, mit dem man Probleme zu lösen versucht. Das ist ein wirklich guter Weg, um besser zu verstehen, welche zusätzlichen Informationen das Modell benötigt, um leistungsfähiger zu werden.
Die Fähigkeit, die KI in der Optimierung besser machte
Diana Hu: Können Sie ein Beispiel für Context Engineering nennen, das Sie persönlich betrieben haben – Fähigkeiten, die Sie geschrieben haben, oder Tools, die in Ihrem Workflow einen enormen Unterschied gemacht haben?
Jeff Dean: Sanjay und ich haben vor einigen Wochen an etwas gearbeitet, und wir nehmen häufig Leistungsverbesserungen an sehr low-leveligen Bibliotheken vor. Wir haben eine Mikrobenchmark-Bibliothek bei Google geschrieben, mit der man Microbenchmarks darüber erstellen kann, wie lange verschiedene Arten von Operationen dauern oder wie lange es dauert, diese Datenstruktur zu befüllen. Manchmal werden diese Datenstrukturen auf Millionen von Prozessen bei Google verwendet, weshalb es tatsächlich ziemlich wichtig ist, sicherzustellen, dass sie eine hohe Performance aufweisen. Man kann Mikrobenchmarks schreiben, aber ohne ein agentenbasiertes System besteht das übliche Vorgehen darin, die aktuelle Leistung anhand einiger relevanter Benchmarks zu messen, einige Änderungen zur Leistungsverbesserung vorzunehmen, die Benchmarks erneut auszuführen, um zu sehen, wo Verbesserungen erzielt wurden, einen breiteren Satz an Benchmarks durchzuführen und den Cache-Footprint zu messen.
Jeff Dean: Wir haben eine Fähigkeit [Skill] geschrieben, die dem Modell im Wesentlichen beibrachte, die Meisten dieser Schritte in verschiedenen Sequenzen auszuführen, sodass es eigenständig eine selbstverbessernde Benchmark-Messung und Code-Änderungen durchführen, die Leistungssteigerung messen und darauf iterieren konnte. Das schien für bestimmte Arten von Problemen ziemlich gut zu funktionieren. Im Grunde geben wir dem Modell damit einfach unseren eigenen menschlichen Lösungsansatz in einer Form weiter, die es nutzen kann.
Diana Hu: Wow, das klingt sehr beeindruckend. Sie meinen also, Sie haben diese Fähigkeit geschaffen, und wenn jemand darauf Zugriff bekäme, könnte er Optimierungen auf dem Niveau von Jeff Dean durchführen. Es wirkt, als würde die Welt darum reißen und es wäre für jemanden unendlich viel Geld wert, darauf Zugriff zu haben.
Jeff Dean: Wir haben vor ein paar Monaten tatsächlich ein Dokument namens „Performance Hints“ veröffentlicht, das Sanjay und ich verfasst haben. Das ist ein etwa 30-seitiges Dokument über verschiedene Arten von Performance-Tricks. Einige Leute haben sich das genommen, es in zusammengefasster Form an verschiedene Modelle gefüttert und festgestellt, dass das Modell dadurch besser in der Lage ist, über Leistungsprobleme im Code zu rationieren.
Diana Hu: Sie haben es hier gehört. Sie können Ihren eigenen Code im Grunde wie Jeff Dean optimieren, wenn Sie sich dieses von ihm veröffentlichte Paper „Performance Hints“ greifen.
Jeff Dean: Jau. Es ist frei verfügbar, das solltet ihr alle mal ausprobieren.
Warum langlaufende Agenten scheitern
Diana Hu: Sehr cool. Nun sprechen Sie über Agenten. Jeder hier baut wahrscheinlich gerade einen oder hat irgendwann einen gebaut. Ich bin sicher, jeder hat schon erlebt, dass sein Agent bei Schritt 30 oder 40 entgleist. Agenten sind großartig bis etwa Schritt 10 oder so, und werden ab Schritt 50 wacklig. Was ist Ihrer Ansicht nach die Einschränkung heutzutage? Sind es Kontext-Evaluatoren oder einfach Fehler, die sich aufsummieren, weil es im Grunde ein offenes System ist?
Jeff Dean: Logischerweise möchten wir, dass Agenten über sehr lange Zeiträume hinweg laufen können, denn nur so werden sie immer kompliziertere Probleme lösen. Aber wie Sie heute beobachten, stellen sie bisweilen nach 10 Interaktionen mit den Tools ihre Arbeit ein. Manchmal liegt das daran, dass das Modell versucht, etwas zu tun, womit es nicht viel Erfahrung hat. Es wurde auf eine bestimmte Menge an Dingen trainiert, und sobald man sich ein wenig von der Verteilung („Distribution“) dessen entfernt, was es zu tun weiß, fängt seine Leistung an sich zu verschlechtern – wie bei den meisten Modellen des maschinellen Lernens. Je weiter man sich aus der Komfortzone dessen entfernt, was es beherrscht, desto wahrscheinlicher ist es, dass es nicht mehr optimal funktioniert.
Jeff Dean: Dagegen lässt sich eine Reihe von Dingen tun. Eines davon ist, dem Modell Fähigkeiten und Hinweise zu geben, die es tendenziell auf dem heller erleuchteten Pfad dessen halten, was es tatsächlich beherrscht. Multi-Agenten-Systeme einzusetzen, in denen mehrere Agenten unterschiedliche Ansätze verfolgen und ein weiteres Modell oder ein anderer Agent bewertet, welche davon vielversprechend erscheinen, ist ein weiterer Weg, um den Raum möglicher Lösungen zu durchsuchen, an den vielversprechendsten festzuhalten und diejenigen zu verwerfen, die sich als untauglich erwiesen haben oder entgleist sind. Das ist eine äußerst nützliche, allgemeine Technik: Inferenzzeit-Computing zur Durchführung einer Suche nach plausiblen Wegen zur Problemlösung, wodurch sich eine deutlich höhere Leistung oder Zuverlässigkeit bei langlaufenden Agenten-Workflows erzielen lässt.
Diana Hu: Auf welche Weisen haben Sie diesen konkreten Workflow für Ihre Agenten intern implementiert?
Jeff Dean: Wir verfügen über entsprechende Testumgebungen [Harnesses] und eine ganze Reihe von Fähigkeiten, insbesondere in der internen Entwicklungsumgebung von Google. Wir haben Fähigkeiten integriert, damit die Agenten wissen, wie sie zahlreiche unserer internen Programmiertools, Code-Reviews, Leistungsmessungen oder Log-Dateien abrufen können. Das sind schlicht Skills, die man dem Basismodell hinzufügen kann, selbst wenn es nicht exakt darauf trainiert wurde, wie ein interner Google-Ingenieur Log-Dateien aus unserem proprietären System abruft. Mit der richtigen Definition von Fähigkeiten bringt man es tatsächlich zum Laufen, und das steigert den Nutzen der Agenten enorm.
Wo Startups Google nach wie vor schlagen können
Diana Hu: Sprechen wir nun darüber, wo Startups gewinnen können. Dieser Abschnitt liegt mir persönlich sehr am Herzen, da jeder in diesem Raum als künftiger Gründer entscheiden muss, was er bauen will. Das Besondere an Google ist, dass Sie alles im System co-designen, von den Prozessoren bis zu den Produkten. Welches sind die Ebenen, die ein Unternehmen wie Google kontinuierlich weiterbauen, vertiefen und beherrschen wird, und wo kann ein Zwei- oder Drei-Personen-Team nach wie vor gewinnen?
Jeff Dean: Offensichtlich versuchen Google, unsere Gemini-Modelle und unsere Hardware-Infrastruktur sehr allgemeine Modelle zu bauen, die fast alles können. In vielen Fällen bedeutet dies jedoch, dass wir nicht den Fokus auf bestimmte nischige Domänen legen, in denen vielleicht eine wirklich gut gestaltete Benutzeroberfläche und ein dazugehöriges Modell mitsamt Skills – oder ein spezialisiertes Modell, das nicht zum allgemeinen Mix gehört, den unsere Modelle abdecken – einen signifikanten Vorteil erzielen können. Man kann etwas Begeisterndes, hochpräzises und extrem hochwertiges für eine Domäne aufbauen, für die man eine echte Leidenschaft hegt. Genau dort haben zwei oder drei Personen in einem Raum, die das aufbauen, einen Vorteil.
Jeff Dean: Ich möchte allerdings auch warnen, dass die allgemeinen Modelle in einem immer breiteren Spektrum an Aufgaben definitiv besser werden. Man muss sich also die Frage stellen: Wird das, woran man arbeitet, von Bestand sein, oder werden die führenden Modelle das in den nächsten 6 bis 12 Monaten ohnehin beherrschen, oder ist es etwas, das sie erst in 2 oder 3 Jahren können werden? Diesen Aspekt sollte man bei der Entscheidung, woran man arbeitet, unbedingt abwägen.
Diana Hu: An den allgemeinen Modellen werden Sie natürlich weiterarbeiten und sie kontinuierlich verbessern. Wie sollte das Publikum darüber nachdenken, welche Bereiche es sich aussucht und bearbeiten soll?
Jeff Dean: Das Wichtigste ist, sich etwas auszusuchen, worüber man restlos begeistert ist, das man unbedingt bauen möchte und von dem man glaubt, dass es in der Welt nützlich sein wird. Wenn man das tut, ist man bereits weit im Vorteil gegenüber jemandem, der aufwacht und denkt: „Das will ich eigentlich gar nicht machen“, oder der etwas baut, das für die Welt oder viele Menschen gar nicht so nützlich ist. Das ist das wichtigste Auswahlkriterium, das ich für die Frage anzulegen versuche, woran ich als Nächstes arbeiten sollte.
Jeff Dean: Zweitens sollte man prüfen, was die aktuellen, allgemeineren Modelle in diesem Problembereich bereits leisten können. Man kann sie testen: Sind sie in der Lage, diese Aufgabe sehr gut zu erledigen? Wenn sie dabei völlig versagen, ist das wahrscheinlich ein gutes Zeichen. Wenn sie es ansatzweise, aber nicht wirklich gut hinbekommen, ist das vielleicht kein so gutes Zeichen. Das deutet vermutlich darauf hin, dass diese Fähigkeit in jenen Modellen bereits im Entstehen begriffen ist und sich durch mehr Trainingsdaten, großskalierte Modelle oder Ähnliches voraussichtlich verbessern wird. Suchen Sie nach etwas, bei dem das Modell zu 0 % oder 1 % erfolgreich ist, nicht zu 20 %.
Diana Hu: Wie findet man solche Bereiche? Sind das Dinge, die faktisch außerhalb der Verteilung („out of distribution“) des Trainingssets liegen, und wie genau sieht die Problemform aus, die dazu passt?
Jeff Dean: Manchmal ist es ein Produkt, das Sie entwickeln und das Zugriff auf eine bestimmte Art von Daten hat, über die ein allgemeines Modell möglicherweise nicht verfügt. Es könnte sein, dass Sie etwas bauen, um Nutzern bei der Organisation all ihrer persönlichen Informationen zu helfen, und das allgemeine Modell hat darauf keinen Zugriff. In diesem Fall haben Sie einen riesigen Vorteil, weil Ihr Produkt plötzlich Einblick in wichtige Daten erhält.
Jeff Dean: Es könnte sich auch um ein unglaublich schweres Problem handeln: Wenn Sie an die richtigen Trainingsdaten herankommen und ein spezifischeres Modell trainieren können als ein universelles, lässt sich das auf sehr kostengünstige Weise bewerkstelligen. Vielleicht erfordert es gar nicht so viel Rechenleistung, ein Nischenmodell für dieses spezielle Problem zu trainieren, aber man erhält etwas mit extrem hoher Genauigkeit. Das kann bisweilen ein hervorragender Baustein sein, um ein wichtiges Problem zu lösen, das von einem allgemeinen Modell vielleicht nicht sonderlich gut gehandhabt wird.
Diana Hu: Es gibt im Grunde zwei Wege. Der erste Weg ist etwas amüsant: Ihr sortiert die Informationen der Welt, das ist gut abgedeckt, aber das Organisieren persönlicher Informationen ist noch offen. Der zweite Weg betrifft die von Ihnen erwähnten spezialisierten Modelle in bestimmten Domänen. Können Sie uns mehr darüber verraten, was das für Domänen sein könnten?
Jeff Dean: Wenn man sich die Arbeit meiner Kollegen an AlphaFold ansieht, war das ein sehr spezifisches Modell für die Proteinfaltung. Es war äußerst erfolgreich und in der Lage, diesen Bereich wirklich hervorragend zu handhaben, sodass man plötzlich über dieses fantastische Tool und Modell verfügt, das Fragen zu Proteinen und ihrer Struktur extrem effektiv beantworten kann. Aber es ist kein allgemeines Modell, sondern ein sehr spezifisches. Es gibt andere Domänen, in denen dieser Ansatz sehr gut funktionieren kann – etwa in der Materialwissenschaft oder im Chipdesign –, wodurch Sie die Fähigkeiten eines hochpräzisen, aber nischenbezogenen Modells nutzen können, um Dinge zu tun, die heute noch schwerfallen.
Wie man ein KI-niver Founder wird
Diana Hu: Wenn einige von Ihnen ein Problem mit einer ähnlichen Struktur wie AlphaFold finden, könnte das ein lohnendes Betätigungsfeld sein. Nehmen wir nun an, Sie haben ein Problem gefunden, an dem Sie arbeiten möchten. Wir sprechen jetzt ein wenig darüber, wie man ein KI-natives Startup-Gründer wird. Sie haben in der Vergangenheit gesagt, dass das Management einer Flotte von 50 oder 100 Agenten im Wesentlichen darin besteht, wirklich gute, präzise Design-Dokumente oder Spezifikationen zu schreiben. Wie erlangt man darin Meisterschaft? Wie sehen solche Dokumente aus?
Jeff Dean: Sie werden bei der Arbeit mit Ihren virtuellen Agenten deutlich mehr Erfolg haben, wenn Sie klar spezifizieren können, was Sie wollen. Je präziser Sie Ihre Wünsche formulieren, desto mehr Richtlinien und Konturen hat der Agent an der Hand, um zu erkennen, was er erreichen soll. Wenn Sie hingegen kaum Vorgaben machen, muss der Agent raten, was Sie gemeint haben könnten. In vielen Fällen schlussfolgert er dann Dinge, die von Ihren Vorstellungen abweichen. Wir haben Informatikern von Anfang an immer gesagt, dass es extrem wichtig ist, genau zu spezifizieren, was die zu schreibende Software leisten soll, bevor man mit dem Programmieren beginnt. Mittlerweile verfügen wir über agentenbasierte Systeme, die das Schreiben übernehmen können, aber die Bedeutung einer klaren Spezifikation hat in Wirklichkeit sogar zugenommen. Früher übergab man die Aufgabe an einen hochintelligenten Menschen, der vielleicht über Kontext verfügte oder Nachfragen stellen konnte. Agenten können das bis zu einem gewissen Grad auch, aber klare Spezifikationen sind nach wie vor eine hervorragende Idee.
Jeff Dean: Um Ihnen ein Beispiel für die Verwendung eines Coding-Agenten zu geben, das extrem gut funktioniert: Man kann heutigen Modellen sehr effektiv auftragen, Software von einer Programmiersprache in eine andere zu übersetzen. In diesem Fall verfügt man über eine unglaublich detaillierte Spezifikation: Man besitzt die gesamte Software, die genau beschreibt, was das System tun soll. Wenn Sie eine Python-Implementierung von etwas haben und eine Go-Implementierung davon wünschen, ist das eine Aufgabe, die Modelle heutzutage scheinbar unglaublich gut meistern. Der Agent kann sämtliche in Python vorhandenen Tests nehmen, sie nach Go übersetzen, sicherstellen, dass sie in der Go-Version erfolgreich durchlaufen, Verhaltensunterschiede zwischen den Implementierungen vergleichen, bis keine mehr vorhanden sind, und dabei hochgradig effektiv sein, weil die Spezifikation so glasklar ist.
Diana Hu: Nehmen wir nun an, jeder Gründer meistert den gleichzeitigen Einsatz von Hunderte von Agenten und der gesamte Code wird von den Agenten geschrieben. Was wird dann zur knappen Fähigkeit?
Jeff Dean: Einen unglaublich guten Instinkt („Geschmack“) dafür zu haben, woran man seine Agenten arbeiten lässt. Das ist der Kern eines Forschungsproblems aus meinem Bereich. Ein Forscher mag über alle Werkzeuge und Techniken verfügen, aber ein Großteil des Erfolgs hängt oft davon ab, in welches Problem man seine Zeit investiert. Wenn man das Problem gut auswählt und es erfolgreich löst, ist das weitaus wertvoller, als eine wissenschaftliche Untersuchung zu einem eher langweiligen Problem exzellent auszuführen. Diese übergeordnete Weisheit darüber, woran man arbeiten sollte, ist unglaublich wichtig, und ich glaube nicht, dass Modelle darin zwangsläufig besonders gut sein werden. Man wird Menschen haben, die KI-gestützte Berechnungen stark lenken, um Großes und das schneller zu erreichen. Dieser Kern dessen, was man von seinen Modellen verlangt, ist das entscheidende Element, auf das man sich konzentrieren sollte.
Diana Hu: Sprechen wir noch etwas mehr über diesen Instinkt, denn in der heutigen Ära des Agenten-Codings wird viel darüber geredet. Wie entwickelt man diesen Instinkt? Wie macht man ihn greifbar?
Jeff Dean: Das ist eine schwierige Sache. Es ist ja nicht so, dass es für diesen Instinkt in den meisten Fällen ein messbares Ziel gibt. Ein Teil davon entstammt der Erfahrung. Wenn man in der Vergangenheit an vielen verschiedenen Problemen gearbeitet hat, lehrt einen das gewissermaßen, welche Arten von Problemen in Zukunft interessant sein könnten oder welche Dinge sich durch das Zusammenstückeln früherer Ansätze gerade so eben realisieren lassen und welche offenen Probleme man noch lösen muss, um etwas Magisches oder extrem Nützliches zu erschaffen.
Jeff Dean: Ein anderer Weg, um eigene Erfahrungen zu sammeln, besteht darin, eine Reihe von Dingen aufzuschreiben, die Ihrer Ansicht nach in den kommenden 12 Monaten wichtig werden könnten. Vielleicht greifen Sie sich eines davon heraus, um daran zu arbeiten, aber nach 12 Monaten gehen Sie zurück und werten aus, welche dieser anderen Dinge sich tatsächlich als wichtig erwiesen haben, welche davon andere Menschen auf der Welt umgesetzt haben und welche anscheinend noch niemand angegangen ist. Das liefert Ihnen zahlreiche Referenzpunkte für die Ausbildung Ihres eigenen Instinkts. Das ist eine wichtige Fähigkeit, die man besitzen sollte.
Hinterfragen Sie Ihre größten Annahmen
Diana Hu: Ein dritter Weg, über den wir vorhin sprachen, waren völlig verrückte Gedankenexperimente.
Jeff Dean: Das ist ein weiterer guter Ansatz. Manchmal ist es ratsam, Dinge, die den Anschein erwecken, als würden sie von den meisten Leuten als gegeben hingenommen, eben nicht als gegeben hinzunehmen. Ich habe neulich mit einigen Kollegen ein verrücktes Gedankenexperiment durchgeführt. Seit 60 Jahren leistet die gesamte Silizium-Chipdesign- und -fertigungsindustrie unglaubliche Arbeit, um immer kleinere Transistoren mit sehr geringen Fehlerraten herzustellen. Die implizite Annahme, die wir haben, lautet: Jeder Chip, den wir im selben Design herstellen, sollte exakt identisch mit jedem anderen Chip sein. Es darf kein einzelnes Bit kippen; kein Bit darf seinen Zustand unabsichtlich ändern. Es sind allerlei Fehlertoleranzen eingebaut, und Speicher verfügen heutzutage über ECC-Fehlerkorrektur.
Jeff Dean: Im Makromaßstab treffen wir diese Annahme beim Bau großskalierter verteilter Systeme jedoch nicht. Wir bauen zuverlässige, verteilte Großsysteme aus unzuverlässigen Komponenten. Einzelne Festplatten können ausfallen, aber Ihre Daten müssen sicher sein. Wir haben Mechanismen auf einer höheren Ebene, die es uns ermöglichen, drei Kopien der Daten auf drei verschiedenen Maschinen und in drei verschiedenen Racks zu speichern, sodass selbst dann, wenn ein einzelner Rack-Switch, eine einzelne Maschine oder eine Festplatte versagt, Ihre Daten erhalten bleiben. Wir nutzen Reed-Solomon-Codierungstechniken. Aber diesen Ansatz scheinbar nicht auf extremster Ebene direkt auf der Transistorenebene der von uns genutzten Technologie anzuwenden.
Jeff Dean: Ein interessantes Gedankenexperiment lautet demnach: Was würde passieren, wenn man versuchte, ein System aus Transistoren zu bauen, die vielleicht 20 Fehler pro Tag aufweisen, anstatt einen alle eine Million Jahre? Das wäre ein völlig anderer Designpunkt und würde es möglicherweise erlauben, auf der Fertigungsseite wirklich faszinierende Dinge zu tun. Man hätte ganz andere Entwurfsmethodiken, denn wenn man ein Signal von A nach B transportieren möchte und über diese extrem unzuverlässigen Transistoren verfügt, greift man vielleicht auf ganz andere Signalisierungsmethoden zurück. Man sendet es möglicherweise über mehrere redundante Pfade, um sicherzustellen, dass es auf mindestens einem von ihnen ankommt. Ich denke, das wäre eine ziemlich interessante Reihe von Gedankenexperimenten. Ich behaupte nicht, dass wir das sofort tun sollten, aber das ist genau die Art von Vorgehensweise, bei der man gelegentlich Annahmen hinterfragen sollte. Oft funktionieren solche Gedankenexperimente nicht, weil es sehr gute Gründe dafür gibt, warum wir diese Dinge in den letzten 50 Jahren so und nicht anders gemacht haben, aber es ist gut, sie von Zeit zu Zeit neu zu bewerten.
Diana Hu: Das ist wahnsinnig faszinierend. Es erinnert stark an neuromorphes Computing oder an das menschliche Gehirn und die Funktionsweise der Natur.
Jeff Dean: Signale in unserem Gehirn sind nicht sonderlich zuverlässig darin, von einem Ort zum anderen zu gelangen. Wenn im Gehirn wirklich wichtige Informationen von A nach B übertragen werden müssen, gibt es mehrere Pfade, die dies ermöglichen.
Diana Hu: Was ist eine dieser verrückten Annahmen, die Sie über Bord warfen und die in der Vergangenheit tatsächlich zu einem wirkungsvollen System geführt hat?
Jeff Dean: TPUs sind ein gutes Beispiel: Die Hardware für eine sehr nischenhafte Problemdomäne zu spezialisieren, bevor diese Domäne so wichtig erschien, wie sie es heute ist. Die Entstehungsgeschichte von MapReduce ist ein weiteres gutes Beispiel. Sanjay, ich selbst und eine Reihe anderer Kollegen hatten an verschiedenen Iterationen des Crawling- und Indexierungssystems von Google gearbeitet. Wir hatten jede Menge manuell parallelisierten Code geschrieben, der mit zahlreichen Checkpoints versehen war, um sicherzustellen, dass er robust und zuverlässig läuft, selbst wenn er auf 100 oder 1.000 Computern ausgeführt wird und einige davon ausfallen. Dieser Code war jedoch untrennbar vermischt mit der vergleichsweise einfachen Aufgabe, die man eigentlich lösen wollte: etwa den Inhalt aller Webseiten durchzusehen und parallel eine Zuordnung von URLs zur jeweiligen Sprache der Seite zu berechnen. Das eigentliche Ziel ging in all diesem Code für Parallelisierung und Ausfallsicherheit völlig unter.
Jeff Dean: Wir erinnerten uns an unsere Ausbildung in funktionalen Programmiersprachen und erkannten, dass wir diese Probleme durch eine begriffliche Abstraktion betrachten und die MapReduce-Abstraktion über die Implementierung legen konnten. Unterhalb dieser Implementierung konnten wir sämtliche Checkpoint- und Ausfallsicherheitsmechanismen in eine untergeordnete Bibliothek verpacken, auf die sich fortan alles aufbauen ließ. Das wurde zu einer enorm erfolgreichen Methode, um hochskalierte Berechnungen bei Google auf robuste und verlässliche Weise zu handhaben – entsprungen aus genau jenem Gedankenexperiment: Wenn wir die Sache abstrakt betrachten, können wir dann zahlreiche Probleme finden, die in dieses Abstraktionsmuster passen?
KI, die bessere KI baut
Diana Hu: Sie sprachen an, dass Sie sich zurzeit für maßgeschneiderte Hardware interessieren. Mittlerweile platziert AlphaChip Chips. Sie haben auch AlphaEvolve, das Lösungen vorschlägt, bewertet und alle funktionierenden behält. Es wirkt, als würden Sie beginnen, Systeme zu konstruieren, die sich selbst potenzieren und eine KI erschaffen, die wiederum KI baut.
Jeff Dean: Allgemeiner ausgedrückt liegt dem das Fundament der wissenschaftlichen Methode zugrunde: Man schlägt ein Experiment vor, implementiert, was zur Durchführung des Experiments erforderlich ist, bewertet das Experiment und wertet die Ergebnisse aus. Es gibt immer mehr Probleme, die sich mittlerweile so implementieren lassen, dass diese gesamte Schleife – bei der man nicht nur ein paar, sondern sehr, sehr viele Experimente ausführt, weil man diesen Loop automatisieren kann und dessen Latenz extrem gering hält – von enormer Bedeutung sein wird. Sie wird es uns ermöglichen, zahlreiche verschiedene Problembereiche in Wissenschaft und Technik, im Design von Modellen des maschinellen Lernens selbst sowie bei ingenieurtechnischen Aufgaben wie dem Chipdesign anzugehen.
Jeff Dean: Wenn man all das auf automatisierte Weise bewerkstelligen kann und über ein Orchestrierungs-Framework verfügt, das übergeordnete Ziele in Teilprobleme zerlegen kann, wobei jedes dieser Teilprobleme eine solche automatisierte Schleife zur Erforschung des besten Lösungswegs durchläuft, dann kann das Orchestrierungs-Framework diese Teillösungen zu einer Gesamtlösung für das übergeordnete Problem zusammenfügen. Das wird den Fortschritt des maschinellen Lernens, die Wissenschaft und das Ingenieurwesen massiv beschleunigen. Das wird schlicht phänomenal sein.
Diana Hu: In vielen Bereichen, in denen man sehr gute Evaluatoren hat, die an formal verifizierbare Dinge heranreichen, sind die Voraussetzungen ideal für KI-Systeme, die sich selbst verbessern können.
Jeff Dean: In vielen Fällen müssen Ihre Evaluatoren deutlich schneller gemacht werden. Als Beispiel: Meine Kollegen haben vor vielleicht einem Jahrzehnt einige Arbeiten zur Quantenchemie durchgeführt, bei denen man die Eigenschaften eines bestimmten Moleküls verstehen möchte. Man kann eine bestimmte Molekülkonfiguration generieren und will wissen, welche Eigenschaften sie besitzt. Dazu lässt sich ein extrem rechenintensiver Dichtefunktionaltheorie-Simulator [DFT-Simulator] ausführen, dessen Berechnungen für eine einzige Fragestellung eine ganze Nacht in Anspruch nehmen können. Meine Kollegen nahmen eine Reihe von Ausgaben aus solchen Simulationsläufen – die eingegebenen Molekülkonfigurationen und die Ergebnisse des aufwendigen Simulators – und nutzten diese, um eine neuronale Annäherung an den Simulator zu trainieren. Anstatt einer ganzen Nacht entwickelten sie etwas, das 300.000-mal schneller und nahezu ebenso präzise war wie der Betrieb des vollständigen Simulators.
Jeff Dean: Das verändert die Art und Weise, wie man Wissenschaft betreibt, von Grund auf. Wenn man 10 Millionen Dinge untersuchen muss, kann man das während der Mittagspause erledigen, anstatt dass es sich um ein sechsmonatiges Unterfangen handelt, bei dem man mühsam genug Rechenleistung zusammenkratzt, um all diese Simulationen auszuführen. Es gibt in vielen Domänen ein enormes Potenzial für weitaus schnellere Validierungsmodelle, möglicherweise gelernte Validierungsmodelle, die eine Approximierung der wahren Antwort wesentlich rascher ermöglichen. Das verändert die Konzeption dieser experimentellen Schleifen und die Geschwindigkeit, mit der man sie durchlaufen kann.
Diana Hu: Auf welche Bereiche und Probleme freuen Sie sich ganz besonders, die mithilfe dieser beschleunigten wissenschaftlichen Methode gelöst oder erreicht werden?
Jeff Dean: Das maschinelle Lernen selbst ist ein solcher Bereich. Können wir ein Modell entwickeln, das sich durch die Durchführung zahlreicher Experimente rekursiv selbst verbessert? Wenn man sich überlegt, wie Modelle heute in großen Forschungsteams weiterentwickelt werden, ist es üblich, dass Menschen Ideen entwickeln, eine Reihe kleinerer Experimente durchführen, prüfen, ob diese gut funktioniert haben, die vielversprechendsten Ansätze im größeren Maßstab ausprobieren, das Ganze bewerten und die Ergebnisse in ein neues Rezept für das Modell integrieren.
Jeff Dean: Es gibt kein echtes Hindernis, das dagegen spräche, daraus einen wesentlich stärker automatisierten Loop zu machen, in dem das Modell selbst entscheidet, Erkundungen anzustellen – vielleicht mit einem kleinen Anstoß auf höchster Ebene durch Menschen, wie etwa: „Warum probierst du nicht ein paar neue Ideen rund um Modellarchitekturen aus, die diesen Aspekt einbeziehen?“ Es wird daraufhin massenhaft Experimente durchführen, sehen, welche davon funktionieren, und sie in einem weitaus höheren Tempo integrieren. Im Grunde möchte man seine Entdeckungen pro Recheneinheit optimieren.
Diana Hu: Wenn jeder in diesem Raum Gründungsmitglied wird oder seine Karriere startet, wird er wahrscheinlich zahlreiche Absagen einstecken. Das ist Ihnen auch passiert, Jeff. Im Jahr 2014 verfassten Sie zusammen mit Geoffrey Hinton und Oriol Vinyals ein Paper zur Destillation – also der Nutzung eines großen Lehrer-Modells, um ein viel kleineres, effizienteres Modell zu trainieren, das mit weniger Parametern rechengünstiger ist. Das hat sich zu einem Standardtrick entwickelt, den heute jeder in der Industrie verwendet, und dieses Paper wurde damals von der NeurIPS abgelehnt.
Jeff Dean: Ich mache dem Programmkomitee keinen Vorwurf. Sehr oft erhält ein Paper drei Reviews, und einer der Gutachter schaute darauf und befand, dass es wahrscheinlich keinen signifikanten Einfluss haben würde. Als wir das Paper verfassten, sahen wir darin ein extrem wichtiges Problem, weil uns klar war, dass das Erstellen günstigerer, hochleistungsfähiger Modelle aus großskalierten Modellen etwas war, das wir in Bereichen wie Sprache oder Vision dringend umsetzen wollten, um Modellen mehr Menschen zugänglich zu machen. Manchmal verfügt der Gutachter jedoch nicht über diese Erfahrung, weil er vielleicht nicht über großskalierte KI-Dienste nachdenkt, sondern sich stattdessen fragt, ob es sich um einen fundamentalen Durchbruch handelt. Solche Paper werden gelegentlich abgelehnt, und das ist in Ordnung. Wir haben es auf arXiv veröffentlicht, die Leute haben es gelesen, die Leute haben es genutzt, und alles ist gut. Wir verwenden dieses Prinzip selbst, um unsere Flash-Modelle aus unserem großskalierten Pro-Modell herzustellen. Das ist mit ein Grund dafür, warum unsere Flash-Modelle in Gemini im Verhältnis zu ihrer Größe und Geschwindigkeit so leistungsfähig sind und zu den besten ihrer Modellgrößenklasse in den Benchmarks gehören.
Diana Hu: Selbst wenn man eine Absage erhält: Einfach weitermachen.
Jeff Dean: Das ist die Lektion, die ich daraus ziehen würde.
Bauen Sie etwas, das wirklich zählt
Diana Hu: Sie sind 1999 als 20-Personen-Startup zu Google gestoßen. Wenn Sie den 25-jährigen Jeff Dean von damals nehmen und ihn mit Ihren heutigen Fähigkeiten in unsere Gegenwart teleportieren könnten – was würden Sie tun? Würden Sie in einem Spitzenforschungslabor („Frontier Lab“) anheuern oder ein Unternehmen gründen?
Jeff Dean: Das ist immer schwer zu sagen, und es ist eine sehr persönliche Entscheidung darüber, worauf man seine Zeit verwenden möchte. Für mich gehören zu den wichtigsten Fragen: Arbeitest du an etwas, das dir wirklich am Herzen liegt, und wenn du dabei mit Kollegen vorankommst, mit denen du gerne zusammenarbeitest, wird das die Welt auf positive Weise verändern? Wirst du in der Lage sein, diesen Dienst anzubieten, um Biochemikern, Programmierern oder allen Verbrauchern im Internet zu helfen? Worauf man hstreben sollte, ist, einen positiven Einfluss auf die Welt auszuüben, mit Menschen zu arbeiten, die man schätzt, hart zu arbeiten und sein Bestes zu geben.
Jeff Dean: Was den Einstieg in ein Frontier Lab im Vergleich zur Gründung eines Unternehmens mit zwei oder drei engen Freunden angeht – das sind völlig unterschiedliche Erfahrungen. In einer großen, etablierten Organisation verfügt man über Strukturen, zahlreiche fantastische Kollegen, die Dinge wissen, die man selbst nicht weiß, eine Menge interessanter Probleme, an denen man arbeiten kann, und eine bestehende Plattform für gesellschaftliche Wirkung, auf der die eigene Arbeit das Leben vieler Menschen auf der Welt beeinflusst. Als sehr kleines Startup benötigt man eine Sache, für die man brennt, und es ist mit enormen Risiken verbunden, sich dieses Problem so anzugehen, dass man erfolgreich ist und ein Unternehmen ausbaut. Aber das kann gleichzeitig unglaublich lohnend sein. Fragen Sie sich unabhängig vom gewählten Weg zumindest stets: Wenn ich an diesem Problem arbeite und das bestmögliche Ergebnis eintritt, wird die Welt dadurch in irgendeiner Weise deutlich besser sein oder wird die Welt sagen: „Ähm, das ist ja ganz nett, aber egal“? Letzteres ist nicht die Art von Vorhaben, in das man seine Zeit investieren sollte.
Diana Hu: Sie haben es verstanden, ein unglaublicher Mentor und Manager für zahlreiche Ingenieure zu sein und gigantische Systeme aufzubauen. Was sind einige Lektionen für alle hier Anwesenden darüber, wie man mit klugen Köpfen arbeitet oder kluge Leute findet?
Jeff Dean: Man sucht sich immer Menschen, die über wirklich herausragende Fähigkeiten in einem Bereich verfügen, der in dem Team, das man aufzubauen versucht, benötigt wird – sei es innerhalb eines Unternehmens oder bei einer Gründung. Man möchte jedoch auch Personen finden, in deren Gesellschaft man sich rundum wohlfühlt, da man viel Zeit mit Menschen verbringen wird, die an extrem schwierigen Problemen arbeiten. Man sucht nach Personen mit niedrigem Ego, echten Teamplayern und Fähigkeiten, die die eigenen ergänzen.
Jeff Dean: Ich persönlich finde die Arbeit in einem kleinen Team immer amüsant und bereichernd, in dem die Leute Dinge wissen, die mir fremd sind, und in dem ich vielleicht über Kompetenzen verfüge, die bei anderen nicht so stark ausgeprägt sind. Man baut gemeinschaftlich etwas auf, das keiner von Ihnen allein bewältigen könnte, und gewinnt dabei ganz nebenbei selbst jede Menge neues Wissen und Fähigkeiten hinzu – und die anderen ebenso. Betrachten Sie Ihre Ingenieurs- oder Forschungskarriere so, als würden Sie einen fantastischen Werkzeuggürtel voller Techniken besitzen. Sie sollten diesem Gürtel immer neue Werkzeuge hinzufügen, denn man weiß nie, wann man auf ein Problem stößt, bei dem man eben diese vier spezialisierten Werkzeuge anstelle jener drei benötigt. Mehr Werkzeuge im Repertoire zu haben, erhöht die Wahrscheinlichkeit, dass die Probleme, denen Sie in Zukunft begegnen, von Ihnen gelöst werden können.
Diana Hu: Mehrere Personen in diesem Raum werden unweigerlich etwas so Wirkungsvolles erschaffen, wie Sie es mit MapReduce, der TPU, der Destillation und so weiter getan haben. An welchem Problem würden Sie sich wünschen, dass sie arbeiten?
Jeff Dean: Die Welt ist ein verdammt großer Ort und voller Probleme. Ich persönlich bin besonders begeistert von neuen Ansätzen im Hardwarebereich, wie etwa wesentlich effizienterer Inferenz-Hardware. Ich glaube, es gibt fundamental andere Arten von Algorithmen für das maschinelle Lernen, die weitaus dateneffizienter sein könnten als die Ansätze, die wir heute einsetzen. Wenn man sich unsere heutigen großskalierten Modelle vor Augen führt, haben diese im Alter von 18 Jahren wahrscheinlich tausendmal so viele Daten gesehen wie ein Mensch. Dennoch ist der Mensch im Alter von 18 Jahren in vielen Dingen besser und auf Augenhöhe mit Spitzenmodellen, die weitaus größere Datenmengen konsumiert haben. Könnte man Systeme entwickeln, die wesentlich dateneffizienter sind und kontinuierlich aus ihren eigenen Handlungen lernen? Kontinuierliches Lernen („Continual Learning“) ist höchst interessant. Multi-Agenten-Interaktionen sind faszinierend. Wege zu finden, um einen besseren Diskurs zwischen Menschen auf der Welt zu ermöglichen, zivilisiertere Unterhaltungen zu führen und Menschen weltweit dabei zu helfen, genau die Personen kennenzulernen, die sie aufgrund ihrer Interessen treffen sollten – all das sind spannende Dinge. Es gibt so viele coole Dinge auf der Welt, und wir sollten alle danach streben, dass noch coolere Dinge geschehen.
Diana Hu: Das klingt wunderbar. Vielen herzlichen Dank, Jeff Dean. Das war alles für heute.
Jeff Dean: Ich danke Ihnen. Tschüss zusammen.