Slimme query-routing voor AI SQL-assistenten: hoe kosten te verlagen zonder kwaliteit te offeren

Stel je voor dat je SQL-assistent een raket is die door complexe queries heen schiet. Dan realiseer je je op een dag dat je raketbrandstof gebruikt om een boodschappenlijst op te halen.

Het is spannend, totdat de brandstofrekening arriveert. Dan wordt het plotseling duidelijk dat eenvoudige boodschappen geen raket nodig hebben. Hetzelfde gebeurt wanneer elke SQL-aanvraag, van een basislookup tot een multischema-analyse, naar hetzelfde krachtige AI-model wordt doorgestuurd.

Het proces van het verkrijgen van een AI SQL-assistent is meestal hetzelfde. Aanvankelijk neemt de productiviteit toe: queries worden sneller gemaakt, boilerplate-code verdwijnt en ontwikkelaars besteden minder tijd aan het schrijven van routine-SQL-queries. Als meer teams het gebruiken, neemt het aantal queries toe. Wanneer de infrastructuurrekening arriveert, verandert de economie.

Het probleem ligt bij de bouw. Het kost veel om Frontier AI-modellen uit te voeren die over uitvoeringsplannen, schemas en complexe querylogica kunnen nadenken. Die prijs is gerechtvaardigd voor moeilijke taken, aangezien het ongeveer $0,03 per query kost. Wanneer het wordt gebruikt voor eenvoudige SELECT-instructies en CRUD-bewerkingen, wordt het verspilling op grote schaal.

Maar het antwoord is niet om het model te verlagen. Het is het doorsturen van queries naar de juiste plaats. Slimme query-routing sorteert elke aanvraag op moeilijkheidsgraad en stuurt deze naar het juiste modelniveau. Deze methode kan de inferentiekosten met 40-70% verlagen in SQL-werklasten zonder de kwaliteit van de output te verlagen.

Dit artikel legt uit hoe die architectuur werkt: het definiëren van SQL-complexiteitstiers, het opbouwen van classificatie- en routeringspijpen en het meten van de echte kost-kwaliteitstrade-offs zodra het systeem draait. Deze patronen weerspiegelen de lessen die zijn geleerd bij het ontwikkelen van schema-gevoelige AI-mogelijkheden in dbForge AI Assistant.

Waarom één model niet alle SQL-taken past

Niet alle SQL-queries zijn hetzelfde qua complexiteit. Een query die een gebruiker ophaalt op basis van de primaire sleutel en een query die sessiefuncties opnieuw opbouwt over meerdere schemas met window-functies, zijn beide SQL, maar de redenering die nodig is om ze te genereren, is heel verschillend.

Als een systeem ze hetzelfde behandelt, is het resultaat voorspelbaar: verspilde rekenkracht. In de meeste enterprise-werklasten zijn de meeste queries routine. Eenvoudige lookups, single-table reads, basisinvoegingen, syntaxisfixes. Niets ingewikkelds. Het doorsturen van al deze naar een frontier-model is als het gebruiken van een freight elevator om een notitieboekje te dragen.

Een manier om over het probleem na te denken is door queries te splitsen in complexiteitstiers:

De kostengap tussen de tiers is groot. Een Tier 1-query kan ongeveer $0,001 op een lichtgewichtmodel kosten. Dezelfde query die naar een frontier-model wordt doorgestuurd, kost dichter bij $0,03. Bij 10.000 queries per dag is dat $10 versus $300 in dagelijkse uitgaven. Een 30× verschil, alleen al door routeringsbeslissingen.

Schema-kennis is hier ook belangrijk. Tier 3-queries hebben niet alleen meer rekenkracht nodig. Ze hebben context nodig: tabelrelaties, foreign keys, indexes, database-specifieke syntaxis. Die context moet tijdens de inferentie worden geïnjecteerd.

Het uitvoeren van een eenvoudige Tier 1-query via dezelfde zware route verspilt tokens, voegt latentie toe en verbetert het resultaat niet.

Een praktische architectuur voor modelselectie

Een routersysteem heeft meestal vier fasen: classificeren, routeren, uitvoeren en valideren. Elke fase doet een andere taak en elke fase kan op een andere manier falen. Het helpt om ze afzonderlijk te bekijken voordat het volledige pijplijn wordt samengesteld.

