Chytré směrování dotazů pro asistenty AI SQL: Jak snížit náklady bez snížení kvality

Představte si, že váš asistent SQL je raketou, která prolétá složitými dotazy. Pak si jednou uvědomíte, že používáte raketové palivo, aby jste získali seznam nákupů.

Je to vzrušující, dokud nepřijde účet za palivo. Najednou je jasné, že jednoduché úkoly nevyžadují raketu. Stejné věci se dějí, když každý SQL dotaz, od základního vyhledávání po analýzu více schémat, je směrován na stejný výkonný model AI.

Proces získání asistenta AI SQL je obvykle stejný. Na začátku se produktivita zvyšuje: dotazy jsou rychlejší, odpadá kód a vývojáři tráví méně času psaním rutinních dotazů SQL. Jak více týmů ho používá, počet dotazů roste. Když přijde účet za infrastrukturu, ekonomika se změní.

Problém je ve stavbě. Náklady na provoz modelů AI Frontier, které mohou zvažovat plány spuštění, schémata a složitou logiku dotazů, jsou vysoké. Tato cena má smysl pro náročné úkoly, protože stojí asi 0,03 dolaru za dotaz. Když se však používají pro jednoduché příkazy SELECT a operace CRUD, stává se to plýtváním v měřítku.

Ale odpověď není snižovat model. Je to směrování dotazů na správné místo. Chytré směrování dotazů třídí každý požadavek podle obtížnosti a směruje ho do správné úrovně modelu. Tato metoda může snížit náklady na inference o 40–70 % v SQL pracovních zátěží bez snížení kvality výstupu.

Tento článek vysvětluje, jak tato architektura funguje: definice úrovní složitosti SQL, vytváření klasifikačních a směrovacích potrubí a měření skutečných nákladů na kvalitu, když je systém spuštěn. Tyto vzorce odrážejí zkušenosti získané při vývoji schopností AI, které jsou vědomé schématu, v dbForge AI Assistant.

Proč jeden model nevyhovuje všem úlohám SQL

Ne všechny dotazy SQL jsou stejné co do složitosti. Dotaz, který vyhledává uživatele podle primárního klíče, a ten, který rekonstruuje kanály relací přes několik schémat s funkcemi okna, jsou oba SQL, ale požadované myšlení pro jejich generování je velmi odlišné.

Jestliže systém zachází s nimi stejně, výsledek je předvídatelný: plýtvání výpočetními prostředky. Ve většině podnikových zátěží je většina dotazů rutinních. Jednoduché vyhledávání, čtení z jedné tabulky, základní vložení, opravy syntaxe. Nic složitého. Směrování všech těchto dotazů na model Frontier je jako použití nákladního výtahu pro přepravu poznámkového bloku.

Jedním způsobem, jak思考ovat o problému, je rozdělit dotazy do úrovní složitosti:

Mezera mezi náklady na úrovně je velká. Dotaz úrovně 1 může stát kolem 0,001 dolaru na lehkém modelu. Stejný dotaz směrovaný na model Frontier stojí blíže 0,03 dolaru. Při 10 000 dotazech denně je to 10 dolarů vs 300 dolarů denně. Rozdíl 30×, pouze z důvodu směrování.

Povědomí o schématu také záleží. Dotazy úrovně 3 nepotřebují pouze více výpočetních prostředků. Potřebují kontext: vztahy mezi tabulkami, cizí klíče, indexy, syntaxe specifické pro databázi. Tento kontext musí být vložen během inference.

Spuštění jednoduchého dotazu úrovně 1 přes stejnou těžkou cestu plýtvá tokeny, přidává latenci a nezlepšuje výsledek.

Praktická architektura pro výběr modelu

Systém směrování obvykle má čtyři fáze: klasifikace, směrování, spuštění a validace. Každá fáze má jinou úlohu a může selhat jiným způsobem. Pomůže, když se o nich zamyslíme zvlášť, než je složíme do plného potrubí.

