Rozmowa z danymi firmy – dlaczego text-to-SQL daje ładne i błędne odpowiedzi

Rozdźwięk między pokazem a produkcją ma twarde potwierdzenie w benchmarkach. Na Spider 1.0 – akademickim zbiorze z czytelnymi schematami – agenty osiągają wyniki rzędu 91%. Ten sam agent na Spider 2.0, zbiorze zbudowanym z realnych korporacyjnych przepływów pracy, spada do 21,3%. To nie jest różnica w jakości modelu; to różnica w tym, jak wygląda schemat, na którym pracuje.

Realna hurtownia w średniej firmie ma kilkaset tabel, w nich kolumny nazwane skrótami z lat dziewięćdziesiątych, kolumny techniczne obok biznesowych, pola wypełniane różnie w zależności od tego, kto wprowadzał rekord, i kilka pokoleń rozwiązań, których nikt nie usunął, bo „coś z tego jeszcze korzysta”. Model dostaje to wszystko naraz i musi zgadnąć, które pole odpowiada pojęciu, o które pyta człowiek.

Do tego dochodzi problem złączeń. Pytanie „ile sprzedaliśmy w zeszłym kwartale klientom z segmentu premium” w dobrze zamodelowanej hurtowni wymaga jednego złączenia. W hurtowni, która rosła organicznie, wymaga sześciu – i każde z nich jest miejscem, w którym można stracić lub zdublować rekordy. Benchmark dbt pokazał to wprost: część pytań była poza zasięgiem jednego podejścia właśnie dlatego, że wymagała zbyt wielu przeskoków między tabelami.

Wniosek jest niewygodny dla sprzedawców narzędzi, ale prosty dla planowania: skuteczność analityki konwersacyjnej w Waszej firmie zależy głównie od stanu Waszego modelu danych, a nie od tego, który silnik wybierzecie.

Według analizy Omni 81,2% błędów text-to-SQL powstaje na poziomie schematu lub semantyki, a nie składni. To rozróżnienie jest kluczowe operacyjnie: błąd składni kończy się komunikatem, którego nie da się przeoczyć. Błąd semantyczny kończy się liczbą.

Najczęstszy przykład z polskich firm: „jaki mieliśmy przychód w czerwcu”. W hurtowni bywają trzy odpowiedzi – wartość netto z faktur wystawionych w czerwcu, wartość zamówień zrealizowanych w czerwcu i wartość rozpoznana księgowo w czerwcu. Każda jest poprawna z perspektywy innego działu i każda daje inną liczbę. Model wybiera pierwsze pole, które wygląda właściwie, i podaje wynik bez zastrzeżenia.

Druga rodzina pomyłek dotyczy filtrów, których nikt nie wypowiada, bo są oczywiste dla ludzi w firmie: że nie liczymy dokumentów anulowanych, że spółka zależna ma osobny raport, że korekty wchodzą do miesiąca faktury pierwotnej. Te reguły żyją w głowach czterech osób i w kodzie kilku raportów, ale nie ma ich w schemacie – więc model ich nie zastosuje.

Trzecia rodzina to jednostki i waluty. Kolumna z ceną bez informacji, czy jest netto czy brutto, w jakiej walucie i po jakim kursie przeliczana, jest dla modelu po prostu liczbą. Odpowiedź będzie zawierała sumę, która wygląda dokładnie tak, jak powinna wyglądać – i będzie zła.

Warstwa semantyczna to zbiór definicji położony między bazą a pytającym: lista wskaźników z jednoznacznym sposobem liczenia, wymiary, po których wolno je ciąć, relacje między encjami i opisy w języku, którym mówi firma. Model nie pisze wtedy zapytania od zera – wybiera z gotowego, zamkniętego zbioru pojęć.

Efekt widać w liczbach. W benchmarku dbt Labs z 2026 r. ugruntowanie w warstwie semantycznej podniosło dokładność z 90,0% do 98,2% dla Claude Sonnet 4.6 i z 84,1% do 100% dla GPT-5.3-Codex. Warto przy tym znać skalę tego pomiaru: to jedenaście pytań uruchomionych po dwadzieścia razy na jednym zbiorze ubezpieczeniowym. To jest silny sygnał kierunku, nie dowód uniwersalnej skuteczności – i dokładnie dlatego warto zmierzyć to samo na własnych danych.

