Синтез речи для наших клиентов стал до 4 раз быстрее. Если раньше у нас было две модели - качественная и большая, то сейчас одна модель - и быстрая и качественная.

Полные сайзинги мы не обновляли, но и простые замеры рассказывают почти всю картину. В шапке таблицы - потоки процессора (1 ядро = 2 потока). При использовании GPU количество потоков процессора предсказуемо почти не влияет на скорость.

1️⃣ Улучшенные модели для AM/LM:

• Cсылка на сравнение;

2️⃣ Ускорение декодера:

• Декодер сам по себе стал быстрее в 3-4 раза;

Как следствие теперь можно поднимать существенно меньше LM консьюмеров, без потери в скорости:

• GPU: 12 LM -> 4 LM;
• CPU: 4 LM -> 1 LM;
• Но поскольку нужно более 1 воркера всё равно, мы не смогли убрать эти воркеры совсем;
• Это должно было повлечь обратно несовместимое изменение всех выданных ключей, но мы пока решили перенести это на СЛЕДУЮЩИЙ РЕЛИЗ КОГДА ВЫДЕТ PYTORCH 2.0;

3️⃣ Параметр АПИ для листов со словарями:

• Добавили dictionary в параметры запроса;
• Слова из dictionary имеют больший приоритет для LM, а значит будут чаще появляться в транскрипте;
• Пример: 'dictionary': json.dumps(['домножить', 'бульцмана']);

4️⃣ Небольшие фиксы логов:

• Лучше читабельность;
• Больше инфы для дебага, добавили chunk_sha1s в основные логи консьюмеров;
• Новый параметр запроса: health_check. С health_check=True логи(кроме rmq) больше не пишутся;

5️⃣ Обновление сайзингов:

• Сайзинги для gRPC;
• С кратно (!) меньшим число LM консьюмеров (!) и без логов примерные приросты скорости на CPU +10%, на GPU до 30%;

6️⃣ Мелочи:

• Баг с ресемплингом из 8к - пока не пофикшен, иногда пока по непонятной причине очень долго ресеплится из 8к в 16к;
• Кривые файлы частично пофиксились;

7️⃣ gRPC:

• Новый VAD - быстрее и точнее для 8КГц;
• Сам по себе VAD стал в 3-4 раза быстрее, но само по себе это мало ощутимо downstream;
• Асинхронность:
•  Cуммарно аудио обрабатывается в ~2 раза быстрее;
•  VAD больше не ждёт транскрипцию, а сразу посылает ответ о наличии речи;
•  Полноценный функционал синхронного gRPC с таймаутами и early requestaми;
•  Больше нет жёсткого порога на количество параллельных сессий;
•  Пофиксили баги v1.6.0 с утечкой памяти;
• Проверка что много коннектов к 1 процессу работает;
• Изменение логики коннектов к gRPC, теперь процессы вместо тредов * процессов, асинк "бесконечный";

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

• Мы не стали опрашивать Google;
• На рынок с распознаванием речи вышли VK и якобы МТС, но нам не удалось продраться через тернии в случае первых и получить ключ с объемами достаточными для исследования, а в случае со вторыми кажется там была форма для лидов, на которую и нам не ответили;
• Опять же добавилось много валидационных сетов из разных реальных доменов;
• Опросы сервисов проводились с октября 2022 года (Яндекс и Тинькофф) по январь 2023 года (Сбер), ниже опишу почему;
• Пропускную способность сервисов в этот раз не тестировали;

Изменения Методологии

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

В общем случае мы постарались дать максимально благоприятные условия для всех сервисов. И в первую очередь в случае Сбера подкручивали параметры запросов, пока точно не убедились, что всё распознается максимально качественно и нет технических ошибок именно в вызове распознавания. В частности проблемы были с "подтеканием" английского языка в русский (туда где точно нет английских слов). Также в отличие от других сервисов пришлось слать аудио с частотой дискретизации 8 и 16 kHz в разные модели.

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

Поскольку методологию описывать заново не будем, постараюсь учесть прошлые ошибки и представить результат максимально сжато и наглядно. Основная метрика - WER (word error rate), выраженный в виде процентов для наглядности:

Краткий анализ

