Halucynacje AI jako ryzyko bezpieczeństwa (OWASP LLM09) - gdy model zmyśla z przekonaniem

W skrócie: LLM09 Misinformation to kategoria OWASP dla sytuacji, w której model generuje fałszywe lub mylące treści brzmiące przekonująco. Halucynacja to nie usterka kosmetyczna - to problem bezpieczeństwa, kiedy zmyślona nazwa biblioteki trafia do kodu produkcyjnego, zmyślony precedens prawny trafia do pisma procesowego, albo zmyślona informacja trafia do klienta jako fakt.

RAG zmniejsza skalę problemu, bo model dostaje zweryfikowane źródło zamiast polegać wyłącznie na pamięci. Nie eliminuje go całkowicie - model wciąż może błędnie zinterpretować albo pomieszać nawet poprawny materiał źródłowy.

To dziewiąty wpis z serii o liście OWASP dla aplikacji LLM, po łańcuchu dostaw modeli, ujawnianiu danych wrażliwych, wstrzykiwaniu promptu, wycieku promptu systemowego, bezpieczeństwie RAG, nadmiernej sprawczości agentów, niezaufanych odpowiedziach modelu i zatruwaniu danych.

Dlaczego halucynacja to temat bezpieczeństwa, nie tylko jakości

Łatwo potraktować halucynacje jako problem UX - model czasem się myli, trzeba to zakomunikować użytkownikowi i iść dalej. OWASP klasyfikuje to inaczej: jako realne ryzyko bezpieczeństwa, prawnej odpowiedzialności i reputacji. Model nie sygnalizuje niepewności w sposób, któremu można zaufać - zmyślona odpowiedź brzmi tak samo pewnie jak poprawna. To właśnie czyni halucynacje niebezpiecznymi: nie ma wbudowanego ostrzeżenia "tego akurat nie jestem pewien".

Źródłem halucynacji bywa sam mechanizm działania modelu - wypełnianie luk w wiedzy na podstawie wzorców statystycznych, bez rzeczywistego rozumienia faktów. Ale to nie jedyna przyczyna. Błędy i luki w danych treningowych też się do tego przyczyniają, podobnie jak nadmierne uogólnianie wzorców z niepełnych przykładów.

Nadmierne poleganie - drugi filar problemu

Sam fakt, że model czasem zmyśla, nie byłby tak groźny, gdyby ludzie konsekwentnie weryfikowali jego odpowiedzi. Problem narasta, gdy użytkownicy zaczynają ufać modelowi bez weryfikacji i włączają nieprawdziwe dane do ważnych decyzji. OWASP nazywa to nadmiernym poleganiem (overreliance) i traktuje jako osobny, towarzyszący czynnik ryzyka - nie samą halucynację, tylko to, co ludzie z nią robią.

Znane przypadki

To nie są hipotetyczne scenariusze - OWASP przywołuje udokumentowane sytuacje, w których halucynacja miała realne konsekwencje:

Chatbot linii lotniczej podał fałszywą informację pasażerowi dotyczącą zasad podróży, co doprowadziło do skutecznego pozwu przeciwko przewoźnikowi.
ChatGPT w kontekście prawnym zmyślił precedensy sądowe, które trafiły do pisma procesowego, wywołując poważne konsekwencje dla sprawy.
Chatboty medyczne przedstawiały złożone zagadnienia zdrowotne w sposób wprowadzający w błąd co do skuteczności leczenia.
Generowanie niebezpiecznego kodu - model sugeruje nieistniejące lub niezabezpieczone biblioteki, które programiści nieświadomie włączają do projektu.

Halucynacja to nie to samo co stronniczość danych

Warto rozróżnić dwa zjawiska, które często się myli. Halucynacja to wymyślenie faktu, który nie ma żadnej podstawy - model generuje coś, czego w danych treningowych po prostu nie było, uzupełniając lukę statystycznym domysłem. Stronniczość (bias) to co innego - model odzwierciedla nierównowagę albo uprzedzenia obecne w danych, na których był trenowany, nawet jeśli konkretna odpowiedź "istnieje" gdzieś w tych danych. Oba zjawiska psują wiarygodność odpowiedzi, ale wymagają różnych metod ograniczania: stronniczość adresuje się przez dobór i równoważenie danych treningowych, halucynację przez dostarczanie zweryfikowanego kontekstu i mechanizmy nadzoru nad odpowiedzią w czasie rzeczywistym.

Package hallucination - most do łańcucha dostaw

