В ручном режиме контролировать все коммуникации — задача трудоемкая и, кроме того, малоэффективная. И мы решили ее автоматизировать. Для этого пришлось обучить нашу Виртуальную АТС новым трюкам. Технологию Text-to-speech мы внедрили давно, теперь же взялись за обратный процесс.
Выбор робота
С самого начала мы понимали, что ресурсов для разработки собственной платформы по распознаванию голоса у нас нет. Поэтому решили взять существующее решение одного из вендоров и внедрить его в Виртуальную АТС.
Сделать выбор оказалось довольно просто. После того, как Dragon предложили приобрести у них не Software Development Kit, а готовый сервис (разумеется, совсем на других условиях), претендентов осталось четверо: Google, Yandex, Microsoft и ЦРТ.
Основной критерий, по которому мы оценивали все эти решения, — качество распознавания именно телефонной речи, которая имеет свою специфику. Нужно учитывать, что это запись речи, а не короткие голосовые запросы, обращенные к поисковому помощнику. У записи есть параметры, диктуемые кодеками, канальностью и пр. Именно поэтому мы остановились на продукте от ЦРТ.
Трудности внедрения
Примерно 2 месяца ушло на интеграцию алгоритма распознавания с нашей платформой. Основная проблема, которую необходимо было решить, — научить его функционировать быстрее. А если точнее, то найти баланс между удобством работы с SDK и производительностью.
Отдача большого пакета для распознавания выгодна по ресурсам (не надо тратить минуту-две на подготовку), но нельзя ни приостановить, ни изменить приоритет отданных на расшифровку разговоров.
Cтрого говоря, то, что в ЦРТ называют SDK, на самом деле не вполне им является. Это пакет бинарных файлов и bat для запуска, в котором указывается:
- какую модель распознавателя загрузить (медицина, телекоммуникации, банки и т. д..),
- папку, в которой взять аудиозаписи,
- папку, в которую положить расшифровки,
- формат, в котором расшифровку делать.
Причем с выбором форматов не густо: либо что-то ini-образное, либо собственный, в котором указаны границы каждого слова, но нет знаков препинания, которые есть в первом случае. Из-за необходимости запускать bat-файл, мы и столкнулись с проблемой: больше пакет — выше производительность, но ниже гибкость.
Все части нашей платформы (очереди, диспетчеры, модули управления коммутатором и пр.) исполнены в виде микросервисов на Python и работают под RHEL. Но ЦРТ предоставил решение только под Windows. Поэтому еще одна задача, которую пришлось решать разработчикам — внедрение микросервиса на Windows.
Все бы ничего, но оказалось, что в режиме сервиса Windows (а именно так мы запускаем распознаватель) невозможно получить доступ к сетевым ресурсам NFS, на которых у нас лежат записанные разговоры, и то, что работало из консоли, отказалось функционировать в режиме сервиса. На борьбу с этим тоже пришлось потратить ресурс разработки.
Сжимать нельзя распознать
Описанные выше трудности внедрения — не единственные. Задача управления записями разговоров тоже оказалась весьма непростой: мы своим клиентам для скачивания должны отдавать записи в сжатом формате. Это экономит ресурсы: и дисковое пространство, и время на скачивание, то есть клиенты получают записи быстрее.
А вот для распознавания сжатые записи подходят чуть больше, чем никак. Поэтому приходится делать копии разговоров без сжатия. А к ним — отдельный алгоритм управления окном хранения, что дополнительно накладывает требование по обеспечению сохранности. Мы настроили резервное хранилище, которое защищено от падений и используется как буфер на случай аварии основного.
Сколько вешать в граммах?
Именно этот вопрос из рекламы возник в голове, когда мы стали тестировать алгоритм классификации. Он использует регрессионный анализ для автоматической разметки. Оказалось, что для его качественной работы требуется значительное количество входных данных.
При обучении на выборке из 500 протегированных разговоров точность поднимается выше 80%. Но до значений, близких к 95%, что на текущий момент развития технологий считается приемлемым уровнем, выборка должна быть на порядок больше.
Точность может оказаться больше 80% и на меньшей выборке, но тут уже трудно говорить о достоверности результата. Так как для самотестирования мало данных, и можно ли этому результату доверять — вопрос проверки практикой.
Прекрасно понимая, что 500 разговоров для обучения для некоторых наших клиентов будет собрать непросто, мы не стали ограничивать их количество при настройке системы.
Но это означает, что на малых выборках качество обучения непредсказуемо даже в случае, когда алгоритм самотестирования показывает хороший результат обучения. То есть на малой выборке лишь практическое приложение алгоритма классификации покажет его качество.
А оно (качество автоматической классификации) — это важнейший параметр, который определяет применимость алгоритма на практике. Наши клиенты ожидают, что качество будет близким к 100%. Иначе этот инструмент не может помочь составить достоверный отчет о качестве входящих обращений.
К сожалению, технологии до этого пока не доросли, но мы уверены, что не за горами светлое будущее. Зато при вполне достижимой точности 80–85% инструмент будет полезен для оперативного контроля и устранения проблем.
Например, в среднем в день метка целевой автоматически проставляется для 40~50 звонков. Если вдруг к вечеру едва набирается 30 таких разговоров, это уже повод разобраться, что происходит. Выборочно прослушав вызовы, можно понять: то ли это неаккуратная работа классификатора, то ли реклама приводит не тех клиентов, а может, есть другие причины, скажем конкуренты снизили цены.
Узнав о проблеме, легко принять меры и устранить ее, не дожидаясь критичных последствий. Скажем, поменять скрипт продаж или перенастроить рекламную кампанию, которая стала приводить мусорные звонки.
Если бы мне пришлось делать такой проект снова
Сейчас мы тестируем работу классификатора и готовимся представить его клиентам. А будь у меня похожая задача, я бы посвятил больше времени анализу.
Предложил бы разработчикам пристальнее присматриваться к возможным осложнениям при выборе движка распознавания. Да, конечно, мы получили работающее решение, но оно чужеродно для нашей среды, из-за чего мы много ресурсов потратили, чтобы одолеть Windows сервисы и запустить в нашей обвязке алгоритм распознавания, поборовшись на ходу еще и за доступ к NFS.
Автор: StephanDeshevikh
