Rutearea inteligentă a interogărilor pentru asistenții SQL AI: Cum să reduceți costurile fără a sacrifica calitatea

Imaginați-vă că asistentul dvs. SQL este o rachetă, străbătând interogări complexe. Apoi, într-o zi, vă dați seama că utilizați combustibil pentru rachetă pentru a obține o listă de cumpărături.

Este interesant, până când vine factura pentru combustibil. Brusc, devine clar că sarcinile simple nu necesită o rachetă. Același lucru se întâmplă atunci când fiecare cerere SQL, de la o căutare de bază la o analiză multi-schemă, este direcționată către același model AI puternic.

Procesul de obținere a unui asistent SQL AI este de obicei același. La început, productivitatea crește: interogările sunt efectuate mai rapid, codul de tip boilerplate dispare, iar dezvoltatorii petrec mai puțin timp scriind interogări SQL de rutină. Pe măsură ce mai multe echipe îl utilizează, numărul de interogări crește. Când vine factura de infrastructură, economia se schimbă.

Problema este cu clădirea. Costă mult să ruleze modelele Frontier AI care pot gândi despre planurile de execuție, scheme și logică de interogare complexă. Acest preț are sens pentru sarcinile grele, deoarece costă aproximativ 0,03 dolari pe interogare. Când sunt utilizate pentru declarații SELECT simple și operații CRUD, devine risipă la scară.

Dar răspunsul nu este să reduceți modelul. Este să trimiteți interogările în locul potrivit. Rutearea inteligentă a interogărilor sortează fiecare cerere după dificultate și o trimite către modelul potrivit. Această metodă poate reduce costurile de inferență cu 40-70% în sarcinile de lucru SQL, fără a compromite calitatea ieșirii.

Acest articol explică cum funcționează această arhitectură: definirea nivelurilor de complexitate SQL, construirea de conducte de clasificare și ruteare, și măsurarea adevăratelor compromisuri cost-calitate odată ce sistemul este în funcțiune. Aceste modele reflectă lecțiile învățate în timpul dezvoltării de capacități AI conștiente de schemă în dbForge AI Assistant.

De ce un model nu se potrivește tuturor sarcinilor SQL

Nu toate interogările SQL sunt la fel ca nivel de complexitate. O interogare care obține un utilizator prin cheia primară și una care reconstruiește canalele de sesiune pe mai multe scheme cu funcții de fereastră sunt ambele SQL, dar raționamentul necesar pentru a le genera este foarte diferit.

Dacă un sistem le tratează la fel, rezultatul este previzibil: computație irosită. În majoritatea sarcinilor de lucru enterprise, aproximativ majoritatea interogărilor sunt de rutină. Căutări simple, citiri de tabele unice, inserări de bază, corecturi de sintaxă. Nimic complicat. Trimiterea tuturor acestor interogări către un model Frontier este ca și cum ați folosi un lift de marfă pentru a transporta un caiet.

Un mod de a gândi despre problema este prin împărțirea interogărilor în niveluri de complexitate:

Gap-ul de cost între niveluri este mare. O interogare de nivel 1 ar putea costa aproximativ 0,001 dolari pe un model ușor. Aceeași interogare trimisă către un model Frontier costă mai aproape de 0,03 dolari. La 10.000 de interogări pe zi, aceasta înseamnă 10 dolari versus 300 de dolari în cheltuieli zilnice. O diferență de 30 de ori, doar din cauza deciziilor de ruteare.

Conștientizarea schemei este importantă și aici. Interogările de nivel 3 nu necesită doar mai multă putere de calcul. Ele necesită context: relații între tabele, chei străine, indici, sintaxă specifică bazei de date. Acest context trebuie injectat în timpul inferenței.

Rularea unei interogări simple de nivel 1 prin același traseu greu irosește token-uri, adaugă latență și nu îmbunătățește rezultatul.

O arhitectură practică pentru selectarea modelului

Un sistem de ruteare are de obicei patru etape: clasificare, ruteare, execuție și validare. Fiecare etapă are o sarcină diferită și poate eșua în moduri diferite. Ajută să se gândească la ele separat înainte de a pune împreună conducta completă.

