DruckFin

Google-transcript: Jeff Dean over inferentiehardware-specialisatie en zelfverbeterende AI-systemen

Y Combinator Startup School 2026, 20 september 2026

Zijn AI-modellen al junior engineers?

Diana Hu: Goed zo. Zullen we beginnen, Jeff?

Jeff Dean: Zeker. Klinkt goed.

Jeff Dean: Ja, ik ben bang dat ik mijn stem kwijt ben. Normaal klink ik niet helemaal zoals dit, maar we doen wat we kunnen.

Diana Hu: Goed zo. Jeff, welkom. En nogmaals, enorm bedankt dat je hier bent. Zeker omdat ik net verkouden ben geworden, en dank dat je hier bent.

Diana Hu: Je hebt MapReduce, Bigtable, TensorFlow, de TPU en Gemini gebouwd. We zouden een heel uur kunnen besteden aan alles wat je hebt gedaan, maar wat ik geweldig vind, is dat je in het openbaar nog steeds gewaagde voorspellingen doet. Vorig jaar mei, op AI Ascent 2025, zei je dat AI op het niveau van een junior engineer zit. Dat is ongeveer een jaar geleden. Hoe dichtbij zijn we bij die voorspelling?

Jeff Dean: Ja, ik heb het gevoel dat de modellen een stuk beter zijn geworden in agent-gebaseerde, langlopende coðeringstaken. Het lijkt me vrij duidelijk dat ze inmiddels behoorlijk bekwaam zijn. Afhankelijk van je exacte definitie van een junior engineer klopt het aardig, zou ik zeggen.

Diana Hu: Wat heb je onderschat bij die voorspelling?

Jeff Dean: Ik denk dat het vermogen om steeds complexere taken uit te voeren sneller is gegroeid dan ik dacht. Ook denk ik dat deze agent-gebaseerde systemen buiten het coðeren om echt beginnen te schitteren in andere domeinen. Ik denk dat dat een belangrijk een trend zal zijn in de toekomst.

Diana Hu: Geef ons nog een gewaagde voorspelling. Wat denk je dat de editie van 2027 wordt?

AI-systemen die zichzelf verbeteren

Jeff Dean: Ik denk dat je veel meer automatisering van ML-systemen zelf zult zien. Kort gezegd: ervoor zorgen dat ML-systemen hun capaciteiten verbeteren door talloze experimenten uit te voeren, problemen op te breken in subproblemen, die subproblemen te laten draaien in een strakke, automatische experimenteerlus, de resultaten samen te voegen en vervolgens een verbeterd systeem te creëren uit die volledig geautomatiseerde probleemdecompositie en experimentering. Ik denk dat dat ontzettend spannend wordt. En dat geldt volgens mij niet alleen voor ML, maar ook voor andere vakgebieden in de wetenschap en engineering. Vrijwel overal waar je een meetbare doelstelling hebt, kun je tegenwoordig flinke vooruitgang boeken.

Diana Hu: Laten we nu een stukje teruggaan in de tijd. Ooit, in 2001, draaide Google Search op harde schijven.

Jeff Dean: Jazeker.

Diana Hu: En jij en Sanjay berekenden dat op een gegeven moment de hele zoekindex in al het RAM-geheugen van alle computers die jullie hadden draaien zou passen. Jullie kwamen tot dat radicale inzicht en brachten in wezen binnen een paar dagen, samen met Sanjay, een compleet nieuwe zoekversie in productie die werkte in RAM in plaats van op harde schijven. Dat zorgde ervoor dat Google Zoeken zo snel werd. Geschiedenis heeft de neiging zichzelf te herhalen. Wat is hét "het past in het geheugen"-moment nu in 2026 waar iedereen in deze zaal over zou moeten nadenken en op zou moeten ontwerpen?

De doorbraak van Google Search die alles veranderde

Jeff Dean: Ja, het is net even anders, maar ik denk dat je steeds meer krachtige en energiezuinige inferentie-hardwaresystemen zult zien. Ik denk dat iedereen zich nu realiseert dat inferentie de sleutel is om deze agent-gebaseerde systemen toegankelijk te maken voor steeds meer mensen, dat latency ontzettend belangrijk is, en dat specialisatie van de hardware een cruciale manier is om dingen te maken die energiezuiniger zijn en een lagere latency hebben dan meer algemene computerapparatuur zoals, zeg, GPU's of TPU's. Iedereen hier is het gewend om te wachten op antwoorden van modellen. Wachten is niet leuk.

Diana Hu: Meesterschap over snelheid. Je zegt dus: wat als we niet meer hoeven te wachten?

Jeff Dean: Ja. Stel je voor wat je kunt doen met iets waarbij de latency 50 keer beter is.

AI-agents zullen wekenlang draaien

Diana Hu: Interessante gedachte. Wat is nu één aanname die zo'n 6.000 mensen in deze zaal hebben over AI die al niet meer klopt?

Jeff Dean: Dat is een goede vraag. Ik denk dat één ding is dat mensen zich niet goed realiseren hoe goed het mogelijk is om agent-gebaseerde systemen te hebben die niet slechts een uur of twee uur aan een probleem werken dat je bezighoudt, maar die in bepaalde probleemdomeinen – met zeer krachtige onderliggende modellen – dagen of weken kunnen doorwerken en echt ingewikkelde taken kunnen voltooien. Sommige mensen beginnen hiervan de eerste tekenen te zien, maar ik denk niet dat iedereen dat al volledig heeft geïnternaliseerd. Dat gaat nog een flinke impact hebben.

Diana Hu: Wat is een specifieke taak die jij hebt laten draaien die wekenlang heeft doorgewerkt? Wat was het? Wat gaf je de agents mee om op te lossen?

Jeff Dean: Je kunt agents op pad sturen om compleet nieuwe versies van software te implementeren in andere programmeertalen die betere veiling- of beveiligingseigenschappen of betere prestaties hebben, en dan kunnen ze dat op een zeer serieuze manier daadwerkelijk gaan doen.

Het achterkant-van-een-servtje-rekenwerk dat leidde tot TPU's

Diana Hu: Dat is erg cool. Waar je heel bekend om staat, is dat je ontzettend goed bent in berekeningen op een servetje ( napkin math). Klinkt grappig. Een van de verhalen over jou is dat toen spraakherkenning rond 2013 begon te werken bij Google, jij op een servetje uitrekende dat als elke Google-gebruiker zijn telefoon zou gebruiken, tegen de telefoon zou praten en het spraakherkenningssysteem slechts 3 minuten per dag zou gebruiken, je de servervloot van Google zou moeten verdubbelen. Dat zou ontzettend duur zijn, puur voor spraakvertaling.

Jeff Dean: Ja.

Diana Hu: En in plaats daarvan bouwden jullie in wezen een eigen maatwerkschip, en dat was het ontstaansverhaal van de TPU.

