Речевые технологии

Ультимативное сравнение систем распознавания речи Ashmanov, Google, Sber, Silero, Tinkoff, Yandex

27.05.2021 16:21:56 |

Автор: admin

sandwich_fake

Какое-то время назад мы писали цикл статей про то, как правильно измерять качество систем распознавания речи, и собственно снимали метрики с доступных решений (цикл статей 1, 2, 3) (на тот момент и коммерческих и некоммерческих решений). На Хабре была выжимка из этого цикла в рамках этой статьи, но до масштабного обновления исследования, достойного публикации на Хабре, руки никак не доходили (это требует как минимум большого количества усилий и подготовки).

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

Добавилось много валидационных сетов из разных реальных доменов;
На рынок вышел Сбер, в первую очередь интересно протестировать именно его;
Для чистоты эксперимента, мы не предупреждали разработчиков систем о доменах и факте проведения тестов;
Мы также попробовали немного протестировать пропускную способность сервисов (понятно, что мы не знаем какое железо и ограничения стоят в облаке);
Мы рассматриваем только коммерческие системы, к которым у нас получилось получить доступ и которые показали хоть какой-то намек на "всеядность", работу с холодного старта и "энтерпрайзность";

Методология

Мы старались следовать нашей стандартной методологии (см. ссылки выше) с небольшими изменениями:

Тестируем одни и те же данные в формате wav (или просто PCM);
Мы слали запросы во все системы в 8 параллельных потоков (если было очень много таймаутов или все было медленно, то снижали);
Расчет скорости делался отдельным небольшим прогоном без всяческой пред- или пост-обработки, чтобы не "загрязнять" метрики, допустим, нормализацией или ресемплингом;
Считаем основную метрику WER. Не пугайтесь высоких показателей в районе 20% WER, нужно понимать что в самой разметке заложено порядка 5% WER и что иногда система получает штраф за неверную форму слова (но корень сохраняется, подробнее писал по ссылке в начале статьи);
По причине большого количества доменов в этот раз на каждый домен случайно выбрали по 1 часу аудио. Стабильные результаты как правило получаются с 2-3 часов аудио (поэтому некоторые метрики могут визуально быть "хуже" прошлых тестов). За тесты в Гугле нам пришлось заплатить почти 500 долларов!;
Метрики считаются на нормализованных текстах (то есть без цифр, "как слышится так и пишется"), так как системы нормализации могут быть разными и строго говоря к качеству распознавания имеют непрямое отношение и зачастую делаются под домен;
Если у системы нет такого функционала, то мы нормализуем тексты самостоятельно. В любом случае это влияет в рамках 1 п.п. WER, мы проверяли;
Сначала мы пробовали слать ogg/opus в системы, которые его поддерживают, но потом отказались от такой идеи, потом что резко вырос процент "пустых" ответов;
Все данные по умолчанию отправляются с родной частотой дискретизации (8 или 16 kHz), но мы не записывали исходную частоту дискретизации всех оригинальных аудио до обработки;

Сухие метрики

Все модели, кроме Silero bleeding egde, это модели упакованные в production сервисы.

Датасет	Ashmanov	Google	Google	Sber	Sber	Silero	Silero new	Tinkoff	Yandex
		default	enhanced	IVR		prod	bleeding edge
Чтение	10	11	10		7	7	6	8	13
Умная колонка	35	24			6	30	27	27	14
Энергосбыт	24	39	41		20	16	11	15	13
Звонки (такси)	47	16	18	22	32	13	12	21	15
Публичные выступления	28	27	24		18	14	12	20	21
Финансы (оператор)	31	37	37	24	33	25	24	23	22
Аэропорт	31	36	37		26	21	22	25	21
Аудио книги	22	60	54		19	24	20	28	22
Радио	24	61	40		26	18	15	27	23
Умная колонка (далеко)	42	49			8	41	27	52	18
Банк	62	30	32	24	28	39	35	28	25
Звонки (e-commerce)	34	45	43	34	45	29	29	31	28
Заседания суда	34	29	29		31	20	20	31	29
Yellow pages	45	43	49		41	32	29	31	30
Финансы (клиент)	43	55	59	41	67	38	37	33	32
YouTube	32	50	41		34	28	25	38	32
Звонки (пранки)	44	72	66		46	41	35	38	35
Медицинские термины	50	37	40		50	35	33	42	38
Диспетчерская	61	68	68		54	41	32	43	42
Стихи, песни и рэп	54	70	60		61	43	41	56	54
Справочная	39	50	53		32	25	20	27

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

	Ashmanov	Google	Google	Sber	Sber	Silero	Tinkoff	Yandex
		default	enhanced	IVR
