Fallbacki w chatbotach AI: Jak bezpiecznie rozpoznawać i przekierowywać luki w wiedzy

Chatbot na stronie internetowej nie musi odpowiadać na każde pytanie. Kluczowe jest to, aby potrafił rozpoznać, kiedy baza wiedzy nie daje mu wiarygodnych podstaw do udzielenia odpowiedzi, i zachował się wtedy w sposób pomocny dla użytkownika. Wypełnianie luk brzmiącymi prawdopodobnie domysłami prowadzi do kryzysu zaufania: błędny czas dostawy, zmyślony regulamin czy nieadekwatna instrukcja wsparcia mogą przysporzyć więcej pracy niż jasne, krótkie wyznaczenie granicy.

Dlaczego brak wyników to osobny problem produktowy

W przypadku chatbota AI korzystającego z bazy wiedzy brak odpowiedzi może wynikać z co najmniej trzech różnych przyczyn. Po pierwsze, danej informacji może po prostu nie być. Po drugie, informacja istnieje, ale nie udało się jej odnaleźć ze względu na język, sformułowanie, metadane lub ranking. Po trzecie, treść da się odnaleźć, jednak nie wystarcza ona do udzielenia pewnej odpowiedzi. Z perspektywy czatu te przypadki wyglądają początkowo podobnie, jednak w praktyce operacyjnej wymagają zupełnie innych działań.

Systemy wyszukiwania (retrieval) nie oceniają automatycznie, czy dana odpowiedź jest uzasadniona z punktu widzenia biznesu. Oficjalny przegląd dotyczący Retrieval-Augmented Generation w Azure AI Search opisuje, jak łączyć wyszukiwanie tekstowe i wektorowe w celu dostarczania źródeł dla odpowiedzi. Takie połączenie poprawia jakość wyszukiwania, ale nie zastępuje reguły określającej, kiedy wynik można uznać za wystarczający. Dlatego chatbot potrzebuje jasnej decyzji jeszcze przed wygenerowaniem tekstu: odpowiedzieć, dopytać czy bezpiecznie przekierować rozmowę.

Brak odpowiedzi to nie martwy punkt

Użyteczna odpowiedź awaryjna (fallback) nie polega na zwykłym stwierdzeniu „Nie mam na ten temat żadnych informacji”. Składa się z czterech elementów: określa granicę bez technicznych wymówek, unika bezpodstawnych zapewnień, oferuje precyzyjne pytanie doprecyzowujące lub bezpieczną alternatywę oraz, w razie potrzeby, wskazuje drogę do kontaktu z człowiekiem. Ton wypowiedzi może być przyjazny, ale nie powinien ukrywać niepewności bota.

• Granica: „Nie znajduję w zatwierdzonych materiałach wiarygodnych informacji na ten temat.”
• Kontekst: „Czy sprawa dotyczy zamówienia, umowy czy konfiguracji technicznej?”
• Kolejny krok: „Jeśli podasz nazwę produktu, mogę ponownie sprawdzić dostępne dokumenty.”
• Przekazanie rozmowy (handoff): „Aby uzyskać wiążącą informację, przekierujemy Twoje zapytanie do właściwego zespołu.”

Dzięki temu czat pozostaje przydatny bez wymyślania cen, terminów, konsekwencji prawnych czy deklaracji. Szczególnie w przypadku danych osobowych, płatności, indywidualnych ofert oraz kwestii związanych z bezpieczeństwem, reguła przekazania rozmowy człowiekowi powinna zadziałać odpowiednio wcześniej. Opublikowany wcześniej przewodnik po Human Handoff w wsparciu na stronie WWW pomaga zaplanować przekazywanie rozmów jako przejrzysty proces, a nie wyjście ewakuacyjne.

Operacjonalizacja decyzji przed udzieleniem odpowiedzi

Zespoły nie powinny przyjmować bezrefleksyjnie magicznych progów odcięcia z wersji demonstracyjnych. Wynik punktowy z wyszukiwarki to tylko sygnał, który może ulegać zmianom w zależności od indeksu, modelu, języka czy struktury zapytań. Dokumentacja dotycząca Semantic Ranking zwraca uwagę, że rozkład ocen modułu reranking może się różnić. Z tego powodu dany próg zawsze musi być dopasowany do przetestowanego zbioru danych oraz konkretnej kategorii błędu.

