Размещено на http://www.allbest.ru/



Аннотации

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

This thesis qualification work relates to the development of a system that will help reduce the load on the call center. During the development, an analysis of the Yandex SpeechKit, Google SpeechKit, Wit.ai services was conducted, and existing methods for recognizing calls were identified. The aim of the work is to develop a system that will be able to help the user or employee with the majority of his questions, in the process of processing or waiting for an order. This product will be implemented in the company "Eyekraft".

Оглавление

Введение

1. Анализ существующих технических решений

1.1 Индивидуальное решение подрядчиком

1.2 Выбор декодера

2. Проектирование сервиса "Секретарь"

2.1 Проектирование модуля голосового декодера

3. Разработка проекта "Секретарь"

4. Фоновое распознавание разговоров Горячей линии

5. Тестирование

Заключение

Список использованных источников

Введение

Актуальность

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

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

· повышением доступности информации на сайтах и порталах;

· превентивным информированием клиентов;

· тренингами и регулярным обучение сотрудников;

· улучшением качества и наглядности инструкций;

· внедрением интерактивных голосовых меню (IVR);

· созданием адаптированных под конкретные нужды форм подачи заявок;

· внедрением систем советов по самостоятельному решению наиболее часто возникающих проблем;

· добавление чатов, позволяющих одному оператору параллельно работать с несколькими запросами.

Рассмотрим компанию "Айкрафт", на Горячую линию которой поступают звонки из двух источников: клиенты и собственные сотрудники. На текущий момент в компании реализованы следующие способы снижения нагрузки на операторов:

· на главной странице сайта система сразу показывает ближайшие к клиенту магазины, указывая расстояние до них, позволяя одним кликом построить маршрут;

Рисунок 1. Схема проезда на машине к ближайшему магазину

· при оформлении заказа ERP предсказывает срок выдачи заказа;

· через несколько минут после оформления и оплаты заказа клиенты получают ссылку для контроля статуса изготовления заказа, после поступления заказа в магазин клиенты получают уведомление о готовности, при вынужденных задержках изготовления система автоматически информирует о переносе сроков выдачи;

· на портале компании для сотрудников размещены наглядные инструкции и советы по самостоятельному решению возникающих вопросов;



Рисунок 2. Пример подачи заявки(слева) с инструкциями(справа)

· создана система подачи заявок с возможностью следить за статусами поданых обращений;

· новые сотрудники проходят недельное обучение и месячную стажировку;

· регулярно обновляются тренинги для поддержания навыков решения различных проблем и вопросов;

· используются интерактивные голосовые меню (IVR);

· при звонке клиента с телефона, указанного в изготавливаемом заказе, телефонная станция сразу переключает вызов на соответствующий магазин, минуя голосовые меню;

· формы подачи заявок структурированы, и каждая форма адаптирована под конкретные нужды, с одновременным отображением релевантных ситуации советов.



Рисунок 3. Таблица форм заявок распределенных по вопросам

Однако, данные меры оказались недостаточными. Проведенный анализ звонков показал, что:

· потенциальные клиенты все равно продолжают достаточно часто спрашивать адреса магазинов и часы их работы;

· заказчики просят переключить на конкретный магазин, номер которого указан на бланке заказа;

· сотрудники магазинов в 30% случаев задают вопросы, отраженные в инструкциях и советах;

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

На данный момент при 500 розничных магазинах Горячая линия обрабатывает свыше 10 000 звонков ежемесячно. С ростом числа магазинов количество звонков увеличивается, что ведет к необходимости увеличения штата сотрудников горячей линии, а это приводит к увеличению себестоимости товара и усложняет реализацию цели компании "качественные очки - это не дорого". И для того, чтобы продолжить следовать политике компании, было решено отдать рутинные звонки машине, и для этого использовать систему маршрутизации телефонных вызовов на базе голосового анализатора.

1. Анализ существующих технических решений

Идея с автоматизацией звонков на базе голосового анализатора достаточно новая, и готовых решений на рынке немного. Анализ рынка показал, что существует 3 типа решений:

· найм подрядчика для создания индивидуального продукта;

· покупка готового решения и его интеграция;

· создание проекта своими силами.

