Weryfikacja
Jak sprawdzać wyniki AI w analizie danych, zanim zobaczy je szef
AI liczy szybko i brzmi przekonująco, także gdy się myli. Cztery kontrole, które stosuję przed pokazaniem wyniku: obliczenia, kompletność, definicje i wnioski.

Wyobraź sobie taką scenę. Dostajesz od AI analizę sprzedaży: ładnie sformatowaną, z nagłówkami, trzema wnioskami i jednym wykresem. Wnioski są logiczne, liczby wyglądają wiarygodnie, a ton jest tak pewny siebie, że aż chce się napisać „dziękuję” na końcu rozmowy. Kopiujesz to do prezentacji. Dwa dni później ktoś z finansów pyta, dlaczego suma w Twoim slajdzie różni się od ich raportu o osiem procent.
Znam tę scenę z różnych stron: jako analityczka, jako osoba, która sprawdza cudze raporty, i jako ktoś, kto kiedyś sam wysłał dalej wynik, którego nie przejrzał dość uważnie. Z biegiem lat wypracowałam sobie krótki zestaw kontroli, który stosuję zawsze, gdy wynik ma opuścić moje biurko. W kursie poświęcamy mu osobny temat w trzecim tygodniu. Tutaj opiszę go w wersji rozszerzonej, z przykładami i z jednym ostrzeżeniem na początek: weryfikacja jest nudna. Właśnie dlatego się ją pomija i właśnie dlatego warto ją zautomatyzować tam, gdzie się da.
Dlaczego AI brzmi przekonująco nawet wtedy, gdy się myli
Zacznę od mechanizmu, bo zrozumienie go oszczędza dużo nerwów. Model językowy generuje tekst, który jest statystycznie prawdopodobny w danym kontekście. Prawdopodobny bywa nieprawdziwy. Jeśli w danych treningowych po zdaniu „Sprzedaż wzrosła o” zwykle następuje liczba z procentem, model chętnie poda liczbę z procentem, nawet gdy nie ma skąd jej wziąć.
Badacze nazywają to halucynacjami i opisują je od kilku lat. Obszerny przegląd literatury znajdziesz w pracy A Survey on Hallucination in Large Language Models, która porządkuje rodzaje błędów i metody ich ograniczania. Z kolei zespół OpenAI w tekście Why language models hallucinate przekonuje, że część problemu bierze się ze sposobu oceniania modeli: testy nagradzają trafne odpowiedzi, a przyznanie się do niewiedzy punktuje gorzej niż zgadywanie. Model, który „zdaje egzamin” metodą strzału, uczy się strzelać. Modele pozostają użyteczne, tyle że ich pewność siebie nie mówi nic o poprawności.
W analizie danych halucynacje mają kilka typowych postaci:
- Błędy rachunkowe. Suma, średnia lub procent, które wyglądają dobrze i nie zgadzają się z danymi.
- Cicha utrata danych. Model odrzucił wiersze z brakami, zduplikował część rekordów albo wczytał tylko początek pliku, i nie wspomniał o tym ani słowem.
- Własna interpretacja definicji. Poproszony o „klientów”, policzył unikalne adresy e-mail, bo tak mu było wygodnie.
- Wnioski nieuzasadnione danymi. Obserwacja („sprzedaż spadła w marcu”) zamieniona w wyjaśnienie („bo kampania była słaba”).
Cztery rodzaje błędów to cztery kontrole. Poniżej opiszę każdą po kolei.
Zasada nadrzędna: plan, wykonanie, weryfikacja
Zanim przejdę do szczegółów, jedna uwaga o miejscu weryfikacji w całym procesie. W pierwszym tygodniu kursu uczymy schematu: plan, wykonanie, weryfikacja. Prawdopodobnie nikt nie zdziwi się, że ostatni krok jest tym, który uczestnicy chcą pominąć. Pierwsze dwa są zabawne. Planowanie daje poczucie kontroli, wykonanie daje efekt „wow”, a weryfikacja daje listę rzeczy do poprawy.
Dlatego dobrze jest wpisać kryteria weryfikacji już na początku, w briefie. Kajo opisał to w artykule o briefie zamiast prompta: jednym z pięciu elementów jest kryterium poprawności. Jeśli napisałeś je przed analizą, weryfikacja przestaje być improwizacją. Staje się odhaczaniem punktów, a odhaczanie punktów jest czynnością, którą nawet w poniedziałek rano da się wykonać.
Kontrola pierwsza: obliczenia
Pierwsze pytanie brzmi: czy liczby są policzone poprawnie? Brzmi banalnie, a jednak to właśnie tu wychodzi najwięcej pomyłek, i to nie tylko po stronie AI.
Historia analizy danych zna spektakularne przykłady błędów w arkuszach. W 2013 roku Thomas Herndon, Michael Ash i Robert Pollin opublikowali krytykę głośnej pracy Carmen Reinhart i Kennetha Rogoffa o zadłużeniu publicznym i wzroście gospodarczym. Wśród zarzutów znalazł się błąd w arkuszu: zakres formuły nie obejmował kilku krajów, więc część danych po prostu nie trafiła do średniej (Reinhart i Rogoff przyznali się do błędu w formule, choć spierali się z resztą zarzutów). Autorami pracy byli doświadczeni ekonomiści z ogromnym zapleczem. Jeśli arkusz potrafi zawieść ich, może zawieść każdego, a model językowy dokłada do tego własne sposoby na pomyłkę.
Jak sprawdzam obliczenia
- Proszę o kod, nie o wynik. Jeśli AI policzyło coś „w głowie”, nie ufam. Jeśli napisało zapytanie SQL albo skrypt i go uruchomiło, mogę przeczytać logikę. Model zdecydowanie pewniej rachuje przez kod niż przez tekst.
- Liczę próbkę ręcznie. Wybieram trzy konkretne przypadki, na przykład jednego klienta, jeden dzień i jeden produkt, i liczę je niezależnie: w arkuszu, w zapytaniu albo na kartce. Jeśli wynik się zgadza, rośnie zaufanie do reszty. Jeśli nie, mam konkretny trop.
- Porównuję z liczbą, którą już znam. Suma sprzedaży z analizy powinna zgadzać się z raportem finansowym lub z innym uznanym źródłem. Jeśli różnica jest większa niż zakładana tolerancja, szukam przyczyny, zanim pójdę dalej.
- Sprawdzam przypadki skrajne. Co się dzieje z zerem, z wartością ujemną, z pustą komórką, z pierwszym i ostatnim dniem okresu? Błędy lubią krawędzie.
- Pytam o rząd wielkości. Zanim zacznę czytać dokładne liczby, patrzę na ich skalę. Jeśli miesięczna sprzedaż małego sklepu wyszła w miliardach, nie potrzebuję kalkulatora.
Tej ostatniej kontroli nie lekceważ. Najwięcej błędów wyłapuję w pierwszych pięciu sekundach, kiedy patrzę na wynik i czuję, że coś nie gra. Nazywam to szóstym zmysłem analityka, choć w praktyce to po prostu doświadczenie z cudzymi i własnymi pomyłkami.
Kontrola druga: kompletność danych
Druga kontrola dotyczy tego, co mogło zginąć po drodze. To najbardziej podstępna kategoria, bo błąd nie zostawia śladu. Wynik jest policzony poprawnie, ale na niepełnych danych.
Model mógł wczytać tylko pierwsze tysiąc wierszy z pliku, bo reszta nie zmieściła się w kontekście. Mógł odrzucić wiersze z pustymi wartościami, nie informując o tym. Mógł połączyć dwie tabele złączeniem, które po cichu zgubiło rekordy bez dopasowania. Albo połączyć je tak, że rekordy się zdublowały i suma urosła.
Dobrym przykładem tego, jak niewinna konwersja potrafi zepsuć dane, jest historia z genetyki. Badacze z Australii pokazali w pracy Gene name errors are widespread in the scientific literature, że w publikacjach naukowych z załącznikami w arkuszach Excela nazwy niektórych genów, na przykład SEPT2, zostały automatycznie zamienione na daty. Według autorów dotyczyło to około jednej piątej przeanalizowanych artykułów. Nikt tego nie chciał i nikt nie zauważył przy zapisie. Dane po prostu cichutko przestały być danymi.
Jak sprawdzam kompletność
- Liczę wiersze na wejściu i na wyjściu. Ile rekordów było w pliku? Ile wczytano? Ile odrzucono i dlaczego? Jeśli model nie umie odpowiedzieć na te pytania, to znaczy, że nie wie, co zrobił.
- Szukam braków. Ile pustych wartości jest w kluczowych kolumnach? Czy braki skupiają się w jednym okresie albo regionie? Brak, który ma wzór, rzadko jest przypadkiem.
- Porównuję zakres dat i kategorii. Czy w wynikach są wszystkie miesiące, które powinny być? Wszystkie regiony? Jeśli analiza kończy się 20 września, a miała obejmować cały miesiąc, to jest sygnał.
- Pilnuję złączeń. Po każdym łączeniu tabel sprawdzam, czy liczba wierszy zachowała się tak, jak powinna. Złączenie jeden do jednego nie powinno zmienić liczby rekordów. Jeśli zmieniło, mamy duplikaty albo straty.
- Proszę o raport z przetwarzania. To prosta sztuczka, której uczę w kursie: w briefie dopisuję, że przed wnioskami model ma pokazać, ile wierszy wczytał, ile odrzucił i co zrobił z brakami. Taki raport kosztuje cztery linijki, a wyłapuje całe klasy błędów.
Kontrola trzecia: definicje wskaźników
Trzecia kontrola pytania: czy AI policzyło to, co miało policzyć? Tu zaczyna się obszar, w którym nawet bezbłędny rachunek prowadzi do złego wyniku.
Weźmy zwykłe słowo „klient”. Dla marketingu może to być osoba, która kliknęła w reklamę. Dla sprzedaży ta, która zostawiła dane w formularzu. Dla finansów ta, która zapłaciła. Zmiana definicji potrafi odwrócić wniosek w porównaniu dwóch kampanii: reklama A wygrywa po kliknięciach, reklama B po zakupach. Pokazujemy to w Pracowni na stronie kursu i pokazujemy to na zajęciach w drugim tygodniu, gdzie omawiamy źródła prawdy i definicje KPI.
Model nie zna Twoich definicji. Jeśli ich nie podasz, wybierze najbardziej prawdopodobną, a ta bywa najczęściej spotykana w internecie, nie w Twojej firmie. Zwróć uwagę, że dotyczy to także wskaźników pozornie oczywistych: „konwersja” (od czego do czego?), „retencja” (po ilu dniach?), „średnia wartość zamówienia” (z rabatami czy bez, ze zwrotami czy bez?).
Jak sprawdzam definicje
- Każę modelowi podać definicję własnymi słowami. Przed analizą pytam: jak rozumiesz pojęcie „aktywny klient” w tym zadaniu? Odpowiedź ujawnia rozbieżności, zanim cokolwiek się policzy.
- Porównuję z dokumentacją firmy. Jeśli istnieje słownik pojęć (a jeśli nie istnieje, to wiem, od czego zacząć), sprawdzam zgodność. W kursie pokazujemy, jak taki słownik zapisać tak, żeby AI mogło z niego korzystać.
- Sprawdzam filtry. Które wiersze weszły do licznika, a które do mianownika? Czy testowe zamówienia i zwroty zostały wyłączone, jeśli powinny?
- Zadaję pytanie odwrotne. Jeśli wynik jest zaskakujący, pytam: co musiałoby być prawdą, żeby ta liczba była poprawna? Często odpowiedź wskazuje na źle rozumiany wskaźnik.
Kontrola czwarta: wnioski
Czwarta kontrola to ta, której żaden skrypt za Ciebie nie wykona. Dotyczy relacji między danymi a tym, co z nich wyciągnięto.
Rozróżnienie jest proste, a mimo to trudne w praktyce: obserwacja mówi, co się stało, wyjaśnienie mówi, dlaczego. Dane pokazują, że sprzedaż spadła w marcu. To obserwacja. „Spadła, bo konkurencja obniżyła ceny” to hipoteza, która może być prawdziwa, ale wymaga osobnego uzasadnienia. W trzecim tygodniu kursu poświęcamy temu odrębny temat: trendy, anomalie i hipotezy. Uczymy się, jak odróżniać jedno od drugiego i jak proponować hipotezy, nie sprzedając ich jako faktów.
Model językowy ma w tym obszarze szczególną skłonność. Jest świetny w opowiadaniu historii i zawsze potrafi znaleźć wiarygodnie brzmiące wyjaśnienie dla dowolnego wykresu. To zaleta, jeśli potrzebujesz pomysłów na hipotezy. To wada, jeśli traktujesz te pomysły jako ustalenia.
Jak sprawdzam wnioski
- Dla każdego wniosku szukam dowodu w danych. Które kolumny, które filtry, który okres? Jeśli model nie umie wskazać, skąd wniosek wynika, traktuję go jako hipotezę.
- Szukam wyjaśnień alternatywnych. Zadaję pytanie: co jeszcze mogłoby dać taki sam obraz danych? Sezonowość, zmiana w sposobie zbierania danych, jednorazowe zdarzenie, pojedynczy duży klient.
- Sprawdzam, czy wniosek przetrwa podział danych. Jeśli „klienci z segmentu A kupują więcej”, czy to prawda w każdym regionie i w każdym miesiącu, czy tylko w sumie? Znany paradoks Simpsona pokazuje, że trend widoczny w całości potrafi znikać w częściach, a nawet się odwracać.
- Oddzielam rekomendacje od ustaleń. W raporcie ustalenia i rekomendacje mają osobne nagłówki. Czytelnik wie wtedy, gdzie kończą się dane, a zaczyna ocena.
- Zgłaszam niepewność. Zdanie „na podstawie tych danych nie da się tego rozstrzygnąć” jest pełnoprawnym wnioskiem. Warto, by pojawiało się w raportach częściej.

