Привет! Распознаванием речи (ASR) уже никого не удивишь, но качественное распознавание на разговорном русском языке, а особенно в телефонии — очень сложная штука: люди редко говорят как профессиональные дикторы, часто бывает плохое качество звука с постоянными шумами на фоне и в целом есть миллиарды прочих нюансов. Наша компания занимается голосом больше 8 лет, есть собственные классные модели синтеза, распознавания и продукты на их основе, поэтому экспериментов мы проводим очень много и за появлением новых голосовых моделей следим очень внимательно. 

В свободном доступе уже есть самый узнаваемый Whisper, интересные модели GigaAM от Сбера, не так давно Т-Банк выложил в открытый доступ свою модель T-One — давайте заглянем под капот нашего внутреннего бенчмарка и посмотрим насколько кто хорош.

Поехали!

Робот-оператор и скрипты звонков

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

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

Про «скрипты» и использование в них LLM стоит рассказать чуть детальнее: любой звонок проходит по заранее разработанному эффективному алгоритму (оочень сложному!), в котором необходимо предусмотреть все возможные ветки развития диалога, — и именно это мы и называем скриптом звонка.

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

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

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

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

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

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

Наша стриминговая модель

Наша модель построена на архитектуре Kaldi, от которой мы когда-то сделали форк и начали развивать и обучать ее под свои нужды. У этой архитектуры есть главный плюс — это си плюс плюс (хаха). А если серьезно, то это сверхбыстрая и производительная модель на плюсах, которая не просто позволяет работать в реальном времени и обрабатывать огромные потоки данных, но и делает это на CPU. То есть, она недорогая в техническом содержании, легко скейлится и совсем не требует GPU.

Kaldi включает три ключевых компонента: акустическую модель, языковую модель и лексикон. Акустическая модель распознает звуковые единицы речи (фонемы с учетом контекста), языковая модель (например, n-граммная) предсказывает вероятности слов и их последовательностей, а лексикон определяет фонетические варианты произношения каждого слова. Языковую модель можно дообучать под нужную специфику, а лексикон — редактировать для учета особенностей произношения (например, региональных).

Наш робот на этой модели обрабатывает десятки тысяч звонков на миллионы минут в месяц и работает замечательно, но ASR требует постоянного функционального улучшения и дообучения, так как требования к системам растут, а язык развивается и появляются новые слова (вайб, краш и другие) и аббревиатуры (взять хотя бы «LLM»), что требует глубокого знания нашей архитектуры и обширного зоопарка технологий под всеобщим капотом.

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

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

Требования к бенчмарку

Почти все время существования бенчмарка главным критерием у нас было именно качество распознавания. Признанным стандартом в индустрии являются две метрики — частота ошибок в словах (WER / Word Error Rate) и частота ошибок в символах (CER / Character Error Rate). CER — слишком требовательная метрика и скорее уместна для языков без явных границ у слов (например, для японского), поэтому де-факто стандартом является WER, который мы и используем.

Но когда до прода добрались наши первые эксперименты с LLM под капотом, то стало очевидно, что для end-to-end голосового сервиса критически важным становится производительность. Потому что для e2e упрощенно цепочка выглядит следующим образом:

1) Голосовой канал буферизуется чанками и передается в модель

2) Модель распознает текст (там много эвристик когда заканчивать распознавание)

3) Микросервис робота выбирает ветку скрипта звонка на основе распознанного

3.1) Если в ветке нет LLM, то моментально передается результат на озвучку

3.2) Если LLM есть, то мы обращаемся к ней

3.3) Если обращение к LLM было, то нам нужен жестко запромченный критик (то есть еще один вызов LLM) или другой вид guardrails, чтобы такая система не сгенерировала чего-то крайне ненужного

4) Другой микросервис получает результат, по нему синтезирует голос и подает его обратно в канал

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

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

— Качество: и это просто WER

— Производительность: память/CPU/GPU/время ответа и прочее понятное у такого рода систем

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

WER — довольная стандартная, классная и скучная инженерная метрика, которая хороша академически, но в реальной жизни ее самой по себе мало.

Продуктовые недостатки качества по WER

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

Поэтому очень важно ввести ключевое понятие — домен распознавания. Клиенты и задачи бывают разные и специфика у всех очень разная. С точки зрения продукта это важно: люди звонят, чтобы получить консультацию по их вопросу, хотят забронировать столик или услугу. И потому совершенно неважно, сколько слов распознала модель, если она не распознала слово «тахикардия» при звонке в клинику или заменила «Cherry Tiggo Pro Max» на «Чехия Tiger Pro Labs». А встречается и более сложное, типа ставшей ASR-мемом марки авто Bestune.

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

