Штучний інтелект може допомогти вам швидше зв’язатися з реальною людиною

Нові дослідження показують, що відкриті системи штучного інтелекту типу ChatGPT можуть потенційно перенаправляти дзвінки до правильної людини в центрі зв’язку за допомогою природної мови, без необхідності проходження через розлючуючі меню вибору, які змінюються кожен тиждень, що здається навмисно перешкоджають.

Спроба зв’язатися з реальною людиною в центрі зв’язку може бути розчаровуючим досвідом через необхідність проходження через множинні варіанти вибору в повільному темпі – часто без впевненості щодо того, який із варіантів підходить вашому випадку. Якщо жоден з них не підходить, досвідчені користувачі схильні використовувати хитрощі та обхідні шляхи, щоб отримати доступ до людини-радника якогось роду, і вийти з «пекла варіантів». Багато з нас впізнають це як більш-менш «войовничий» і ворожий до користувача досвід.

Не дивно, що центри зв’язку знаходяться на передовій лінії для доповнення або заміни системами штучного інтелекту; і, незважаючи на обережний підхід, який рекомендується з деяких кварталів, автоматизація центрів зв’язку штучним інтелектом залишається легкою здобиччю для заголовків про технології, і для перспективи інновацій на основі штучного інтелекту, які можуть запропонувати незвично ранню окупаемість інвестицій.

Закрита крамниця

Але є деякі області, де відкриті принципи та вільно доступні дані рідко застосовуються або доступні, і це одна з них. Це має сенс: будь-яка компанія, зацікавлена в автоматизації своїх систем відповіді на звернення клієнтів, матиме обмежений або нульовий інтерес до обміну даними, які підтримують їх важко здобуті знання, методи або корпоративну інтелектуальну власність.

По-перше, обмін цими ресурсами коштуватиме їм конкурентної переваги; що ще важливіше, враховуючи, наскільки системи штучного інтелекту схильні розкривати конфіденційну інформацію, це юридично ризиковано.

Це призвело до того, що кілька добре інвестованих гравців створили незалежно системи відповіді центрів зв’язку, підтримувані штучним інтелектом (очевидно, з деякою неминучою надмірністю зусиль); і до розгалуження Б2Б стартапів і встановлених гравців, які намагаються задовольнити зростаючий попит на можливості відповіді клієнтів, підтримувані штучним інтелектом.

Помічник голосу PolyAI відкриває дзвінок клієнта для вигаданої компанії «Augusta Lawn Care», використовуючи велику кількість навчальних розмов, щоб автоматизувати відповіді через існуючу інфраструктуру центру зв’язку. Джерело

Крім того, гонка за видалення розчарування від навігації лабіринту центру зв’язку стала спонукою до досліджень – хоча більшість таких публікацій tend до того, щоб відбуватися поза мережами відкритих дослідницьких публікацій Arxiv та інших, у відповідності з загалом закритою природою розробки Interactive Voice Response (IVR).

Натомість дослідження, дані та бізнес-інтелект, пов’язані з автоматизацією систем відповіді клієнтів штучним інтелектом, всією мірою охороняються, з дуже少кими відкритими варіантами – навіть якщо використання систем з відкритим кодом та даних пропонувало юридично зважений варіант, що сумнівно.

Місний дзвінок

З урахуванням цього, освіжаюче бачити нову роботу з Колумбії, яка намагається вивести IVR з корпоративної камери, хоча б трохи. Нова робота, лаконічний вступ під назвою Peyond IVR Touch-Tones: Customer Intent Routing using LLMs, походять від дослідника з Universidad Distrital Francisco José de Caldas у Боготі, і стверджують, що це перший некорпоративний проект, який використовує великі мови моделі (LLM), щоб створити робочу схему для системи маршрутизації намірів клієнтів (CIR).

Натомість спроби отримати доступ до реальних даних дзвінків або пропрієтарних дерев меню, новий проект генерує всі компоненти з нуля за допомогою трьох моделей штучного інтелекту: одну для винаходу реалістичного меню центру зв’язку; іншу для симуляції сотень скарг клієнтів; і третю для виконання ролі чат-бота, який намагається перенаправити ці скарги до правильного місця призначення.