Во-первых, все сервисы сильно подросли по своим метрикам с прошлого раза. Сразу в глаза бросается большое отличие метрик Сбер и Яндекса на датасетах "умной колонки". В принципе логично и предсказуемо. В остальном наблюдается некоторая конвергенция результатов. Местами можно разглядеть некоторые "точки роста" и на каких данных учились модели, но самый большой основной вывод - Сбер сделал свои модели более-менее всеядными. В прошлый раз там был сильно больше разброс по показателям. Но тут можно резонно поиронизировать на тему того, что мы не знаем какие огромные расходы, модели и суперкомпьютеры стоят за этим АПИ. В глаза также бросается то, что в отличие от всех остальных в этот раз Tinkoff не показал существенного роста метрик.

Конвергенция маленьких моделей

Сущестенным также является то, что наша маленькая модель буквально "дышит" в спину большой и что она показала существенный рост и в этот раз, гораздо более заметный, чем рост "большой" модели:

Silero TTS

🎙 Silero - наш синтез в высоком качестве и не только. 📢 @silero_voice_news💬 @silero_voice_chat🚀 boosty.to/silero

Telegram

У бота есть официальный канал с новостями:

Silero Bot News

🎙 @silero_voice_bot 📢 @silero_voice_news 💬 @silero_voice_chat 🚀 boosty.to/silero

Telegram

У этого бота также есть верифицированная страничка на Boosty:

Silero - Нужно больше золота!

Делаем прикольные штуки, связанные с голосовыми технологиями, например нашего бота для синтеза речи @silero_voice_bot. Подписчикам доступен приватный чат в телеграме. У участников чата нет лимитов в боте. Разовые донаты: 10,000 1,000 400 200 Все ресурсы: Бот @siler…

Boosty.toBogdan Lypchak

Никаких других официальных ресурсов в телеграме у нашего бота нет. Любые другие боты, якобы постящие от нашего имени и притворяющиеся нами - это мошенники.

Тут важно сказать, что:

• Записано было около пары часов в микрофон (сейчас мы можем сделать синтез даже по 15 минутам речи);
• Обладатель голоса - не диктор, просто условно случайный сотрудник с яркими артефактами дикции (системный администратор);
• Микрофон был хорошим, но на фоне немного гудел кондиционер;

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

100 реальных аудио человека сравниваются со 100 разными сгенерированными примерами (включая пример с таким же текстом), созданными на основе текстов этих же 100 реальных аудио.

На картинке ниже вы можете увидеть сравнение 100 реальных аудио со 100 сгенерированными аудио и скоры системы (помечено цветом). Зеленым цветом (скор менее 1) помечено, что система считает это одним человеком. Красным - это "разные" люди (скор более 1.1). Желтый - это пограничные значения (скор между 1 и 1.1).

Если взять среднее значение по точке отсечения 1.1, то получается, что в среднем НЕ УДАЛОСЬ обмануть систему где-то в 10% случаев. То есть в 90% случаев систему обмануть удалось.

По общей "матрице" также видно, что "плохие" (или "хорошие", тут как смотреть) примеры сгруппированы. По отзывам заказчика, основные ошибки относились скорее к недостаткам именно системы синтеза V1:

• Нестабильная работа;
• Нестабильность на более длинных аудио и на совсем коротких аудио;
• Система не принимала более 140 символов на вход;

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

Также люди в комментариях к статье на Хабре активно обсуждали, насколько "опасно" клонирование голоса в реальной жизни. Эта короткая заметка должна добавить одну точку к этим наблюдениям.

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

• Снизили размер модели в 2 раза;
• Научили наши модели делать паузы;
• Добавили один высококачественный голос (и бесконечное число случайных);
• Ускорили наши модели где-то примерно в 10 раз (!);
• Упаковали всех спикеров одного языка в одну модель;
• Наши модели теперь могут принимать на вход даже целые абзацы текста;
• Добавили функции контроля скорости и высоты речи через SSML;
• Наш синтез работает сразу в трех частотах дискретизации на выбор — 8, 24 и 48 килогерц;
• Решили детские проблемы наших моделей: нестабильность и пропуск слов, и добавили флаги для контроля ударения;
• Добавили 20 языков и более 170 голосов;

