Неочевидные проблемы в Text‑to‑Speech, о которых редко говорят

Когда приходишь в Text‑to‑Speech из классического ML (или даже из CV/NLP), кажется, что всё знакомо: датасет, модель, loss, валидация, поехали. А потом довольно быстро ловишь себя на мысли, что что‑то тут не так.

В TTS есть набор проблем, которые:

• не очевидны на старте;

• почти не обсуждаются;

• и при этом регулярно бьют по разработке.

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

Метрики, которым не очень хочется верить

Наверное, самое болезненное место. Если коротко: в TTS нет одной нормальной метрики, на которую можно спокойно опереться и сказать «всё, модель стала лучше». Точнее опереться то можно, но с оговорками.

WER / CER — вроде всё ок, но не совсем

Самое очевидное — взять Word Error Rate (WER) и Character Error Rate (CER).
Схема простая:

1. синтезируем аудио;

2. прогоняем через модель распознавания речи;

3. сравниваем с исходным текстом, считая долю слов (WER) и символов (CER), где допущена ошибка ^[1].

Получаем долю ошибок. Всё красиво. Проблема в том, что это проверяет только правильность текста, но не качество звука. Модель может звучать неестественно, иметь странную интонацию, звучать как робот. Но показывать хороший WER и CER.

Для раннего фильтра и sanity check подходит, но не как финальная метрика качества.

Инструкции для асессоров

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

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

Я лично переписывал наши инструкции для асессоров. Оказалось, что до этого они были длиной буквально в несколько строчек, из‑за чего мы не могли поймать, например, «ненатуральные» интонации, или неестественные паузы и плохую работу с пунктуацией (в некоторых случаях паузы должны быть короче, чем в других). Моя новая инструкция была размером в 3–4 страницы. Пришлось ввести систему баллов, разные типы ошибок, иерархию критичности каждого типа и подробное описание каждого с примерами.

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

Side‑by‑side — работает, но с нюансами

Side‑by‑side (SBS) — попарное сравнение. Из названия понятен смысл — берем тексты, генерим их двумя разными моделями, просим асессора проголосовать за лучшую из пары (либо указать, что качество одинаково).

Спойлер — самая качественная метрика на моей практике. Основная сложность — она относительная. Она дает понимание только в контексте 2 конкретных моделей. Если у вас есть N моделей примерно равного качества, то в худшем случае вам придется посчитать SBS для N*(N-1)/2 пар (модель 1 сравнить с моделями 2,…, N; модель 2 с моделями 3,…, N; и так далее).

Конечно на практике до такого редко доходит, но чтобы найти лучшую модель почти всегда придется посчитать >N метрик. А это — лишние деньги на разметку и время.

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

MOS — любимая всеми и при этом странная

Казалось бы, после всех проблем SBS хочется иметь абсолютную метрику качества. И такая метрика есть!

Mean Opinion Score (MOS) — очень часто используемая метрика. Считается просто: даешь аудио разметчику, он ставит оценку от 1 до 5, считаешь среднее.

MOS очень любят. Ведь он:

• абсолютный;

• понятный;

• красиво смотрится в отчетах и докладах.

Звучит очень хорошо. В чем проблема? Много шума, большая дисперсия (иногда больше 1.5 при максимальной оценке = 5). На практике нашей команды люди очень плохо оценивают качество аудио «независимо».

Аналогия для понимания:

• пусть у нас есть 2 колонки с разными голосовыми моделями;

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

• если дать первую колонку на неделю, потом вторую — разницу он заметит только если она разительна.

Причем аналогия эта возникла не на пустом месте. По слухам, один из топ менеджеров в нашей компании с завидной регулярностью ставил рядом с нашей колонкой колонку конкурента и гонял их по своим представлениям «запросов пользователей». Было очень сложно объяснить, что такой тест почти не имеет статистической силы. Общее качество ответа устройства зависит от множества факторов, а не только от TTS. Но ещё сложнее было объяснить, что при независимом прослушивании разница ощущалась бы намного слабее. Повторять ^[2] эксперимент по второму сценарию он, конечно же, не хотел.

Поэтому ситуация, что Модель А имеет MOS ≈ 4.0, а Модель B имеет MOS ≈ 4.4, на практике может не сказать ничего. Эта разница может оказаться статистически незначимой.

Меньше loss ≠ лучше качество

В конце поговорим про loss, который мы оптимизируем непосредственно во время обучения ^[3] модели.

Если сильно упростить, пайплайн ТТС выглядит таким образом:
Текст → Нормализация → Мел‑спектрограммы → Аудио
Основная работа и инновации происходят на шаге получения Мел‑спектрограммы.

Мы предсказываем эту Мел‑спектрограмму либо как задачу регрессии, либо как классификации на аудио токены (в более новых подходах). И оптимизируем обычный Loss (MSE в случае регрессии, кросс энтропию в случае классификации).

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

• checkpoint на шаге 120.000;

• checkpoint на шаге 150.000;

• у второго loss лучше.

Но на слух ^[4] качество аудио либо одинаково, а иногда у первого даже звучит приятнее.
Из‑за этого стандартный пайплайн: берем лучший checkpoint по loss’у на валидации, в TTS часто не работает.

Приходится сохранять несколько чекпоинтов, генерить ими несколько аудио (обычно 10–20) и слушать.

Да, руками (ушами). Я переслушал столько вариаций «озвучки» абзацев из Википедии про А.С. Пушкина, что мог повторять их наизусть. То есть, валидация становится частично ручной, как минимум при выборе чекпоинтов для подсчета метрик и сравнения с продом.

Итог

Когда я начинал работать с TTS, ожидал обычный ML‑пайплайн с нюансами. Интересно было именно разбираться во внутренностях моделей и копаться под капотом torch. По факту оказалось, что значительная часть времени уходит не на обучение и построение модели, а на попытку ответить на вопрос: «Она реально стала лучше или мне кажется?».

В какой‑то момент в TTS начинаешь доверять своим ушам больше, чем метрикам.