Klasifikace je nejdůležitějším krokem. Klasifikátor dostává buď surový dotaz SQL nebo přirozený jazykový prompt, který vygeneruje jeden, a přiřadí ho k úrovní složitosti. Existují tři běžné způsoby, jak postavit tento klasifikátor.

Klasifikace založená na pravidlech spoléhá na vzorce regex a parsing abstraktního syntaxe stromu (AST) k detekci strukturních signálů: věci jako počet tabulek, hloubka vnoření, funkce okna, poddotazy nebo agregované operátory. Tento přístup je rychlý a předvídatelný, s téměř žádnou režijní náklady. Dobře funguje pro zjevné případy: jednoduché příkazy SELECT a základní DML lze obvykle identifikovat bez zapojení modelu. 

Modely lehkých klasifikátorů používají malý jazykový model, který je vyškoleno odhadnout složitost SQL. To přidává další krok, ale je to jedna z nejlepších investic v celém potrubí. Volání klasifikátoru může stát kolem 0,0001 dolaru, což snadno ospravedlňuje vyhnutí se volání modelu Frontier za 0,03 dolaru. 

Ve mnoha nastaveních mohou tyto lehké modely také běžet místně, což efektivníma odstraňuje náklady pro jednoduché uživatelské dotazy. Mohou také klasifikovat přirozené jazykové prompty předtím, než je vygenerován SQL, což je užitečné v pracovních postupech asistentů, kde dotaz ještě neexistuje. 

Hybridní klasifikace kombinuje oba přístupy. Logika založená na pravidlech zpracovává jasný případ za nulové náklady, zatímco klasifikátor zpracovává nejasný střed: dotazy, které vypadají středně, ale mohou ve skutečnosti vyžadovat povědomí o schématu, aby je generovaly správně. 

Směrování se děje po klasifikaci. Ale úroveň sama o sobě není jediným faktorem. Několik dalších věcí ovlivňuje, kam by měl dotaz jít. Tyto zahrnují: 

1. Požadavky na kontext schématu. Některé dotazy potřebují, aby model rozuměl vztahům mezi tabulkami, indexům nebo jiným strukturním detailům. Tyto dotazy přinášejí více kontextu a obvykle potřebují být směrovány do modelu s vyšší kapacitou. 
2. Toleranci latence. Uživatelům čelící funkce, jako je automatické dokončování nebo inline návrhy, mají přísné rozpočty latence. Pozadí úkoly obvykle ne. V těchto případech může být přijatelný pomalejší, ale schopnější model. 
3. Práhové hodnoty důvěry. Někdy klasifikátor není jistý ohledně úrovně. V těchto případech je směrování nahoru obvykle bezpečnější volbou. Špatné degradování může vést k špatnému dotazu a spouštění opakovaných pokusů, což často stojí více než použití silnějšího modelu na prvním místě. 

Validační vrstva běží po spuštění kódu. Jejím úkolem je chytit chyby směrování předtím, než se dostanou k uživateli. Po spuštění se kontroluje, zda je syntaxe správná, zda výsledky jsou rozumné (získal dotaz správné tvary řádků?), a zda schéma je konzistentní. Když výsledek selže validaci, systém se přesune na vyšší úroveň a spustí dotaz znovu.

V Devartu byla nejdůležitější věcí pro dosažení přesnosti směrování dbForge AI Assistant výstavba povědomí o schématu do klasifikační rozhodnutí. Bez kontextu schématu byly dotazy, které používaly nejasné názvy tabulek nebo spoléhaly na implicitní vztahy, vždy špatně klasifikovány a směrovány do levnějších modelů, které je nemohly zpracovat. Řešením bylo poskytnout klasifikátorovi nejen strukturu dotazu, ale také一些 metadata schématu.

Měření toho, co záleží: nákladové kvalitativní kompromisy v praxi

Obchodní případ pro směrování platí pouze tehdy, pokud kvalita drží spolu s ním. Snížení nákladů, které způsobí zhoršení výstupu, zvýšené opakované pokusy nebo nedůvěru vývojářů, není úspora, je to přenos nákladů z účtu infrastruktury na čas inženýrů. Tři metriky určují, zda systém směrování skutečně funguje.

