Pytania do danych firmy w języku naturalnym — dlaczego to działa na demie, a nie na Waszej bazie

Co właściwie obiecuje to wdrożenie

W firmie 10–100 osób wiedza o danych jest zwykle skupiona w jednej, maksymalnie dwóch osobach. Ktoś potrafi wyciągnąć sprzedaż z systemu ERP, ktoś inny wie, których faktur nie wliczać, i obie te osoby mają inne obowiązki. Skutek jest przewidywalny: pytania o dane trafiają do kolejki, a decyzje podejmuje się na pamięci — „wydaje mi się, że ten klient kupuje mniej niż rok temu”.

Obietnica jest więc konkretna i nie dotyczy wcale efektownych wykresów. Chodzi o skrócenie drogi od pytania do liczby z trzech dni do trzech minut, dla kilkunastu osób, które dziś tej drogi nie przechodzą wcale, bo nie warto zawracać komuś głowy.

Warto jednak od razu nazwać, czego to wdrożenie nie robi. Nie zastąpi analityka przy pytaniach, na które odpowiedź wymaga interpretacji. „Ile mamy otwartych zleceń” to pytanie o fakt zapisany w bazie. „Dlaczego marża spadła w sierpniu” to pytanie o hipotezę i model odpowie na nie równie chętnie, tylko że ta odpowiedź będzie zgadywaniem ubranym w liczby. Granica przebiega dokładnie tam: jedno pytanie ma w bazie jednoznaczną odpowiedź, drugie nie ma.

Skąd różnica między 80% na benchmarku a 40% u Was

Liczby z publikacji są dostępne i warto je znać, bo dostawcy cytują tylko te korzystne. Na benchmarku BIRD modele klasy GPT-4o osiągają około 82% trafności. Na benchmarku Spider 2.0, zbudowanym tak, aby przypominać prawdziwe hurtownie danych — średnio ponad pięćdziesiąt tabel i osiemset kolumn na bazę — te same metody spadają do około 63%. A benchmark BEAVER, zbudowany na rzeczywistych firmowych hurtowniach, pokazał, że modele „z półki” radzą sobie na nich po prostu słabo. W ocenach wdrożeń na realnych schematach pojawia się rząd 40%.

Przyczyna tego spadku nie leży w jakości modelu i to jest najważniejszy wniosek praktyczny. Leży w tym, że model dostaje schemat bazy, a potrzebuje wiedzy, której w schemacie nie ma.

Model nie wie, że kolumna `kwota` w jednej tabeli jest netto, a w drugiej brutto. Nie wie, że w Waszej firmie „klient aktywny” znaczy „kupił w ostatnich dwunastu miesiącach”, a nie „ma flagę aktywny ustawioną na prawdę”, bo tej flagi nikt nie aktualizuje od 2023 roku. Nie wie, że faktur korygujących nie wlicza się do sprzedaży w ten sam sposób, co w dziale controllingu. Nie wie, że tabela `zamowienia_archiwum` zawiera rekordy, które są też w `zamowienia`, i zsumuje jedno z drugim bez mrugnięcia okiem.

Nazwa tego problemu w literaturze to „metric drift”: to samo pytanie zwraca inną liczbę w zależności od tego, kto pyta. Tylko że u Was ten problem istnieje już dziś, przed jakimkolwiek AI — dwie osoby proszone o „sprzedaż za wrzesień” przynoszą dwie różne kwoty. AI tego nie powoduje. AI to ujawnia i zwielokrotnia.

Najgroźniejszy błąd nie wygląda jak błąd

To jest punkt, dla którego warto czytać dalej, nawet jeśli reszta brzmi technicznie. Większość systemów, które wdrażamy w firmach, zawodzi w sposób widoczny: formularz nie wysyła, integracja zwraca błąd, agent nie rozumie pytania. Zapytania generowane przez model zawodzą odwrotnie.