Jeff Dean: Ja. We zagen resultaten van heel hoge kwaliteit bij de op deep learning gebaseerde spraakmodellen die we aan het trainen waren, maar ze waren computationeel duur vergeleken met het oude spraaksysteem. Maar ze halveerden het foutpercentage. Dat stond gelijk aan ongeveer 20 jaar vooruitgang in spraakherkenning in slechts een paar maanden sleutelen aan het model, het wat opschalen en het verzamelen van betere data. Dus we begonnen ons zorgen te maken dat als spraak veel beter zou werken, mensen het vaker zouden gebruiken. Die berekening op de achterkant van een servet ging eigenlijk daarover. Wat als mensen spraakherkenning vaker gaan gebruiken om e-mails te dicteren, tegen hun telefoon te praten of wat dan ook? Het bleek dat we een betere oplossing nodig hadden dan het destijds laten draaien op CPU's. Dus kwamen we met TPU's, die heel gespecialiseerd zijn in in feite lagedeltings-lineaire algebra met lage precisie, wat de kern vormt van bijna alle moderne machine learning-algoritmen die we vandaag de dag gebruiken. Als je een gespecialiseerd chip bouwt voor lineaire algebra met lage precisie en niets anders kunt doen, blijkt dat ontzettend nuttig te zijn voor machine learning-inferentie, ook al kan hij geen Chrome, Word of wat dan ook draaien. Dat leverde een paar jaar later een chip op die 30 tot 80 keer energiezuiniger was dan de CPU's en GPU's van die tijd, en bovendien een stuk lagere latency had, zo'n 20 tot 30 keer lager.

Diana Hu: Ongelofelijk wat een fundament de TPU vandaag de dag is geworden. Er is geen man over boord dat je had kunnen voorspellen dat de TPU zo fundamenteel zou zijn geworden met de transformer-architectuur, die pas ver na jouw uitvinding van de TPU werd bedacht.

Jeff Dean: Ja, daarom hebben we in wezen een lineair algebra-systeem voor algemene doeleinden gebouwd, wat een TPU in de kern eigenlijk is. We wisten dat ML-algoritmen nog steeds in ontwikkeling waren en je wilde niet te veel overspecialiseren, maar wel genoeg om de dramatische prestatievoordelen te behalen van zeer grote vermenigvuldigingseenheden (multiplier units). We konden supersnel geheugen hebben. We konden supersnelle interconnects hebben voor latere TPU's die heel veel chips efficiënt op hetzelfde probleem inzetten. We zijn doorgegaan met het opschalen daarvan en hebben de prestaties over vele, vele generaties heen verbeterd.

Hoe je baanbrekende ideeën vindt

Diana Hu: Ongelofelijk rekenwerk op een servetje. Servetjes zijn handig. Wat voor soort snelle berekening op een servet zou iedereen hier die een toekomstige oprichter wil worden vanavond moeten maken om potentieel iets te bouwen dat net zo invloedrijk is als de TPU?

Jeff Dean: Het is altijd moeilijk te zeggen. Bedenk welke problemen je ziet in wat je ook maar overweegt, welke knelpunten je opmerkt, en of er heel andere manieren zijn om na te denken over oplossingen voor die problemen waarmee je een factor tien of honderd betere prestaties of capaciteiten kunt behalen, of wat dan ook. Soms, als je met samengeknepen ogen naar een probleem kijkt en niet per se gebonden blijft aan precies hoe dat probleem vandaag de dag wordt opgelost, maar hoe je het zou oplossen vanuit first principles, kun je op heel goede ideeën komen waar andere mensen misschien niet aan denken.

Het nieuwe mentale model van de AI-engineer

Diana Hu: Dat is een goede tip. Voor iedereen hier die het niet weet: jaren geleden schreef Jeff een heel beroemde lijst genaamd "Latency Numbers Every Computer Scientist Should Know" (Latencyngetallen die elke computerwetenschapper zou moeten kennen). Dit zijn getallen rondom bijvoorbeeld hoe lang een cache miss duurt, een disk seek, een netwerkpakketje dat reist van, zeg, Californië naar Nederland, heel veel van dit soort getallen over gedistribueerde systemen en systems engineering. Het is ingelijst en uitgegroeid tot de bijbel voor veel engineers van gedistribueerde systemen. Fast forward naar nu, die lijst is toe aan een update. Geef ons de AI-editie voor nu in 2026.

Jeff Dean: Als je kijkt naar wat er tegenwoordig belangrijk is in AI-systemen, wil je dingen weten zoals de bandbreedte tussen het hoofdgeheugensysteem op je accelerator en het on-chip geheugen naar de vermenigvuldigingseenheid. Je wilt weten hoeveel energie het kost om één enkele vermenigvuldigingsoperatie uit te voeren. Wat is de interconnect-bandbreedte tussen chips, en hoeveel chips kun je met die bandbreedte met elkaar verbinden? En als je verder gaat dan dat domein: wat is de afname in netwerkbandbreedte wanneer je moet communiceren met 10.000 chips in plaats van 500? Ik denk dat dit stuk voor stuk ontzettend belangrijke getallen zijn om te kennen, en ze beïnvloeden sterk hoe je nadenkt over het oplossen van specifieke soorten problemen.

Diana Hu: Iets interessants dat ik je heb horen vertellen, is dat de eenheid waarin je tegenwoordig alles meet, energie is.

Jeff Dean: Ja.

Diana Hu: Je wees erop dat het uitvoeren van een berekening of som ongeveer 1 picojoule kost, maar dat het verplaatsen van de data en het doen van data-I/O duizend keer zoveel kost.

Jeff Dean: Ja. Alleen al het binnenhalen vanuit HBM op een accelerator naar de processor zodat deze er daadwerkelijk op kan rekenen.

Waarom AI in werkelijkheid een energieprobleem is

Diana Hu: Jazeker. Dat gat bepaalt stilletjes welke producten mogelijk zijn en hoe deze algoritmen in AI worden gebouwd. Wat voor soort problemen noemen oprichters voortdurend modelproblemen, terwijl het in feite energie- of data-I/O-problemen zijn?

Jeff Dean: Het voorbeeld dat je aanhaalde van een duizendvoudig verschil in het verplaatsen van data versus het daadwerkelijk berekenen ervan qua energie is een vrij ingrijpende, en het vormt vele aspecten van wat we doen binnen machine learning. Want als je dat duizendvoudige verschil niet had, dan zou je niet hoeft te batchen. Maar je moet wel batches maken van vele voorbeelden of vele tokens tegelijk om die databeweging te amortiseren, zodat je niet een duizendvoudige vertraging betaalt, maar de energiekosten deelt door de batchgrootte (1.000 gedeeld door de batchgrootte). Voor een heel lage latency is batching eigenlijk niet erg gunstig. Dit soort zaken en de energieachtergrond achter verschillende beslissingen in de computerhardware die we gebruiken, hebben echt grote invloed op veel beslissingen die we nemen bij het bouwen van systemen op een hoger niveau.

