Halucynacje AI - skąd się biorą i jak je ograniczyć

Halucynacja AI — w dokumentach NIST nazywana konfabulacją — to pewnie brzmiąca treść, która jest fałszywa albo nie ma podstawy w źródłach. To ryzyko całej klasy modeli generatywnych, nie wyłącznie jednego dostawcy; NIST wiąże je z mechanizmem generowania odpowiedzi z rozkładu danych treningowych.

Nie ma jednej techniki, która zagwarantuje brak takich błędów. Lepsze pytanie brzmi: jak ograniczyć ich częstość, wykrywać brak podstawy i zmniejszyć skutek pomyłki.

Skąd się biorą halucynacje

Cztery mechanizmy, każdy z inną obroną:

1. Model nie ma potrzebnej informacji. Pytasz o Twoją procedurę, której model nigdy nie widział. Wypełnia lukę tym, co statystycznie pasuje.
2. Model dostał informację niepełną albo sprzeczną. Dwie wersje dokumentu, jedna nieaktualna. Model wybierze jedną i nie powie, że były dwie.
3. Pytanie zakłada nieprawdę. „Który paragraf naszej umowy reguluje kary za opóźnienie?” — gdy takiego paragrafu nie ma. Model chętnie go wskaże, bo pytanie sugerowało, że istnieje.
4. Zadanie wymaga precyzji, której model nie ma z natury. Liczenie, przytaczanie dokładnych kwot, cytowanie z pamięci.

Dodanie trafnego kontekstu pomaga przede wszystkim przy braku informacji, ale samo nie rozwiązuje sprzecznych źródeł, sugestywnego pytania ani zadań wymagających deterministycznej precyzji. Te przypadki wymagają także kontroli źródeł, projektu instrukcji i zabezpieczeń poza modelem.

Sześć technik, które realnie działają

1. Ugruntowanie na własnych danych

Podstawa: model dostaje trafne fragmenty źródeł przed odpowiedzią. To jest RAG. Może ograniczyć błędy wynikające z braku wiedzy, ale nie gwarantuje poprawności: wyszukiwarka może pobrać zły fragment, a model może go źle zinterpretować.

2. Wymóg cytowania źródła

Odpowiedź bez wskazania fragmentu, na którym się opiera, może być odrzucona albo skierowana do człowieka. Cytat nie dowodzi jeszcze, że wniosek jest poprawny, ale umożliwia szybkie sprawdzenie i ujawnia sytuację, w której system nie ma podstawy.

3. Wyraźne pozwolenie na „nie wiem”

Model jest optymalizowany do wygenerowania odpowiedzi, więc trzeba mu wprost dać bezpieczną alternatywę: jeśli w dostarczonych fragmentach nie ma podstawy, właściwym wynikiem jest informacja o braku danych plus wskazanie, gdzie szukać. To niedroga zmiana instrukcji i logiki przepływu, ale jej skuteczność trzeba sprawdzić na pytaniach bez odpowiedzi.

4. Rozdzielenie: model rozumie, kod liczy

Arytmetykę, porównania i twarde reguły warto wykonywać w kodzie, a modelowi zostawić interpretację pytania i przedstawienie wyniku. Ogranicza to błędy obliczeniowe, ale nadal trzeba walidować zapytanie wygenerowane przez model, typy danych i sposób prezentacji rezultatu.

5. Weryfikacja drugim przebiegiem

Osobny krok sprawdza, czy odpowiedź faktycznie wynika z dostarczonych fragmentów. Może to być reguła, porównanie z danymi ustrukturyzowanymi albo drugie wywołanie modelu z wąskim zadaniem. Drugi model nie jest niezależnym dowodem i może powtórzyć ten sam błąd, dlatego przy wysokiej stawce potrzebny jest człowiek lub deterministyczna kontrola. W zadaniach wieloetapowych można wydzielić osobną rolę weryfikatora, ale jej wartość również trzeba zmierzyć.

