Kąt Andersona

AI może pomóc Ci szybciej dotrzeć do prawdziwej osoby

mm
Dodaj Unite.AI do preferowanych źródeł w Google
A stock-style image of a smashed domestic landline phone, where the receiver has been thrust into the main phone body. Qwen, Qwen Edit 5209, Firefly V3 et al.

Naukowcy odkryli, że otwarte źródło ChatGPT-style AI może potencjalnie skierować dzwoniących do odpowiedniej osoby w centrum obsługi klienta przy użyciu języka naturalnego, bez konieczności przechodzenia przez frustrujące wybory menu, które różnią się co tydzień i wydają się celowo utrudniające.

 

Próba dotarcia do prawdziwej osoby w centrum obsługi klienta może być frustrującym doświadczeniem, ze względu na konieczność nawigowania przez wiele wyborów z ograniczoną ilością czasu – często bez pewności, który z nich odpowiada Twojemu przypadkowi. Jeśli żaden z nich nie odpowiada, doświadczeni użytkownicy mają tendencję do stosowania sztuczek i obejść, aby uzyskać dostęp do ludzkiego doradcy i wyjść z “piekła wyborów”. Większość z nas rozpozna to jako bardziej lub mniej “walkę” i nieprzyjazne doświadczenie dla użytkownika.

Nie jest zaskakujące, że centra obsługi klienta są na pierwszej linii do uzupełnienia lub zastąpienia przez systemy AI; i, pomimo zachęcania do ostrożności ze strony niektórych, automatyzacja centrum obsługi klienta pozostaje łatwym celem dla nagłówków technologicznych i perspektywy innowacji opartej na AI, która może zaoferować niezwykle wczesne zwrotne korzyści.

Zamknięte biuro

Jednak istnieją pewne obszary, w których otwarte źródło i swobodnie dostępne dane są rzadko stosowane lub dostępne, i to jest jeden z nich. Ma to sens: każda firma zainteresowana automatyzacją swoich systemów odpowiedzi na zapytania klientów będzie miała ograniczone lub żadne zainteresowanie udostępnianiem danych, które napędzają ich trudno zdobyte spostrzeżenia, metody lub korporacyjną własność intelektualną.

Przede wszystkim, udostępnianie tych zasobów kosztowałoby ich przewagę nad konkurentami; co więcej, biorąc pod uwagę, jak podatne są systemy AI na ujawnienie poufnych informacji, jest to również ryzykowne pod względem prawnym.

To doprowadziło do powstania wielu dobrze inwestowanych podmiotów rozwijających niezależne systemy odpowiedzi na zapytania klienta z użyciem AI; oraz do rozprzestrzenienia się startupów i ugruntowanych graczy B2B, które starają się zaspokoić rosnące zapotrzebowanie na możliwości odpowiedzi na zapytania klienta oparte na AI.

Asystent głosowy PolyAI otwiera połączenie serwisowe dla fikcyjnej firmy 'Augusta Lawn Care', wykorzystując duże ilości szkoleniowych rozmów, aby zautomatyzować odpowiedzi za pomocą istniejącej infrastruktury centrum obsługi klienta. Źródło: zebrano w https://www.unite.ai/best-ai-phone-platforms/

Asystent głosowy PolyAI otwiera połączenie serwisowe dla fikcyjnej firmy ‘Augusta Lawn Care’, wykorzystując duże ilości szkoleniowych rozmów, aby zautomatyzować odpowiedzi za pomocą istniejącej infrastruktury centrum obsługi klienta. Źródło

Dodatkowo, wyścig, aby usunąć frustrację związaną z nawigowaniem w labiryncie centrum obsługi klienta, okazał się impulsem do badań – choć większość takich publikacji ma tendencję do pojawiania się poza sieciami publikacji badań otwartych, takimi jak Arxiv, w związku z ogólnie tajemniczym charakterem Interaktywnej Odpowiedzi Głosowej (IVR).