Diana Hu: Een heel concreet voorbeeld is hoe het trainen van modellen wordt aangepakt. Er is dat hele concept van het batchen van de datasets en het draaien van epochs (tijdperken/trainingsronden). Mensen verwarren dat wellicht soms als een modelprobleem, maar het is in werkelijkheid een systems-data-I/O-probleem, toch?

Jeff Dean: Ja. Je moet batches samenstellen om een betere efficiëntie in je hardware te krijgen. Idealiter zou je training met batchgrootte 1 kunnen doen, maar qua efficiëntie is dat minder goed. Dus gebruiken mensen tegenwoordig vrij grote batches.

Diana Hu: Je staat erom bekend dat je er een lange week of weekend tussenuit knijpt en op de proppen komt met een briljante oplossing. Bestaat er zoiets als dat Jeff eraan werkt gedurende een paar weken en training met batchgrootte 1 voor elkaar krijgt?

Jeff Dean: Ik ben eigenlijk meer over inferentie aan het nadenken. Inferentie is een behoorlijk interessant probleem omdat je wel degelijk een heel lage latency wilt hebben. Bij training heb je niet per se een ongelofelijk lage latency nodig. Ik denk dat er nog veel ruimte is om hardware meer te specialiseren voor inferentie dan we nu doen.

Diana Hu: Wat zijn enkele van die interessante dingen op het gebied van inferentie waar je heel erg over nadenkt?

Jeff Dean: Gewoon proberen de databeweging te minimaliseren, nadenken over operaties met een ongelofelijk lage precisie, en misschien niet heel veel verschillende soorten precisies ondersteunen. Als je het gevoel hebt dat je een goed antwoord hebt op wat voor soort precisie je nodig hebt, bouw dat dan misschien gewoon in de hardware in en niet veel meer dan dat.

Diana Hu: Wat neerkomt op een kernanalogie die ik hoorde van beroemde computerwetenschappers, namelijk dat het hele proces van AI in feite een groot compressieprobleem is. Om te zorgen dat de data met verlies (lossy) wordt gecomprimeerd en vervolgens weer hersteld, moet je het in feite begrijpen.

Jeff Dean: Als je de data echt begrijpt, moet je haar erg goed kunnen comprimeren.

Diana Hu: En nu is de transformer-architectuur in feite een van de manieren gebleken die heel goed werkt.

Jeff Dean: Ja, werkt tot nu toe erg goed. Goed werk van mijn collega's.

Context engineering is de volgende grens

Diana Hu: Zeker. Laten we nu een stukje uitzoomen. AI-vooruitgang betekende vroeger simpelweg betere modellen. Je had meer data, trainde modellen met grotere parameters. Maar in toenemende mate, in het afgelopen jaar of zo, draait het om alles *rondom* het model. Niet alleen de modelgrootte en het aantal parameters of meer data, het is alles eromheen zoals retrieval, tools, geheugen, agent-tools, en dat zou wel eens geconsolideerd kunnen worden in wat mensen context engineering noemen, toch?

Jeff Dean: Ja. Het model is in feite slechts één onderdeel van wat je probeert te doen, namelijk het bouwen van een algeheel systeem dat echt interessante problemen kan oplossen. Dat omvat een model dat weet hoe het verschillende tools moet gebruiken. Het weet misschien hoe het relevante informatie moet opvragen (retrieve), heeft mogelijk een geschiedenis van andere informatie die het heeft opgehaald voor eerdere problemen, en het kan informatie in de context van het model plaatsen. Het mooie daarvan is dat die informatie heel helder is voor het model, in tegenstelling tot de trainingsdata waarop het model is getraind – waar alles als het ware bestaat uit biljoenen tokens die door elkaar zijn geroerd in een soep van honderden miljarden of biljoenen parameters – maar dat is allemaal minder helder dan de daadwerkelijke context die het model direct ziet voor dit specifieke probleem of gebruiksscenario.

Jeff Dean: En dan het vermogen om te begrijpen welke tools er beschikbaar zijn, welke daarvan het model gaan helpen om deze volgende fase van het probleem op te lossen, hoe je een probleem kunt opbreken in een reeks tool-aanroepen, misschien meerdere benaderingen proberen om het probleem op te lossen en te zien welke werken en dat kunnen evalueren. Dit is de hele orchestratie van complexe agent- en multi-agent-systemen die naar mijn mening steeds belangrijker zal worden. Super spannende tijden, zou ik zeggen.

Diana Hu: Het leuke aan deze specifieke verzameling probleemdomeinen is eigenlijk iets wat iedereen in deze zaal kan doen. Vroeger had je voor het trainen van een model een ongelofelijke hoeveelheid middelen nodig, een ongelofelijke hoeveelheid toegang tot GPU's en data. Maar voor context engineering kan iedereen het. Je hebt enkel de API nodig van iets als Gemini en kunt vervolgens werken aan je eigen setup voor je eigen retrieval, je eigen tool-aanroepen, enzovoort. Wat zijn enkele tips voor iedereen hier? Hoe wordt iedereen beter in en uitzonderlijk goed in context engineering?

Jeff Dean: Een ontzettend goede manier om dat te doen is door deze modellen, frameworks (harnesses) en tools te gebruiken om te proberen problemen op te lossen, en dan kun je soms daadwerkelijk zien waar de modellen falen. Vaak kun je het model beter laten werken en succesvol laten zijn bij dat soort problemen door niet alleen de modelparameters aan te passen – wat lastig is vanuit de buitenkant –, maar door betere richtlijnen voor het model te creëren, vaardigheden (skills) voor het model te schrijven zodat het weet hoe het verschillende tools moet gebruiken die ongelofelijk nuttig zouden zijn voor het oplossen van deze specifieke klasse van problemen. Terwijl je dat doet, kom je terecht in dit soort zelfverbeterende setup die je probeert te gebruiken om dingen op te lossen. Dat is een ontzettend goede manier om beter te begrijpen welke extra informatie het model zou willen hebben om capabeler te worden.

De vaardigheid die AI beter maakte in optimalisatie

Diana Hu: Kun je een voorbeeld geven van wat context engineering die je persoonlijk hebt gedaan, vaardigheden die je hebt geschreven of tools die echt een enorm verschil maakten in je workflow?

