Smartare frågerouting för AI SQL-assistenter: Hur man skär ner kostnader utan att offra kvalitet

Tänk dig att din SQL-assistent är en raket som skjuter genom komplexa frågor. Sedan inser du att du använder raketbränsle för att hämta en inköpslista.

Det är spännande tills bränsleräkningen kommer. Plötsligt blir det tydligt att enkla ärenden inte behöver en raket. Samma sak händer när varje SQL-förfrågan, från en grundläggande sökning till en analys av flera scheman, skickas till samma kraftfulla AI-modell.

Processen för att få en AI SQL-assistent är vanligtvis densamma. Till en början ökar produktiviteten: frågor görs snabbare, standardkod försvinner och utvecklare tillbringar mindre tid med att skriva rutinmässiga SQL-frågor. När fler team använder det ökar antalet frågor. När infrastrukturräkningen kommer förändras ekonomin.

Problemet är med byggnaden. Det kostar mycket att köra Frontier AI-modeller som kan tänka på exekveringsplaner, scheman och komplex frågelogik. Den priset är rimlig för svåra uppgifter, eftersom det kostar cirka 0,03 dollar per fråga. När de används för enkla SELECT-uttryck och CRUD-åtgärder blir det slöseri i stor skala.

Men svaret är inte att sänka modellen. Det är att skicka frågorna till rätt plats. Smart frågerouting sorterar varje förfrågan efter hur svår den är och skickar den till rätt modellnivå. Den här metoden kan minska inferenskostnaderna med 40–70% i SQL-arbetsbelastningar utan att sänka kvaliteten på utdata.

Den här artikeln förklarar hur den arkitekturen fungerar: att definiera SQL-komplexitetsnivåer, bygga klassificerings- och routningspipeliner och mäta de faktiska kostnads-kvalitetsavvägningarna när systemet är igång. Dessa mönster återspeglar lärdomar som gjorts under utvecklingen av schema-medvetna AI-funktioner i dbForge AI Assistant.

Varför en modell inte passar alla SQL-uppgifter

Inte alla SQL-frågor är desamma när det gäller komplexitet. En fråga som hämtar en användare med primärnyckel och en som bygger om sessionskanaler över flera scheman med fönsterfunktioner är båda SQL, men resonemanget som behövs för att generera dem är mycket olika.

Om ett system behandlar dem på samma sätt är resultatet förutsägbart: slösad beräkning. I de flesta företagsarbetsbelastningar är de flesta frågorna rutinmässiga. Enkla sökningar, enkel-tabellläsningar, grundläggande infogningar, syntaxkorrigeringar. Inget komplicerat. Att skicka alla dessa till en frontier-modell är som att använda en godsvagn för att bära en anteckningsbok.

Ett sätt att tänka på problemet är att dela in frågorna i komplexitetsnivåer:

Kostnadsgapet mellan nivåerna är stort. En Nivå 1-fråga kan kosta runt 0,001 dollar på en lätt modell. Samma fråga skickad till en frontier-modell kostar närmare 0,03 dollar. Vid 10 000 frågor per dag är det 10 dollar mot 300 dollar i daglig utgift. En 30-gånger skillnad, bara från routningsbeslut.

Schemamedvetenhet spelar också roll här. Nivå 3-frågor behöver inte bara mer beräkning. De behöver sammanhang: tabellrelationer, främmande nycklar, index, databasspecifik syntax. Det sammanhanget måste injiceras under inferens.

Att köra en enkel Nivå 1-fråga genom samma tunga väg slösar tokens, lägger till latency och förbättrar inte resultatet.

En praktisk arkitektur för modellval

Ett routningssystem har vanligtvis fyra faser: klassificera, routa, exekvera och validera. Varje fas har ett annat jobb, och var och en kan misslyckas på olika sätt. Det hjälper att tänka på dem separat innan man sätter ihop hela pipelinen.

Klassificeringen är det viktigaste steget. Klassificeraren tar emot antingen den råa SQL-frågan eller den naturliga språkprompten som kommer att generera en och tilldelar den till en komplexitetsnivå. Det finns tre vanliga sätt att bygga den här klassificeraren.

Regelbaserad klassificering förlitar sig på regex-mönster och AST (abstrakt syntaxträd) parsing för att upptäcka strukturella signaler: saker som tabellräkning, nivådjup, fönsterfunktioner, underfrågor eller aggregeringsoperatorer. Det här tillvägagångssättet är snabbt och förutsägbart, med nästan ingen överhuvudtagen. 

Lätta klassificeringsmodeller använder en liten språkmodell som tränats för att uppskatta SQL-komplexitet. Det här lägger till ett extra steg, men det är ett av de högsta ROI-besluten i hela pipelinen. En klassificeringsanrop kan kosta runt 0,0001 dollar, vilket lätt rättfärdigar att undvika en 0,03 dollar frontier-modellanrop. 

I många konfigurationer kan dessa lätta modeller också köras lokalt, vilket effektivt tar bort kostnaden för enkla användarfrågor helt. De kan också klassificera naturliga språkprompter innan SQL genereras, vilket är användbart i assistentarbetsflöden där frågan inte finns ännu. 

Hybridklassificering kombinerar båda tillvägagångssätten. Regelbaserad logik hanterar tydliga fall vid nollkostnad, medan klassificeraren hanterar det tvetydiga mittsegmentet: frågor som ser måttliga ut men kan kräva schema-medvetet resonemang för att genereras korrekt. 

Routning sker efter klassificering. Men nivån ensam är inte den enda faktorn. Några andra saker påverkar var en fråga ska skickas. Dessa inkluderar:  