Praktyczny algorytm decyzyjny może łączyć kilka etapów weryfikacji. Czy istnieje przynajmniej jedno źródło z dozwolonego obszaru treści? Czy jest ono zgodne z językiem oraz aktualną wersją produktu lub umowy? Czy zawiera bezpośrednie uzasadnienie dla planowanej odpowiedzi? Czy najważniejsze wyniki nie są ze sobą sprzeczne? Generator może sformułować odpowiedź dopiero wtedy, gdy te kryteria zostaną spełnione w wystarczającym stopniu. W przeciwnym razie bot zadaje celowane pytanie precyzujące lub przechodzi do trybu fallback.

Przykład: Wiążąca informacja o dostawie

Gdy użytkownik pyta o termin dostawy konkretnego produktu, ogólny artykuł o wysyłce nie jest wystarczający. Bot może wyjaśnić, że nie znajduje wiążącej informacji, poprosić o numer zamówienia lub wariant produktu i skierować do działu obsługi. Odpowiedź w stylu „Twoja paczka dotrze jutro” nie miałaby natomiast pokrycia w bazie wiedzy. Ta sama zasada dotyczy gwarancji, rezygnacji z usług, kwestii zdrowotnych i dostępu do konta: im większe ryzyko ewentualnych szkód, tym mocniejsze muszą być dowody w źródłach.

Sprawdź wyszukiwanie, zanim zaczniesz przepisywać treści

Sytuacja braku odpowiedzi (No-Answer) jest często bardzo dobrym sygnałem pomiarowym. Zanim zespół przystąpi do pisania nowego promptu, powinien przeanalizować cały łańcuch: oryginalne pytanie, rozpoznany język, znormalizowane zapytanie wyszukiwania, zastosowane filtry, najwyżej ocenione wyniki, użyte wersje źródeł oraz wybrany rezultat końcowy. Pozwala to ustalić, czy brakuje samego dokumentu, czy też proces wyszukiwania omija właściwe treści.

1. Zanonimizuj i sklasyfikuj pytanie oraz intencję użytkownika, np. produkt, wsparcie, konto lub kwestie prawne.
2. Zestaw ze sobą oczekiwane źródła oraz faktycznie pobrane wyniki.
3. Zarejestruj filtry języka, ważności dokumentu, uprawnień dostępu i wersji produktu.
4. Sprawdź, czy najważniejsze wyniki naprawdę potwierdzają odpowiedź, czy zawierają jedynie podobne słowa kluczowe.
5. Oznacz dany przypadek jako lukę w dokumentacji, problem z wyszukiwaniem (retrieval), regułę bezpieczeństwa lub uzasadnione przekazanie do konsultanta.

Do takich porównań świetnie nadaje się niewielki zbiór testowy (Golden Set), składający się z realistycznych, wcześniej zweryfikowanych pytań. Artykuł poświęcony mierzeniu jakości odpowiedzi chatbota AI wyjaśnia, dlaczego pytania krytyczne i rzadkie nie mogą znikać w uśrednionych statystykach. Świadomie dołączaj pytania, na które nie ma odpowiedniej wiedzy w bazie. Tylko w ten sposób sprawdzisz, czy chatbot reaguje w sposób kontrolowany również wtedy, gdy czegoś nie wie.

Przekształcanie luk w wiedzy w proces edytorski

Pojedyncza rozmowa na czacie nie stanowi jeszcze powodu do tworzenia nowego wpisu w FAQ. Jednak powtarzające się, bezpieczne odpowiedzi typu fallback mogą sygnalizować, że ważna informacja jest niedostępna lub trudna do znalezienia. Do monitorowania tego zjawiska wystarczy oszczędna pod kątem danych lista zawierająca intencję, kategorię błędu, dany język, identyfikatory istniejących źródeł oraz status. Pełna treść rozmów, imiona i nazwiska czy dane konta nie powinny trafiać do ogólnego panelu analitycznego.

Osoba odpowiedzialna za treści decyduje następnie, czy należy rozbudować FAQ, doprecyzować stronę produktu, poprawić metadane, czy zmienić tekst przekazania rozmowy. Każda nowa treść wymaga opiekuna, źródła oraz daty publikacji. W przypadku informacji wrażliwych na czas, takich jak dostępność czy promocje, warto ustalić także datę wygaśnięcia. W ten sposób zespół zapobiega sytuacji, w której dobrze przemyślany artykuł sam staje się kolejnym nieaktualnym źródłem.

Nie używaj wskaźnika halucynacji jako głównej metryki jakości