Jeff Dean: Sanjay en ik waren een paar weken geleden aan het werk, en we doen vaak een zekere mate van prestatieverbetering voor heel laagniveau-bibliotheken (low-level libraries). We hebben een microbenchmark-bibliotheek geschreven bij Google waarin je microbenchmarks kunt schrijven over hoe lang verschillende soorten operaties duren of hoe lang het duurt om deze datastructuur te vullen. Soms worden die datastrucs gebruikt op miljoenen processen binnen Google, dus het is feitelijk heel belangrijk om te zorgen dat ze topprestaties leveren. Je kunt microbenchmarks schrijven, maar zonder een agent-gebaseerd systeem is wat je doorgaans doet: meten wat de huidige prestaties zijn op enkele benchmarks waar je om geeft, enkele wijzigingen aanbrengen om de prestaties te verbeteren, dan de benchmarks opnieuw draaien om te zien waar de dingen zijn verbeterd, een breder set aan benchmarks draaien en de cache-footprint van de boel meten.

Jeff Dean: We schreven een vaardigheid (skill) die het model in feite leerde hoe het de meeste van die dingen in verschillende reeksen moest doen, zodat het daadwerkelijk zelfverbeterende benchmarkmetingen kon uitvoeren, codewijzigingen kon aanbrengen, de prestatieverbetering kon meten en daar vervolgens iteratief op door kon gaan. Dat leek redelijk goed te werken voor sommige soorten problemen. Het komt er eigenlijk gewoon op neer dat we de aanpak die wij als mensen zouden gebruiken, overdragen aan het model in een vorm die het kon gebruiken.

Diana Hu: Wauw, dat klinkt erg indrukwekkend. Je zegt dus dat je deze vaardigheid hebt en als iemand daar toegang toe krijgt, kan diegene optimalisaties uitvoeren zoals Jeff Dean. Het lijkt erop dat de wereld hiervan smult en het voor iemand een oneindige hoeveelheid geld waard is om hier toegang toe te krijgen.

Jeff Dean: We hebben een paar maanden geleden feitelijk een document gepubliceerd genaamd "Performance Hints" dat Sanjay en ik hebben geschreven. Het is een document van zo'n 30 pagina's over allerlei soorten prestatietrucjes. Sommige mensen hebben dat genomen en in samengevat formaat aan verschillende modellen gegeven en gezien dat het model nu beter is geworden in het redeneren over prestatieproblemen in code.

Diana Hu: Je hoort het hier als eerste. Je kunt je eigen code daadwerkelijk optimaliseren zoals Jeff Dean als je dit paper pakt dat jullie hebben gepubliceerd, "Performance Hints".

Jeff Dean: Jazeker. Het is gratis beschikbaar, dus jullie zouden het allemaal moeten proberen.

Waarom langlopende agents falen

Diana Hu: Erg cool. Nu heb je het over agents. Iedereen hier is er waarschijnlijk eentje aan het bouwen of heeft er op enig moment een gebouwd. Ik weet zeker dat iedereen heeft gezien hoe hun agent op hol slaat bij stap 30 of 40. Agents zijn geweldig tot ongeveer stap 10 of zo, en beginnen dan te wankelen bij stap 50. Wat denk je dat de beperking is vandaag de dag? Zijn het context-evaluators, of simpelweg fouten die zich opstapelen omdat het in wezen een open-loop-systeem is?

Jeff Dean: Uiteraard willen we dat agents heel lang achter elkaar kunnen doorsturen omdat ze op die manier steeds ingewikkelder problemen gaan oplossen. Maar zoals je vandaag de dag opmerkt, stoppen ze soms met werken na 10 interacties met de tools. Soms komt dat doordat het model iets probeert te doen waar het niet heel veel ervaring mee heeft. Het is getraind op een hele reeks dingen, en zodra je een beetje buiten de distributie (out of distribution) raakt van dingen die het weet te doen, zal de prestatie – net als bij de meeste machine learning-modellen – beginnen te degraderen. Hoe verder je buiten de comfortzone komt van wat het weet te doen, hoe groter de kans dat het minder goed werkt.

Jeff Dean: Er zijn een aantal dingen die je kunt doen. Eén daarvan is om het model vaardigheden en hints te geven die het doorgaans op het beter verlichte pad houden van dingen die het wel weet te doen. Het inzetten van multi-agent-systemen waarbij je meerdere agents hebt die verschillende benaderingen proberen, en je misschien een ander model of een andere agent hebt die evalueert welke daarvan veelbelovend lijken, is een andere manier om de ruimte van mogelijke oplossingen te doorzoeken, vast te houden aan degene die het meest veelbelovend lijken en de dingen weg te gooien die niet bleken te werken of op hol sloegen. Dat is een heel nuttige algemene techniek: inferentie-tijd computerkracht inzetten om een zoektocht uit te voeren naar plausibele manieren om het probleem op te lossen, wat kan zorgen voor veel betere prestaties of een veel grotere betrouwbaarheid in langlopende agent-stromen.

Diana Hu: Wat zijn manieren waarop je deze specifieke workflow intern voor jullie agents hebt geïmplementeerd?

Jeff Dean: We hebben frameworks (harnesses), en daarnaast hebben we een hele set aan vaardigheden (skills), met name in de interne ontwikkelomgeving van Google. We hebben vaardigheden zodat de agents weten hoe ze veel van onze interne tools voor coðeren, code-reviews, het meten van prestaties of het ophalen van logbestanden moeten gebruiken. Dat zijn simpelweg vaardigheden die je kunt toevoegen om het basismodel bekwamer te maken, ook al is het niet per se getraind op de exacte manier waarop interne engineers bij Google logbestanden zouden ophalen uit ons propriëtaire systeem. Met het juiste type vaardigheidsdefinitie kun je het feitelijk aan de praat krijgen, en dat verhoogt de nuttigheid van de agents.

Waar startups Google nog steeds kunnen verslaan

Diana Hu: Laten we nu praten over waar startups kunnen winnen. Dit onderdeel vind ik persoonlijk erg belangrijk omdat iedereen in deze zaal moet bepalen wat ze in de toekomst gaan bouwen als je een toekomstige oprichter bent. Het punt met Google is dat jullie alles codesignen op het systeem, van de processors tot de producten. Welke lagen zijn dat die iemand als Google zal blijven bouwen, waarin we blijven accumuleren en beter worden, en waar kan een team van twee of drie personen nog steeds winnen?

Jeff Dean: Uiteraard proberen Google, onze Gemini-modellen en onze hardware-infrastructuur zeer algemene modellen te bouwen die bijna alles kunnen doen. Maar in een hele hoop gevallen betekent dat dat we niet veel aandacht hebben voor specifieke domeinen waar wellicht een heel goed ontworpen gebruikersinterface (surface), en misschien een model en set aan vaardigheden, of een gespecialiseerd model dat niet in de algemene mix zit van de dingen die onze modellen goed doen, feitelijk een significant voordeel kan opleveren. Je kunt iets bouwen dat verrukkelijk is, een heel hoge nauwkeurigheid heeft en een heel hoge kwaliteit voor een domein waar je echt gepassioneerd over bent. Dát is waar die twee of drie mensen in een kamer die dat bouwen een voordeel kunnen hebben.

