Клуб 4CIO Чат-боты

Рынок чат-ботов на сегодняшний день один из самых быстрорастущих – по данным Credence Research, на вторую половину 2023 года мировой спрос на чат-ботов оценивался в 4.9 миллиарда долларов, а в период с 2024 по 2032 год ожидается его рост до 37.4 миллиарда долларов. Немецкая компания Statista, специализирующаяся на изучении рынков и больших данных, прогнозирует к 2028 году увеличение общего количества устройств с виртуальными помощниками до 27 миллиардов.

Чат-боты уже применяются почти во всех сферах бизнеса, таких как транспорт, металлургия и IT. Однако лидирующие позиции занимают телеком, финансовые институты, ритейл и нефтегазовая отрасль, в которых больше половины компаний используют чат-ботов, и наиболее широко – в области продаж и поддержке. В 2023 году компания Naumen провела исследование по использованию голосовых и текстовых чат-ботов в клиентском сервисе ритейла. Было замечено, что количество организаций, использующих чат-боты и интегрировавших их с внутренними информационными системами, увеличилось до 48%. Это позволило клиентам управлять заказами, проверять количество баллов и статус карты, получать персонализированные данные прямо в диалоге и т.д.

Сфера чат-ботов имеет дело с естественным языком, из-за чего роль зарубежных ИТ-гигантов не столь высока, как в других технологических отраслях. Из-за различий в языках в работе с каждым из них нужен индивидуальный и точный подход. Кроме того, каждая страна имеет свои популярные сервисы и нишевые отрасли. Всё это открывает возможности для развития небольшим стартапам, которые могут конкурировать с IBM, Google и Amazon, превосходя их с точки зрения глубины проработки языковых и культурных особенностей. Также стартапы по природе своей более гибкие и позволяют найти решение под каждую сферу.

Мир чат-ботов переживает революцию, и в ее центре – генеративный искусственный интеллект (GenAI) и большие языковые модели (LLM), такие как GPT-4, PaLM 2, Llama 2 и другие. Аналитики McKinsey отметили, что на 2024 год уже 65% компаний используют GenAI хотя бы для одной бизнес-функции.

Согласно мнению экспертов The Boston Consulting Group, генеративный искусственный интеллект способен превратить общение с чат-ботами в нечто более полезное для потребителя, позволить бизнесу сэкономить ресурсы и увеличить количество собираемых для анализа данных.

Подходы и технологии, используемые при создании бота, зависят от типа и назначения системы. Традиционная классификация диалоговых систем опирается на 2 критерия:

• 

Ориентированность на задачу (goal-oriented) VS общее назначение.

• 

Закрытая VS открытая предметная область (домен).

Goal-oriented боты разрабатываются для решения конкретных задач ― выдачи информации по запросу, выполнения операций (проверка баланса, подключение тарифа и т.п.).

Диалоговые системы общего назначения (так называемые боты-«болталки») направлены исключительно на поддержание диалога и развлечение пользователя.

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

Системы с открытым доменом предполагают универсальные возможности использования ― к ним относятся ассистенты типа Алексы от Amazon или Алисы от Яндекса. Большинство таких систем выполняют роль интерфейса к специализированным сервисам (например, фраза «Алиса, давай закажем билет в кино» вызывает специализированный сервис по бронированию билетов в сети кинотеатров). Открытый домен здесь – инструмент продвижения интерфейса на рынке пользователей.

Сложность разработки чат-бота возрастает по мере расширения его предметной области и генерализации назначения (или увеличения количества задач, которые он способен выполнять). На Рис. 1 приведен пример классификации некоторых чат-ботов по этим критериям.

Рис. 1. Пример классификации чат-ботов.

Для большинства бизнес-задач достаточно goal-oriented бота с ограниченной областью знаний; стремление охватить все предметные сферы и создать универсального собеседника (AI) в теории может привести к созданию «настоящего» искусственного интеллекта.

Рассмотрим архитектуру классического бота (Рис. 2).

Рис. 2. Архитектура классического бота.

Модуль понимания естественного языка (Natural Language Understanding, сокращенно NLU, NLP Engine) – один из ключевых модулей любой диалоговой системы. Он обеспечивает структуризацию и «понимание» (интерпретацию) сообщений пользователя. Существует несколько способов коммуникации с ботом: предопределенные диалоговые кнопки (например, «Да» и «Нет»), ключевые слова (/start, /bye и т.д.) и общение в свободной форме с использованием произвольного текста на естественном языке. В общем случае свободу общения можно представить в виде Рис. 3.

Рис. 3. Свобода общения.

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

