Łapanie halucynacji AI: 3 zabezpieczenia dla zespołów B2B

Jak wyglądają halucynacje AI w realnych workflow B2B

Halucynacja to gdy model generuje pewną siebie, ale błędną odpowiedź. W B2B objawia się w trzech klasycznych formach: (1) wymyślenie nieistniejącego numeru zamówienia w odpowiedzi na zapytanie supportu, (2) "cytowanie" daty, której nie ma w umowie, podczas jej podsumowania, (3) wymyślenie nowej kategorii przy klasyfikacji faktur poza zdefiniowanym zbiorem.

Wszystkie trzy mają ten sam wzorzec: bez prawdziwego zakotwiczenia model uzupełnia lukę. Problem w tym, że wyjście brzmi pewnie — nawet jeśli jest błędne. "AI się myli" to za mało; trzeba wiedzieć gdzie i dlaczego. Trzy zabezpieczenia poniżej to robią.

Trzy zabezpieczenia: źródło, reguła, człowiek

1) Cytat źródła: model zwraca każdą odpowiedź z id lub numerem wiersza dokumentu źródłowego. Bez źródła odpowiada "nie wiem". Halucynacje spadają o ~80%.

2) Pre-check regułami: walidacja wyjścia przed przekazaniem — czy numer zamówienia ma 8 cyfr? Czy kategoria faktury jest na liście? Czy format daty jest poprawny? Te tanie checki w Pythonie łapią większość.

3) Ludzka aprobata: działania wysokiego ryzyka (zwroty, podpisy umów) są proponowane przez AI, a zatwierdzane przez człowieka. AI obsługuje ~95% samodzielnie; 5% wyjątków trafia do Ciebie do przeglądu.

Trzy razem: w niezależnych audytach poziom halucynacji spada poniżej 2%.

Budowa procesu ewaluacji przed wdrożeniem

Nie da się uchwycić wskaźnika halucynacji, oglądając wyniki na oko — potrzebny jest zestaw testowy. Zbuduj wzorcowy zbiór 50–200 rzeczywistych przykładów ze znanymi poprawnymi odpowiedziami i upewnij się, że obejmuje on przypadki brzegowe — brakujące dane, niejednoznaczne zapytania, prośby wykraczające poza zakres. Uruchamiaj na nim model przed każdą zmianą promptu lub modelu, nie tylko przy wdrożeniu.

Śledź dwie odrębne liczby: dokładność (czy odpowiedź była poprawna) oraz wskaźnik wstrzymywania się od odpowiedzi (czy model poprawnie powiedział „nie wiem", gdy powinien). Model, który nigdy się nie wstrzymuje, wygląda na pewny siebie, ale jest bardziej ryzykowny; model, który wstrzymuje się zbyt często, jest uciążliwy, ale bezpieczniejszy. Właściwy próg zależy od tego, jak kosztowna jest błędna odpowiedź w porównaniu z odpowiedzią odłożoną.

Testowanie adwersarialne ma równie duże znaczenie co testowanie przypadków standardowych — celowo podawaj modelowi zapytania zaprojektowane tak, by wywołać halucynację: pytania o nieistniejące byty, prośby mieszające dwa różne rekordy, prompty proszące o ekstrapolację poza dokument źródłowy. Jeśli model nie potrafi „upaść z klasą" w kontrolowanym teście, nie zrobi tego również w produkcji.

Traktuj to jako żywy proces, a nie jednorazową bramkę kontrolną. Za każdym razem, gdy zmieniasz prompt, wymieniasz model albo dodajesz nowe źródło dokumentów, uruchom ponownie zestaw ewaluacyjny i porównaj nowe wartości dokładności oraz wstrzymywania się od odpowiedzi z wartością bazową przed wdrożeniem. To ta sama dyscyplina co testy regresyjne w tradycyjnym oprogramowaniu — tyle że testuje ocenę sytuacyjną zamiast logiki.

Które zadania niosą największe ryzyko halucynacji

Nie każde zadanie AI niesie takie samo ryzyko, więc budżet na mechanizmy zabezpieczające również nie powinien być rozłożony równomiernie. Generowanie otwarte — pisanie maila do klienta, streszczanie spotkania, tworzenie tekstów marketingowych — pozostawia przestrzeń na kreatywność, ale to właśnie w tej przestrzeni ukrywa się halucynacja: zmyślone statystyki, wymyślone cytaty, obietnice, których firma nigdy nie złożyła. To kategoria najwyższego ryzyka, ponieważ nie istnieje stały „poprawny" wynik, z którym można porównać wynik modelu — jest tylko zakres akceptowalnych odpowiedzi.

Tuż za nią plasuje się ekstrakcja danych liczbowych i finansowych. Wyciąganie sumy z faktury, obliczanie rabatu, wydobywanie numeru identyfikacji podatkowej — błędy tutaj są ciche (liczba wygląda wiarygodnie) i kosztowne (zasilają bezpośrednio przepływ pieniędzy). Twierdzenia prawne i zbliżone do medycznych — zobowiązania umowne, oświadczenia o zgodności z przepisami, informacje o dawkowaniu czy bezpieczeństwie — należą do tej samej kategorii wysokiego ryzyka: jeden błąd oznacza tu nie zażenowanie, lecz odpowiedzialność prawną.

Na drugim biegunie znajduje się ekstrakcja ustrukturyzowana według stałego schematu — rozbicie CV na imię, e-mail i umiejętności, klasyfikacja zgłoszenia do jednej z 12 kategorii, oznaczenie transakcji kodem sprzedawcy — co jest stosunkowo niskim ryzykiem. Model ma mniej pola do zmyślania, ponieważ przestrzeń wyników jest ograniczona i łatwa do zweryfikowania mechanicznie: można sprawdzić, czy kategoria istnieje, czy adres e-mail zawiera znak @, czy wartość jest jedną z 12 opcji. Klasyfikacja do niewielkiego, zamkniętego zbioru zachowuje się podobnie — nawet gdy model się myli, robi to w granicach, które sam zdefiniowałeś, co jest zasadniczo tańszym trybem awarii.

Wykorzystaj tę gradację, by zdecydować, gdzie skierować wysiłek na mechanizmy zabezpieczające. Zadania niskiego ryzyka o zamkniętym schemacie często można obsłużyć lekką walidacją i wyrywkowymi kontrolami. Zadania wysokiego ryzyka — otwarte lub liczbowo-prawne — zasługują na pełen zestaw środków z poprzedniej sekcji: cytowanie źródeł, kontrole reguł oraz człowieka w pętli — zanim pozwolisz automatyzacji dotknąć klienta lub księgi finansowej.