Náklad na dotaz podle úrovně stanoví základnu. Sledujte skutečné výdaje v každé úrovni zvlášť, ne jako průměrnou směs. Směsování zakrývá, zda směrování funguje, systém, který směruje 50 % dotazů do špatné úrovně, bude stále ukazovat nižší průměrné náklady, zatímco potichu produkuje horší výsledky. 

Kvalitativní skóre kontroluje správnost, úplnost a dodržování nejlepších praktik SQL. Míra eskalace je nejřímějším signálem. Říká, jak často model úrovně 1 nebo 2 produkuje výstup, který neprochází validací a potřebuje být směrován na jiné místo. Systém, který je dobře naladěn, by měl udržet eskalaci pod 5 %. Klasifikátor potřebuje být přeškoleno nad touto úrovní. Může špatně číst strukturní signály nebo nemusí mít kontext schématu, aby rozlišoval mezi středními a složitými. 

Dopad latence sleduje, jak dlouho trvá, než odpověď projde z jedné úrovně do druhé, včetně jakéhokoli dodatečného času potřebného pro klasifikaci. Uživatelé by měli zaznamenat zpoždění pouze 50 až 100 milisekund v interakcích, které procházejí vrstvou směrování. Pokud se sama klasifikace stane problémem, hybridní přístup (pravidla pro jasný případ, klasifikátor pouze pro nejasný) to opraví bez ztráty přesnosti. 

V reálném životě může dobře naladěný systém směrování snížit náklady na inference o 40–60%, udržet eskalaci pod 5 % a udržet kvalitu výstupu vysokou pro složitý dotaz. Ušetřit 70 % nebo více obvykle vyžaduje, abyste úkoly úrovně 1 provedli sami s menšími modely. To může fungovat, ale také to činí věci složitějšími, s čímž ne každý tým chce pracovat.

“Daň z eskalace” je další věc, která musí být sledována. Pokud je směrování příliš tvrdé na levnější modely, systém může muset udělat více práce celkově: volání klasifikátoru, počáteční volání modelu, selhaná validace, přesměrování a druhé volání modelu. V některých případech to stojí více než směrování dotazu na model Frontier na prvním místě.

Sledování pouze nákladů na volání chybí tento efekt. Míra eskalace musí být sledována spolu s ním.

Strategické závěry pro inženýrské týmy

Chytré směrování není pouze hezkou věcí pro zavedené nasazení AI SQL; je to nutnost pro dlouhodobé nasazení. Týmy, které to přeskočí, vymění problém rozpočtu, který nelze vyřešit, za architektonický problém, který lze vyřešit. Vzorce jsou tam; zbývá pouze rozhodnout, které z nich následovat první.

Začněte s klasifikátorem, ne s modely. Vrstva směrování rozhoduje, zda všechno ostatní funguje. Dobře naladěný hybridní klasifikátor vám poskytne většinu úspor nákladů bez zbytečného komplikování.

Použijte kontext schématu zdroje, aby vám pomohl při rozhodování o klasifikaci. Pro SQL zátěže, které zahrnují vztahy mezi několika tabulkami nebo myšlení specifické pro schéma, struktura dotazu sama o sobě nestačí. Částečná metadata schématu v době klasifikace výrazně zvyšuje přesnost úrovně.

Použijte míru eskalace jako primární signál kvality. Nachází špatnou klasifikaci rychleji než jakékoli jiné metriky a ukazuje přesně, kde klasifikátor potřebuje zlepšení.

Před klasifikátorem naplánujte validační vrstvu. Vědět, co vypadá selhání a co způsobuje eskalaci, činí logiku směrování čistější a systém lépe vybavený pro zpracování hraničních případů.

Hodnota vrstvy směrování roste, ne klesá, jak se modely open-source zlepšují a náklady na lokální inference klesají. Levnější modely úrovně 1 činí rozdíl mezi úrovněmi větší, což činí správnou klasifikaci cennější. Architektura směrování, která je postavena dnes, bude užitečná po dlouhou dobu, nejen jako rychlé řešení.