Inteligentne routowanie zapytań dla asystentów SQL AI: jak obniżyć koszty bez poświęcania jakości

Wyobraź sobie, że twój asystent SQL to rakieta, która przelatuje przez złożone zapytania. Potem jeden dzień zdajesz sobie sprawę, że używasz paliwa rakietowego, aby pobrać listę zakupów.

To jest ekscytujące, dopóki nie przychodzi rachunek za paliwo. Nagle staje się jasne, że proste errandy nie potrzebują rakiety. To samo dzieje się, gdy każde żądanie SQL, od podstawowego wyszukiwania do analizy wieloschematowej, jest kierowane do tego samego potężnego modelu AI.

Proces uzyskania asystenta SQL AI jest zwykle taki sam. Na początku produktywność rośnie: zapytania są wykonywane szybciej, kod boilerplate znika, a deweloperzy spędzają mniej czasu na pisaniu rutynowych zapytań SQL. Gdy więcej zespołów używa go, liczba zapytań rośnie. Gdy przychodzi rachunek za infrastrukturę, zmienia się ekonomia.

Problem polega na budynku. Koszt uruchomienia modeli AI Frontier, które mogą myśleć o planach wykonania, schematach i złożonej logice zapytań, jest duży. Ta cena ma sens dla trudnych zadań, ponieważ kosztuje około 0,03 USD za zapytanie. Gdy używane są dla prostych instrukcji SELECT i operacji CRUD, staje się to marnotrawstwem w skali.

Ale odpowiedź nie polega na obniżeniu modelu. Chodzi o kierowanie zapytań do odpowiedniego miejsca. Inteligentne routowanie zapytań klasyfikuje każde żądanie według jego trudności i kieruje je do odpowiedniego poziomu modelu. Ta metoda może obniżyć koszty inferencji o 40-70% w obciążeniach SQL bez obniżania jakości wyjścia.

Artykuł ten wyjaśnia, jak działa ta architektura: definiowanie poziomów złożoności SQL, tworzenie potoków klasyfikacji i routingu, oraz mierzenie rzeczywistych wymian między kosztami a jakością, gdy system jest uruchomiony. Te wzorce odzwierciedlają nauki zdobyte podczas rozwijania świadomości schematu AI w dbForge AI Assistant.

Dlaczego jeden model nie pasuje do wszystkich zadań SQL

Nie wszystkie zapytania SQL są takie same pod względem złożoności. Zapytanie, które pobiera użytkownika według klucza podstawowego, i zapytanie, które odbudowuje kanały sesji w kilku schematach z funkcjami okien, są oba zapytaniami SQL, ale rozumowanie potrzebne do ich wygenerowania jest bardzo różne.

Jeśli system traktuje je tak samo, wynik jest przewidywalny: zmarnowany komput. W większości obciążeń przedsiębiorstw większość zapytań jest rutynowa. Proste wyszukiwania, odczyty z jednej tabeli, podstawowe wstawiania, naprawy składni. Nic skomplikowanego. Wysyłanie wszystkich tych do modelu Frontier jest jak używanie windy towarowej, aby przenieść notes.

Jednym ze sposobów myślenia o tym problemie jest podział zapytań na poziomy złożoności:

Przerwa między poziomami jest duża. Zapytanie Poziomu 1 może kosztować około 0,001 USD na lekkim modelu. To samo zapytanie wysłane do modelu Frontier kosztuje bliżej 0,03 USD. Przy 10 000 zapytaniach dziennie to 10 USD wobec 300 USD dziennie. Różnica 30-krotna, tylko z powodu decyzji dotyczących routingu.

Świadomość schematu również ma tu znaczenie. Zapytania Poziomu 3 nie potrzebują tylko więcej obliczeń. Potrzebują kontekstu: relacji między tabelami, kluczy obcych, indeksów, składni specyficznej dla bazy danych. Ten kontekst musi być wstrzyknięty podczas inferencji.

Uruchomienie prostego zapytania Poziomu 1 przez tę samą ciężką ścieżkę marnuje tokeny, dodaje opóźnienia i nie poprawia wyniku.

Praktyczna architektura wyboru modelu

System routingu zwykle składa się z czterech etapów: klasyfikacja, routing, wykonanie i walidacja. Każdy etap ma inne zadanie i może awaryjnie działać na różne sposoby. Pomaga myśleć o nich oddzielnie, zanim złoży się cały potok.

