Когда приходишь в Text‑to‑Speech из классического ML (или даже из CV/NLP), кажется, что всё знакомо: датасет, модель, loss, валидация, поехали. А потом довольно быстро ловишь себя на мысли, что что‑то тут не так.
В TTS есть набор проблем, которые:
не очевидны на старте;
почти не обсуждаются;
и при этом регулярно бьют по разработке.
Причём это не какие‑то редкие кейсы. Это вещи, которые встречаются постоянно.
Попробую описать несколько таких моментов, о которые обжегся сам во время работы над аудио ассистентом в одном из российских бигтехов.
Метрики, которым не очень хочется верить
Наверное, самое болезненное место. Если коротко: в TTS нет одной нормальной метрики, на которую можно спокойно опереться и сказать «всё, модель стала лучше». Точнее опереться то можно, но с оговорками.
WER / CER — вроде всё ок, но не совсем
Самое очевидное — взять Word Error Rate (WER) и Character Error Rate (CER).
Схема простая:
синтезируем аудио;
прогоняем через модель распознавания речи;
сравниваем с исходным текстом, считая долю слов (WER) и символов (CER), где допущена ошибка.
Получаем долю ошибок. Всё красиво. Проблема в том, что это проверяет только правильность текста, но не качество звука. Модель может звучать неестественно, иметь странную интонацию, звучать как робот. Но показывать хороший 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. Но ещё сложнее было объяснить, что при независимом прослушивании разница ощущалась бы намного слабее. Повторять эксперимент по второму сценарию он, конечно же, не хотел.
Поэтому ситуация, что Модель А имеет MOS ≈ 4.0, а Модель B имеет MOS ≈ 4.4, на практике может не сказать ничего. Эта разница может оказаться статистически незначимой.
Меньше loss ≠ лучше качество
В конце поговорим про loss, который мы оптимизируем непосредственно во время обучения модели.
Если сильно упростить, пайплайн ТТС выглядит таким образом:
Текст → Нормализация → Мел‑спектрограммы → Аудио
Основная работа и инновации происходят на шаге получения Мел‑спектрограммы.
Мы предсказываем эту Мел‑спектрограмму либо как задачу регрессии, либо как классификации на аудио токены (в более новых подходах). И оптимизируем обычный Loss (MSE в случае регрессии, кросс энтропию в случае классификации).
На первых стадиях обучения все идет как обычно: лосс падает, качество растет. Но на более поздних эпохах, из которых ты и будешь выбирать модель для сравнения с продом, часто бывают такие ситуации:
checkpoint на шаге 120.000;
checkpoint на шаге 150.000;
у второго loss лучше.
Но на слух качество аудио либо одинаково, а иногда у первого даже звучит приятнее.
Из‑за этого стандартный пайплайн: берем лучший checkpoint по loss'у на валидации, в TTS часто не работает.
Приходится сохранять несколько чекпоинтов, генерить ими несколько аудио (обычно 10–20) и слушать.
Да, руками (ушами). Я переслушал столько вариаций «озвучки» абзацев из Википедии про А.С. Пушкина, что мог повторять их наизусть. То есть, валидация становится частично ручной, как минимум при выборе чекпоинтов для подсчета метрик и сравнения с продом.
Итог
Когда я начинал работать с TTS, ожидал обычный ML‑пайплайн с нюансами. Интересно было именно разбираться во внутренностях моделей и копаться под капотом torch. По факту оказалось, что значительная часть времени уходит не на обучение и построение модели, а на попытку ответить на вопрос: «Она реально стала лучше или мне кажется?».
В какой‑то момент в TTS начинаешь доверять своим ушам больше, чем метрикам.