Halucynacje AI: czym naprawdę są, skąd się biorą i jak je mierzyć w firmie (test na 100 promptach) 

Halucynacja AI to odpowiedź, która brzmi pewnie i wiarygodnie, ale nie ma żadnego pokrycia: ani w dokumentach, które system pobrał, ani w rekordach, które umiał odczytać, ani w faktach. Nie chodzi o pomyłkę w dacie, tylko o twierdzenie podane tonem pewności, którego nie da się sprawdzić. W praktyce biznesowej to najważniejsza definicja, bo ona mówi, co dokładnie mierzysz.

Skala zależy mocno od zastosowania. Dla GPT-4 przy ogólnym użyciu mowa o 1,8% halucynacji, a przy konkretnych aplikacjach wartość rośnie do 28,6%. W pytaniach prawnych modele ogólne, bez dokładania własnych dokumentów, halucynowały w 69% do 88% przypadków. Narzędzia z wbudowanym wyszukiwaniem dokumentów schodzą do 17-33%, ale to nadal co piąta odpowiedź.

Dlatego w firmie nie pytasz „czy model halucynuje”, tylko „wolę, ile zarabiam na każdej setce odpowiedzi”. Poniżej konkretna metoda: zestaw 100 pytań z prawdziwego ruchu, cztery rodzaje pomiaru i próg, który ustawiasz sam.

Skąd się biorą halucynacje i dlaczego żaden prompt ich nie usunie

Model językowy przewiduje kolejne słowa na podstawie prawdopodobieństwa, a nie prawdy. Nie ma w nim kroku „czy to jest prawda?”. Jeśli w kontekście brakuje danych, system je dopisuje, bo ciągłe płynne zdanie jest statystycznie prawdopodobne. Nie ma też wewnętrznego sygnału „nie jestem pewien”. Płynność i pewność to dwie różne rzeczy i tylko jedna z nich wychodzi z modelu.

Da się ten mechanizm opisać twardo. Jeśli w korpusie dokładnie raz występuje piąta część określonej kategorii danych, model bazowy pomyli co najmniej piątą część pytań o tę kategorię. Żaden prompt tego nie usuwa, bo to granica danych treningowych, a nie błąd w instrukcji.

Sprowadzenie temperatury do zera też nie pomaga. Nie zamienia twierdzenia bez pokrycia w twierdzenie z pokryciem. W jednym z badań dekodowanie deterministyczne (temperatura 0) nie dało istotnej poprawy, co wskazało, że problem leży w strukturze odpowiedzi, a nie w losowości generowania. To dlatego tak często widzisz porady w stylu „dodaj do promptu: odpowiadaj tylko, gdy masz ponad 90% pewności”. Brzmi rozsądnie, ale to prośba, nie mechanizm kontrolny. Wszystko, co naprawdę trzyma odpowiedź w ryzach, działa poza modelem.

Praktyczny wniosek: jeśli w Twojej firmie halucynacje mają być rzadkie, to jest to zadanie inżynierskie, a nie promptowe. Dlatego temat promptowania w firmach omawiam osobno, z podejściem praktycznym.

Szczegółowo pisałem o tym, dlaczego prompt engineering przestał wystarczać w 2026 roku. Tamten tekst dotyczył głównie jakości odpowiedzi, tutaj chodzi o rzecz ostrzejszą: o poprawność, którą da się policzyć.

Test na 100 promptów: skąd bierzesz pytania i kto je pisze

Zestaw ewaluacyjny powstaje z prawdziwego ruchu, nie z głowy. Sto do dwustu realnych pytań ze znanymi poprawnymi odpowiedziami, wziętych z faktycznych zgłoszeń. Zestaw pisany przez zespół, który budował system, jest bezużyteczny, bo pokryje pytania, które zespół już umie rozwiązać. Brzmi to jak drobiazg, ale to najtańsza decyzja w całym wdrożeniu.

Pytania dzielisz na cztery wiadra, bo każde wymaga innego sprawdzenia:

• odpowiedź prawdziwa w świecie, ale nie ma jej w Twoich dokumentach (asystent musi odmówić albo oznaczyć brak pokrycia),
• odpowiedź jest w dokumencie, ale wyszukiwanie jej nie znajduje (wada indeksu, nie modelu),
• wyszukiwanie znajduje właściwy fragment, a model go niepoprawnie czyta (wada generowania),
• odpowiedź jest poprawna i dobrze uźródłowiona (to Twoja linia bazowa, bez niej nie masz z czym porównać).

Przy 100 pytaniach licz się z tym, że złote odpowiedzi pisze osoba, która zna domenę, a nie programista. Zajmuje to więcej czasu niż samo puszczenie testu, ale to jedyna praca, która się nie psuje po dwóch zmianach modelu.