Наша система синтеза живет внутри нашего проекта Silero Models тут и мы написали про нее отличные и подробные посты, которые вновь стали очень популярными на Хабре:

Теперь наш публичный синтез в супер-высоком качестве, в 10 раз быстрее и без детских болячек

В нашей прошлой статье про синтез речи мы дали много обещаний: убрать детские болячки, радикально ускорить синтез еще в 10 раз, добавить новые "фишечки", радикально улучшить качество....

HabrAlexander Veysov

Теперь наш синтез на 20 языках

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

HabrAlexander Veysov

Сейчас проще всего послушать наш синтез можно:

• Через колаб - Google Colaboratory;
• Можно послушать многочисленные примеры в самих статьях;
• В ближайшее время подъедет бот в Телеграме;

Следите за нашими релизами:

• На Хабре - https://habr.com/ru/users/snakers4/posts/;
• На канале с нашими новостями - https://t.me/silero_news;

📦 Релиз Enterprise Дистрибутивов v1.4.4

Начиная с внутренней версии 1.4.1 мы активно обкатывали свои дистрибутивы на своих внутренних продуктах (телеграм-бот и сервис для распознавания аудио) и вместе с нашими партнерами.

Просуммируем что мы добавили с точки зрения пакетирования во время промежуточных релизов с 1.4.1 по 1.4.4.

Общее:

• Добавлена поддержка работы с 2 LM для других языков;
• Добавлена возможности работы с другими языками;
• Старые лиц. файлы и дистрибутивы совместимы с новыми образами;

gRPC:

• Масштабный релиз нашего VAD-а, он теперь встроен и в gRPC АПИ;
• Добавлена модель расстановки знаков препинания и пунктуации (te-model);
• Дальнейшие фиксы проблем VAD-а в начале и конце сессии ("спасибо", лишняя обрезка, повышена точность определения границ речи);
• Существенно снижено потребление ресурсов VAD-ом, убраны разные его разновидности, на порядок снижено количество кода для вызова непосредственно самого VAD-а;
• Рефакторинг и существенное упрощение логики работы VAD-а;
• Масштабная переработка параметров VAD-а, добавлена возможности указывать их не только при старте сервиса, но и в каждой gRPC сессии;
• Добавлена поддержка SSL в gRPC API без возни с сертификатами;
• Возможность изменять адрес api консюмера в gRPC через .env переменные: API_NAME - по умолчанию, 'api', API_PORT - по умолчанию, '5000';
• Нагрузочное тестирование gRPC на длинных файлах на больших объемах при стресс тестах, блуждающие ошибки самого gRPC локализованы и устранены, утечки памяти найдены и устранены;
• Нашли и пофиксили в gRPC критичный баг, который при одновременном прогоне нескольких длинных файлов иногда приводил к странным ошибкам и падению всего контейнера;

Основное API:

• Для te-model вынесен отдельный эндпоинт в основное АПИ;
• Фикс тупого бага в диаризации;

TTS:

• Новое обязательное поле в запросе в /voice метод - sample_rate;
• Добавили TTS-only compose file;
• Обновили доку;
• Финишная прямая перед масштабным релизом синтеза;

💎 Релиз новых моделей V15

Изначально планировалось, что релизы дистрибутивов и моделей будут иметь одну мажорную версию, но они разошлись (мы пропустили одну версию, в будущем синхронизируемся, потому что будем сильно менять наши модели, и это займет время).

Обновление от 07.04.2022 - сделали ручную переразметку "новых" валидационных сетов.

Основные моменты:

• В среднем качество растет;
• На звонках качество существенно растет;
• Появились новые валидационные датасеты (еще предстоит их немного почистить и переразметить, реальные метрики скорее всего на ~5 пп лучше);
• На такси скорее всего мы уперлись в лимиты нашего пост-процессинга (акустическая модель в этот раз была заметно лучше), нам предстоит большая работа именно над пост-процессингом в принципе;

Мы видели разные маркетинговые материалы на тему точности определения спикеров / идентификации / аутентификации спикеров. Как правило это или довольно непонятные академические метрики на идеализированных модельных данных или метрики вроде 99.999% для text-dependent систем (надо говорить одно и то же слово).

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

