В целом аббревиатура AMD (Answering Machine Detection) достаточно хорошо знакома всем, кто в той или иной степени работает с автоматизированными исходящими телефонными вызовами. Пользователи различных predictive dialing систем наверняка проводили время пытаясь настроить эту подсистему их платформы или сервиса для получения максимально высоких результатов анализа за минимальное время. Специалисты, работающие с Asterisk PBX и его дефолтным AMD модулем, уж точно в курсе о чем я говорю. Давайте попробуем разобраться в этом вопросе чуть глубже.
Из истории автоответчиков
Интересный факт: технологии, которые были использованы для первых автоответчиков были созданы еще в 19 веке Вальдемаром Поульсеном и Томасом Эдисоном, хоть и полноценное коммерческое применение нашли уже только в 20х годах 20 века.
Одним из интересных изобретений того времени был Ипсофон, разработанный в Германии/Швейцарии в 40х годах. Он проигрывал ранее записанное сообщение, после чего производил запись сообщения звонящего, то есть работал полноценным автоответчиком. Но, что самое интересное, в нем присутствовала возможность прослушать записанные сообщения удаленно, позвонив на свой номер и "введя" кодовую комбинацию. Делалось это следующим образом: после дозвона на Ваш Ипософон в определенный момент запускался алгоритм получения кодовой последовательности, состоявший из проигрывания последовательности цифр от 0 до 10 с паузами между цифрами, в течение которых Вы должны были дважды произнести слово "Привет" после 3х цифр выбранных в качестве секретного кода.
Так что автоответчики, которые мы теперь пытаемся обойти появились уже давным-давно. Подробнее о зарождении автоответчиков можно прочитать здесь.
Существующие методы анализа автоответчиков
На данный момент существует два наиболее распространённых способа определения автоинформаторов:
1. Метод каденции (поиска каденса)
Состоит в сравнении длительностей двух состояний шума/голоса и тишины с шаблонными значениями, задающимися предварительно при настройке модуля.
Одним из примеров такого метода является AMD модуль Asterisk'a. Ниже приведен пример его настроек:
- initialSilence (начальная пауза) — максимальная продолжительность паузы перед приветствием. Если это значение превышено, будет выбран статус "машина".
- greeting (приветствие) — максимальная продолжительность приветствия. Если превышена, будет задано значение "машина".
- afterGreetingSilence (пауза после приветствия) — максимальная пауза после обнаружения приветствия. Если превышена - "машина".
- totalAnalysisTime (общее время анализа) — максимальное время, предоставляемое алгоритму для принятия решения о том, является ли вызываемая сторона человеком или автоответчиком.
- minimumWordLength (минимальная длина слова) — если продолжительность разговора короче, чем minimumWordLength, это не будет считаться речью человека.
- betweenWordsSilence (пауза между словами) — минимальная пауза после слова, чтобы считать следующий аудио сигнал новым словом.
- maximumNumberOfWords (максимальное число слов) — максимальное число слов в приветствии. Если это значение превышено, будет задано значение "машина".
- silenceThreshold (пороговая продолжительность паузы) — чувствительность алгоритма при выявлении паузы.
Преимуществами такого подхода являются простота настройки и реализации, но есть и огромный недостаток - не самая высокая точность.
Даже в рамках одной страны приветственные фразы могут отличаться как разнообразием самих слов, так и банальными особенностями произношения в различных регионах. Так одно значение, неплохо показывающее себя в одной зоне, может быть не применимо в другой. А попытка его увеличить приведёт к прохождению большего числа машин. Не говоря уже о том, что в фоне часто бывают посторонние шумы, которые и вовсе полностью разрушают метод.
В среднем 2-3 звонка из 10, в лучшем случае, будут "машинами" пропущенными к Вашим телефонным агентам. Но это не самая главная проблема. Примерно такое же количество вызовов с человеком на удаленной стороне будут расценены как "машина" и будут автоматически сброшены. Для человека это, как правило, выглядит как вызов с тишиной в течение 2-3 секунд и последующий за ним сброс вызова со стороны звонящего. Знакомая ситуация?
В Великобритании в связи с большим количеством жалоб на ежедневные вызовы с тишиной Ofcom (местный Роскомнадзор) в 2011 году ввел увеличенные штрафы и дополнительные правила обзвона. Вот несколько из них:
1) не более одного вызова со статусом "machine" в день на один и тот же номер, повторные вызовы должны быть с гарантированным соединением с агентом;
2) в течение 72 часов нельзя совершать повторные вызовы на ранее сброшенный номер без гарантии на соединение с агентом;
3) общее количество сброшенных исходящих вызовов не должно превышать 3%.
Прибавьте ко всему вышесказанному FAS calls, в которые входят звонки с "гудками" после Answer, или с шумом выше порогового уровня речи. Все это только усугубляет ситуацию.
Таким образом, мы по сути получаем три проблемы:
- трата времени наших телефонных агентов на обработку вызовов с автоответчиками, которые не приводят к закрытию сделок или привлечению клиентов, или других поставленных Вами задач;
- увеличение негативных отзывов о Вашей исходящей кампании из-за "тихих" звонков;
- необходимость делать большее количество вызовов и, как следствие, увеличение денежных затрат на операторов связи для того, чтобы наши телефонные агенты как можно больше времени находились на звонках с реальными людьми.
2. Метод анализа результата транскрибации
Данный метод базируется на переводе голосового потока в текст и его анализе на предмет наличия ключевых последовательностей слов, позволяющих однозначно определить является ли запись автоинформатором или человеком. Данный метод намного более точен, в сравнении с системами основанными на методе поиска каденса или тона, но в тоже время более сложен в реализации. Точность работы системы такого типа как правило достигает 90-98%.
В данном методе я бы выделил следующие несколько проблем которые требуется решить при разработке:
- наличие датасета на базе которого Вы будете обучать свою языковую модель и формировать словарь ключевых последовательностей. Данный пункт очень важен, так как вариантов автоответчиков/автоинформаторов/голосовых почт бесчисленное множество, и чем больше данных у Вас будет для каждого из языков, которые Вы планируете поддерживать, тем выше будет точность анализа разрабатываемого модуля.
- доставка голосового потока на анализ Вашей языковой модели и последующая проверка в соответствии со словарем. Причем речь идет не только о формировании массива сэмплов оцифрованного сигнала на анализ в реальном времени, но и времени/скорости его обработки локальной или удаленной системой. В случае удаленного сервиса необходимо иметь ввиду задержки в канале связи между точкой получения голосовых данных и точкой анализа. Чем меньше данные задержки будут, тем меньше времени придется находится Вашему клиенту на линии до момента соединения с телефонным агентом.
- стоимость сервиса транскрибации голоса, в случае если вы используете сторонний. Так минимальная стоимость в Yandex speech kit'e для коротких записей менее 15 секунд составляет 15 копеек за анализ, в GCloud'e для движка Speech-To-Text (свыше 60 минут за период) стоимость будет составлять порядка 45 копеек по текущему курсу.
Что было реализовано нами
Функционал:
- На данный момент мы поддерживаем два языка - русский и английский, на собственных обученных языковых моделях.
- LCPM поток с частотой дискретизации в 8 или 16 КГц.
- В зависимости от схемы работы Вашего дайлера возможно определение голосовых почт до подъема трубки, с помощью анализа early media.
- Простая интеграция с Asterisk PBX, состоящая в замене в дайлплане строки запуска дефолтового модуля на наш скомпилированный EAGI скрипт.
- Функционал может быть предоставлен как в виде сервиса, так и в виде on-premise решения, которое будет "крутится", например, в Вашем k8s кластере.
В течение ближайшего месяца мы планируем осуществить запуск сервиса с личным кабинетом и возможностью привязки банковских карт. Средняя стоимость анализа одного звонка будет составлять 10 копеек.