Test puszczasz przy każdej zmianie promptu, modelu, sposobu dzielenia dokumentów na fragmenty albo modelu embeddingów. Ostatnia pozycja jest podstępna: zmiana embeddingów przebudowuje cały indeks i po cichu zmienia to, co system pobiera dla każdego pytania, które dziś działa dobrze. Metoda porównywania konfiguracji po odsetku halucynacji jest przy tym standardowa, bo dopiero ona pozwala stwierdzić, która wersja jest lepsza.

Ten sam schemat, tylko na innych pytaniach, stosowałem przy porównaniu modeli na polskim tekście. Tam zebrałem 25 zadań i mierzyłem wynik dla każdego modelu osobno.

Cztery pomiary, które warto liczyć

Osadzenie twierdzeń. Rozbija odpowiedź na pojedyncze twierdzenia i sprawdza, czy każde ma pokrycie w pobranym tekście. Drugi model dostaje wyłącznie pobrany fragment i jedno zdanie, po czym odpowiada, czy fragment to zdanie potwierdza. Jedna zasada jest tu ważniejsza od reszty: sprawdź tego sędziego, zanim mu zaufasz, na zestawie ze znanymi odpowiedziami. Sędzia, który zgadza się ze wszystkim, jest gorszy niż brak sędziego.

Pusty i słaby retrieval. To najbardziej opłacalna pozycja w logach, a większość zespołów jej nie ma. Zapisujesz każde zapytanie, przy którym wyszukiwanie nie zwróciło nic albo nic powyżej progu trafności, i obok dopisujesz, co asystent i tak odpowiedział. Tu jest najwięcej cichego zmyślania: pusta lista dokumentów, a system i tak wyprodukował pełny akapit. Przy wdrożeniu na 500 tys. rekordów weryfikacja każdego twierdzenia liczbowego względem źródłowego fragmentu, zanim odpowiedź wróci, jest jedną regułą, która sama w sobie robi największą różnicę.

Rozjazd między narzędziem a tekstem. Jeśli system ma dostęp do API, porównujesz liczbę w odpowiedzi z liczbą zwróconą przez narzędzie. To kontrola czysto mechaniczna, bez modelu w pętli, więc jest najtańsza i najbardziej wiarygodna.

Przegląd ludzki w ogonie, nie w losowej próbce. Pięćdziesiąt losowych odpowiedzi tygodniowo głównie potwierdza, że łatwe pytania nadal są łatwe. Ludzie patrzą tam, gdzie przyrządy pokazały problem: wysoki odsetek odmów, puste pobrania, długie odpowiedzi bez cytowań.

Pozostałe mechanizmy, które faktycznie trzymają odpowiedź w ryzach, opisałem osobno w zestawieniu 9 technik ograniczania halucynacji AI, od RAG po human-in-the-loop.

Do tego dochodzi dokładność cytowań, osobno. Cytat, który się nie rozwiązuje, i cytat, który się rozwiązuje, ale nie wspiera twierdzenia, to dwie różne klasy błędu. W praktyce pierwsza jest częstsza, a jej skutki w obrocie prawnym są najdroższe. W sierpniu 2025 dwóch prawników w Kolorado zapłaciło po 3000 dolarów za około 30 wadliwych cytowań. Skala nie jest stabilna: kary w pojedynczych sprawach rosły z około 5000 dolarów w 2023 roku do 55 597 dolarów w 2025, czyli jedenaście razy w ciągu osiemnastu miesięcy. Regresja jest wyraźna też tam, gdzie spraw było niewiele: w jednej z nich orzeczenie sięgnęło 110 204,38 dolara.

Jak to wygląda w praktyce i ile kosztuje

Badanie 300 przypadków klinicznych zweryfikowanych przez lekarzy dało wynik około 66% halucynacji w streszczaniu, spadający do około 44% po zastosowaniu ustrukturyzowanej instrukcji mitygacyjnej. To jednocześnie najlepsza i najgorsza wiadomość: mitygacja działa, ale nie przy zerze.

Przy kosztach nie znajdziesz wiarygodnych kwot w złotych ani euro, bo nikt tego nie publikuje. Jedyne, co da się powiedzieć konkretnie: ocena oparta na rozbijaniu odpowiedzi na fakty atomowe i sprawdzaniu każdego osobno jest 50 do 100 razy droższa od prostej kontroli zgodności z ustalonym dokumentem. To nie jest problem do rozwiązania na etapie budżetu, tylko do zaprojektowania: w pierwszej wersji wystarczy kontrola mechaniczna i pusty retrieval, a pełna weryfikacja twierdzeń wchodzi dopiero tam, gdzie odpowiedź jest kosztowna w skutkach.

