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

Jak wyglądają halucynacje AI w rzeczywistych procesach B2B

Halucynacja występuje wtedy, gdy model generuje odpowiedź brzmiącą pewnie, ale błędną. W B2B przybiera trzy typowe formy: (1) wymyślenie nieistniejącego numeru zamówienia w odpowiedzi na zgłoszenie do wsparcia, (2) „cytowanie” w podsumowaniu umowy daty, której nie ma w dokumencie, (3) utworzenie przy klasyfikacji faktur nowej kategorii spoza zdefiniowanego zbioru.

Wszystkie trzy mają wspólny mechanizm: bez oparcia w rzeczywistych źródłach model uzupełnia lukę. Problem polega na tym, że wynik brzmi przekonująco, nawet gdy jest błędny. Stwierdzenie „AI się myli” nie wystarcza; trzeba wiedzieć, gdzie i dlaczego. Temu służą trzy poniższe zabezpieczenia.

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

Kontrola źródeł: pokaż dokument i fragment potwierdzający odpowiedź; sprawdź, czy faktycznie uzasadnia twierdzenie. Sama obecność odnośnika nie wystarcza. Brakujące lub sprzeczne dowody kieruj do weryfikacji.

Kontrola reguł: w kodzie aplikacji sprawdzaj istnienie zamówienia, uprawnienia, kwotę i dozwoloną kategorię. Poprawny format nie dowodzi zgodności z faktami.

Zatwierdzenie przez człowieka: przed płatnością, zwrotem pieniędzy lub wysłaniem wiążącej wiadomości uprawniona osoba sprawdza i zatwierdza dokładny wynik. Każda zmiana wymaga ponownego zatwierdzenia. Nie istnieje uniwersalny procent skuteczności. Testuj odpowiedzi poprawne, błędne i pozbawione źródeł: nieprawidłowy wynik musi zostać zatrzymany, a kolejka weryfikacji musi mieć przypisaną osobę odpowiedzialną.

Budowa procesu ewaluacji przed wdrożeniem

Nie da się określić 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 przypadki brzegowe: brakujące dane, niejednoznaczne zapytania i prośby wykraczające poza zakres. Po każdej zmianie instrukcji lub modelu sprawdź nową wersję na tym zestawie, zanim ją wdrożysz.

Śledź dwie odrębne miary: dokładność (czy odpowiedź była poprawna) oraz częstość wstrzymywania się od odpowiedzi. Osobno sprawdzaj, czy model właściwie odpowiedział „nie wiem”. Model, który nigdy nie wstrzymuje się od odpowiedzi, może odpowiadać także na pytania, na które nie potrafi odpowiedzieć; zbyt częste wstrzymywanie się zmniejsza użyteczność. Sam ten wskaźnik nie dowodzi bezpieczeństwa. Właściwy próg zależy od kosztu błędnej odpowiedzi w porównaniu z kosztem braku odpowiedzi.

Testy zaprojektowane w celu sprowokowania błędów są równie ważne jak testy standardowych przypadków. Celowo podawaj modelowi pytania o nieistniejące byty, prośby mieszające dwa różne rekordy lub instrukcje nakłaniające do wyciągania wniosków wykraczających poza dokument źródłowy. Jeśli model nie potrafi bezpiecznie poradzić sobie z takim przypadkiem w kontrolowanym teście, nie zrobi tego również w środowisku produkcyjnym.

Traktuj to jako stały proces, a nie jednorazową kontrolę. Za każdym razem, gdy zmieniasz instrukcję, wymieniasz model lub dodajesz nowe źródło dokumentów, uruchom ponownie zestaw testowy i przed wdrożeniem porównaj nową dokładność oraz wstrzymywanie się od odpowiedzi z wynikami bazowymi. To ta sama dyscyplina co testy regresji w tradycyjnym oprogramowaniu, tyle że sprawdza ocenę sytuacji zamiast logiki.

Które zadania niosą największe ryzyko halucynacji

Ryzyko nie zależy wyłącznie od swobodnego lub uporządkowanego tekstu. Błędny zapis księgowy w prawidłowej kategorii też może wyrządzić szkodę. Oceń wpływ, odwracalność, wrażliwość danych i odbiorców. Przygotowywanie szkiców nie powinno dawać takich samych praw jak kontakt z klientem czy przesyłanie pieniędzy.