Чтение	0%	0%	0%	0%		0%	5%	4%
Умная колонка	0%	2%		0%		0%	4%	0%
Энергосбыт	1%	12%	13%	6%		0%	2%	1%
Звонки (такси)	0%	0%	0%	1%	0%	0%	7%	0%
Публичные выступления	0%	1%	0%	0%		0%	2%	0%
Финансы (оператор)	0%	0%	0%	2%	0%	0%	6%	0%
Аэропорт	0%	8%	10%	4%		0%	4%	0%
Аудио книги	0%	22%	6%	2%		0%	1%	0%
Радио	0%	19%	2%	3%		1%	4%	0%
Умная колонка (далеко)	0%	12%		0%		0%	1%	0%
Банк	0%	2%	3%	1%	1%	0%	5%	1%
Звонки (e-commerce)	0%	0%	0%	7%	1%	0%	7%	0%
Заседания суда	0%	0%	0%	1%		0%	4%	0%
Yellow pages	1%	13%	9%	14%		0%	2%	2%
Финансы (клиент)	0%	0%	7%	35%	9%	0%	5%	0%
YouTube	0%	13%	1%	6%		0%	1%	0%
Звонки (пранки)	1%	33%	12%	17%		5%	1%	1%
Медицинские термины	0%	1%	0%	7%		0%	6%	1%
Диспетчерская	3%	26%	28%	25%		0%	2%	4%
Стихи, песни и рэп	2%	19%	3%	25%		0%	1%	1%
Справочная	1%	12%	14%	9%		0%	3%	0%

Качественный анализ и интерпретация метрик

Неудивительно, что каждый силен в том домене, на котором фокусируется. Tinkoff на звонках в банк, справочную, финансовые сервисы. Сбер имеет ультимативно лучшие результаты на своей "умной колонке" (спекулирую, что они поделились в лучшем случае 1/10 своих данных) и в среднем неплохие показатели. IVR модель Сбера на доменах, где оригинальные данные лежат у нас в 8 kHz, показывает себя достойно, но она не ультимативно лучшая. Приятно удивил Яндекс в прошлых рейтингах их модели были не в списке лидеров, а сейчас точно лучше, чем в среднем по больнице. Другой сюрприз Google, который является аутсайдером данного исследования вместе с Ашмановым.

Также интересно посчитать количество доменов, где production модели поставщика лучшие / худшие (допустим с неким "послаблением" в 10% от лучшего или худшего результата):

Сервис	Лучше всех	Хуже всех
Ashmanov	0	7
Google	1	13 (9 у enhanced)
Sber	2	0
Sber IVR	4	4
Silero	13	0
Tinkoff	6	2
Yandex	10	1

Как и ожидалось наша модель показывает в среднем неплохие показатели на всех доменах, заметно отставая на банках и финансах. Также если смотреть по формальной метрике "на каком числе доменов модель лучшая или почти лучшая" то наша модель как минимум лучше всех генерализуется. Если включить в забег нашу bleeding edge модель (мы пока не выкатили ее еще), то она отстает только на "умной колонке" и банковских датасетах, лидируя уже на 17 доменах из 21. Это логично, так как у нас нет своей колонки и банки очень неохотно делятся своими данными даже приватно.

Удобство использования

