Halucynacje modelu AI — skąd się biorą i jak je wykrywać w firmie

Model językowy potrafi podać nieistniejący numer artykułu regulaminu, wymyślić funkcję produktu albo zacytować dokument, którego nigdy nie było — i zrobić to z takim samym przekonaniem, z jakim podaje prawdę. To zjawisko nazywane halucynacją nie jest usterką, którą dostawca wkrótce naprawi, lecz konsekwencją sposobu działania modeli. Nie da się go całkowicie wyeliminować, ale da się projektować systemy, w których zmyślenie zostaje wychwycone, zanim wyrządzi szkodę.

Autor: zespół Convert Studio — software house z Kielc i Krakowa, projektujemy aplikacje webowe, sklepy i wdrożenia AI dla firm.

Skąd biorą się halucynacje

Model językowy nie przechowuje faktów w formie bazy, z której je odczytuje. Nauczył się wzorców — tego, jakie słowa zwykle następują po innych w podobnym kontekście. Zapytany o coś, odtwarza najbardziej prawdopodobny ciąg dalszy.

Przez większość czasu prawdopodobne i prawdziwe pokrywają się, bo model widział wiele poprawnych tekstów. Rozchodzą się w trzech sytuacjach: gdy pytanie dotyczy wiedzy, której model nie posiada, gdy wiedza jest rzadka lub sprzeczna w materiałach, na których się uczył, oraz gdy pytanie zakłada coś nieprawdziwego. W każdej z nich model nadal wygeneruje odpowiedź o poprawnej formie — tylko treść nie będzie oparta na niczym.

Rodzaje halucynacji spotykane w firmach

Gdzie halucynacje są najgroźniejsze

To samo zjawisko ma zupełnie inną wagę w zależności od zadania. Warto ocenić to przed wdrożeniem, a nie po pierwszej reklamacji.

• Informacje dla klientów o warunkach, terminach i cenach — klient ma prawo polegać na tym, co usłyszał.
• Dane wprowadzane do systemów — zmyślona wartość trafia do bazy i żyje tam dalej.
• Kwestie prawne i regulacyjne — wymyślony przepis bywa kosztowny.
• Instrukcje techniczne i bezpieczeństwa — błąd może prowadzić do szkody fizycznej.
• Decyzje podejmowane automatycznie bez udziału człowieka.

Mniej groźne są zadania, w których wynik czyta człowiek znający temat: robocza wersja tekstu, streszczenie spotkania dla jego uczestników, propozycja kategorii sprawdzana przez pracownika.

Jak ograniczać halucynacje

1. Odpowiedzi wyłącznie na podstawie dostarczonych dokumentów

Najskuteczniejsza pojedyncza metoda. Zamiast pytać model o wiedzę, dostarczasz mu właściwe fragmenty dokumentów i każesz odpowiadać tylko na ich podstawie. Mechanizm opisaliśmy w materiale o odpowiedziach opartych na dokumentach firmy.

2. Obowiązkowe wskazanie źródła

Każda odpowiedź zawiera odnośnik do fragmentu, na którym się opiera. Pozwala to zweryfikować ją w kilka sekund — i pozwala zrobić to automatycznie.

3. Jawne pozwolenie na „nie wiem"

Modele mają skłonność do odpowiadania za wszelką cenę. Instrukcja musi wprost mówić, że brak odpowiedzi jest poprawnym wynikiem, i pokazywać to na przykładzie. Szczegóły w materiale o pisaniu instrukcji dla modelu.

4. Ograniczenie swobody

Zadania zamknięte — wybór z listy, wyciągnięcie pola o znanym formacie — dają znacznie mniej miejsca na zmyślenie niż zadania otwarte. Jeśli wynik może być wyborem z listy dozwolonych wartości, niech będzie.

5. Weryfikacja poza modelem

Fakty, które da się sprawdzić automatycznie, trzeba sprawdzić automatycznie. Numer zamówienia istnieje w bazie albo nie. Cena zgadza się z cennikiem albo nie. Kod powinien to zweryfikować, zanim odpowiedź dotrze do klienta.

Mechanizmy wykrywania

• Sprawdzenie cytatu. Czy fragment wskazany jako źródło faktycznie zawiera przytoczoną informację — to da się sprawdzić programowo.
• Walidacja identyfikatorów. Każdy numer, kod, adres URL czy nazwa produktu w odpowiedzi porównywany z bazą.
• Drugie wywołanie oceniające. Osobne zapytanie, którego jedynym zadaniem jest ocena, czy odpowiedź wynika z dostarczonych fragmentów.
• Porównanie wielu odpowiedzi. To samo pytanie zadane kilka razy — rozbieżne odpowiedzi sygnalizują niepewność modelu.
• Próg przekazania człowiekowi. Odpowiedzi, które nie przeszły którejkolwiek kontroli, trafiają do weryfikacji zamiast do klienta.
• Zgłaszanie przez użytkowników. Prosta możliwość oznaczenia odpowiedzi jako błędnej, przeglądana regularnie.