Jak to zautomatyzować, żeby się chciało
Cztery kontrole brzmią rozsądnie, ale rozsądne rzeczy mają tę wadę, że zostają w sferze zamiarów. Najlepsza metoda, jaką znam, to wbudowanie weryfikacji w sam proces.
Po pierwsze, brief z kryteriami. Jeśli kryterium poprawności jest zapisane przed analizą (suma zgodna z raportem finansowym, raport z przetwarzania, wskazanie dowodu dla każdego wniosku), model może samodzielnie wykonać część kontroli, a Ty sprawdzasz, czy je rzeczywiście wykonał.
Po drugie, drugie podejście. Poproś model o ponowną analizę tego samego zadania w osobnej rozmowie i porównaj wyniki. Jeśli się różnią, masz natychmiast listę miejsc do sprawdzenia. Jeśli są zgodne, nie masz gwarancji, ale masz silniejszy sygnał.
Po trzecie, recenzent. W tygodniu czwartym pokazujemy podział ról: manager, implementer i reviewer. Agent wykonujący analizę ma być kimś innym niż agent, który ją ocenia. Na tej zasadzie opiera się kontrola jakości w każdej poważnej organizacji: autor nie recenzuje własnej pracy.
Po czwarte, testy. Jeśli analiza ma być powtarzana, na przykład co tydzień, napisz kilka automatycznych testów: suma musi zgadzać się z raportem, liczba wierszy nie może spaść poniżej progu, w danych nie może być ujemnych cen. Wtedy pierwszy błąd zgłasza się sam.
Czego nie da się zrobić automatycznie
Zostaje jeszcze element, który zawsze zostanie po stronie człowieka: ocena sensu biznesowego. Żadna kontrola techniczna nie odpowie na pytanie, czy wynik ma sens w kontekście tego, co dzieje się w firmie.
Dlatego ostatni krok zawsze wykonuję sama: odsuwam się od ekranu i zadaję sobie trzy pytania. Czy ten wynik pasuje do tego, co wiem o biznesie? Czy zdziwiłabym się, gdyby ktoś o niego zapytał? Czy czuję się komfortowo, broniąc go przed osobą, która zna dane lepiej ode mnie? Jeśli na któreś pytanie odpowiedź brzmi „nie”, wracam do kontroli.
Brzmi to prosto, ale właśnie taka postawa odróżnia analityka, któremu się ufa, od takiego, któremu się nie ufa. Zaufanie buduje się latami, a traci jednym błędnym slajdem.
Krótka lista kontrolna do wydruku
Na koniec zestaw, który możesz skopiować do własnego briefu albo przykleić nad monitorem.
- Czy zgadza się suma z niezależnym źródłem?
- Czy ręcznie policzona próbka zgadza się z wynikiem?
- Ile wierszy wczytano, ile odrzucono i dlaczego?
- Czy braki danych mają wzór (okres, region, kategoria)?
- Czy definicje wskaźników zgadzają się ze słownikiem firmy?
- Które filtry weszły do licznika i mianownika?
- Czy każdy wniosek ma wskazany dowód w danych?
- Czy rozdzieliłam obserwacje od hipotez i rekomendacji?
- Czy wynik ma sens biznesowy?
- Czy czuję się komfortowo, broniąc go przed ekspertem?
Dziesięć pytań, dwadzieścia minut. Dla porównania, odkręcanie błędnej analizy po jej prezentacji zajmuje zwykle kilka dni, przeprosiny w mailu do zarządu i pewien uszczerbek na reputacji.
Podsumowanie
AI jest znakomitym asystentem do analizy, o ile traktujesz je jak zdolnego stażystę: bystrego, szybkiego i pewnego siebie, a jednocześnie potrzebującego kontroli. Cztery kontrole, czyli obliczenia, kompletność, definicje i wnioski, pokrywają większość błędów, które spotykam w pracy. Ich wspólny mianownik jest taki, że wymagają wiedzy o biznesie i o danych, której model nie ma, a Ty masz.
To dobra wiadomość dla wszystkich, którzy zastanawiają się, czy AI zabierze im pracę analityczną. Zabierze te fragmenty, które polegają na mechanicznym liczeniu i formatowaniu. Zostanie ta część, w której ktoś musi odpowiedzieć za wynik. Warto się w niej wyspecjalizować.
Najważniejsze pytania i odpowiedzi
Czy AI naprawdę się myli przy prostych obliczeniach?
Model językowy przewiduje tekst, a nie wykonuje rachunków, więc zdarza mu się podać wynik, który wygląda dobrze i jest błędny. Znacznie pewniej liczy wtedy, gdy napisze i uruchomi kod albo zapytanie SQL. Dlatego proszę zawsze o pokazanie kodu i sprawdzam próbkę wyniku niezależnym narzędziem.
Jak długo trwa porządna weryfikacja?
Przy typowej analizie na pliku z danymi sprzedażowymi to od dwudziestu minut do godziny. Zwykle jest to kilka razy krócej niż samo przygotowanie analizy i kilkadziesiąt razy krócej niż tłumaczenie się z błędu na spotkaniu zarządu.
Czy mogę poprosić AI, żeby samo sprawdziło swój wynik?
Można i warto, bo drugie podejście wyłapuje część pomyłek, zwłaszcza rachunkowych. Samokontrola ma jednak ograniczenia: model może powtórzyć to samo błędne założenie. Ostatni krok, czyli porównanie z niezależnym źródłem i ocena sensu biznesowego, powinien zostać po stronie człowieka.
Źródła
Chcesz przećwiczyć to na własnych danych?
Analiza z AI to 6 tygodni praktyki z Kajo i Kasią. Start 11 stycznia 2027.