Halucynacje AI: jak je rozpoznać i wyciąć z systemu produkcyjnego

Halucynacja AI to płynna odpowiedź bez pokrycia

Halucynacja AI to wyjście modelu, które brzmi wiarygodnie i pewnie, a nie ma pokrycia: ani w dokumentach, które system pobrał, ani w rekordach, które umie odczytać, ani w faktach. To cała definicja, a najważniejsze jest w niej 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.

Trzy rzeczy, którymi halucynacja nie jest. Nie jest bugiem w sensie zepsutej ścieżki w kodzie, bo nic się nie zepsuło - model zrobił to, co robi, czyli wygenerował najbardziej prawdopodobne dokończenie. Nie jest losowością, bo zejście z temperaturą do zera nie zamienia twierdzenia bez pokrycia w twierdzenie z pokryciem. I nie jest kłamstwem, bo kłamstwo wymaga intencji, a nie ma tam nikogo, kto mógłby ją mieć. Przegląd Mahmuta Ozera w Turkish Journal of Psychiatry argumentuje z tego samego powodu, że trafniejszym słowem jest *konfabulacja*, bo pożyczony termin kliniczny sugeruje przeżycie, którego system nie ma.

Z tego przeglądu warto zabrać jeszcze jeden podział, bo przekłada się na dwa różne zadania inżynierskie. Halucynacja wewnętrzna zaprzecza materiałowi, który system dostał, i da się ją złapać mechanicznie, porównując odpowiedź z pobranym tekstem. Halucynacja zewnętrzna dokłada coś, czego w ogóle nie da się zweryfikować względem tego materiału, i tu potrzeba źródła spoza rozmowy. Większość systemów produkcyjnych radzi sobie z pierwszą i jest ślepa na drugą.

Jeden przykład domyka obraz. W pracy Why Language Models Hallucinate autorzy pytają model open source o wielkości 600 mld parametrów o datę urodzin konkretnej osoby, wprost zaznaczając, żeby odpowiedział tylko wtedy, gdy wie. W trzech podejściach dostają trzy różne daty i żadna nie jest prawdziwa. Nic w tych odpowiedziach nie sygnalizuje zgadywania. To właśnie ta cecha robi z halucynacji problem projektowy, a nie problem czytania ze zrozumieniem: pewna odpowiedź błędna i pewna odpowiedź trafna wyglądają identycznie.

Modele zgadują, bo zgadywanie lepiej punktuje

Skłonność do zgadywania jest wtrenowana, i to na dwóch etapach. W pretreningu faktów pojawiających się w danych raz nie da się nauczyć pewnie, a ta sama praca wyprowadza z tego dolną granicę, nie tendencję: jeśli piąta część dat urodzin w korpusie występuje dokładnie raz, model bazowy pomyli co najmniej piątą część pytań o daty urodzin. Żaden prompt nie usuwa statystycznej podłogi.

Ciekawszy jest drugi etap, bo to problem punktacji, nie modelowania. Większość benchmarków ocenia odpowiedź zero-jedynkowo i nie daje żadnych punktów za „nie wiem”. Przy takiej regule, jak ujmują to autorzy, wstrzymanie się jest ściśle gorsze od zgadywania - uczciwy model, który sygnalizuje niepewność, przegrywa z identycznym modelem, który zawsze strzela. Każdy ranking zbudowany w ten sposób płaci modelom za blefowanie, a modele się nauczyły.

Praktyczny wniosek dla firmy jest krótki. Model przychodzi z przechyleniem w stronę odpowiadania, tego przechylenia nie zgłosisz jako błędu, a „odpowiadaj tylko, gdy masz pewność” w prompcie systemowym jest prośbą, nie mechanizmem kontrolnym. Wszystko, co naprawdę trzyma, jest poza modelem. Mówimy to wprost, bo prompt engineering wciąż bywa sprzedawany jako główny sposób na halucynacje, a nim nie jest.

Halucynacja, stronniczość algorytmu i zwykły błąd to trzy różne awarie

Te trzy rzeczy zlewa się nagminnie, zwykle w jednym zdaniu, i to zlanie kosztuje, bo każda z nich ma inną metodę wykrywania i inną naprawę. Kupowanie guardraila od osadzania na problem stronniczości nie daje nic. Dotrenowywanie modelu na problem nieaktualnego dokumentu daje mniej niż nic, bo kosztuje i zostawia nieaktualny dokument na miejscu.