6. Człowiek na końcu tam, gdzie stawka jest wysoka

Tryb „system przygotowuje, człowiek zatwierdza” nie jest porażką automatyzacji. To projektowa decyzja o tym, gdzie postawić granicę. Przy odpowiedziach do klienta w sprawach umownych poziom kontroli powinien wynikać z ryzyka, polityki firmy i oceny prawnej; sam model nie powinien być ostatecznym decydentem.

Jedna technika, która tylko wygląda na rozwiązanie

Instrukcja w prompcie: „nie wymyślaj, odpowiadaj tylko na podstawie faktów”.

To pomaga trochę i warto ją mieć, ale traktowanie jej jako zabezpieczenia jest błędem. Prompt jest wskazówką, nie ograniczeniem technicznym — model może jej nie posłuchać, zwłaszcza gdy pytanie jest sugestywne albo kontekst niepełny. Zabezpieczeniem jest to, że system nie przyjmuje odpowiedzi bez źródła, a nie to, że poprosiliśmy model, żeby był rzetelny.

Jak zmierzyć, czy jest lepiej

Bez pomiaru wszystkie te techniki to opowieść. Minimalna wersja pomiaru:

1. Reprezentatywny zestaw realnych pytań z Twojego procesu, z oczekiwaną odpowiedzią, w tym pytania, na które poprawną odpowiedzią jest „nie wiem”. Pilotaż można zacząć od 30–50 przypadków, jeśli obejmują ważne kategorie i ryzyka, a następnie rozbudowywać zestaw o wykryte błędy.
2. Po każdej zmianie liczymy trzy rzeczy: ile odpowiedzi poprawnych, ile błędnych, ile razy system przyznał się do braku danych.
3. Wskaźnik, na który patrzymy szczególnie uważnie: ile razy system odpowiedział pewnie i błędnie. To szczególnie ryzykowny błąd, bo może pozostać niezauważony. Fałszywe „nie wiem” także ma koszt — zwiększa liczbę eskalacji i niezałatwionych spraw — dlatego oba typy błędów trzeba raportować osobno.

Kiedy ryzyko halucynacji dyskwalifikuje pomysł

• Gdy pomyłka jest nieodwracalna. Przelew, decyzja kadrowa, zgłoszenie do urzędu. Tu chcemy kodu i człowieka.
• Gdy nikt nie umie ocenić poprawności odpowiedzi. Jeśli nie ma kto zweryfikować wyniku, nie zauważysz momentu, w którym system zaczął się mylić.
• Gdy dane źródłowe są sprzeczne i nikt nie chce tego uporządkować. System będzie wtedy wiarygodnie prezentował nieaktualne informacje, co jest gorsze niż brak systemu.

Najczęstsze pytania

Czy mocniejszy model halucynuje mniej?

Może, ale wynik zależy od zadania, języka, danych i sposobu oceny. Nie warto zakładać poprawy z samej nazwy modelu — trzeba porównać modele na tym samym zestawie pytań, a ugruntowanie i kontrolę pozostawić niezależnie od wyniku.

Czy da się osiągnąć zero halucynacji?

Nie należy tego obiecywać w otwartym systemie generatywnym. Realny cel projektowy to zmierzone ryzyko, wykrywanie odpowiedzi bez podstawy i ograniczenie uprawnień tak, żeby pojedynczy błąd nie powodował nieodwracalnego działania.

Kto powinien pilnować jakości po wdrożeniu?

Właściciel procesu po Twojej stronie plus cykliczny przebieg zestawu ewaluacyjnego. Jakość systemu AI może pogarszać się bez oczywistej awarii, na przykład po zmianie modelu, danych albo zachowań użytkowników.

---

W systemie opartym na wiedzy projektujemy regułę, która zatrzymuje albo eskaluje odpowiedź bez wystarczającej podstawy, i mierzymy jakość zestawem pytań, a nie wrażeniem. Zobacz second brain dla firm albo napisz, jakie pytania ma obsługiwać Twój system.