Scaling Transformers for Low-Bitrate High-Quality Speech Coding

Мечта многих — заменить олдскул в аудиокодеках на нормальный трансформер. У авторов это, наконец, получилось, хоть и не сразу. Они обнаружили, что «трансформер в лоб» не работает — и пошли разбираться почему. На постере причину не написали, но мы спросили — ведь ML-аудитории важны не только архитектура и таблички с метриками.

Так вот. Если обучить трансформерный кодек и проверить его через adversarial-атаку на дискриминатор, можно увидеть: искажения группируются по границам STFT-патчей, которые мы снимаем с wave-формы. Это значит, что трансформеры умеют подстраиваться под дискриминатор, ломая wave-форму в правильных узких областях. А эти узкие места всегда повторяются из-за регулярности периодичности.

Можно заметить, что сейчас мода на дискриминаторы с периодикой по простым числам. Авторы действуют нестандартно: используют дискриминаторы не по числам, а по золотому сечению. Говорят, что просто перебирали разные периодичности и пришли к этому решению. (Ссылку на работу Луки Пачоли дать забыли).

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

В остальном — авторы честно признались, что использовали FSQ, потому что это модно, а размер кодбука был спущен сверху продуктово.

В целом это всё напоминает статью Zoom с Interspeech, где использовали достаточно большой дискриминатор — и без просадок в инференсе получили буст качества.

Степан Комков ❣ специально для Speech Info

#YaICLR

WavChat: A Survey of Spoken Dialogue Models. Часть 3/4

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

В предыдущих сериях: 1, 2.

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

Авторы рассматривают разные способы объединять текстовые и аудиоданные на этапе тренировки (как на картинке). Но одними из самых многообещающих считают интерливинг и chain-of-modality.

Оба этих подхода позволяют учиться на больших корпусах частично структурированных данных, запоминая как структуру аудиоданных, так и взаимное обусловливание речи и текста друг на друга. А вот обучение адаптера в text-only-output-парадигме на большом наборе датасетов из разных задач (как было в SALMONN и Qwen-Audio) авторы считают не очень жизнеспособным. Полноценно обучить синтезу, в отрыве от других задач, нельзя — а значит, диалог с такой моделью проиграет в естественности другим подходам.

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

Продолжение следует.

Никита Рыжиков ❣ Специально для Speech Info

WavChat: A Survey of Spoken Dialogue Models. Часть 4/4

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

В предыдущих сериях: 1, 2, 3.

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

Полудюплекс включает в себя автоматическое определение конца речи, после которого она обрабатывается и ответ возвращается в виде аудио — как это реализовано в Alexa, Алисе и других умных помощниках.

В полноценной дюплекс-реализации модель каждый чанк времени обрабатывает входящие реплики и генерирует выходные. Когда она слушает, она генерирует тишину или поддакивает, показывая что на связи. А если её перебить, сможет естественно остановиться, договорив слово до конца. Так получаются наиболее живые диалоги, но попытку сделать полноценный дюплекс на момент написания статьи сделали только в Moshi.

Ещë в статье была часть про бенчи, которая скорее расстроила: эффективно измерять качество именно диалоговых систем пока толком не на чем. Есть замеры, которые сравнивают отдельные аспекты «умности» диалоговых систем/ALM. При этом у выигрывающих по бенчам статей далеко не всегда самые впечатляющие демо.

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

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

Для себя я вынес следующее:

1. SpiritLLM, Moshi, SyncLM — интересные реализации диалоговых систем.

2. Победят акустические токены + длительная стадия пост-претрейна на большом объёме аудио + файнтюн на диалогах (даже синтезированных). Но это не точно.

3. Нормальных бенчей нет.

4. Дюплекс — правильный путь, но работает пока только у Moshi, и то плохо. Спойлер, выходящий за пределы этого обзора: кажется, у Sesame.com получилось.

5. Статей становится всё больше, так что будущее — за e2e-диалоговыми системами.

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