Zapytanie wychodzi składniowo poprawne, wykonuje się bez ostrzeżenia i zwraca liczbę. Liczba jest w sensownym rzędzie wielkości, bo pochodzi z Waszych danych. Jest tylko nie na to pytanie, które ktoś zadał — bo model wziął złą tabelę, pominął filtr na firmę, policzył podwójnie przez niewłaściwe złączenie albo zsumował brutto z netto. Nikt tego nie zauważy, dopóki ta liczba nie pojawi się w rozmowie z zarządem obok liczby z innego źródła.

W materiałach z 2026 roku ta różnica jest opisywana wprost: zapytania generowane bezpośrednio na schemacie zawodzą jako „pewna zła liczba”, a systemy oparte na warstwie semantycznej zawodzą jako odmowa odpowiedzi. Przy liczbie, która idzie do decyzji, do audytora albo do prezentacji, ten sposób zawodzenia jest ważniejszy niż sam procent trafności. Osiemdziesiąt procent trafności z widocznymi dwudziestoma procentami odmów to narzędzie użyteczne. Osiemdziesiąt procent z dwudziestoma procentami cichych pomyłek to narzędzie, które psuje zaufanie do wszystkich liczb w firmie, także tych poprawnych.

Praktyczny wniosek jest jeden i jest nienegocjowalny: system musi mieć prawo powiedzieć „nie wiem, jak to policzyć”. Jeśli dostawca chwali się, że jego narzędzie odpowiada na każde pytanie, to nie jest zaleta, tylko informacja o tym, jak będzie się mylić.

Warstwa semantyczna, czyli jedyna część, której nie da się kupić

Rozwiązanie jest znane i nudne: model nie powinien pisać zapytań na surowym schemacie. Powinien je pisać na zdefiniowanym słowniku miar i wymiarów — tam, gdzie „przychód”, „klient aktywny”, „marża” i „region” mają jedną, zapisaną definicję wraz z regułami złączeń i filtrów. To jest warstwa semantyczna i w praktyce to po prostu zestaw plików konfiguracyjnych albo widoków, które ktoś musi napisać.

Efekt jest mierzalny. W badaniu dbt Labs z kwietnia 2026 zakotwiczenie w warstwie semantycznej podniosło trafność Claude Sonnet 4.6 z 90,0% do 98,2%, a GPT-5.3-Codex z 84,1% do 100% w konfiguracji „modeled project”. Branżowe wdrożenia raportują wzrosty z poziomu niskiego do 85–95% i zamknięcie 8–16 punktów procentowych luki. Te liczby należy czytać ostrożnie, bo pochodzą od dostawców narzędzi, ale kierunek jest jednoznaczny i zgodny z mechanizmem: model przestaje zgadywać biznesowy sens kolumn, bo ktoś mu go zapisał.

I tu jest cała trudność tego wdrożenia. Model dostaniecie za kilkadziesiąt złotych miesięcznie. Definicji dwunastu najważniejszych miar w Waszej firmie nie kupicie od nikogo, bo nikt poza Wami ich nie zna — a często nie znacie ich i Wy, w tym sensie, że dwa działy liczą je inaczej i nigdy nie musiały się dogadać. Wdrożenie AI na danych wymusza tę rozmowę. To jest jego największy koszt i, zupełnie szczerze, najczęściej największa korzyść — niezależnie od tego, czy narzędzie potem zadziała.

Zakres startowy, który u większości firm wystarcza: od ośmiu do piętnastu miar. Nie więcej. Jeśli lista przekracza dwadzieścia pozycji w pierwszym podejściu, to znaczy, że mieszacie miary z pytaniami. „Przychód” jest miarą. „Przychód od nowych klientów w kanale online w drugim kwartale” jest pytaniem złożonym z jednej miary i trzech filtrów.

Trzy poziomy dostępu, które trzeba rozdzielić

