В информационном мире программы не работают изолированно. Они связываются друг с другом: чтобы получить ценную для себя информацию, положить данные во внешнее хранилище, расширить свои возможности. Банковское приложение на телефоне связывается с приложением «Контакты» для удобства переводов. «Контакты» связываются с мессенджерами и показывают, в каких из них зарегистрирован этот номер. Мессенджеры связываются с платформой W11 – и пользователь может общаться с агентом там, где ему удобно. Сам цифровой диалоговый ассистент – не исключение. Помимо общения с пользователем, он способен общаться и с другими программами на особом языке. Этот язык называется протоколом HTTP (HyperText Transfer Protocol).


Протокол весьма популярен: браузер, с которого вы выходите в Интернет, общается с сайтами как раз по HTTP. Браузер спрашивает у Википедии статью про пчёл – сайт отвечает этой статьёй (с картинками, ссылками на другие статьи, предложением принять участие в написании). Такие вопросы к другим программам называют HTTP-запросами, а ответы на них – HTTP-ответами. Задающих вопросы называют Клиентами, отвечающих – Серверами. Изначально HTTP предназначался только для отправки страниц как в примере про Википедию, но сегодня используется для передачи любых полезных данных между программами. Программы, которые позволяют общаться с собой другим, делают это по закреплённому ими API (Application Programming Interface) – набору способов общаться с ними.

HTTP-запросы состоят из следующей информации:

• Метод запроса: что клиент хочет сделать на сервере. Самые популярные методы – GET (получить информацию) и POST (передать информацию)
• URL: путь до сервера с указанием запроса. По сути, обычная ссылка: http://example.com/doSomething
• Заголовки запроса: особая информация о самом запросе. Какие данные передаются, какие хотим получить, кто мы (авторизация, куки). Заголовки имеют формат «Название: Значение»
• Параметры запроса для GET-запросов: уточнение о том, что именно хотим получить. Например, когда мы ищем в Яндексе слово «цда», это слово передаётся в параметре с названием text. Иногда параметры записываются прямо в ссылке после знака ‘?’: https://yandex.ru/search/?text=цда
• Тело запроса для POST-запросов: что именно хотим передать. Тело может быть разных видов – строка, кусочек файла, данные в особом формате – в зависимости от требований сервера. Для построения ЦДА чаще всего используется формат JSON (https://ru.wikipedia.org/wiki/JSON)

HTTP-ответы состоят из заголовков и тела и имеют код состояния: число, которое кратко объясняет, успешен ли был запрос. Популярные коды состояния:

• 200 – запрос успешен
• 301 – сервер перенаправил запрос в другое место
• 401 – нужно авторизоваться, прежде чем запрашивать
• 404 – запрашиваемые данные не найдены
• 500 – на сервере проблемы

Во время разговора с ассистентом пользователь может внезапно спросить о погоде. Так как о погоде ассистент не знает в точности ничего, то без общения с другими программами он может разве что отшутиться. Но если он обратится к API условной Яндекс.Погоды, узнает текущую погоду и передаст пользователю – это произведёт впечатление. Возможны и более серьёзные ситуации: банковский ассистент может сам узнать у API банка, какие счета заведены в нём у пользователя, и показать ему баланс каждого.

На платформе W11 диалоговый ассистент может быть как вопрошающим клиентом, так и слушающим сервером. Для этой цели предусмотрены два слота – HTTP-request и Webhook. Слот HTTP-request позволяет отправить запрос к другой программе (в нём можно задать метод, url, заголовки, параметры и тело) и получить ответ прямо в контекст диалога (куда именно – тоже настраивается). Слот Webhook позволяет принимать входящие запросы и складывать информацию из них в контекст.

То, что ассистенты могут как спрашивать, так и слушать, даёт нам весьма полезное свойство – ассистенты могут общаться между собой. Это свойство позволяет составлять комплексные системы из множества ЦДА, работающих в команде (об этом ниже).

Иногда с цифровым ассистентом нужно поговорить «голосом». Ситуации могут быть разные: проблемы со здоровьем, заняты руки, рядом нет телефона и так далее. В конце концов, это просто круто. Проблема в том, что ассистент взаимодействует исключительно с текстовой информацией, технология NLU просто не может работать с голосом (набор звуковых волн). В таком случае нам помогут технологии распознавания речи (v2t, voice to text). Всё станет просто – сначала голос переводим (транскрибируем) в текст, а затем отправляем этот текст в NLU.

На технологии распознавания речи построены голосовые ЦДА, которые способны общаться с пользователем во время звонка, об этом ниже. Помимо этого, распознавание речи можно использовать для поддержки общения с агентом голосовыми сообщениями в мессенджерах (и агент не будет против). В таком случае мы можем использовать API v2t, которое при отправке в него звукового файла возвратит распознанный текст.

При помощи платформы W11 можно создавать голосовых агентов.

Голосовые ЦДА – это программное обеспечение на основе искусственного интеллекта, которое может понимать естественный язык и синтезировать речь, чтобы общаться с пользователями. Голосовые ЦДА могут использоваться для различных целей, например, запускать автоматический обзвон пользователей, помещать данные в CRM, перенаправлять вызовы на разные категории операторов и пр.

Голосовые агенты применяют технологии обработки естественного языка (NLP) для понимания речи. Когда дело доходит до предоставления ответов, голосовые ЦДА могут использовать предварительно записанные аудиозаписи или технологию Text-to-Speech (TTS), которая также называется синтезом речи. Это компьютерное моделирование человеческой речи с применением методов глубокого обучения. TTS создает имитацию человеческого голоса из текста.

Голосовому агенту присущи следующие особенности:

• Ответ пользователю происходит также посредством текстовых слотов, но для озвучивания прописанных в них реплик используются загруженные на платформу голосовые записи.
• Транскрипция голосовой записи, загруженной на платформу, должна полностью соответствовать тексту в стратегии.
• Если голосовая запись не предзаписана, то ее можно сгенерировать с помощью модуля T2V (text to voice), переводящего реплику из текста в голос. Это полезно, если используется динамическая переменная, например, агент обращается к пользователю по имени.

В настройках компании можно установить лимит звонков для ЦДА, которые одновременно могут находиться на агенте, т.е. единовременно агент может говорить только с тем количеством пользователей, которое указано в лимите. Голосовые ЦДА умеют самостоятельно завершать диалог с пользователем. Работа голосовых агентов осуществляется посредством их подключения к телефонии через канал Voice Connector.

В сервис Voice connectorпопадает реплика пользователя, который общается с агентом через телефонию. Сервис распознает голос, реализуя логику разбиения потока голоса на фрагменты. После того, как сервис распознал самую длинную паузу, он понимает, что реплика окончена. Затем с помощью технологии voice to text голосовая фраза переводится в текст и отправляется в агента. Реплика пользователя обрабатывается согласно стратегии – например, модуль NLU относит ее к определенному интенту – и агент возвращает в коннектор соответствующий ответ. Далее, чтобы озвучить этот ответ пользователю, действие происходит по одному из двух сценариев. Voice connector обращается к базе, где хранятся загруженные на платформу предзаписанные реплики, и ищет соответствие ответу, который ему необходимо дать. Если такая реплика существует, он выдает нужный ответ пользователю в виде голосовой записи. В противном случае происходит обращение к технологии text to voice, которая генерирует голосовую реплику на основе полученного текста и возвращает ее в коннектор, а он в свою очередь отправляет сгенерированный ответ пользователю.

Наглядно работа Voice connector представлена на схеме.

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

Предположим, что наша задача – создать корпоративного ЦДА, с помощью которого сотрудник может взять отпуск. Этот процесс происходит в три этапа: сотрудник пишет заявление на отпуск, согласовывает его с начальством, заявление попадает в бухгалтерию для начисления отпускных. В процесс вовлечены три разных отдела, и для каждого нужен свой агент: первый получает информацию от сотрудника и формирует заявление, второй уведомляет руководство и утверждает предоставление отпуска, третий передаёт данные в бухгалтерию. Из трёх агентов собирается один процесс – и ЦДА информирует сотрудника о результате согласования отпуска.

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

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

Запоминание контекста. Пользователь вводит имя, номер телефона – и прекращает общение с ассистентом. Через несколько дней возвращается и хочет продолжить заполнение формы. Хороший ассистент предложит начать с места, где пользователь остановился, а все его введённые данные достанет из контекста, где их заранее сохранил. Это реализуется сохранением переменной состояния, которая проверится в начале диалога при повторном обращении пользователя.

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

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

Извлечение сущностей. С помощью такого понятия как извлечение сущностей можно выделять из реплик пользователя важную информацию, какие-либо данные, необходимые для обработки его запроса. После их выделения и сохранения в контекст агент может больше не запрашивать эти данные для выполнения своих дальнейших действий. Например, в агенте есть ветка, где пользователь хочет проверить статус заказа. Он может написать об этом, и диалоговый ассистент попросит ввести номер заказа. Если пользователь напишет «Скажите статус заказа №123456», указав номер заказа в первой же своей реплике с просьбой, тогда будет нелогичным со стороны ЦДА этот номер запрашивать. В такой ситуации с помощью регулярного выражения можно проверять первую реплику на наличие в ней номера заказа, выделять номер и сразу выдавать ответ на основе полученных данных.

Различные, казалось бы, незначительные детали в дизайне агента могут очень сильно влиять на впечатление пользователя от общения с диалоговым ассистентом.

Приветственное сообщение. С самого начала, при первом же касании диалоговый ассистент может заинтересовать, а может оттолкнуть пользователя. Так как общение начинается с приветственного сообщения, желательно продумать его так, чтобы сразу было понятно, что это за ЦДА и для чего он нужен — это поможет пользователю сразу перейти к вопросам, которые ассистент умеет решать. Для этой же цели используется интент «Что ты умеешь?», который позволяет с помощью простого вопроса узнать возможности агента.

Small talk. Если диалоговый ассистент умеет отвечать на сложные вопросы, будет несколько странным не обучить его понимать минимальный small talk в виде фраз «Привет», «Пока», «Спасибо». Даже если пользователи не будут болтать с ассистентом на отвлеченные темы и ни разу не спросят его «Как погодка?», такие фразы они наверняка будут использовать.

Подсказки. Диалоговый ассистент может направлять пользователя, подсказывая ему о своих возможностях. Если реплика не была распознана и агент вывел соответствующее сообщение, он может дать подсказку в виде текста, например, «Я не понял, но могу подсказать вот это…» либо кнопок, нажав на которые пользователь попадет на нужный ему ответ или функционал.

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

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

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

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

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

На 2020 год в России установлено 14 миллионов камер видеонаблюдения, 60% которых установили коммерческие организации. Камеры используются для предотвращения краж в магазинах, отслеживания времени прихода и ухода сотрудников офиса, регистрации ДТП. Они собирают огромное количество информации, но использовать эту информацию сложно – гигабайты видео не вставишь в отчёты, 24-х часовую запись пяти камер магазина в день недостачи не предоставишь в суде. Поэтому есть такая профессия – за камерами наблюдать.

Наблюдающих называют операторами видеонаблюдения. Это ответственная, сложная и портящая здоровье работа: нужно по 8 часов в день сидеть и смотреть на мониторы, выявлять признаки кражи, сообщать охране или пожарным о ЧС, открывать шлагбаумы для служебных машин и т.д. Все эти действия происходят по чёткому алгоритму: увидел подъезжающую машину и посмотрел номер, узнал, есть ли он в базе, открыл шлагбаум, закрыл шлагбаум. Но когда есть чёткий алгоритм – его можно оцифровать. Создать цифрового оператора видеонаблюдения.

Если взаимодействие с базой, открытие и закрытие шлагбаумов, даже информирование охраны можно реализовать уже известными вам способами, то как наш цифровой оператор «увидит» машину и её номер? Для решения таких задач используется технология компьютерного зрения, а точнее её раздел – распознавание образов и видеоаналитика.

Единицей компьютерного зрения для задачи построения ЦОВ является детектор. Он выполняет одну конкретную задачу распознавания: определение положения объектов (человек, машина, предмет), считывание номера, распознавание лица. Если упрощать, детектор смотрит на кадр и выделяет в нём рамочкой распознанные объекты с указанием дополнительной информации (и делает это с каждым кадром):

Используя данные нескольких детекторов и возможности ЦДА (в том числе и интегративные), можно строить сложные сценарии видеоаналитики. Например, автоматически открывать шлагбаум (обращаясь к API управления шлагбаумом), если в поле зрения камеры появилась машина с номером из базы. Или предлагать сотруднику в офисе размяться, когда он уже 4 часа безвылазно сидит за компьютером. Или автоматически составлять отчёт в конце рабочего дня по тому, кто сколько времени провёл за работой.

Совокупность той информации о сцене, по которой можно сделать полезные для решаемой задачи видеоаналитики выводы, мы называем Семантикой сцены. Для ЦОВ свободности переговорки семантика сцены – число людей в переговорке; для ЦОВ на стройке – нарушения техники безопасности. Если обобщать, задачу видеоаналитики можно разделить на две подзадачи: определение семантики сцены по данным с детекторов; и настройка различных реакций на семантику.