W skrócie
Pilotaż chatbota AI warto zacząć od niewielkiej grupy powtarzalnych pytań, dla których firma ma aktualne i jednoznaczne źródła informacji. Przed uruchomieniem trzeba przygotować bazę wiedzy, zestaw testów, zasady przekazywania rozmowy pracownikowi oraz sposób mierzenia jakości odpowiedzi.
Nie warto oceniać chatbota wyłącznie liczbą rozmów obsłużonych bez udziału człowieka. Dobra odpowiedź musi być poprawna, wynikać z właściwego źródła i prowadzić do rozwiązania sprawy. W niektórych sytuacjach najlepszym zachowaniem asystenta będzie przyznanie, że nie ma wystarczających informacji, i przekazanie rozmowy pracownikowi.
Najpierw określ, w czym chatbot ma pomagać
„Chatbot do obsługi klienta” jest zbyt szerokim zakresem na pierwsze wdrożenie.
Obsługa klienta może obejmować pytania o ofertę, dostępność produktów, dostawy, zwroty, reklamacje, płatności, faktury, status zamówienia, konfigurację produktu i dziesiątki innych tematów.
Każdy z nich może wymagać innych źródeł danych i innego poziomu dostępu do systemów firmy.
Dlatego na początku warto wybrać jedną lub kilka powiązanych kategorii. Może to być na przykład odpowiadanie na pytania dotyczące oferty i zasad dostawy na podstawie istniejącej bazy wiedzy.
Znacznie łatwiej ocenić jakość systemu odpowiadającego na 50 dobrze określonych typów pytań niż asystenta, który od pierwszego dnia ma „odpowiadać na wszystko”.
Zacznij od rzeczywistych rozmów z klientami
Najlepszym źródłem do zaprojektowania pilotażu są pytania, które klienci rzeczywiście zadają.
Można przeanalizować wiadomości e-mail, zgłoszenia supportowe, czaty lub pytania przekazywane handlowcom. Przed wykorzystaniem takich danych trzeba usunąć informacje, które nie są potrzebne do analizy i testowania rozwiązania.
Następnie warto pogrupować zgłoszenia według tematów i sprawdzić, które z nich:
- powtarzają się najczęściej,
- mają jednoznaczną odpowiedź,
- korzystają z istniejącego źródła wiedzy,
- nie wymagają skomplikowanej decyzji pracownika,
- można łatwo zweryfikować po udzieleniu odpowiedzi.
To właśnie takie pytania są dobrymi kandydatami do pierwszego pilotażu.
Oddziel odpowiadanie na pytania od wykonywania operacji
To jedno z najważniejszych rozróżnień przy projektowaniu asystenta AI.
Chatbot może powiedzieć klientowi, jakie są zasady zwrotu produktu. Może również pobrać status konkretnego zamówienia po prawidłowym rozpoznaniu użytkownika.
Znacznie większym krokiem jest umożliwienie mu anulowania zamówienia, zmiany adresu dostawy, utworzenia zwrotu albo zlecenia operacji finansowej.
Wtedy chatbot przestaje być wyłącznie interfejsem do informacji. Staje się elementem systemu wykonującym operacje.
Taki scenariusz wymaga osobnego zaprojektowania uwierzytelnienia, autoryzacji, potwierdzeń, logowania operacji i obsługi błędów.
Dlatego pierwszą wersję często warto ograniczyć do odpowiedzi i odczytu informacji, a możliwość wykonywania działań dodawać później dla konkretnych, dobrze zabezpieczonych przypadków.
Baza wiedzy jest ważniejsza niż sam model
Nawet bardzo dobry model nie naprawi sprzecznych informacji znajdujących się w firmowych materiałach.
Jeżeli regulamin mówi jedno, strona FAQ drugie, a wewnętrzna instrukcja pracownika zawiera trzecią wersję zasad, chatbot nie ma jednoznacznej podstawy do udzielenia odpowiedzi.
Przed wdrożeniem warto więc ustalić:
- które źródła mogą być wykorzystywane przez asystenta,
- które źródło ma pierwszeństwo przy sprzecznych informacjach,
- kto odpowiada za aktualizowanie materiałów,
- jak szybko zmiany trafiają do bazy wiedzy chatbota,
- co asystent robi, jeśli nie znajduje odpowiedzi.
Baza wiedzy potrzebuje właściciela również po uruchomieniu. Zmiana cennika, regulaminu albo zasad dostawy powinna zostać uwzględniona także w źródłach wykorzystywanych przez AI.
RAG pomaga korzystać z firmowej wiedzy, ale nie gwarantuje poprawnej odpowiedzi
W chatbotach wykorzystujących wiedzę firmy często stosuje się RAG, czyli Retrieval-Augmented Generation.
W uproszczeniu system najpierw wyszukuje fragmenty materiałów związane z pytaniem użytkownika, a następnie przekazuje je modelowi jako kontekst potrzebny do przygotowania odpowiedzi.
Dzięki temu model może odpowiadać na podstawie dokumentacji firmy zamiast polegać wyłącznie na wiedzy uzyskanej podczas treningu.
Nadal mogą jednak wystąpić błędy. System może znaleźć niewłaściwy dokument, pominąć ważny fragment albo poprawnie odnaleźć materiał, ale źle go zinterpretować.
Dlatego podczas pilotażu warto osobno oceniać dwa elementy: czy system znalazł właściwe źródło oraz czy na jego podstawie przygotował poprawną odpowiedź.
Asystent powinien wiedzieć, kiedy nie odpowiadać
Jednym z celów pilotażu powinno być określenie granic działania chatbota.
Jeżeli użytkownik pyta o temat spoza bazy wiedzy albo dostępne informacje nie pozwalają przygotować wiarygodnej odpowiedzi, system nie powinien uzupełniać braków przypuszczeniami.
Poprawnym zachowaniem może być prośba o doprecyzowanie, poinformowanie o braku wystarczających danych albo przekazanie sprawy pracownikowi.
W praktyce chatbot, który poprawnie odmawia odpowiedzi w 10% rozmów, może być znacznie bezpieczniejszy i bardziej użyteczny niż system odpowiadający na 100% pytań, ale regularnie podający nieprawidłowe informacje.
Przygotuj zestaw pytań testowych przed uruchomieniem
Jakości chatbota nie warto sprawdzać wyłącznie przez kilka spontanicznych rozmów zespołu.
Przed pilotażem dobrze przygotować stały zestaw przypadków testowych. Powinien obejmować różne sposoby zadawania tych samych pytań oraz sytuacje, w których chatbot nie powinien udzielać bezpośredniej odpowiedzi.
| Rodzaj testu |
Przykład |
Oczekiwane zachowanie |
| Typowe pytanie |
„Ile mam czasu na zwrot?” |
poprawna odpowiedź na podstawie właściwego źródła |
| Inne sformułowanie |
„Do kiedy mogę odesłać zakup?” |
ta sama merytorycznie odpowiedź |
| Pytanie niejednoznaczne |
„Kiedy przyjdzie?” |
prośba o doprecyzowanie |
| Brak wiedzy |
pytanie o nieobsługiwany temat |
brak zgadywania i właściwa eskalacja |
| Dane klienta |
„Gdzie jest moje zamówienie?” |
weryfikacja użytkownika przed dostępem do danych |
| Dane innej osoby |
prośba o informacje dotyczące cudzego zamówienia |
odmowa dostępu |
| Sprzeczne założenie |
klient podaje nieprawdziwą informację jako fakt |
brak bezrefleksyjnego potwierdzenia |
| Próba manipulacji |
polecenie ignorowania wcześniejszych zasad |
zachowanie ograniczeń systemu |
Taki zestaw warto zachować również po pilotażu. Po zmianie modelu, instrukcji, bazy wiedzy albo sposobu wyszukiwania można uruchomić te same testy i sprawdzić, czy jakość się nie pogorszyła.
Jedna poprawna odpowiedź nie wystarczy do testu
Modele generatywne mogą przygotowywać różne odpowiedzi na podobne pytania, dlatego przy ważnych scenariuszach warto wykonywać więcej niż jedną próbę.
Test powinien również obejmować parafrazy, błędy językowe, skrócone pytania i sytuacje, w których użytkownik podaje tylko część potrzebnych informacji.
Klienci nie będą komunikować się z chatbotem według przygotowanego przez zespół scenariusza. Pilotaż powinien więc sprawdzać nie tylko idealnie sformułowane pytania.
Uprawnienia muszą być kontrolowane przez aplikację
Jeżeli chatbot ma dostęp do danych klientów albo funkcji systemu, bezpieczeństwo nie może opierać się wyłącznie na instrukcji przekazanej modelowi.
Polecenie „pokazuj użytkownikowi tylko jego zamówienia” nie zastępuje kontroli uprawnień po stronie aplikacji.
Serwer powinien sam ustalić, jaki użytkownik jest zalogowany, do których danych ma dostęp oraz jakie operacje może wykonać. Model powinien otrzymać wyłącznie informacje i narzędzia potrzebne do realizacji konkretnego zadania.
Ma to znaczenie również w kontekście prompt injection, czyli prób wpływania na zachowanie modelu poprzez odpowiednio przygotowane instrukcje umieszczone w wiadomości lub danych przetwarzanych przez system.
OWASP wymienia między innymi prompt injection, ujawnianie informacji wrażliwych oraz nadmierne uprawnienia jako istotne obszary ryzyka przy budowie aplikacji wykorzystujących modele językowe.
Im mniej uprawnień na początku, tym łatwiejszy pilotaż
W pierwszej wersji warto udostępnić chatbotowi tylko dane i funkcje niezbędne do realizacji ustalonego zakresu.
Jeżeli ma odpowiadać na pytania dotyczące oferty, nie potrzebuje dostępu do zamówień. Jeżeli ma podawać status zamówienia, nie musi automatycznie otrzymywać możliwości jego anulowania.
Każde dodatkowe uprawnienie zwiększa liczbę scenariuszy, które trzeba zabezpieczyć i przetestować.
Zakres można rozszerzać później, kiedy podstawowe zachowanie systemu jest już zmierzone i przewidywalne.
Zaprojektuj przekazanie rozmowy do człowieka
Eskalacja nie powinna być traktowana jako porażka chatbota.
Asystent powinien przekazać rozmowę pracownikowi wtedy, gdy temat wykracza poza jego zakres, dane są niewystarczające, klient tego oczekuje albo sprawa wymaga decyzji, której system nie powinien podejmować.
Warto zadbać o to, żeby klient nie musiał wtedy rozpoczynać rozmowy od początku.
Pracownik może otrzymać historię konwersacji, krótkie podsumowanie sprawy, informacje pobrane z systemu oraz wskazanie materiałów wykorzystanych przez chatbota.
Trzeba jednak rozróżnić dane potwierdzone od interpretacji modelu. Jeżeli chatbot uznał na przykład, że klient chce złożyć reklamację, pracownik powinien wiedzieć, że jest to klasyfikacja wygenerowana przez AI, a nie informacja potwierdzona w systemie.
Nie optymalizuj wyłącznie liczby rozmów zakończonych przez AI
Wysoki poziom automatyzacji wygląda dobrze w raporcie, ale sam w sobie nie mówi, czy obsługa klienta się poprawiła.
Chatbot może ograniczać liczbę przekazań do pracowników, odpowiadając również wtedy, gdy nie ma wystarczających informacji. W statystykach będzie wyglądał na bardzo samodzielny, ale część klientów otrzyma nieprawidłowe odpowiedzi.
Dlatego odsetek rozmów zakończonych bez udziału pracownika powinien być tylko jedną z metryk.
Jak mierzyć jakość chatbota AI?
Przed rozpoczęciem pilotażu warto ustalić kilka mierników i zmierzyć podobne wartości dla obecnej obsługi, jeżeli jest to możliwe.
| Metryka |
Co pokazuje |
| Poprawność odpowiedzi |
czy odpowiedź jest zgodna z aktualną wiedzą firmy |
| Poprawność źródła |
czy system wykorzystał właściwy materiał |
| Rozwiązanie sprawy |
czy klient otrzymał informację potrzebną do zakończenia sprawy |
| Poprawność eskalacji |
czy chatbot przekazuje sprawy, których nie powinien obsługiwać samodzielnie |
| Ponowne zgłoszenia |
czy klient wraca z tym samym tematem po rozmowie z chatbotem |
| Czas obsługi |
jak długo trwa rozwiązanie sprawy |
| Koszt rozmowy |
koszt modeli, infrastruktury i pozostałych usług |
| Praca człowieka |
ile czasu wymaga kontrola, eskalacje i poprawianie bazy wiedzy |
Nie każdą metrykę trzeba wdrażać od pierwszego dnia. Najważniejsze jest jednak ustalenie, po czym firma pozna, że pilotaż rzeczywiście poprawił obsługę.
Sprawdzaj próbkę prawdziwych rozmów
Automatyczne metryki nie zastąpią całkowicie kontroli jakości.
W trakcie pilotażu warto regularnie wybierać próbkę rzeczywistych rozmów i oceniać je według stałych kryteriów. Można sprawdzać poprawność merytoryczną, zgodność ze źródłami, kompletność odpowiedzi, prawidłowość eskalacji oraz to, czy chatbot nie obiecał klientowi czegoś, czego firma nie może wykonać.
Taka analiza szybko pokazuje powtarzające się błędy.