Voicebot może przejść demo i nadal zawieść na produkcji. Powód jest prosty: użytkownik nie rozmawia z samym LLM-em. Przechodzi przez cały łańcuch: audio, rozpoznawanie mowy, turn-taking, logikę rozmowy, RAG, tool calle, API i finalny stan procesu.
Najważniejsza zasada: test voicebota kończy się dopiero wtedy, gdy sprawdzisz, czy proces biznesowy rzeczywiście zakończył się poprawnym stanem. Naturalna odpowiedź głosowa nie jest dowodem, że rezerwacja, anulowanie albo zmiana danych faktycznie się wykonała.
1. Testuj warstwy, nie tylko transkrypcję
Największy błąd to redukowanie testu do pytania „czy bot dobrze odpowiedział?”. W voice trzeba rozdzielić co najmniej kilka rodzajów ryzyka. Nie każdy system ma wszystkie warstwy, dlatego zakres powinien wynikać z architektury i ryzyka procesu.
- Audio / ASR: czy krytyczne słowa, nazwy, daty, godziny i numery są rozpoznawane wystarczająco dobrze w realnych warunkach.
- Turn-taking: czy agent wie, kiedy użytkownik skończył mówić, czy nie wchodzi w słowo i czy potrafi zareagować na przerwanie.
- Conversation state: czy korekta użytkownika nadpisuje poprzednią wartość i czy stan nie gubi się po dygresji.
- Knowledge / RAG: czy odpowiedź opiera się na właściwym źródle i aktualnej intencji.
- Tools / API: czy wybrano właściwe narzędzie, z prawidłowymi argumentami i we właściwym momencie.
- Business outcome: czy backend po rozmowie ma oczekiwany stan.
2. Warstwa głosowa ma własne failure modes
Voice dodaje problemy, których nie zobaczysz w chatbocie. Testy powinny obejmować różne tempo mowy, pauzy, przerwania, hałas adekwatny do użycia i wypowiedzi, w których użytkownik zmienia zdanie w połowie. Mechanizmy VAD i turn detection wpływają bezpośrednio na to, kiedy agent uzna wypowiedź za zakończoną i czy przerwie własną odpowiedź po rozpoczęciu mowy użytkownika.
Nie ustawiałbym jednego „magicznego” progu latencji dla wszystkich systemów. Akceptowalny czas zależy od procesu, kanału i oczekiwań użytkownika. Ważniejsze jest zmierzenie go w powtarzalny sposób i sprawdzenie zachowania w gorszych warunkach, a nie pojedynczy pomiar w idealnym połączeniu.
3. Krytyczne sloty wymagają potwierdzenia i walidacji
Nie każdy błąd ASR ma taką samą wagę. Pomyłka w mało istotnym słowie może nie zmienić wyniku. Pomyłka w dacie, kwocie, nazwisku, numerze zamówienia albo godzinie może wykonać złą operację. Dlatego scenariusze powinny oznaczać dane krytyczne i definiować, kiedy system ma je potwierdzić, odrzucić albo eskalować.
4. Testuj błędy integracji i recovery
Voicebot powinien być sprawdzany również wtedy, gdy narzędzie lub API nie działa idealnie. Szczególnie istotne są timeouty, konflikty zasobów, błędy 4xx/5xx, częściowe wykonanie operacji oraz retry. Timeout nie zawsze oznacza, że operacja się nie wykonała, więc bez sprawdzenia stanu retry może stworzyć duplikat.
Przykład: agent wysyła book(), połączenie timeoutuje, ale backend zdążył zapisać wizytę. Ślepy retry może utworzyć drugą rezerwację. Poprawny test sprawdza idempotency albo weryfikację stanu przed ponowieniem.
5. Nie oczekuj identycznego zdania za każdym razem
Systemy AI mogą być niedeterministyczne. Twarde reguły biznesowe nadal da się testować deterministycznie: wybrane narzędzie, argumenty, kod odpowiedzi API, liczba rezerwacji czy finalny status. Dla jakości semantycznej lepsze mogą być kryteria, score albo kilka uruchomień z progiem akceptacji niż porównanie całej odpowiedzi znak w znak.
W praktyce dobrze rozdzielić „czy proces się wykonał” od „jak dobrze agent to zakomunikował”. To pozwala uniknąć sytuacji, w której ładnie brzmiąca odpowiedź przykrywa błąd biznesowy.
6. Minimalny zestaw przed go-live
- Najważniejszy happy path od początku do finalnego stanu backendu.
- Co najmniej jeden błąd reguły biznesowej lub niespełniony precondition.
- Korekta multi-turn i zmiana krytycznego slotu.
- Nieudany tool/API call oraz recovery.
- Przerwanie wypowiedzi i ponowne przejęcie tury.
- Przypadek słabego lub niepewnego rozpoznania krytycznej wartości.
- Scenariusz po zmianie promptu/modelu, który wcześniej już się zepsuł.
Pełny zakres powinien być risk-based: im większa szkoda po błędzie, tym mocniejsze kryteria, więcej wariantów i lepsza obserwowalność procesu.
Źródła i standardy
To są źródła techniczne, na których opiera się metodologia opisana wyżej. Nie oznacza to certyfikacji zgodności z tymi standardami.