Stronniczość algorytmu (algorithmic bias) to systematyczne przechylenie wyników w obrębie całej grupy przypadków: system jest konsekwentnie surowszy, hojniejszy albo po prostu mniej trafny dla jednego segmentu niż dla innego. Dwie rzeczy odróżniają ją od halucynacji. Jest powtarzalna, więc widać ją w agregacie, a nie w pojedynczej odpowiedzi, i bywa doskonale udokumentowana - model potrafi wskazać, skąd wzięło się przechylenie, bo tkwi ono w danych albo w procesie, który te dane wytworzył. NIST w SP 1270 zwraca uwagę, że branża szuka stronniczości w warstwie obliczeniowej, w reprezentatywności zbiorów i sprawiedliwości algorytmów, a źródła ludzkie i instytucjonalne zostają niezbadane. Tego wymóg cytowania nie rusza.

Trzecia awaria jest w praktyce najczęstsza i najrzadziej omawiana: zwykła błędna odpowiedź, poprawnie pobrana ze źródła, które jest nieaktualne, zastąpione nowszym dokumentem albo od początku błędne. Model zachował się bez zarzutu. Twój korpus nie. To warto sprawdzić przed wszystkim innym, bo sprawdzenie jest tanie i tłumaczy zaskakująco dużą część zgłoszeń przychodzących z etykietą „halucynacja”.

Zespół, który nie odróżnia tych trzech rzeczy, spali kwartał na niewłaściwym lekarstwie i zostanie z pierwotnym problemem, i dlatego to rozróżnienie warte jest akapitu. Przy złej odpowiedzi zadaj jedno pytanie: czy system mógł to wiedzieć? Jeśli tak, to awaria retrievalu albo danych. Jeśli nie, a mimo to odpowiedział - to jest halucynacja.

Głośne wpadki trafiają do sądu, ciche po prostu idą na produkcję

Dwie sprawy warto znać, bo stoją za nimi akta sądowe, a nie anegdoty. W sprawie Mata przeciwko Avianca, rozstrzygniętej w Południowym Dystrykcie Nowego Jorku 22 czerwca 2023, dwóch prawników złożyło pismo cytujące sześć orzeczeń, które nie istniały. Wyprodukował je ChatGPT, razem z cytatami i odesłaniami. Sędzia Castel nałożył grzywnę 5000 dolarów i napisał zdanie, które do dziś porządkuje dyskusję: postęp technologiczny jest czymś zwyczajnym i nie ma nic niewłaściwego w korzystaniu z rzetelnego narzędzia AI, ale istniejące reguły nakładają na prawnika rolę strażnika, który odpowiada za rzetelność pisma. Problemem nie było narzędzie. Problemem był brak sprawdzenia.

Druga sprawa jest bliższa temu, co realnie działa w firmach. W Moffatt przeciwko Air Canada, rozstrzygniętej przez trybunał w Kolumbii Brytyjskiej 14 lutego 2024, bot na stronie linii lotniczej powiedział klientowi, że o taryfę żałobną można wystąpić wstecznie. Nie można było. Air Canada argumentowała między innymi, że nie odpowiada za informacje podane przez bota; trybunał odpowiedział, że chatbot ma wprawdzie komponent interaktywny, ale wciąż pozostaje częścią strony Air Canada, i kazał liniom zapłacić 812,02 dolara tytułem odszkodowania, odsetek i opłat. Kwota jest symboliczna. Precedens mówi, że odpowiedzi twojego asystenta to twoje oświadczenia.

Żadna z nich nie jest jednak wzorcem, pod który warto się przygotowywać, bo wersja codzienna nigdy nie robi nagłówka. Przykłady halucynacji AI, które realnie kosztują firmy pieniądze, wyglądają tak:

Asystent wsparcia podaje termin zwrotu, którego nie ma w żadnym regulaminie.

Bot od statusu zamówienia opisuje przesyłkę dla zamówienia, którego nigdy nie sprawdził, bo odpytanie po cichu się nie powiodło, a model dopowiedział prawdopodobną resztę.

Asystent sprzedaży podaje konfigurację produktu, która czyta się bez zarzutu i nie istnieje w katalogu.

Streszczarka umowy dokłada okres wypowiedzenia, którego w umowie nie ma, bo większość umów tego typu go ma.

Każde z tych zdarzeń to jedno zdanie w skądinąd poprawnej odpowiedzi, i dlatego nikt go nie zauważa, dopóki klient nie zacznie działać.

