När Demis Hassabis beskriver Gemini Flash beskriver han egentligen inte en liten modell. Han beskriver ett rörmokeriproblem.
Google har AI som löper genom Sök, AI Overviews, AI Mode, Maps, YouTube, Gemini-appen och mer än ett dussin produkter med användarantal som de flesta företag aldrig ser. Varje svar kostar pengar. Varje fördröjning syns. Varje extra sekund multipliceras över produkter som används av miljarder.
Så när Hassabis säger att systemen måste levereras "extremt snabbt, extremt effektivt och billigt och med låg fördröjning" är nyckelordet inte snabbt. Nyckelordet är levereras.
En modell i Googles händer är inte bara en intelligensmotor. Det är något som måste få plats inne i ett globalt system utan att blockera flödet.
Destillering är försöket att bära över beteende från en större, starkare modell till en mindre som är billigare och snabbare att köra. Hassabis beskriver den komprimeringen in i Flash- och Flash Lite-modellerna som en av Googles styrkor.
Intervjuaren ramar in avvägningen som ungefär 95 procent av förmågan till en tiondel av priset. Hassabis bekräftar inte de exakta siffrorna, men han godtar formen på argumentet: en del förmåga kan bytas mot lägre kostnad, lägre fördröjning och snabbare iteration.
För Google kan den bytesaffären vara rimlig även när den snabbare modellen ger upp en del förmåga på vissa uppgifter. Om systemet är tillräckligt bra för att levereras över enorma produkter förstärks vinsterna. En något svagare modell som kan placeras överallt kan skapa mer produktvärde än en starkare modell som är för långsam eller för dyr att pressa genom rören.
Det är god ingenjörskonst. Det är inte bevis för att samma modell är rätt för ditt svåraste arbetsflöde.
Problemet med "95 procent lika kapabel" är att det är ett samlat påstående. Det talar inte om var den saknade förmågan dyker upp. Den kan försvinna på ställen du inte bryr dig om. Den kan dyka upp i ett hörn av uppgiften som betyder mycket. Siffran ensam svarar inte på den frågan.
Ett supportverktyg är ett enkelt exempel. En Flash-modell kan sammanfatta vanliga ärenden bra, dirigera de flesta förfrågningar rätt och hålla kön i rörelse. Det är nyttigt. Men om din verksamhet hänger på att fånga det ovanliga ärendet där kunden beskriver det verkliga felet i en vag mening, är genomsnittspoängen inte det du ska lita på. Frågan är om modellen fångar det fallet tillräckligt ofta.
Det här handlar inte om att hastighet orsakar hallucinationer. Det är för enkelt, och samtalet med Hassabis fastställer inte det. Den poäng som stöds är smalare: Google balanserar förmåga mot kostnad, fördröjning och skala. Flash är formad av den balansen.
Den som bygger måste ställa en annan fråga. Inte "är den här modellen smart nog i allmänhet?" Inte "är den snabb?" Inte "såg demon ren ut?" Frågan är var modellen fallerar under den arbetsbörda som betyder något.
Det betyder att testa de fall där det kostar något att ha fel. Använd de verkliga gränsfallen. Använd de stökiga indata. Använd exemplen som orsakade återbetalningar, supporteskaleringar eller arga Slack-trådar förra kvartalet. Jämför den mindre modellen mot den starkare på de fallen, inte på den lätta trafiken där allt ser bra ut.
Klarar den sig där, använd den. Snabbt och billigt är inga små dygder. Men låna inte Googles optimeringsmål utan att kontrollera om det stämmer med ditt.
Modellen som löser Googles skalproblem löser kanske inte ditt kvalitetsproblem.