Данные

Чтобы лишний раз не заниматься ручной разметкой для диаризации, данные мы взяли следующие:

1. Один часовой диалог между 3 спикерами, аудио есть как смешанное, так и поканальное. Также отдельно есть по дополнительному часу речи на каждого из спикеров (видимо из другого диалога);
2. Один часовой диалог между 7 спикерами, аудио есть как смешанное, так и поканальное (на самом деле это собранные вместе 2 встречи, так как на одной из них было мало спикеров);
3. Длины смешанных и одноканальных аудио идеально совпадают.

Разметка

Имея такие данные, можно несложным алгоритмом понять точно, где говорят конкретные люди:

1. Нарезаем каждое одноканальное аудио на высказывания конкретного спикера;
2. Убираем тишину и кусочки речи, короче чем одна секунда;
3. Запоминаем когда кто говорил и применяем  эту нарезку к смешанному аудио;
4. Далее разделяем высказывания одного спикера на "тренировочную" и "валидационную" выборки;
5. Голосовые слепки для конкретного спикера считаются на основе "тренировочной" выборки, как на смешанном аудио, так и на одноканальных аудио. Получается соответствие 1 спикер - 1 голосовой слепок;
6. Голосовые слепки на валидационной выборке могут считаться как на том же аудио, так и на другом, если оно есть;
7. Валидационная выборка сильно больше тренировочной (вопреки обычной ситуации);

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

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

Результаты на 7 спикерах

На аудио с 7 спикерами у нас было по сути одно аудио. Поэтому мы смогли только проверить только влияние того, как мы считаем голосовой слепок - по смешанным или одноканальным аудио (разницы не было). Результаты получились следующие:

На графике:

• Отрицательные "классы" - это кусочки, которые использовались для расчета голосового слепка на тренировочной выборке;
• Положительные "классы" - это уже валидационная выборка;
• Хорошо видно, что один спикер использовал два разных устройства;

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

Результаты на 3 спикерах

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

"Тренируемся" на том же диалоге на смешанном аудио

Тут результат аналогичный.

"Тренируемся" на том же диалоге но на одноканальных аудио

Результат тоже очень похожий.

"Тренируемся" на другой речи этого спикера (дополнительный час аудио)

Тут уже видно, что для спикеров 1 и 2 ситуация похожа на прошлые эксперименты, а вот у спикера 3 (на графике 3 и -3) уже сильно отличаются микрофоны.

"Тренируемся" на всей речи этого спикера из дополнительного часа аудио

Сейчас в список наших основных поддерживаемых решений входят:

• Программный модуль "СИЛЕРО" для синтеза речи на русском языке и сопутствующих задач на основе нейронных сетей и алгоритмов машинного обучения (ссылка, Реестровая запись №15935);
• "Программный модуль "СИЛЕРО" для распознавания речи и сопутствующих задач на основе нейронных сетей и алгоритмов машинного обучения" (ссылка, Реестровая запись №10106);

Для получения коммерческого предложения по лицензированию нужно отправить письмо на электронную почту hello@silero.ai с указанием:

• Названия вашего юрлица;
• Предполагаемого сценария использования;
• Какой-либо оценки по масштабу использования для примерного расчета сайзингов для коммерческого предложения;

Обновление от 2022-10-11

Публичная версия документации программного модуля Силеро для синтеза речи на русском языке доступна по ссылке. Она содержит информацию про:

• Описание функциональных характеристик;
• Информацию для установки и эксплуатации ПО;

Сайзинги

Актуальные сайзинги для наших дистрибутивов на базе Ubuntu и Astra Linux, версия 1.5.4. За этот период произошло радикальное ускорение синтеза речи и увеличение его качества.

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

Распознавание речи, CPU

Intel(R) Core(TM) i7-6800K CPU @ 3.40GHz

v1.5.4:

v1.5.4_astra:

Сайзинги на astra почти не отличаются и приведены для справки.

Распознавание речи, GPU

v1.5.4:

1080Ti:

3090:

Время ответа в секундах в зависимости от числа поднятых AM-консьюмеров и количества параллельных потоков (workers), отправляющих запросы с аудио в API.

