SpeechJudge: Towards Human-Level Judgment for Speech Naturalness

TTS-модели становятся всё лучше, но как это измерить? Стандарт в речевой индустрии — субъективная оценка MOS. Автоматические метрики удобны, но плохо коррелируют с тем, что реально слышит человек. Сегодня разберём работу, которая стала первой серьёзной попыткой закрыть пробел в оценке естественности речи с помощью LLM-as-a-judge.

Авторы представляют три сущности:

- SpeechJudge-Data. Большой аннотированный датасет для обучения — 99K сэмплов.
- SpeechJudge-Eval. Бенчмарк для оценки естественности речи, в который вошли сэмплы из SpeechJudge-Data.
- SpeechJudge-GRM. Генеративная reward-модель: получает на вход пару аудио, выбирает более естественное и объясняет свой вердикт.

Начнём с того, как собирали SpeechJudge-Data. Датасет состоит из триплетов (текст + аудио-1 + аудио-2). Для генерации аудио авторы взяли SoTA-модели трёх разных парадигм: авторегрессию (CosyVoice2), flow-matching (F5-TTS) и маскированную генерацию (MaskGCT). TTS-модель генерировала аудио-1 и аудио-2 на основе текста и аудиореференса.

Сами аудиореференсы собирали двух типов: простые regular из датасета Emilia-Large и expressive с проявлением эмоций из Paraspeech, L2-Arctic, KeSpeech и даже Genshin Impact. Языки тоже варьировали: китайский, английский и code-switching.

Полученный датасет аннотировали вручную: оценивали разборчивость речи и её естественность.

Из собранного корпуса авторы выделили SpeechJudge-Eval — 1000 сэмплов, где разметчики пришли к полному согласию с однозначным предпочтением одного из аудио. Затем на новом датасете проверили целый зоопарк моделей: WER, FAD, MOS-предикторы, deepfake-детекторы и AudioLLM. Результаты оказались удручающими — лучшая модель из коробки, Gemini-2.5-Flash, набрала лишь 69,1% совпадения с человеческими оценками. Большинство метрик и вовсе работают на уровне случайного угадывания.

Для решения этой проблемы авторы обучили свою модель SpeechJudge-GRM. В качестве основы взяли Qwen2.5-Omni-7B. Модель тренировали в два этапа:

1) SFT — дистилляция CoT-рассуждений от Gemini-2.5-Flash на тех сэмплах, где Gemini угадывала правильно.
2) RL (GRPO) — дообучение на сложных сэмплах, где Gemini ошибалась; человеческая аннотация служит верифицируемой наградой.

Получилось 77,2% точности против 72,7% у классической модели Брэдли–Терри. При majority voting из 10 результатов точность вырастает до 79,4%. Авторы также использовали GRM как reward-функцию для post-training TTS-моделей, что улучшило метрики разборчивости и естественности. Кажется, мы на шаг ближе к тому, чтобы обходиться без субъективной разметки, когда нужно сравнивать модели синтеза речи.

Владимир Гогорян ❣ Специально для Speech Info

Qwen3-TTS Technical Report [1/2]

Команда Alibaba представила Qwen3-TTS — семейство моделей для синтеза речи, которым под силу voice cloning и voice design по текстовому описанию, а также fine-grained control голоса. Сегодня разберём, как они устроены с точки зрения архитектуры, а в следующем посте подробнее остановимся на их обучении.

Все модели работают на дискретных токенах с авторегрессионной LLM. Но в Qwen3-TTS авторы делают не один токенайзер, а сразу два.

На схеме слева — Qwen-TTS-Tokenizer-25Hz. Подход похож на CosyVoice: это 25 Гц single-codebook-токенайзер, построенный поверх Qwen-2-Audio. Его обучают в два этапа. Сначала продолжают претрейн Qwen2-Audio на ASR-задаче и вставляют VQ-слой, чтобы получить семантические токены. Затем добавляют свёрточный декодер и дообучают модель на восстановление мел-спектрограмм, чтобы подмешать акустическую информацию. Видимо, чисто семантических токенов не всегда хватает для выразительного TTS. На полученных токенах обучают стриминговый блочный DiT с flow-matching, чтобы предсказывать мел-спектрограмму. Для восстановления аудио используют модифицированный BigVGAN.

На схеме справа — Qwen-TTS-Tokenizer-12Hz. Это уже 12,5 Гц токенайзер со Split-VQ и суммарно 16 уровнями квантизации. Первый его кодбук отвечает за семантику, остальные 15 — добавляют акустические детали через RVQ. Есть дистилляция в семантический кодбук эмбеддингов WavLM. Подход сильно вдохновлён Mimi, но Qwen переделали декодер, где использовали ConvNeXt-блоки и Snake-активации.