Jeff Dean: Maar ik wil er ook voor waarschuwen dat de algemene modellen absoluut beter worden in een steeds breder scala aan dingen. Dus je moet achterhalen: is dat ding waar je aan werkt duurzaam, of denk je dat de vooroplopende modellen daar de komende 6 maanden of 12 maanden beter in worden, of is het iets dat ze pas over 2 of 3 jaar kunnen? Dat wil je afwegen wanneer je besluit waar je aan gaat werken.

Diana Hu: Aan de algemene modellen gaan jullie uiteraard doorwerken en die blijven verbeteren. Hoe moet het publiek beredeneren welke gebieden ze moeten kiezen en waarin ze moeten werken?

Jeff Dean: Het allerbelangrijkste is om iets te kiezen waar je super enthousiast over bent, dat je wilt bouwen en waarvan je denkt dat het nuttig zal zijn in de wereld. Als je dat doet, lig je al enorm voor op het moment dat je 's ochtends wakker wordt en denkt: "Hier heb ik eigenlijk niet zo'n zin in", of als je iets bouwt dat feitelijk niet zo nuttig is voor de wereld of voor veel mensen. Dat is het selectiecriterium nummer één dat ik probeer toe te passen voor welk probleem ik als volgende aan zou moeten werken.

Jeff Dean: Ten tweede denk ik dat je moet kijken naar wat de huidige, meer algemene modellen kunnen doen in dat probleemdomein. Je kunt ze testen: zijn ze in staat om dit heel goed te doen? Als ze falen op alle fronten, is dat waarschijnlijk een goed teken. Als ze het tot op zekere hoogte een beetje kunnen, maar niet erg goed, is dat misschien geen geweldig teken. Dat is waarschijnlijk een teken dat die capaciteit in die modellen begint te ontstaan, en met meer trainingsdata, modellen op grotere schaal, of wat dan ook, zal dat waarschijnlijk beter worden. Zoek naar iets waarbij het model 0% of 1% van de tijd slaagt, niet 20%.

Diana Hu: Hoe vind je die? Vallen dat soort dingen effectief buiten de distributie (out of distribution) van de trainingsset, en wat is precies de probleemvorm die daarbij past?

Jeff Dean: Soms is het een product dat je bouwt dat toegang kan hebben tot een specifiek soort data waar een algemeen model misschien geen toegang toe heeft. Het kan zijn dat je iets bouwt om gebruikers te helpen al hun eigen persoonlijke informatie te organiseren, en het algemene model heeft daar niet per se toegang toe. Daar kun je een enorm voordeel behalen doordat je product ineens zichtbaarheid heeft in belangrijke data.

Jeff Dean: Het kan een ongelofelijk moeilijk probleem zijn waarbij je, als je de juiste trainingsdata krijgt en een meer specifiek model kunt trainen dan een algemeen model, dat daadwerkelijk op een heel betaalbare manier kunt doen. Misschien kost het niet eens zoveel rekenkracht om een nichemodel te trainen voor dit specifieke probleem, maar kun je wel iets krijgen dat zeer nauwkeurig is. Dat kan soms een ontzettend goede bouwsteen zijn om een belangrijk probleem op te lossen dat misschien niet zo goed wordt afgehandeld door het algemene model.

Diana Hu: Er zijn in feite twee paden. Het eerste pad is een beetje grappig: jullie organiseren 's werelds informatie, dat is goed afgedekt, maar het organiseren van persoonlijke informatie ligt nog open. Het tweede pad: je had het over meer gespecialiseerde modellen in bepaalde domeinen. Kun je ons meer vertellen over wat sommige van deze domeinen zijn?

Jeff Dean: Als je kijkt naar het werk van mijn collega's aan AlphaFold, dat was een heel specifiek model voor eiwitvouwing (protein folding). Dat was enorm succesvol en kon dat domein daadwerkelijk heel goed aan, zodat je ineens de beschikking hebt over deze geweldige tool en dit model dat je op een heel effectieve manier antwoorden kan geven op vragen over eiwitten en hun structuur. Maar het is geen algemeen model; het is een heel specifiek model. Er zijn andere domeinen waar dat soort aanpak heel goed kan werken, misschien in de materiaalkunde of chipontwerp, waarmee je de capaciteiten van een heel nauwkeurig maar niche-model kunt inzetten om dingen te doen die vandaag de dag lastig zijn.

Hoe je een AI-native oprichter wordt

Diana Hu: Als sommigen van jullie een probleem vinden van een soortgelijke vorm als AlphaFold, zou dat een goed probleem kunnen zijn om aan te werken. Laten we nu aannemelijk maken dat je een probleem hebt gevonden om aan te werken. We gaan het even hebben over hoe je een AI-native oprichter wordt. In het verleden zei je dat het aansturen van een vloot van 50 of 100 agents volledig neerkomt op het schrijven van heel goede, heldere designdocs of specs. Hoe worden mensen daar goed in? Hoe zien die eruit?

Jeff Dean: Je zult veel meer succes hebben bij het werken met je virtuele agents als je helder kunt specificeren wat het is dat je wilt. Hoe duidelijker je bent over wat je wilt, hoe meer richtlijnen en een overzicht de agent heeft van wat hij probeert te bereiken. Terwijl als je niet veel specificeert, de agent moet afleiden wat je bedoelde. In veel gevallen leidt hij wellicht dingen af die anders zijn dan wat jij je inbeeldde. We hebben computerwetenschappers vanaf het allereerste begin altijd verteld dat het ontzettend belangrijk is om te specificeren wat de software die je schrijft probeert te bereiken voordat je deze gaat schrijven. Nu hebben we daadwerkelijk agent-gebaseerde systemen die het schrijven kunnen uitvoeren, maar het belang van het specificeren van wat je wilt is feitelijk alleen maar toegenomen. Vroeger droeg je het over aan een zeer intelligent mens die misschien context heeft of je opvolgende vragen kan stellen. Agents kunnen dat soms ook doen, maar heldere specificaties zijn een heel goed idee.

Jeff Dean: Om je een voorbeeld te geven van het gebruik van een coðerende agent dat buitengewoon goed werkt: je kunt de modellen van vandaag vragen om software heel effectief te vertalen van de ene computertaal naar de andere. In dat geval heb je feitelijk een ongelofelijk gedetailleerde specificatie: je hebt de complete software die beschrijft wat het systeem hoort te doen. Als je een Python-implementatie ergens van hebt en je wilt er een Go-implementatie van, dan is dat iets waar de modellen tegenwoordig ongelofelijk toe in staat lijken. Het kan alle tests die in Python staan pakken, de tests vertalen naar Go, controleren of ze slagen in de Go-versie, gedragsmatige verschillen tussen de implementaties vergelijken tot er geen meer over zijn, en uiterst effectief zijn omdat die specificatie zo helder is.

