Привет! Меня зовут Илья Волынкин, я технический директор МТС Exolve. Когда мы говорим про коммуникации, то обычно представляем себе двух человек, общающихся либо в чате, либо голосом. В современном мире такая схема встречается все реже: появляются разные боты, новые каналы связи, которые еще и действуют параллельно. Так возникают сложные системы для голосовых коммуникаций — омниканальные роботы. В статье я расскажу об их основных архитектурных паттернах, применении ИИ-моделей и возникновении новых и непривычных решений.
Про каких роботов вообще идет речь?
Под этим определением обычно понимают системы, которые общаются с человеком вместо оператора:
-
Автоответчик в КЦ/ВАТС или помощник на сайте. Клиент звонит на номер или пишет в чат, и система отвечает ему по мере своих автоматических сил синтезированным голосом или текстом.
-
Автоинформатор — замена СМС и пушам в приложениях. Как правило, это просто предзаписанная фраза, но есть и исключения.
-
Всеми любимые автоматические прозвонщики. Из-за них появилось целое семейство защитных сервисов, таких как «Защитник» от МТС.
В повседневной жизни с роботами мы сталкиваемся постоянно: их можно собрать буквально за несколько минут. Берем платформу с API, например МТС Exolve, прикручиваем к ней любой сервис синтеза и распознавания — и все. Если добавить небольшой сценарий, то у вас будет робот, умеющий понимать сказанное и отвечать.
Все хорошо, но есть и недостатки. В такой реализации мы получаем лишь жесткий сценарий, который ищет конкретный смысл по ряду признаков. У него нет какого-то разума или интеллекта, кроме синтеза и распознавания, он может идти лишь строго по скрипту. Это классика, но все постепенно меняется.
Что такое омниканальные коммуникации
Как я уже говорил, в современном мире коммуникации стали гораздо сложнее. Выглядит это так:
Если очень сильно упростить, то в коммуникации может вступать либо человек, либо бот. Они взаимодействуют через разные устройства: телефон, колонку, компьютер и так далее. Каналы тоже различаются. Это может быть звонок, СМС, чат в мессенджере, виджеты на сайте, API и так далее.
Во всех этих каналах и устройствах используются разные формы общения: голос, видео, текст или API. Кроме того, они еще могут друг в друга превращаться. Например, с помощью ML-моделей текст переводится в речь и наоборот.
Классический вариант выглядит так:
Два человека звонят друг другу по аудиоканалу. Все просто и понятно. Но давайте усложним схему. Пусть один из людей не говорит, а общается текстом:
Здесь на помощь приходят конверсионные модели, которые трансформируют аудио от первого человека в текст и отправляют его второму в мессенджере. Тот отвечает, и процесс повторяется в обратном направлении.
В таком сценарии нужны трансформационные модели, которые вносят определенную задержку, отнимают ресурсы, но добавляют комфорта при общении.
Требования к ML-моделям в омниканальных коммуникациях
В верхней части картинки выше можно увидеть, по каким критериям различаются требования к разным формам. Давайте их разберем подробнее:
-
Задержка. Для видео нужна минимальная, потому что картинка будет неестественной, если у нас меньше 60 Fps, а многие хотят и все 120 Fps. Для голоса приемлема задержка в генерации в 1–2 секунды, а для текста может быть достаточно длительный период ожидания — до десятков секунд.
-
Ресурсоемкость. Чем сложнее форма коммуникации, чем больше в ней компонентов, которым нужно больше оперативной памяти, места на дисках, мощности процессоров и видеокарт.
-
Точность. Да, с неограниченным временем можно получить любую точность работы модели, но в реальности все иначе. В зависимости от канала, требования к задержкам существенно меняются. В тексте легко отбросить эмоциональную составляющую и получить высокую точность передачи информации. Для видео и аудио возникают сложности. Современные модели плохо передают эмоции: оттенки голоса, жесты, мимику и т. п. Сейчас уже есть разработки, позволяющие создавать «эмоциональных роботов», но их немного.
-
Контекст. Важный фактор, который нужно поддерживать в рамках какого-то конкретного звонка, диалога. А вот в API контекста нет, вместо него — история в базе данных.
Под все критерии есть модели с разным уровнем востребованности и зрелости:
И тут возникает проблема. С помощью ML-моделей разработчики омниканальных роботов хотят трансформировать любую форму через любой канал. Причем это должно быть красиво, удобно, комфортно, без всяких задержек. Но, как всегда, в реальности все по-другому. На иллюстрации — один из типовых сценариев:
Здесь у нас и преобразование аудио в текст, и распознавание эмоций, и робот в «облаке», который «дергает» какую-нибудь API. Например, чтобы в календарь поставить событие. Здесь уже возникает проблема задержек.
Как видите, схема коммуникаций становится все сложнее, особенно если сравнить просто с обычным телефонным звонком между двумя абонентами.
Как вписать GPT-модель в омниканального робота. Без регистрации и СМС
Казалось бы, есть прекрасные технологии — большие языковые модели (LLM). Но в бизнес-коммуникациях они пока еще распространены слабо, так как не всегда отвечают правильно, а порой и «галлюционируют». LLM тренируются для поддержания диалога, а не для решения целевых задач, поэтому их эффективность заметно ниже, чем у специализированных моделей. И здесь нужно выстроить сложную систему, чтобы добиться приемлемых результатов.
У нас есть кейс, когда мы реализовали поддержку разных каналов на вход и на выход, решили проблему с задержками и ресурсами и использовали все возможности GPT:
Начнем сверху вниз:
-
Когда к нам приходит голос, мы извлекаем метаинформацию и анализируем акустику. Это нужно, чтобы при переводе речи в текст не потерялась эмоциональная составляющая.
-
Затем запускаем диаризацию: может быть много людей, и надо все правильно разбить на фразы.
-
Трансформируем аудио в текст. Если к нам сразу приходит текст, он попадает прямо сюда.
-
Проверяем звонок на спам ML-моделями и на уровне текста анализируем эмоции.
-
С помощью NLU преобразуем слова в смыслы, вытаскиваем цифры и адреса и загружаем в некоторый агрегатор признаков. Каждый из них может влиять на дальнейшее развитие диалога.
-
Следующий этап — передаем предыдущий контекст в общий обработчик. Мы не отправляем сразу результаты анализа в LLM. Сначала понимаем, что нас спрашивают, и формулируем ветку с корректным промптом. Более того, еще проверяем, из какого канала все это поступает.
-
В конце коммуникации классифицируются по контекстам для каждого отдельного собеседника. Контексты заполняются из внешних данных, а также по результатам коммуникаций. Причем это можно делать двумя путями: сохранять справочную информацию в базе данных либо формировать небольшую контекстуальную модель, дообучая ее новыми фразами из классифицированных в этот контекст диалогов.
Теперь давайте погрузимся в основной пайплайн:
У нас уже есть контекст, приходящий из разных каналов. Мы обновляем его сначала входящими событиями, затем полученной из них метаинформацией. События в итоге попадают в обработчик, где скрипт решает, какие целевые действия выполнять дальше.
Главная сложность в этой схеме — нужно очень быстро определить скриптовую модель перед переходом к LLM, от которой в любом случае будет задержка ответа.
Чтобы решить эту проблему, мы используем векторную СУБД QDRANT: она классно спроектирована и позволяет быстро определить ближайших соседей в пространстве смыслов. QDRANT в нашем случае дает примерно на два порядка лучшую производительность, чем PostgreSQL. На основе этой системы и функционирует наш робот.
Реалии XXI века: что делать, если боты решили пообщаться между собой
Роботов становится все больше и больше. Из-за этого может возникнуть ситуация, когда они общаются друг с другом. Например, робот-информатор попадает на робота-ассистента и начинает с ним взаимодействие через огромную схему с синтезом и распознаванием в обе стороны:
Ресурсов на это тратится много, а результата не будет никакого. В такой ситуации можно стандартизировать приветствие роботов, добавить базовый handshake, по которому запустится взаимодействие на уровне API.
Самое интересное, что решения, помогающие в этом, уже есть. Например, Open API, описывающий практически все API, которые так или иначе используются. Применяя этот стандарт, можно организовать общение роботов между собой, чтобы они «понимали», кто из них что хочет и может сделать:
В таком сценарии будут использоваться все те же самые каналы и функции, но только через открытые API. Если это организовать, то появятся новые возможности. Например, кто-то хочет купить автомобиль. Он «просит» робота прозвонить объявления и узнать по заданным критериям, кто что продает. На выходе получает подборку с подходящими ему вариантами. Работать такая схема будет на уровне API.
На этом примере мы видим, что современная коммуникация усложняется, появляются новые инструменты и сценарии общения.
Куда это может развиться дальше
Омниканальные роботы не только автоматизируют определенные функции, но и становятся первым шагом к такой интересной теме, как виртуальный сотрудник. Это не очень сложно, особенно в простых задачах, где требуется только получать информацию, обрабатывать ее по заданным сценариям, сохранять и передавать. Для них необходимо соединить все каналы в один, преобразовать в текст и понять текущий контекст. Этим как раз и занимается платформа Exolve, которую мы развиваем.
Когда все сводится к тексту, появляется возможность применять различные LLM, которые понимают запрос и запускают по нему действие. И здесь заключается вторая важная часть нашей работы в Exolve — превращение программных интерфейсов в навыки, активируемые с помощью голоса или комбинации каналов.
Компании могут создавать таких виртуальных сотрудников для несложных и рутинных задачах, а простые пользователи — делать своих персональных ассистентов: достаточно будет установить платформу на любой компьютер, выбрать необходимые действия и настроить их под себя.
На этом у меня все. Если у вас возникнут вопросы, пишите в комментариях.
Автор: iVolynkin