При внедрении голосового анализатора планируется экономить до 50 тыс.руб/месяц на текущих объемах звонков при одновременном повышении оперативности оказания помощи. Так как данный проект является экспериментальным и нет уверенности в его успехе, то срок его окупаемости должен быть минимален - не более 1 года. Учитывая расходы на горячую линию и планируемую экономию, следует, что бюджет данного проекта составляет порядка 500 тыс.руб.

1.1 Индивидуальное решение подрядчиком

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

Данный тип решения не подходит компании "Айкрафт", ввиду высокой стоимости.

Готовое решение

Более дешевый и быстрый вариант - это воспользоваться уже разработанной системой и после обследования бизнес-процессов и потребностей компании, заказать ее интеграцию. Были найдены следующие компании: Ziax, iVoice. Рассмотрим данные варианты ниже.

Ziax

Ziax - это готовый продукт по автоматизации звонков. Первые упоминания об этом проекте можно встретить в августе 2018 года, так что проект достаточно свежий.

Как заявляет разработчик данного проекта, его продукт имеет голосовую маршрутизацию, может принимать звонки и отвечать на вопросы пользователя, делать холодный обзвон клиентов без участия оператора, а также осуществлять мониторинг автоматических звонков. Так же данный продукт интегрируется с любыми ERP/CRM клиента, что дает возможность обрабатывать большинство запросов пользователей. При этом в проекте отсутствует возможность распознавать звонки персонала с возможностью просмотра результата, и возможностью создания списка исключений номеров для распознавания. Проект в основном предназначен для автоматизации исходящих звонков по достаточно простым сценариям с простыми ответами абонента. Разработчики не смогли доказать наличие достаточного опыта в автоматизации обработки входящих слабо типизированных звонков, требующих оперативно решать запросы среди десятков тематик, каждая из которых может потребовать отдельной интеграции с ERP/CRM.

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

iVoice

iVoice - это, как и предыдущий пример, готовый проект по автоматизации звонков, а также система анализа диалогов продавцов с клиентами в прикассовой зоне. Информацию об этом проекте можно найти примерно с октября 2017 года, так что это проект старше чем предыдущий.

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

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

Индивидуальное решение своими силами

Разработка собственными силами оценивается примерно в 300 тыс.руб, что позволит вписаться в бюджет, а также выполнить любые доработки нужные компании. И что самое важное, позволит компании своевременно увидеть преимущества и недостатки данного проекта, и принять решение о его внедрении уже после первых 50-100 тыс.руб. инвестиций.

Выводы

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

Для данного проекта нужно будет разработать систему из 3 модулей: ядро, декодер, телефонная станция. Ядро и телефонная станция у проекта фиксированы, так как они уже давно используются в компании и их смена не целесообразна: это Odoo ERP и Asterisk соответственно. А вот декодер нужно будет выбрать. Выбирать его надо будет по нескольким критериям: конкурентно-способная ценовая политика, возможность распознавать звонки длиннее минуты, возможность распознавать несколько звонков параллельно. Выбор планируется между следующими проектами: Yandex SpeechKit, Google SpeechKit, Wit.ai.

Основная сложность этого проекта - создать удобный и полезный интерфейс для пользователя с учетом достаточно сильного ограничения в ресурсах.

Постановка цели и задач

Цель - создать промежуточный проект "Секретарь", для тестирования возможностей общения человека с роботом по телефону; а также создать промежуточный проект по распознаванию всех звонков Горячей линии и Технической поддержки для последующего изучения и составления сценариев по обслуживанию клиентов.

Задачами работы являются:

1. Исследование Yandex SpeechKit, Google SpeechKit и Wit.ai для выбора, подходящего под нужды компании;

2. Обзор документации

2.1. Обзор документации Yandex SpeechKit;

2.2. Обзор документации Google SpeechKit;

2.3. Обзор документации Wit.ai;

3. Проектирование проекта "Секретарь";

4. Разработка проекта "Секретарь";

5. Проектирование проекта по распознаванию звонков;

6. Разработка проекта по распознаванию звонков;

7. Тестирование проектов;

8. Разработка документации и руководства пользователя;

9. Внедрение проектов в рабочую практику;

Цели и задачи

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