Никита Рыжиков ❣ Специально для Speech Info

Moshi в деталях: новая архитектура диалоговой системы в реальном времени. Часть 1/2

Разбираем статью о real-time dialogue-модели Moshi, которая, в отличие от предыдущих диалоговых систем, объединяет в одной архитектуре три компонента: ASR (распознавание речи), LLM (языковая модель) и TTS (синтез речи). Такая схема позволяет воспринимать речь и генерировать ответ одновременно. Управление тем, когда говорить и когда слушать, реализовано через специальный управляющий токен. (Даже я не всегда так умею — прим. автора).

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

Helium

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

Претрейн модели проводился на 2,1 трлн токенов. (Для сравнения: Llama 2 — 1,8 трлн, Llama 3 — 15,6 трлн). Данные собирали, фильтруя CommonCrawl — огромный дамп интернета, где много мусора, но если хорошо почистить, получается неплохой датасет. В итоге датасет состоит из 87,5% CommonCrawl и 12,5% Wikipedia.

После претрейна провели три дополнительных этапа обучения: пост-тренировку, файнтюнинг и инструкционное обучение — чтобы модель лучше справлялась с диалогами. По оценке авторов, Helium сравнима с Llama 2 и первым Mistral, но не дотягивает до Llama 3.

Mimi

Нейросетевой аудиокодек на основе Residual Vector Quantization (RVQ). Архитектура — стандартный энкодер-декодер, но с интересными деталями: обычно в аудиокодеках используются только свёрточные слои, а тут добавили трансформеры — в конце энкодера и в начале декодера. Это сделало кодек умнее (и тяжелее).

Ещё одно важное отличие Mimi от остальных аудиокодеков — у него довольно маленькая герцовка. Mimi нужно 12,5 векторов, чтобы закодировать секунду аудио. Для сравнения у EnCodec — 75, WavTokenizer — 40. За счёт этого трансформер поверх такого кодека можно учить с бóльшим батчем (в секундах) и быстрее инферить.

Набор лоссов у Moshi примерно такой же, как и у HiFi-GAN-a. Единственное отличие — это то, что авторы убрали L1-loss между STFT-спектрограммами, из-за плохой корреляции с человеческим восприятием. Без него субъективные метрики получались лучше.

Главное ноу-хау Mimi — семантическая дистилляция, которая позволяет получить акустические токены со свойствами семантических.

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

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

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

Решение — дистиллировать семантические эмбеддинги WavLM в акустические эмбеддинги Mimi. Для этого нужно посчитать косинусное расстояние между эмбеддингами WavLM и Mimi и использовать это как дополнительную компоненту лосса. Есть одна проблема — у моделей разные герцовки: у WavLM — 50, а у Moshi — 12.5, в 4 раза реже. Мы не можем просто посчитать косинусное расстояние между соответствующими эмбеддингами. Чтобы справиться с этим, авторы применили AveragePooling со stride-ом 4 к последовательности эмбеддингов из WavLM и привели обе последовательности к одной частоте — 12,5.

В следующей части разберём главное об устройстве модели Moshi и алгоритма Inner-monologue.

Роман Кайль ❣ Специально для Speech Info

Moshi в деталях: новая архитектура диалоговой системы в реальном времени. Часть 2/2

Продолжаем разбирать Moshi — диалоговую систему, которая совмещает распознавание, чат-бота и синтез речи в одной модели. В первой части речь шла о LLM Helium и аудиокодеке Mimi. Здесь — о том, как устроена сама Moshi и как работает механизм переключения между «слушать» и «говорить».

Moshi

На следующем этапе авторы хотят научить текстовую LLM Helium аудиомодальности, а конкретно — предсказывать токены от Mimi. Да ещё и так, чтобы модель не потеряла свои LLM-ные знания.

Наша задача — предсказывать матрицу из токенов с размерностями времени на 8 кодеков. Для этого модель Moshi состоит из двух трансформеров: Temporal Transformer и Depth Transformer.