Classificatie is de belangrijkste stap. De classificator ontvangt de ruwe SQL-query of de natuurlijke taalprompt die een query zal genereren en wijst deze toe aan een complexiteitstier. Er zijn drie veelvoorkomende manieren om deze classificator te bouwen.

Regelgebaseerde classificatie vertrouwt op regex-patronen en AST (abstracte syntaxisboom) parsing om structurele signalen te detecteren: dingen als telfout, nestingsdiepte, window-functies, subqueries of aggregatie-operatoren. Deze benadering is snel en voorspelbaar, met bijna geen overhead. Het werkt goed voor voor de hand liggende gevallen: eenvoudige SELECT-instructies en basis-DML kunnen meestal zonder model worden geïdentificeerd. 

Lichtgewicht classificatiemodellen gebruiken een klein taalmodel dat is getraind om SQL-complexiteit te schatten. Dit voegt een extra stap toe, maar het is een van de hoogste ROI-beslissingen in de hele pijplijn. Een classificatoraanroep kan ongeveer $0,0001 kosten, wat gemakkelijk de $0,03 frontier-modelaanroep rechtvaardigt. 

In veel configuraties kunnen deze lichtgewichtmodellen ook lokaal worden uitgevoerd, waardoor de kosten voor eenvoudige gebruikersquery’s effectief worden verwijderd. Ze kunnen ook natuurlijke taalprompts classificeren voordat SQL wordt gegenereerd, wat nuttig is in assistent-workflows waar de query nog niet bestaat. 

Hybride classificatie combineert beide benaderingen. Regelgebaseerde logica behandelt duidelijke gevallen tegen nul kosten, terwijl de classificator de dubieuze middengroep behandelt: queries die er matig uitzien, maar mogelijk complexe redenering nodig hebben om correct te genereren. 

Routeren gebeurt na classificatie. Maar de tier alleen is niet de enige factor. Een paar andere dingen beïnvloeden waar een query naartoe moet gaan. Deze omvatten: 

1. Schemacontextvereisten. Sommige queries hebben nodig dat het model de foreign key-relaties, indexes of andere structurele details begrijpt. Deze queries dragen meer context en moeten meestal naar een model met een hogere capaciteit worden doorgestuurd. 
2. Latentietolerantie. Gebruikersgerichte functies zoals autocomplete of inline-suggesties hebben strikte latentiebegrotingen. Achtergrondtaken hebben dat meestal niet. In die gevallen kan een langzamere maar capabelere model acceptabel zijn. 
3. Vertrouwensdrempels. Soms is de classificator niet zeker van de tier. In die gevallen is routeren omhoog meestal de veiligste optie. Een verkeerde downgrade kan een slechte query produceren en retries triggeren, wat vaak meer kost dan het gebruik van het sterkere model in de eerste plaats. 

De validatielaag wordt uitgevoerd nadat de code is uitgevoerd. De taak hiervan is om routeringsfouten te vangen voordat ze bij de gebruiker komen. Na de uitvoering worden controles uitgevoerd om ervoor te zorgen dat de syntaxis correct is, dat de resultaten redelijk zijn (heeft de query de juiste rijvormen geretourneerd?) en dat het schema consistent is. Wanneer een resultaat de validatie niet doorstaat, verplaatst het systeem zich naar een hoger niveau en voert de query opnieuw uit.

Bij Devart was het belangrijkste voor het verkrijgen van de nauwkeurigheid van de routering van dbForge AI Assistant het opbouwen van schema-gevoelige context in de classificatiebeslissing. Zonder schemacontext werden queries die onduidelijke tabelnamen gebruikten of afhankelijk waren van impliciete relaties altijd verkeerd geclassificeerd en naar goedkopere modellen doorgestuurd die ze niet aankonden. De oplossing was om de classificator niet alleen de querystructuur, maar ook enige schemametadata te geven.

Het meten van wat er toe doet: kost-kwaliteitstrade-offs in de praktijk

Het businessgeval voor routering houdt alleen stand als de kwaliteit behouden blijft. Kostverlaging die leidt tot verslechterde output, verhoogde retries of ontwikkelaarsvertrouwen is geen besparing, maar een overdracht van kosten van de infrastructuurrekening naar ontwikkelingtijd. Drie metrics bepalen of een routersysteem daadwerkelijk werkt.

