Intelligente SQL-routning til AI-assistenter: Sådan reducerer du omkostningerne uden at gå på kompromis med kvaliteten

Forestil dig, at din SQL-assistent er en raket, der skyder gennem komplekse forespørgsler. Så en dag går det op for dig, at du bruger raketbrændstof til at hente en indkøbsliste.

Det er spændende, indtil regningen for brændstof kommer. Pludselig bliver det klart, at simple ærinder ikke kræver en raket. Det samme sker, når hver SQL-anmodning, fra en grundlæggende opslag til en multi-schema-analyse, sendes til samme kraftfulde AI-model.

Processen med at få en AI SQL-assistent er normalt den samme. Til at begynde med stiger produktiviteten: Forespørgslerne udføres hurtigere, standardkoden forsvinder, og udviklerne bruger mindre tid på at skrive rutine-SQL-forespørgsler. Da flere hold bruger det, stiger antallet af forespørgsler. Når regningen for infrastrukturen kommer, ændrer økonomien sig.

Problemet ligger i bygningen. Det koster meget at køre Frontier AI-modeller, der kan tænke over udførelsesplaner, schemata og komplekse forespørgselslogik. Den pris er rimelig for svære opgaver, da den koster omkring 0,03 $ pr. forespørgsel. Når de bruges til simple SELECT-udtalelser og CRUD-operationer, bliver det dog spild på størrelse.

Men svaret er ikke at nedgradere modellen. Det handler om at sende forespørgslerne til det rette sted. Intelligent forespørgselsroutning sorterer hver anmodning efter sværhedsgrad og sender den til den rette modelklasse. Denne metode kan reducere omkostningerne ved inference med 40-70% i SQL-arbejdsmængder uden at gå på kompromis med outputkvaliteten.

Denne artikel forklarer, hvordan denne arkitektur fungerer: Definering af SQL-kompleksitetsklasser, opbygning af klassificerings- og routningsrørledninger og måling af de faktiske omkostningskvalitetsudvekslinger, når systemet er i gang. Disse mønstre afspejler erfaringer fra udviklingen af schema-bevidste AI-kapaciteter i dbForge AI-assistenten.

Hvorfor en model ikke passer til alle SQL-opgaver

Ikke alle SQL-forespørgsler er ens i kompleksitet. En forespørgsel, der henter en bruger efter primærnøgle, og en, der genopbygger sessionskanaler på tværs af flere schemata med vinduefunktioner, er begge SQL, men den tænkning, der er nødvendig for at generere dem, er meget forskellig.

Hvis et system behandler dem på samme måde, er resultatet forudsigeligt: Spild af beregning. I de fleste enterprise-arbejdsmængder er de fleste forespørgsler rutinemæssige. Simple opslag, enkelttabellæsninger, grundlæggende indsættelser, syntaksrettelser. Intet kompliceret. At sende alle disse til en frontier-model er som at bruge en godsvægtløfter til at bære en notesbog.

En måde at tænke over problemet på er at splitte forespørgslerne op i kompleksitetsklasser:

Omkostningsforskellen mellem klasserne er stor. En forespørgsel i klasse 1 kan koste omkring 0,001 $ på en letvægtsmodel. Den samme forespørgsel sendt til en frontier-model koster tættere på 0,03 $. Ved 10.000 forespørgsler pr. dag er det 10 $ vs. 300 $ i daglige udgifter. En 30-gangs forskel, kun på grund af routingsbeslutninger.

Schema-bevidsthed er også vigtig her. Forespørgsler i klasse 3 har ikke kun brug for mere beregning. De har brug for kontekst: tabellrelationer, fremmednøgler, indekser, databasespecifik syntaks. Denne kontekst skal injiceres under inference.

At køre en simpel forespørgsel i klasse 1 gennem samme tunge sti spilder tokens, tilføjer latency og forbedrer ikke resultatet.

En praktisk arkitektur for modelvalg

Et routingsystem har normalt fire faser: klassificering, routning, udførelse og validering. Hver fase har et andet job, og hver kan fejle på forskellige måder. Det hjælper at tænke over dem separat, før man samler den fulde pipeline.