• Яркая палитра - среднее время ответа;
• Тёмная палитра - 95 перцентиль;
• Светлая палитра - 99 перцентиль;

1/RTF - Количество секунд распознанного аудио за 1 секунду работы - в зависимости от числа поднятых AM-консьюмеров и количества параллельных потоков(workers), отправляющих запросы с аудио в API.

Синтез речи, CPU

Intel(R) Core(TM) i7-6800K CPU @ 3.40GHz

v1.5.4

v1.5.4_astra

Сайзинги на astra почти не отличаются и приведены для справки.

Синтез речи, GPU

v1.5.4

1080Ti SR=8000 Hz

1080Ti SR=24000 Hz

1080Ti SR=48000 Hz

3090 SR=8000Hz

3090 SR=24000Hz

3090  SR=48000Hz

Время ответа в секундах в зависимости от числа поднятых TTS консьюмеров и количества параллельных потоков(workers), отправляющих запросы с текстом в API.

• Яркая палитра - среднее время ответа;
• Тёмная палитра - 95 перцентиль;
• Светлая палитра - 99 перцентиль;

Количество секунд синтезируемого аудио за 1 секунду работы - в зависимости от числа поднятых TTS консьюмеров и количества параллельных потоков(workers), отправляющих запросы с текстом в API.

(*)

В целом подходят любые GPU Nvidia начиная с архитектуры Pascal, в  частности:

• Любые игровые GPU Nvidia выше чем 1070 8+GB RAM с турбиной;
• Любые однослотовые GPU Nvidia серии Quadro 8+GB RAM (TDP 100 - 150W) с турбиной или пассивные;
• Nvidia Tesla T4, пассивная, TDP 75W;
• Любые карты лучше / мощнее;

Обновление от 2021-11-18

Сейчас в список наших основных поддерживаемых решений входят:

• Распознавание речи;
• Синтез речи;
• Детектор голоса и расстановка пунктуации и знаков препинания являются вспомогательными;

Дальше мы приведем сайзинги для GPU и CPU версии нашего распознавания и синтеза речи для недавнего масштабного релиза наших дистрибутивов v012:

• GPU сайзинг для распознавания речи;
• GPU сайзинг для синтеза речи;
• СPU сайзинг для распознавания речи;
• CPU сайзинг для синтеза речи;

GPU сайзинг для распознавания речи

1080 Ti

3090

GPU сайзинг для синтеза речи

СPU сайзинг для распознавания речи

Intel(R) Core(TM) i7-6800K CPU @ 3.40GHz:

CPU сайзинг для синтеза речи

Intel(R) Core(TM) i7-6800K CPU @ 3.40GHz:

Оригинальная Статья от 2020-12-05

Какое-то время назад мы публиковали целый ряд статей про нашу систему Speech-To-Text, а именно про:

• Её качество;
• Её скорость и пропускную способность;
• Про требования к ресурсам;

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

Чем Мы Занимались Все Это Время

Может показаться, что мы ушли в подполье, но с тех пор многое изменилось и мы не сидели без дела:

• Мы выпустили публичную Community Edition версию наших моделей для нескольких языков. Нас даже похвалил Soumith Chintala;
• Cделали несколько глобальных рефакторингов кода, выпустили V2 версию нашей CE-edition модели для английского языка;
• Публично выпустили экспериментальную модель для украинского языка в рамках Silero Models для мотивации наших украинских коллег;
• Запустили несколько больших research-проектов и провели большую подготовительную работу для обширного обновления перезапуска (как говорится, stay tuned!). Будем выпускать новые публичные продукты when it's done;

Финальное Ускорение Наших Моделей

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

Метрики указаны в секундах аудио обработанных в секунду на 1 ядро процессора (1 / RTF на ядро):

Может показаться, что скачок является слишком огромным, но мы просто не сидели без дела. Тут еще важно отметить, что цифры отчасти кажутся нереалистичными в сравнении с теми же 8+ RTS, о которых писал фейсбук в своей статье. Но тут важно понимать, что мы обрабатываем аудио батчами, а фейсбук - по одному кусочками по 750 ms. Плюс это идеальные условия, когда файлы по сути кормятся в акустическую сеть из памяти. В реальности все не так радужно (смотрите сайзинги ниже) и мы тратим гораздо больше времени на ожидание и коммуникацию.

