Учим робота слушать разговоры

    image

     

    В ручном режиме контролировать все коммуникации — задача трудоемкая и, кроме того, малоэффективная. И мы решили ее автоматизировать. Для этого пришлось обучить нашу Виртуальную АТС новым трюкам. Технологию 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.

    UIS
    27,00
    Телефония для бизнеса
    Поделиться публикацией

    Комментарии 13

      0

      Интересно.
      Для клиентов это как будет выглядеть?
      Будет API какое-то чтобы запись сразу куда-то к себе слать?
      Стоить сколько будет?
      Готов поучаствовать в качестве тестера.

        +1
        Давайте с другого конца зайдем. А вы какую задачу хотите решить? Обещаю в ответ на вопрос показать скриншот и честно изложить все, что мне самому известно на этот момент. :)
          0

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

            0
            Да, интересная задача. Такой вариант использования мы ещё тестировали. Попробуем в ближайшее время на себе, спасибо. :)
              0

              Вот ещё вариант исполнения​: рассылка участникам конференции текста этой конференции. Найти нужную информацию будет на порядок легче, чем прокручивать файл в 30-60 минут.

                0
                Это хорошая мысль, но пока качество распознавания не позволяет давать достоверные расшифровки участникам. Работаем над этим пока.
            0

            Для начала я пытаюсь автоматизировать выдачу заданий в текстовом виде по телефону.
            Т.е. как только в разговоре прозвучало ключевое слово, например, "Задача", сразу создаем задачу и в неё всё до слова "Конец". Ну а там уже на нашей стороне даты распознаем, исполнителя или ещё что-то.

              0
              Именно такую задачу мы в текущей реализации не решаем. Более того, постановка задач же где-то должна делаться? В CRM, например? То есть требуется ещё и интеграция с внешней системой. Мы сами именно эту задачу решать не планируем, однако в следующей версии будет возможность «подписаться» на определенные слова и расшифровку разговора использовать для генерации задачи во внешней системе.
                0

                Вот в следующей версии вроде всё как раз как нам и надо.

          +1
          скрытая реклама црт
            0
            Мне в первую очередь важно было показать, как мы выбирали. А выбирали мы по назначению движков распознавания и особенностям эксплуатации: мы хотели иметь решение in-house, а не отдавать в другое облако. И потребительские свойства «SDK» я выписал честно: SDK по факту не является и платой за «правильное» для нас предназначение является просто ужасающая негибкость и стоимость внедрения.
            0
            Ах-ах-ах, тотальный контрол, гугл вроде тоже логи должен откладывать что в мобильник говорят, а вот, почему-то в поисковике на pc версии гугла такого нет :-/
              0

              Рассматривали ли такие решения, как CMU Sphinx, Kaldi, HTK?

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

              Самое читаемое