Diana Hu: Laten we er nu vanuit gaan dat elke oprichter goed wordt in het tegelijkertijd aansturen van honderden agents en dat alle code voor ze wordt geschreven door de agents. Wat wordt dan de schaarse vaardigheid?

Jeff Dean: Het hebben van een ongelofelijk goede smaak (taste) in wat je aan je agents vraagt om aan te werken. Dat is de kern van een onderzoekscommissie of onderzoeksprobleem vanuit mijn achtergrond. Een onderzoeker kan over alle tools en alle technieken beschikken, maar vaak is het leeuwendeel van de strijd aan welk probleem je je tijd gaat besteden. Als je het probleem goed kiest en je slaagt erin dat op te lossen, is dat vele malen beter dan wanneer je op een verrukkelijke manier een onderzoeksonderzoek uitvoert naar een nogal saai probleem. Die hoge mate van wijsheid over waaraan te werken is ongelofelijk belangrijk, en ik denk dat modellen daar niet per se heel goed in zullen zijn. Je krijgt mensen die een hoop AI-geassisteerde computerkracht sturen om geweldige dingen sneller tot stand te brengen. Die essentie van wat je wilt dat je modellen doen is het allerbelangrijkste punt waar je je op moet richten.

Diana Hu: Laten we het wat meer hebben over smaak, want daar wordt momenteel heel veel over gesproken in dit huidige tijdperk van agent-coding. Hoe kweek je smaak? Hoe maak je dat concreet?

Jeff Dean: Dat is een lastig iets. Het is niet zo dat er in een hele hoop gevallen een meetbare doelstelling van smaak is. Een deel ervan komt door ervaring. Door in het verleden aan een hoop verschillende problemen te werken, leer je wat voor soort problemen in de toekomst interessant zouden kunnen zijn, of wat voor soort dingen net nauwelijks mogelijk zouden zijn door eerdere benaderingen aan elkaar te knopen, en vervolgens aan welke openstaande problemen je zou moeten werken om tot iets magisch of enorm nuttigs te komen.

Jeff Dean: Een andere manier waarop je meer ervaring voor jezelf kunt opdoen, is door een stel dingen op te schrijven waarvan jij denkt dat ze de komende 12 maanden belangrijk zouden kunnen zijn. Misschien pik je er eentje uit om aan te werken, maar ga over 12 maanden eens terug en evalueer welke van die andere dingen feitelijk belangrijk bleken, welke daarvan andere mensen in de wereld daadwerkelijk zijn gaan bouwen, en welke ze nog niet leken te doen. Dat kan je een hoop meer voorbeelden opleveren voor je eigen smaakvormingscapaciteit. Dat is een belangrijk vermogen om te hebben.

Stel je grootste aannames ter discussie

Diana Hu: Een derde manier waar we het eerder over hadden, was het uitvoeren van hele gekke gedachte-experimenten.

Jeff Dean: Dat is een andere goede manier. Soms is het goed om dingen die de meeste mensen als een gegeven beschouwen, niet zomaar als een gegeven aan te nemen. Ik was laatst met sommige collega's een gek gedachte-experiment aan het doen. Al 60 jaar verricht de hele silicium-chipontwerp- en fabricage-industrie enorm werk om steeds kleinschaligere transistors te maken met een heel laag foutenpercentage. De aanname die we willen, is dat elke chip die we produceren van hetzelfde ontwerp identiek moet zijn aan elke andere chip. Je wilt niet dat er bits omvallen; er mogen geen bits flippen. Er zijn allerlei foutmarges ingebouwd, en geheugens hebben tegenwoordig ECC-geheugen.

Jeff Dean: Op macro-schaal maken we die aanname niet wanneer we grootschalige gedistribueerde systemen bouwen. We bouwen betrouwbare, grootschalige gedistribueerde bestandsystemen uit onbetrouwbare onderdelen. Individuele schijven kunnen stukgaan, maar je data moet veilig zijn. We hebben mechanismen op een hoger niveau om ons in staat te stellen om drie kopieën van de data op drie verschillende machines en drie verschillende racks te hebben, zodat als een rack-switch, individuele machine of schijf uitvalt, je nog steeds je data hebt. We hebben Reed-Solomon-coderingsstechnieken. Maar we lijken dat niet op een echt extreem niveau te doen op de schaal van het transistorniveau van de technologie waar we aan werken.

Jeff Dean: Een interessant gedachte-experiment is: wat zou er gebeuren als je zou proberen een systeem te bouwen van transistors die misschien 20 fouten per dag hebben in plaats van één per miljoen jaar? Dat zou een heel ander ontwerppunt zijn en zou je in staat kunnen stellen om echt interessante dingen te doen aan de fabricagekant. Je zou heel andere ontwerpmethodologieën hebben, want als je een signaal van hier naar daar wilt krijgen en je hebt deze super onbetrouwbare transistors, dan hanteer je misschien heel andere manieren om signalen door te geven. Je verstuurt het wellicht langs meerdere redundante paden om te zorgen dat het langs een van alle aankomt. Ik denk dat dat een behoorlijk interessante reeks gedachte-experimenten zou zijn. Ik zeg niet dat we dit per se moeten gaan doen, maar dat is het type zaak waarbij je af en toe aannames ter discussie wilt stellen. Vaak werken die gedachte-experimenten niet omdat er erg goede redenen zijn waarom we dit de afgelopen 50 jaar op deze manier hebben gedaan en niet op die andere manier, maar het is goed om dat zo nu en dan opnieuw te bekijken.

Diana Hu: Dat is echt wild. Het begint erg te rijmen met neuromorphic computing, of het menselijk brein en hoe de natuur werkt.

Jeff Dean: Signalen in ons brein zijn niet bepaald betrouwbaar in het verplaatsen van de ene plek naar de andere. In hersenen zijn er, wanneer er echt belangrijke dingen zijn die je van de ene plek naar de andere moet krijgen, meerdere paden die je in staat stellen om dat te doen.

Diana Hu: Wat is een van deze gekke aannames die jij uit het raam hebt gegooid die in het verleden daadwerkelijk een invloedrijk systeem heeft opgeleverd?

