Sprawdzaj, nie zgaduj: dlaczego asystent AI do SQL powinien czytać prawdziwy schemat, a nie go zmyślać

Poproś model językowy o zapytanie do „tabeli zamówień”, a chętnie je napisze — z kolumną order_date, kluczem obcym do customers i statusem 'completed'. Pewnie, sensownie i całkiem prawdopodobnie błędnie. Twoja tabela może nazywać tę kolumnę created_at, klucz obcy może wskazywać na accounts, a enum statusu może używać 3 zamiast słowa.

To jest sedno problemu z używaniem AI do pisania SQL: model, który nie widział Twojej bazy, zgaduje jej strukturę. Czasem trafia. Gdy nie trafi, dostajesz zapytanie, które wygląda poprawnie, wykonuje się bez protestu w wyobraźni modelu, a na Twojej prawdziwej bazie zawodzi — albo, co gorsza, po cichu zwraca złe wiersze.

Lekarstwem jest zasada warta nazwania: sprawdzaj, nie zgaduj. Asystent AI do SQL powinien opierać odpowiedzi na Twoim rzeczywistym schemacie, prawdziwych wartościach i planach zapytań — a nie na tym, jak tabela „prawdopodobnie” wygląda.

Ujawnienie: pracuję nad SQL Sage, którego użyję dalej jako konkretnego przykładu. Zasada poniżej obowiązuje niezależnie od tego, jakiego narzędzia używasz.

Dlaczego LLM-y zmyślają nazwy tabel i kolumn?

Bo model językowy generuje tekst, przewidując to, co statystycznie prawdopodobne, a nie sprawdzając cokolwiek w źródle. Gdy prosisz go o SQL, sięga po wzorce z ogromnej ilości kodu, na którym był trenowany. W tych danych tabela zamówień bardzo często ma kolumnę order_date, więc model przewiduje order_date. To rozsądne założenie wstępne. To nie jest fakt o Twojej bazie.

Model nie ma połączenia z Twoim schematem, dopóki ktoś mu go nie da. Zostawiony sam sobie, wypełnia luki najczęstszym wzorcem, jaki widział. Branżowy termin na to zjawisko to halucynacja: model produkuje wynik, który jest płynny i pewny siebie, ale nieoparty na żadnym rzeczywistym źródle. W prozie halucynacja to kompromitujący błędny fakt. W SQL to zapytanie, które odwołuje się do nieistniejącej kolumny, łączy po złym kluczu albo zakłada typ danych, którego Twoja kolumna nie ma.

Ta usterka jest szczególnie podstępna, bo halucynacje w SQL są wiarygodne. Model nie wymyśla bzdur — wymyśla coś, co byłoby sensowne w generycznej bazie. To sprawia, że błędy trudno wyłapać okiem, bo wyglądają dokładnie jak poprawny SQL dla jakiejś bazy, tyle że nie Twojej.

Co znaczy „ugruntować” (ground) LLM w schemacie bazy?

Grounding to podanie modelowi prawdziwych faktów, zanim odpowie, tak aby jego wynik był ograniczony Twoją bazą, a nie statystycznym zgadywaniem.

Dla SQL liczą się następujące fakty:

• Schemat — rzeczywiste nazwy tabel, nazwy kolumn, typy danych, klucze i relacje, odczytane z działającej bazy.
• Prawdziwe wartości tam, gdzie mają znaczenie — na przykład rzeczywiste wartości, jakie przyjmuje kolumna statusu, żeby model napisał WHERE status = 'shipped' tylko wtedy, gdy 'shipped' istnieje.
• Plany zapytań — jak baza deklaruje, że wykona zapytanie, co ujawnia, czy złączenie lub filtr zachowują się tak, jak model założył.

Gdy model ma te fakty, nie przewiduje już Twojego schematu — czyta go. Różnica widać od razu. Ugruntowany asystent pisze created_at, bo Twoja kolumna nazywa się created_at, a nie dlatego, że order_date to częsta nazwa. Łączy po kluczu, który naprawdę istnieje. Używa wartości enuma, które naprawdę są w danych. Zgadywanie zastępuje odczyt.

To ta sama idea co retrieval-augmented generation (RAG) w innych dziedzinach: nie każ modelowi przypominać sobie faktu, którego może nie mieć — podaj mu fakt i każ rozumować. Dla baz danych „retrieval” to introspekcja działającego schematu oraz, gdy trzeba, rzeczywisty rozkład wartości i plan wykonania.