· декодер, отвечающий за преобразование голоса в текст

· ядро, принимающее решения

· координатор, обеспечивающий

o взаимодействие с телефонной станцией

o преобразование текста в речь

o вызов декодера и ядра

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

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

Для сбора статистики поступающих вопросов решено создать программу фонового распознавания разговоров Горячей линии.

Распределение задач проекта в команде

В созданной тестовой среде необходимо протестировать следующие ключевые моменты:

· выбор голосового декодера (выполнял Валерий)

o вычитка документаций декодеров

o сравнение качества распознавания

o сравнение стоимости использования разных декодеров

· взаимодействие с голосовыми декодерами (выполнял Вячеслав):

o передача файла на распознавание текста

o качество распознавания

o генерация голоса из текста

o ограничения декодеров

· взаимодействие с телефонной станцией (Вячеслав):

o получение записи голоса звонящего абонента

o способы воспроизведения звонящему речевых сообщений

o способы получения ответов абонента

o способы переключения звонящего абонента на найденного

· взаимодействие телефонной станции с базой данных Odoo ERP (Вячеслав):

o передача модулю Odoo ERP распознанного текста для поиска абонента

o поиск абонента в адресной книге Odoo ERP, среди пользователей, среди сотрудников

o возврат станции команды на соединение с найденным телефоном

o передача станции списка для выбора среди найденных

o передача станции команды на уточнение запроса в связи с большим числом совпадений или по причине отсутствия совпадений

· фоновое распознавание состоявшихся разговоров Горячей линии (Валерий):

o занесение записей в MySQL записывающихся звонков

o распознавание записанных звонков

o передача текстов распознанных звонков в Odoo

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

Настройка тестовой среды

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

· передача файла на распознавание текста

· качество распознавания

· генерация голоса из текста

· ограничения декодеров

· обход ограничений

В качестве телефонной станции используется Issabel PBX, ядром которой является Asterisk, в качестве операционной системы используется CentOS. Внешние модули Asterisk можно создавать практически на любом языке программирования, доступном в CentOS. Есть примеры взаимодействия с Asterisk на Bash, PHP, Perl, Python. На языке Bash не очень удобно взаимодействовать с Asterisk и неудобно обрабатывать исключения. Для Perl практически нет примеров как для Asterisk, так и для голосовых движков. Для PHP много примеров для Asterisk, но не очень удобно реализовывать многопоточность процессов распознавания (чтобы обеспечить достаточную производительность при фоновом распознавании состоявшихся разговоров) и потоковую передачу голоса (чтобы справляться с распознаванием бесед длиннее нескольких десятков секунд). Для Python не очень много примеров взаимодействия с Asterisk, но есть примеры по использованию распознавания голоса в Яндекс и Гугл. Также язык Python более структурный, в сравнении с PHP, что стимулирует написание более легкого в поддержке кода. Поэтому, по совокупности факторов, выбор пал на использование языка Python для целей интеграции с движками распознавания голоса.

Поскольку язык Python кроссплатформенный, значительная часть тестирования проводилась на операционной системе Ubuntu 16.04 LTS, установленная на локальном компьютере. При этом использовались языки программирования как Python, так и Bash. Финальные тесты проводились на резервной телефонной станции на языке Python.

Выбор декодера

В данном проекте выбор декодера очень важен, так как именно от него, в основном, зависит качество и скорость распознавания. Пожалуй, декодер - самая важная часть в этом проекте. Выбор у нас стоял между Yandex SpeechKit, Google SpeechKit и Wit.ai. Далее рассмотрим каждый из них подробнее.

Yandex SpeechKit

В библиотеке Yandex SpeechKit Cloud API есть возможность как декодировать голос пользователя, так и создавать голосовое сообщение из текста. Распознавать и генерировать голосовое сообщение можно на любом из 3 языков: Русский, Английский и Турецкий. Так же присутствует такая возможность как "Выбор языковых моделей". Языковая модель - это база слов, которые, в теории, может сказать пользователь. Данная особенность может улучшить распознавание в определенных ситуациях за счет того, что у системы будет меньше возможных вариантов распознавания. Однако у декодера уже после создания работающего проекта появилось ограничение - Яндекс не распознает записи длиннее 5 минут, даже если передавать голос вместо файла потоком. На этапе выбора декодера Яндексом использовалась иная библиотека, позволявшая распознавать диалоги, превышавшие даже 10 минут. Тем не менее, для задач автосекретаря достаточно возможностей Яндекса, так как на произнесение ФИО или названия магазина требуется лишь несколько секунд.