Содержимое бенчмарка

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

Всего у нас в корзине чуть больше 160 датасетов, есть разбиение на хорошее/плохое качество, длинные/короткие фразы, важность домена для нас и много глубокой специфики (шумы, прерывания, мультиголосность, русский культурный код типа «бамбарбия киргуду» и так далее). В публичной версии сейчас мы отобрали 25 датасетов — наиболее массовых, сбалансированных и выровненных по качеству.

В каждом датасете — от тысячи до десятков тысяч фраз (исходное аудио и эталонная транскрибация к нему), кропотливо обработанных через нашу внутреннюю платформу разметки, что позволяет измеряться с точностью от 0.1% и выше.

Пара примеров детальнее:

Допустим, клиент звонит в шиномонтаж и ему нужно сказать, что у него Porsche. И здесь возможно несколько вариантов произношения: «паршЕ», «пОрш»,  «пОрше» или даже совсем разговорный «поршАк». В таком случае, очень важно тонко настроить лексикон модели, чтобы все варианты были допустимыми.

А как насчет марки Jaecoo? «ДжаЕко», «джакУ», «джейко», «джаэкО», «джАку», «жеко» — вот это вот все и делает хороший ASR очень сложная штукой.

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

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

Но есть и другая ситуация, например, с адресами. Люди очень однозначно и корректно произносят названия своих населенных пунктов — проблемы многовариантности не стоит, но успех распознавания здесь зависит непосредственно от величины словаря модели и веса слова. Здесь очень важна актуальность информации и тонкая подстройка: чтобы «Серёдка» (деревня в Коськовском сельском поселении Тихвинского района Ленинградской области) не превращалась в селёдку, с которой потом непонятно что делать.

Итак, вот более детализированное описание датасета:

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

Претенденты и замеры

С датасетом и методологией — разобрались. Теперь стоит описать самих претендентов. Будем сравнивать две наши закрытые модели (ту, что флагманская в проде и ее подтюненную версию, которая в процессе обучения видела сильно больше разных сложных ФИО) и открытые модели: семейства GigaAM и Whisper, T-One, а также потоковую модель vosk 0.54, построенная на базе фреймворка k2 с архитектурой conformer. 

Про Whisper стоит отдельно сказать несколько слов. Данная модель от OpenAI долгое время в коммьюнити считалась самым популярным стандартом для систем распознавания речи за счет zero-shot и поддержки множества языков, но на русском в боевых условиях телефонии она показывает существенную просадку. Даже тяжелая whisper large-v3 не очень спасает ситуацию. И у виспера есть родовая травма в реакции на сильные шумы, некачественное аудио, музыку и тишину (длинные паузы) — они распознаются как текст, что сваливает модель в галлюцинации. Поэтому в реальных приложениях перед ней надо ставить блок VAD (Voice Activity Detection), что повышает затраты, снижает скорость и надежность системы. 

Про T-one так же честно будет добавить, что это стриминговая модель (что хороший плюс) и то, что она обучалась на схожем с нами датасете — телефонии, поэтому в нашем бенче у нее со старта ожидается преимущество.

А вот и замеры:

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

Напомню, что все модели находились не совсем в равных условиях: мы обучались на нашем датасете телефонии и под наши задачи, поэтому в критически важных для бизнеса доменах наша модель ощутимо лучше открытых — что было ожидаемо, но и было бы странно, если бы было не так. И это хотя и слегка рафинированная, упрощенная, но сбалансированная и показательная часть бенчмарка (25 датасетов из 160). 

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

А общественный главный вывод здесь такой: опенсорсные модели для русского языка — от Сбера и Т-Банка очень хорошо сбалансированы, очень хорошо натренированы на русский язык и близко приближаются к закрытым коммерческим моделям типа нашей. Пока не настолько, чтобы заменить ими свой прод, но эти открытые модели сильны сразу из коробки и качественно обошли как whisper, так и многие наши экспериментальные наработки.

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

Но если это не требуется, русскоязычные open-source-модели можно смело брать и пользоваться — они хороши!

Спасибо!

Этой статьи не получилось бы, если бы не активное участие @sergey_tushev,@Ko4Ai, @bobegи всей команды разработки и продукта робота-оператора, за что им всем — большая благодарность.