Архитектурно Qwen3-TTS базируется на семействе Qwen3 LM. Входная последовательность конкатенирует текстовые и речевые токены по channel axis. Для контроля спикера используется обучаемый speaker-encoder.

Для кодека с 12 Гц основной backbone transformer предсказывает нулевой семантический codebook, а затем MTP-модуль достраивает оставшиеся уровни с акустическими деталями. Для 25 Гц версии используется стандартный AR-трансформер, предсказанные токены которого декодирует DiT.

Владимир Гогорян ❣ Специально для Speech Info

Qwen3-TTS Technical Report [2/2]

Продолжаем обсуждать новинку от команды Alibaba. В предыдущем посте разобрали архитектуру Qwen3-TTS, в этом рассмотрим, как и на чём его обучали.

Для обучения используют сначала 5M+ часов многоязычной речи, затем continual pretraining на более качественных данных, чтобы снизить галлюцинации и улучшить качество, затем long-context stage, где увеличивают контекст с 8K до 32K токенов и апсэмплят длинные аудио.

Post-training состоит из трёх этапов: DPO на human preference pairs, затем GSPO с rule-based rewards для стабильности, затем lightweight speaker fine-tuning под конкретные голоса. Для voice design авторы добавляют probabilistically activated thinking pattern – модель иногда учится «думать» над сложным описанием голоса, чтобы лучше следовать инструкциям.

На zero-shot voice cloning Qwen3-TTS-12Hz-1.7B показывает WER = 0,77 на китайском и 1,24 на английском Seed-TTS test set. Это сильнее большинства бейзлайнов, включая F5-TTS, FireRedTTS 2, MiniMax-Speech и CosyVoice 3 на английском. Интересно, что 12Hz здесь стабильно лучше 25Hz по WER, судя по всему, более грубое временное разрешение упрощает авторегрессионную генерацию.

В multilingual speech generation модель поддерживает 10 языков. По WER она выигрывает у MiniMax и ElevenLabs в 6 из 10 языков, включая русский. По speaker similarity Qwen3-TTS побеждает во всех 10 языках.

В cross-lingual voice cloning тоже достойные результаты. Например, в zh-to-ko 12Hz-1.7B получает error rate = 4,82 против 14,4 у CosyVoice3.

На InstructTTSEval модель в режиме voice design становится лучшей среди опенсорс-решений и обходит Hume, VoiceSculptor, Parler-TTS и PromptTTS по метрикам соответствия описанию. В target speaker editing Qwen3-TTS сильно обгоняет GPT-4o-mini-tts, хотя Gemini всё ещё остаётся чемпионом.

Самый интересный результат — long speech generation. На текстах до 2000 слов и аудио больше 10 минут выигрывает уже версия 25 Гц: Qwen3-TTS-25Hz-1.7B-CustomVoice получает WER = 1,517 на китайском и 1,225 на английском, лучше Higgs-Audio-v2, VibeVoice и VoxCPM. Получается, семантические токены лучше держат контент на длинных последовательностях.

В итоге Qwen3-TTS — сильный опенсорс-бейзлайн для авторегрессионных LLM-TTS. Авторам удалось оценить доминирующие подходы к токенизации аудио и выяснить, что акустический вариант с 12 Гц лучше подходит для streaming и низкой задержки, а версия кодека с 25 Гц — для семантики и стабильности длинной генерации. Познакомиться с моделями по лицензии Apache 2.0 можно на GitHub авторов.

Владимир Гогорян ❣ Специально для Speech Info

Reward-Driven Interaction: Enhancing Proactive Dialogue Agents through User Satisfaction Prediction

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

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

Модель диалог-менеджера состоит из трёх веток, чьи представления конкатенируются и подаются в MLP-голову предсказания недовольства.

Query-side. На вход: ASR-вывод, n-best гипотез и rewritten query. Для n-best гипотез считается attention pooling, чтобы собрать их в одно агрегированное представление. Эта ветка должна уловить расхождения между вариантами одного и того же запроса и тем самым помочь выявить возможные ASR-ошибки.

Response-side. На вход: финальный запрос, ответ-кандидат и связанные с ним признаки. Эта ветка моделирует, насколько согласованы между собой пользовательский запрос и тот результат, который система собирается вернуть.

