Halucynacje LLM: 5 technik redukcji w środowisku produkcyjnym

Model pewnie odpowiada na pytanie, na które odpowiedzieć poprawnie nie potrafi. Wymyśli cytat, doda brakującą liczbę, potwierdzi założenie zawarte w pytaniu — a cała odpowiedź brzmi przekonująco. To właśnie nazywamy halucynacją (ang. *hallucination*): generowaniem wiarygodnego, lecz faktycznie nieprawidłowego wyniku. W środowisku eksperymentalnym irytuje. W produkcji — przy pracy z dokumentacją, umowami, normami technicznymi lub wymaganiami klientów — powoduje realne straty.

Praktyka pokazuje, że bazowy poziom halucynacji modeli frontier wynosi od kilku do kilkudziesięciu procent przy pytaniach specjalistycznych, gdzie model nie dysponuje wystarczającym groundingiem. Celem tego artykułu nie jest obietnica systemu wolnego od halucynacji — taki nie istnieje. Celem jest przedstawienie pięciu technik, które potrafią ten problem w produkcji znacząco ograniczyć, oraz wyjaśnienie, dlaczego każda działa inaczej i dlaczego żadna nie wystarczy sama w sobie.

Dlaczego halucynacje nie znikają całkowicie

Zanim przejdziemy do technik, trzeba zrozumieć przyczynę źródłową. LLM nie wyszukują faktów — generują tokeny na podstawie tego, co jest statystycznie prawdopodobne w danym kontekście. Model nie odróżnia stanu „wiem" od „nie wiem": jeśli nie jest explicite wytrenowany lub instruowany, aby wyrażał niepewność, domyślnie generuje płynną i wiarygodną odpowiedź.

Rozmiar modelu sam w sobie problemu nie rozwiązuje — większy model może halucynować pewniej, ponieważ jego zdolności językowe są lepsze, a wyniki brzmią bardziej przekonująco. Bez strategii groundingu wzrost modelu nie zmniejsza ryzyka, a w niektórych przypadkach wręcz je zwiększa.

Wniosek dla wdrożeń produkcyjnych: halucynacjami należy zarządzać architektonicznie, a nie tylko wybierać lepszy model.

Technika 1: Grounding przez RAG z cytowalnymi źródłami

RAG (*Retrieval-Augmented Generation*) to dziś najpowszechniejszy mechanizm ograniczania halucynacji przy pytaniach faktograficznych. Zasada jest prosta: zamiast odpowiadać z pamięci parametrycznej (z tego, czego nauczył się podczas treningu), model otrzymuje w kontekście odpowiednie fragmenty ze zweryfikowanych dokumentów. Odpowiedź musi wtedy wynikać z tego kontekstu.

Samo dołączenie dokumentów do promptu nie wystarczy. Dobry system groundingu ma trzy warstwy:

• Retrieval — wyszukiwanie wektorowe (np. przez Qdrant lub pgvector) uzupełnione wyszukiwaniem hybrydowym (BM25 + wektory), aby znaleźć nie tylko semantycznie podobne, ale i trafne słownikowo fragmenty
• Reranking — model cross-encoder weryfikuje kolejność wyników; bez rerankingu retrieval zwraca zarówno trafne, jak i mniej trafne chunki, reranker znacząco poprawia precyzję doboru
• Cytowalność — model dostaje instrukcję: każde twierdzenie musi być poparte konkretnym źródłem z odnośnikiem do dokumentu i strony; jeśli źródło nie istnieje, model niczego nie wymyśla

Cytowalność jest kluczowa nie tylko dla precyzji, ale też dla weryfikowalności: użytkownik widzi, skąd pochodzi informacja, i może ją sprawdzić. W praktyce znacznie zwiększa to zaufanie i pozwala wykryć przypadki, gdy model zignorował cytat lub go sfabrykował. Więcej o ocenie pipeline RAG przeczytasz w artykule Jak ewaluować RAG (RAGAS), gdzie opisujemy metryki faithfulness i answer relevance.

Ważna uwaga: RAG nie rozwiązuje wszystkiego. Jeśli retrieval zwróci nieprawidłowe chunki (mismatch embeddingów, złe chunkowanie, nieaktualna baza danych), model może halucynować nawet z kontekstem — a co gorsza, halucynować z fałszywym cytatem. RAG to warunek konieczny, nie wystarczający.

