Analityk i AI w 2026: fundamenty, które pomagają sprawdzić wynik

Czy w 2026 roku nadal warto uczyć się analizy danych, skoro AI potrafi napisać zapytanie i przygotować podsumowanie? Ja zacząłbym od innego, bardzo praktycznego sprawdzianu: czy potrafisz rozpoznać, że wynik jest błędny, mimo że kod się uruchomił i odpowiedź brzmi przekonująco? W codziennej analizie to pytanie szybko sprowadza rozmowę z prognoz rynku do konkretnej roboty.

Nie znam pewnej odpowiedzi na to, jak będzie wyglądać liczba stanowisk analitycznych za kilka lat. Nie będę też obiecywać, że znajomość jednego narzędzia zapewni komuś zatrudnienie. Mogę natomiast pokazać sposób pracy, w którym korzystasz z pomocy modelu i zachowujesz możliwość wyjaśnienia wyniku. Fundamenty są do tego bardzo przydatne: definicje, model danych, obliczenia, kontrola i komunikacja ograniczeń.

W tym tekście używam autorskiego przykładu na syntetycznych danych. Kod został sprawdzony w SQLite przez node:sqlite w Node 24. Błędne zapytanie jest celowo przygotowanym przykładem, a nie zapisem odpowiedzi konkretnego modelu. Nie jest to benchmark AI ani ponowny test narzędzi z filmu. Chodzi o metodę, którą możesz zastosować do własnego zadania.

Płynna odpowiedź nie rozstrzyga poprawności

Model może przygotować czytelny opis, który zawiera błędne stwierdzenie albo niejawne założenie. NIST opisuje takie przekonująco przedstawiane nieprawdziwe treści jako konfabulacje w profilu generatywnej AI, sekcja 2.2. To powód, żeby sprawdzać treść odpowiedzi. Sam fakt istnienia tego ryzyka nie mówi jeszcze, jak często konkretny model pomyli się w Twoim zadaniu.

W analizie danych błąd nie musi polegać na wymyślonej funkcji. Często wszystko wygląda rozsądnie: prawdziwe nazwy tabel, poprawna składnia i sensownie nazwany wykres. Problem tkwi w tym, że liczysz pozycje zamiast zamówień, pomijasz brakujące rekordy albo porównujesz niepełny miesiąc z pełnym. Te rzeczy potrafi przeoczyć również człowiek. Dlatego kontrola powinna dotyczyć wyniku i jego znaczenia, niezależnie od autora kodu.

Nie traktuję zdania „sprawdź jeszcze raz” jako osobnego testu. Może skłonić model do znalezienia problemu, ale może też dać kolejne przekonujące uzasadnienie tej samej pomyłki. Potrzebuję punktu odniesienia poza samą odpowiedzią: małego zbioru z ręcznie ustalonym wynikiem, dokumentacji użytej funkcji albo porównania z innym sposobem obliczenia.

Równie ostrożnie patrzę na powtarzalność. Zapytanie może za każdym razem zwracać tę samą złą liczbę. Stałość wyniku pomaga odtworzyć działanie, lecz nie potwierdza poprawnej definicji. Z drugiej strony różne sformułowania odpowiedzi nie muszą oznaczać różnych obliczeń. Oddzielam tekst modelu, kod, dane wejściowe i rezultat uruchomienia. Każdy z tych elementów wymaga innego rodzaju sprawdzenia.

Ustal, co delegujesz i kto rozstrzyga znaczenie

Do modelu mogę skierować prośbę o szkic zapytania, propozycję przypadków testowych albo wyjaśnienie błędu składni. Zanim to zrobię, określam pytanie i jednostkę analizy. Jeżeli chcę sumy wartości zamówień, muszę wiedzieć, czy obejmuje ona anulowania, zwroty, podatki i różne waluty. Model nie powinien samodzielnie dopowiadać firmowej definicji tylko dlatego, że w poleceniu zabrakło szczegółu.

W naszym ćwiczeniu zakres jest mały: trzy kompletne zamówienia w jednej umownej jednostce, bez podatków, korekt i przeliczeń walutowych. Pytamy o ich łączną wartość. Osobna tabela zawiera pozycje zamówień. Taki opis wystarcza do pokazania błędu relacji, a jednocześnie nie udaje pełnego modelu sprzedaży. Uproszczenia są jawne, więc czytelnik wie, czego przykład nie rozstrzyga.

Przy zadaniu firmowym najpierw sprawdzam, jakie dane wolno przekazać do wybranego narzędzia. Do ćwiczenia używam danych syntetycznych i minimalnego schematu. Samo usunięcie imienia z eksportu nie jest dla mnie automatycznym potwierdzeniem, że cały plik nadaje się do wysłania. Jeśli potrzebne są dane organizacji, pracuję w zatwierdzonym środowisku zgodnie z ustaleniami zespołu.