Znacznie ciekawszy jest inny wynik z tego samego badania. Zanim do zbioru dodano modele danych, oba podejścia radziły sobie przeciętnie: 64,5% dla text-to-SQL i 72,7% dla warstwy semantycznej. Dodanie zaledwie trzech modeli podniosło wyniki obu podejść skokowo. To najmocniejszy argument w całej dyskusji: praca, która realnie poprawia jakość odpowiedzi, to modelowanie danych, a nie wybór narzędzia.

Warstwa semantyczna ma jeszcze jedną zaletę, o której rzadko się mówi w kontekście AI: wymusza rozstrzygnięcie sporów definicyjnych. Żeby ją zbudować, ktoś musi zdecydować, czym jest przychód. To bywa najtrudniejsza część projektu i jednocześnie ta, która daje wartość niezależnie od tego, czy ktokolwiek zada pytanie modelowi.

W ekosystemie Microsoftu nie trzeba budować warstwy semantycznej od zera – ona już tam jest i nazywa się modelem semantycznym. Miary zdefiniowane w DAX są dokładnie tym, czym w innych stosach są definicje wskaźników: jednym obowiązującym sposobem policzenia przychodu, marży czy rotacji.

Różnica między firmą, w której Copilot w Power BI działa dobrze, a firmą, w której odpowiada bez sensu, sprowadza się zwykle do trzech rzeczy. Pierwsza: czy liczby są liczone miarami, czy doraźnie w wizualizacjach. Druga: czy tabele, kolumny i miary mają wypełnione opisy, i czy te opisy są napisane językiem biznesu, a nie skrótami z bazy. Trzecia: czy model zawiera synonimy – to, że dział handlowy mówi „obrót”, a zarząd „sprzedaż”, musi być gdzieś zapisane.

Praktyczna kolejność prac wygląda więc inaczej, niż zakłada większość projektów. Najpierw przegląd modelu semantycznego i uzupełnienie opisów dla obszaru, w którym chcecie zacząć – zwykle sprzedaż albo finanse. Potem lista dwudziestu pytań, które ludzie faktycznie zadają. Dopiero na końcu włączenie asystenta. Odwrotna kolejność kończy się wnioskiem „Copilot nie działa”, podczas gdy nie działa opis modelu.

Warto też ograniczyć obszar startowy. Asystent nad jednym dobrze opisanym obszarem odpowiada wiarygodnie; ten sam asystent nad wszystkimi modelami w organizacji ma do wyboru kilkanaście tabel o podobnych nazwach i zaczyna zgadywać.

Analityka konwersacyjna wymaga tego samego rygoru co każdy inny komponent AI w produkcji: zestawu pytań z oczekiwanymi odpowiedziami i regularnego uruchamiania go po każdej zmianie.

Zestaw buduje się z historii, nie z wyobraźni. Weźcie dwadzieścia do pięćdziesięciu pytań, które w ostatnim kwartale trafiły do analityków mailem albo na komunikatorze, i ustalcie dla każdego prawidłową odpowiedź – tę, którą podpisze właściciel obszaru. To jest jednocześnie test jakości i lista definicji do uzupełnienia w modelu.

Mierzcie dwie rzeczy osobno. Pierwsza: czy liczba się zgadza. Druga, ważniejsza: czy przy pytaniu niejednoznacznym system dopytał, zamiast zgadnąć. Asystent, który na pytanie o przychód odpowiada pytaniem „czy chodzi o wartość zafakturowaną, czy zrealizowane zamówienia”, jest wart więcej niż asystent z wyższą surową skutecznością, który nigdy nie sygnalizuje wątpliwości.

Test powtarzajcie po każdej zmianie modelu danych i po każdej zmianie wersji silnika. To ten sam mechanizm, który opisujemy przy ewaluacji agentów – i w analityce jest szczególnie istotny, bo zmiana w modelu semantycznym potrafi zmienić odpowiedzi na pytania pozornie z nią niezwiązane.