Jak przy każdym wdrożeniu, które sięga do systemów, ryzyko rośnie nie z inteligencją modelu, a z zakresem jego uprawnień. Przy danych ta gradacja jest prosta i warto ją przejść w kolejności.

• Pytania do gotowych miar. Model nie pisze SQL-a — wybiera z listy zdefiniowanych miar, wymiarów i filtrów. Zakres odpowiedzi jest ograniczony do tego, co ktoś wcześniej zdefiniował, więc pytanie poza zakresem kończy się odmową, nie zgadywaniem. Najmniejsze ryzyko, najszybszy start i dla większości firm jedyny poziom, jaki jest naprawdę potrzebny.
• Generowanie zapytań na warstwie semantycznej. Model pisze SQL, ale wyłącznie na przygotowanych widokach z czytelnymi nazwami i wbudowanymi regułami, na koncie z prawem tylko do czytania. Dochodzą pytania nieprzewidziane, rośnie ryzyko cichej pomyłki — więc tu obowiązkowe jest pokazywanie użytkownikowi, jakie zapytanie powstało i na jakich danych.
• Dostęp do surowego schematu produkcyjnego. Pełna swoboda, pełne ryzyko: zła tabela, brak filtra na firmę, dane z archiwum doliczone do bieżących, obciążenie bazy produkcyjnej w środku dnia. Ten poziom ma sens dla analityka, który i tak sprawdzi wynik, i prawie nigdy dla reszty firmy.

Czego ten system nie powinien móc zrobić

Zasady techniczne są krótkie, ale pominięcie któregokolwiek punktu zamienia narzędzie raportowe w ryzyko operacyjne.

• Konto tylko do czytania, na replice. Nie na bazie produkcyjnej i nie z prawem zapisu — nigdy, bez wyjątków i bez „na razie, bo szybciej”. Pojedyncze nieoptymalne zapytanie wygenerowane na dużej tabeli potrafi położyć bazę, z której w tej chwili korzysta cała firma.
• Twardy limit czasu i wielkości wyniku. Zapytanie przerywane po kilku sekundach, wynik ograniczony do rozsądnej liczby wierszy. Model nie ma intuicji co do kosztu operacji, którą właśnie napisał.
• Filtry bezpieczeństwa na poziomie danych, nie promptu. Jeśli handlowiec ma widzieć tylko swoich klientów, to musi wynikać z uprawnień konta albo z reguły w warstwie danych. Instrukcja „nie pokazuj danych innych handlowców” wpisana do promptu nie jest zabezpieczeniem — jest sugestią.
• Widoczne zapytanie i widoczne źródło przy każdej odpowiedzi. Liczba bez informacji o tym, skąd się wzięła, jest nieweryfikowalna, a więc bezwartościowa w sporze. To jest też jedyny realny mechanizm, przez który ktokolwiek wychwyci cichą pomyłkę.
• Brak dostępu do danych wrażliwych, których pytanie nie dotyczy. Wynagrodzenia, dane kadrowe, dane zdrowotne — zakres dostępu zawężacie do tego, co jest potrzebne, a nie do tego, co jest podłączone. Obowiązki wokół powierzenia przetwarzania rozpisaliśmy w tekście o RODO przy wdrożeniu AI.

Jak to przetestować, zanim ktokolwiek w firmie to zobaczy

Jest jedna rzecz, która decyduje o tym, czy to wdrożenie się udaje, i prawie nikt jej nie robi: zbiór pytań z policzonymi wcześniej odpowiedziami. Nie demo, nie „zobaczmy, co powie” — lista pytań i liczb, które ktoś wyliczył ręcznie i których jest pewien.

Pięćdziesiąt pytań wystarczy i warto je dobrać celowo. Dwadzieścia prostych, na jednej miarze z jednym filtrem. Piętnaście wymagających złączenia dwóch obszarów — sprzedaż i zwroty, zlecenia i czas pracy. Dziesięć takich, w których kryje się pułapka, którą znacie: korekty, archiwum, podwójne rekordy, zmiana cennika w środku okresu. I pięć pytań, na które odpowiedzi w danych nie ma w ogóle — bo najważniejszy test to nie trafność, a to, czy system odmówi, czy coś wymyśli.