Klassificering er det vigtigste trin. Klassificatoren modtager enten den rå SQL-forespørgsel eller den naturlige sprogsprompt, der genererer en forespørgsel, og tilordner den til en kompleksitetsklasse. Der er tre almindelige måder at bygge denne klassificator på.

Regelbaseret klassificering afhænger af regex-mønstre og AST (abstrakt syntaks-træ)-parsing til at registrere strukturelle signaler: ting som tabellæsning, indlejring, vinduefunktioner, underforespørgsler eller aggregationsoperatorer. Denne tilgang er hurtig og forudsigelig, med næsten ingen overhead. Den fungerer godt for åbenlyse tilfælde: simple SELECT-udtalelser og grundlæggende DML kan normalt identificeres uden at involvere en model overhovedet. 

Lette klassificeringsmodeller bruger en lille sprogmodel, der er trænet til at estimere SQL-kompleksitet. Dette tilføjer et ekstra trin, men det er en af de bedste ROI-beslutninger i hele pipeline. En klassificator-opkald kan koste omkring 0,0001 $, hvilket let kan retfærdiggøre undgåelse af en 0,03 $ frontier-model-opkald. 

I mange opsætninger kan disse lette modeller også køre lokalt, hvilket effektivt fjerner omkostninger for simple brugerforespørgsler helt. De kan også klassificere naturlige sprogsprompts før SQL genereres, hvilket er nyttigt i assistent-arbejdsgange, hvor forespørgslen endnu ikke eksisterer. 

Hybrid-klassificering kombinerer begge tilgange. Regelbaseret logik håndterer åbenlyse tilfælde med nul omkostninger, mens klassificatoren håndterer den tvetydige midte: forespørgsler, der ligner moderate, men faktisk kræver schema-bevidst tænkning for at generere korrekt. 

Routning sker efter klassificering. Men klassen alene er ikke den eneste faktor. Nogle andre ting påvirker, hvor en forespørgsel skal sendes. Disse inkluderer: 

1. Schema-kontekstkrav. Nogle forespørgsler kræver, at modellen forstår fremmednøgler, indekser eller andre strukturelle detaljer. Disse forespørgsler bærer mere kontekst og kræver normalt at blive sendt til en model med højere kapacitet. 
2. Latens-tolerance. Brugerfacing-funktioner som autocomplete eller inline-forslag har strenge latens-budgetter. Baggrundsopgaver har normalt ikke. I disse tilfælde kan en langsommere, men mere kapabel model være acceptabel. 
3. Tillidsniveauer. Nogle gange er klassificatoren ikke sikker på klassen. I disse tilfælde er routning op normalt den sikrere mulighed. En forkert nedgradering kan producere en dårlig forespørgsel og udløse genoptagelser, som ofte koster mere end at bruge den stærkere model fra starten. 

Valideringslaget kører efter, at koden er blevet kørt. Dets job er at fange routingsfejl, før de når brugeren. Efter udførelsen kontrolleres det, at syntaksen er korrekt, at resultaterne er rimelige (returnerede forespørgslen den rigtige rækkeform?), og at schemat er konsistent. Når et resultat fejler validering, flytter systemet op på niveau og kører forespørgslen igen.

Ved Devart var det vigtigste for at få dbForge AI-assistentens routingsnøjagtighed ret, at bygge schema-bevidst kontekst ind i klassificeringsbeslutningen. Uden schema-kontekst blev forespørgsler, der brugte uklare tabellnavne eller afhængige af implicitte relationer, altid mis klassificeret og sendt til billigere modeller, der ikke kunne håndtere dem. Løsningen var at give klassificatoren ikke kun forespørgselsstrukturen, men også nogen schema-metadata.

Hvad der betyder noget: Omkostningskvalitetsudvekslinger i praksis

Den økonomiske grund til routning gælder kun, hvis kvaliteten holder. Omkostningsreduktion, der medfører nedgraderet output, øgede genoptagelser eller udviklertillid, er ikke en besparelse, men en overførsel af omkostninger fra infrastrukturregningen til udviklingstid. Tre målinger bestemmer, om et routingsystem virker.