Ускорения против базовой "маленькой модели":

Сайзинги и Дистрибутивы

Метрики акустической модели являются несколько абстрактными. В реальном деплое на скорость и пропускную способность (latency / throughput) влияет гораздо больше вещей - пост-обработка, архитектура сервиса, задержка сети, сериализация, коммуникация, итд итп.

По этой причине - мы просто провели огромную работу по расчету реальных сайзингов наших EE моделей и оптимизации гипер-параметров наших дистрибутивов.

Пара слов о методологии:

• Метрики рассчитаны для файлов длиной 1 - 7 секунд, которые "кормятся" в сервис в 4 - 8 - 16 потоков;
• Распределение длин файлов соответствует распределению длин файлов в реальных диалогах людей по телефону;
• Метрики рассчитаны для многопоточного веб-сервиса, что немного абстрагируется от сценария реального использования. Ну то есть если мы можем держать условно 8 потоков с условной гарантией в latency в 500 мс, то это значит, что правильно настроив конечную бизнес-логику, можно обрабатывать сильно больше, чем 8 одновременных звонков;
• Реальные люди не говорят одновременно, пока человек заканчивает вторую фразу мы уже усеваем обработать первую итд итп. Но это уже сильно зависит от реального бизнес-кейса;

Настройка Сайзинга Для GPU

(*) Есть 3 типа подходящих GPU:

• Любые игровые GPU Nvidia выше чем 1070 8+GB RAM с турбиной;
• Любые однослотовые GPU Nvidia серии Quadro 8+GB RAM (TDP 100 - 150W) с турбиной или пассивные;
• Nvidia Tesla T4, пассивная, TDP 75W;

Настройка Сайзинга Для CPU

Комментарии по Сайзингам

• В реальности со всем фаршем даже у сервиса с GPU получается только 10 - 15 RTS на одно ядро процессора (хотя теоретический RTS самой модели на GPU находится где-то в районе 500 - 1,000). В теории число воркеров CPU на 1 GPU можно наращивать больше, чем мы пробовали, но мы упираемся в удорожание процессоров;
• CPU-версия сервиса показывает только в районе 5 честных RTS, что немало, но она скорее оптимизирована как баланс между гарантиями по latency и throughput;
• Метрики настоящие и честные и подбор параметров стоил много боли и страданий. Если честно - я вообще не видел, чтобы кто-то вообще показывал перцентили реальных систем;
• Многие крупные проекты просят 50 одновременных разговоров, поэтому иметь возможность покрыть такой проект используя всего 2 GPU (+ резервирование) это довольно круто;
• Использование GPU сервиса где-то в 2-3 раза дешевле, чем если считать все только на CPU;

Бесплатное распознавание речи для всех желающих

После относительно недавнего релиза мы сделали наше распознавание речи бесплатным для всех индивидуальных пользователей на страничке по адресу — https://audio-v-text.silero.ai/.

Да, вы не ослышались. Это не шутка, не очередная кампания по продаже "шпионских" гаджетов, не альтруизм и не обман:

• Да, сервис сделан для простых людей, и там есть разумные ограничения на объем, перепродавать не получится (а если у кого-то получится, то нам придется или закрутить все сильнее, или закрыть сервис).
• Да, мы предприняли разумные меры, чтобы сделать все безопасным как для нас, так и для пользователей.
• Да, этот сервис будет бесплатным.
• Да, мы полностью независимы и никак не аффилированы с теми самыми компаниями (если вы понимаете, о чем я).

Как Пользоваться

Инструкция простая до банальности:

• зайти на страничку,
• опционально попробовать демку с микрофоном,
• залить свой файл в формочку,
• получить распозанный файл на email.

По идее должно работать во всех основных браузерах. Рекомендуется заходить с ноутбука или десктопа, но и со смартфона в принципе тоже должно работать.

Не лишним будет упомянуть: правильно указывая, из какого домена (какого типа) ваше аудио, вы поможете повысить качество распознавания вашего аудио.

Идея Сервиса

Если сейчас обычному физическому лицу нужно что-то транскрибировать, то на рынке есть опции:

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