Ten zbiór uruchamiacie przy każdej zmianie konfiguracji, modelu i definicji miary. Bez niego każda zmiana jest zakładem, a po trzech miesiącach nikt nie wie, czy narzędzie działa lepiej, czy gorzej niż w dniu uruchomienia. Metodę budowania takich zestawów opisaliśmy szerzej w tekście o testowaniu wdrożenia AI.

Osobno sprawdźcie dwie rzeczy specyficzne dla danych. Pierwsza: to samo pytanie zadane dwa razy w trochę innych słowach — „sprzedaż we wrześniu” i „ile sprzedaliśmy w zeszłym miesiącu” — musi dać tę samą liczbę. Jeśli nie daje, warstwa semantyczna jest niepełna i rozjazd będzie rósł. Druga: pytanie zadane przez dwie osoby o różnych uprawnieniach musi zwrócić wyniki zgodne z ich zakresem dostępu, a nie ten sam wynik dla obu.

Rachunek i to, co w nim zwykle pomijane

Koszt modelu jest tu drugorzędny i to warto powiedzieć wprost, bo większość rozmów zaczyna się od cennika narzędzia. Kilkadziesiąt do kilkuset pytań dziennie to koszt rzędu kilkudziesięciu–kilkuset złotych miesięcznie. Licencja narzędzia, jeśli kupujecie gotowe, to zwykle rząd kilkuset złotych miesięcznie przy kilkunastu użytkownikach.

Realny koszt to praca nad definicjami i podłączeniem. Osiem do piętnastu miar ustalonych tak, że dwa działy się na nie zgadzają, replika bazy, konta z właściwymi uprawnieniami, zbiór testowy. Przy typowym firmowym bałaganie w danych to kilkadziesiąt godzin pracy kogoś, kto rozumie i bazę, i biznes — i to jest ta pozycja, która zwykle nie trafia do kosztorysu. Anatomię takiego budżetu rozpisaliśmy w tekście ile kosztuje wdrożenie AI. Jeśli dane są w stanie, który opisaliśmy w tekście o danych gotowych na AI, ta pozycja rośnie, a nie maleje.

Korzyść liczcie na jednej liczbie, nie na procentach z cudzych wdrożeń: ile pytań o dane zadano w firmie w ostatnim miesiącu i ile z nich dostało odpowiedź. Druga liczba jest zwykle zawstydzająco niska i to w niej leży cała wartość tego projektu. Jeśli dwanaście osób przestaje rezygnować z pytania, bo odpowiedź kosztuje trzy minuty zamiast trzech dni, zmienia się sposób podejmowania decyzji — i to jest efekt, którego żaden dashboard nie dał, bo dashboard odpowiada na pytania zadane rok temu.

Wdrożenie w pięć tygodni

Kolejność jest tu ważniejsza niż gdziekolwiek indziej, bo pierwszy tydzień decyduje o wszystkim, a jest najmniej efektowny.

