Jaką metodą należy oceniać przyczynowo-skutkowy efekt wprowadzenia asystenta AI na pierwszej linii wsparcia klienta na satysfakcję użytkowników (CSAT) i koszty operacyjne, jeśli pełne testy A/B są niemożliwe z powodu ryzyka degradacji usług w godzinach szczytu, istnieje efekt uczenia się zarówno operatorów, jak i użytkowników, a część dialogów wymaga eskalacji do człowieka, tworząc zależność między grupą testową a kontrolną?

Odpowiedź na pytanie

Historycznie wsparcie dla klientów rozwijało się od monopolu ludzkich operatorów do automatyzacji poprzez chatboty oparte na regułach, które jednak często frustrowały użytkowników z powodu sztywnych scenariuszy. Współczesny etap charakteryzuje się wprowadzeniem Large Language Models (LLM) takich jak GPT-4 lub Claude, zdolnych do prowadzenia kontekstowych dialogów i rozwiązywania złożonych zadań bez sztywnego programowania logiki. Problem oceny skuteczności takich systemów pogłębia się tym, że tradycyjne metryki (czas rozwiązania, koszt na zgłoszenie) korelują z jakością obsługi nieliniowo: spadek kosztów może prowadzić do spadku CSAT, a wzrost automatyzacji — do wzrostu frustracji przy nieudanych eskalacjach.

Postawienie zadania wymaga izolacji czystego efektu właśnie asystenta AI, oddzielonego od sezonowości (świąteczne wyprzedaże zmieniają profil zapytań), efektu nowości (użytkownicy bardziej eksperymentują z botem w pierwszych tygodniach) i endogeniczności samo-selekcji (proste zapytania trafiają do bota, złożone — od razu do ludzi). Klasyczna randomizacja jest niemożliwa, ponieważ wyłączenie wsparcia dla grupy kontrolnej w godzinach szczytu stwarza ryzyko etyczne i biznesowe, a eskalacja dialogu z bota do człowieka zanieczyszcza czysty efekt.

Optymalne rozwiązanie — użycie Regression Discontinuity Design (RDD) na progu długości kolejki oczekiwania. Gdy liczba oczekujących użytkowników przekracza próg N (na przykład, 5 osób), system automatycznie oferuje asystenta AI jako alternatywę oczekiwania na operatora. To tworzy naturalny eksperyment: użytkownicy po lewej i prawej stronie progu są statystycznie identyczni pod względem obserwowanych i nieobserwowanych cech. Aby uwzględnić efekt uczenia się, model stosuje się Difference-in-Differences z grupą proxy — na przykład, użytkownicy w nocy, gdzie bot działa nieprzerwanie, są porównywani z analogicznym oknem czasowym przed wdrożeniem. Do analizy heterogeniczności efektów (różny wpływ na różne kategorie zapytań) używa się Causal Forests, które pozwalają zbudować warunkowe średnie efekty oddziaływania (CATE).

Sytuacja z życia

W dużym projekcie e-commerce z 500K zapytań miesięcznie zespół postanowił wdrożyć asystenta LLM do obsługi zapytań typu "gdzie jest moje zamówienie" i "zmień adres dostawy". Problem polegał na tym, że pilotaż zbiegł się ze świątecznym sezonem, kiedy ruch wzrósł trzykrotnie, a dane historyczne pokazały sezonowy spadek CSAT z powodu opóźnień w logistyce, niezależnie od jakości wsparcia.

Pierwsza rozważana opcja — bezpośrednie porównanie metryk miesiąc przed i miesiąc po wdrożeniu. Plusy: prostota wdrożenia, nie wymaga zmian w infrastrukturze. Minusy: całkowity brak kontroli sezonowości, niemożność oddzielenia efektu AI od efektu wzrostu ogólnego ruchu i zmiany asortymentu (noworoczne towary mają inny profil zwrotów). To podejście od razu odrzucono.

