Hi-tech коммуникации, или как мы создаем голосового агента всего на 500 записях

uovpx6qalaxnty1y55rc9o2yaoi.png?v=1
На Хабре не раз и не два писали о голосовых роботах, принципах их работы и задачах, которые они способны решать. Соответственно, общие принципы создания таких роботов (их мы предпочитаем называть «цифровыми агентами) понятны многим. И это хорошо, ведь в этой статье мы хотели бы поговорить о быстром обучении роботов.

Нам удалось успешно обучать агентов на очень ограниченной базе звонков. Минимальное количество записей, на основе которых можно разработать полноценного цифрового агента — всего 500. (Спойлер — речь идет, скорее, о специализации ассистента, а не обучении с нуля). Как происходит обучение, и какие здесь есть подводные камни, особенности, что лежит в основе технологии? Об этом сегодня и поговорим.

Что должен уметь цифровой агент?


На текущий момент проектируемые нами цифровые агенты, которые работают с использованием интент-классификаторе в сегменте b2c могут поддерживать полноценный диалог. Это стало возможным благодаря тому, что мы их научили:
  • Определять в речи человека и классифицировать различные ответы, вопросы, возражения.
  • Подбирать подходящий по смыслу ответ или реакцию.
  • Определять кейсы, когда абонент не настроен на диалог и выражает негатив. Определять, когда абонент является ребенком и/или пожилым человеком, и корректно завершать звонок в таких случаях.
  • Определять в речи человека и фиксировать, если необходимо, различные сущности, которые называет абонент: имена, адреса, даты, номера телефонов и т.д.
  • Естественным образом реагировать на попытки перебить со стороны абонента. Так, если собеседник начинает говорить параллельно с ассистентом, последний останавливается, слушает возражение абонента и отрабатывает его. Пример разговора с перебиванием вы найдете чуть ниже.
  • «Поддакивать» и воспроизводить разные междометия («угу», «ага») в уместные моменты, чтобы речь ассистента звучала максимально естественно.
  • Произносить, в зависимости от заданных условий (например, в зависимости от региона проживания конкретного абонента) различные переменные. Допустим, разную стоимость услуги или разные ее составляющие.
  • Воспроизводить на протяжении всего звонка «background sound» («фоновый шум»). Это может быть, например, «шум офиса», чтобы создать у абонента ощущение, что он общается с реальным сотрудником колл-центра и многие другие функции, т.к. это не весь важный функционал. Пример — ниже.

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

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


Как обучить робота вести диалог


Это весьма интересная задача. Сейчас мы решаем ее совсем не так, как еще пару лет назад. И как раз сейчас нам хватает несколько сотен записей для обучения агента. Но, конечно, пришли к этому мы не сразу — пришлось немало поработать.

Как было раньше?


Несколько лет назад извлечение интентов и сущностей из речи человека и их классификация осуществлялись с помощью регулярных выражений (regex). Если по-простому — это язык поиска по тексту. Для поиска используется строка-образец (она же паттерн), которая задает правило поиска. Чтобы установить правила поиска, в regex используется специальный синтаксис. Но у этого способа было несколько недостатков:
  • Необходимость в большом и квалифицированном человеческом ресурсе для создания регулярных выражений.
  • Необходимость постоянного анализа и ручной обработки больших объемов информации для улучшения качества распознавания — система, работающая на регулярных выражениях, не способна к самообучению на размеченных данных.
  • Трудность, а иногда — полная невозможность сложной классификации.
  • Ошибки, вызванные человеческим фактором.
  • Сроки подготовки регулярных выражений для конкретного голосового ассистента по сравнению с использованием интент-классификатора (NLU).
  • Средний срок подготовки паттернов (анализ диалогов, создание регулярных выражений на его основе, тесты, правки, доработки) для запуска проекта составлял порядка 3–7 дней; после этого для достижения необходимого качества требовалось еще несколько итераций анализа и масштабных доработок.

А что сейчас?


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

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

Сейчас обучение состоит из двух этапов: непосредственно обучение модели на датасете и дальнейшее дообучение в ходе коммерческой эксплуатации. На текущий момент подключение к движку NLU и экспресс-тесты распознавания занимают у нас всего несколько часов.
Качество, которое раньше достигалось неделями скрупулезной работы, сейчас обеспечивается сразу благодаря основной базе. К примеру, в сегменте b2c первоначальный % ошибок при распознавании согласия/отказа на совершение целевого действия уменьшился в 3 раза (с 10% до 2–3% от общего числа кейсов).

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

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

Entities (сущности).
Intents (намерения).

Важный момент: у нас не классическая диалоговая система в её традиционном понимании, система на машинном обучении не составляет ответ динамически, ответ определяется скрипт-дизайнерами. Фразы бота строго предопределены, никакой свободы воли для искусственного интеллекта здесь нет, к счастью или сожалению…

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

Пример диалога