Rozdzielam też przygotowanie propozycji od wykonania zmiany. Prośba o zapytanie do odczytu nie oznacza zgody na modyfikowanie źródłowych tabel. Na etapie sprawdzania potrzebuję kontrolowanego przykładu i możliwości odtworzenia. Kiedy wynik ma wejść do cyklicznego raportu, dochodzą przegląd, właściciel i reguły aktualizacji. Wygenerowanie pierwszej wersji jest jednym z kroków tej pracy.

Napisz polecenie, które ujawnia założenia

Przykładowe polecenie brzmiałoby: „Przygotuj zapytanie SQLite liczące łączną wartość zamówień. orders ma jeden rekord na zamówienie, a items może mieć wiele rekordów dla tego samego zamówienia. Kwota amount dotyczy całego zamówienia. Dane są syntetyczne. Najpierw wypisz założenia i zaproponuj kontrolę, która wykryje powielenie wartości po połączeniu tabel”. Taki opis daje znacznie więcej kontekstu niż samo „policz sprzedaż”.

Dodałbym oczekiwany format: jedno zapytanie, krótkie wyjaśnienie poziomu szczegółowości i przypadki, dla których wynik wymaga dodatkowej decyzji. Jeżeli potrzebuję konkretnej wersji silnika albo biblioteki, podaję ją. Kod zgodny z innym dialektem może wyglądać znajomo i mimo to nie uruchomić się w moim środowisku. Czytelna deklaracja zmniejsza liczbę rzeczy pozostawionych przypadkowemu domysłowi.

Nie podaję modelowi prawa do rozstrzygania braków w definicji. Proszę, żeby je nazwał. Gdy odpowiedź zawiera założenie o pomijaniu anulowań, wracam do źródła wymagań. Nawet rozsądnie brzmiąca reguła może być niezgodna z zadaniem. Prompt jest sposobem przekazania kontekstu, a nie zamiennikiem uzgodnienia tego kontekstu z osobą odpowiedzialną za wynik.

Zbuduj małe dane, na których znasz odpowiedź

Poniższy kod tworzy dwie tabele w pustej bazie SQLite. Trzy kwoty zamówień to 100, 200 i 50, więc oczekiwana suma wynosi 350. Pierwsze zamówienie ma dwie pozycje, pozostałe po jednej. Tę różnicę w poziomie szczegółowości zapisuję przed uruchomieniem zapytania. Właśnie ona będzie kontrolowanym miejscem, w którym łatwo popełnić błąd.

-- example: fixture
CREATE TABLE orders (order_id INTEGER PRIMARY KEY, amount INTEGER);
CREATE TABLE items (item_id INTEGER PRIMARY KEY, order_id INTEGER);
INSERT INTO orders VALUES (1, 100), (2, 200), (3, 50);
INSERT INTO items VALUES (11, 1), (12, 1), (21, 2), (31, 3);

Dane mają być na tyle małe, żeby dało się przejść po nich palcem. Jeśli zaczynam od miliona wierszy i nie znam żadnego oczekiwanego wyniku, łatwo pomylić uruchomienie z weryfikacją. Mały przykład nie dowodzi poprawności wszystkich danych produkcyjnych. Pozwala za to sprawdzić konkretną własność rozwiązania i wyjaśnić, dlaczego wynik powinien wyglądać właśnie tak.

W prawdziwym zadaniu sprawdziłbym dodatkowo kompletność źródła, okres i znaczenie kwoty. Tutaj świadomie odkładam te kwestie, bo ćwiczymy powielenie po połączeniu tabel. Dobry test ma jasno określony cel. Jeśli w jednym przykładzie mieszam kilkanaście nieznanych reguł, trudno później ustalić, która z nich odpowiada za różnicę.

Zobacz błąd, którego nie wykryje sama składnia

Celowo błędna propozycja sumuje kwoty po połączeniu zamówień z pozycjami. Zapytanie działa w SQLite i zwraca 450. Pierwsze zamówienie trafia do wyniku dwa razy, ponieważ ma dwie pozycje. W efekcie jego kwota 100 zostaje dodana ponownie. Baza nie zgłasza błędu: wykonuje dokładnie to, co zapisano w zapytaniu.

-- example: wrong-join
SELECT SUM(o.amount) AS total_amount
FROM orders AS o
JOIN items AS i ON i.order_id = o.order_id;

To użyteczny moment na pytanie do modelu o wyjaśnienie, ale mam już niezależne oczekiwanie: 350. Nie szukam odpowiedzi, która usprawiedliwi 450. Szukam miejsca, w którym zmieniła się liczba reprezentacji zamówienia. Można obejrzeć połączone rekordy albo policzyć ich liczbę dla każdego identyfikatora.

