Moshi: GPT4-O voice mode дома (обзор)

Intro

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

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

• Moshi не опирается на сложные каскадные пайплайны (ASR, NLU, TTS), а объединяет все эти функции в единую модель, обеспечивая непрерывное взаимодействие между пользователем и системой. Это позволяет модели:

  • Вести диалог без задержек

  • Обрабатывать паралингвистические аспекты (эмоции, интонацию)

  • Справляться с перекрестной речью (перебивания, параллельные ответы)

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

• Inner Monologue: Модель обучается сначала предсказывать текстовые токены, а затем генерировать аудио, что обеспечивает высокую фактическую точность и качество речи

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

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

Можно было бы авторам не предобучать свой собственный кодер аудио, а использовать Speechtokenizer? Ну да, очевидно можно, т.к. изменения внесены минорные. Захотелось авторам промерить + несколько процентов за счет своих изменений? ‑ДА. было. То же касается и Helium (LLM 7B from scratch)

Поговорить про эти минорные изменения все равно очень хочется, поэтому начну:

Helium

TL;DR: 7B LLM, обученная на 2.1 триллионах токенов. Используется RoPE (link) для работы с длинными последовательностями, FlashAttention (link), RMS нормализация (link), GLU блоки (link) для стабильной и эффективной обработки текста и токенайзер SentencePiece (link) с 32000 словаре в основом на английском

Шаги обработки данных включали:

1. Дедупликация: Удаление повторяющегося текста на уровне строк с помощью хэширования и классификатора fastText.

2. Определение языка: Оставлялись только документы, уверенно классифицируемые как английские (с порогом 0.85) с использованием fastText.

3. Качественная фильтрация: Использовался классификатор fastText для оценки и отбора документов, близких по качеству к высококачественным источникам.

! Взаимодействие с остальной системой (почему без него никак):

• Helium служит основой для Temporal Transformer в Moshi, позволяя использовать текстовое понимание Helium для обработки аудио-токенов и создания полноценной мультимодальной модели

• Helium генерирует текстовые токены для Inner Monologue, формируя основу для аудиогенерации, которая затем передается через Mimi и RQ-Transformer для создания аудиопотока Moshi.

Этапы обучения:

• Pre-training – Moshi начинает обучение с неразмеченными данными, где Temporal Transformer инициализируется из модели Helium, чтобы унаследовать её знания и способность обрабатывать текстовую информацию

• Post-training with simulated multi-stream based on diarization – Moshi обучается в условиях, моделирующих диалог в режиме нескольких потоков. Этот этап особенно важен для того, чтобы подготовить модель к одновременному прослушиванию и говорению

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

• Fine-tuning on the Fisher dataset

• Instruction fine-tuning

Mimi

Кодиродание и декодирование аудио происходит в архитекрутуре за счет предобученного кодека

TL;DR: Mimi – это аудиокодек, основанный на принципах SoundStream (link) и Encodec (link) (это буквально вырезка из статьи, а вот на что реально сильно похож кодек, так это Speachtokenizer (link). Собственно про это они пишут в предыдущих методах. Но противоречий тут нет). Она включает в себя автоэнкодер SeaNet (link) и метод квантования Residual Vector Quantizer (RVQ). Автоэнкодер и RVQ вместе позволяют преобразовать аудиосигнал в компактное дискретное представление.

Из важного – Mimi кодирует аудиосигнал в два типа токенов:

• Семантические токены – передают лингвистическое содержание (смысл).

• Акустические токены – обеспечивают сохранение деталей аудиокачества, таких как интонация, тембр, эмоции.

В чем отличия от SpeechTokenizer:

• Архитектура и объединение токенов:

  • Mimi в Moshi использует разделенную Residual Vector Quantizer (RVQ) для обработки речи. Первый слой RVQ создает семантические токены, которые обеспечивают лингвистическое содержание, а последующие уровни RVQ генерируют акустические токены, отвечающие за детали звука.

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

• Дистилляция семантической информации:

  • Mimi использует WavLM как своего рода “семантического учителя”, чтобы перенести семантическую информацию в первый уровень RVQ. Этот процесс помогает Mimi эффективно комбинировать аудио и текстовую информацию

  • SpeechTokenizer более явно проводит дистилляцию, используя HuBERT в качестве семантического учителя, что позволяет достичь более высоких результатов по сравнению с EnCodec в задаче совмещения текстовой информации и качества звука

• Иерархическое разделение информации:

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

  • SpeechTokenizer фокусируется на иерархическом моделировании, где первый слой RVQ обрабатывает семантическую информацию, а следующие RVQ-слои дополняют акустические детали, объединяя оба аспекта речи в единую структуру

! Взаимодействие с остальной системой (почему без него никак):

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

• Mimi предоставляет аудиотокены для RQ-Transformer, а затем RQ-Transformer объединяет информацию от Helium (текстовые токены) и Mimi (семантические и акустические токены), чтобы сгенерировать связную речь.

RQ-Transformer

TL;DR: RQ-Transformer обеспечивает Moshi возможность моделировать длинные последовательности и эффективно обрабатывать информацию из различных источников (текст, семантика, акустика) в режиме реального времени.

Архитектура RQ-Transformer состоит из двух компонентов:

• Temporal Transformer – обрабатывает информацию на временной шкале, позволяя модели понимать длинные фрагменты аудио и текста.

• Depth Transformer – обрабатывает токены на каждом временном шаге, обеспечивая детализацию и уточнение информации.

! Взаимодействие с остальной системой (почему без него никак):

• Helium генерирует текстовые и семантические токены на основе входных данных и внутреннего контекста диалога.

• Mimi предоставляет аудиотокены для RQ-Transformer, а затем RQ-Transformer объединяет информацию от Helium (текстовые токены) и Mimi (семантические и акустические токены), чтобы сгенерировать связную речь.

• RQ-Transformer служит мостом между Helium и Mimi, позволяя модели интегрировать текстовую и аудиоинформацию и генерировать последовательности речи, которые соответствуют лингвистическому и аудиоконтексту

Inner Monologue & Full-Duplex

TL;DR: Вместо стандартной последовательной генерации аудио Moshi сначала генерирует токены текста, а затем использует их как префикс к генерации аудиотокенов. Этот процесс реализован через механизм Inner Monologue, позволяющий Moshi сначала продумывать ответ в текстовом виде и лишь затем озвучивать его

Концепция Full-Duplex (link):

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

Как Moshi реализует full-duplex:

• Благодаря гибкой архитектуре и задержке между текстовыми и аудиотокенами, Moshi может одновременно генерировать речь и слушать, без явных границ между моментами «говорения» и «слушания».

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

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

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

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

• Link на саму статью

• Link на репозиторий

• Link на демку