Резюмируя: нет качественных решений для "маленьких"/одноразовых случаев использования (без геморроя и высокого порога входа). Мы решили это исправить. Будем признательны за вашу конструктивную обратную связь.

Текущие Ограничения

У сервиса в текущем виде есть ряд ограничений, часть которых решается технологически, а часть только процессуально:

• Хотя мы можем разделять заранее известное количество говорящих, это не вошло в MVP сервиса.
• Многоканальное аудио в MVP не разделяется и обрабатывается после усреднения каналов.
• Наличие большого количества жаргона, англицизмов или очень редкой уникальной лексики негативно влияет на распознавание. Конечно это решается, но скорее уже в рамках отдельного проекта или с помощью ручной пост-обработки.
• Чем лучше качество исходного аудио, тем лучше качество транскрибации.
• На данный момент пунктуация и заглавные буквы автоматически в сервисе не проставляются, хотя мы в это умеем.
• Для некоторых случаев, даже при хорошем качестве аудио и с учетом автоматической простановки знаков препинания, нужна пост-обработка людьми. Мы пока не предлагаем такой сервис.

Безопасность и Использование Данных

Мы используем лучшие из доступных нам инструментов. Мы шифруем трафик и данные. Мы блокируем ботов и пресекаем нецелевое использование.

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

Основные моменты:

• Фокус на повышении качества реальных звонков, немного боковой тренд на старых доменах;
• Стабильный прирост метрик в среднем для xlarge модели;
• (!) Огромный прирост метрик для small и small_q моделей (!). По сути малые компактные модели (для CPU) совсем недалеко теперь от больших;

Сопутствующие ожидаемые релизы:

• Кардинальное улучшение качества и простоты использования silero-vad, вероятно также добавление 95 языков в данные для VAD;
• Релиз дистрибутивов для v013;
• Выход gRPC клиента из затянувшегося бета-теста;

GitHub - snakers4/silero-vad: Silero VAD: pre-trained enterprise-grade Voice Activity and Number Detector

Silero VAD: pre-trained enterprise-grade Voice Activity and Number Detector - GitHub - snakers4/silero-vad: Silero VAD: pre-trained enterprise-grade Voice Activity and Number Detector

GitHubsnakers4

На данный момент у нас есть ряд вспомогательных моделей, которые умеют:

• Определять наличие речи в аудио (Voice Activity Detector, VAD);
• Определять наличие сказанных числительных в речи (Number Detector);
• Определять на каком языке и языковой группе что-то было сказано (Language Classifier);

Все модели живут и обновляются в репозитории silero-models. Там же находятся примеры, документация по настройке гипер-параметров и базовый код для применения моделей на практике.

VAD

Самая популярная и часто обновляемая модель. Определяет наличие речи в аудио, а также ее начало и конец.

Существует в ряде вариаций:

• Большая (1M параметров) и малые модели (10 - 100k параметров);
• Модель для частоты дискретизации в 16 kHz и 8 kHz;
• Также для некоторых моделей чекпойнты сконвертированы в ONNX;

Популярные страницы:

• Метрики и скорость;
• Тонкая настройка параметров;
• Механизм работы;

Также многочисленные примеры можно найти в списке примеров в ноутбуке:

Google Colaboratory

... и в папке с примерами:

silero-vad/examples at master · snakers4/silero-vad

Silero VAD: pre-trained enterprise-grade Voice Activity and Number Detector - silero-vad/examples at master · snakers4/silero-vad

GitHubsnakers4

Language Classifier

На данный момент лучший классификатор языков:

• Поддерживает 95 языков (85% точности) и 58 языковых групп (90% точности);
• Взаимопонятные языки объединены в группы (например Сербский + Хорватский + Боснийский);
• Натренирован примерно на 20k часов аудио (10к из которых принадлежат к 5 самым популярным языкам);
• Данные взяты из максимально разных источников, это не просто оверфит на один публичный датасет;
• Довольно компактная сетка в 4.7M параметров;

GitHub - snakers4/silero-vad: Silero VAD: pre-trained enterprise-grade Voice Activity and Number Detector

Silero VAD: pre-trained enterprise-grade Voice Activity and Number Detector - GitHub - snakers4/silero-vad: Silero VAD: pre-trained enterprise-grade Voice Activity and Number Detector

