Jak ograniczyć halucynacje AI: 9 technik od RAG po human-in-the-loop (z kodem n8n) 

Halucynacji AI nie da się wyeliminować, da się ją jednak ograniczyć do poziomu, przy którym Twój system nadaje się do pracy z prawdziwymi danymi. Dziewięć technik poniżej ustawia w kolejności, od najmocniejszej (dokumenty zamiast pamięci modelu) do ostatniej bramki (człowiek zatwierdza działanie). Każdą opisuję z konkretnym krokiem w n8n, bo tam buduję takie systemy dla firm.

Zacznę od uczciwego zastrzeżenia: żadna z tych technik nie daje gwarancji. Modele językowe przewidują kolejne słowa na podstawie prawdopodobieństwa, a nie prawdy, więc zawsze zostaje podłoga błędu. Pytanie brzmi nie „jak pozbyć się halucynacji", tylko jak niską uczynić tę podłogę w Twoim konkretnym procesie i jak ją mierzyć.

Czym jest halucynacja AI i dlaczego nie da się jej wyeliminować

Halucynacja to odpowiedź brzmiąca wiarygodnie i pewnie, która nie ma pokrycia: ani w dokumentach, które system pobrał, ani w rekordach, które umie odczytać. Ważne jest słowo „pokrycie", nie słowo „błąd" - zmyślona odpowiedź może przypadkiem okazać się trafna i dalej jest halucynacją, bo w momencie jej wypowiedzenia system nie miał do niej podstaw.

Warto odróżnić halucynację od zwykłej niepewności. Przy niepewności model używa sformułowań typu „prawdopodobnie" albo „nie mam pewności". Przy halucynacji po prostu tworzy treść brzmiącą na pewną. Do tego dochodzi podział praktyczny: halucynację wewnętrzną da się złapać mechanicznie, porównując odpowiedź z pobranym tekstem, a halucynacja zewnętrzna wymaga źródła spoza rozmowy - i większość systemów produkcyjnych jest na nią ślepa.

Skala problemu jest większa, niż sugeruje intuicja. W badaniach prawnych z 2024 roku modele ogólne odtwarzające odpowiedzi z pamięci (GPT-3.5, Llama 2, PaLM 2) halucynowały w 69-88% przypadków na ponad 200 tys. zapytań na model. Te same systemy oparte na retrievalu, czyli Lexis+ AI, Westlaw AI-Assisted Research i Ask Practical Law AI, schodziły do 17-33%. Zastrzeżenie jest tu ważne: to trzy różne zadania i trzy różne definicje halucynacji, więc każdy z tych słupków czytaj osobno. Jedyna liczba, która rządzi Twoimi decyzjami, to ta zmierzona na Twoich własnych pytaniach.

Skąd biorą się halucynacje? Nie tylko z „słabej" wiedzy modelu. Jeśli jakaś część danych występuje w korpusie dokładnie raz, model bazowy pomyli co najmniej piątą część pytań dotyczących tego faktu - i to jest statystyczna podłoga, której żaden prompt nie rusza. Do tego benchmarki zwykle oceniają odpowiedź zero-jedynkowo i nie dają punktów za „nie wiem", przez co wstrzymanie się wypada gorzej niż zgadywanie.

1. Retrieval RAG: podaj modelowi dokument, nie licz na jego pamięć

RAG, czyli retrieval augmented generation, polega na doklejeniu do promptu fragmentów dokumentów pobranych z Twojej bazy wiedzy, zamiast proszenia modelu o odpowiedź z głowy. W n8n buduje się to w czterech krokach: import danych i podłączenie bazy wektorowej, pocięcie i osadzenie fragmentów, dodanie agenta z podłączonym modelem, a na końcu zdolności wyszukiwania. W bibliotece szablonów widzisz wtedy węzły takie jak Google Drive Trigger, Edit Fields (Set), HTTP Request, AI Agent czy Ollama Chat Model.