-- example: cardinality
SELECT o.order_id, COUNT(*) AS joined_rows
FROM orders AS o
JOIN items AS i ON i.order_id = o.order_id
GROUP BY o.order_id
ORDER BY o.order_id;

Wynik to pary 1, 2, 2, 1, 3, 1: pierwsze zamówienie ma dwa wiersze po JOIN. Ta kontrola wskazuje przyczynę, zamiast jedynie stwierdzać różnicę w sumie. O relacjach i zachowaniu połączeń szerzej piszę w przewodniku po JOIN w SQL. Znajomość tego mechanizmu pozwala ocenić propozycję niezależnie od tego, kto ją napisał.

Popraw regułę, a potem spróbuj ją podważyć

Do sumy wartości wszystkich zamówień tabela pozycji w ogóle nie jest potrzebna. Liczę na poziomie, na którym zapisano kwotę. Poniższe zapytanie zwraca 350 i pozostaje zgodne z naszym wąskim pytaniem. Jeśli potrzebuję później podziału według produktu, będę musiał ustalić odpowiednią kwotę na poziomie pozycji. To już inne obliczenie.

-- example: total
SELECT SUM(amount) AS total_amount FROM orders;

Nie poprawiam problemu przez SUM(DISTINCT amount). Taka operacja usuwa powtarzające się wartości kwoty, a nie powtarzające się zamówienia. Dwa różne zamówienia mogą mieć identyczną kwotę. Po dodaniu czwartego zamówienia o wartości 100 poprawna suma wzrośnie do 450, podczas gdy suma różnych kwot nadal wyniesie 350. Działanie DISTINCT opisuje dokumentacja agregacji SQLite.

Dopisuję więc przypadek z identyczną kwotą i zamówieniem bez pozycji. Sprawdzam również pustą tabelę oraz brakującą kwotę. W SQLite SUM pomija wartości NULL, a przy braku wartości do zsumowania zwraca NULL. To zachowanie techniczne, nie zgoda biznesowa na ignorowanie braków. Jeśli oczekuję kompletnych kwot, osobna kontrola powinna wykryć brak zanim wynik zostanie przekazany.

Sprawdź również granice własnego testu

Test może przechodzić i nadal nie obejmować najważniejszego ryzyka. Gdybym w przykładzie zostawił tylko zamówienia z jedną pozycją, błędny JOIN zwróciłby oczekiwaną sumę. Dlatego dobieram przypadki według zasady, którą chcę sprawdzić. Potrzebuję zamówienia z kilkoma pozycjami, dwóch identycznych kwot oraz brakującego dopasowania. To właśnie różnice między przypadkami ujawniają, czy rozwiązanie zachowuje właściwy poziom szczegółowości danych.

Uważam też na źródło oczekiwania. Jeżeli model napisał zapytanie, a potem na tej samej podstawie wygenerował oczekiwaną liczbę, oba elementy mogą powtarzać jedno błędne założenie. W małym zbiorze liczę osobno i opisuję regułę zwykłym językiem. Przy większym wyniku szukam uzgodnionej sumy kontrolnej lub niezależnego przeglądu. Sam drugi plik z napisem „test” nie zapewnia niezależności sprawdzenia.

Kiedy porównuję dwie metody, sprawdzam, czy obejmują tę samą populację. Różnica może wynikać z innego okresu, filtra albo momentu pobrania danych. Zgodność sum również nie dowodzi, że wszystkie rekordy są poprawne: dwa błędy mogą się wzajemnie znieść. Dlatego obok sumy oglądam liczebność, klucze oraz wybrane przypadki. Zakres kontroli dobieram do skutku pomyłki i zapisuję, czego jeszcze nie sprawdziłem.

Oddziel obliczenie od interpretacji

Po sprawdzeniu sumy nadal nie mam automatycznie rekomendacji biznesowej. W przykładzie wiem, że trzy zamówienia mają łączną wartość 350 w przyjętej jednostce. Nie wiem, czy sklep działa lepiej, czy klienci są bardziej zadowoleni ani co spowodowało zmianę sprzedaży. Do takich pytań potrzeba porównania, dodatkowych danych i uzgodnionych kryteriów. Ładnie napisany akapit nie uzupełnia tych braków.

Gdy proszę AI o opis wyniku, przekazuję sprawdzone liczby, definicje i ograniczenia. Potem kontroluję, czy tekst nie dodał przyczyny, której nie ustaliliśmy. Słowa „dzięki”, „spowodowało” albo „udowadnia” potrafią zmienić ostrożną obserwację w bardzo mocną tezę. W raporcie zapisuję osobno to, co policzyłem, możliwe wyjaśnienie i propozycję kolejnego sprawdzenia.

