Метрики качества синтеза речи: как оценить надежность API

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

Метрики оценки качества синтеза речи в API отвечают на разные вопросы. MOS описывает субъективное восприятие естественности. WER и CER помогают найти ошибки в произнесенном тексте. TTFA показывает, когда приходит первый аудиофрагмент, а RTF — насколько быстро система генерирует речь относительно ее длительности. Если свести эти показатели в общий рейтинг, потеряются различия между качеством голоса, корректностью текста и скоростью инференса.

MOS: оценка естественности звучания

MOS, или Mean Opinion Score, получают из оценок слушателей. Асессоры прослушивают аудио и выставляют баллы по шкале от 1 до 5. Метрика подходит для проверки естественности, чистоты речи и общего впечатления от звучания. Реальные записи дикторов обычно набирают около 4,5 балла. Для нейросетевого синтеза результат выше 4,0 считают высоким ориентиром.

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

Для внутреннего тестирования протокол стоит зафиксировать до запуска моделей. Например:

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

Последний пункт важен для диагностики. Общий MOS может скрыть деградацию на конкретных конструкциях. Модель хорошо озвучивает обычный текст, но снижает качество на перечислениях, вопросительных предложениях или числах. Разрезы по типу текста показывают это лучше, чем единый средний балл.

MOS полезно дополнять комментариями асессоров с фиксированными категориями: неверное ударение, неестественная пауза, металлический тембр, смазанные согласные, скачок громкости. Свободные отзывы тоже могут быть полезны, но их сложнее агрегировать и сопоставлять между прогонами.

MOS измеряет впечатление слушателя. Он не заменяет проверку произнесенного текста и поведения API под нагрузкой.

TTFA и RTF: две разные характеристики скорости

Для интерактивного сценария задержка до первого аудиофрагмента часто важнее времени генерации всего ответа. TTFA, или First Chunk Latency, измеряет интервал от отправки запроса до получения первого аудиопакета. Для голосовых ассистентов целевым ориентиром служит значение до 300 мс. Это не универсальная граница для любого приложения: допустимая задержка зависит от сценария, сетевого пути и того, как клиент воспроизводит поток.

TTFA нужно измерять на стороне клиента. Замер только времени ответа сервера не включает сетевую задержку и обработку аудиофрагмента в приложении. В тесте фиксируют момент отправки запроса и момент, когда первый пригодный для воспроизведения пакет доступен клиенту. Повторные запросы запускают несколько раз, отдельно сохраняя медианное значение и разброс. Одно удачное измерение не характеризует стабильность.

RTF показывает отношение времени синтеза к длительности полученного аудио. При таком определении значение меньше 1 означает, что синтез идет быстрее реального времени: например, десятисекундный фрагмент получен менее чем за десять секунд. Для потокового сценария генерация должна успевать за воспроизведением. В документации и бенчмарках встречаются разные соглашения и производные показатели скорости, поэтому перед сравнением следует проверить формулу. Иногда под скоростью понимают обратное отношение: длительность аудио к времени синтеза. Там, наоборот, большее значение означает более быструю генерацию.

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

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

Спектральные метрики: MCD, PESQ и STOI

Объективные показатели качества синтезированного голоса позволяют сравнить сигнал с эталонной записью. Здесь нужны пары: синтезированное аудио и референс, произнесенный диктором текст. Если у фраз отличаются тайминг, произношение или интонация, вычисленная метрика будет отражать сразу несколько причин расхождения.

MCD, Mel-Cepstral Distortion, оценивает спектральное расстояние между сигналами через мел-кепстральные коэффициенты. Метрика помогает анализировать акустические различия, но сама по себе не отвечает на вопрос, насколько естественно звучит голос для слушателя. На значение влияют выравнивание аудио, набор фраз и способ извлечения признаков. Сравнивать MCD имеет смысл только при одинаковом пайплайне обработки.