Классификация сообщений (Intent Classification). Она может производиться с применением как нейронных сетей (наиболее популярны архитектуры на основе рекуррентных ячеек GRU/LSTM), так и классических алгоритмов машинного обучения (наивный байесовский классификатор, логистическая регрессия), которые успешно применяются в случае небольшого количества обучающих данных. Любому сообщению пользователя должен соответствовать определенный класс (интент). Например, сообщения «привет», «хай», «добрый день» могут быть классифицированы в один класс intent_hello, а сообщения «до свидания», «пока», «удачи» – в класс intent_bye. Сообщения, класс которых с достаточной вероятностью определить не удалось, относятся к классу no_match. В общем и целом, все интенты разделяют на General intents (например, интенты приветствия и прощания) и Domain intents (например, интенты заказа конкретной пиццы или бронирования гостиницы на определенный день).

Выделение именованных сущностей (Named Entity Extraction, Named Entity Recognition, Slot Filling). Сущности представляют собой единый лексический элемент определенного типа (географическое название, имя, дата и т.п.). Так, в сообщении «Покажи расписание рейсов из Москвы в Париж 12 августа» именованными сущностями являются «Москва», «Париж» и «12 августа». Выделение сущностей может быть реализовано как на основе регулярных выражений (шаблонов, паттернов) и справочников, так и посредством NER Network – специально обученной нейронной сети с архитектурой many-to-many.

Модуль управления диалогом (Dialog Management Module, сокращенно DM) – ядро чат-бота, которое управляет текущим контекстом и реализует требуемый функционал. Контекст представляет собой «память» бота обо всех (или последних) действиях и сообщениях. Не все диалоговые модули поддерживают контекст, и не всегда в нем есть необходимость. Например, в простых вопросно-ответных системах нет необходимости поддерживать контекст. В случае примитивных диалогов используют следующие типы DM: switch statement (т.е. полное отсутствие контекста, аналогично поисковым системам) или FSM (finite-state machine) – конечный автомат, представляющий собой однонаправленный диалог без сохранения полученных от клиента данных для других диалогов в рамках той же сессии. В случае goal-oriented чат-бота использование контекста обязательно, и тогда DM включает в себя:

Dialog State Tracking (DST) – компонент, отслеживающий текущее состояние (state) диалоговой машины и допустимые переходы между стейтами. Сохраняет и отслеживает все сообщения клиента и ответные действия системы, чтобы помочь компоненту Policy Learning оптимально выбрать следующий шаг.

Policy Learning (Dialog Policy, PL, DP) – компонент, определяющий дальнейшие действия бота на основе текущего состояния и контекста. Вариантами последующих действий могут быть: формирование ответного сообщения, обращение во внешнюю информационную систему за дополнительной информацией, условный переход в другой стейт (context switching) и тому подобное. Policy Learning может быть реализован на основе правил (rule based), на основе предобученной классической нейронной сети (supervised learning), которая сама определяет, что лучше делать дальше, либо с использованием подхода обучения с подкреплением (reinforcement learning). Первый вариант получил наибольшее распространение из-за простоты реализации и отсутствия необходимости обучения на большом объеме дата-сетов.

Модуль генерации ответов (Response Generator Module, Natural Language Generator, NLG) – формирование ответа клиенту в соответствии с данными, полученными из диалогового модуля и из внешних информационных систем. В общем случае выделяют следующие архитектуры RGM:

Извлечение данных (Retrieval Based Modelling) – в простейшем случае ответом является статичный текст. Для «оживления» сценария бот может случайным образом выбирать вариант из предописанного набора статичных текстов (например, для прощания с пользователем всякий раз использовать случайный вариант из доступного списка: «пока», «приятно было пообщаться», «до свидания» и т.д.). Ответ может быть динамическим, т.е. включать в себя результаты, полученные из внешних систем: к примеру, значение баланса счета или время вылета самолета. Варианты генерации ответа статичным или динамическим текстом являются самыми распространенными из-за простоты реализации, отсутствия необходимости обучения и предсказуемости результата.

Рис. 4. Архитектура RGM: извлечение данных.

Порождение (Generative Modelling) – формирование ответа на основе работы нейронной сети (как правило, архитектура кодировщика-декодера). В таком случае содержание ответа полностью формируется предобученной нейронной сетью. Подход нашел свое отражение в вопросно-ответных системах, но в классических чат-ботах он применяется крайне редко из-за сложности обучения и риска неожиданных ответов (пример ― известная ситуация с ботом Microsoft, который в результате бесконтрольного самообучения стал генерировать расистские высказывания).

Рис. 5. Архитектура RGM: порождение.

Извлечение с улучшением (Retrieve and Refine) ― гибридный метод. Известно, что генеративные модели склонны давать общие, более «безопасные» ответы («да», «нет», «не знаю»), в то время как Retrieval Based модели ограничены набором предзаписанных ответов, которые могут не полностью соответствовать контексту текущего диалога. Модель Retrieve and Refine комбинирует два описанных выше подхода. В гибридной модели Retrieve and Refine ответы, обнаруженные моделью Retrieval Based, подаются на вход генеративной модели в качестве дополнительного контекста. Генеративная модель формирует окончательный ответ бота.