Odbiorca powinien dostać wynik, źródło, okres, metodę kontroli oraz informację, co pozostaje niepewne. Nie potrzebuje całej historii rozmowy z modelem. Potrzebuje za to dowodu pozwalającego odtworzyć obliczenie. W moim sposobie pracy pomoc AI nie usuwa tego obowiązku. Jeśli nie potrafię wyjaśnić kluczowego kroku, zatrzymuję publikację i wracam do sprawdzenia.

Ćwicz fundamenty przez przewidywanie wyniku

Nie potrzebuję twierdzenia, że AI nieuchronnie pogarsza pamięć albo inteligencję, żeby uzasadnić samodzielną praktykę. Wystarczy sprawdzić własne zachowanie: czy umiem przewidzieć liczbę wierszy po JOIN, wyjaśnić mianownik wskaźnika i znaleźć brakującą regułę? Jeśli odpowiedź brzmi „nie”, mam konkretny obszar do nauki. To obserwacja umiejętności, bez diagnozy psychologicznej.

Przy ćwiczeniu najpierw zapisuję oczekiwanie bez pomocy modelu. Potem korzystam z AI do porównania podejść albo szukania kontrprzykładu. Na końcu zamykam odpowiedź i sam wyjaśniam rozwiązanie na zmienionych danych. Ten ostatni krok jest ważny: rozpoznanie znajomego fragmentu kodu bywa znacznie łatwiejsze niż samodzielne zastosowanie zasady w nowym przypadku.

Nie trzeba uczyć się wszystkich narzędzi równocześnie. Do przykładu wystarcza rozumienie tabel, relacji i agregacji. W arkuszu podobny problem może dotyczyć zakresu formuły, a w Pythonie poziomu grupowania. Wybieram narzędzie używane przy danym zadaniu i ćwiczę zasadę, która pozwala sprawdzić wynik. O szerszym doborze metody piszę w artykule o metodach analizy danych.

Sprawdź cały koszt automatyzacji

Szybko wygenerowany szkic może być pomocny, ale czas pierwszej odpowiedzi nie jest całym kosztem zadania. Dochodzi sprawdzenie, poprawienie założeń, uruchomienie i późniejsze utrzymanie. Jeśli chcę ocenić usprawnienie, porównuję podobne zadania z takim samym warunkiem jakości. Bez takiego porównania nie wpisuję procentowego wzrostu produktywności tylko dlatego, że kod pojawił się na ekranie w kilka sekund.

Przy cyklicznej analizie zapisuję wersję kodu, środowisko i zestaw kontroli. Nowy eksport może zmienić typ kolumny albo przynieść przypadek, którego wcześniej nie było. Jeśli aktualizuję bibliotekę lub sposób generowania propozycji, ponawiam właściwe testy. Nie muszę za każdym razem odtwarzać całego projektu, ale muszę wiedzieć, które założenia mogła naruszyć zmiana.

Potrzebna jest także reakcja na nieudaną kontrolę. Raport może poczekać na wyjaśnienie zamiast publikować niepewną liczbę. W zespole ustalamy, kto sprawdza problem i co widzi odbiorca w tym czasie. Automatyzacja, która umie jedynie wygenerować wynik, ma węższy zakres niż proces gotowy do regularnego użycia. Warto nazwać tę różnicę przy prezentacji prototypu.

Zrób własną próbę na małym zbiorze

Uruchom przykład w pustej bazie SQLite. Zanim wykonasz zapytania, rozpisz na kartce wiersze po połączeniu i sumę kwot. Następnie dodaj zamówienie o takiej samej wartości jak istniejące oraz zamówienie bez pozycji. Sprawdź, które zapytania zmienią wynik zgodnie z oczekiwaniem. Opisz, dlaczego usuwanie różnych kwot nie naprawia problemu powielonych zamówień.

W drugiej części poproś model o propozycję testów, ale sam ustal wyniki oczekiwane. Dodaj brakującą kwotę i pusty zbiór, a potem zdecyduj, jak raport powinien pokazać takie sytuacje. Możesz otrzymać sensowną podpowiedź, lecz decyzja o znaczeniu braku musi być jawna. Oddziel przypadek techniczny od reguły, którą przyjmujesz dla konkretnego zastosowania.

Zapisz na koniec krótką notatkę: pytanie, dane, oczekiwanie, otrzymany wynik, poprawka i ograniczenie. Jeśli korzystasz z AI, dodaj, w którym kroku pomogło i co sprawdziłeś samodzielnie. Taki zapis pokazuje więcej niż samo „używam AI w analizie”. Pokazuje, że potrafisz przejść od propozycji do wyniku, który rozumiesz i umiesz obronić na konkretnych danych.