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

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

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

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

Закрытая лавка

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

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

Это привело к тому, что несколько хорошо инвестированных игроков разработали системы ответов на запросы клиентов с помощью ИИ, независимо от других (предположительно с некоторым неизбежным избытком усилий); и к распространению 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 библиотек.

Результаты

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

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

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

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

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

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

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

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

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

Вывод

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

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

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

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