Te cztery słupki niosą większość argumentu. Odtwarzanie z wag na otwarte pytania wypada katastrofalnie. Podaj modelowi dokument, a najgorszy wynik spada o większość dystansu, ale podłoga i tak nie jest zerowa - nawet dla najlepszego systemu na zadaniu, w którym odpowiedź leży w kontekście.

Halucynacje łapie się pomiarem, nie wyrywkowym czytaniem

Czytanie próbki odpowiedzi nie znajduje prawie niczego, bo te awarie są płynne z definicji. Działa mierzenie, a cztery pomiary zakrywają większość terenu.

Osadzenie, per twierdzenie. Rozbij odpowiedź na twierdzenia faktograficzne i sprawdź, czy każde z nich ma pokrycie w pobranym tekście. To ta sama robota, którą automatyzują publiczne rankingi, i tanią wersję zrobisz sam: drugi model dostaje wyłącznie pobrany fragment i jedno zdanie, i odpowiada, czy fragment to zdanie potwierdza. Sprawdź sprawdzającego, zanim mu zaufasz, na zestawie ze znanymi odpowiedziami - sędzia, który zgadza się ze wszystkim, jest gorszy niż brak sędziego.

Pusty i słaby retrieval. To najbardziej opłacalna linijka loga w całym systemie i większości zespołów jej nie ma. Zapisuj każde zapytanie, przy którym retrieval nie zwrócił nic albo nic powyżej progu trafności, a obok to, co asystent i tak powiedział. Na tej liście mieszkają wymyślone zapisy regulaminu. Jeśli liczby cię zaskoczą, to zwykle pipeline retrievalu wymaga pracy, a nie prompt.

Stały zestaw ewaluacyjny z prawdziwego ruchu. Sto do dwustu realnych pytań ze znanymi poprawnymi odpowiedziami, wziętych z faktycznych zgłoszeń, a nie napisanych przez zespół, który budował system. Puszczaj go przy każdej zmianie promptu, modelu, chunkowania albo embeddingów. To ostatnie waży więcej, niż brzmi, bo zmiana modelu embeddingów przebudowuje cały indeks i po cichu zmienia to, co pobiera się do każdego istniejącego pytania.

Rozjazd między narzędziem a tekstem. Jeśli agent wywołał narzędzie, masz i wynik narzędzia, i zdanie, które model o nim napisał. Porównanie liczby z odpowiedzi z liczbą zwróconą przez narzędzie to kontrola czysto mechaniczna, bez modelu w pętli, i łapie tę klasę awarii, w której pobranie zadziałało, a streszczenie odjechało.

Przegląd ludzki idzie tam, gdzie wskazują przyrządy, czyli w ogon, a nie w losową próbkę. Niskie oceny osadzenia, pusty retrieval, nietypowe kształty pytań, wszystko, co dotyka pieniędzy albo uprawnień. Przeczytanie pięćdziesięciu losowych odpowiedzi tygodniowo głównie potwierdza, że łatwe pytania nadal są łatwe.

Siedem mechanizmów, które zatrzymują zgadywanie przed użytkownikiem

Nie da się odebrać modelowi skłonności do zgadywania, więc przestań próbować i zbuduj system, w którym zgadywanka nie ma dokąd pójść. Każdy mechanizm poniżej zwęża odstęp między tym, co system wie, a tym, co wolno mu powiedzieć. Żaden nie wymaga trenowania modelu. Każdy jest zwykłą inżynierią, co jest dobrą wiadomością i zarazem powodem, dla którego wszystkie lądują na później.

Dwa z nich zasługują na przypis z praktyki, bo to one bywają pomijane. Na bazie wiedzy z 500 tys. rekordów weryfikujemy każde twierdzenie liczbowe względem źródłowego chunku, zanim odpowiedź wróci, a twierdzenie bez możliwego do pobrania źródła jest oznaczane jako niezweryfikowane, a nie wygładzane w pewną siebie prozę. Ta jedna reguła jest wewnętrznie niepopularna przez mniej więcej tydzień, bo asystent zaczyna głośno mówić „nie mam tego”, a potem staje się powodem, dla którego ludzie mu ufają.

