Jak testować firmowego chatbota przed jego uruchomieniem

Automatycznego asystenta nie testuje się, czytając kilka rozmów i stwierdzając, że «dobrze odpowiada». Dobrze odpowiada na pytania, które zadają Państwo sami, znając już odpowiedzi i używając własnych słów. Prawdziwe pytania przychodzą źle napisane, niepełne, dotyczące przypadków, których nikt nie przewidział. Testy służą do zmierzenia się z nimi, zanim zada je klient.

Metoda nie wymaga szczególnych narzędzi: lista pytań, oczekiwana odpowiedź dla każdego z nich, wynik zapisywany ręcznie. Wymaga jednak dyscypliny powtarzania testów za każdym razem, gdy coś się zmienia.

Pytania testowe pochodzą z prawdziwych zapytań

Pytania wymyślone na spotkaniu przypominają odpowiedzi, które system zna. To błąd systematyczny: osoba, która je pisze, już wie, co jest w dokumentach.

• Wychodzi się od otrzymanych zapytań: wiadomości do wsparcia, zapytań ze strony, notatek osób odbierających telefony. Usuwa się dane identyfikujące osoby, zachowując pytanie w oryginalnej postaci, wraz z błędami.
• Obejmuje się zarówno typowe, jak i rzadkie przypadki: nie tylko dziesięć najczęstszych pytań, ale też te, które pojawiają się raz w miesiącu i sprawiają trudność osobie odpowiadającej.
• Uwzględnia się pytania, na które nie należy odpowiadać: ceny do negocjacji, sprawy umowne, zapytania dotyczące osób trzecich.
• Dodaje się pytania sformułowane źle: pół zdania, dwa pytania naraz, błędny szczegół podany jako pewnik.

Sto pytań zebranych w ten sposób jest warte więcej niż tysiąc stworzonych przy biurku, ponieważ odzwierciedlają rzeczywisty rozkład zapytań, łącznie z tymi niewygodnymi.

Testy, których nikomu nie chce się robić

• Pytania z fałszywym założeniem: «skoro Państwo też to robicie…», podczas gdy tego nie robicie. System musi to sprostować, a nie potwierdzać.
• Próby nakłonienia go do zignorowania otrzymanych instrukcji lub powiedzenia rzeczy, których firma nigdy by nie powiedziała. To nie jest hipoteza teoretyczna: zdarza się to w systemach publicznych.
• Pytania na tematy zbliżone, ale wykraczające poza zakres, aby sprawdzić, czy granica jest rozpoznawana.
• Zapytania proszące o zobowiązanie: rabat, termin, gwarancję.

Co jest akceptowalną odpowiedzią

Przed rozpoczęciem testów trzeba zdecydować, co uznaje się za poprawne, w przeciwnym razie ocena zmienia się w zależności od osoby czytającej i pory dnia.

1. Treść: jakie informacje muszą się znaleźć, aby odpowiedź była użyteczna, i jakie nie powinny się pojawić.
2. Źródło: z jakiego dokumentu ma pochodzić. Poprawna odpowiedź wzięta z niewłaściwego dokumentu to problem odłożony w czasie, który ujawni się, gdy ten dokument się zmieni.
3. Wstrzymanie się od odpowiedzi: dla niektórych pytań poprawną odpowiedzią jest przyznanie, że się nie wie, i wskazanie innej drogi. Trzeba to zapisać jako oczekiwany wynik, w przeciwnym razie osoba oceniająca zaznaczy to jako błąd.
4. Forma: poprawna odpowiedź, ale trzykrotnie dłuższa niż potrzeba, w oknie czatu jest odpowiedzią, której nikt nie przeczyta do końca.

Karta oceny

Testy zapisuje się w jednej tabeli, która służy do porównania dwóch wersji i pokazania innym, jak przebiega praca. Poniższe wiersze mają charakter poglądowy.

Kolumna wagi to ta, na podstawie której podejmuje się decyzje. Niedokładność w szczególe nie waży tyle samo co zobowiązanie podjęte w imieniu firmy: skalę trzeba ustalić wcześniej, a minimalne rozróżnienie to podział na odpowiedzi niedokładne, odpowiedzi błędne i odpowiedzi, które kogoś wiążą lub narażają na ryzyko.

Poza błędami: co warto liczyć

• Wstrzymania się od odpowiedzi: ile razy system zatrzymał się, gdy powinien, i ile razy zatrzymał się, mimo że mógł odpowiedzieć. To dwie przeciwstawne wady i naprawia się je w przeciwny sposób.
• Przekazania do osoby, podzielone według tematu: pokazują, gdzie brakuje publicznie dostępnych informacji.
• Odpowiedzi poprawne, ale bezużyteczne: trafne, ogólnikowe, i pozostawiające czytającego dokładnie w tym samym punkcie co wcześniej.
• Zachowanie w przypadku wyjątków: co się dzieje, gdy połączenie nie odpowiada lub dokument jest niedostępny. System, który w takiej sytuacji improwizuje, jest bardziej niebezpieczny niż taki, który się zatrzymuje.

Powtarzanie testów po każdej zmianie

Lista pytań przydaje się przede wszystkim po pierwszym razie. Zachowanie systemu zmienia się, gdy zmienia się jedna z trzech rzeczy, a przynajmniej jedna z nich się zmieni.

1. Źródła: zaktualizowany dokument, przepisana strona, nowy cennik.
2. Instrukcje: reguła dodana w celu poprawienia jednego przypadku często psuje dwa inne i jest najczęstszą przyczyną nagłych pogorszeń.
3. Model bazowy, który może zostać zaktualizowany bez wiedzy nikogo w firmie.

Dlatego te same pytania trzeba okresowo przechodzić ponownie i przed każdą publikacją. To nużąca praca, ale jedyna, która zapobiega wzajemnemu znoszeniu się poprawek.

Kiedy testy mówią, żeby nie publikować

• Jeśli pozostają poważne błędy. Odpowiedź, która zobowiązuje firmę lub dotyczy bezpieczeństwa, nie ma akceptowalnej częstotliwości występowania.
• Jeśli system działa tylko przy dobrze napisanych pytaniach: klienci nie piszą dobrze.
• Jeśli źródła są ze sobą sprzeczne. W tym przypadku wada nie leży po stronie systemu: ujawnia on sprzeczność, która już istniała, i trzeba ją najpierw usunąć.
• Jeśli nie istnieje naprawdę działające przekazanie sprawy do osoby.

Czego nie obejmuje ten poradnik

Tu mowa jest o jakości odpowiedzi: jak się testuje, jak się to zapisuje, kiedy można opublikować. Ścieżka przekazania sprawy do osoby — kiedy się zatrzymać i co przekazać — projektuje się osobno. A ocena ekonomiczna projektu, czyli czy i na ile się opłaca, opiera się na innych kryteriach i nie wynika z liczby poprawnych odpowiedzi.