Ostatni punkt z listy powyżej zasługuje na osobne rozwinięcie, bo łączy się z łańcuchem dostaw, o którym pisaliśmy w poprzednim wpisie. Modele generujące kod regularnie sugerują nazwy pakietów, które brzmią wiarygodnie, ale nie istnieją - to zjawisko znane jako package hallucination. Atakujący namierzają takie często zmyślane nazwy i publikują pod nimi złośliwe paczki w publicznych rejestrach (PyPI, npm). Programista, który zaufa sugestii modelu i zainstaluje pakiet bez weryfikacji, wprowadza do swojego projektu złośliwy kod - bez żadnego wstrzykiwania promptu, bez ataku na model, wyłącznie przez wykorzystanie statystycznej skłonności modelu do zmyślania przekonujących nazw.

To scenariusz, w którym atakującemu wystarczy znać typowe wzorce halucynacji konkretnego modelu - nie trzeba żadnej interakcji z ofiarą poza tym, że ofiara normalnie korzysta z asystenta kodującego.

Dlaczego RAG nie rozwiązuje problemu do końca

Podpięcie modelu do zweryfikowanej bazy wiedzy (Retrieval-Augmented Generation) to jedna z najskuteczniejszych metod ograniczania halucynacji - model dostaje konkretny materiał źródłowy zamiast polegać wyłącznie na tym, co "pamięta" z treningu. Ale to ograniczenie ryzyka, nie jego eliminacja. Model wciąż może błędnie zinterpretować fragment dokumentu, pomieszać informacje z dwóch różnych źródeł, albo uzupełnić lukę w pobranym materiale własnym zmyśleniem, gdy odpowiedź nie jest wprost zawarta w dostarczonym kontekście. RAG zmniejsza częstotliwość halucynacji, nie gwarantuje ich braku.

Co robić

Stosuj RAG dla odpowiedzi wymagających faktów. Dostarczanie zweryfikowanego kontekstu zamiast polegania na pamięci modelu znacząco ogranicza skalę problemu.
Dołącz dostrajanie i łańcuch rozumowania. Techniki takie jak chain-of-thought prompting zmniejszają liczbę odpowiedzi zmyślonych bez podstawy w danych.
Wymuszaj weryfikację krzyżową i nadzór człowieka. Szczególnie przy odpowiedziach o wysokiej stawce (medycznych, prawnych, finansowych) - automatyczna walidacja kluczowych twierdzeń przed publikacją.
Komunikuj ograniczenia wprost. Interfejs powinien jasno oznaczać treść wygenerowaną przez AI i informować o granicach jej wiarygodności, zamiast prezentować odpowiedzi jako pewniki.
Stosuj bezpieczne praktyki przy kodzie generowanym przez model. Weryfikacja istnienia i reputacji sugerowanych pakietów przed instalacją - nie inaczej niż przy każdej nowej zależności z nieznanego źródła.
Edukuj użytkowników. Świadomość, że model może brzmieć pewnie i wciąż się mylić, to pierwszy krok do ograniczenia nadmiernego polegania.

Co sprawdzamy w teście

Przy testach penetracyjnych aplikacji LLM w kontekście LLM09 weryfikujemy między innymi:

Czy model w pytaniach z Waszej domeny biznesowej generuje fałszywe fakty, zmyślone źródła albo nieistniejące produkty i usługi.
Czy interfejs jasno komunikuje użytkownikowi, że odpowiedź może być niepoprawna, czy prezentuje ją jako pewną.
Czy asystent kodujący sugeruje pakiety, które nie istnieją lub mają podejrzanie niską reputację.
Czy przy pytaniach wysokiego ryzyka (zdrowie, finanse, prawo) istnieje mechanizm nadzoru człowieka przed przekazaniem odpowiedzi dalej.
Czy podłączenie RAG faktycznie zmniejsza liczbę halucynacji w porównaniu z samym modelem bazowym, czy tylko przesuwa problem.

Czego to nie załatwi

Żadna z powyższych metod nie daje stuprocentowej gwarancji, że model nigdy nic nie zmyśli - to ograniczenie wynikające z tego, jak działają obecne modele językowe, nie błąd konkretnej implementacji. Cel nie jest taki, żeby wyeliminować halucynacje całkowicie, tylko żeby system wokół modelu nie pozwalał im trafiać dalej bez weryfikacji tam, gdzie konsekwencje błędu są poważne. To ta sama logika obrony warstwowej, co przy wstrzykiwaniu promptu - model jako warstwa generująca treść, a nie jako jedyne źródło prawdy w systemie.