Jeff Dean: TPU's zijn een goed voorbeeld: het kunnen specialiseren van hardware voor een heel niche-achtig probleemdomein voordat dat probleemdomein zo belangrijk leek als het vandaag de dag is. Het ontstaan van MapReduce is een ander goed voorbeeld. Sanjay en ikzelf en een aantal andere collega's hadden aan verschillende iteraties van het crawl- en indexeringssysteem bij Google gewerkt. We hadden een hoop handmatig geparalleliseerde code geschreven met talloze checkpoints om te zorgen dat het robuust en betrouwbaar zou zijn als het draaide op 100 computers of 1.000 computers en sommigen daarvan uitvielen. Maar die code raakte doorgaans vermengd met het relatief eenvoudige ding dat je vaak probeerde te doen, zoals het bekijken van alle inhoud van alle webpagina's en het berekenen aan de zijkant van een mapping van URL naar in welke taal de pagina is geschreven. Het raakte volkomen verduisterd door al die andere code voor parallelisering en betrouwbaarheid.

Jeff Dean: We herinnerden ons onze training in functionele talen en realiseerden ons dat we met samengeknepen ogen naar die problemen konden kijken en deze MapReduce-abstractie boven de implementatie konden ontwikkelen. Onder de implementatie kon je al die checkpoint- en betrouwbaarheidsmechanismen in die laagniveau-bibliotheek stoppen waar alles vervolgens op kon bouwen. Dat werd een enorm succesvolle manier om op een robuuste en betrouwbare manier om te gaan met grootschalige berekeningen bij Google, vanuit dat gedachte-experiment van: als we er met samengeknepen ogen naar kijken, kunnen we dan een hoop problemen vinden die binnen deze abstractie passen?

AI die betere AI bouwt

Diana Hu: Je had het even over je huidige interesse in het werken aan aangepaste hardware. Op dit moment legt AlphaChip chips neer. Je hebt ook AlphaEvolve dat oplossingen aandraagt, ze evalueert en alle dingen behoudt die werken. Het lijkt erop dat je systemen begint te bouwen die kunnen cumuleren en AI bouwen die AI bouwt.

Jeff Dean: Meer in het algemeen is er dit fundament van de wetenschappelijke methode: je draagt een experiment aan, je implementeert wat je nodig hebt om het experiment uit te voeren, je evalueert het experiment en vervolgens haal je resultaten daaruit. Er zijn steeds meer problemen die nu geïmplementeerd kunnen worden waarbij die hele lus van niet zomaar een paar experimenten draaien, maar heel veel experimenten draaien – omdat je in staat bent om die lus te automatiseren en de latency van die lus extreem laag te maken – ontzettend belangrijk gaat worden. Het zal ons in staat stellen om een heleboel verschillende probleemdomeinen aan te pakken in de wetenschap en engineering, in het ontwerp van machine learning-modellen zelf, en in engineeringstaken zoals het ontwerpen van chips.

Jeff Dean: Als je die dingen daadwerkelijk op een geautomatiseerde manier kunt doen en een orchestratieframework hebt dat doelstellingen van een heel hoog niveau kan opbreken in subproblemen, kan elk van die subproblemen een van deze geautomatiseerde lussen laten draaien om de beste manier te onderzoeken om dat subprobleem op te lossen. Vervolgens kan het orchestratieframework oplossingen van subproblemen samenvoegen tot de algehele oplossing voor het probleem van een hoger niveau. Dat gaat de vooruitgang op het gebied van machine learning versnellen, de wetenschap versnellen en engineering versnellen. Dat wordt geweldig.

Diana Hu: Een hoop vakgebieden waar je heel goede evaluators kunt hebben, die nauw aansluiten bij dingen die formeel geverifieerd kunnen worden, zijn rijp voor AI-systemen die zichzelf kunnen verbeteren.

Jeff Dean: In een hoop gevallen moeten je evaluators een stuk sneller worden gemaakt. Als voorbeeld: mijn collega's deden zo'n tien jaar geleden wat werk op het gebied van kwantumchemie, waarbij je de eigenschappen van een bepaalde molecuul probeert te begrijpen. Je kunt een molecuulconfiguratie genereren en je wilt begrijpen welke eigenschappen het heeft. Je kunt een computationeel zeer intensieve *density functional theory*-simulator draaien, iets wat zomaar een nacht aan rekenkracht kan kosten om je het antwoord voor één ding te geven. Mijn collega's namen een boel output van die simulatieruns – de invoermolecuulconfiguratie en de outputs van de dure simulator – en gebruikten die om een neurale benadering van de simulator te trainen. In plaats van dat het een nacht kostte, maakten ze iets dat 300.000 keer sneller was en nagenoeg even nauwkeurig als het draaien van de volledige simulator.

Jeff Dean: Dat verandert fundamenteel hoe je wetenschap bedrijft. Als je 10 miljoen dingen moet screenen, kun je dat doen terwijl je gaat lunchen, in plaats van dat het een onderneming van 6 maanden is waarin je probeert voldoende rekenkracht bij elkaar te schrapen om al deze simulaties te draaien. Er is in tal van domeinen heel veel ruimte voor veel snellere validatiemodellen, mogelijk geleerde validatiemodellen die je een benadering van het ware antwoord veel sneller kunnen verschaffen. Dat verandert hoe over die experimentele lussen kan worden nagedacht en hoe snel je ze kunt doorlopen.

Diana Hu: Wat zijn enkele van de ruimtes en problemen waar je super enthousiast over bent dat deze versnelde wetenschappelijke methode die gaat oplossen of bereiken?

Jeff Dean: Machine learning zelf is er een van. Kunnen we een model hebben dat in staat is om zichzelf recursief te verbeteren door heel veel experimenten te draaien? Als je nadenkt over hoe modellen tegenwoordig binnen grote onderzoeksteams worden verbeterd, bedenken mensen ideeën, draaien ze een stel kleinschalige experimenten, kijken ze of die goed uitpakken, nemen ze de meest veelbelovende om op grotere schaal te proberen, evalueren ze dat en integreren ze de resultaten in een nieuw recept voor je model.

Jeff Dean: Er is geen echte belemmering om daar een veel meer geautomatiseerde lus van te maken waarin het model zelf besluit dat het gaat ontdekken, misschien met een duwtje in de rug van mensen op het hoogste niveau zoals: "Waarom probeer je niet wat nieuwe ideeën rondom modelarchitecturen die dit incorporeren?" Het gaat talloze experimenten draaien, kijken welke werken, en ze integreren in een veel hoger tempo. Effectief wil je je ontdekkingen per eenheid van ingevoerde rekenkracht optimaliseren.

Diana Hu: Terwijl iedereen in de zaal oprichter wordt of aan zijn carrière begint, zullen ze waarschijnlijk een hoop afwijzingen verzamelen. Dat is jou ook overkomen, Jeff. In 2014 schreven jij, Geoffrey Hinton en Oriol Vinyals een paper over distillatie (distillation), wat neerkomt op het nemen van een groot leraar-model om een veel kleiner en efficiënter model te trainen dat goedkoper is om mee te rekenen met minder parameters. Het is een truc geworden die iedereen in de industrie momenteel gebruikt, en dat paper werd afgewezen op NeurIPS.

