Kiedy Twoja sztuczna inteligencja popełnia błąd przed klientem
Jak zaprojektować ścieżki eskalacji, przeprosiny i rejestry audytowe przed popełnieniem przez twój system AI pierwszego publicznego błędu.
Decyzja co oznacza "nieprawidłowe" zanim będzie na to potrzeba
Nie wszystkie błędne odpowiedzi zasługują na taką samą reakcję. Oceniaj je przed uruchomieniem, w prostym języku, z nazwiskiem osoby odpowiedzialnej za każdą ocenę.
Problem tonu - system jest surowy lub niepomocnie formalny - to kwestia szkoleniowa na przyszły tydzień. Błąd faktyczny dotyczący polityki, ceny lub terminu dostawy wymaga natychmiastowej naprawy i kontaktu z klientem. Błąd wpływający na pieniądze, bezpieczeństwo, zobowiązanie prawne lub dane osobowe to zdarzenie wymagające zatrzymania działania: funkcja jest wyłączana aż do zrozumienia, co się stało.
Upisz te trzy poziomy na stronie. Przypisz każdemu poziomowi właściciela, czas reakcji i wyraźną władzę do wyłączenia systemu. Osoba, która może wyłączyć system nie powinna musieć najpierw szukać dyrektora. Jeśli jedynym przełącznikiem jest wdrożenie, to nie masz przełącznika.
Daj klientowi osobę, a nie pętlę
Najbardziej szkodliwy wzorzec w usługach z AI to zamknięta pętla: klient nie zgadza się z systemem, system wyjaśnia się ponownie, a nie ma widocznego wyjścia. Ludzie przeaczą błędną odpowiedź, ale nie znoszą bycia uwięzionymi.
Każda interakcja z AI-em wymaga drogi do osoby dostępnej od pierwszego żądania, nie trzeciego. Uczyń to widocznym w interfejsie, a nie ukrytym na stronie pomocy. Przekieruj to do kogoś, kto może zobaczyć całą konwersację, jaką klient właśnie miał, aby klient nie musiał jej powtórzyć. Śledź również wskaźnik eskalacji jako główny wskaźnik - system, który nigdy się nie eskaluje jest zazwyczaj systemem, którego nikt nie potrafi znaleźć wyjścia.
Ustaw próg wyzwalający interwencję człowieka proaktywnie. Jeśli klient powtarza swoje słowa dwa razy, jeśli konwersacja trwa dłużej niż ustalone limit lub jeśli temat dotyczy zwrotów lub skarg, przekazuj bez oczekiwania na prośbę.
Przeprosiny to decyzja biznesowa
Podczas kontaktu z klientem w sprawie błędnej odpowiedzi trzy rzeczy są istotne: szybkość, precyzja i co oferujesz, aby tego nie powtórzyć. Przygotuj szablon teraz, gdy nikt nie jest pod presją.
Powiedz, co system zrobił źle. Powiedz, jaka jest poprawna pozycja. Powiedz, co robisz, aby tego nie powtórzyć. Nie obwiniaj modelu, nie wyjaśniaj architektury i nie używaj frazy "halucynacja AI" z klientem - brzmi to jak wymówka dla firmy, która wyszła z czymś, czego nie kontrolowała.
Następnie zdecyduj o polityce napraw w wyprzedzeniu. Jeśli system cytował błędną cenę, czy ją honorujesz? Jeśli obiecał termin dostawy, którego nie możesz spełnić, co oferujesz? Odpowiedz na te pytania w pokoju raz, a nie indywidualnie pod presją. Koszt konsekwentnej polityki jest zazwyczaj niższy niż koszt improwizacji.
Zapisz to, czego będziesz żałować
Śledzenie audytu przekształca argumentację w dochodzenie. Zapisz to od pierwszego dnia, bo nie będziesz mógł tego później zrekonstruować:
- Dokładne dane wejściowe i dokładne dane wyjściowe z datą i identyfikatorem konwersacji, jaką klient może przytoczyć
- Jaki model i jaka wersja go wyprodukowała oraz która prosta lub konfiguracja była aktywna
- Jakie dokumenty lub rekordy system pobrał, abyś mógł odróżnić złe źródło od złej odpowiedzi
- Każda interwencja człowieka: kto eskalował, kto przełączył, co zmienili
- Wynik - rozwiązane, zwrócone, skargi, utrata klienta
Zasady dotyczące przechowywania i dostępu do nich idą w parze. Zdecyduj jak długo będziesz przechowywać konwersacje, kto będzie mógł do nich uzyskać dostęp i jak klient korzystający ze swoich praw dotyczących danych otrzyma czystą odpowiedź. Przegląd prawny przed uruchomieniem jest tańszy niż po skargi.
Przetestuj to raz
Przeprowadź 30-minutowy trening przed uruchomieniem. Weź prawdopodobną błędną odpowiedź, przejdź przez wykrywanie, eskalację, kontakt z klientem i naprawę. Natychmiast znajdziesz luki: brak właściciela w weekendy, brak sposobu wyłączenia jednej funkcji bez wyłączania wszystkich lub brak logu, który pokazuje, jaka prosta była aktywna.
Wszystko to jest nieatrakcyjne, ale to właśnie określa, czy jedna błędna odpowiedź pozostanie jedną błędną odpowiedzią. Budujemy te ścieżki do systemów przed uruchomieniem, a nie po pierwszym złym tygodniu - ciężar jest łatwiejszy do noszenia, gdy ktoś już zaplanował na to.