Zamiast tego, badania, dane i informacje biznesowe związane z automatyzacją systemów odpowiedzi na zapytania klienta są wszystkie zazdrośnie strzeżone, z bardzo niewielką ilością opcji open source – nawet jeśli użycie systemów FOSS i danych oferowałoby prawnie uzasadnioną opcję, co jest wątpliwe.

Local Call

Z tym na uwadze, jest odświeżające zobaczyć nowy artykuł z Kolumbii, który próbuje wyłamać się z corporate vault, przynajmniej trochę. Nowa praca, zwięzły wpis zatytułowany Poza IVR Touch-Tones: Customer Intent Routing using LLMs, pochodzi od badacza z Universidad Distrital Francisco José de Caldas w Bogocie i twierdzi, że jest to pierwszy niezamknięty projekt, który wykorzystuje Duże Modele Językowe (LLM) do wygenerowania działającego schematu systemu Customer Intent Routing (CIR).

Zamiast próbować uzyskać dostęp do danych z prawdziwych połączeń lub własnych drzew menu, nowy projekt generuje wszystkie komponenty od podstaw, wykorzystując trzy modele AI: jeden do wynalezienia realistycznego menu centrum obsługi klienta; drugi do symulowania setek skarg klientów; i trzeci, aby działać jako chatbot, próbując skierować te skargi do odpowiedniego miejsca.

Wynikiem jest w pełni syntetyczne, ale przekonywujące środowisko testowe, zawierające fikcyjną firmę telekomunikacyjną, wraz z 920 odrębnymi zapytaniami użytkowników, co pozwala na przeprowadzenie eksperymentu, aby ominąć ryzyko prawne, jednocześnie badając, jak dobrze obecne AI mogą interpretować niejasne, zabrudzone mowy i nadal łączyć dzwoniącego z odpowiednią osobą.

Testy wskazują, że system może dopasować skargi dzwoniących do odpowiedniego miejsca w centrum obsługi klienta z dokładnością do 89,13%, szczególnie gdy menu jest “spłaszczane” zamiast zawierać werbalne opisy (więcej na ten temat później).

Badanie również wykazało, że gdy dzwoniący używali bardziej swobodnego lub zróżnicowanego języka, AI popełniało więcej błędów; ale że niektóre z tych błędów wystąpiły nie dlatego, że AI źle zrozumiało, ale dlatego, że samo menu było mylące.

Przykłady interakcji klienta, udostępnione w ramach nowego projektu. [Źródło] https://figshare.com/articles/dataset/Beyond_IVR_Touch-Tones_Customer_Intent_Routing_using_LLMs/30118690

Przykłady interakcji klienta, udostępnione w ramach nowego projektu. Źródło

Dane dla projektu zostały udostępnione publicznie.

Metoda

Pierwszy model w trójstopniowym podejściu tworzy szczegółowe menu telefonu dla fikcyjnej firmy telekomunikacyjnej; drugi generuje unikalne wiadomości od klientów – niektóre proste, inne przeprojektowane lub zrobione bardziej swobodnie – aby symulować, jak ludzie naprawdę mówią, gdy dzwonią po pomoc. W odniesieniu do tego, wygenerowano 920 przykładów dla projektu.

Trzeci model otrzymał zadanie połączenia każdego dzwoniącego z odpowiednim działem, opierając się wyłącznie na wiadomości i wersji menu. Ten schemat pozwolił na przeprowadzenie eksperymentu w sposób w pełni powtarzalny, omijając jednocześnie potrzebę danych z prawdziwych połączeń lub narażania informacji klienta:

Trzy systemy wybrane do trójstopniowego podejścia. [Źródło] https://arxiv.org/pdf/2510.21715

Trzy systemy wybrane do trójstopniowego podejścia. Źródło

Trzy użyte modele to odpowiednio gpt-3.5-turbo; gpt-4o-mini; i gpt-4.1-mini.

