Databricks skúša LLM agentov na optimalizáciu poradia SQL joinov
Databricks a UPenn testovali agenta, ktorý mimo horúcej cesty query optimalizátora skúša rôzne poradia joinov a v experimentoch zlepšil latenciu oproti predvolenému optimalizátoru.
Pripravil HERMES. Výber tém pomáha robiť BuloSentinel. Redakčná kontrola: Marek Považský.
- Typ zdroja
- Kurátorovaný súhrn
- Zdroj / autorita
- Databricks Blog
Redakčný kontext
Tému vybral BuloSentinel ako súčasť monitorovania AI ekosystému. Text pripravil HERMES zo zdrojovo ukotvených podkladov a zodpovednú kontrolu pravidiel robí Marek Považský.
Článok je zaradený v sekcii AI výskum a opiera sa o 2 zdroje.
Databricks opisuje experiment, ktorý posúva LLM agentov do prekvapivo starej databázovej úlohy: výberu poradia joinov v SQL dotaze. Join ordering je klasický problém query optimalizátorov. Pri dotazoch s mnohými tabuľkami počet možných plánov rastie explozívne a zlý odhad veľkosti medzivýsledkov môže viesť k výrazne pomalšiemu plánu. Databricks spolu s výskumnou spoluprácou z University of Pennsylvania skúša, či agent s prístupom k meraniam behu vie fungovať ako automatizovaný databázový špecialista.
Dôležité je, že nejde o nahradenie optimalizátora v horúcej ceste. Query optimalizátor musí väčšinou rozhodnúť v zlomkoch sekundy, zatiaľ čo volanie veľkého modelu a testovanie viacerých plánov by bolo príliš pomalé. Databricks preto agentovi dáva rolu offline experimentátora. Agent môže navrhnúť poradie joinov, spustiť ho cez nástroj, dostať späť čas behu a veľkosť medzivýsledkov a počas viacerých iterácií skúšať ďalšie alternatívy. Výsledkom je najlepší nájdený plán, nie okamžitá odpoveď modelu.
Tento rozdiel je zásadný. Mnohé pokusy s LLM v databázach zlyhávajú, keď sa od modelu očakáva jednorazové rozhodnutie bez merania. Databricks využíva agenta ako niekoho, kto môže skúmať priestor riešení a učiť sa z reálnych výsledkov. Nástroj pritom núti model generovať štruktúrovaný výstup, ktorý zodpovedá platnému poradiu joinov. Tým sa znižuje riziko, že model navrhne syntakticky alebo logicky neplatný plán. Agent teda nerobí mágiu, ale riadenú sériu merateľných experimentov.
V testoch na Join Order Benchmarku firma uvádza, že agent s frontier modelom zlepšil geometrický priemer latencie približne 1,288-násobne a v 80 percentách prípadov našiel lepšie riešenie než predvolený optimalizátor. Najväčší efekt bol v chvoste rozdelenia, kde P90 latencia klesla o 41 percent. To je pre databázy dôležité, pretože používatelia často nevnímajú priemerný dotaz, ale najhoršie pomalé prípady, ktoré blokujú dashboardy, pipeline alebo interaktívnu analýzu.
Príklad z blogu ukazuje, prečo môže agent pomôcť. Tradičný optimalizátor sa pri niektorých dotazoch opiera o odhady kardinality, ktoré sú pri textových podmienkach alebo špecifických filtroch nepresné. Agent môže skúsiť plán, ktorý vyzerá menej intuitívne, ale v reálnom behu rýchlejšie zníži medzivýsledky. V istom zmysle automatizuje prácu skúseného DBA: spustiť alternatívu, pozrieť sa na výsledky, upraviť hypotézu a pokračovať. Rozdiel je v tom, že agent môže tento cyklus vykonať systematicky na mnohých dotazoch.
Databricks zároveň priznáva limity. Agent potrebuje časový rozpočet a jeho prínos dáva najväčší zmysel tam, kde sa dotaz opakuje alebo kde je optimalizácia drahá, ale oplatí sa. Nie je to nástroj pre každú ad hoc otázku. Otvorená zostáva aj otázka generalizácie: ak agent nájde lepší plán pre konkrétny dotaz, vie systém zistiť, či tým odhalil širšiu chybu v optimalizátore? Ak áno, LLM agent by nemusel iba zrýchľovať jednotlivé dotazy, ale pomáhať zlepšovať databázový engine.
Pre AI ekosystém je zaujímavé, že ide o agenta nad dátovou infraštruktúrou, nie o chatbota nad dokumentmi. Model tu neodpovedá používateľovi prirodzeným jazykom, ale plánuje experimenty, volá nástroj a optimalizuje merateľnú metriku. To je zdravší tvar agentickej AI: úloha má jasný cieľ, akcie sú ohraničené a výsledok možno objektívne porovnať. Podobné vzory môžu vzniknúť pri ladení konfigurácií, plánovaní zdrojov, testovaní indexov alebo vyhľadávaní výkonových regresií.
Z pohľadu zákazníkov Databricks zatiaľ nejde o bežnú produktovú funkciu, ale o výskumný a inžiniersky smer. Blog hovorí o prototype a experimentálnych benchmarkoch. To je dôležité, pretože databázové optimalizátory sú extrémne citlivé na spoľahlivosť a predvídateľnosť. Agent, ktorý občas nájde skvelý plán, ale inokedy minie veľa času alebo vyberie nestabilnú cestu, musí byť opatrne zasadený do workflow. Najpravdepodobnejšie použitie je preto poradné alebo offline ladenie, nie okamžité automatické prepísanie každého dotazu.
Význam experimentu je napriek tomu veľký. Ukazuje, že LLM agenti nemusia byť len vrstva nad používateľským rozhraním. Môžu sa stať nástrojmi pre samotnú infraštruktúru, ak dostanú bezpečné akcie, spätnú väzbu a merateľný cieľ. Databricks tým naznačuje budúcnosť, v ktorej dátové systémy používajú AI nie iba na generovanie SQL, ale aj na vlastnú optimalizáciu. Ak sa tento prístup podarí dostať z prototypu do spoľahlivých prevádzkových nástrojov, môže zmeniť spôsob, akým sa ladia analytické platformy.
Zdroje