Результатом є повністю синтетична, але переконлива тестова лабораторія, що включає вигадану телекомунікаційну компанію, а також 920 різних запитів користувачів, що дозволяє експерименту уникнути юридичних ризиків, одночасно досліджуючи, наскільки добре поточний штучний інтелект може інтерпретувати невиразну, заплутану мову, і все ж таки зв’язати дзвінка з правильною людиною.

Тести показують, що схема системи може зіставити вільно сформовані скарги клієнтів з правильним місцем призначення центру зв’язку з точністю до 89,13%, особливо коли надані «сплющені» варіанти меню замість розгорнутих описів (більше про це пізніше).

Дослідження також показало, що коли клієнти використовували більш неформальну або різноманітну мову, штучний інтелект помилявся частіше; але деякі з цих помилок траплялися не через те, що штучний інтелект неправильно зрозумів, а через те, що саме телефонне меню було плутаним.

Приклади взаємодій клієнтів, поданих у рамках нового проекту. Джерело

Дані для проекту були відкрито доступні для загалу.

Метод

Перша модель у тричастинному підході створює детальне телефонне меню для вигаданої телекомунікаційної компанії; друга генерує унікальні повідомлення клієнтів – деякі прості, інші перефразовані або зроблені більш неформальними – щоб симулювати, як люди насправді говорять, коли дзвонять за допомогою. Відносно цього, для проекту було сгенеровано 920 прикладів.

Третя модель була задіяна для підключення кожного клієнта до правильного відділу, виходячи лише з повідомлення та версії меню. Ця схема дозволила експерименту бути повністю повторюваним, одночасно обходячи потребу у реальних даних дзвінків або розкритті інформації клієнтів:

Три системи, вибрані для тричастинного підходу. Джерело

Три моделі, які були використані, відповідно, були gpt-3.5-turbo; gpt-4o-mini; і gpt-4.1-mini.

Для симуляції переконливого середовища обслуговування клієнтів було необхідно синтезувати складне телефонне меню з нуля. Через нестачу відповідних наборів даних модель gpt-3.5-turbo була спровокована для генерації повної, багаторазової структури для вигаданого телекомунікаційного постачальника.

Кожна гілка була сконфігурована для представлення сервісних областей, таких як оплата, технічна підтримка, управління обліковим записом, і нові послуги, з реалістичними субопціями та різною глибиною по всьому дереву. З цього штучного меню було створено дві версії для пізнішого тестування: одну як плоску текстову ієрархію, щоб симулювати, як людина могла б прочитати все меню; і іншу як список кінцевих точок, кожна з яких мала свою власну послідовність натискань кнопок.

Це дозволило системі бути протестованою як на детальному, так і на «розібраному» варіанті маршрутизаційної задачі:

Дві версії телефонного меню були надані штучному інтелекту: детальна текстова ієрархія, і спрощений список прямих меню опцій, щоб порівняти, наскільки добре кожен формат підтримував маршрутизацію клієнтів до правильного місця.

Для створення повідомлень клієнтів, необхідних для тестування, була використана друга мова модель для генерації набору оригінальних скарг або запитів, з десятьма унікальними прикладами, створеними для кожного кінцевого пункту меню.

Кожен з них потім був розширений до декількох перефразованих версій, щоб симулювати різноманітність способів, якими реальні клієнти могли б сформулювати свої проблеми, і ввели зміни у довжині, тоні та навіть дрібні помилки чи ‘заповнювальні’ слова.

920 повідомлень клієнтів, сгенерованих на початку, були розроблені для тестування точності системи та для симуляції непередбачуваності реальної мови.

Третій етап протестував, наскільки точно остання модель могла зіставити кожне повідомлення клієнта з правильним пунктом меню, виходячи з двох різних способів подання системи IVR (див. вище зображення).

