Inte alla frågor förtjänar en doktorsexamen: Hur vi byggde en promptrouter som vet när den ska tänka mindre

"Varför skulle någon vilja ha ett dummare svar?"

Det var motståndet jag fick när jag argumenterade för att ibland är rätt svar att tänka mindre.

Jag arbetar med AI-produkter som marknadsföringsteam använder i stor skala varje dag, vilket innebär att jag känner av problem med latens och tokenkostnad innan de flesta team ens märker dem. Vi hade ägnat månader åt att bygga en berikande pipeline som vi var genuint stolta över, och med goda skäl. När Opal hämtade varumärkesriktlinjer via RAG, sökte i kunskapsbasen, laddade specialverktyg och konsulterade episodiskt minne från tidigare konversationer, var svaren mätbart bättre.

Så varför skulle någon hoppa över det?

Saken är den att vi redan fattade smarta beslut om berikande. Vi spred inte blint ut oss över varje kontextkälla vid varje begäran. Systemet kontrollerade om relevanta kunskapsbaser fanns tillgängliga, om konversationens tillstånd motiverade vissa sökningar och vilken modell användaren hade valt. Berikningspipelinen hade villkor. Den hade tidiga utgångar. Det var ett principbaserat system.

Men även när dessa kontroller kom fram till "nej, vi behöver inte detta", lade systemet fortfarande ner tid på att utvärdera frågan. Varje enskild anrikningskontroll var snabb; tiotals millisekunder snabb. Men i ett system där total latens är summan av inbäddningsgenerering, kontexthämtning, promptmontering och modellinferens, summeras dessa millisekunder.

För en användare som väntar på ett enkelt faktasvar är dessa extra sekunder skillnaden mellan "detta känns omedelbart" och "detta känns trögt".

Samma ineffektivitet visar sig i kostnaden. Varje onödig kunskapsbassökning, varje verktygsupptäckt som inte behöver ske, varje prompt som dirigeras till en toppmodell när en lättare skulle räcka – dessa kostnader mångdubblas över tusentals dagliga konversationer. På företagsnivå blir den symboliska ekonomin med att använda maximal ansträngning ohållbar.

Över dussintals kundkonversationer var mönstret konsekvent: användare var villiga att offra anrikningskvalitet för hastighet och kostnadseffektivitet när uppgiften är enkel. Inte för att de vill ha dåliga svar, utan för att ett snabbt och ekonomiskt svar på "sammanfatta den här artikeln" är det bättre svaret. Och även om användare älskar kontroll, ville de också att systemet skulle fatta dessa beslut automatiskt, utan att behöva tänka på det varje gång.

Restaurangen som hanterar varje beställning på samma sätt

Tänk dig en restaurang som hanterar varje beställning genom samma process, oavsett om det är en femrätters avsmakningsmeny eller en portion pommes frites. Samma antal kockar, samma förberedelsetid, samma koreografi för tallriken. Pommes fritesen skulle vara fantastiska. De skulle också ta 45 minuter.

Det var vad vi gjorde. Varje prompt, oavsett hur enkel, gick genom hela köket.

Tre lägen, en rullgardinsmeny

Vi landade på en trenivås routingmodell:

1. Snabbläget hoppar helt över kontextberikning. Billig applikationskontext (som vilken sida du är på i produkten) flödar fortfarande igenom, eftersom den är trivialt snabb att hämta och ofta relevant. Men den dyra utbyggnaden, RAG, minne, verktygsupptäckt, allt hoppas över. Bara prompten och modellen.

2. Berikat läge är den fullständiga upplevelsen. Varumärkesriktlinjer, innehållshistorik, verktyg, minne. Det här är vad du vill ha för komplex innehållsskapande, kampanjplanering eller allt som drar nytta av att Opal känner till ditt varumärkes röst och unika kontext.

3. Autoläge är där det blir intressant. Istället för att be användaren bestämma sig klassificerar Opal varje prompt och väljer rätt tillvägagångssätt automatiskt. Enkel fråga? Hoppa över berikningen, använd en lättare modell, få tillbaka svaret snabbt. Komplex kreativ uppgift? Hämta allt, använd den mest kapabla modellen, ta dig tid att göra det rätt.

Med Auto-läget gör vi en intelligent avvägning mellan hastighet och kvalitet, på varje enskilt meddelande, utan att användaren någonsin behöver tänka på det.

Möt Mycroft: En routinghjärna på 25 millisekunder

För Auto-läget byggde vi en dedikerad tjänst med det interna kodnamnet Mycroft. Dess uppgift är enkel: titta på en prompt och bestäm vad den behöver innan något annat händer.

Varje prompt i Auto-läget skickas till Mycroft innan berikningsutbyggnaden börjar. Mycroft kör texten genom en lätt meningskodare för att generera en numerisk representation av promptens betydelse. Det kodningssteget tar cirka 10 millisekunder.