У Сбера на момент тестирования было только gRPC API. Это не самое удачное решение для SMB клиентов с точки зрения удобства, имеющее более высокий порог на вход. Также в их реализации вообще не прокидываются важные ошибки (или отсутствуют в принципе, чем часто грешат корпоративные сервисы). Документация запрятана внутри портала их экосистемы, но в целом кроме лишней "сложности" проблем особо там нет, читать приятно. 40 страниц на два метода это конечно сильно (мы читали сначала в PDF), но документация хотя бы подробная и с примерами и пояснениями.

У Яндекса и Гугла стандартная корпоративная документация. Она несложная, но иногда длиннее, чем хотелось бы. Есть и обычные и потоковые интерфейсы. У Яндекса кстати она стала сильно приятнее и человечнее с момента, когда я в последний раз ее видел.

У Tinkoff само распознавание работает по умолчанию также через gRPC, а поверх написаны клиенты (в тех, которые мы разбирали было много лишнего). С учетом фокуса на enterprise (оставим за скобками этические, правовые и финансовые последствия монетизации банком ваших данных без явного согласия и возможности отказаться) это имеет больше смысла, чем то, что сделал Сбер. Это уже мои спекуляции, но скорее всего это в первую очередь артефакт разработки решения под свои нужды.

У сервиса Ашманова вообще нет документации, примеры не работают из коробки, пришлось немного позаниматься перебором для запуска. Отдельно отмечу, что обычно b2b сервисы не славятся читаемыми ошибками и читаемой документацией, но тут вообще не было ни ошибок, ни документации. Или 500-я ошибка или 200 с пустым ответом. Это создает легкий когнитивный диссонанс с учетом проработки анимации девушки-маскота, количества маркетинговых материалов и "успешных" кейсов.

ashmanov

У нашего сервиса само публичное АПИ весьма минималистичное и состоит из 2 методов (синтеза и gRPC нет еще в публичной документации) с примерами. Есть также gRPC АПИ, которое сейчас проходит обкатку. Наверное я тут не лучший судья, но основная ценность как мне кажется состоит в радикальной простоте для публичного АПИ и детальных инструкциях / сайзингах / опциях конфигурирования для более крупных клиентов.

Пропускная способность

Все АПИ, которые мы протестировали (кроме Ашманова) показали себя довольно бодро по скорости (это баг или фича решать вам). Для измерения пропускной способности мы считаем показатель секунд аудио в секунду на 1 поток распознавания (RTS = 1 / RTF):

Сервис	RTS per Thread	Threads	Комментарий
Ashmanov	0.2	8
Ashmanov	1.7	1
Google	4.3	8
Google enhanced	2.9	8
Sber	13.6	8
Sber	14.1	1
Silero	2.5	8	4-core, 1080
Silero	3.8	4	4-core, 1080
Silero	6.0	8	12 cores, 2080 Ti
Silero	9.7	1	12 cores, 2080 Ti
Tinkoff	1.4	8
Tinkoff	2.2	1
Yandex	5.5	2	8 много пустых ответов

Поскольку никто не публикует сайзинги облачных и даже иногда коробочных (тут поправьте меня, если пропустил) версий своих систем публично (кстати прошлая версия нашего сайзинга например доступна по ссылке), то довольно сложно оценить адекватность работы систем по ресурсам. Ведь за АПИ может скрываться как одна VDS, так и сотни карт Nvidia Tesla, которыми любят хвастаться корпорации в своих пресс-релизах (что кстати частично подтверждается результатами Сбера пропускная способность там не падает от роста нагрузки совсем). Расчеты выше не являются заменой полноценным сайзингам.

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

Вообще меня очень приятно удивили результаты Сбера. На текущих версиях моделей у нас например сайзинг на 12 ядерном процессоре + GPU рассчитан на ~150 RTS. По идее это означает, что если мы поднимем тестовый и сервис на 12+ ядрах процессора на чуть более новой карточке, мы должны получить результаты более близкие к Сберу. У нас все равно не получается получить такие же высокие показатели без просадки от нагрузки, но какие-то выводы уже можно строить и получается все равно весьма достойно. Снимаем шляпу перед инженерами Сбера и ставим aspirational цель сделать наш сервис еще в 2-3 раза быстрее.