1. Schemakontextkrav. Vissa frågor behöver att modellen förstår främmande nycklar, index eller andra strukturella detaljer. Dessa frågor bär mer sammanhang och behöver vanligtvis skickas till en högre kapacitetsmodell. 
2. Latensolerans. Användarorienterade funktioner som autocomplete eller inline-förslag har stränga latensbudgetar. Bakgrundsaktiviteter har vanligtvis inte det. I dessa fall kan en långsammare men mer kapabel modell vara acceptabel. 
3. Förtroendetrösklar. Ibland är klassificeraren inte säker på nivån. I dessa fall är routning upp vanligtvis det säkrare alternativet. En felaktig nedgradering kan producera en dålig fråga och utlösa omfrågningar, vilket ofta kostar mer än att använda den starkare modellen från början. 

Valideringslagret körs efter att koden har körts. Uppgiften är att catcha routningsmisstag innan de når användaren. Efter exekvering görs kontroller för att säkerställa att syntaxen är korrekt, att resultaten är rimliga (återvände frågan rätt radform?) och att schemat är konsekvent. När ett resultat misslyckas med validering flyttar systemet upp en nivå och kör frågan igen.

På Devart var det viktigaste för att få dbForge AI Assistants routningsnoggrannhet rätt att bygga schema-medveten kontext in i klassificeringsbeslutet. Utan schema-kontext klassificerades frågor som använde oklara tabellnamn eller förlitade sig på implicita relationer alltid fel och skickades till billigare modeller som inte kunde hantera dem. Lösningen var att ge klassificeraren inte bara frågestrukturen utan också någon schemametadata.

Att mäta vad som betyder något: kostnads-kvalitetsavvägningar i praktiken

Affärsfallet för routning gäller endast om kvaliteten hålls. Kostnadsminskning som orsakar försämrad utdata, ökade omfrågningar eller utvecklartillit är inte en besparing, det är en överföring av kostnad från infrastrukturräkningen till utvecklingstid. Tre mått bestämmer om ett routningssystem faktiskt fungerar.

Kostnad per fråga per nivå etablerar baslinjen. Spåra den faktiska utgiften på varje nivå separat, inte som en blandad genomsnitt. Blandning döljer om routningen fungerar, ett system som routar 50% av frågorna till fel nivå kommer fortfarande att visa en lägre genomsnittskostnad, medan det tyst producerar sämre resultat. 

Kvalitetsscoren kontrollerar korrekthet, fullständighet och följsamhet till SQL-bästa praxis. Eskalationsfrekvensen är den mest direkta signalen. Den visar hur ofta en Nivå 1- eller Nivå 2-modell producerar utdata som inte klarar validering och behöver skickas till en annan plats. Ett väljusterat system bör hålla eskalation under 5%. Klassificeraren behöver omtränas ovanför den nivån. Den kan missförstå strukturella signaler eller så kan den inte ha den schema-kontext den behöver för att skilja på måttlig och komplex. 

Latenspåverkan tittar på hur lång tid det tar för ett svar att flytta från en nivå till en annan, inklusive eventuell extra tid som behövs för klassificering. Användare bör bara märka en 50 till 100 millisekunders fördröjning i interaktioner som går genom routningslagret. Om klassificeringen i sig blir ett problem löser hybridtillvägagångssättet (regler för tydliga fall, klassificerare endast för oklara) det utan att förlora noggrannhet. 

I verkligheten kan ett väljusterat routningssystem minska inferenskostnaderna med 40–60%, hålla eskalation under 5% och hålla utdatakvalitet hög för komplexa frågor. För att spara 70% eller mer måste man vanligtvis göra Nivå 1-uppgifter på egen hand med mindre modeller. Det kan fungera, men det gör också saker mer komplicerade, vilket inte alla team vill hantera.

“Eskalationsskatten” är en annan sak som måste undersökas. Om routning är för hård på billigare modeller kan systemet behöva göra mer arbete totalt: klassificeringsanrop, initial modellanrop, misslyckad validering, omroutning och ett andra modellanrop. I vissa fall kostar det mer än att skicka frågan till frontier-modellen från början.

Att bara titta på kostnad per anrop missar den här effekten. Eskalationsfrekvensen måste spåras bredvid det.

Strategiska slutsatser för utvecklingsteam

Smart routning är inte bara en bra sak att ha för mogna AI SQL-distributioner; det är ett måste för långsiktiga. Team som hoppar över det byter ut ett budgetproblem som inte kan lösas mot ett arkitekturproblem som kan lösas. Mönstren finns där; det enda som återstår är att bestämma vilka som ska följas först.

Börja med klassificeraren, inte modellerna. Routningslagret bestämmer om allt annat fungerar. En väljusterad hybridklassificerare kommer att ge dig de flesta av kostnadsbesparingarna utan att göra det för komplicerat.

Använd schemakontexten i feeden för att hjälpa dig fatta klassificeringsbeslut. För SQL-arbetsbelastningar som involverar relationer mellan flera tabeller eller resonemang som är specifikt för ett schema räcker frågestrukturen ensam inte. Delvis schemametadata vid klassificeringstid ökar avsevärt nivå noggrannhet.

Använd eskalationsfrekvensen som den primära kvalitetssignalen. Den hittar missklassificering snabbare än någon annan mått och visar exakt var klassificeraren behöver förbättras.

Innan klassificeraren planerar valideringslagret. Att veta vad misslyckande ser ut som och vad som orsakar en eskalation gör routningslogiken renare och systemet bättre på att hantera kanter.

Värdet av routningslagret ökar, inte minskar, när öppen källkodsmodeller blir bättre och kostnaden för lokal inferens går ner. Billigare Nivå 1-modeller gör kostnadsdifferensen mellan nivåer större, vilket gör korrekt klassificering mer värdefull. Routningsarkitekturen som byggs idag kommer att vara användbar under lång tid, inte bara som en snabb lösning.