Clasificarea este pasul cel mai important. Clasificatorul primește fie interogarea SQL brută, fie promptul de limbaj natural care va genera una și o atribuie unui nivel de complexitate. Există trei moduri comune de a construi acest clasificator.

Clasificarea bazată pe reguli se bazează pe modele de regex și analiza arborelui de sintaxă abstractă pentru a detecta semnale structurale: lucruri precum numărul de tabele, adâncimea încapsulării, funcții de fereastră, subinterogări sau operatori de agregare. Acest abordare este rapidă și previzibilă, cu aproape niciun overhead. Funcționează bine pentru cazurile evidente: interogări SELECT simple și operații DML de bază pot fi de obicei identificate fără a implica un model. 

Modelele de clasificare ușoare utilizează un model de limbaj mic antrenat pentru a estima complexitatea SQL. Acesta adaugă un pas suplimentar, dar este una dintre deciziile cu cel mai bun raport cost-eficiență din conducta întreagă. O apelare a clasificatorului ar putea costa aproximativ 0,0001 dolari, ceea ce justifică ușor evitarea unei apelări a modelului Frontier de 0,03 dolari. 

În multe configurații, aceste modele ușoare pot funcționa și local, eliminând efectiv costul pentru interogările simple ale utilizatorilor. Ele pot clasifica, de asemenea, prompturile de limbaj natural înainte de a genera SQL, ceea ce este util în fluxurile de lucru ale asistenților în care interogarea nu există încă. 

Clasificarea hibridă combină ambele abordări. Logica bazată pe reguli gestionează cazurile clare la zero cost, în timp ce clasificatorul gestionează cazurile ambigue: interogări care par moderate, dar care pot necesita, de fapt, raționament conștient de schemă pentru a fi generate corect. 

Rutearea are loc după clasificare. Dar nivelul singur nu este singurul factor. Câteva alte lucruri influențează unde ar trebui să meargă o interogare. Acestea includ: 

1. Cereri de context de schemă. Unele interogări necesită ca modelul să înțeleagă relații între tabele, chei străine, indici sau alte detalii structurale. Aceste interogări poartă mai mult context și, de obicei, necesită să fie direcționate către un model cu o capacitate mai mare. 
2. Toleranță la latență. Caracteristicile orientate către utilizator, cum ar fi autocomplete sau sugestii inline, au bugete de latență stricte. Sarcinile de fundal, de obicei, nu. În aceste cazuri, un model mai lent, dar mai capabil, poate fi acceptabil. 
3. Praguri de încredere. Uneori, clasificatorul nu este sigur despre nivel. În aceste cazuri, rutearea în sus este, de obicei, opțiunea mai sigură. O coborâre greșită poate produce o interogare proastă și poate declanșa retrimiteri, care, de obicei, costă mai mult decât utilizarea modelului mai puternic din start. 

Stratul de validare rulează după ce codul a fost executat. Sarcina sa este să prindă greșelile de ruteare înainte de a ajunge la utilizator. După execuție, se verifică dacă sintaxa este corectă, dacă rezultatele sunt rezonabile (a returnat interogarea rândurile corecte?), și dacă schema este coerentă. Când un rezultat nu trece validarea, sistemul se mută la un nivel superior și rulează interogarea din nou.

La Devart, cel mai important lucru pentru a obține acuratețea ruteării dbForge AI Assistant a fost construirea contextului conștient de schemă în decizia de clasificare. Fără contextul schemei, interogările care utilizează nume de tabele neclare sau se bazează pe relații implicite erau întotdeauna clasificate greșit și trimise către modele mai ieftine care nu le puteau gestiona. Soluția a fost să ofere clasificatorului nu numai structura interogării, ci și câteva metadate ale schemei.

Măsurarea a ceea ce contează: compromisuri cost-calitate în practică

Cazul de afaceri pentru ruteare este valabil doar dacă calitatea se menține alături de aceasta. Reducerea costurilor care cauzează o ieșire degradată, retrimiteri crescute sau neîncrederea dezvoltatorilor nu este o economie, ci o transferare a costului de la factura de infrastructură la timpul de inginerie. Trei metrici determină dacă un sistem de ruteare funcționează cu adevărat.

