Halucynacje LLM w firmie: jak ograniczyć błędne odpowiedzi AI?
Aby ograniczyć halucynacje LLM, trzeba ustalić, skąd asystent ma brać fakty, jak ma reagować na brak danych i które odpowiedzi wymagają sprawdzenia przed użyciem. RAG, czyli wyszukiwanie materiałów przed przygotowaniem odpowiedzi, może pomóc. Nie zastępuje jednak kontroli źródeł ani testu całego procesu obsługi klienta.
Halucynacją nazywamy sytuację, w której model językowy podaje nieprawdziwą lub niepopartą materiałem informację tak, jakby była faktem. Pewny ton i poprawny język nie potwierdzają jej prawdziwości. NIST opisuje ten problem także w odniesieniu do zmyślonych cytowań i uzasadnień. Dla firmy znaczenie ma to, czy ktoś wykorzysta taką odpowiedź do dalszej pracy lub przekaże ją klientowi.
Ustal, co asystent może powiedzieć i zrobić
Innej kontroli wymaga przeredagowanie sprawdzonej wiadomości, a innej odpowiedź o dostępności produktu, terminie dostawy lub warunkach konkretnego zamówienia. W tych drugich przypadkach wskaż źródło, które rozstrzyga dany fakt. Nie wystarczy ogólna wiedza modelu o tym, jak zwykle działa sprzedaż.
Oddziel przygotowanie tekstu od działania w systemie. To, że asystent potrafi ułożyć odpowiedź o zwrocie, nie oznacza, że powinien sam zatwierdzać zwrot pieniędzy. W zakresie wdrożenia ustal osobno dostęp do danych, możliwość wysłania wiadomości i uprawnienia do zmiany zamówienia. Wskaż też osobę odpowiedzialną za decyzje, których asystent nie może podjąć.
Jeśli odpowiedź może stworzyć zobowiązanie wobec klienta, określ sposób jej zatwierdzenia. Pracownik sprawdzający tekst powinien mieć dostęp do informacji, na których opiera się odpowiedź, i wiedzieć, co dokładnie ma ocenić. Sam przycisk „zaakceptuj” nie zastąpi takiego sprawdzenia.
RAG pomaga znaleźć materiał, ale nie rozstrzyga jego prawdziwości
W rozwiązaniu RAG system najpierw wyszukuje potrzebne fragmenty dokumentów, a następnie przekazuje je modelowi do przygotowania odpowiedzi. Dokumentacja Microsoft opisuje znaczenie trafności wyszukiwania i dostępu do właściwych materiałów. Samo podłączenie firmowej bazy nie gwarantuje, że do odpowiedzi trafi odpowiedni dokument.
Przypisz odpowiedzialność za aktualność materiałów. Jeżeli w bazie pozostają dwie sprzeczne wersje warunków, trzeba wskazać obowiązującą i określić, co system ma zrobić przy rozbieżności. To samo dotyczy zmian oferty: nowa treść na stronie nie oznacza automatycznie, że kopia używana przez asystenta została już odświeżona.
Dane konkretnego zamówienia najlepiej pobierać z systemu, który je obsługuje, w zakresie dostępu danego użytkownika. Opis procedury dostawy w dokumencie nie potwierdza daty wysyłki jednej paczki. Sprawdź także zachowanie przy awarii połączenia: brak pobranej informacji nie powinien zostać zamieniony w przekonująco brzmiący domysł.
Brak danych musi mieć ustaloną ścieżkę obsługi
W instrukcji dla modelu warto jasno dopuścić odpowiedź, że materiał nie zawiera potrzebnej informacji. Takie podejście znajduje się również w zaleceniach Anthropic dotyczących ograniczania halucynacji Claude. Skuteczność instrukcji trzeba jednak sprawdzić na własnych pytaniach, także wtedy, gdy klient naciska na jednoznaczną odpowiedź.
Ustal, co nastąpi dalej: prośba o brakujące dane, przekazanie sprawy do pracownika czy podanie tylko tej części odpowiedzi, która ma podstawę. Jeśli asystent zapowiada kontakt człowieka, proces musi zapewniać przekazanie sprawy do obsługi, na przykład przez utworzenie i przypisanie zgłoszenia. Nie dodawaj takiej obietnicy tylko po to, by zakończenie rozmowy brzmiało uprzejmie.
Przykładowa instrukcja dla asystenta może brzmieć: „Termin dostawy podaj wyłącznie wtedy, gdy jest potwierdzony w danych tego zamówienia. Jeśli go brakuje, wskaż brak informacji i zastosuj uzgodnioną ścieżkę obsługi”. Taką instrukcję trzeba sprawdzić wraz z pobieraniem danych i przekazywaniem spraw.
Przykład: pytanie o termin dostawy
Przyjmijmy hipotetycznie, że klient pyta o dzień doręczenia. System zamówień zwraca status „w przygotowaniu”, ale nie zawiera potwierdzonego terminu. Asystent ma wtedy podstawę do podania statusu. Nie ma podstawy, by dopisać datę wynikającą z typowego czasu dostawy.
Odpowiedź może więc informować, że zamówienie jest w przygotowaniu i nie ma jeszcze potwierdzonej daty doręczenia. Dalszy krok zależy od rzeczywistej procedury firmy. Jeśli pracownik ma ustalić termin, trzeba sprawdzić, czy otrzyma zgłoszenie z danymi potrzebnymi do działania. Jest to przykład projektowania obsługi, a nie opis wdrożenia lub wyniku uzyskanego u klienta.
W teście zmień warunki: podaj potwierdzony termin, usuń go, zwróć sprzeczne informacje i zasymuluj niedostępność systemu. Dobra odpowiedź w jednym z tych przypadków nie mówi jeszcze, jak asystent zachowa się w pozostałych.
Sprawdzaj treść odpowiedzi, a nie sam format
JSON to format uporządkowanego zapisu danych. Poprawna składnia takiej odpowiedzi nie potwierdza prawdziwości wpisanej daty lub ceny. Link do dokumentu też nie wystarcza: sprawdź, czy dokument rzeczywiście zawiera informację wspierającą dane zdanie. Kontrola powinna dotyczyć zarówno istnienia źródła, jak i związku źródła z odpowiedzią.
Drugi model może pomagać w wykrywaniu sprzeczności, lecz jego zgoda nie jest potwierdzeniem faktu. Ostateczne sprawdzenie terminu czy kwoty powinno odwoływać się do właściwego zapisu w systemie albo dokumentu. Przed zastosowaniem dodatkowego modelu porównaj, jakie błędy rzeczywiście wykrywa, co przeocza oraz ile kosztuje jego użycie i obsługa poprawek.
Odbierz wdrożenie na pytaniach z pracy zespołu
Przygotuj zestaw typowych i trudnych pytań oraz oczekiwany sposób obsługi. Powinny znaleźć się w nim przypadki bez odpowiedzi w źródłach, nieaktualne materiały i niejednoznaczne pytania. Wskazówki Anthropic dotyczące oceny aplikacji LLM również wiążą kryteria z zadaniem i uwzględniają brakujące dane. Nie ma jednego progu jakości odpowiedniego dla każdej firmy.
Oceniaj osobno błędne fakty, prawidłowe wskazanie braku danych i niepotrzebne odmowy. Asystent, który odmawia odpowiedzi na wszystko, może rzadko podawać fałszywe informacje, ale nadal nie pomaga zespołowi. Sprawdź również czas potrzebny pracownikowi na poprawienie odpowiedzi oraz skuteczność przekazania sprawy do człowieka.
Po wdrożeniu zachowaj możliwość zgłoszenia błędu i ustal, kto go analizuje. Do odtworzenia problemu przydadzą się użyte źródła, wersja modelu i instrukcji oraz treść odpowiedzi; zakres zapisu i dostęp do niego powinny odpowiadać zasadom firmy dotyczącym danych. Wykryte przypadki dodawaj do testów kolejnych zmian. W ten sposób decyzja o dalszym użyciu asystenta opiera się na jego rzeczywistym zachowaniu, a nie na deklaracji, że zastosowano RAG lub „lepszą instrukcję”.
