ИИ может помочь вам связаться с реальным человеком быстрее

Новые исследования показывают, что открытые системы ИИ в стиле ChatGPT могут потенциально направлять звонящих в правильного человека в колл-центре с помощью естественного языка, без необходимости следовать раздражающим меню-выборам, которые меняются каждую неделю и кажутся намеренно препятствующими.

Попытка связаться с реальным человеком в колл-центре может быть разочаровывающим опытом из-за необходимости проходить через множество вариантов выбора с медленной скоростью – часто без уверенности в том, какой из них подходит для вашего случая. Если ни один из них не подходит, опытные пользователи часто используют хитрости и обходные пути, чтобы получить доступ к человеческому консультанту и выйти из ‘ада вариантов’. Многие из нас признают это как более или менее ‘боевой’ и враждебный для пользователя опыт.

Неудивительно, что колл-центры находятся на передовой линии для дополнения или замены системами ИИ; и, несмотря на осторожный подход, рекомендуемый некоторыми кварталами, автоматизация колл-центра ИИ остается низко висящим фруктом для технологических заголовков, и для перспективы инноваций на основе ИИ, которые могут предложить необычно раннюю окупаемость инвестиций.

Закрытый магазин

Но есть некоторые области, где принципы открытого источника и свободно доступных данных редко применяются или доступны, и это одна из них. Это имеет смысл: любая компания, заинтересованная в автоматизации своих систем ответов клиентов, будет иметь ограниченный или нулевой интерес в обмене данными, которыеfeed их трудно завоеванные идеи, методологии или корпоративную интеллектуальную собственность.

Во-первых, обмен этими ресурсами будет стоить им преимущества перед конкурентами; более важно, учитывая, как склонны системы ИИ к раскрытию конфиденциальной информации, это юридически рискованно.

Это привело к тому, что несколько хорошо инвестированных игроков разработали системы ответов колл-центра с помощью ИИ, независимые от других (предположительно, с некоторым неизбежным избытком усилий); и к распространению стартапов и установленных игроков B2B , стремящихся удовлетворить растущий спрос на возможности ответа клиентов на основе ИИ.

Помощник голоса PolyAI открывает звонок обслуживания клиентов для вымышленной компании ‘Augusta Lawn Care’, опираясь на большие объемы обучающих разговоров для автоматизации ответов через существующую инфраструктуру колл-центра. Источник

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

Вместо этого исследования, данные и бизнес-интеллект, связанные с автоматизацией систем ответа клиентов ИИ, все ревностно охраняются, с очень немногими открытыми исходными вариантами – даже если использование систем и данных с открытым исходным кодом предлагало юридически обоснованный вариант, что сомнительно.

Местный вызов

С учетом этого приятно видеть новую работу из Колумбии, пытающуюся вытащить IVR из корпоративного хранилища, хотя бы немного. Новая работа, краткая запись под названием За пределами IVR Touch-Tones: Маршрутизация намерений клиентов с помощью LLM, исходит от исследователя 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 (см. изображение выше).

В первой версии ИИ был предоставлен полный, описательный план телефонного дерева, с каждой ветвью и суб-опцией, расположенной в текстовой форме. Во второй версии он увидел только список конечных точек, каждая из которых была связана с последовательностью нажатий кнопок.

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

Изоляция

Чтобы избежать загрязнения результатов тестирования, эксперимент giữ каждую модель изолированной от других: телефонное меню было создано первой моделью, но затем финализировано вручную, так что оно осталось незнакомым для других систем.

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

Метрики

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

Результаты

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

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

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

Эти результаты, отмечает статья, предполагают, что более простые, списковые подсказки помогли модели сопоставить запросы более надежно, чем длинные иерархические описания.

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

Статья заключает:

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

‘Это подтверждает принцип, что ясность и краткость улучшают производительность LLM в задачах классификации.

‘Важно, что преобразование меню в сплющенные пути является простым, автоматизируемым процессом для реального использования.’

Заключение

Приятно видеть, что хотя бы некоторая открытая работа происходит в одной из самых замкнутых и исключительных ветвей исследований в литературе. Что остается быть увиденным, так это то, будут ли необходимы ‘рамочные’ архитектуры, которые контекстуализируют LLM, или же модель будет нуждаться только в доступе к (локально-доступной) бизнес-интеллекту, обходя необходимость для компании делиться данными с третьими сторонами.

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

* Пожалуйста, обратитесь к исходной статье за этими.

Опубликовано впервые в среду, 29 октября 2025