Kolejna sprawa jest mniej wygodna, ale warto ją znać. Na benchmarku wiary, na którym testowano 26 czołowych modeli, odsetek halucynacji rozciągał się od 22% do 94%. To nie jest hałas pomiarowy, to różnica rzędu czterech razy między modelem a modelem. Wybór modelu jest decyzją o jakości, a nie o kwestii estetycznej.

Jeśli wybór modelu jest w Twoim przypadku realnym dylematem, rozpisałem się o tym, jak wygląda wybór modelu po koszcie tysiąca zadań automatyzacji.

Społecznościowe badanie nad modelami odpowiadającymi na pytania w stylu „w co użytkownik wierzy” pokazało, że ta sama zmiana promptu potrafi zbić dokładność z 98,2% do 64,4%. Jeśli Twój asystent ma dostęp do historii rozmów, to jest dokładnie ten mechanizm: użytkownik może skierować go w stronę błędu jednym zdaniem.

Ryzyko, które dotyczy Ciebie jako firmy

Najbardziej zaskakujący wyrok dotyczył linii lotniczych. Sąd uznał, że chatbot jest częścią serwisu, mimo że ma komponent interaktywny, i nakazał wypłatę odszkodowania za błędną informację o warunkach bagażowych. Kwota różni się zależnie od źródła: jeden serwis podaje 812,02 dolara, inny 650,88 dolara. Nie zgadzam się tu wyrównywać, bo to dwie różne kwoty z dwóch orzeczeń albo dwie waluty w jednym zapisie. Sam wniosek jest jednoznaczny: odpowiedzi Twojego asystenta są Twoimi oświadczeniami, nawet jeśli sformułował je model.

Po stronie europejskiej obowiązki przejrzystości z AI Act obowiązują od 2 sierpnia 2026. Co istotne, regulacja nie wymaga, żebyś miał rację. Wymaga, żebyś ujawnił, że po drugiej stronie jest maszyna, i oznaczył treści generowane. Halucynacje są tu osobnym problemem, ale nie regulacyjnym.

Inna sprawa to RODO i dane osobowe. Gdy model wymyśla fakty o konkretnej osobie, są to nieprawidłowe dane osobowe, a RODO nakazuje ich sprostowanie. Organizacja noyb złożyła skargę w kwietniu 2024 właśnie o odmowę sprostowania zmyślonej daty urodzenia, gdy OpenAI odpowiedziało, że może jedynie blokować takie odpowiedzi. Blokowanie to nie jest sprostowanie.

Przy okazji warto przeglądnąć jak zbudować agenta w n8n z pamięcią, narzędziami i człowiekiem w pętli. Tam rozdzieleniem uprawnień do odczytu i zapisu zajmuję się od strony architektury.

Skala rynku wyjaśnia, dlaczego to nie jest problem jednej firmy. Wartość rynku modeli językowych szła z 10,5 miliarda dolarów w 2022 roku do prognozowanych 40,8 miliarda w 2029, przy 21,4% rocznego wzrostu. Liczba udokumentowanych incydentów w bazie AI Incident Database wzrosła z 233 w 2024 roku do 362 w 2025. Jednocześnie udział firm bez żadnej polityki odpowiedzialnego AI spadł z 24% do 11%, więc świadomość ryzyka rośnie, ale tempo zmian orzecznictwa jest szybsze niż tempo wdrażania zabezpieczeń.

Co zrobić w pierwszym tygodniu

Nie zaczynaj od kupowania narzędzia do ewaluacji. Zrób jedną rzecz: przez siedem dni loguj zapytania, przy których wyszukiwanie nie zwróciło nic powyżej progu trafności, razem z odpowiedzią, którą system mimo to wyprodukował. Zero konfiguracji, zero nowego narzędzia, jeden plik.

Po tygodniu wybierasz z tabeli najmniejszy mechanizm, który zamyka największą część tych przypadków. Zwykle jest to ścieżka odmowy, bo to jakiś dzień pracy, a zamienia całą listę z cichego zmyślania na widoczne luki. Odpowiedź, na którą nie masz pokrycia, ma brzmieć „nie mam tego”, a nie akapit z prawdopodobnie wyglądającym faktem.

Dopiero potem dokładasz 100 pytań z poprzednich zgłoszeń i ustawiasz próg, który dla Twojego procesu jest akceptowalny. Próg ustalasz sam, bo twoja firma, twoje ryzyko i twoja tolerancja błędu. Warto tylko pamiętać, że odsetek, który wygląda jako bezpieczny w prezentacji, szybko rośnie, gdy Twój system odpowiada tysiąc razy dziennie.