n8n ma integracje z Pinecone, Qdrant, Supabase, Weaviate, Milvus, Zep, MongoDB Atlas i Postgres PGVector. Baza wektorowa to zwykła baza, która trzyma wektory - listy liczb opisujące fragmenty tekstu - i potrafi znaleźć te najbliższe zapytaniu.

Sama w sobie technika ta jednak nie wystarcza. Dokumentacja n8n mówi wprost, że RAG „mitiguates" halucynacje i zaraz potem dodaje, że może nie wyeliminować wszystkich błędów. Zgadzam się z tym zastrzeżeniem: retrieval ogranicza, nic nie usuwa.

Do tego dochodzi warunek, który decyduje o wdrożeniu: każde twierdzenie musi wskazywać fragment, z którego pochodzi, a zdanie bez fragmentu nie wychodzi. W n8n realizujesz to po stronie promptu i walidacji, nie w samej bazie. Przy okazji warto zerknąć na wzorce architektury agentów w n8n, bo pokazują RAG w szerszym kontekście przepływu. Jeśli dopiero zaczynasz z tą platformą, dlaczego polskie firmy automatyzują właśnie w n8n wyjaśnia, dlaczego to dobry wybór na pierwszy projekt.

2. Prompt anty-halucynacyjny i ścieżka odmowy

Prompt nie jest mechanizmem kontrolnym, ale jest darmowy i działa. Działa pod warunkiem, że dajesz modelowi jawną drogę do wycofania się, zamiast zakazywać mu kłamania. Sprawdzona konstrukcja wygląda tak:

Odpowiadaj wyłącznie na podstawie poniższych fragmentów.
Jeśli brakuje informacji - napisz: "Brak danych w materiałach".
Dołącz listę identyfikatorów źródeł.

Kluczowe jest tu „brak danych w materiałach" jako gotowa fraza odmowy. Sama ścieżka odmowy działa tak, że pusty albo słaby retrieval zwraca „nie mam tego" i drogę do człowieka zamiast akapitu. Efekt uboczny jest taki, że na dashboardzie widzisz spadek odsetka odpowiedzianych pytań - a to jest właśnie dowód, że mechanizm działa. Bez tego masz metrykę, która kłamie: system mierzony tym, ile odpowiedział, a nie tym, ile z tego było prawdą.

Przypominam tylko, że sama obróbka promptów ma granice. O tym, dlaczego prompt engineering sam w sobie już nie wystarczy, pisałem osobno - warto to przeczytać przed budowaniem całej strategii ochrony na warstwie tekstu.

3. Narzędzia zamiast pamięci

Jeśli asystent ma policzyć, sprawdzić status zamówienia albo podać kwotę z faktury, niech odczyta to z systemu źródłowego, zamiast odtwarzać z pamięci. Każde takie odczytanie usuwa całą kategorię zmyślania, bo liczba pochodzi z rekordu, a nie z rozkładu prawdopodobieństwa.

W n8n dajesz agentowi dostęp do narzędzi węzłami takimi jak HTTP Request tool, Workflow tool czy Nodes as tools. Kontrola jest czysto mechaniczna i nie wymaga modelu w pętli: porównujesz liczbę z odpowiedzi z liczbą zwróconą przez narzędzie. Gdy się rozjadą, masz alert, nie zmyślony wniosek. W praktyce wpięcie asystenta w systemy źródłowe to więcej pracy niż wrzucenie eksportu do bazy wektorowej, ale usuwa błędy, których żaden prompt nie dotknie.

4. Wyjście strukturalne i walidacja schematu

Gdy odpowiedź modelu zasila kolejny system, nie powinna być prozą, tylko zwalidowanym obiektem. W n8n służą do tego Structured Output Parser, który wymusza zgodność z wcześniej zdefiniowanym schematem JSON i automatycznie ponawia próbę, gdy wyjście jest błędne, oraz Auto-Fixing Parser, który każe modelowi samemu poprawić błąd parsowania.

