Smarter spørringsruting for AI SQL-assistenter: Hvordan kutte kostnader uten å ofre kvalitet

Forestiller du deg at din SQL-assistent er en rakett som skyter gjennom komplekse spørringer. Deretter innser du at du bruker rakettdrivstoff for å hente en handleliste.

Dette er spennende, frem til regningen for drivstoff kommer. Plutselig blir det klart at enkle errander ikke trenger en rakett. Det samme skjer når hver SQL-forespørsel, fra en enkel oppslag til en multi-skjemaanalyse, blir sendt til samme kraftige AI-modell.

Prosessen med å få en AI SQL-assistent er vanligvis den samme. Først øker produktiviteten: Spørringer blir gjort raskere, boilerplate-kode forsvinner, og utviklere bruker mindre tid på å skrive rutine SQL-spørringer. Når flere team bruker det, øker antallet spørringer. Når infrastrukturregningen kommer, endres økonomien.

Problemet ligger i bygningen. Det koster mye å kjøre Frontier AI-modeller som kan tenke på eksekveringsplaner, skjema og komplekse spørringslogikk. Denne prisen er rimelig for vanskelige oppgaver, siden den koster omtrent $0,03 per spørring. Når de brukes til enkle SELECT-uttrykk og CRUD-operasjoner, blir det sløsing på større skala.

Men svaret er ikke å senke modellen. Det handler om å sende spørringene til riktig sted. Smart spørringsruting sorterer hver forespørsel etter hvor vanskelig den er og sender den til riktig modellnivå. Denne metoden kan kutte inferenskostnadene med 40–70% i SQL-arbeidsbelastninger uten å senke kvaliteten på utdataene.

Denne artikkelen forklarer hvordan denne arkitekturen fungerer: å definere SQL-kompleksitetsnivåer, bygge klassifiserings- og ruteringsrørledninger og måle de faktiske kostnadskvalitets-avveiingene når systemet er i drift. Disse mønsterne reflekterer lærdommer fra utviklingen av skjema-bevisste AI-egenskaper i dbForge AI Assistant.

Hvorfor en modell ikke passer for alle SQL-oppgaver

Ikke alle SQL-spørringer er like kompliserte. En spørring som henter en bruker etter primærnøkkel og en som bygger om sessionsspor over flere skjema med vindusfunksjoner er begge SQL, men resonneringen som trengs for å generere dem er svært forskjellig.

Hvis et system behandler dem likt, er resultatet forutsigbart: Sløsing av beregning. I de fleste bedriftsbelastninger er omtrent de fleste spørringene rutinemessige. Enkle oppslag, enkelttabelllesninger, grunnleggende innføringer, syntaksfeil. Ingen kompliserte. Å sende alle disse til en frontiermodell er som å bruke en godsvind til å bære en blokknote.

En måte å tenke på problemet er å dele spørringene inn i kompleksitetsnivåer:

Kostnadsforskjellen mellom nivåene er stor. En Nivå 1-spørring kan koste rundt $0,001 på en lett modell. Samme spørring sendt til en frontier-modell koster nærmere $0,03. Ved 10 000 spørringer per dag, er det $10 mot $300 i daglig utgift. En 30-ganger forskjell, bare fra ruteringsbeslutninger.

Skjema-bevissthet teller også her. Nivå 3-spørringer trenger ikke bare mer beregning. De trenger kontekst: tabell-relasjoner, fremmednøkler, indekser, database-spesifikk syntaks. Denne konteksten må injiseres under inferens.

Å kjøre en enkel Nivå 1-spørring gjennom samme tung vei sløser tokens, legger til latent tid og forbedrer ikke resultatet.

En praktisk arkitektur for modellvalg

Et rutersystem har vanligvis fire stadier: klassifisering, ruting, eksekvering og validering. Hver fase gjør en annen jobb, og hver kan feile på forskjellige måter. Det hjelper å tenke på dem separat før du setter sammen hele rørledningen.

