«Hvorfor skulle noen ønske et dummere svar?»
Det var motargumentet jeg fikk da jeg argumenterte for at noen ganger er det riktige svaret å tenke mindre.
Jeg jobber med AI-produkter som markedsføringsteam bruker i stor skala hver dag, noe som betyr at jeg føler problemer med latens og tokenkostnader før de fleste team i det hele tatt legger merke til dem. Vi hadde brukt måneder på å bygge en berikelsespipeline vi var genuint stolte av, og med god grunn. Da Opal hentet inn merkevareretningslinjer via RAG, søkte i kunnskapsbasen, lastet inn spesialiserte verktøy og konsulterte episodisk minne fra tidligere samtaler, var svarene målbart bedre.
Så hvorfor skulle noen hoppe over det?
Saken er at vi allerede tok smarte beslutninger om berikelse. Vi spredte oss ikke blindt utover hver kontekstkilde på hver forespørsel. Systemet sjekket om relevante kunnskapsbaser var tilgjengelige, om samtalestatusen berettiget visse søk, og hvilken modell brukeren hadde valgt. Berikelsespipelinen hadde betingelser. Den hadde tidlige avslutninger. Det var et prinsipielt system.
Men selv når disse kontrollene konkluderte med «nei, vi trenger ikke dette», brukte systemet fortsatt tid på å evaluere spørsmålet. Hver enkelt berikelsessjekk var rask; titalls millisekunder rask. Men i et system der total latens er summen av innebyggingsgenerering, kontekstinnhenting, promptmontering og modellinferens, forsterkes disse millisekundene.
For en bruker som venter på et enkelt faktasvar, er disse ekstra sekundene forskjellen mellom «dette føles umiddelbart» og «dette føles tregt».
Den samme ineffektiviteten viser seg i kostnader. Hvert unødvendig søk i kunnskapsbasen, hvert verktøysøk som ikke trenger å skje, hver prompt som rutes til en toppmodell når en lettere en ville være tilstrekkelig – disse utgiftene mangedobles over tusenvis av daglige samtaler. På bedriftsnivå blir den symbolske økonomien ved å bruke maksimal innsats uholdbar.
På tvers av dusinvis av kundesamtaler var mønsteret konsistent: brukere var villige til å ofre berikelseskvalitet for hastighet og kostnadseffektivitet når oppgaven er enkel. Ikke fordi de vil ha dårlige svar, men fordi et raskt og økonomisk svar på «oppsummer denne artikkelen» er det bedre svaret. Og selv om brukere elsker kontroll, ønsket de også at systemet skulle ta disse avgjørelsene automatisk, uten å måtte tenke på det hver gang.
Restauranten som kjører hver bestilling på samme måte
Se for deg en restaurant som kjører hver bestilling gjennom samme prosess, enten det er en femretters smaksmeny eller en side med pommes frites. Samme antall kokker, samme forberedelsestid, samme koreografi for anretning. Pommes fritesen ville vært flott. De ville også tatt 45 minutter.
Det var det vi gjorde. Hver prompt, uansett hvor enkel, gikk gjennom hele kjøkkenet.
Tre moduser, én rullegardinmeny
Vi landet på en trelags rutingsmodell:
Hurtigmodus hopper over kontekstberikelse helt. Billig applikasjonskontekst (som hvilken side du er på i produktet) flyter fortsatt gjennom, fordi den er trivielt rask å hente og ofte relevant. Men den dyre utbredelsen, RAG, minne, verktøyoppdagelse, alt hoppes over. Bare ledeteksten og modellen.
Beriket modus er den komplette opplevelsen. Merkevareretningslinjer, innholdshistorikk, verktøy, minne. Dette er hva du ønsker for kompleks innholdsproduksjon, kampanjeplanlegging eller alt som drar nytte av at Opal kjenner merkevarens stemme og unike kontekst.
Automodus er der det blir interessant. I stedet for å be brukeren bestemme seg, klassifiserer Opal hver ledetekst og velger riktig tilnærming automatisk. Enkelt spørsmål? Hopp over berikelsen, bruk en lettere modell, få svaret raskt tilbake. Kompleks kreativ oppgave? Hent inn alt, bruk den mest kapable modellen, ta deg tid til å få det riktig.
Med Auto-modus foretar vi en intelligent avveining mellom hastighet og kvalitet, på hver eneste melding, uten at brukeren trenger å tenke på det.
Møt Mycroft: En rutingshjerne på 25 millisekunder
For Auto-modus bygde vi en dedikert tjeneste med det interne kodenavnet Mycroft. Jobben dens er enkel: se på en ledetekst og bestem hva den trenger før noe annet skjer.
Hver ledetekst i Auto-modus sendes til Mycroft før berikelsesutbredelsen begynner. Mycroft kjører teksten gjennom en lett setningskoder for å generere en numerisk representasjon av ledetekstens betydning. Dette kodingstrinnet tar omtrent 10 millisekunder.
Kombinert med kontekstuelle signaler og klassifisering, fullføres hele rutingsbeslutningen på omtrent 25 millisekunder fra ende til ende.
Utover den semantiske innebyggingen, trekker Mycroft ut 20 tilleggsfunksjoner fra hver ledetekst: ting som ledetekstens lengde, linjetall, om den inneholder kodegjerder eller SQL-nøkkelord, om den kaller en agent, om den slutter med et spørsmålstegn, om den inneholder fraser som "forklar hvordan" eller "guide meg gjennom", og signaler som merkeidentitetstokener eller brukerpreferansenøkkelord. Disse lette regex-baserte funksjonene fanger opp struktur og intensjon som rene innebygginger kan gå glipp av, og de trekkes ut på bare noen få millisekunder.
Den kombinerte representasjonen – innebygging pluss 20 tilleggsfunksjoner – mates inn i fem klassifiseringshoder. Hver av dem er trent til å svare på et spesifikt rutingsspørsmål:
- Hopp over minne? Trenger denne ledeteksten brukerens samtalehistorikk, eller kan vi hoppe over oppslaget helt?
- Hopp over RAG? Trenger den et kunnskapsbasesøk, eller er dette selvstendig?
- Hopp over verktøy? Trenger den tilgang til spesialiserte verktøy, eller er dette en ren språkoppgave?
- Hvilken modellleverandør?Bør dette gå til Gemini eller Claude?
- Hvilket inferensnivå? Bør den bruke en lett-, mellomklasse- eller proffmodell?
For å gjenta: hele klassifiseringen kjører på omtrent 25 millisekunder. Når brukeren er ferdig med å lese sin egen ledetekst, har Mycroft allerede bestemt seg for hvordan den skal håndteres.
Den delen som betyr mest: Sikkerhetsnettet
Mycroft trenger minst 80 % sikkerhet for å hoppe over enhver berikelse, og minst 70 % sikkerhet for å overstyre brukerens standardmodellleverandør. Under disse tersklene faller den tilbake til full beriket modus.
Denne asymmetrien er forsettlig. En rutingsfeil som legger til unødvendig berikelse koster tokener og tid. En rutingsfeil som hopper over nødvendig berikelse koster kvalitet. Vi kalibrerte systemet til å være mer redd for den andre typen.
Det som overrasket oss
Det mest interessante funnet var atferdsmessig, ikke teknisk.
Alle våre betabrukere roste aktivt Auto-modus. De tenkte ikke på det som å få dårligere svar, de tenkte på det som å få svaret i riktig størrelse. Når du stiller et raskt spørsmål, er et raskt og effektivt svar det bedre svaret. Hastighet og kostnadseffektivitet er ikke avveininger mot kvalitet. For enkle ledetekster er de dimensjoner av kvalitet.
Dette omformulerte hvordan vi tenker på intelligens i AI-produkter. Instinktet i dette feltet er å alltid maksimere kapasiteten. Flere parametere, mer kontekst, mer resonnement. Men å matche innsatsnivået til oppgaven er ikke å "dumme ting ned". Det er et smartere system. Et system som alltid bruker maksimal innsats på alt er ikke grundig. Det kan bare ikke se forskjell på oppgaver.
Kostnadsimplikasjonene forsterkes også. På bedriftsnivå summerer hvert unødvendig søk i kunnskapsbasen, hver verktøyaktivering på en enkel ledetekst, hver toppmodell som krever et faktisk oppslag seg. Riktig størrelse på slutninger er ikke bare en bedre brukeropplevelse – det er en meningsfull kostnadsløfter.
To fordeler, én arkitektur
Dette arbeidet gir to sammensatte fordeler: hastighet og kostnad.
Hastighet er det brukerne føler direkte. Å hoppe over unødvendig berikelse og ruting til en lettere modell betyr raskere tid til første token på enkle ledetekster. Forskjellen merkes umiddelbart i samtaleflyten.
Kostnaden er det som skaleres bak kulissene. Hver hoppede RAG-forespørsel, hver ledetekst som rutes til en mellomnivåmodell i stedet for toppnivået, hvert verktøygjennomgang som ikke trengte å skje – disse besparelsene mangedobles over tusenvis av daglige samtaler.
De to forsterker hverandre. De samme rutevalgene som gir raskere svar, gjør dem også billigere. Vi trengte ikke å velge.
Før (hver ledetekst) | Etter (Auto-modus) | |
Berikelseskontroller | Alle evaluert | Bare det som trengs |
Modellnivå | Fest per forekomst | Tilpasset ledetekstkompleksitet |
Latens | Konstant (full pipeline) | Variabel (skalerer med oppgave) |
Tokenkostnad | Konstant (full berikelse) | Variabel (skalerer med oppgave) |
Hva vi bør se etter videre
Vi gleder oss til å fortsette å iterere i automatisk modus. Vi har bygget et dashbord for rutingskvalitet for å spore fremdrift. Vi ønsker avviksvarsler som flagger når modellens beslutninger endrer seg utenfor forventede områder. Og vi ønsker å gi brukersignaler (tommel ned, regenereringer) tilbake slik at korreksjoner forsterkes over tid.
Hvis du bygger AI-produkter og tenker på tokenomikk og rask ruting, vil jeg gjerne sammenligne notater. Dette er et av de problemene der det riktige svaret avhenger sterkt av brukerne dine og berikelsesoverflaten din, og jeg tror bransjen fortsatt jobber med strategien.