Schemat piszesz pod własne dane. Najprostszy wariant wygląda tak:

{
  "odpowiedz": "string",
  "zrodla": "array",
  "brak_danych": "boolean"
}

Wysyłasz właściwości answer, sources i confidence_score. Kluczowe jest to, że model dostaje instrukcję wprost: „confidence_score poniżej 0.5 oznacza, że nie masz odpowiedzi w materiałach". Dzięki temu brak wiedzy staje się wartością w danych, a nie akapitem tekstu udającym odpowiedź. Błędny obiekt wywala się wtedy głośno, zamiast cicho przejść dalej i skazić dane w systemie docelowym.

5. Sprawdzanie pokrycia każdego twierdzenia

Rozbij odpowiedź na twierdzenia faktograficzne i sprawdź, czy każde ma pokrycie w pobranym tekście. W praktyce drugi model dostaje wyłącznie pobrany fragment i jedno zdanie, po czym odpowiada, czy fragment potwierdza zdanie - taki model pełni rolę sędziego.

Tu jest pułapka, o której mało kto mówi: sprawdź samego sprawdzającego, zanim mu zaufasz, na zestawie ze znanymi odpowiedziami. Sędzia, który zgadza się ze wszystkim, jest gorszy niż brak sędziego - bo daje Ci fałszywy komfort. Przy korpusie liczącym 500 tys. rekordów praktyka polega na weryfikowaniu każdego twierdzenia liczbowego względem źródłowego fragmentu, zanim odpowiedź wróci do użytkownika, a twierdzenie bez możliwego do pobrania źródła jest oznaczane jako niezweryfikowane zamiast wygładzane w pewną siebie prozę.

Koszt jest realny - to dodatkowe wywołanie modelu na odpowiedź. Przy pytaniach, gdzie odpowiedź ma trafić do klienta, zwykle się opłaca. Przy pytaniach wewnętrznych, gdzie ktoś i tak sprawdzi, często nie.

6. Konsensus kilku modeli

Wyślij to samo zapytanie do kilku modeli, porównaj odpowiedzi i odrzuć informacje, które nie pojawiają się w co najmniej dwóch wynikach. To najprostsza wersja weryfikacji krzyżowej, którą da się zbudować w n8n równoległymi gałęziami i węzłem Merge.

Wiem, co zarzucisz: to mnoży koszt przez liczbę modeli. Zgadzam się, dlatego stosuję to punktowo - na pytania wysokiego ryzyka, nie jako filtr pierwszy. Na pytaniach o czymś, co można sprawdzić mechanicznie, ten sam koszt lepiej wydać na technikę 5.

7. Świeżość danych i właściciel źródła

Najczęstsza awaria w praktyce to nie halucynacja, tylko zwykła błędna odpowiedź poprawnie pobrana ze źródła, które jest nieaktualne. Model zachował się bez zarzutu. Twoja baza wiedzy nie.

Tu nie ma tricku promptowego. Potrzebujesz właściciela każdego źródła danych, reguł świeżości i wersjonowanej ingestii. W n8n świeżość utrzymujesz przez cykliczne indeksowanie nowych danych, odświeżanie embeddingów i pilnowanie metadanych. Zmiana modelu embeddingów przebudowuje cały indeks i po cichu zmienia to, co pobiera się do każdego wcześniejszego pytania - to jest dokładnie ten rodzaj zmiany, po którym zespół nie potrafi wytłumaczyć, dlaczego odpowiedzi się poprawiły.

Drugą stroną jest miejsce, gdzie leżą dane. Over the postawienie modelu i bazy na własnym serwerze bywa decyzją nie tylko kosztową, ale też RODO-ową. Przy danych klientów i pracowników warto o tym rozmawiać, zanim korpus trafi do cudzego API.

8. Stały workflow zamiast swobodnego agenta