Декодер Яндекса платный. За синтез 1 млн символов необходимо заплатить 183 рубля, а распознавание 15 секунд обойдется в 15 копеек.

Яндекс озаботился созданием инструкции по использованию Yandex SpeechKit API, а также создал примеры использования на разных языках. Разработка начинается с получения API-ключа для SpeechKit Cloud (https://cloud.yandex.ru/docs/speechkit/concepts/auth):

· войти под своей учетной записью разработчика в сервисы Яндекса

· открыть страницу разработчика для SpeechKit (https://tech.yandex.ru/yandexcloud/)

· нажать "Получить ключ" и выбрать "SpeechKit Cloud"

· полученный теперь ключ можно использовать в своем модуле

Вот простой пример для распознавания текста в небольшом файле (примерно до 1 минуты):

Рисунок 4. Пример кода для распознавания небольших файлов

Рисунок 5. Примеры распознанных фраз

Рисунок 6. Пример кода отправки файлов на распознавание

Записав множество разных фраз, можно оценить достоверность распознавания. Ответы от Яндекса получаются примерно такие:

Проверку движка проще выполнять на языке Bash, поскольку для отправки другого файла достаточно в терминале Ubuntu/CentOS вызвать предыдущую команду и исправить название файла.

После оценки качества распознавания можно убедиться в работоспособности примеров на языке Python:

Google SpeechKit

Голосовой движок Google также может не только распознавать голос, но и генерировать речь из текста. В отличие от Яндекса, движок Гугл может распознавать файлы до 480 минут, а также поддерживает более 120 языков и диалектов. В отличие от Яндекса у Гугл нет языковых моделей, однако есть возможность указать число дикторов.

Использование облачного сервиса Гугл тоже платное. За синтез 1 млн символов необходимо заплатить $4.00 (240 рублей), а распознавание 15 секунд стоит $0.006 (36 копеек). То есть цены Гугл в 2 раза выше, чем у Яндекса.

Гугл достаточно хорошо описал Google SpeechKit API, но пока описание доступно только на английском языке. Гугл также предоставляет разработчикам примеры использования движка на разных языках программирования, в том числе и на языке Python:

Рисунок 7. Пример кода для распознавания фалов при помощи Google

Чтобы воспользоваться сервисом Гугл потребуется зарегистрироваться как разработчик, получить ключ для своего приложения и установить библиотеки для Python. Однако, оценить качество распознавания, зависимость распознавания от настроек и пример соответствующего запроса можно непосредственно из онлайн-документации: https://cloud.google.com/speech-to-text/

Рисунок 8. Веб-интерфейс для распознавания аудиофайлов

Выдав сервису аудиофайл с непростой для Яндекса фразой "Кальщиков Олег" можно убедиться, что и для Гугл фамилия непростая и может быть распознана как "Колесников Олег".

Рисунок 9. Пример распознавания сложной фамилии

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

Зато Гугл умеет распознавать несколько дикторов, что делает сервис удобным для распознавания телефонных разговоров:



Рисунок 10. Пример распознавания телефонного разговора

В этом отношении сервис Гугл удобнее и тем, что может распознавать аудиопотоки длиной до 480 минут (в отличие от новой версии Яндекса, в котором ограничение установили в 5 минут, а таких разговоров на телефонной станции не так уж и мало).

По перечисленным выше причинам сервис Гугл предпочтительно использовать для распознавания телефонных переговоров, особенно для длинных разговоров. Для распознавания команд практичнее использовать Яндекс.

Wit.ai

В данном декодере есть возможность только распознавать голос. Генерация голоса из текста невозможна. Отсутствует возможность выбрать языковую модель, движок не распознает записи длиннее 1 минуты, запросы можно отправлять не чаще 1 раза в секунду.

Зато данный проект абсолютно бесплатный и платная версия пока не планируется.

Начать использовать сервис достаточно просто:

· создать учетную запись

· зарегистрировать свое приложение и язык приложения (русский)

· получить ключ для приложения

Все это весьма доступно описано в документации, хотя и на английском. Протестировать сервис можно из командной строки (https://wit.ai/docs/http/20170307#post__speech_link):

Рисунок 11. Пример запроса на распознавание в wit.ai

Основное назначение сервиса - создание чат-ботов. Для целей распознавания голоса Wit подходит на случай, когда временно не работает основной сервис.

1.2 Выбор декодера

У Wit.ai есть ограничение по количеству запросов в секунду, что критично для нашего проекта, поэтому движок интересен исключительно в академических целях. У Google на момент выбора декодеров не было существенных преимуществ перед Яндексом, но при этом цены вдвое выше, а также компании-заказчику сложнее оплачивать зарубежные услуги в сравнении с оплатой российских сервисов. С учетом всех факторов было решено использовать Yandex SpeechKit.

2. Проектирование сервиса "Секретарь"

Для снижения трудозатрат на разработку и на дальнейшее развитие проекта было решено разделить структуру сервиса на 3 части:

· декодер, отвечающий за преобразование голоса в текст

· ядро, принимающее решения

· координатор, обеспечивающий

o за взаимодействие с телефонной станцией

o преобразование текста в речь

o вызов декодера и ядра

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

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

Рис.12 UML-диаграмма вариантов использования со стороны пользователя

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

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

· следить, что все адресаты присутствуют и корректно настроены в базе данных Odoo ERP, в недрах которой функционирует ядро решения

· курировать своевременное создание абонентов на телефонной станции

· анализировать логи с попытками соединения Пользователей с желаемыми абонентами, чтобы добавлять синонимы, повышающие процент переключений, состоявшихся с первой попытки (например, для соединения с магазинами могут потребоваться синонимы, такие как "солярис" для соединения с "ТЦ Саларис", или "самбреро" для соединения с "ТЦ Сомбреро", или "филимон" для "ТЦ Филион", или "кабельщиков" для "Кальщиков" и прочее)

· просматривать автоматически созданные синонимы, чтобы активировать корректно выявленные соответствия, такие как "как мороженка" или "осторожен как" для "Красноруженко", "лего уткина" для "Леуткина", "иванов вячеслав" для "Юров Вячеслав" и тому подобное.

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

Рис.13 UML-диаграмма вариантов использования модератора

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

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

Рис.14 UML-диаграмма последовательности идеального сценария вызова

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



Рис.15 UML-диаграмма деятельности всего проекта

2.1 Проектирование модуля голосового декодера

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

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

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

Проектирование модуля взаимодействия с телефонной станцией

Проектирование данной части проекта состоит из следующих функций:

· запись фразу пользователя в аудиофайл

· отправить аудиофайл модулю декодирования голоса в текст

· отправить распознанный текст в ядро создаваемого приложения

· принять команду от ядра

· преобразовать текст в голос

· запросить станцию озвучить преобразованный в аудиофайл текст

· запросить станцию соединить с заданным абонентом

Взаимодействие с сервисом Секретарь начинается со следующих действий:

· записать фразу Пользователя

· распознать фразу.



Рис.16 UML-диаграмма деятельности распознавания первичной фразы

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

Рис.17 UML-диаграмма деятельности взаимодействия с Пользователем

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

Проектирование ядра системы Секретарь

Задачами ядра системы являются следующие функции:

· поиск абонента среди пользователей, среди контактов, среди сотрудников (в Odoo ERP это разные сущности, первые из которых могут входить непосредственно в систему, вторые могут быть в числе постоянных партнеров, третьи по своим трудовым обязанностям не обязаны входить в Odoo ERP, но при этом могут пользоваться телефонами, подключенными как напрямую к станции, так и доступные по мобильному, знать который вызывающему собеседнику может быть вовсе не обязательно)

· сохранение логов звонка

· автоматическое создание синонимов пользователей

· генерирование команд для телефонной станции на основе запроса пользователя

Система Odoo ERP для взаимодействия допускает создание API на основе HTTP POST/GET запросов без авторизации и xml-rpc с обязательной авторизацией. Вариант xml-rpc требует высокого уровня доверия ко второй стороне и усложняет версионность интеграции. Запросы HTTP POST необходимы в случае передачи вложений, которые в нашем случае не требуются, а реализация на базе POST чуть более трудоемкая. С учетом всего сказанного выше, было решено на стороне Odoo ERP использовать контроллер для взаимодействия через HTTP GET-запросы - проще независимо обновлять модули, проще подключаться, практически нет проблем с доверием к вызывающей контроллер стороне, проще в реализации как на стороне телефонной станции, так и на стороне Odoo.

3. Разработка проекта "Секретарь"

Разработка модуля взаимодействия с телефонной станцией

В этом модуле требуется:

· принимать звонок пользователя

· записывать то, что говорит пользователь

· отправлять голосовое сообщение на распознавание

· отправлять распознанный текст в ядро системы

· выполнять команды ядра

В начале нам нужно было научиться принимать звонок пользователя и обрабатывать его. Это прописывается в конфигурационных файлах самого Asterisk.

Рисунок 18. Код по запуску секретаря при звонке на номер 400

Первыми 3 строками мы создаем номер "400" для сервиса "Секретарь" и устанавливаем начальное значение для переменных программы. Далее мы отвечаем на звонок, начинаем запись (до паузы в 2 секунды или до нажатия #), запись отправится непосредственно в интеграционный модуль.

Как только программа decoder_speech.php начнет свою работу, система:

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

· отправит текст в Яндекс

· запишет результат в лог

· отправит распознанный текст в Odoo

· выполнит указание Odoo:

o соединит с найденным абонентом

o предложит выбрать одного из найденных

o попросит повторить запрос, если найдено слишком много

o попросит повторить запрос, если найти абонента не удалось

Воспроизведение фразы абоненту

Для преобразования текста в голос и воспроизведение голоса абоненту написано следующее:

Рисунок 19. Код для воспроизведения аудиофайла пользователю

Этот код:

· проверяет наличие ранее сохраненного голоса для данной фразы

· преобразует текст в речь и сохраняет аудиофайл, если ранее такая фраза на данной станции не встречалась

· дает команду Asterisk воспроизвести указанный файл

Вызов модуля распознавания голоса

Для распознавания голоса достаточно вызвать модуль, указав имя файла для распознавания:



Рисунок 20. Вызов программы на распознавание

В ответ будет получен распознанный текст.

Вызов ядра системы для получения команды для телефонной станции

Распознанную фразу передаем в Odoo ERP - в ядро системы:

Рисунок 21. Получение ответа от ядра системы

Выполнение команды, полученной от ядра системы

От ядра получаем перечень команд, передаем их телефонной станции:

Рисунок 22. Распознавание команд от ядра

Разработка ядра системы Секретарь

Ядро системы выполняет следующие функции:

· ищет абонента:

o среди пользователей

o среди контактов

o среди сотрудников

· сохраняет лог запроса

· автоматически создает синоним, если абонент найден не с первой попытки

· генерирует команды для телефонной станции

Поиск абонента в базе Odoo ERP

При помощи созданного в Odoo контроллера получаем запрос от телефонной станции:

Рисунок 23. Определение полученных переменных

Находим искомого абонента в базе и генерируем команды для телефонной станции:

Рисунок 24. Запись звонка в базу

Сохраняем запрос в истории вызовов:

Рисунок 25. Поиск пользователя

Сохранение разговоров Горячей линии

Со стороны Odoo ERP сохранение логов переговоров Горячей линии состоит из формирования структуры хранения информации:

Рисунок 26. Создание модели для хранения

А также контроллера, обеспечивающего запись распознанных разговоров:

Рисунок 27. Запись звонка

А также описательная часть интерфейса и прав доступа в виде XML и CSV.

4. Фоновое распознавание разговоров Горячей линии

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

· после завершения разговора сохранить в очередь на распознавание основные параметры звонка (дата, время, длительность, собеседники, ссылка на аудиозапись)

· в фоновом режиме брать из очереди следующие аудиозаписи, разделяя процесс распознавания на параллельные потоки

· сохранять распознанный текст:

o сохранять текст в локальную базу данных на станции

o пересылать текст в Odoo ERP, где удобнее осуществлять поиск и есть также возможность предоставить распознанный текст на анализ руководителю Горячей линии

Создание очереди звонков на распознавание

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

Рисунок 28. Вызов функции записи звонка в MySQL

в вызванной процедуре получить переданные параметры:

Рисунок 29. Получаемы параметры

добавить в очередь информацию о разговоре:

Рисунок 30. Запись в базу MySQL

Фоновое распознавание звонков

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

Чтобы обеспечить параллельную работу нескольких потоков распознавания достаточно использовать exec("$cmd &"), где "&" дает команду операционной системе оставить процесс в фоне и вернуть управление вызвавшему процесс потоку, а для порождения нового потока при помощи bash-команды ps контролировать количество уже работающих потоков:

Рисунок 31. Запуск параллельного распознавания

Передача распознанного текста в Odoo ERP

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

Рисунок 32. Передача всех распознанных звонков в Odoo

5. Тестирование

Внедрение проекта "Секретарь"

Внедрение проекта "Секретарь" происходило в 2 этапа:

· Внедрение в IT-отделе

· Внедрение в компании в целом

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

· Создать синонимы популярных целевых фраз

· Определить короткие номера для частых функций

· Добавить звуковое сообщение об принятии запроса

· Повысить скорость произношения бота

· Вставить приветствие

Задача с синонимами была описана ранее, ее цель - с первой попытки соединять с искомым абонентом с первой попытки, даже при ошибочном распознавании фразы.

Задача по определению шага заключается в автоматическом переключении шага по номеру, на который позвонили. Эта функция нужна для того, чтобы снизить нагрузку на пользователя, ведь в полном проекте система не в курсе, чего хочет пользователь, и на практике выяснилось, что пользователю сложно в начале звонка добавлять слово-команду перед своим запросом (например, "вызов Юров Вячеслав" вместо набора номера 400 и произнесением только "Юров Вячеслав).

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

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

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

За счет предварительного внедрения в IT-отдел, при внедрении в компанию в целом программа не требовала доработок. Необходимо было сообщить сотрудникам короткий номер и проинструктировать что требуется делать после звукового сигнала.

Внедрение в компанию в целом помогло собрать статистику, и она показала, что в среднем на звонок пользователю уходит 10 секунд, если система распознала все с 1 раза, и 25 секунд, если система распознала со 2 раза.

Из 10 секунд работы службы "Секретарь" время этапов следующее:

· 2 секунды уходит на установку связи (можно нажать "#")

· 1 секунды уходит на произношение ФИО пользователем

· 2 секунды уходит на ожидание конца фразы (можно нажать "#")

· 1 секунда уходит на уведомление об принятии запроса

· 1 секунда уходит на обработку запроса

· 3 секунды уходят на произношение ответа

Если знать о возможности использования "#", время соединения с искомым абонентом можно сократить примерно до 8 секунд.

Тестирование распознавания звонков

Первое массовое тестирование в реальных условиях показало, что программа распознавала и передавала в Odoo только 8% звонков, найденных в истории вызовов на телефонной станции. При более детальном изучении проблемы было выяснено, что только 25% звонков имели аудиозапись, поэтому остальные вызовы программа не распознавала. Среди звонков с аудиозаписью половина была длительностью в секунды. То есть изначально программа распознавала 60% звонков, имевших корректную аудиозапись. Оставшиеся 40% звонков - это слишком длинные звонки, которые ни Яндекс, ни Wit не могли распознать обычными методами, об исправлении этого недочета подробнее рассказано ниже.

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

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

Доработка распознавания длинных звонков

В мае 2019 года Яндекс в тестовом режиме добавил функцию распознавания длинных звонков (более 1 Мбайта или 5 минут). Новый способ позволяет распознавать аудиозаписи до 1 Гбайта (то есть примерно до 5000 минут).

Процедура работы с большими аудиофайлами принципиально отличается от обработки коротких файлов. Необходимо три обращения к сервисам Yandex:

* загрузить файл с аудиозаписью (форматы opus или ogg) в папку компании для данного приложения;

* отправить запрос на распознание звонка с указанием ссылки на загруженный файл и получить id созданного задания;

* отправить запрос на получение статуса или результатов распознавания с указанием id, присвоенного на предыдущем шаге.

Соответственно и само тестирование разделилось на эти три шага, а также на встраивание нового функционала в существующую на сервере программу распознавания звонков.

Первый шаг потребовал следующих действий:

· регистрации для компании доступа к сервису Яндекс.Bucket;

· сервисного аккаунта, через который будет идти загрузка;

· создание и привязка ключа авторизации к сервису Bucket.

После получения этих компонентов, с использованием python-пакета boto и инструкции от Yandex были успешно реализованы загрузка файла и получение ссылки на его скачивание.

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

На третьем шаге используется id запроса на распознавание, полученный в ответе команды на распознавание загруженной аудиозаписи. Поскольку распознавание Яндексом отправленного аудиофайла может занять не одну секунду, было решено сохранять полученный от Яндекса id с целью позже получить распознанные тексты всех аудиозаписей, отправленных на анализ. Это позволяет сохранять разумное количество параллельных процессов распознавания записей без спонтанных резких нагрузок на процессор и дисковую систему телефонной станции. Идентификатор задачи распознавания было решено хранить в поле для результата распознавания, добавив префикс "queue", т.е. в формате queue_<id>. Доработанный алгоритм обработки вызовов в первую очередь обрабатывает звонки в очереди на ожидание распознанного Яндексом текста, находящиеся там с прошлого запуска, и только после этого начинает обработку новых.

Распознавание всех разговоров через очереди невозможно, так как на данный момент Яндексом введено ограничение в 50 запросов в сутки, поэтому достаточно короткие звонки требуется, как и прежде, распознавать в реальном времени, ожидая получение распознанного текста.

Для перевода нового алгоритма в боевой режим потребовалось автоматизировать обновления токена к сервису Яндекса после его устаревания. Так же новая версия программы фонового распознавания разговоров пропускает пустые и слишком короткие аудиозаписи, чтобы не отправлять лишние запросы. Для выбора способа распознавания (в реальном времени или через очередь) теперь программа заранее определять длительность аудиозаписи в секундах и в мегабайтах. Проверка количества длинных аудиозаписей показала, что в течение месяца таких разговоров набирается менее 1500, поэтому пока что лимиты, используемые Яндексом, позволят распознавать все длинные записи, а также позволят распознать сохранившиеся длинные аудиозаписи предыдущих периодов. Если бы длинных записей было бы больше, пришлось бы регистрировать несколько сервисных аккаунтов и добавить алгоритм переключения между аккаунтами, чтобы успевать их обрабатывать быстрее, чем появляются новые. Пока что можно отложить на более позднее время создание такой доработки.

Проведенная череда тестов позволила в разы улучшить качество созданного приложения по распознаванию записанных разговоров и значительно улучшить сервис "Секретарь".

Заключение

По итогу работы над этим дипломным проектом была настроена интеграция сервиса Yansex Speech Kit в телефонную станцию компании, способная распознавать:

· звонки "на лету", позволяя создать телефонного бота

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

Так же была добавлена интеграция с системой Odoo 10 ERP, позволяющая представить лог истории звонков в более читабельном виде и с легкостью настроить доступы для различных сотрудников.

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

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

Этот функционал позволил нашей команде запустить сервис "Секретарь", способный по голосовой команде переключать вызов на магазин (по городу или названию торгового центра) или на сотрудника (по фамилии или ФИО). Транскрипция истории разговоров Горячей линии позволяет выполнять текстовый поиск, а также использовать эти диалоги для анализа статистики и расширения списка тем, на которые система может найти правильного собеседника.

Пройденный путь позволил понять возможности современных систем распознавания голоса и убедиться в целесообразности расширения голосовых сервисов:

· анкетирование клиентов

o сбор отзывов об удовлетворенности покупками

o заполнение анкет клиентов по предпочтениям в коррекции зрения

· автоматическое обслуживание:

o статус заказа

o подбор ближайшего магазина для визита

o график работы магазина.

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

Список использованных источников

1. ZIAX [Электронный ресурс]: Режим доступа: http://ziax.ru/ - (Дата обращения: 22.03.2019).

...