Jak zmierzyć skalę problemu

Deklaracja „system rzadko się myli" bez pomiaru nie ma wartości. Warto przygotować zestaw testowy zbudowany specjalnie pod kątem halucynacji.

Szczególnie wartościowe są pytania z drugiej i trzeciej kategorii. System, który poprawnie odpowiada na wszystkie pytania z odpowiedzią w dokumentach, ale zmyśla przy pytaniach bez odpowiedzi, jest w praktyce niebezpieczny — bo użytkownik nie odróżni jednych od drugich.

Halucynacje jako założenie projektowe

Najdojrzalsze podejście nie polega na próbie wyeliminowania halucynacji, lecz na zaprojektowaniu systemu, który zakłada, że się pojawią. W praktyce oznacza to kilka decyzji architektonicznych.

• Człowiek w pętli tam, gdzie koszt błędu jest wysoki — model przygotowuje, człowiek zatwierdza.
• Czynności nieodwracalne poza zasięgiem modelu — o czym piszemy przy agentach AI.
• Jasny komunikat dla klienta, że odpowiada system, wraz z łatwym dostępem do człowieka.
• Dziennik odpowiedzi pozwalający ustalić po fakcie, co i na jakiej podstawie zostało powiedziane.
• Procedura korekty — co zrobić, gdy klient otrzymał błędną informację.

Halucynacje a organizacja pracy

Techniczne zabezpieczenia to tylko połowa rozwiązania. Druga połowa to sposób, w jaki ludzie korzystają z odpowiedzi modelu. Pracownik, który wie, że system czasem się myli, i ma prosty sposób zgłoszenia błędu, jest skuteczniejszym zabezpieczeniem niż kolejna warstwa automatycznej weryfikacji.

• Szkolenie użytkowników — krótko o tym, czym są halucynacje i w jakich sytuacjach zdarzają się najczęściej.
• Przycisk zgłoszenia błędu przy każdej odpowiedzi, zapisujący pytanie, odpowiedź i źródła.
• Regularny przegląd zgłoszeń — każdy potwierdzony błąd trafia do zestawu testowego.
• Jasna odpowiedzialność — informacja przekazana klientowi pozostaje odpowiedzialnością pracownika, niezależnie od narzędzia.
• Kultura sprawdzania — weryfikacja odpowiedzi w sprawach ważnych nie jest oznaką nieufności, tylko standardem.

Z czasem zestaw zgłoszonych błędów staje się najcenniejszym zasobem projektu: pokazuje realne słabości systemu na realnych pytaniach, a nie na przykładach wymyślonych przy biurku.

Od czego zacząć

Jeśli system już działa, a zabezpieczeń jest niewiele, najlepiej zacząć od trzech kroków. Po pierwsze, wymusić podawanie źródeł przy każdej odpowiedzi opartej na dokumentach. Po drugie, zebrać kilkadziesiąt pytań z prawdziwego ruchu i sprawdzić odpowiedzi ręcznie, zapisując każdy błąd. Po trzecie, dodać przycisk zgłoszenia. Te trzy działania w ciągu kilku tygodni pokazują, jak często i w jakich sytuacjach model się myli, a to podstawa do decyzji o dalszych zabezpieczeniach.

Nie trzeba do tego specjalistycznych narzędzi. Wystarczy arkusz, kilka godzin pracy osoby znającej temat i konsekwencja w zapisywaniu wyników. Po takim przeglądzie rozmowa o dalszych zabezpieczeniach opiera się na faktach, a nie na obawach czy entuzjazmie.

Warto też ustalić, kto w firmie podejmuje decyzję o tym, że poziom błędów jest akceptowalny. Bez tej osoby dyskusja o jakości systemu nigdy się nie kończy, a kolejne zabezpieczenia są dodawane bez jasnego celu i bez oceny, czy rzeczywiście coś poprawiły.

Podsumowanie

Halucynacje są stałą cechą modeli językowych, a nie usterką do naprawienia w następnej wersji. Nie da się ich całkowicie wyeliminować, ale da się ograniczyć ich częstotliwość i — co ważniejsze — wychwytywać je, zanim trafią do klienta lub do systemu. Najskuteczniejsze są odpowiedzi oparte wyłącznie na dostarczonych dokumentach, obowiązkowe wskazanie źródła i automatyczna weryfikacja faktów sprawdzalnych.

Jeśli masz już działający system, dodaj do zestawu testowego kilkanaście pytań, na które dokumenty nie odpowiadają, i sprawdź, co się dzieje. To najszybszy sposób, żeby dowiedzieć się, czy system przyznaje się do niewiedzy, czy zmyśla — a od tej jednej właściwości zależy, czy można mu powierzyć kontakt z klientami. Szerszy kontekst znajdziesz na stronie AI w firmie.