Aby symulować przekonywujące środowisko obsługi klienta, konieczne było wygenerowanie złożonego menu telefonu od podstaw. Ze względu na brak odpowiednich zbiorów danych, model gpt-3.5-turbo został zaproszony do wygenerowania pełnej, wielogaleziowej struktury dla fikcyjnego dostawcy usług telekomunikacyjnych.

Każda gałąź została skonfigurowana do reprezentowania obszarów usług, takich jak rozliczenia, wsparcie techniczne zarządzanie kontem i nowe usługi, z realistycznymi podopcjami i różną głębokością w drzewie. Z tego sztucznego menu utworzono dwie wersje do późniejszych testów: jedną jako zwykłą hierarchię tekstu, aby naśladować, jak człowiek mógłby przeczytać całe menu; i drugą jako listę punktów końcowych, z których każdy miał własną sekwencję naciśnięć przycisków.

To pozwoliło na przetestowanie systemu zarówno w wersji szczegółowej, jak i “rozpakowanej” wersji wyzwania routingu:

Dwie wersje menu telefonu zostały udostępnione AI: szczegółowa hierarchia tekstu i uproszczona lista bezpośrednich opcji menu, aby porównać, jak dobrze każdy format wspierał routing dzwoniących do odpowiedniego miejsca.

Dwie wersje menu telefonu zostały udostępnione AI: szczegółowa hierarchia tekstu i uproszczona lista bezpośrednich opcji menu, aby porównać, jak dobrze każdy format wspierał routing dzwoniących do odpowiedniego miejsca.

Aby utworzyć wiadomości od klientów potrzebne do testowania, wykorzystano drugi model językowy, aby wyprodukować zestaw oryginalnych skarg lub wniosków, z dziesięcioma unikalnymi przykładami utworzonymi dla każdego punktu końcowego menu.

Każdy z nich został następnie rozwinięty w kilka przepisanych wersji, aby naśladować zakres sposobów, w jakie prawdziwi klienci mogliby sformułować swoje problemy, i wprowadzono zmiany w długości, tonie i nawet niewielkie błędy lub ‘słowa wypełniające’.

920 wiadomości od klientów wygenerowanych na początku zostało zaprojektowanych zarówno do testowania precyzji systemu, jak i do symulowania nieprzewidywalności prawdziwej mowy.

Trzeci etap przetestował, jak dokładnie ostatni model mógł mapować każdą wiadomość od klienta na odpowiednie miejsce w menu, opierając się na dwóch różnych sposobach prezentacji systemu IVR (patrz powyżej).

W pierwszej wersji AI otrzymał pełny, opisowy zarys drzewa telefonu, z każdą gałęzią i podopcją wyłożoną w postaci tekstu. W drugiej wersji zobaczył tylko listę punktów końcowych, z których każdy był związany z sekwencją naciśnięć przycisków.

Celem było sprawdzenie, czy wersja “spłaszczona” menu ułatwi modelowi podjęcie decyzji, dokąd powinno być skierowane każde połączenie. W obu przypadkach system otrzymał jedną wiadomość na raz i został poproszony o zwrócenie tylko ścieżki, bez dodatkowych słów lub wyjaśnień, aby ułatwić automatyczne punktowanie.

Izolacja

Aby uniknąć skażenia wyników testowych, eksperyment utrzymywał każdy model w izolacji od innych: menu telefonu zostało opracowane przez pierwszy model, ale następnie sfinalizowane ręcznie, tak aby pozostało nieznane dla innych systemów.

Wiadomości od klientów zostały wygenerowane oddzielnie przez gpt-4o-mini, wykorzystując tylko nazwy punktów końcowych, i nie miały dostępu do struktury menu. W końcu, gpt-4.1-mini, który zajmował się routowaniem, zobaczył tylko tekst menu i nadchodzące wiadomości, i nie miał udziału w tworzeniu żadnego z nich.