На цене мы останавливаться особо не будем (большая часть серьезных клиентов все равно не использует облако), но в очередной раз неприятный сюрприз преподнес Гугл выставив круглый счет за смешной (как нам кажется) объем. А ответ прост зачастую облачные корпоративные сервисы распознавания имеют не только крутой ценник (и в случае Гугла еще и в долларах), но и неочевидные системы округления вверх. В начале своего пути мы тестировали какой-то сервис из Великобритании который округлял до 60 секунд!

photo_2021-05-27_09-18-04

Небольшая ложка дегтя

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

Подробнее..

Категории: Звук , Искусственный интеллект , Машинное обучение , Google , Голосовые интерфейсы , Распознавание речи , Asr , Yandex , Stt , Sber , Речевые технологии , Silero

Распознавание эмоций в записях телефонных разговоров

21.06.2021 02:14:29 |

Автор: admin

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

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

1) Empath

В 2017 году был основан японский стартап Empath. Он создал платформу Web Empath, основанную на алгоритмах, обученных на десятках тысяч голосовых образцов японской медицинской технологической компании Smartmedical. Недостатком платформы является то, что она анализирует только голос и не пытается распознать речь.

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

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

2) Центр речевых технологий

В составе программного продукта Smart Logger II компании ЦРТ есть модуль речевой аналитики QM Analyzer, позволяющий в автоматическом режиме отслеживать события на телефонной линии, речевую активность дикторов, распознавать речь и анализировать эмоции. Для анализа эмоционального состояния QM Analyzer измеряет физические характеристики речевого сигнала: амплитуда, частотные и временные параметры, ищет ключевые слова и выражения, характеризующие отношение говорящего к теме [2]. При анализе голоса первые несколько секунд система накапливает данные и оценивает, какой тон разговора был нормальным, и далее, отталкиваясь от него, фиксирует изменения тона в положительную или отрицательную сторону [3].

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

3) Neurodata Lab

Компания Neurodata Lab разрабатывает решения, которые охватывают широкий спектр направлений в области исследований эмоций и их распознавания по аудио и видео, в том числе технологии по разделению голосов, послойного анализа и идентификации голоса в аудиопотоке, комплексного трекинга движений тела и рук, а также детекции и распознавания ключевых точек и движений мышц лица в видеопотоке в режиме реального времени. В качестве одного из своих первых проектов команда Neurodata Lab собрала русскоязычную мультимодальную базу данных RAMAS комплексный набор данных об испытываемых эмоциях, включающий параллельную запись 12 каналов: аудио, видео, окулографию, носимые датчики движения и другие о каждой из ситуаций межличностного взаимодействия. В создании базы данных приняли участие актеры, воссоздающие различные ситуации повседневного общения [4].

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

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

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

	Empath	ЦРТ	Neurodata Lab	Разрабатываемый сервис
семантический анализ	-	+	+	+
русский дата-сет	-	нет	+	+
дата-сет спонтанных эмоций	+	нет	-	+

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

Общий алгоритм работы разрабатываемого сервиса выглядит следующим образом.

Блок-схема алгоритма обработки звонка

При реализации были использованы следующие инструменты:

Шумоочистка RNNoise_Wrapper
Диаризация pyAudioAnalysis
Транскрибация vosk-api
Анализ эмоций текста dostoevsky

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

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

Я выбрала пять наиболее часто используемых признаков:

мел-частотные кепстральные коэффициенты (MFCC)
вектор цветности
мел-спектрограмма
спектральный контраст
тональный центроид (Tonnetz)

На основе выделенных из записей телефонных разговоров отрезков я составила 3 варианта дата-сетов с различным количеством выделяемых классов эмоций. Также для сравнения результатов обучения была взята берлинская база эмоциональной речи Emo-DB, созданная с привлечением профессиональных актеров.