Klasyfikacja jest najważniejszym krokiem. Klasyfikator otrzymuje albo surowe zapytanie SQL, albo naturalny język, który wygeneruje je, i przypisuje je do poziomu złożoności. Istnieją trzy powszechne sposoby budowy tego klasyfikatora.

Klasyfikacja oparta na regułach polega na wzorcach regex i parsowaniu drzewa składni abstrakcyjnej, aby wykryć sygnały strukturalne: takie jak liczba tabel, głębokość zagnieżdżania, funkcje okien, podzapytania lub operatory agregacji. Ten podejście jest szybkie i przewidywalne, z prawie żadnym nakładem. Działa dobrze w przypadku oczywistych przypadków: proste instrukcje SELECT i podstawowe operacje DML mogą zwykle być identyfikowane bez angażowania modelu w ogóle.

Modele klasyfikatora o niskich kosztach używają małego modelu językowego, który jest szkolony, aby oszacować złożoność SQL. To dodaje dodatkowy krok, ale jest to jedna z najwyższych decyzji ROI w całym potoku. Wywołanie klasyfikatora może kosztować około 0,0001 USD, co łatwo uzasadnia unikanie wywołania modelu Frontier o wartości 0,03 USD.

W wielu konfiguracjach te modele o niskich kosztach mogą również działać lokalnie, skutecznie usuwając koszty dla prostych zapytań użytkowników w ogóle. Mogą one również klasyfikować naturalne języki przed wygenerowaniem SQL, co jest przydatne w przepływach pracy asystenta, w których zapytanie jeszcze nie istnieje.

Klasyfikacja hybrydowa łączy oba podejścia. Logika oparta na regułach obsługuje wyraźne przypadki przy zerowym koszcie, podczas gdy klasyfikator obsługuje niejasne przypadki pośrednie: zapytania, które wyglądają na umiarkowane, ale mogą wymagać świadomości schematu, aby je wygenerować poprawnie.

Routing następuje po klasyfikacji. Ale sam poziom nie jest jedynym czynnikiem. Kilka innych rzeczy wpływa na to, gdzie zapytanie powinno się znaleźć. Obejmują one:

1. Wymagania kontekstu schematu. Niektóre zapytania potrzebują, aby model zrozumiał relacje między tabelami, indeksy lub inne szczegóły strukturalne. Te zapytania przenoszą więcej kontekstu i zwykle muszą być kierowane do modelu o wyższych możliwościach.
2. Tolerancja opóźnienia. Funkcje użytkowników, takie jak autouzupełnianie lub sugestie w linii, mają ścisłe budżety opóźnienia. Zadania w tle zwykle nie. W tych przypadkach wolniejszy, ale bardziej zdolny model może być akceptowalny.
3. Progi ufności. Czasami klasyfikator nie jest pewny poziomu. W takich przypadkach routing w górę jest zwykle bezpieczniejszą opcją. Złe obniżenie może spowodować wygenerowanie złego zapytania i wywołać ponowne próby, co często kosztuje więcej niż użycie silniejszego modelu od razu.

Warstwa walidacji działa po uruchomieniu kodu. Jego zadaniem jest złapanie błędów routingu przed ich dotarciem do użytkownika. Po wykonaniu sprawdzane jest, czy składnia jest poprawna, czy wyniki są rozsądne (czy zapytanie zwróciło odpowiednie kształty wierszy?), i czy schemat jest spójny. Gdy wynik nie przechodzi walidacji, system przechodzi na wyższy poziom i ponownie uruchamia zapytanie.

W Devart najważniejszą rzeczą dla uzyskania dokładności routingu w dbForge AI Assistant było wprowadzenie świadomości schematu do decyzji klasyfikacji. Bez kontekstu schematu zapytania, które używały niejasnych nazw tabel lub polegały na niejawnych relacjach, były zawsze błędnie sklasyfikowane i kierowane do tańszych modeli, które nie mogły ich obsłużyć. Rozwiązaniem było dostarczenie klasyfikatorowi nie tylko struktury zapytania, ale także niektórych metadanych schematu.

Mierzenie tego, co się liczy: wymiany między kosztami a jakością w praktyce

Przypadek biznesowy dla routingu obowiązuje tylko wtedy, gdy jakość jest zachowana. Redukcja kosztów, która powoduje obniżoną jakość wyjścia, zwiększone ponowne próby lub brak zaufania deweloperów, nie jest oszczędnością, ale przeniesieniem kosztów z rachunku za infrastrukturę na czas inżynierów. Trzy metryki określają, czy system routingu działa naprawdę.