Session-side. На вход: история взаимодействия и время отклика. Эта ветка извлекает признаки на уровне сессии — то есть паттерны, связанные с пользовательской неудовлетворенностью в ходе диалога.

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

1) На ошибках ASR — распознавание часто даёт странные или редкие формулировки, которых мало в обучении, и диалог-менеджер плохо на них обобщается;

2) Редкие домены — на частых сценариях система работает лучше, а в QA и других long-tail-случаях заметно проседает. Авторы связывают это с тем, что здесь используются слабые метки, извлечённые из последующего поведения пользователя, а редких кейсов мало, чтобы основной сигнал сам научил модель устойчивым представлениям.

Архитектуру авторы не меняют. Вместо этого усиливают обучение с помощью двух дополнительных задач.

Первая — contrastive self-supervised learning. Схема, близка к SimCSE: один и тот же запрос дважды пропускается через энкодер с разным dropout, после чего полученные представления сближаются как positive pair, а остальные примеры в батче используются как negatives. За счёт этого модель становится устойчивее к ASR-шуму, редким вариантам запроса и вообще лучше переносит «кривые» формулировки.

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

В итоге всё обучается совместно: основной лосс на предсказание недовольства и два вспомогательных лосса с весами. Отдельный претрейн не требуется.

Основной прирост возникает там, где у базовой модели были проблемы: в редких доменах и шумных запросах. В офлайне это особенно заметно в домене universal QA, где CLA растёт с 0,045 до 0,058. Онлайн-замер это подтверждает: в разборе тысячи сессий новая модель лучше выявляет ошибки ASR (38/119 против 30/119) и NLU (10/61 против 5/61).

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

Никита Боровко ❣ Специально для Speech Info

Как устроена голосовая активация в Яндекс Дропс

Недавно Яндекс запустил свои первые ИИ-наушники — Яндекс Дропс. В числе прочего они умеют распознавать обращение «Алиса», а отвечает за эту способность компонент, который мы внутри называем «споттером» (чуть подробнее писали о споттерах тут). И если с голосовой активацией в колонках всё плюс-минус понятно, то перенести её в наушники — это челлендж.

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

Для начала следовало выбрать чип, который позволил бы споттеру работать непрерывно и постоянно искать обращение в окружающем шуме. Большинству CPU такое не под силу — поэтому взяли чип с NPU (Neural Processing Unit). Решение казалось практически беспроигрышным — но ещё подкинуло сложностей в процессе.

Даже с NPU надо было придумать, как оптимизировать потребление энергии. Решили сделать два этапа — и тем самым уменьшили нагрузку в пять раз:

1. Лёгкая модель VAD (Voice Activity Detector) отделяет голос от фонового шума.

2. Когда VAD услышал голос, включается споттер и разбирается, «Алиса» это или нет.

Также была проблема с тем, что модели из умных колонок в наушники никак бы не влезли. Надо было ужать модель под NPU, сохранив качество распознавания. Провели ряд оптимизаций (разбили подсчёт зависимостей на два шага с помощью Depthwise‑separable convolution, добавили дистилляцию знаний и квантование в 8 бит) — и уместили модель в 200 КБ.

А теперь возвращаемся к той самой проблеме в NPU. Выяснилось, что SDK производителя чипа накладывает жёсткие ограничения на архитектуру: размер ядра свёртки — до 15 фреймов для обычных свёрток и до 11 фреймов для depthwise.

Пришлось сделать сеть глубже, чтобы набрать нужный контекст, а вместо Hardswish выбрать ReLU, которая хорошо ведёт себя после квантования. Но тут получили затухание градиента, из-за которого нижние слои почти не обучались. Помог переход на residual‑архитектуру.

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

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

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

Григорий Афанасенко ❣ Специально для Speech Info

Chunk-wise Attention Transducers for Fast and Accurate Streaming Speech-to-Text

В NVIDIA есть несколько сотрудников, которые стабильно пишут интересные статьи об ASR в целом и RNN-T в частности. Примеры таких работ — FastConformer, TDT, WIND. Сегодня расскажем о CHAT, суть которого также в улучшении RNN-T. Но сначала вспомним, что это такое.

Recurrent Neural Network Transducer — архитектура для распознавания и перевода речи (а в одной статье внезапно предлагают использовать её и для синтеза), состоящая из энкодера, prediction network и joint network. Работает следующим образом:

1. Энкодер принимает на вход звук, чтобы выдать последовательность эмбеддингов.

2. Prediction Network, используя уже имеющийся контекст транскрипции или перевода, предсказывает эмбеддинг для следующего токена транскрипции или перевода.