Druga opcja — test A/B geolokalizacyjny, w którym w niektórych regionach bot jest włączony, w innych — nie. Plusy: czysta randomizacja, prosta interpretacja. Minusy: efekty sieciowe (użytkownik może mieszkać w regionie A, ale składać zamówienie w regionie B dla przyjaciela), różna infrastruktura logistyczna wpływa na charakter zapytań, a w godzinach szczytu przeciążenie w jednym regionie stworzyłoby ryzyko utraty klientów. Zdecydowano się szukać alternatywy.

Wybrane rozwiązanie — RDD z progiem długości kolejki 3 osoby. Gdy kolejka przekroczyła 3 oczekujące, system proponował asystenta AI z możliwością pozostania w kolejce do człowieka. Aby skorygować efekt eskalacji, stosowano analizę Intent-to-Treat (ITT): porównywano wszystkich, którym zaoferowano bota, niezależnie od faktycznego wykorzystania, co unikało stronniczości samo-selekcji z powodu umiejętności technicznych. Dodatkowo stworzono Synthetic Control z danych historycznych podobnych kategorii zapytań, gdzie bot nie był stosowany (na przykład, złożone reklamacje), aby odfiltrować sezonowe wahania.

Ostateczny wynik: udało się zmierzyć, że asystent AI skraca średni czas rozwiązania prostych zapytań z 8 do 2 minut bez statystycznie istotnego spadku CSAT (różnica 0.1 punktu w granicach przedziału ufności). Jednak odkryto negatywny efekt dla segmentu "zwroty": przy eskalacji od bota do człowieka CSAT był o 15% niższy niż przy bezpośrednim kontakcie z operatorem, co doprowadziło do stworzenia osobnej ścieżki fast-track dla takich zapytań. Koszty operacyjne zmniejszyły się o 30% dzięki odciążeniu pierwszej linii.

Co często umykają kandydaci

Jak poprawnie zająć się endogenicznością eskalacji, gdy użytkownik, rozczarowany botem, przechodzi do człowieka z większą frustracją?

Kandydaci często proponują porównywać tylko udane dialogi z botem z dialogami z człowiekiem, ignorując stronniczość przetrwania. Prawidłowe podejście — analiza Local Average Treatment Effect (LATE) za pomocą zmiennych instrumentalnych: wykorzystanie losowych awarii technicznych w działaniu bota (gdy jest tymczasowo niedostępny) jako narzędzia do oceny efektu konkretnie dla tych, którzy byliby obsłużeni przez bota, gdyby była taka możliwość. To pozwala oddzielić efekt samej technologii od efektu selekcji według typu zapytania.

Dlaczego standardowe metryki dokładności bota (F1-score, BLEU) są niepoprawne dla oceny wpływu przyczyny?

Często analitycy koncentrują się na jakości generowania odpowiedzi, zapominając, że celem produktowym jest zmiana metryk biznesowych, a nie doskonałość techniczna. LLM może generować poprawne, ale nierelewantne odpowiedzi, lub odwrotnie — podawać technicznie nieprecyzyjne, ale skuteczne instrukcje rozwiązujące problem użytkownika (np. "spróbuj zrestartować aplikację"). Prawidłowe podejście to ocena uplift na poziomie sesji użytkownika z wykorzystaniem Propensity Score Matching w celu porównania złożoności zapytań, a nie dokładności generowania tekstu.

Jak uwzględnić niestacjonarność efektu przy ciągłym dokształcaniu modelu na nowych danych?

Kandydaci pomijają, że LLM w produkcji podlega ciągłemu uczeniu się: model jest dokształcany na oznaczonych dialogach codziennie, dlatego efekt tygodnia 1 nie jest porównywalny z efektem tygodnia 4. Należy używać modeli Time-Varying Treatment Effects z oceną rolling window lub Bayesian Structural Time Series (BSTS) do dynamicznej korekty baseline. Ignorowanie tego prowadzi do niedoszacowania długozasięgowego efektu, gdy bot "uczy się" specyfiki produktu, lub do przeszacowania efektu nowości.