Сначала я попробовала обучить простые классификаторы библиотеки scikit-learn:

SVC
RandomForestClassifier
GradientBoostingClassifier
KNeighborsClassifier
MLPClassifier
BaggingClassifier

В результате обучения на дата-сете Emo-DB получилось достичь точности распознавания 79%. Однако при тестировании полученной модели на размеченных мной записях телефонных разговоров, точность оказалась равной всего 23%. Это подтверждает тезисы о том, что при многоязычной классификации и переходе от модельных эмоций к спонтанным точность распознавания значительно снижается.

На составленных мной дата-сетах получилось достичь точности 55%.

База данных	Количество классов	Количество записей	Модель	Точность
Emo-DB	4	408	MLPClassifier	79.268%/22.983%
MCartEmo-admntlf	7	324	KNeighborsClassifier	49.231%
MCartEmo-asnef	5	373	GradientBoostingClassifier	49.333%
MCartEmo-pnn	3	421	BaggingClassifier	55.294%

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

Далее я попробовала обучить сверточную нейронную сеть на дата-сете MCartEmo-pnn. Оптимальной архитектурой оказалась следующая.

Точность распознавания такой сети составила 62.352%.

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

График истории обучения и матрица ошибок полученной CNN

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

Сервис Gateway API производит аутентификацию пользователей по стандарту JSON Web Token и выполнять роль прокси-сервера, направляя запросы к функциональным микросервисам, находящимся в закрытом контуре.

Разработанный сервис был проинтегрирован с Битрикс24. Для этого было создано приложение Аналитика речи. В понятиях Битрикс24 это серверное приложение или приложение второго типа. Такие приложения могут обращаться к REST API Битрикс24, используя протокол OAuth 2.0, а также регистрировать свои обработчики событий. Поэтому достаточно было в сервере добавить роуты для установки приложения (по сути регистрация пользователя), удаления приложения (удаление аккаунта пользователя) и обработчик события OnVoximplantCallEnd, который сохраняет результаты анализа записей в карточках связанных со звонками CRM-сущностей. В качестве результатов приложение добавляет расшифровку записи к звонку и комментарий с оценкой успешности разговора по пятибалльной шкале с прикреплением графика изменения эмоционального состояния по каждому участнику разговора.

Заключение

В работе представлен результат исследования на тему распознавания эмоций в речи, в ходе которой на основе русскоязычных записей телефонных разговоров был создан дата-сет эмоциональной речи, на котором была обучена CNN. Точность распознавания составила 66.66%.
Был реализован веб-сервис, с помощью которого можно выполнять очистку аудиозаписей от шума, диаризацию, транскрибацию и анализ эмоций в аудиозаписи или текстовых сообщениях.
Сервис был доработан, чтобы его также можно было использовать как приложение Битрикс24.

Данная работа выполнялась по заказу компании Эм Си Арт в рамках ВКР бакалавра образовательной программы "Нейротехнологии и программирование" университета ИТМО. Также по этой теме у меня был доклад на X КМУ и была принята на публикацию в "Сборнике трудов Конгресса" статья.

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

Список источников

Давыдов, А. Классификация эмоционального состояния диктора по голосу: проблемы и решения / А. Давыдов, В. Киселёв, Д. Кочетков // Труды международной конференции "Диалог 2011.". 2011. С. 178185.
Smart Logger II. Эволюция систем многоканальной записи. От регистрации вызовов к речевой аналитике [Электронный ресурс]. Режим доступа: http://www.myshared.ru/slide/312083/.
Smart logger-2 не дремлет. Эмоции операторов call-центров и клиентов под контролем [Электронный ресурс]. Режим доступа: https://piter.tv/event/_Smart_logger_2_ne_drem/.
Perepelkina, O. RAMAS: Russian Multimodal Corpus of Dyadic Interaction for Studying Emotion Recognition / O. Perepelkina, E. Kazimirova, M. Konstantinova // PeerJ Preprints 6:e26688v1. 2018.