Model idący stałą sekwencją kroków ma mniej miejsc na zmyślanie niż taki, który sam wybiera drogę. Jeśli proces za każdym razem wygląda tak samo, nie dawaj modelowi swobody na kreatywność - poprowadź go węzłami w ustalonej kolejności.

To jest kompromis, nie dogmat. Agenty biorą się, gdy proces jest nieprzewidywalny, ale wtedy płacisz za to mierzalnie: nikt nie policzył, ile zapytań agent musi wykonać, żeby odpowiedź w ogóle była poprawna. Dobra zasada brzmi: odczyt niech będzie autonomiczny, a wszystko, co zapisuje lub działa na świecie, niech pędzi przez potwierdzenie.

9. Człowiek w pętli przed działaniem (HITL w n8n)

To jest ostatnia bramka i najskuteczniejsza. W n8n human-in-the-loop blokuje wykonanie narzędzia, dopóki człowiek się nie zgodzi: zatwierdzenie uruchamia narzędzie z parametrami wskazanymi przez AI, odrzucenie kasuje akcję, a model dostaje informację o odmowie. W n8n działa to dokładniej niż kontrola całej odpowiedzi, bo bramka stoi przed akcją, a nie po niej.

Konfiguracja wygląda tak: otwierasz Tools Panel przy węźle AI Agent, w sekcji Human review wybierasz kanał zatwierdzania, a potem podłączasz do tego kroku narzędzia wymagające review. Kanały to wbudowany Chat, Slack, Discord, Telegram, Microsoft Teams, Gmail, WhatsApp Business Cloud, Google Chat czy Outlook - czyli zatwierdzenie może iść dokładnie tam, gdzie Twoi ludzie już są.

Komunikat do reviewera budujesz ze zmiennych $tool.name (nazwa narzędzia) i $tool.parameters (parametry, które AI chce użyć), a wartości wyznaczone przez model wstawiasz przez $fromAI(), żeby to, co zatwierdzasz, było dokładnie tym, co zostanie wykonane:

The AI wants to use {{ $tool.name }}
with the following parameters:
{{ JSON.stringify($tool.parameters, null, 2) }}

Ważne dopowiedzenie z dokumentacji: opisz w system promptcie, które narzędzia wymagają zatwierdzenia i jak ma się zachować agent po odrzuceniu. Bez tego agent po odmowie czasem próbuje znaleźć inną drogę do tego samego celu.

Praktyczna reguła: zacznij z review włączonym dla wszystkiego, co zapisuje, wysyła albo usuwa, i redukuj nadzór w miarę, jak rośnie zaufanie do systemu. Szczegóły, human-in-the-loop w n8n bez wpadania w koszty, opisałem osobno - tam rozkład kosztu tej bramki na konkretne liczby wywołań.

Czego te 9 technik nie naprawi

Żadna z nich nie usuwa podłogi statystycznej. Warto wymienić rzeczy, które kupuje się najczęściej, a które niczego nie dają.

Zero temperatury nie zamienia twierdzenia bez pokrycia w twierdzenie z pokryciem. Obniżenie temperatury zmniejsza kreatywność, ale może dać bardziej schematyczne i mniej szczegółowe odpowiedzi - to parametr do dostrojenia, nie zabezpieczenie.

Guardrail od osadzania nie działa na stronniczość, a trenowanie modelu na problem nieaktualnego dokumentu daje mniej niż nic, bo kosztuje i zostawia stary dokument na miejscu. Każdą technikę dobieraj do rodzaju awarii, którą faktycznie masz.

Prompt engineering bywa wciąż sprzedawany jako główny sposób na halucynacje, a nim nie jest. To prośba, nie mechanizm kontrolny - i wszystko, co naprawdę trzyma, działa poza modelem.

Jak sprawdzić, czy to działa