Ниже — сложный HR-скрипт с обозначением intents и entities; распознанные сущности и интенты указаны под каждой репликой абонента и выделены курсивом.

Бот: Здравствуйте! Меня зовут Елена, звоню по поводу вашего резюме. Подскажите, предложение по вакансии актуально для вас?

Абонент: Да, здравствуйте

Intent: hello_confirm=true

Бот: Смотрите, сейчас у нас открыта вакансия специалиста офиса продаж. В обязанности входит консультация абонентов, продажа оборудования и работа с кассой. Оформление идет полностью официальное, белая зарплата, средний уровень дохода N рублей, максимальный уровень практически не ограничен, есть возможность карьерного роста. График 5 рабочих дней с двумя плавающими выходными. Также предоставляем все социальные гарантии, дмс, бонусы и скидки от компании.

Рассмотрите такие условия для себя?

Абонент: А еще раз, откуда вы звоните?

Intent: question =what_company

Бот: Это розничная сеть NNN

Абонент: А какой у вас график?

Intent: question=schedule

Бот: График работы формируется программой автоматически с учетом потока клиентов и нагрузки на офис с двумя плавающими выходными, то есть смены рабочие 6 8 10 12 часов в день могут быть и не более 40 часов в неделю. При этом график составляется заранее на 2 недели, то есть вы заранее знаете ваш график, ваши выходные, и можете уже планировать.

Абонент: Ну хорошо

Intent: confirmation=true

Бот: Давайте тогда сверим с вами анкетные данные…
Подскажите, пожалуйста, ваши Фамилию Имя Отчество полностью

Абонент: Гудкова Елена Вячеславовна

Entity: name=true

Бот: Назовите, пожалуйста, вашу дату рождения

Абонент: тринадцатое ноль второе восемьдесят седьмого

Entities:
day=[30]
month==[February]
year==[1987]

Бот: Скажите, номер, на который вам звоню, могу записать как контактный?

Абонент: Да нет, наверное

Intent: confirmation=false

Бот: Подскажите тогда номер, по которому можно к вам обращаться?

Абонент: девятьсот десять восемьсот восемьдесят пятьдесят двадцать пять

Entity: telephone=true

Бот: Подскажите, какое у вас образование?

Абонент: Высшее

Entity: education=higher

Бот: Уточните, вы сейчас обучаетесь на очной основе?

Абонент: Нет

Intent: confirmation=false

Бот: Скажите, у вас гражданство Российской Федерации?

Абонент: Российское гражданство

Entity: citizenship=russia

Бот: Хорошо, это был последний вопрос. Спасибо, что ответили на мои вопросы, сейчас я отправлю анкету на рассмотрение руководителю. Анкеты рассматривают в течение 3 дней, и, в случае положительного решения, с вами свяжутся наши сотрудники. Всего доброго, до свидания.

Хорошо, скрипт разработан, что потом?


После всего этого с заказчиком проводится согласование разработанных скриптов. В некоторых случаях клиенты хотят что-то добавить или изменить, что мы и делаем. Иногда возникает необходимость уточнить технические параметры:
  • Способ интеграции.
  • Входные / выходные параметры.
  • Подключение SIP транка (если планируется к использованию телефония заказчика).
  • SMS-подключение или подключение к сторонним системам заказчика (CRM, Campaign management).

Что за входные и выходные параметры? Это — различные переменные, которые нужны нашему цифровому агенту для инициализации звонка. В первую очередь это, конечно, номер телефона или id абонента, которого мы вызываем. Опционально, в зависимости от конкретного заказчика и проекта, это могут быть и другие данные, например:
  • различные компоненты и стоимость услуг и сервисов, которые должен озвучивать ассистент разным абонентам в зависимости от конкретных условий;
  • названия пакетов услуг или сервисов, которые называет ассистент разным абонентам;
  • различные имена, по которым ассистент может обращаться к абонентам при приветствии;
  • дополнительные данные.

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

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

К примеру: номер телефона абонента, длительность звонка, название проекта, в рамках которого совершался звонок, итоги звонка и т.д. Еще выходные данные содержат основной результат звонка, которые зависит от итогов диалога по конкретному проекту (самый простой пример — результат «Согласие» если абонент согласился совершить целевое действие или результат «Отказ» — если абонент отказался). Ну и последнее, это технические данные о статусе звонка и различные коды возможных ошибок (звонок состоялся, звонок не состоялся из-за проблем телефонии, звонок не состоялся из-за некорректных входных данных, и т.п.).
Эти данные могут просто попадать в выходные данные из входных (допустим, во входных данных мы передали ассистенту номер абонента, и в выходных данных по итогам звонка ассистент передал нам тот же номер телефона).

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

Ну, а потом наступает черед таких этапов, как озвучка скриптов, разработка логики, разработка паттернов, верификация ПО и, наконец передача проекта клиенту.

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

© Habrahabr.ru