Costul pe interogare pe nivel stabilește baza. Urmați cheltuielile reale la fiecare nivel separat, nu ca o medie amestecată. Amestecarea ascunde dacă rutearea funcționează, un sistem care rulează 50% din interogări către nivelul greșit va arăta, totuși, un cost mediu mai mic, în timp ce produce rezultate mai slabe în mod silențios. 

Scorul de calitate verifică corectitudinea, completețea și respectarea celor mai bune practici SQL. Rata de escaladare este cel mai direct semnal. Arată cât de des un model de nivel 1 sau 2 produce o ieșire care nu trece validarea și necesită să fie trimisă către o altă locație. Un sistem bine reglat ar trebui să mențină escaladarea sub 5%. Clasificatorul are nevoie de reantrenare peste acest nivel. Poate că citește greșit semnalele structurale sau nu are contextul schemei necesar pentru a face diferența între moderate și complex. 

Impactul latenței examinează cât timp durează ca un răspuns să se deplaseze de la un nivel la altul, inclusiv orice timp suplimentar necesar pentru clasificare. Utilizatorii nu ar trebui să observe o întârziere de 50 până la 100 de milisecunde în interacțiunile care trec prin stratul de ruteare. Dacă clasificarea în sine devine o problemă, abordarea hibridă (reguli pentru cazurile clare, clasificator doar pentru cele neclare) o repară fără a pierde acuratețe. 

În viața reală, un sistem de ruteare bine reglat poate reduce costurile de inferență cu 40-60%, menține escaladarea sub 5% și menține calitatea ieșirii ridicată pentru interogări complexe. Pentru a economisi 70% sau mai mult, de obicei, trebuie să faceți sarcinile de nivel 1 singur, cu modele mai mici. Acest lucru ar putea funcționa, dar face și lucrurile mai complicate, ceea ce nu toate echipele vor să se ocupe.

“Taxa de escaladare” este un alt lucru care trebuie examinat. Dacă rutearea este prea dură pe modelele mai ieftine, sistemul poate fi nevoit să facă mai multă muncă în general: apelare a clasificatorului, apelare inițială a modelului, validare eșuată, ruteare și un al doilea apel de model. În unele cazuri, acest lucru costă mai mult decât trimiterea întrebării către modelul Frontier din start.

Examinarea doar a costului pe apel ratează acest efect. Rata de escaladare trebuie urmărită alături de aceasta.

Concluzii strategice pentru echipele de ingineri

Rutearea inteligentă nu este doar un lucru bun pentru implementările mature de AI SQL; este un must-have pentru cele pe termen lung. Echipele care o saresc schimbă o problemă de buget care nu poate fi rezolvată cu o problemă de arhitectură care poate fi. Modelele sunt acolo; singurul lucru care trebuie făcut este să decideți care să urmați mai întâi.

Începeți cu clasificatorul, nu cu modelele. Stratul de ruteare decide dacă totul funcționează. Un clasificator hibrid bine reglat vă va oferi majoritatea economiilor de cost fără a face lucrurile prea complicate.

Utilizați contextul schemei alimentării pentru a ajuta la deciziile de clasificare. Pentru sarcinile de lucru SQL care implică relații între mai multe tabele sau raționament specific schemei, structura interogării singură nu este suficientă. Metadatele parțiale ale schemei la momentul clasificării măresc semnificativ acuratețea nivelului.

Utilizați rata de escaladare ca semnal principal de calitate. Acesta găsește mai rapid decât orice altă metrică clasificările greșite și arată exact unde clasificatorul are nevoie de îmbunătățiri.

Înainte de clasificator, planificați stratul de validare. Știind ce arată eșecul și ce cauzează o escaladare face logica de ruteare mai curată și sistemul mai capabil să gestioneze cazurile marginale.

Valoarea stratului de ruteare crește, nu scade, pe măsură ce modelele open-source devin mai bune și costul inferenței locale scade. Modelele mai ieftine de nivel 1 fac diferența de cost între niveluri mai mare, ceea ce face clasificarea corectă și mai valoroasă. Arhitectura de ruteare construită astăzi va fi utilă pentru o perioadă lungă de timp, nu doar ca o soluție rapidă.