Technika 2: Ustrukturyzowany wynik i walidacja programatyczna

Wolny tekst jest trudny do zweryfikowania. Jeśli model zwróci odpowiedź w ściśle zdefiniowanej strukturze — schemat JSON, model Pydantic, wyliczenie dozwolonych wartości — możemy maszynowo zwalidować wynik, zanim trafi do użytkownika lub kolejnego systemu.

Nowoczesne modele i frameworki obsługują structured outputs (*ustrukturyzowane wyniki*): model jest zmuszany do generowania tokenów zgodnych z podanym schematem. Halucynacja nie może więc wymyślić pola, którego schemat nie zawiera. Jeśli dozwolone pole risk_level przyjmuje wartości ["low", "medium", "high"], model nie może zwrócić "critical" ani nonsens.

W praktyce łączymy trzy kroki:

1. 1.Definicja schematu wyjściowego (np. JSON schema lub model Pydantic)
2. 2.Użycie structured outputs / JSON mode w wywołaniu API
3. 3.Programatyczna walidacja wyniku — jeśli wynik nie odpowiada schematowi, wywołanie jest powtarzane lub eskalowane do przeglądu ludzkiego

Podejście to działa najlepiej przy ograniczonych zadaniach: ekstrakcja encji, klasyfikacja, wypełnienie formularza, konwersja dokumentu do struktury. Dla wolnego tekstu (streszczenie, interpretacja) stosowalność jest ograniczona, ale nawet tu możemy walidować przynajmniej obecność wymaganych pól (np. sekcja „Źródła" lub „Ostrzeżenia").

Technika 3: Zezwolenie na „nie wiem" — kalibracja niepewności

Jednym z najprostszych i najskuteczniejszych kroków jest explicite zezwolenie modelowi na odpowiedź „nie wiem" lub „na podstawie dostępnych informacji nie jestem w stanie tego ocenić". Brzmi to trywialnie, ale większość produkcyjnych promptów o tym zapomina — a model domyślnie generuje odpowiedź, nawet gdy nie dysponuje informacjami.

Konkretnie w systemowym promptcie (ang. *system prompt*) rekomendujemy sformułowania w stylu:

• Jeśli odpowiedź nie wynika z dostarczonych dokumentów, explicite poinformuj, że informacja jest niedostępna.
• Nie domyślaj się ani nie wywnioskuj faktów, które nie są zawarte w kontekście.
• Jeśli nie jesteś pewny, wyraź stopień niepewności słowami („prawdopodobnie", „według dostępnych informacji").

Ważne jest, że kalibracja niepewności musi być aktywną instrukcją, a nie tylko brakiem zakazu halucynowania. „Nie halucynuj" nie wystarczy — model rozumie tę instrukcję, ale nie dysponuje mechanizmem jej wykonania bez explicitnych ram dla wyrażania niepewności.

W obszarach regulowanych (dokumenty prawne, dokumentacja techniczna, normy bezpieczeństwa) zalecamy jednocześnie zdefiniowanie reguły eskalacji: jeśli model nie jest w stanie odpowiedzieć z wystarczającą pewnością, odpowiedź powinna zawierać wezwanie do weryfikacji przez kompetentną osobę. To bezpośrednio zmniejsza ryzyko cichego błędu — sytuacji, gdy system odpowiada pewnie, a błąd pozostaje nieodkryty.

Technika 4: LLM-as-Judge — automatyczna weryfikacja wyników

LLM-as-Judge (*LLM jako sędzia*) to technika, w której drugi model językowy ocenia wynik pierwszego. W produkcji stosuje się ją do automatycznego wykrywania halucynacji, weryfikacji spójności z kontekstem i oceny jakości odpowiedzi — bez potrzeby angażowania recenzenta ludzkiego przy każdej odpowiedzi.

Typowy przepływ wygląda następująco:

1. 1.Główny model generuje odpowiedź
2. 2.Model weryfikujący otrzymuje trójkę: pytanie + kontekst źródłowy + wygenerowana odpowiedź
3. 3.Model weryfikujący ocenia: czy odpowiedź zawiera twierdzenia nieobsługiwane przez kontekst? Czy odpowiedź jest faktycznie spójna ze źródłami?
4. 4.Na podstawie wyniku odpowiedź jest albo dostarczona, zatrzymana, albo wysłana do przeglądu ludzkiego