Рис. 6. Архитектура RGM: извлечение с улучшением.

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

Рис. 7. Пример архитектуры текстового бота.

Как правило, используют следующие дополнительные интерфейсные модули:

• 

для голосовых ботов – системы синтеза (Text to Speech, TTS) и распознавания (Automatic Speech Recognition, ASR) речи. Их качество достигло такого уровня, что при общении отличить живого человека от синтезированного голоса не всегда просто (впрочем, во многих решениях используются предзаписанные реплики, сознательно имитирующие человеческую речь – с придыханием, паузами, фоновым шумом). Существует довольно много разработчиков этих решений в России (ЦРТ, Яндекс, АСМ-Решения) и в мире (IBM, Google, Microsoft, Nuance). Чтобы стандартизировать методы интеграции подобных систем, разработаны интерфейсы протокола управления медиаресурсами (MRCP) и удаленного вызова процедур (gRPC).

• 

для неголосовых систем широко применяются уже зарекомендовавшие себя протоколы HTTP REST/WebSocket. Они гораздо проще в реализации, т.к. не требуют распознавания голоса в режиме онлайн. Разработчики вправе как использовать общепринятые интерфейсы, так и создавать свои собственные – в случае, если новая разработка по каким-либо критериям лучше существующих.

Различия MRCPv1 и MRCPv2

Протокол MRCPv1 (RFC 4463) был разработан совместными усилиями компаний Cisco, Nuance и Speechworks в 2006 г. Последовавший за ним MRCPv2 (RFC 6787) стал развитием первой версии. Табл. 3.3.1 демонстрирует ключевые отличия двух протоколов.

RTSP и SIP/SDP являются клиент-серверными текстовыми протоколами (аналогичны HTTP) и достаточно схожи между собой по формату и параметрам сообщений. Также в обоих случаях транспорт голосового потока реализуется протоколом RTP (Real-time Transport Protocol).

Многие разработчики реализуют собственный стек MRCP, но в то же время существует кроссплатформенная реализация стека UniMRCP с открытым кодом, распространяемая по лицензии Apache License 2.0, которая нашла широкое применение у поставщиков решений синтеза и распознавания речи.

Табл. 1. Сравнительная характеристика протоколов MRCPv1/MRCPv2.

Ранее была рассмотрена классическая архитектура goal-oriented бота и его ключевые компоненты. Как уже было отмечено, каждый из них может быть реализован как с применением нейронной сети, так и без нее. Классическая архитектура допускает также частичное использование нейронных сетей: например, компонент NLU может быть реализован нейросетью, а модули управления диалогом и генерации ответов ― на основе правил (rule-based). Таким образом, можно отметить гибкость и адаптируемость архитектуры классического бота, в которой каждый компонент может оптимизироваться и дорабатываться отдельно от других.

Развитие нейронных сетей и глубокого обучения привело к появлению новых подходов к реализации ботов:

• 

Сквозное обучение

(end-to-end learning) ― в этом подходе сохраняется классическая архитектура бота, но все ее компоненты представлены нейронными сетями. Обучение производится сквозным методом, т.е. на каждом экземпляре обучающего диалога все компоненты обучаются как единое целое, а не по отдельности.

• 

Диалоговые модели, полностью управляемые данными

(Fully data driven Conversation Models) ― в этом подходе уже не применяется классическая архитектура. Весь бот представляет собой одну глубокую нейронную сеть, классическим примером которой является ChatGPT

Существенное развитие получили боты в связи с применением больших языковых моделей (Large Language Model, LLM). Как было отмечено ранее, есть класс чат-ботов общего домена знаний, которые могут поговорить с пользователем на любую тематику общего характера. Этот вариант чат-ботов интересен с точки зрения привлечения новых пользователей и демонстрацией красивой игрушки. И это прекрасно работает на волне текущего хайпа вокруг LLM.

Если же говорить о конкретной задаче, которую требуется возложить на чат-бота, то как правило, любой диалог строится по какой-то согласованной схеме, когда клиента нужно последовательно провести через некоторый этап (путь) для сбора необходимых параметров и последующего предоставления сервиса (ответа). Компании, во-первых, строго согласовывают данный путь и используемые ботом фразы на каждом этапе и, с другой стороны, стремятся максимально эффективно решить возникшую у пользователя задачу. Т.е. становится очевидным, что должно использоваться rule-based ядро чат-бота, которое точно отслеживает текущее состояние (статус) пользователя и однозначно определяет, что делать дальше. Использование только LLM (пусть даже совместно с RAG) не позволяет реализовать данный, строго детерминированный функционал. Отсюда становится очевидным, что построение современного чат-бота для решения проблем и запросов заказчиков возможно только с применением синтеза традиционного механизма построения чат-ботов (которое было рассмотрено ранее) и точечного применения LLM.