1. Tydzień pierwszy: dwadzieścia pytań i dwanaście miar. Zbierzcie dwadzieścia pytań, które faktycznie padają w firmie — z maili, z rozmów, z proszenia o raporty. Z nich wyciągnijcie listę miar i wymiarów, których te pytania dotyczą. Każdą miarę zapiszcie jednym zdaniem i jedną regułą liczenia, zatwierdzoną przez osobę, która za ten obszar odpowiada.
2. Tydzień drugi: replika i widoki. Konto tylko do czytania na replice, czytelne widoki dla ustalonych miar, filtry uprawnień wbudowane w dane. Jednocześnie usuńcie z zakresu wszystko, czego nie zdefiniowaliście — tabele archiwalne, kolumny nieużywane, obszary wrażliwe. Model widzi tylko to, co opisane.
3. Tydzień trzeci: zbiór testowy pięćdziesięciu pytań z ręcznie policzonymi odpowiedziami, w tym pięć bez odpowiedzi w danych. Uruchomienie, pomiar trafności i — osobno — pomiar odsetka odmów. Jeśli odmów jest zero, konfiguracja jest zła, nie dobra.
4. Tydzień czwarty: pilotaż na trzech osobach, zawsze z widocznym zapytaniem i źródłem przy każdej odpowiedzi. Każde pytanie, na które system odpowiedział źle albo odmówił, zapisywane. To jest Wasze główne źródło brakujących definicji.
5. Tydzień piąty: domknięcie luk z pilotażu i dopiero wtedy udostępnienie szerzej — z jedną jasno zakomunikowaną zasadą: liczba, która idzie na zewnątrz firmy albo do decyzji finansowej, jest sprawdzana u źródła. Dalej, raz w miesiącu: przegląd pytań odrzuconych i rozjazdów w definicjach, bo lista miar starzeje się razem z firmą — co opisaliśmy w tekście o utrzymaniu AI po wdrożeniu.

Cztery sygnały, że poszło w złą stronę

• System nigdy nie odmawia odpowiedzi. Oznacza to, że na pytania poza zakresem definicji zgaduje. Zero odmów przy swobodnych pytaniach do firmowej bazy jest statystycznie niemożliwe i jest najpoważniejszym z możliwych sygnałów ostrzegawczych.
• Dwie osoby dostają różne liczby na to samo pytanie. Nie jest to problem modelu, tylko dowód, że definicja miary nie istnieje albo jest niepełna. Naprawia się to w warstwie semantycznej, nie w promptach.
• Nikt nie patrzy na pokazywane zapytanie. Zaufanie wyprzedziło weryfikację i od tego momentu ciche pomyłki przechodzą w całości. Pomaga tu nie szkolenie, a prosta zasada: liczby idące do decyzji mają podany okres, filtr i źródło, inaczej nie są przyjmowane.
• Pytania w narzędziu zaczynają brzmieć „dlaczego” i „czy warto”. To już nie jest raportowanie, a model odpowie równie gładko. Granica jest przy pytaniach o fakty zapisane w danych — i trzeba ją powiedzieć zespołowi wprost, bo sama się nie narzuca.

Od czego zacząć

Jeden konkret na ten tydzień, bez narzędzia i bez budżetu: wypiszcie dwanaście najważniejszych miar w firmie i poproście dwie osoby z różnych działów, żeby niezależnie napisały, jak każdą z nich liczą. Godzina pracy, kartka papieru. Rozjazdy, które zobaczycie, są dokładnie tymi, które AI powieliłoby w setkach odpowiedzi — z tą różnicą, że tam byłyby niewidoczne. Jeśli ta lista zejdzie się bez sporu, jesteście gotowi na wdrożenie. Jeśli nie zejdzie się — właśnie znaleźliście problem wart więcej niż całe narzędzie.

Osobno warto wiedzieć, że samo podłączenie modelu do systemów jest dziś najmniej trudną częścią: standardy integracyjne opisaliśmy w tekście o MCP i integracji AI z systemami firmy, a ryzyka związane z dawaniem modelowi narzędzi — w tekście o atakach przez prompt injection. Trudna część zawsze zostaje po stronie definicji.

Budujemy takie wdrożenia jako wąskie i mierzalne: ustalone miary, replika z prawem tylko do czytania, jawne odmowy zamiast zgadywania, widoczne zapytanie przy każdej liczbie i zbiór testowy, który biegnie przy każdej zmianie. Jeśli w Waszej firmie pytanie o dane trwa trzy dni albo kończy się dwiema różnymi kwotami, umówcie bezpłatną konsultację albo zobaczcie, jak wygląda nasz konsulting i wdrożenia AI.