Bez pomiaru wdrożenie siedzi bez informacji, a informacja jest jedynym argumentem za utrzymaniem budżetu. Zbuduj zestaw 100-200 realnych pytań ze znanymi poprawnymi odpowiedziami, wziętych z faktycznych zgłoszeń, a nie napisanych przez zespół, który buduje system. Puszczaj go przy każdej zmianie promptu, modelu, chunkowania albo embeddingów.

W n8n masz do tego gotowe mechanizmy: AI Evaluations przepuszczające testowy zbiór danych przez workflow, z technikami typu string similarity, exact match i LLM-as-a-Judge, oraz własne metryki, np. poprawność faktograficzną i trafność dokumentów. Warto monitorować cztery liczby: odsetek odpowiedzi z cytowaniami, odsetek treści, które przeszły walidację, liczbę zgłoszeń od użytkowników i czas reakcji na błąd.

Do tego dwa nawyki z praktyki: loguj przez 7 dni zapytania z pustym lub słabym retrievalem (to pokazuje, ile pytań w ogóle nie powinno było trafić do modelu), i przeglądaj 50 losowych odpowiedzi tygodniowo. Tyle wystarczy, żeby wychwycić regresję, zanim zgłosi ją klient. Jeśli wdrażasz to na istniejącym procesie, 9 błędów w n8n, które kosztują najwięcej warto mieć pod ręką jako listę kontrolną.

Kiedy odpowiedzialność spada na Ciebie

Tu nie ma już warstwy technicznej, tylko prawo. Odpowiedzi Twojego asystenta to Twoje oświadczenia - dwa wyrody są tu dobrą lekcją.

W sprawie Mata vs Avianca (22 czerwca 2023) dwóch prawników złożyło pismo z sześcioma orzeczeniami, których nie ma. Wygenerował je ChatGPT, razem z cytatami i odesłaniami. Sędzia nałożył grzywnę 5000 USD, a uzasadnienie brzmiało, że reguły nakładają na prawnika rolę strażnika odpowiedzialnego za rzetelność pisma, nawet przy korzystaniu z rzetelnego narzędzia.

W sprawie Moffatt vs Air Canada (14 lutego 2024) trybunał w Kolumbii Brytyjskiej kazał liniom zapłacić 812,02 USD, gdy asystent podał błędną informację o możliwości wstecznego zgłoszenia taryfy żałobnej.

Do tego dochodzą dwie linie regulacyjne. Od 2 sierpnia 2026 obowiązują przepisy o przejrzystości AI - nie wymagają, żebyś miał rację, wymagają ujawnienia, że po drugiej stronie jest maszyna. A zmyślone dane osobowe to w RODO nieprawidłowe dane osobowe, do których trzeba je sprostować; skarga noyb z 29 kwietnia 2024 dotyczyła właśnie wymyślonej daty urodzenia. Blokowanie treści to nie sprostowanie.

Praktyczny wniosek: miejsc, w których system odpowiada za decyzję wobec klienta, nie zostawiaj bez review człowieka. Zasada jest prosta - odczyt autonomicznie, zapis i działanie z potwierdzeniem.

Od czego zacząć w swoim procesie

Nie wdrażaj dziewięciu naraz, bo nie odróżnisz, co zadziałało. Zacznij od trzech rzeczy: RAG na wąskiej bazie zmuszający do cytowania, ścieżka odmowy, i zestaw 100-200 pytań do pomiaru przed zmianą czegokolwiek. Dopiero potem dokładaj warstwę po warstwie, sprawdzając po każdej, czy odsetek odpowiedzi poprawnych rośnie.

Jeśli masz proces, w którym halucynacje są dziś ryzykiem, a nie dokonanym faktem, napisz do mnie. Odpowiadam zwykle tego samego dnia. Zwykle wystarcza rozmowa o jednym procesie i o tym, gdzie w nim leży najwięcej ryzyka - a potem zakres i wycena na pisemnie, żeby było wiadomo, co dokładnie wdrażamy.