Привет, Хабр! Меня зовут Алексей Борщов и я занимаюсь проектированием голосовых диалоговых систем в компании Just AI. Как вы уже догадались по заголовку, речь сейчас пойдет о процессе создания голосового бота техподдержки, который может быть использован как для внутрикорпоративной, так и для внешней (клиентской) поддержки. И начнем мы с очевидного вопроса – а зачем он вообще нужен?

«Я никогда не звоню в техподдержку, проще же написать!», – скажете вы. Но давайте будем честны – телефонные звонки в первую очередь не любят сами сотрудники техподдержки, а не пользователи. Ведь телефон это про «здесь и сейчас» – дай ответ или помоги прямо по ходу разговора, не отвлекаясь на другие задачи. Поэтому техсаппорт всеми силами старается никому не сообщать свои прямые контакты, отправляя пользователя либо в электронную почту, либо сразу в систему Service Desk, чтобы он самостоятельно оформил тикет и встал с ним в очередь обращений. 

В этой ситуации нет ничего странного. Сложно организовать техподдержку, которая может:

1) Оперативно отвечать на телефонные обращения;

2) Оперативно отвечать на телефонные обращения в рамках выделенного бюджета;

3) Оперативно отвечать на телефонные обращения, сталкиваясь с низкой квалификацией мотивированных юзеров или, наоборот, высокой демотивацией квалифицированных инженеров.

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

А в чем, собственно, сложность?

При запуске голосового бота мы решали две большие и непростые задачи:

• Бот должен правильно понять, что от него хочет пользователь, учитывая специфичные термины, сленговые выражения и самое главное – учитывая постоянные, но незначительные помехи в телефонном канале. К помехам добавляются ошибки, которые всегда есть даже в самом продвинутом модуле ASR (Automatic Speech Recognition).

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

Запуск такого проекта проходит в несколько объемных этапов. На этапе разработки мы используем расшифровки диалогов техподдержки, которые размечаются в автоматическом режиме инструментами нашей платформы JAICP. Лингвист проверяет результаты разметки, дополняет их или корректирует.

После запуска бота в эксплуатацию начинается процесс его дообучения, когда лингвист разбирает все реплики пользователей, которые не попали в штатные ветки сценария или попали не туда. Это так называемые стейты «NoMatch» или «CatchAll», которые создаются на этапе разработки для того, чтобы бот правильно реагировал на такие ситуации. Сейчас для автоматизации этой работы мы используем запросы в большие языковые модели (LLM) и, в частности, в GPT. В большинстве случаев это позволяет дообучать бота под нужную тематику полностью в автоматическом режиме.

Датасет – одна из главных болей бота техподдержки

Представьте, каким должен быть датасет, который одинаково интерпретирует фразы типа «я не могу никуда зайти», «у меня пароль отвалился», «меня винда не пускает» или «как пароль на ноуте восстановить». И добавьте к этому набору данных 5-10 вариаций каждого слова, которые может вернуть ASR из-за фонового шума, скорости речи или акцента пользователя. «Пароль», «король», «моль», «соболь» и даже «полет» – все это может вернуть ASR в самых разных комбинациях на слово «Пароль».

В таком случае задача дизайнера-лингвиста сводится к наполнению базы синонимов, нахождению баланса и работы с весами, которые возвращает модуль NLU (Natural Language Understanding). Нужно правильно отработать пограничные ситуации с учетом контекста диалога и вероятности получения в ответе ожидаемого от пользователя интента. Чем больше бот понимает вопросов и тематик, тем сложнее его база знаний и тем больше тренировочных фраз должно быть использовано при обучении бота.

В основе полезности бота лежит объем его базы знаний – чем больше в ней вопросов, тем умнее будет бот, а значит тем больше обращений сможет решить самостоятельно, не привлекая к консультации специалиста. Этот параметр бота называется уровнем автоматизации (AL) и определяется в процентах от числа обращений, обработанных ботом. На это значение очень сильно влияет специфика бизнеса. На давно работающих и стабильных проектах процент простых запросов, которые можно автоматизировать с помощью бота, обычно выше 70%. Из них бот сможет качественно отработать больше 60%. Это значение связано как с уровнем NLU, так и с готовностью пользователей работать с ботом.

Бот, не упусти пользователя

Но какой бы качественной и наполненной не была модель, будут случаи, когда бот не поймет запроса пользователя. Такие ситуации важно отработать на уровне сценария, чтобы запрос не потерялся, и человек в любом случае получил ответ на свой вопрос. В зависимости от настроек сценария бот может постараться уточнить запрос, попросить его переформулировать и, если это не помогло, то попробовать перевести на оператора или сразу создать обращение в техподдержку с результатами диалога. Число попыток уточнить запрос до перевода зависит от логики сценария и уровня поддержки, часто связанным с уровнем SLA (Service Level Agreement) обратившегося юзера.

Как обеспечить авторизацию?

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

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

Омниканальность – наше все

Функциональные возможности нашего бота сильно расширяют его способность поддерживать диалог с пользователем одновременно в нескольких каналах коммуникации. Чаще всего это пара «телефон + e-mail», но в нашем списке 21 канал для связи с пользователем, можно выбрать любые комбинации. Выглядит это так – клиент обращается к нам по телефону, бот авторизует пользователя, находит его адрес электронной почты. Далее, если хватило консультации по телефону, то бот просто присылает клиенту на почту расшифровку диалога, его результат и ссылку на созданную ботом задачу в ITSM-системе. Если нужно дослать пользователю инструкцию или какую-то ссылку, она также улетает к нему на почту или любой другой выбранный канал. Ответить человек может как на почту, так и повторно позвонив по телефону – история общения будет сохранена, диалог возобновится, и проблема пользователя рано или поздно будет решена. 

Для реализации такой непрерывной омниканальности диалога мы соединяем в одном проекте сразу двух ботов – голосового и текстового. Голосовой работает только с телефонным каналом, текстовый бот берет на себе прием и отправку e-mail и все остальные текстовые каналы коммуникации. Оба бота ходят в общие базы для сохранения данных диалогов и сбора аналитики. Взаимодействие с внешними системами по API и HTTPS выполняют оба бота для ускорения циклов обмена.

Как видно из схемы, обмен с ITSM двухсторонний. Это нужно для того, чтобы бот мог реагировать на изменения в статусах задач и коммуницировать с клиентами без участия специалиста. Самый частый пример такого взаимодействия – закрытие большинства задач по таймауту, когда мы не дожидаемся ответа пользователя на уточняющий вопрос или он не подтверждает успешное выполнение таски по каким-то причинам. В этот момент ITSM может дергать метод API, и бот позвонит клиенту, уточнит, решен ли его вопрос и заодно проведет оценку качества выполнения задачи (CSI). Затем бот вернет в ITSM результат звонка, дополнит таску оценкой или вернет таску исполнителю, если задача все еще не решена.

В заключение

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