Dlaczego grounding daje poprawniejszy SQL?

Bo większość błędów SQL od AI to nie błędy logiki — to błędy odwołań. Model zrozumiał, o co Ci chodzi; po prostu zaadresował to do złych nazw. Daj mu właściwe nazwy, a cała klasa pomyłek znika.

Grounding pomaga na trzech poziomach:

1. Identyfikatory. Poprawne nazwy tabel i kolumn, zapisane i z wielkością liter tak, jak istnieją, sprawiają, że zapytanie odwołuje się do rzeczy, które naprawdę tam są.
2. Typy i wartości. Wiedza, że kolumna to enum typu integer, a nie tekstowy status, zmienia klauzulę WHERE, którą pisze model. Znajomość rzeczywistego zbioru wartości zapobiega filtrowaniu po ciągu, który nigdy nie występuje.
3. Zachowanie. Plan zapytania ujawnia, czy złączenie rozmnaża wiersze, czy używany jest indeks, czy filtr działa tam, gdzie myślisz. Model potrafi odczytać plan i poprawić zapytanie, które jest składniowo dobre, ale semantycznie błędne.

Nic z tego nie czyni modelu nieomylnym — nadal powinieneś czytać to, co produkuje. Ale przesuwa to asystenta z „pewnego siebie zgadywania” do „sprawdzania z rzeczywistością”, a to różnica między SQL-em, który musisz weryfikować od zera, a SQL-em, któremu ufasz na tyle, by szybko go przejrzeć.

Jak poznać, czy asystent AI zgaduje, czy sprawdza?

Nie zawsze zajrzysz do środka narzędzia, ale możesz zadać celne pytania i obserwować zachowanie:

• Czy łączy się z Twoją prawdziwą bazą, czy to tylko okno czatu? Jeśli narzędzie nigdy nie czyta Twojego schematu, z definicji zgaduje. Nie ma innego źródła, z którego mogłoby korzystać.
• Czy używa Twoich prawdziwych nazw tabel i kolumn, czy generycznych? Wklej prośbę o tabelę o nietypowej nazwie. Ugruntowany asystent użyje Twojej nazwy; zgadujący sięgnie po podręcznikowy domyślnik.
• Czy zna Twoje wartości enumów i statusów? Poproś o filtr po kolumnie statusu. Jeśli wymyśli 'active', gdy w danych jest 'A', nie sprawdził.
• Czy potrafi rozumować o planie zapytania? Asystent, który umie odczytać, jak baza wykona zapytanie, pracuje na faktach, nie na wzorcach.
• Co dokładnie wysyła do modelu? Dobrze zaprojektowane narzędzie jasno mówi, że wysyła schemat i SQL, a dane z wierszy traktuje jako świadomą zgodę (opt-in), nie cichy domyślnik. Ta granica — co powinno, a co nie, trafiać do modelu — to znak, że narzędzie przemyślało, skąd bierze fakty.

SQL Sage jest zbudowany wokół zasady „sprawdzaj, nie zgaduj”. Czyta prawdziwy schemat, prawdziwe wartości i plany zapytań z Twojej bazy i na nich opiera odpowiedzi, zamiast zakładać strukturę. Działa jako dodatek do SSMS i wtyczka do DBeavera (wtyczka do DBeavera jest tylko dla Windows i obsługuje PostgreSQL, MySQL, MariaDB, Oracle, SQL Server i SQLite). Do modelu wysyła schemat i SQL — nigdy Twoich wierszy, chyba że wyrazisz na to zgodę — domyślnie pozostaje w trybie tylko do odczytu i jest bezkluczowy: rozmawia z Twoim własnym kontem Claude lub ChatGPT, bez dostawcy na ścieżce danych.

Wniosek

Asystent AI do SQL jest tak dobry, jak to, co wie o Twojej bazie. Sam model nie wie o Twojej nic — zna średnią ze wszystkich baz, na których był trenowany, i właśnie dlatego halucynuje nazwy tabel, które brzmią dobrze, a są błędne.

Zasada, która to naprawia, jest prosta: sprawdzaj, nie zgaduj. Ugruntuj model w prawdziwym schemacie, prawdziwych wartościach i prawdziwych planach zapytań. Gdy oceniasz narzędzie, to jest pytanie leżące pod wszystkimi innymi — czy ono czyta Twoją bazę, czy ją sobie wyobraża?