Kosten per query per tier legt de basis vast. Volg de daadwerkelijke uitgaven per tier afzonderlijk, niet als een gemiddelde. Gemiddelden verhullen of de routering werkt, een systeem dat 50% van de queries naar de verkeerde tier stuurt, zal nog steeds een lagere gemiddelde kosten laten zien, terwijl het stilzwijgend slechtere resultaten produceert. 

De kwaliteitsscore controleert op correctheid, volledigheid en het volgen van SQL-richtlijnen. De escalatiesnelheid is het meest directe signaal. Het vertelt je hoe vaak een Tier 1- of Tier 2-model output produceert dat de validatie niet doorstaat en naar een andere locatie moet worden doorgestuurd. Een goed afgestemd systeem moet de escalatie onder de 5% houden. De classificator moet opnieuw worden getraind boven dat niveau. Het kan structurele signalen verkeerd interpreteren of het kan de schemacontext niet hebben die nodig is om het verschil tussen matig en complex te zien. 

Latentie-impact kijkt naar de tijd die nodig is voor een antwoord om van het ene niveau naar het andere te gaan, inclusief eventuele extra tijd die nodig is voor classificatie. Gebruikers moeten alleen een vertraging van 50 tot 100 milliseconden merken in interacties die door de routeringslaag gaan. Als classificatie zelf een probleem wordt, lost de hybride benadering (regels voor duidelijke gevallen, classificator alleen voor onduidelijke gevallen) het probleem op zonder nauwkeurigheid te verliezen. 

In het echte leven kan een goed afgestemd routersysteem de inferentiekosten met 40-60% verlagen, de escalatie onder de 5% houden en de outputkwaliteit hoog houden voor complexe queries. Om 70% of meer te besparen, moet je meestal Tier 1-taken zelf doen met kleinere modellen. Dat kan werken, maar het maakt dingen ook ingewikkelder, wat niet elke team wil doen.

De “escalatiebelasting” is nog een ding dat moet worden bekeken. Als routering te hard is voor goedkopere modellen, kan het systeem meer werk overall moeten doen: classificatoraanroep, initiële modelaanroep, mislukte validatie, doorsturen en een tweede modelaanroep. In sommige gevallen kost dit meer dan het doorsturen van de vraag naar het frontier-model in de eerste plaats.

Het enkel kijken naar de kost per aanroep mist dit effect. De escalatiesnelheid moet samen met de kost per aanroep worden gevolgd.

Strategische takeaways voor ontwikkelingsteams

Slimme routering is niet alleen een nice-to-have voor volwassen AI SQL-implementaties; het is een must-have voor langetermijnimplementaties. Teams die dit overslaan, ruilen een budgetprobleem dat niet kan worden opgelost in voor een architectuurprobleem dat kan worden opgelost. De patronen zijn er; het enige dat overblijft, is te beslissen welke patronen eerst te volgen.

Begin met de classificator, niet de modellen. De routeringslaag bepaalt of alles werkt. Een goed afgestemde hybride classificator zal je de meeste van de kostbesparingen geven zonder dingen te ingewikkeld te maken.

Gebruik de schemacontext van de feed om classificatiebeslissingen te helpen nemen. Voor SQL-werklasten die betrekking hebben op relaties tussen meerdere tabellen of redenering die specifiek is voor een schema, is querystructuur alleen niet voldoende. Gedeeltelijke schemametadata tijdens de classificatie verhoogt de nauwkeurigheid van de tier aanzienlijk.

Gebruik de escalatiesnelheid als het belangrijkste kwaliteitssignaal. Het vindt misclassificatie sneller dan elke andere metric en toont precies waar de classificator moet verbeteren.

Voordat de classificator, plan de validatielaag. Wetende wat mislukking lijkt en wat escalatie veroorzaakt, maakt de routeringslogica schoner en het systeem beter in staat om randgevallen te behandelen.

De waarde van de routeringslaag gaat omhoog, niet omlaag, naarmate open-sourcemodellen beter worden en de kosten van lokale inferentie omlaag gaan. Goedkopere Tier 1-modellen maken het kosterverschil tussen tiers groter, waardoor correcte classificatie waardevoller wordt. De routeringsarchitectuur die vandaag wordt gebouwd, zal voor een lange tijd nuttig zijn, niet alleen als een snelle oplossing.