3. Joint Network использует эмбеддинг от Prediction Network и один из эмбеддингов от энкодера, чтобы предсказать следующий токен.

4. Полученный токен подаём назад в Prediction Network, чтобы получить новый эмбеддинг. Если же был предсказан специальный токен <BLANK>, то оставляем эмбеддинг от Prediction Network в покое и берём уже следующий по порядку эмбеддинг от энкодера.

5. Повторяем шаги 3 и 4, пока не кончатся эмбеддинги от энкодера или пока Joint Network не предскажет <EOS>.

Сегодняшняя статья строится на двух логичных и справедливых утверждениях:

1. В реальных системах распознавания речи звук поступает чанками, а не отдельными токенами.

2. Для предсказания следующего токена в Joint Network можно и полезно использовать более одного эмбеддинга от энкодера за раз.

Руководствуясь первым, авторы предлагают использовать не стандартную для LLM треугольную каузальную маску, а блочно-треугольную. С неё, помимо возможности смотреть назад, токены в рамках блока (чанка) могут смотреть друг на друга. Сама идея не тянет на новаторскую, но она ощутимо подкрепляет следующую.

Нововведение статьи основано на втором утверждении. Обычно Joint Network незамысловатый: сумма, конкатенация или линейный слой с нелинейностью для агрегации эмбеддингов и голова для предсказания следующего токена. Авторы для агрегации решили использовать cross-attention, где эмбеддинг от Prediction Network становится Q, а чанк (!) эмбеддингов от энкодера становится K и V (к этому чанку также конкатенируется токен из нулей чтобы модель могла использовать его для генерации токена <BLANK>). Таким образом мы получаем чанк, токены которого смотрели друг на друга на протяжении всего энкодера и который используется в Joint Network целиком.

Это даёт победу сразу по нескольким направлениям:

🔴Обучение RNN-T требует построения решетки из всех пар эмбеддингов от энкодера и от Prediction Network, чтобы считать лосс по всем возможным траекториям. Метод уменьшил «энкодерную» сторону этой решётки в число раз, равное размеру чанка (в статье — 12).

🔴Пиковое использование GPU-памяти уменьшилось почти в два раза и обучение ускорилось на 36%.

🔴Инференс также ускорился на 69%, потому что мы используем чанки целиком и достаточно проставить 1 <BLANK> для всего чанка вместо каждого эмбеддинга от энкодера.

🔴ASR WER уменьшился на 6,3% и AST BLEU вырос на 18% относительно аналогичных классических RNN-T. Авторы объясняют это тем, что возможность использовать более одного эмбеддинга от энкодера за раз даёт необходимый (особенно для перевода) контекст, позволяющий решать задачу более качественно. Я (автор обзора) считаю, что также благодаря использованию чанка целиком, модели не нужно паковать всю полезную контекстную информацию в каждый токен и она может извлечь и упаковать больше информации в чанк.

Бонус: на недавно прошедшей ICASSP нашему человеку повезло столкнуться с авторами этой статьи. На вопросы «Действительно ли необходимо добавлять токен чисто из нулей для предсказания <BLANK>? Как вы это поняли?» один из авторов ответил: «Inspiration, I had a kind of feeling I should add zeros», — и дальше не углублялся.

Николай Коновальчук ❣ Специально для Speech Info

UALM: Unified Audio Language Model for Understanding, Generation and Reasoning

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

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

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

Для решения предлагают генерировать аудио тоже через авторегрессионную модель, используя для этого:

🔴Кратно больше аудиоданных, чтобы модель могла сойтись в то же качество.
🔴Classifier free guidance, который, по заявлениям авторов, сильно улучшает финальное качество генерации.
🔴Более универсальный кодек, который не требует больших вычислений, но умеет сохранять достаточно информации.
🔴Delay pattern — технику, которую используют в ряде последних статей для генерации аудио через токены.
🔴Self-adaptation-стадии через DPO.

С помощью этих составляющих собирают модель UALM-Gen на базе Qwen2.5-1.5B, которая, по словам авторов, достигает качества диффузионных моделей. Правда, за это надо платить большим объёмом данных: около 80 тысяч часов аудио против нескольких тысяч часов у диффузионок.

В плане архитектуры верхнеуровнево UALM — это аудиоэнкодер + адаптер + Qwen2.5-7B (для основной модели). Аудио переводится в общее с текстом пространство представлений, после чего единая языковая модель занимается пониманием, ризонингом и генерацией аудио.

