Jak mierzyć jakość rozmów z AI poza prostym sentymentem?

Większość z nas zna ten scenariusz. Kontakt z infolinią lub botem, sprawa z pozoru prosta, a rozmowa ciągnie się w nieskończoność. Kolejne pytania bez związku z problemem, kolejne porady, które zostały już wypróbowane, aż do momentu, w którym jedynym celem rozmowy staje się „połączenie z człowiekiem”.

Niedawno doświadczyłem tego w praktyce, kontaktując się z botem jednej z arabskich linii lotniczych. Prosta sprawa okazała się być długą rozmową z szeregiem pętli i nieprzydatnych odpowiedzi. Finalnie problem rozwiązał konsultant, w kilka minut. Co istotne: analiza sentymentu moich wiadomości wykazałaby zapewne ton neutralny. Komunikacja pozostała uprzejma, jednak przez pętle moja frustracja narastała z każdą kolejną turą.

Na tym polega zasadniczy problem pomiaru. Standardowe metryki oceny rozmów z AI, czas odpowiedzi, wskaźnik defleksji, sentyment pojedynczych wiadomości mierzą pojedyncze klatki. Frustracja natomiast rozgrywa się w całym filmie: w powtarzaniu tej samej intencji po raz trzeci, w propozycjach kroków już wykonanych, w rozmowie, która przestała robić postęp, mimo że żadna pojedyncza wiadomość nie zawiera nic „negatywnego”. Literatura obsługi klienta określa najbardziej dotkliwy wariant tego zjawiska mianem double deviation: nieudana próba naprawy błędu wyrządza większą szkodę niż sam błąd.

Dla naszego narzędzia konwersacyjnego stworzyliśmy działający system, którego zadaniem jest monitorowanie właśnie tych zjawisk. Zamiast pytać „czy ta wiadomość jest negatywna?”, system analizuje trajektorię całej sesji: czy rozmowa robi postęp, czy wpadła w pętlę, czy po błędzie nastąpiła naprawa czy pogorszenie, czy stan końcowy jest lepszy od początkowego oraz w którym momencie trajektoria się załamała. Ocenę realizuje model językowy w roli sędziego (LLM-as-a-Judge), operujący na stałych rubrykach, z twardym wymogiem wskazania fragmentu transkryptu uzasadniającego każdy werdykt. System nie interpretuje „prawdziwych emocji” użytkownika, lecz rejestruje wyłącznie to, co obserwowalne w tekście.

Architektura działa produkcyjnie i przetworzyła dotychczas 1 146 sesji z pięciu branż. Jedna z obserwacji dobrze ilustruje skalę problemu: wśród 119 sesji oznaczonych przez system jako priorytetowe do interwencji ani jedna nie zakończyła się pełnym rozwiązaniem sprawy użytkownika, mimo że znaczna część z nich wyglądała na „poprawne” rozmowy, które klasyczny raport przepuściłby bez zastrzeżeń.

Rozwiązanie ma status prototypu: przedstawione wyniki to wstępne obserwacje z pilotażu, a formalna walidacja, niezależna anotacja, zgodność ocen, korelacja ze wskaźnikami biznesowymi jest w toku.

Pełny opis rozwiązania wraz z architekturą, taksonomią ryzyk, schemat danych wyjściowych oraz plan walidacji znajduje się w whitepaperze poniżej.