У першій версії штучний інтелект отримував повний, описовий план телефонного дерева, з кожною гілкою та субопцією, викладеною у текстовій формі. У другій він бачив лише список кінцевих пунктів, кожний з яких був пов’язаний з послідовністю натискань кнопок.

Мета полягала в тому, щоб побачити, чи спрощена версія меню зробить його легшим для моделі вирішити, куди повинен бути перенаправлений кожен дзвінок. У обох випадках система отримувала одне повідомлення за раз і запитувалася повернути тільки шлях, без додаткових слів чи пояснень, щоб полегшити автоматичне оцінювання.

Ізоляція

Для уникнення забруднення результатів тестів експеримент тримав кожну модель ізольованою від інших: телефонне меню було створено першою моделлю, але потім остаточно затверджено вручну, так що воно залишилося незнайомим для інших систем.

Повідомлення клієнтів потім були сгенеровані окремо gpt-4o-mini, використовуючи лише назви кінцевих пунктів, і без доступу до структури меню. Нарешті, gpt-4.1-mini, який займався маршрутизацією, бачив лише текст меню та надходять повідомлення, і не брав участі у створенні жодного з них.

Метрики

Для вимірювання того, наскільки добре система маршрутизації працювала, були використані два стандартні метрики: точність була визначена як відсоток випадків, коли модель повернула точно правильний шлях (наприклад, 1‑2‑3). Для ізоляції місць помилок були сгенеровані матриці плутанини*, що показують, наскільки часто кожний шлях плутався з іншими. Оцінки були виконані на Python за допомогою бібліотек pandas і scikit-learn.

Результати

У тестах точність моделі сильно залежала від того, як було представлено телефонне меню: коли надавався сплющений список шляхів меню, система досягла 89,13% точності на простішому наборі даних, порівняно з 81,30%, коли використовувалася повна описова версія меню:

Точність маршрутизації для третьої (LLM3) моделі, по різних форматах підказок і типам наборів даних, вказуючи на те, що сплющені меню-шляхи послідовно перевершували ієрархічні описи, і що точність трохи знижувалася, коли входи були доповнені перефразованими чи неформальними мовами.

Цей шаблон зберігся для більшого, лінгвістично різноманітного набору даних, де сплющена версія знову показала кращу продуктивність, набравши 86,52% проти 77,07% для описової версії.

Ці результати, як зазначається в статті, свідчать про те, що простіші, спискові підказки допомогли моделі зіставити запити більш надійно, ніж довгі ієрархічні описи.

Точність також трохи знижувалася, коли вводилися перефразовані та неформальні версії повідомлень клієнтів, вказуючи на те, що більша різноманітність покращила реалізм, але також зробила класифікацію складнішою.

Стаття закінчується:

Наші результати показують, що LLM маршрутизують наміри більш точно, коли їм надаються сплющені шляхи IVR (до 89,13%), ніж розгорнуті меню-описи (до 77,07%), вказуючи на те, що лаконічні, структуровані підказки зменшують шум і краще відповідають завданням маршрутизації.

Це підтверджує принцип, що ясність і лаконічність підвищують продуктивність LLM у класифікаційних умовах.

Важливо, що перетворення меню на сплющені шляхи є простим, автоматизованим процесом для реального використання.’

Висновок

Це освіжаюче бачити хоча б деяку відкриту роботу, яка відбувається в одному з найбільш ізольованих і виключних напрямків досліджень у літературі. Що залишається побачити, чи будуть потрібні «фреймові» архітектури, які контекстуалізують LLM, у майбутньому, чи чи буде моделі достатньо мати доступ до (локально доступної) бізнес-інтелекту, що зробить зайве поділ даних компанією з третіми сторонами.

У кінцевому підсумку, більш широкі принципи дизайну, які працюють тут, схоже, будуть прийняті природно майбутніми системами штучного інтелекту, навіть у галузях за межами обслуговування клієнтів, без потреби у свідомому вирівнюванні з цим випадком.

* Будь ласка, зверніться до джерельної статті для цих даних.

Перша публікація – середа, 29 жовтня 2025 року