Omkostning pr. forespørgsel efter klasse etablerer grundlinjen. Sporet faktiske udgifter på hver klasse separat, ikke som en gennemsnitsværdi. Gennemsnit forstærker, om routingsbeslutningerne virker, et system, der router 50% af forespørgslerne til den forkerte klasse, vil stadig vise en lavere gennemsnitsomkostning, mens det stille producerer dårligere resultater. 

Kvalitetsscoren kontrollerer for korrekthed, fuldstændighed og overholdelse af SQL-bedste praksis. Eskalationsraten er det direkte signal. Den viser, hvor ofte en model i klasse 1 eller 2 producerer output, der ikke passerer validering, og kræver at blive sendt til en anden destination. Et velafstemt system bør holde eskalation under 5%. Klassificatoren skal gen-trænes over dette niveau. Den kan mislæse strukturelle signaler eller mangler måske den schema-kontekst, den behøver for at skelne mellem moderate og komplekse forespørgsler. 

Latenspåvirkning ser på, hvor lang tid det tager for et svar at flytte fra den ene klasse til den anden, herunder eventuel ekstra tid, der kræves til klassificering. Brugere bør kun bemærke en forsinkelse på 50-100 millisekunder i interaktioner, der går gennem routingslaget. Hvis klassificering selv bliver et problem, løser den hybride tilgang (regler for åbenlyse tilfælde, klassificator kun for uklare tilfælde) det uden at gå på kompromis med nøjagtighed. 

I virkeligheden kan et velafstemt routingsystem reducere omkostningerne ved inference med 40-60%, holde eskalation under 5% og holde outputkvaliteten høj for komplekse forespørgsler. For at spare 70% eller mere skal man normalt udføre opgaver i klasse 1 på egen hånd med mindre modeller. Det kan fungere, men det gør også ting mere komplicerede, hvilket ikke alle hold ønsker at beskæftige sig med.

“Eskalationsafgiften” er en anden faktor, der skal undersøges. Hvis routingsbeslutninger er for hårdt på billigere modeller, kan systemet være nødt til at udføre mere arbejde i alt: klassificator-opkald, initial model-opkald, fejlet validering, omdirigering og andet model-opkald. I nogle tilfælde koster det mere end at sende spørgsmålet til frontier-modellen fra starten.

At se kun på omkostning pr. opkald overser denne effekt. Eskalationsraten skal spores sammen med det.

Strategiske takeaways for udviklingsteams

Intelligent routning er ikke kun et ønskeligt tilbehør til modne AI SQL-udviklinger; det er et nødvendigt tilbehør til langsigtede udviklinger. Hold, der springer over det, handler en uopløselig budgetproblematik for en arkitekturproblematik, der kan løses. Mønstrene er der; det eneste, der mangler, er at beslutte, hvilke til at følge først.

Start med klassificatoren, ikke modellerne. Routingslaget bestemmer, om alt andet virker. En velafstemt hybrid-klassificator giver dig de fleste af omkostningsbesparelserne uden at gøre ting for komplicerede.

Brug schema-konteksten af fødekilden til at hjælpe med at træffe klassificeringsbeslutninger. For SQL-arbejdsmængder, der indebærer relationer mellem flere tabeller eller tænkning, der er specifik for et schema, er forespørgselsstrukturen alene ikke nok. Delvist schema-metadata under klassificeringstid øger betydeligt klasse-nøjagtigheden.

Brug eskalationsraten som det primære kvalitetssignal. Den finder mis-klassificering hurtigere end nogen anden måling og viser præcist, hvor klassificatoren skal forbedres.

Før klassificatoren planlægger valideringslaget. At vide, hvordan fejl ser ud, og hvad der forårsager en eskalation, gør routingslogikken renere og systemet bedre i stand til at håndtere kanter.

Værdien af routingslaget stiger op, ikke ned, efterhånden som open-source-modeller bliver bedre og omkostningerne ved lokal inference går ned. Billigere modeller i klasse 1 gør omkostningsforskellen mellem klasserne større, hvilket gør korrekt klassificering mere værdifuld. Routingsarkitekturen, der bygges i dag, vil være nyttig i lang tid, ikke kun som en hurtig løsning.