„Halucynacja” nie jest problemem kosmetycznym. W komunikacji zewnętrznej i procesach regulowanych to ryzyko
operacyjne: nieprawdziwe tezy, zmyślone cytowania, błędne decyzje. Ten przewodnik porządkuje temat
w sposób wdrożeniowy: źródła, ograniczenia, weryfikacja.
Czas czytania: ~12–16 minZastosowanie: produkcjaAktualizacja: 4 stycznia 2026
Sygnały ostrzegawcze
kategoryczne tezy bez źródeł („na pewno”, „zawsze”)
cytowania, które nie istnieją albo nie pasują do tezy
zbyt szczegółowe liczby bez pochodzenia
odpowiedź „ładna”, ale niezgodna z procedurą
sprzeczność między fragmentami tej samej odpowiedzi
Definicja robocza:
Halucynacja to treść wygenerowana jako fakt lub uzasadnienie, która nie ma podstaw w dostarczonych źródłach
(kontekście, dokumentach, narzędziach) albo jest z nimi sprzeczna — przy jednoczesnym wysokim tonie pewności.
1. Taksonomia praktyczna
W produkcji warto rozróżniać typy halucynacji, ponieważ mają różne przyczyny i różne metody ograniczania.
Typ
Objaw
Typowa przyczyna
Najlepsza dźwignia
Faktograficzna
„Zmyślony fakt” (liczba, termin, funkcja).
Brak źródeł lub niska trafność retrieval.
RAG + cytowania + gating.
Cytowań / źródeł
Zmyślone referencje, nieistniejące dokumenty.
Brak kontraktu cytowań i walidacji.
Wymuszenie cytowań + walidator źródeł.
Narzędziowa
Model „udaje”, że wykonał zapytanie / operację.
Brak bramki narzędziowej (tool gateway).
Kontrolowane narzędzia + logi wykonania.
Proceduralna
Treść brzmi poprawnie, ale łamie proces (np. compliance).
Brak polityk i checklist w kontekście.
Policy‑as‑code + checklisty + reviewer.
Redukcja halucynacji jest procesem: źródła + ograniczenia + weryfikacja. W pojedynczym promptcie nie ma na to miejsca.
2. Dlaczego halucynacje się zdarzają
Zjawisko jest naturalną konsekwencją tego, jak LLM działa: model tworzy najbardziej prawdopodobną kontynuację tekstu.
Jeżeli nie ma wiarygodnych podstaw, wypełnia luki. Najczęstsze powody w systemach produkcyjnych:
brak lub niedobór źródeł (kontekst jest zbyt ubogi albo nieaktualny),
zbyt duża swoboda generacji (parametry dekodowania ustawione „kreatywnie”),
sprzeczne dane (różne wersje procedur, brak precedence),
brak walidacji (nikt nie sprawdza cytowań, schematu, PII),
mieszanie instrukcji i danych (np. prompt injection z dokumentów).
Uwaga:
Halucynacja to nie tylko „błędna informacja”. Często jest to błędna pewność.
Dlatego standard językowy powinien ograniczać absoluty („na pewno”, „gwarantujemy”) w treściach zewnętrznych.
3. Redukcja halucynacji: 7 dźwigni, które działają
Jeśli odpowiedź ma być faktograficzna, model musi dostać źródła — oraz obowiązek cytowania.
Dobre praktyki: wersjonowanie dokumentów, ograniczenia uprawnień, minimalna liczba trafnych fragmentów,
cytowania inline.
Format‑first jest prostą metodą ograniczenia przestrzeni odpowiedzi: sekcje, JSON Schema, limity długości,
obowiązkowe zastrzeżenia. Na poziomie procesu: checklisty „pass/fail”.
Stabilny wzorzec produkcyjny: najpierw generacja, potem weryfikacja regułowa i/lub modelowa.
Weryfikator nie musi „myśleć” — ma sprawdzić zgodność z kontraktem: cytowania, schemat, PII, zakazane zwroty.
Model nie powinien „udawać” operacji. Jeżeli system korzysta z narzędzi (wyszukiwarka, baza danych),
wykonanie musi być kontrolowane i logowane. Wyniki narzędzi są częścią kontekstu, nie domysłem modelu.
Dla treści operacyjnych i faktograficznych należy ograniczać swobodę: niska temperatura, jawne stop criteria,
ograniczenie długości. Kreatywność jest kosztowna, gdy wynik ma konsekwencje.
Jeżeli retrieval jest słaby albo brak danych, lepiej zebrać brakujące informacje albo odmówić, niż „wymyślać”.
To wymaga polityki: kiedy system ma powiedzieć „nie mam podstaw”, a kiedy eskalować do człowieka.
Halucynacje należy mierzyć: golden set, metryki naruszeń polityk, sampling do review, alerty.
Bez tego organizacja nie wie, czy zmiana polityk, źródeł albo modelu poprawiła sytuację.
4. Ewaluacja i audyt: minimalny standard
Poniżej przykład minimalnego test case’u, który można uruchamiać przy zmianie polityk lub źródeł:
test_case:
id: "refund.policy.017"
context_packet: "support.reply.v1@1.2.0"
input:
ticket: "Klient prosi o zwrot po 45 dniach..."
expected:
must_include:
- "informacja o terminie"
- "prośba o numer zamówienia"
must_not_include:
- "gwarantujemy"
- "na pewno"
require_citations: true
Najpierw dowody (źródła), potem ograniczenia (format, reguły), na końcu weryfikacja.
W odwrotnej kolejności zwykle „gasi się pożary”, zamiast budować stabilność.