UALM-Gen решает только задачу генерации. Следующий шаг — объединить в модели задачи аудиопонимания и генерации. Для этого модифицируют DataMix, увеличивая долю генерационных задач, и вводят стадию Modality Alignment для согласования аудио- и текстовых представлений.

Последняя часть — мультимодальный ризонинг. Здесь используют Rich Captions — подробные текстовые планы будущего аудио, которые служат промежуточным представлением между запросом пользователя и генерацией. Также добавляют «самокритицизм», чтобы модель сама понимала, что можно улучшить, и могла итеративно прийти к лучшему результату.

Чтобы добавить ризонинг, модель обучают трём вещам:

🔴Enrichment — дополнять слишком краткие или расплывчатые запросы пользователя.
🔴Dialogue — задавать уточняющие вопросы перед генерацией.
🔴Self-reflection — анализировать собственный результат, находить расхождения с исходным планом и улучшать следующую версию.

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

Можно посмотреть код и демо, а вот веса пока не выложены.

Александр Шаршавин ❣ Специально для Speech Info

Voxtral Realtime

Разбираем статью о модели Voxtral Realtime, в которой предложили ещё один способ, как стримить speech-to-text.

Авторы утверждают, что у них получилось сделать модель, в которой можно контролировать латенси и которая при задержке в полсекунды имеет паритет по качеству с Whisper. Если увеличить задержку до секунды, то модель начинает превосходить Whisper, ещё больше — например, 2,5 секунды, — качество уже сравнивается с офлайновой Voxtral Mini Transcribe V2.

На Open ASR Leaderboard модель занимает место примерно в середине таблицы. Тот же офлайновый Voxtral располагается выше (но он и значительно больше).

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

Чтобы сделать нативную стриминговую модель, нужно иметь алайнмент между аудио и текстом, а также архитектуру, которая поддерживает постепенную обработку приходящего аудио. Например, распространенный подход — RNN-T со стриминговым энкодером (такой часто используют в Nvidia). Другой, менее известный подход, — DSM (Delayed Streams Modeling). И Voxtral Realtime — это как раз и есть DSM-ка.

Состоит модель из трёх частей: аудиоэнкодера, адаптера и текстового декодера. Фичи аудио прогоняют через энкодер, потом с помощью адаптера приводят в одно пространство с текстовыми эмбедингами. Они суммируются, подаются на вход в декодер — и предсказывается следующий токен.

Чуть подробнее о каждой части.

Трансформер-энкодер — базовая архитектура с уже привычными RMSNorm, SwiGLU, RoPE и прочим. В качестве аудио фичей, которые подаются на вход, используется log-Mel-спектрограмма. Фичи проходят через две каузальные свертки, что приводит к даунсемплингу в два раза. В итоге энкодер выдаёт фичи каждые 20 миллисекунд. Тут также используется sliding window self-attention с окном в 15 секунд, то есть 750 фреймов.

Адаптер, который представляет из себя простой MLP-слой. С помощью него дополнительно даунсемплим аудио ещё в четыре раза. В итоге фичи идут с шагом 80 миллисекунд.

Трансформер-декодер работает поверх этих фичей и предсказывает следующий токен.

Из интересного — здесь есть не только текстовые токены, но ещё два служебных: padding [P] (аналог blank-токена в RNN-T) и word [W] (означает, что буквально «сейчас начнётся предсказание слова»). В отличии от RNN-T, где мы можем на один эмбеддинг энкодера предсказать несколько текстовых токенов, здесь предсказываем ровно один токен.

Чтобы обучать такую модель, авторы собирают данные в виде набора (аудио, текст, word-level алайнмент). Таргеты для обучения на next-token prediction формируются примерно так:

🔴На тех фреймах, где произносится слово + некоторый дилэй после конца слова, мы должны предсказать токен [P].
🔴После этого идёт токен [W], за которым следуют токены соответствующего слова.
🔴Всё остальное заполняем токеном [P].

Одно из нововведений — использование механизма Ada RMS-Norm в декодере — пожалуй, самое интересное в архитектуре. С ним можно во время обучения использовать разную задержку, чтобы модель могла адаптироваться под разную скорость, а во время инференса буквально за счёт изменения одного параметра контролировать то, с какой задержкой ASR выдаёт текст.

В аблейшенах сравнивают Ada RMS-Norm с другими способами контроля латенси, среди которых он показывает лучший результат. Также оказалось полезно не разделять токеном [W] слова, которые произносятся почти одновременно.

Александр Палаевич ❣ Специально для Speech Info