Klassifisering er det viktigste steget. Klassifisereren mottar enten den rå SQL-spørringen eller den naturlige språkprompten som vil generere en og tilordner den til et kompleksitetsnivå. Det finnes tre vanlige måter å bygge denne klassifisereren.

Regelbasert klassifisering avhenger av regex-mønster og AST (abstrakt syntaks-tre) parsing for å detektere strukturelle signaler: ting som tabell-telling, innkapslingsdybde, vindusfunksjoner, under-spørringer eller aggregasjonsoperatorene. Denne tilnærmingen er rask og forutsigbar, med nesten ingen overhead. Den fungerer bra for åpenbare tilfeller: enkle SELECT-uttrykk og grunnleggende DML kan vanligvis identifiseres uten å involvere en modell i det hele tatt. 

Lettvekt-klassifiseringsmodeller bruker en liten språkmodell trent for å estimere SQL-kompleksitet. Dette legger til et ekstra steg, men det er ett av de høyeste ROI-beslutningene i hele rørledningen. En klassifiseringsanrop kan koste omtrent $0,0001, som lett kan rettferdiggjøre å unngå en $0,03 frontier-modell-anrop.  

I mange oppsett kan disse lettvekt-modellene også kjøres lokalt, og fjerner effektivt kostnaden for enkle brukerspørringer helt. De kan også klassifisere naturlige språkprompter før SQL genereres, som er nyttig i assistent-arbeidsflyter der spørringen ikke eksisterer ennå. 

Hybrid-klassifisering kombinerer begge tilnærmingene. Regelbasert logikk håndterer åpenbare tilfeller uten kostnad, mens klassifisereren håndterer den tvetydige midten: spørringer som ser moderate ut, men kan faktisk kreve skjema-bevisst resonnering for å generere korrekt. 

Ruting skjer etter klassifisering. Men nivået alene er ikke den eneste faktoren. Enkelte andre ting påvirker hvor en spørring skal gå. Disse inkluderer:  

1. Skjema-kontekst-krav. Noen spørringer trenger at modellen forstår fremmednøkler, indekser eller andre strukturelle detaljer. Disse spørringene bærer mer kontekst og trenger vanligvis å bli sendt til en høyere-egenskapsmodell. 
2. Latent-toleranse. Bruker-orienterte funksjoner som autocomplete eller inline-forslag har strenge latent-budsjett. Bakgrunnsoppgaver har vanligvis ikke. I disse tilfellene kan en langsommere, men mer kapabel modell være akseptabel. 
3. Tillitsnivåer. Noen ganger er klassifisereren ikke sikker på nivået. I disse tilfellene er ruting opp vanligvis det tryggeste valget. En feil nedgradering kan produsere en dårlig spørring og utløse omgjøringer, som ofte koster mer enn å bruke den sterkere modellen fra første sted. 

Valideringslaget kjører etter at koden har blitt kjørt. Jobben med dette er å fange ruteringsfeil før de når brukeren. Etter eksekvering gjøres sjekker for å sikre at syntaksen er korrekt, at resultater er rimelige (returnerte spørringen riktige rad-former?), og at skjemaet er konsistent. Når et resultat feiler validering, flytter systemet opp ett nivå og kjører spørringen igjen.

Ved Devart var det viktigste for å få dbForge AI Assistants ruteringsnøyaktighet rett å bygge skjema-bevisst kontekst inn i klassifiseringsbeslutningen. Uten skjema-kontekst ble spørringer som brukte uklare tabellnavn eller avhengig av implisitte relasjoner alltid feilklassifisert og sendt til billigere modeller som ikke kunne håndtere dem. Løsningen var å gi klassifisereren ikke bare spørringsstrukturen, men også noe skjema-metadata.

Måling av hva som teller: kostnad-kvalitets-avveiinger i praksis

Forretningscasen for ruting holder bare hvis kvaliteten holder sammen med det. Kostnadsreduksjon som forårsaker forringet utdata, økt omgjøringer eller utvikler-mistrivelse er ikke en besparelse, det er en overføring av kostnad fra infrastruktur-regningen til utviklingstid. Tre målinger bestemmer om et rutingssystem faktisk fungerer.