Koszt na zapytanie według poziomu ustala podstawę. Śledź rzeczywiste wydatki na każdy poziom oddzielnie, a nie jako średnią ważoną. Średnia ważona zaciemnia, czy routing działa, system, który kieruje 50% zapytań do niewłaściwego poziomu, nadal wykaże niższy średni koszt, podczas gdy cicho produkując gorsze wyniki.

Wynik jakości sprawdza poprawność, kompletność i przestrzeganie najlepszych praktyk SQL. Stawka eskalacji jest najbardziej bezpośrednim sygnałem. Mówi, jak często model Poziomu 1 lub Poziomu 2 produkuje wynik, który nie przechodzi walidacji i wymaga wysłania do innego miejsca. Dobrze dostrojony system powinien utrzymać eskalację poniżej 5%. Klasyfikator wymaga ponownego szkolenia powyżej tego poziomu. Może źle odczytywać sygnały strukturalne lub może nie mieć kontekstu schematu, aby odróżnić poziom umiarkowany od złożonego.

Wpływ na opóźnienie sprawdza, jak długo trwa odpowiedź na przejście z jednego poziomu do następnego, w tym dodatkowy czas potrzebny do klasyfikacji. Użytkownicy powinni zauważyć tylko opóźnienie 50-100 milisekund w interakcjach, które przechodzą przez warstwę routingu. Jeśli sama klasyfikacja staje się problemem, podejście hybrydowe (reguły dla wyraźnych przypadków, klasyfikator tylko dla niejasnych) rozwiązuje to bez utraty dokładności.

W praktyce dobrze dostrojony system routingu może obniżyć koszty inferencji o 40-60%, utrzymać eskalację poniżej 5% i utrzymać wysoką jakość wyjścia dla złożonych zapytań. Aby zaoszczędzić 70% lub więcej, zwykle trzeba wykonywać zadania Poziomu 1 samodzielnie z mniejszymi modelami. To może działać, ale także komplikuje sprawy, z którymi nie każdy zespół chce się zmierzyć.

“Podatek eskalacyjny” to kolejna rzecz, którą trzeba rozważyć. Jeśli routing jest zbyt surowy dla tańszych modeli, system może musieć wykonać więcej pracy w ogóle: wywołanie klasyfikatora, initialne wywołanie modelu, nieudana walidacja, routing i drugie wywołanie modelu. W niektórych przypadkach to kosztuje więcej niż wysłanie pytania do modelu Frontier od razu.

Patrzenie tylko na koszt wywołania pomija ten efekt. Stawka eskalacji musi być śledzona obok niego.

Strategiczne wnioski dla zespołów inżynierskich

Inteligentne routowanie nie jest tylko miłym dodatkiem dla dojrzałych wdrożeń AI SQL; jest to must-have dla długoterminowych. Zespoły, które pomijają je, wymieniają problem budżetowy, który nie może być rozwiązany, na problem architektury, który może być. Wzorce są tam; jedyną rzeczą, która pozostaje, jest decyzja, które z nich należy najpierw postępować.

Zacznij od klasyfikatora, a nie modeli. Warstwa routingu decyduje, czy wszystko inne działa. Dobrze dostrojony klasyfikator hybrydowy da ci większość oszczędności kosztów bez komplikowania spraw.

Użyj kontekstu schematu zasilania, aby pomóc w podejmowaniu decyzji klasyfikacji. Dla obciążeń SQL, które obejmują relacje między wieloma tabelami lub rozumowanie specyficzne dla schematu, struktura zapytania sama w sobie nie jest wystarczająca. Częściowe metadane schematu w czasie klasyfikacji znacznie zwiększają dokładność poziomu.

Użyj stawki eskalacji jako głównego sygnału jakości. Znajduje błędy klasyfikacji szybciej niż jakakolwiek inna metryka i pokazuje dokładnie, gdzie klasyfikator potrzebuje się poprawić.

Przed klasyfikatorem zaplanuj warstwę walidacji. Wiedza o tym, jak wygląda awaria i co powoduje eskalację, czyni logikę routingu czystszą i system lepiej zdolnym do radzenia sobie z przypadkami brzegowymi.

Wartość warstwy routingu wzrasta w górę, a nie w dół, gdy modele open-source stają się lepsze, a koszt inferencji lokalnej spada. Tańsze modele Poziomu 1 powodują, że różnica kosztów między poziomami staje się większa, co sprawia, że poprawna klasyfikacja staje się jeszcze bardziej wartościowa. Architektura routingu zbudowana dzisiaj będzie przydatna przez długi czas, a nie tylko jako szybkie rozwiązanie.