GitHubsnakers4

Number Detector

Детектор чисел ищет устно сказанные числа на 4 языках:

GitHub - snakers4/silero-vad: Silero VAD: pre-trained enterprise-grade Voice Activity and Number Detector

Silero VAD: pre-trained enterprise-grade Voice Activity and Number Detector - GitHub - snakers4/silero-vad: Silero VAD: pre-trained enterprise-grade Voice Activity and Number Detector

GitHubsnakers4

Полную версию статьи-релиза вы можете прочитать здесь. Сама модель живет тут:

GitHub - snakers4/silero-models: Silero Models: pre-trained speech-to-text, text-to-speech and text-enhancement models made embarrassingly simple

Silero Models: pre-trained speech-to-text, text-to-speech and text-enhancement models made embarrassingly simple - GitHub - snakers4/silero-models: Silero Models: pre-trained speech-to-text, text-t...

GitHubsnakers4

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

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

По этой причине мы бы хотели поделиться с сообществом системой, которая:

• Расставляет заглавные буквы и основные знаки препинания (точка, запятая, дефис, вопросительный знак, восклицательный знак, тире для русского языка);
• Работает на 4 языках (русский, английский, немецкий, испанский);
• По построению должна работать максимально абстрактно на любом тексте и не основана на каких-то фиксированных правилах;
• Имеет минимальные нетривиальные метрики и выполняет задачу улучшения читабельности текста;

На всякий случай явно повторюсь — цель такой системы — лишь улучшать читабельность текста. Она не добавляет в текст информации, которой в нем изначально не было.

Как Попробовать

Модель выложена в репозитории проекта silero-models и, соответственно, будет поддерживаться, как и прочие наши решения оттуда. А вот простой запуск модели (с более подробными примерами можно ознакомиться в colab):

import torch

model, example_texts, languages, punct, apply_te = torch.hub.load(repo_or_dir='snakers4/silero-models', model='silero_te')

input_text = input('Enter input text\n')
apply_te(input_text, lan='en')

GitHub - snakers4/silero-models: Silero Models: pre-trained speech-to-text, text-to-speech and text-enhancement models made embarrassingly simple

Silero Models: pre-trained speech-to-text, text-to-speech and text-enhancement models made embarrassingly simple - GitHub - snakers4/silero-models: Silero Models: pre-trained speech-to-text, text-t...

GitHubsnakers4

Google Colaboratory

Ограничения

У данной работы есть ряд ограничений и очевидных вещей, которые мы решили пока не делать (так сказать нужно же было где-то поставить точку):

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

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

На самом деле наша система синтеза живет внутри нашего проекта Silero Models тут и мы написали про нее отличный и подробный пост, который стал очень популярным на Хабре:

Мы Опубликовали Качественный, Простой, Доступный и Быстрый Синтез Речи

Вокруг темы синтеза речи сейчас много движения: на рынке есть огромное число тулкитов для синтеза, большое число закрытых коммерческих решений за АПИ (как на со...

HabrAlexander Veysov

Сейчас проще всего послушать наш синтез можно:

• Через колаб - Google Colaboratory

Мы уже готовим следующий релиз, который сделает наш синтез еще лучше.

Следите за нашими релизами:

• На Хабре - https://habr.com/ru/users/snakers4/posts/
• На канале с нашими новостями - https://t.me/silero_news

Какое-то время назад мы писали цикл статей про то, как правильно измерять качество систем распознавания речи, и собственно снимали метрики с доступных решений (цикл статей — 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 сервисы. Используемый показатель — WER (для простоты восприятия можно мысленно пририсовать знак процента или считать WER процентом ошибок в словах).

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Обновления / ошибки

Я перепутал, второй раз мы тестировали пропускную способность нашего сервиса на 1080 Ti, а не 2080 Ti. Это важно, так как между поколениями сильнее меняется скорость карточек.

Именно в Яндекс мы слали данные в формате opus. Мы потестили немного, вроде именно у Яндекса особой разницы между wav и opus нет.

Оригинальная версия данной статьи была опубликована на Хабре тут. Это копия статья на всякий случай и для полноты истории.