Jeff Dean: Ik neem het de programmacommissie niet kwalijk. Heel vaak krijgt een paper drie beoordelingen, en keek een van de reviewers ernaar en zei dat het waarschijnlijk geen significante impact zou hebben. Toen we het paper schreven, zagen we dat dit een super belangrijk probleem was omdat we wisten dat het maken van goedkopere, zeer krachtige modellen op basis van modellen op grotere schaal iets was dat we wanhopig wilden doen om modellen aan meer mensen te serveren in domeinen zoals spraak of visie. Maar soms heeft de reviewer die ervaring niet omdat ze misschien niet nadenken over grootschalige AI-diensten en nadenken over de vraag of dit een fundamentele vooruitgang is. Het wordt zo nu en dan afgewezen, en dat is prima. We zetten het op arXiv, mensen lezen het, mensen gebruiken het, en het is allemaal goed. We gebruiken het wel degelijk bij het maken van onze Flash-modellen op basis van ons grotere Pro-model. Dat is deels de reden waarom onze Flash-modellen in Gemini zo capabel zijn ten opzichte van hun grootte en snelheid, en behoren tot de beste in de benchmark voor hun modelgroottecategorie.

Diana Hu: Zelfs als je wordt afgewezen, ga door.

Jeff Dean: Dat is de les die ik daaruit zou destilleren.

Bouw iets dat er echt toe doet

Diana Hu: Je kwam in 1999 bij Google als een startup met 20 man. Als je de 25-jarige Jeff Dean van toen zou kunnen teleporteren naar vandaag in dit tijdperk met jouw vaardigheden, wat zou je dan doen? Sluit je je aan bij een frontier lab, of start je een bedrijf?

Jeff Dean: Het is altijd moeilijk te zeggen, en het is een heel persoonlijke keuze over waar je je tijd aan wilt besteden. Voor mij zijn enkele van de belangrijkste vragen: ga je werken aan iets waar je echt om geeft, en als je daar vooruitgang in kunt boeken met collega's waar je graag mee werkt, gaat dat op de een of andere positieve manier een verschil maken in de wereld? Ga je die dienst kunnen aanbieden om biochemici, of programmeurs, of alle consumenten op internet te helpen? Waar je naar moet streven is impact hebben in de wereld die positief is, werken met mensen met wie je met plezier samenwerkt, hard werken en je best doen.

Jeff Dean: Wat betreft het aansluiten bij een frontier lab versus het starten van een bedrijf met twee of drie van je naaste vrienden: dat zijn verschillende ervaringen. In een grote, gevestigde organisatie heb je structuur, een hoop geweldige collega's die dingen weten die jij niet weet, heel veel interessante problemen om aan te werken, en een bestaand platform voor impact waar je werk van invloed is op talloze mensen in de wereld. Als zeer kleine startup moet je iets hebben waar je gepassioneerd over bent, en er is een hoop risico verbonden aan het aanpakken van dat probleem op een manier waarmee je kunt slagen en een onderneming kunt laten groeien. Maar dat kan ook ongelofelijk lonend zijn. Vraag jezelf op zijn minst, ongeacht welk pad je kiest, af: als ik aan dit probleem werk en de best mogelijke uitkomst vindt plaats, zal de wereld er dan op de een of andere manier een stuk beter aan toe zijn, of zal de wereld zeggen: "Ach, dat is wel geinig, maar het zal wel"? Dat is niet het soort zaak waar je je tijd aan moet besteden.

Diana Hu: Je bent een ongelofelijke mentor en manager geweest voor veel engineers en hebt enorme systemen gebouwd. Wat zijn enkele lessen voor iedereen hier over hoe je met slimme mensen werkt of slimme mensen vindt?

Jeff Dean: Je wilt altijd mensen vinden die werkelijk goede vaardigheden hebben op een bepaald gebied dat nodig is in een team dat je probeert te vormen, hetzij binnen een bedrijf, hetzij bij het starten van een bedrijf. Maar je wilt ook mensen vinden waar je met veel plezier mee omgaat, omdat je een hoop tijd gaat doorbrengen met mensen die aan heel moeilijke problemen werken. Je wilt mensen met een laag ego, teamspelers, en die complementaire vaardigheden hebben ten opzichte van jezelf.

Jeff Dean: Ik merk altijd dat werken in een klein team waar mensen dingen weten die ik niet weet, en waar ik misschien vaardigheden heb die andere mensen minder hebben, super leuk is. Je bouwt gezamenlijk iets dat geen van jullie individueel zou kunnen, maar in dat proces vergaar je feitelijk een hoop nieuwe kennis en vaardigheden voor jezelf, en zij ook. Beschouw je engineering- of onderzoekscarrière als het hebben van een geweldige gereedschapsriem vol technieken. Je wilt altijd nieuwe tools toevoegen aan die gereedschapsriem, want je weet nooit wanneer je tegen een probleem aanloopt waarbij je deze vier gespecialiseerde tools nodig hebt in plaats van deze drie. Het toevoegen van meer gereedschap maakt de kans groter dat de problemen die je in de toekomst tegenkomt door jou kunnen worden opgelost.

Diana Hu: Meerdere mensen in deze zaal gaan uiteindelijk iets bouwen dat net zo invloedrijk is als wat jij hebt gedaan met MapReduce, de TPU, distillatie, enzovoort. Aan welk probleem hoop je dat ze gaan werken?

Jeff Dean: De wereld is een heel grote plek en zit vol problemen. Ik ben met name enthousiast over nieuwe benaderingen van hardware, zoals veel efficiëntere inferentiehardware. Ik denk dat er radicaal verschillende soorten algoritmen voor machine learning bestaan die misschien veel data-efficiënter zijn dan de benaderingen die we vandaag de dag gebruiken. Als je nadenkt over onze grootschalige modellen van nu, dan zien die waarschijnlijk duizend keer zoveel data als een mens tegen de tijd dat die 18 is. Toch is de mens op zijn 18e beter in een hoop dingen en vergelijkbaar met frontier-modellen die veel meer data hebben gezien. Zou je met veel data-efficiëntere systemen kunnen komen die continu kunnen leren van hun eigen acties? Continueel leren is erg interessant. Multi-agent-interacties zijn iets interessants. Het creëren van manieren om een betere dialoog onder mensen in de wereld te hebben, het voeren van veel civilere gesprekken en het helpen van mensen om andere mensen over de hele wereld te ontmoeten die ze zouden moeten kennen op basis van hun interesses – dit zijn allemaal interessante dingen. Er zijn tal van coole dingen in de wereld, en we moeten er allemaal op uitgaan om nog coolere dingen te laten plaatsvinden.

Diana Hu: Dat klinkt prachtig. Hartelijk dank, Jeff Dean. Dat is alles voor vandaag.

Jeff Dean: Veel waardering voor. Dank jullie wel allen.