Dla modelu weryfikującego zalecamy użycie takiego samego lub silniejszego modelu niż główny — słabszy weryfikator nie jest w stanie niezawodnie wykryć błędów silniejszego. W praktyce obserwujemy dobre wyniki przy kombinacji lokalnie działającego modelu głównego i weryfikatora frontier (np. klasa Claude Sonnet lub GPT-4o) dla odpowiedzi krytycznych.

Frameworki takie jak Langfuse lub Arize Phoenix pozwalają włączyć ten przepływ do produkcyjnego pipeline z logowaniem, alertowaniem i retrospektywną analizą. Więcej o całościowym podejściu do pomiaru jakości znajdziesz w artykule Jak zmierzyć jakość aplikacji LLM (evals).

Ograniczenie: LLM-as-Judge nie jest nieomylny — model weryfikujący również może „zgodzić się" z halucynowaną odpowiedzią, jeśli obie są spójne wewnętrznie, lecz faktycznie błędne. Dlatego łączymy go z groundingiem (technika 1) i regularnym ludzkim audytem próbki wyników.

Technika 5: Temperatura, sampling i prompt engineering

Ostatnia technika jest najtańsza we wdrożeniu, ale ma najmniejszy efekt bez pozostałych warstw. Mimo to jest istotna.

Temperatura (*temperature*) wpływa na losowość generowania. Niska temperatura (np. 0.0–0.2) produkuje bardziej deterministyczne, spójne wyniki — model wybiera najbardziej prawdopodobny token, nie losowy. Dla zadań faktograficznych (ekstrakcja, klasyfikacja, odpowiedzi na pytania z dokumentów) rekomendujemy niską temperaturę. Dla zadań kreatywnych lub generatywnych wyższa temperatura jest pożądana, ale jednocześnie zwiększa ryzyko odchyleń.

Prompt engineering na rzecz redukcji halucynacji ma kilka sprawdzonych zasad:

• Przykłady few-shot — pokaż modelowi przykłady prawidłowego zachowania, w tym przykłady, gdzie odpowiedź brzmi „nie wiem"; model uczy się tego zachowania w kontekście
• Explicite określenie formatu — „odpowiadaj wyłącznie na podstawie poniższych dokumentów, każde twierdzenie zakończ numerowanym cytatem"
• Instrukcje negatywne — „nie wywnioskuj informacji, które nie są explicite podane w kontekście"
• Chain-of-thought (*łańcuch myśli*) — przy złożonych pytaniach zachęć model, by przemyślał odpowiedź krok po kroku przed końcowym wynikiem; przy wrażliwych zadaniach znacząco to redukuje „skróty" do halucynowanej odpowiedzi

Uwaga: prompty są kruche — działają dla konkretnego modelu i wersji. Przy zmianie modelu lub wersji prompty wymagają ponownej ewaluacji. Prompt engineering to zatem działanie ciągłe, a nie jednorazowy wynik. Więcej na ten temat: Prompt engineering do produkcji.

Pięć technik razem

Żadna technika nie wystarczy sama. W praktyce łączymy je w warstwy:

• Warstwa podstawowa — RAG z cytatami + zezwolenie na „nie wiem" w systemowym promptcie
• Warstwa wynikowa — ustrukturyzowany wynik + walidacja programatyczna
• Warstwa weryfikacyjna — LLM-as-Judge dla odpowiedzi krytycznych
• Warstwa kalibracyjna — niska temperatura + prompt few-shot dla spójności

Efekt kombinacji jest znacznie większy niż suma poszczególnych technik. Systemy produkcyjne, w których wdrożyliśmy wszystkie cztery warstwy, osiągają znacznie niższy poziom błędów faktycznych niż systemy z jedną warstwą — rzędu dziesiętnych części procenta wobec kilku procent przy pytaniach specjalistycznych. Dokładne liczby zależą od domeny, jakości dokumentów źródłowych i sposobu ewaluacji.

Czego techniki nie naprawią

Dla kompletności: co nierzetelnie ogranicza halucynacje:

• Większy model — może halucynować pewniej; bez strategii groundingu nie pomoże
• Dłuższy kontekst — więcej danych w kontekście nie oznacza mniej halucynacji; model może ignorować relewantny kontekst lub błędnie go interpretować
• Prosty zakaz halucynowania w promptcie — model nie rozumie pojęcia „halucynowanie" w sposób, który pozwoliłby mu aktywnie temu zapobiegać; potrzebuje pozytywnych instrukcji dotyczących wyrażania niepewności
• Wyniki benchmarkowe modelu — MMLU i podobne benchmarki są nasycone i nie mierzą zachowania produkcyjnego w specjalistycznych domenach; wynik na leaderboardzie nie koreluje wiarygodnie ze wskaźnikiem halucynacji w Twojej konkretnej aplikacji

Najczęstsze pytania

Czy możliwe jest stworzenie systemu, który nigdy nie halucynuje?

Nie. LLM to stochastyczne modele generatywne — zawsze istnieje niezerowe prawdopodobieństwo halucynowanego wyniku. Celem nie jest zerowy wskaźnik błędów, lecz redukcja do akceptowalnego poziomu dla danego przypadku użycia oraz wprowadzenie mechanizmów wykrywania i wychwytywania błędów, zanim wyrządzą szkodę. Przy decyzjach krytycznych (prawnych, medycznych, bezpieczeństwa) przegląd ludzki pozostaje niezbędny.

Czy fine-tuning na danych firmowych pomoże ograniczyć halucynacje?

Jedynie częściowo i nie bezpośrednio. Fine-tuning (*dostrajanie modelu* na własnych danych) poprawia styl odpowiedzi, terminologię i format — ale nie poprawia precyzji faktycznej, jeśli model podczas inferencji nie otrzymuje odpowiedniego kontekstu. Do ograniczania halucynacji RAG jest typowo skuteczniejszym i tańszym podejściem. Fine-tuning i RAG wzajemnie się nie wykluczają — ich kombinacja ma sens w bardziej zaawansowanych wdrożeniach. Decydowanie między nimi opisujemy w artykule RAG vs fine-tuning — jak wybrać.

Jak sprawdzić, ile halucynuje nasza aplikacja LLM?

Systematyczna ewaluacja wymaga eval datasetu — zestawu pytań z poprawnymi odpowiedziami lub dokumentami źródłowymi — oraz frameworku ewaluacyjnego, takiego jak RAGAS (dla pipeline RAG) lub Langfuse (dla ogólnych aplikacji LLM). Automatyczna ewaluacja z LLM-as-Judge może objąć duże wolumeny, ale wymaga kalibracji względem oceny ludzkiej przynajmniej na próbce. Okresowy ludzki audyt wyników w produkcji zalecamy zawsze, nie tylko przy pierwszym wdrożeniu.

Czy niska temperatura zwiększa ryzyko stereotypowych lub niekompletnych odpowiedzi?

Tak, to realny trade-off. Niska temperatura zmniejsza zmienność — model konsekwentnie wybiera najbardziej prawdopodobne tokeny, co w skrajnych przypadkach może prowadzić do powtarzających się fraz lub pomijania mniej prawdopodobnych, lecz relewantnych informacji. W praktyce rekomendujemy temperaturę 0.1–0.3 dla zadań faktograficznych, nie bezwzględne zero, i łączenie jej z explicite instrukcjami dotyczącymi kompletności odpowiedzi.

Jaki jest koszt wdrożenia tych technik?

Koszty to przede wszystkim nakłady implementacyjne i operacyjne. Pipeline RAG wymaga bazy wektorowej, modelu embeddingów i logiki retrieval — przy rozwiązaniu self-hosted (np. Qdrant + open-weight model embeddingów) to kilka euro miesięcznie za infrastrukturę. LLM-as-Judge podwaja liczbę wywołań LLM dla wyników krytycznych, co zwiększa koszty API. Structured outputs są praktycznie bezkosztowe. Łączna inwestycja zależy od wolumenu, ale przy typowych aplikacjach firmowych (dziesiątki do setek zapytań dziennie) wzrost kosztów jest pomijalny wobec ryzyka cichego błędu w produkcji.

*Jeśli planujesz wdrożyć LLM w środowisku, gdzie precyzja faktyczna bezpośrednio wpływa na decyzje — od dokumentacji technicznej po wsparcie klientów czy compliance — chętnie pomożemy ocenić, która kombinacja technik ma sens dla Twojego konkretnego przypadku. MP Industrial Solutions ma doświadczenie w produkcyjnych wdrożeniach zarówno w środowisku przemysłowym, jak i regulowanym.*