Niski wskaźnik widocznych błędów może wprawiać w błąd, jeśli bot zbyt często unika odpowiedzi. Z drugiej strony, wysoki odsetek udzielonych odpowiedzi nie jest sukcesem, gdy nie mają one pokrycia w źródłach. Lepszym rozwiązaniem jest zwięzły zestaw wskaźników: udział bezpiecznie obsłużonych zapytań, udział uzasadnionych odpowiedzi fallback, wskaźnik przekazań (handoff) dla poszczególnych intencji, czas do podjęcia decyzji przez Dział Obsługi, powtarzające się luki oraz wyniki z ręcznych prób losowych. Analiza musi być możliwa w podziale na języki, obszary produktów i klasy ryzyka.

Ramy NIST AI Risk Management Framework zalecają zarządzanie ryzykiem w odpowiednim kontekście oraz wdrożenie procesów pomiaru i kontroli. Dla zespołów dbających o strony WWW nie oznacza to konieczności zapisywania każdej rozmowy. Oznacza to posiadanie jasnych zakresów odpowiedzialności oraz weryfikowalnych kryteriów dla bezpiecznych odpowiedzi.

Testy powinny odzwierciedlać realne sytuacje użytkowników. Krótkie pytanie zadane na smartfonie zawiera zazwyczaj mniej kontekstu niż rozbudowane zapytanie z komputera. Literówki, skróty produktowe i mieszanie języków to codzienne przypadki, a nie sytuacje wyjątkowe. Dlatego przetestuj nie tylko idealnie sformułowane pytanie, ale i jego warianty – bez numeru zamówienia, z kilkoma nazwami produktów czy nieprecyzyjnym określeniem czasu. Każdy wariant powinien wywołać popartą źródłami odpowiedź, sensowne pytanie doprecyzowujące lub bezpieczne przekazanie rozmowy. Fallback, który działa tylko przy perfekcyjnie sformułowanych pytaniach testowych, nie zapewni ochrony w codziennym użytkowaniu.

Równie cenny jest feedback płynący z Działu Obsługi Klienta. Gdy pracownicy odpowiadają na przekierowane zapytanie, mogą zwięźle skategoryzować jego przyczynę: brak informacji, nieaktualna informacja, wymagany dostęp do systemu lub konieczność podjęcia indywidualnej decyzji. Te kategorie łączą serwis internetowy, redakcję bazy wiedzy oraz obsługę klienta, bez zamieniania użytkowników w obiekt skomplikowanych analiz. Miesięczny przegląd najczęstszych kategorii w zupełności wystarczy do zaplanowania priorytetowych poprawek.

Lista kontrolna bezpiecznego fallbacku

• Odpowiedzi pojawiają się tylko na podstawie dopasowanych, zatwierdzonych i aktualnych źródeł.
• Progi odcięcia i kombinacje sygnałów zostały przetestowane na zbiorze Golden Set.
• Wysokie klasy ryzyka posiadają własne reguły doprecyzowania oraz przekazywania rozmów ludziom.
• Teksty fallback wyjaśniają ograniczenia bota bez zasłaniania się kwestiami technicznymi i bez stwarzania fałszywego poczucia bezpieczeństwa.
• Logi zawierają jedynie niezbędne, ograniczone do minimum informacje diagnostyczne.
• Powtarzające się przypadki mają wyznaczonego opiekuna i zweryfikowany status naprawy.
• Nowe źródła są ponownie weryfikowane przed publikacją, po zmianach oraz po upływie terminu ważności.

Podsumowanie: Uczciwe granice podnoszą jakość odpowiedzi

Profesjonalny chatbot AI nie dąży do odpowiadania na jak największą liczbę pytań za wszelką cenę – odpowiada tylko na to, co ma potwierdzenie w zweryfikowanej bazie wiedzy. Najlepsza odpowiedź typu fallback jest konkretna, pomocna i płynnie przekazuje wiążące sprawy w ręce ludzi. Jeśli zespoły potraktują przypadki braku odpowiedzi jako dane testowe i sygnały dla redakcji, zarówno wyszukiwanie, jak i sama treść ulegną mierzalnej poprawie. Zacznij od dziesięciu kluczowych pytań, dziesięciu pytań celowo pozbawionych odpowiedzi i jednego jasnego schematu przekazania rozmowy dla każdej klasy ryzyka. Stworzy to stabilny fundament, zanim chatbot przejmie na siebie większą odpowiedzialność.

Źródła

• Microsoft Learn: RAG and Generative AI in Azure AI Search
• Microsoft Learn: Semantic Ranking Overview
• Microsoft Learn: Create a Full-Text Query
• NIST: AI Risk Management Framework