Czym są halucynacje i dlaczego się pojawiają
Halucynacja w LLM to wygenerowanie informacji, która brzmi wiarygodnie, ale jest faktycznie nieprawdziwa lub nieuzasadniona. Nie jest to „błąd” w sensie awarii systemu — to konsekwencja sposobu działania modeli językowych. LLM nie „wie” w taki sposób jak baza danych — przewiduje najbardziej prawdopodobny następny token, na podstawie statystyki uczenia. Gdy w prompcie pojawia się pytanie, na które model nie ma dobrego pokrycia w danych treningowych, generuje „najbardziej prawdopodobnie brzmiącą” odpowiedź. Często ta odpowiedź jest poprawna. Czasem — nie.
Typowe scenariusze halucynacji w zastosowaniach biznesowych:
- Cytowanie nieistniejących orzeczeń sądów lub paragrafów ustaw przy doradztwie prawnym
- Wymyślanie nazw funkcji, klas lub bibliotek przy generowaniu kodu
- Podawanie nieprawidłowych statystyk lub dat w raportach
- Wymyślanie kontaktów, adresów, numerów telefonów
- Mieszanie faktów dotyczących różnych firm lub osób o podobnych nazwach
Warstwa 1 — Grounding (RAG)
Najskuteczniejsza pojedyncza technika redukcji halucynacji to grounding — dostarczenie modelowi konkretnych dokumentów lub danych jako kontekst, z którego ma czerpać odpowiedzi. Klasyczny RAG (Retrieval-Augmented Generation):
- Pytanie użytkownika → wyszukanie najbardziej trafnych fragmentów dokumentów (vector search w bazie pgvector / Qdrant / Milvus)
- Fragmenty + pytanie → prompt z instrukcją „odpowiedz wyłącznie na podstawie poniższych dokumentów”
- Odpowiedź modelu → weryfikacja, że zawiera cytaty/referencje do źródeł
RAG redukuje halucynacje typowo o 60-80% w zastosowaniach typu „odpowiadaj na pytania o naszą bazę wiedzy”. Nie eliminuje ich całkowicie — model może wciąż „zinterpretować” dokumenty w sposób nieuprawniony. Stąd potrzebne kolejne warstwy.
Warstwa 2 — Self-consistency i ensemble
Self-consistency to technika polegająca na zadaniu tego samego pytania kilkakrotnie (lub kilku różnym modelom) i porównaniu odpowiedzi. Gdy odpowiedzi są spójne — wysokie zaufanie. Gdy różnią się — sygnał, że temat jest niepewny.
Wariant praktyczny: zapytaj Claude Sonnet, Llama 70B i Bielika o to samo pytanie. Jeśli wszystkie trzy zwracają tę samą liczbę, datę, fakt — prawdopodobnie poprawne. Jeśli się różnią — eskalacja do człowieka lub bardziej kosztownego modelu (Opus). Ten wzorzec, zaimplementowany w 8-poziomowym routingu LLM, łączy redukcję kosztu z poprawą wiarygodności.
Warstwa 3 — Evaluation pipelines
Produkcyjne wdrożenie LLM bez evaluation pipeline to jak pisanie kodu bez testów. Konkretne metryki:
- Faithfulness — czy odpowiedź wynika z dostarczonych dokumentów. Mierzone przez drugi model AI (LLM-as-judge) lub bibliotekę typu RAGAS, deepeval.
- Answer relevance — czy odpowiedź adresuje pytanie użytkownika.
- Context precision — czy najlepsze fragmenty zostały zwrócone przez retrieval (jakość vector search).
- Groundedness score — odsetek twierdzeń w odpowiedzi, dla których można wskazać źródło w kontekście.
Każdy nowy build aplikacji opartej na LLM powinien przechodzić zestaw 50-500 pytań ewaluacyjnych z znanym ground truth. Jeśli faithfulness spada poniżej 90% — deployment blocked.
Warstwa 4 — Guardrails i walidacja outputu
Guardrails to reguły walidujące output LLM przed dostarczeniem go użytkownikowi. Przykłady:
- Schema validation — output musi spełniać konkretny schemat (JSON Schema, Pydantic). Halucynacje typu „wymyślone pola” są wykrywane mechanicznie.
- Forbidden patterns — wykrywanie i blokowanie wzorców niedopuszczalnych (PII bez maskowania, dane finansowe poza kontekstem, treści potencjalnie szkodliwe).
- Citation enforcement — każde twierdzenie faktyczne musi mieć cytat źródła. Jeśli model nie cytuje — odpowiedź jest odrzucana.
- Numeric range validation — liczby w outputie sprawdzane pod kątem sensu (np. cena > 0, data ≤ dzisiaj, procent w zakresie 0-100).
- Cross-reference check — porównanie outputu z bazą faktów (np. KRS, dictionary cytatów ustaw).
Biblioteki: Guardrails AI, NeMo Guardrails, instructor (dla schema enforcement). Implementacja własna często prostsza i tańsza w utrzymaniu.
Warstwa 5 — Human-in-the-loop
Dla aplikacji wysokiego ryzyka (decyzje prawne, medyczne, finansowe, kadrowe) warstwa human-in-the-loop jest niezbędna. Modele AI nie podejmują finalnej decyzji — wspierają człowieka. Konkretne wzorce:
- Draft + review — AI generuje pierwszą wersję dokumentu/odpowiedzi, człowiek weryfikuje i akceptuje przed wysłaniem.
- Confidence threshold — odpowiedzi o niskim confidence (z self-consistency lub explicit confidence asking) automatycznie eskalowane do człowieka.
- Random sampling QA — 5-10% wszystkich odpowiedzi LLM jest manualnie audytowane, niezależnie od confidence — bazowa metryka jakości w czasie.
- Feedback loop — użytkownik może zaznaczyć błędną odpowiedź; system uczy się i ulepsza retrieval, prompty, parametry.
Pomiar — jak wiedzieć, że redukcja działa
Konkretne metryki produkcyjne, które warto monitorować:
- Halucynacja rate — odsetek odpowiedzi sklasyfikowanych jako halucynacja w ewaluacji manualnej (sampling). Cel: poniżej 2% dla aplikacji business-critical.
- User feedback rate — odsetek użytkowników, którzy oznaczyli odpowiedź jako błędną.
- Escalation rate — odsetek zapytań eskalowanych do człowieka. Zbyt niski (poniżej 5%) — system prawdopodobnie pomija przypadki niepewne. Zbyt wysoki (powyżej 30%) — system nie dostarcza wartości automatyzacyjnej.
- Faithfulness score w testach regresyjnych — trend miesięczny.
- Time-to-correction — od wykrycia halucynacji do wdrożenia poprawki (lepszy retrieval, nowy guardrail, fine-tuning).
Wnioski dla decydentów
Halucynacje są zarządzalne — wymagają inwestycji w architekturę obronną na wielu warstwach. Firmy, które wdrażają LLM bez tej architektury, prędzej czy później natrafią na poważny incydent (publikacja błędnej informacji klientowi, błędna decyzja na podstawie halucynowanych danych, reputacyjne uszkodzenie). Koszt zbudowania pełnego stacku obronnego (RAG + evaluation + guardrails + human-in-the-loop) to typowo 15-30% kosztu samego wdrożenia LLM — i jest to inwestycja absolutnie konieczna dla zastosowań produkcyjnych. Konsekwencje pominięcia są asymetryczne: niski koszt zaniechania w 95% przypadków, katastrofalny w 5%.