PESQ используется для оценки воспринимаемого качества речи при сравнении с эталонным сигналом. STOI оценивает разборчивость. В этой шкале результат выражают в диапазоне от 0 до 100%. Эти показатели применяют для автоматизированного сопоставления аудиосигналов, однако для синтеза с разной просодией или длительностью требуется аккуратная подготовка пар и выравнивание.

Практический тест строят так:

1. Подготовить набор фраз, покрывающий лексику и синтаксис целевого продукта.

2. Записать эталон с диктором либо выбрать готовые записи с совпадающим текстом.

3. Привести аудио к единому формату и проверить выравнивание.

4. Считать выбранные метрики на уровне фраз, а затем агрегировать результат по группам.

5. Прослушать фразы с наиболее заметными отклонениями и определить источник расхождения.

Алгоритмические показатели полезны для регрессионного контроля. После смены модели, версии API или параметров синтеза можно повторить тот же прогон и увидеть сдвиг. Но высокая близость спектра не гарантирует, что слушатели предпочтут именно эту версию. Метрики описывают отдельные свойства сигнала, а не универсальное качество голоса.

WER и CER: проверка того, что модель произнесла

WER, Word Error Rate, и CER, Character Error Rate, применяют к результату распознавания синтезированного аудио. Генерацию прогоняют через ASR-модель, затем сравнивают распознанный текст с исходным. WER считает ошибки на уровне слов, CER — на уровне символов.

Такой тест выявляет пропуски, замены и искажения. Он особенно полезен для чисел, имен, адресов, аббревиатур и слов с нестандартным произношением. Для русского языка ошибки ASR могут зависеть от морфологии, пунктуации и нормализации чисел. Перед расчетом нужно определить правила: считать ли «2025» и «две тысячи двадцать пять» эквивалентными, удалять ли знаки препинания, приводить ли текст к нижнему регистру.

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

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

Просодия и пределы автоматической оценки

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

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

Для тестирования задают отдельные наборы, а не пытаются покрыть все одним корпусом:

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

В каждом наборе полезно фиксировать настройки голоса. Изменение скорости, стиля или параметров просодии может дать иной результат даже при неизменном тексте. В тестовом отчете версию API, идентификатор голоса и параметры запроса записывают вместе с результатами метрик.

Сборка тестового контура для API

Тестирование TTS-моделей для разработчиков должно воспроизводить реальный путь запроса. В контур включают генерацию, получение аудиофрагментов, сохранение файлов, распознавание через ASR и расчет метрик. Отдельно ведут журнал ошибок API: таймауты, пустые ответы, сбросы соединения и ошибки формата. Такие сбои не относятся к качеству звучания, но напрямую влияют на надежность интеграции.

Минимальный набор для сравнения провайдеров включает:

• фиксированный корпус текстов с пометками типов фраз;
• одинаковые настройки голоса и формата аудио там, где API позволяют их сопоставить;
• MOS для оценки слушателями;
• TTFA и полное время ответа;
• RTF с явно указанной формулой;
• WER и CER после нормализации;
• MCD, PESQ или STOI при наличии подходящего эталона;
• число технических ошибок и разброс задержек при параллельной нагрузке.

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

Сравнение полезно проводить не только между поставщиками, но и между версиями одного API. Запускать контрольный корпус после обновления модели, изменения голоса или перенастройки клиентского пайплайна. Если MOS снизился, а WER остался прежним, вероятна проблема в звучании или просодии. Если растут WER и CER, нужно разбирать текстовые ошибки и поведение ASR. Если качество аудио стабильно, но увеличился TTFA, причина лежит в производительности или инфраструктуре.

Надежный API определяется измеряемым соответствием конкретному сценарию. MOS закрывает восприятие, WER и CER — текстовую точность, спектральные метрики — сравнение сигналов, TTFA и RTF — скорость. Для интеграции эти показатели следует держать раздельно и проверять одним воспроизводимым контуром.