Druga rzecz to różnica między czytaniem a pamiętaniem. Agent wpięty w żywe systemy nie musi pamiętać statusów zamówień, bo może po prostu sprawdzić; w agencie na telemetrii w czasie rzeczywistym każda odpowiedź jest składana z wywołań narzędzi wykonanych w momencie pytania, a nieaktualne wyniki pośrednie są celowo wyrzucane z historii, żeby kolejne pytanie nie rozumowało na nich. Wpięcie asystenta w systemy źródłowe to więcej roboty niż wrzucenie eksportu do bazy wektorowej i usuwa całą kategorię zmyślania, dlatego podłączenie agentów do danych firmy zwykle jest pierwszą rzeczą z tej listy, którą warto zrobić.

Nad tą siódemką stoi jeszcze jeden wybór architektoniczny. Model idący stałą sekwencją kroków ma mniej miejsc na zmyślanie niż taki, który sam wybiera drogę, więc pytanie agent czy workflow jest po części pytaniem o halucynacje. Jeśli proces za każdym razem wygląda tak samo, nie dawaj modelowi swobody na kreatywność.

I uczciwa granica: to wszystko nie dowozi zera. Audyt Stanfordu na komercyjnych narzędziach do researchu prawnego, a więc na systemach retrievalowych budowanych przez firmy z głębokimi danymi dziedzinowymi, wciąż zmierzył halucynacje w 17-33% odpowiedzi i uznał deklaracje producentów o ich wyeliminowaniu za przesadzone. Planuj ograniczanie i oznaczanie, nie problem rozwiązany.

Rachunek za odpuszczenie jest dziś prawny, nie tylko wizerunkowy

Air Canada pokazała kształt odpowiedzialności: to, co mówi twój asystent, jest oświadczeniem, które złożyłeś, a „tak powiedział bot” nie jest obroną, która przeżywa zderzenie z organem. To rozumowanie nie zależy w żaden ciekawy sposób od prawa kanadyjskiego, a reżimy konsumenckie w Europie lądują w podobnym miejscu.

W Unii dochodzi druga warstwa i jest bliżej, niż zakłada większość zespołów. Obowiązki przejrzystości z AI Act obowiązują od 2 sierpnia 2026 i nie wymagają, żebyś miał rację - wymagają ujawnienia, że po drugiej stronie jest maszyna, i oznaczenia treści generowanej. Rozłożyliśmy to na części w tekście o tym, czego AI Act naprawdę wymaga od systemu, który już działa, razem z tym, które terminy się przesunęły, a które nie.

Jest też cichsza ekspozycja, która z AI Act nie ma nic wspólnego. Kiedy model wymyśla fakty o osobie z imienia i nazwiska, są to nieprawidłowe dane osobowe, a RODO nakazuje ich sprostowanie. Organizacja noyb złożyła 29 kwietnia 2024 skargę do austriackiego organu dokładnie o to, po tym jak OpenAI nie potrafiło poprawić zmyślonej daty urodzenia i odpowiedziało, że może jedynie filtrować lub blokować odpowiedzi na temat tej osoby. Blokowanie to nie sprostowanie. Jeśli twój asystent mówi o klientach, pracownikach czy dostawcach z nazwiska, ta luka jest również twoja.

Na tym tle mechanizmy z poprzedniej sekcji są tanie. Większość kosztu to decyzja o zaakceptowaniu niższego odsetka odpowiedzi, a tę decyzję zwykle podejmuje ktoś, kto nigdy nie musiał tłumaczyć klientowi wymyślonego zapisu regulaminu. To ten sam wzorzec, który stoi za wdrożeniami cicho przewracającymi się po starcie: system mierzono tym, ile odpowiedział, a nie tym, ile z tego było prawdą.

Zacznij od loga, którego nikt nie pisze

Jedna rzecz do zrobienia w tym tygodniu. Przez siedem dni loguj każde zapytanie, przy którym retrieval nie zwrócił nic powyżej progu trafności, razem z odpowiedzią, którą system mimo to wyprodukował. Potem przeczytaj tę listę. W systemach, które nigdy tam nie zaglądały, jest zwykle dłuższa, niż się spodziewano, i skupiona w kilku typach pytań - i sama porządkuje roadmapę.

Potem wybierz z tabeli najmniejszy mechanizm, który adresuje to, co znalazłeś. Zwykle jest to ścieżka odmowy, bo to jakiś dzień pracy, a zamienia całą listę z cichego zmyślania na widoczne luki, które można pójść i zapełnić.

Budujemy i audytujemy takie rzeczy na co dzień, więc jeśli wolisz, żeby pierwsze przejście po logach twojego asystenta zrobił ktoś inny, od tego jest bezpłatny audyt. Ta linijka loga i tak broni się sama.

FAQ