Kombinerat med kontextuella signaler och klassificering slutförs hela routingbeslutet på cirka 25 millisekunder från början till slut.

Utöver den semantiska inbäddningen extraherar Mycroft 20 hjälpfunktioner från varje prompt: saker som promptlängd, radantal, om den innehåller kodgränser eller SQL-nyckelord, om den anropar en agent, om den slutar med ett frågetecken, om den innehåller fraser som "förklara hur" eller "guida mig igenom", och signaler som varumärkesidentitetstokens eller användarpreferensnyckelord. Dessa lättviktiga regex-baserade funktioner fångar struktur och avsikt som rena inbäddningar kan missa, och de extraheras på bara några millisekunder.

Den kombinerade representationen – inbäddning plus 20 hjälpfunktioner – matas in i fem klassificeringshuvuden. Var och en är tränad att svara på en specifik routingfråga:

• Hoppa över minne? Behöver den här prompten användarens konversationshistorik, eller kan vi hoppa över sökningen helt?
• Hoppa över RAG? Behöver den en kunskapsbassökning, eller är detta fristående?
• Hoppa över verktyg? Behöver den tillgång till specialiserade verktyg, eller är detta en ren språkuppgift?
• Vilken modellleverantör?Bör detta gå till Gemini eller Claude?
• Vilken inferensnivå? Bör den använda en lätt-, mellan- eller proffsmodell?

För att upprepa: hela klassificeringen körs på cirka 25 millisekunder. När användaren är klar med att läsa sin egen prompt har Mycroft redan bestämt hur den ska hanteras.

Den delen som är viktigast: Skyddsnätet

Mycroft behöver minst 80 % konfidens för att hoppa över någon berikning och minst 70 % konfidens för att åsidosätta användarens standardmodellleverantör. Under dessa trösklar faller den tillbaka till det fullständigt berikade läget.

Denna asymmetri är avsiktlig. Ett routingmisstag som lägger till onödig berikning kostar tokens och tid. Ett routingmisstag som hoppar över nödvändig berikning kostar kvalitet. Vi kalibrerade systemet för att vara mer rädd för den andra typen.

Vad som förvånade oss

Det mest intressanta fyndet var beteendemässigt, inte tekniskt.

Alla våra betaanvändare berömde aktivt autoläget. De tänkte inte på det som att få sämre svar, de tänkte på det som att få rätt storlek på svaret. När du ställer en snabb fråga är ett snabbt och effektivt svar det bättre svaret. Hastighet och kostnadseffektivitet är inte avvägningar mot kvalitet. För enkla uppmaningar är de dimensioner av kvalitet.

Detta omformulerade hur vi tänker kring intelligens i AI-produkter. Instinkten i detta område är att alltid maximera kapaciteten. Fler parametrar, mer sammanhang, mer resonemang. Men att matcha ansträngningsnivån till uppgiften är inte att "förenkla saker". Det är ett smartare system. Ett system som alltid använder maximal ansträngning på allt är inte grundligt. Det kan helt enkelt inte se skillnad mellan uppgifter.

Kostnadsimplikationerna ökar också. På företagsnivå läggs varje onödig kunskapsbassökning, varje verktygsanrop på en enkel uppmaning, varje toppmodell som kräver en faktauppslagning ihop. Rätt storlek på inferens är inte bara en bättre användarupplevelse – det är en meningsfull kostnadshävstång.

Två fördelar, en arkitektur

Detta arbete ger två sammansatta fördelar: hastighet och kostnad.

Hastighet är vad användarna känner direkt. Att hoppa över onödig berikning och routing till en lättare modell innebär snabbare tid till första token på enkla uppmaningar. Skillnaden märks omedelbart i konversationsflödet.

Kostnaden är det som skalas upp bakom kulisserna. Varje hoppad RAG-fråga, varje prompt som dirigeras till en mellannivåmodell istället för toppnivån, varje verktygsupptäckt som inte behövde ske, dessa besparingar mångdubblas över tusentals dagliga konversationer.

De två förstärker varandra. Samma routingbeslut som gör svar snabbare gör dem också billigare. Vi behövde inte välja.

Vad vi ska se upp för härnäst

Vi är glada att fortsätta iterera i Auto-läge. Vi har byggt en instrumentpanel för routingkvalitet för att spåra framsteg. Vi vill ha avvikelsevarningar som flaggar när modellens beslut avviker utanför förväntade intervall. Och vi vill mata tillbaka användarsignaler (tummen ner, regenereringar) så att korrigeringar ackumuleras över tid.

Om du bygger AI-produkter och funderar på tokenomics och snabb routing, skulle jag gärna jämföra anteckningar. Detta är ett av de problem där rätt svar beror starkt på dina användare och din anrikningsyta, och jag tror att branschen fortfarande arbetar med att utarbeta spelboken.