Kostnad per spørring etter nivå etablerer basislinjen. Spore faktisk utgift på hvert nivå separat, ikke som en blandet gjennomsnitt. Blanding skjuler om rutingen fungerer, et system som router 50% av spørringene til feil nivå vil fortsatt vise en lavere gjennomsnittlig kostnad, mens det stille produserer dårligere resultater. 

Kvalitetsscoren sjekker for korrekthet, fullstendighet og følger SQL-best-practices. Eskalasjonsraten er det mest direkte signalet. Den forteller hvor ofte en Nivå 1 eller Nivå 2-modell produserer utdata som ikke passerer validering og må sendes til en annen lokasjon. Et system som er godt justert bør holde eskalasjon under 5%. Klassifisereren må være omtrænt over dette nivået. Den kan misforstå strukturelle signaler eller den kan ikke ha skjema-konteksten den trenger for å skille mellom moderat og kompleks. 

Latent-påvirkning ser på hvor lenge det tar for et svar å flytte fra ett nivå til det neste, inkludert ekstra tid nødvendig for klassifisering. Brukere bør bare merke en 50 til 100 millisekunders forsinkelse i interaksjoner som går gjennom ruteringslaget. Hvis klassifisering selv blir et problem, fikser hybrid-tilnærmingen (regler for åpenbare tilfeller, klassifiserer bare for uklare) det uten å tape nøyaktighet. 

I virkeligheten kan et godt justert rutingssystem senke inferenskostnadene med 40–60%, holde eskalasjon under 5% og holde kvaliteten på utdataene høy for komplekse spørringer. For å spare 70% eller mer, må du vanligvis gjøre Nivå 1-oppgaver på egen hånd med mindre modeller. Det kan fungere, men det gjør også ting mer kompliserte, noe ikke alle team ønsker å håndtere.

“Eskalasjonsskatten” er en annen ting som må vurderes. Hvis ruting er for hard på billigere modeller, kan systemet måtte gjøre mer arbeid totalt: klassifiseringsanrop, initial modellanrop, feil validering, omruting og en annen modellanrop. I noen tilfeller koster det mer enn å sende spørringen til frontier-modellen fra første sted.

Å se bare på kostnad per anrop overser denne effekten. Eskalasjonsraten må spores sammen med det.

Strategiske takeaways for utviklingsteam

Smart ruting er ikke bare et ønske for modne AI SQL-utviklinger; det er et måtte-ha for langsiktige. Team som hopper over det bytter en budsjett-problem som ikke kan løses ut med et arkitektur-problem som kan løses. Mønsterene er der; det eneste som er igjen er å bestemme hvilke å følge først.

Start med klassifisereren, ikke modellene. Ruteringslaget bestemmer om alt annet fungerer. En godt justert hybrid-klassifiserer vil gi deg de fleste kostnadsbesparelsene uten å gjøre ting for kompliserte.

Bruk skjema-konteksten til å hjelpe med klassifiseringsbeslutninger. For SQL-arbeidsbelastninger som involverer relasjoner mellom flere tabeller eller resonnering som er spesifikk for et skjema, er spørringsstruktur alene ikke nok. Delvis skjema-metadata på klassifiserings-tid øker nivå-nøyaktigheten betydelig.

Bruk eskalasjonsraten som hovedkvalitetssignal. Den finner mis-klassifisering raskere enn noen annen måling og viser nøyaktig hvor klassifisereren må bli bedre.

Før klassifisereren, plan valideringslaget. Å vite hva feil ser ut som og hva som forårsaker en eskalasjon gjør ruteringslogikken renere og systemet bedre i stand til å håndtere kanter.

Verdien av ruteringslaget øker, ikke synker, ettersom åpen-kilde-modeller blir bedre og kostnaden av lokal inferens går ned. Billigere Nivå 1-modeller gjør kostnadsforskjellen mellom nivå større, noe som gjør korrekt klassifisering mer verdifull. Ruteringsarkitekturen som bygges i dag vil være nyttig i lang tid, ikke bare som en rask løsning.