Temporal Transformer — это большой трансформер, проинициализированный весами Helium. Он будет авторегрессивно идти по размерности времени и генерировать эмбеддинг для каждого тика времени. Depth Transformer инициализируется шумом. Его задача — на каждом шаге Temporal Transformer-a закондишениться на сгенерированный эмбеддинг и развернуть его в 8 Mimi-токенов.

Учиться вся эта конструкция будет в три этапа. Тут опускаем много подробностей, но идея примерно такая:

1. Учимся на огромном, шумном audio-only датасете. На этом этапе моделька познаёт аудиомодальность и пытается соотнести её с текстовой модальностью.

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

3. Тюнимся на более качественном диалоговом датасете. Модель обретает свой голос и выучивает более осознанные диалоговые ответы.

Важнейшая фича Moshi — full-duplex: способность модели одновременно слушать и говорить. С ней диалог получается плавнее и человечнее, в нём могут быть одновременные реплики, перебивания и междометия. Модель достигает режима full-duplex с помощью алгоритма Inner Monologue.

Inner-monologue

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

Дальше мы хотим учить модельку на этих данных. Тут полезно посмотреть на картинку.

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

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

— На выход мы хотим получать только текст и аудио реплик. На картинке — это оранжево-жёлто-зелёные (каждый цвет — отдельное слово) токены. Текст предсказывает линейная голова поверх Temporal Transformer, а для аудиотокенов есть Depth Transformer.

— В такой парадигме моделька учится и инферится.

Moshi вышла 7 месяцев назад и, кажется, уже потихоньку устаревает. Если попользоваться демкой, сначала она приводит в восхищение, но потом становятся заметны косяки: модель говорит глупости, неуместно перебивает, начинает отвечать с большой задержкой. Она ощутимо слабее, чем, например, VoiceMode от OpenAI. Но у ребят подробная статья, много интересных выводов и экспериментов, а также выложенный в открытый доступ кодек. Это довольно большой вклад в область.

Роман Кайль ❣ Специально для Speech Info

Обзор статей с ICASSP 25. Часть 1: шумоподавление в наушниках

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

Towards Sub-millisecond Latency Real-Time Speech Enhancement Models on Hearables

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

Авторы сделали компактную нейросеть, которая предсказывает параметры FIR-фильтра — по сути, какую свёртку применить к звуку. Эта свёртка обновляется каждые 8 мс, но применяется сразу к новым аудиофрагментам, так что задержка остаётся минимальной — 2–3 мс (алгоритмическая задержка — 1 мс, а всё остальное — вычислительная). Работает даже на слабом железе — тестировали на 600 MHz HiFi4 Audio DSP(Cadence), и там всё летает.

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

BONE CONDUCTED SIGNAL GUIDED SPEECH ENHANCEMENT FOR VOICE ASSISTANTON EARBUDS

Ещё одна статья о шумоподавлении, но уже для очистки того, что пользователь наушников говорит, а не слышит. Человек говорит в шумной обстановке (на улице, на ветру, в метро), и сам этого может даже не замечать. Снаружи всё гудит, а внутри уха — тишина. Только вот собеседнику слышно совсем не так.

В современных наушниках уже есть не только внешние микрофоны, но и внутренние, которые улавливают сигнал через кость черепа. Он искажён, но в нём почти нет внешнего шума. Его и используют.

Вход у модели — два канала: грязный внешний микрофон и искажённый, но «чистый» костный сигнал. Всё это подаётся в Cleanformer — это их старая модель, адаптированная под такую задачу. Cleanformer предсказывает маску, которую потом накладывают на внешний сигнал, чтобы его «почистить»: сохранить полезные частоты и убрать шум. Похожую модель Google использует уже довольно давно для очистки звука в умных колонках.

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

В следующей части разберём пару работ о голосовой активации.

Алексей Рак ❣ Специально для Speech Info