Metryki

Aby zmierzyć, jak dobrze system routingu działał, wykorzystano dwie standardowe metryki: dokładność została zdefiniowana jako procent przypadków, w których model zwrócił dokładną poprawną ścieżkę (tj. 1‑2‑3). Aby izolować lokalizację błędów, wygenerowano również macierze konfuzji*, pokazujące, jak często każda ścieżka była mylona z innymi. Oceny zostały wykonane w Pythonie przy użyciu bibliotek pandas i scikit-learn.

Wyniki

W testach dokładność modelu zależała silnie od tego, jak menu telefonu zostało przedstawione: gdy podano mu “spłaszczoną” listę ścieżek menu, system osiągnął 89,13% dokładności w przypadku prostszego zestawu danych, w porównaniu z 81,30%, gdy wykorzystano pełną opisową wersję menu:

Dokładność routingu dla trzeciego (LLM3) modelu, w różnych formatach i typach danych, wskazująca, że ścieżki menu “spłaszczane” konsekwentnie przewyższały opisy hierarchiczne, i że dokładność nieco spadła, gdy dane wejściowe zostały uzupełnione o przepisane lub nieformalne języki.

Ten wzorzec utrzymywał się również dla większego, lingwistycznie zróżnicowanego zestawu danych, gdzie wersja “spłaszczona” ponownie działała lepiej, osiągając 86,52% w porównaniu z 77,07% dla formatu opisowego.

Te wyniki, jak zauważa artykuł, sugerują, że proste, listowe podpowiedzi pomogły modelowi dopasować zapytania w sposób bardziej niezawodny niż długie opisy hierarchiczne.

Dokładność również nieco spadła, gdy wprowadzono przepisane i nieformalne wersje wiadomości od klientów, wskazując, że większa różnorodność poprawiła realizm, ale również utrudniła klasyfikację.

Artykuł kończy się następująco:

‘Nasze wyniki pokazują, że LLM routują intencje bardziej dokładnie, gdy otrzymują “spłaszczane” ścieżki IVR (do 89,13%), niż gdy otrzymują opisy hierarchiczne (jak niskie jak 77,07%), sugerując, że zwięzłe, ustrukturyzowane podpowiedzi redukują szum i lepiej odpowiadają na zadanie routingu.

‘To potwierdza zasadę, że klarowność i zwięzłość poprawiają wydajność LLM w ustawieniach klasyfikacji.

‘Co ważne, przekształcanie menu w “spłaszczane” ścieżki jest prostym, zautomatyzowanym procesem dla użytku w świecie rzeczywistym.’

Podsumowanie

Jest odświeżające zobaczyć, że choć trochę otwartej pracy w jednym z najbardziej wykluczonych i wyłączonych obszarów badań. Co pozostaje do zobaczenia, to czy “ramy” architektury, które kontekstualizują LLM, będą potrzebne w przyszłości, czy model będzie potrzebował tylko dostępu do (lokalnie dostępnej) inteligencji biznesowej, eliminując potrzebę udostępniania danych przez firmę dostawcom zewnętrznym.

Ostatecznie, szersze zasady projektowe stosowane tutaj wydają się prawdopodobnie być przyjęte naturalnie przez przyszłe systemy AI, nawet w dziedzinach poza obsługą klienta, bez potrzeby świadomego dostosowania do tego przypadku.

 

* Proszę odnosić się do oryginalnego artykułu w celu uzyskania tych informacji.

Pierwotnie opublikowane w środę, 29 października 2025

Pisarz zajmujący się uczeniem maszynowym, specjalista w dziedzinie syntezy ludzkich obrazów. Były szef ds. treści badawczych w Metaphysic.ai, aż do jej rozwiązania w Brahma.ai firmy DNEG.
Strona internetowa: martinanderson.ai
Kontakt: martin@martinanderson.ai