Как мы голос для ИИ-ассистента выбирали или критерии оценки TTS-движков. nlp.. nlp. tts.. nlp. tts. голосовые ассистенты.. nlp. tts. голосовые ассистенты. ии-ассистент.. nlp. tts. голосовые ассистенты. ии-ассистент. клиентский сервис.. nlp. tts. голосовые ассистенты. ии-ассистент. клиентский сервис. синтез речи.. nlp. tts. голосовые ассистенты. ии-ассистент. клиентский сервис. синтез речи. телефония.

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

Первый шаг, который оказался совсем не тривиальным — договориться между собой о том, что вообще считать «хорошим голосом» для ИИ-агента. Без четких критериев любое сравнение превращается в спор о вкусах, а он их, как говорится, не спорят:) Если один говорит «звучит нормально», а другой — «меня раздражает», третий вообще никакой разницы не слышит, то в продакшене на таких субъективных оценках далеко не уедешь. я долго собирался с мыслями и решил написать на эту тему подробный отчет.

Эта статься посвящена первому шагу — формированию критериев отбора TTS-движка. Сравнение моделей я тут затрону вскользь, пока можно ориентироваться на данные, которые наш маркетинг опубликовал во время релиза нашего движка targetspeak. И, кстати, есть хороший обзор open source TTS-решений с точки зрения метрик у коллег из Raft. И если хватит сил и энергии, то чуть позже напишу собственный полноценный обзор.

Дисклеймеры: Всё описанное ниже не претендует на объективную истину. Выводы и трактовки основаны исключительно на моем личном опыте и опыте моей команды в работе с конкретными решениями в конкретном продакшен-контексте. Уровень технических деталей в тексте намеренно упрощен — этот текст ориентирован в первую очередь на технических менеджеров и CTO, принимающих архитектурные решения.

Онлайн vs офлайн: принципиально разные задачи

Прежде чем перейти к критериям — важное разграничение, которое часто упускают.

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

Онлайн-синтез — это то, что нужно нам: голосовой ассистент в реальном времени. Агент получил текст реплики → должен начать говорить достаточно быстро, чтобы диалог ощущался живым. Здесь всё иначе: задержка в 2–3 секунды — это уже дискомфорт для абонента. Нестабильная задержка — ещё хуже: агент то отвечает быстро, то «думает» неприлично долго без видимой причины.

Это разграничение напрямую влияет на приоритизацию критериев.

Шесть критериев, которые мы зафиксировали

1. Поддержка онлайн-режима: задержка и стабильность

Три конкретных параметра, которые нас интересовали:

Time-to-first-audio — как быстро агент «начинает говорить» после получения текста. Для телефонии комфортный порог — единицы сотен миллисекунд, не секунды.

Стабильность задержки — дисперсия важна не меньше, чем медиана. Если модель в среднем отвечает за 300 мс, но иногда уходит на 1,5 секунды — пользователь будет замечать именно эти «провалы».

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

2. Фонетическое качество

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

Есть один нюанс, который мы для себя зафиксировали: микро-отклонения от эталонного произношения иногда работают в плюс. Лёгкая «индивидуальность» голоса — условная небольшая особенность произношения — может на долю секунды заставить собеседника усомниться, что перед ним робот. Это тонкая грань между «человечно» и «странно», и в разных сценариях она разная. Но сам феномен стоит держать в голове.

Отдельная болевая точка для русского языка — ударения. Многие мультиязычные open source модели попросту не умеют работать с явным символом ударения в разметке. Без этой возможности «за́мок» и «замо́к», «му́ка» и «муки́» превращаются в лотерею при каждом прогоне. Для клиентского сервиса это критично: агент, неверно ставящий ударения, звучит некомпетентно.

3. Лёгкость добавления нового голоса

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

  • Объём датасета для дообучения — сколько минут/часов записей нужно для нового спикера,

  • Стоимость обучения — в GPU-часах и деньгах.

Чем меньше порог входа — тем быстрее можно запустить кастомный голос под конкретный бренд.

4. Качество клонирования голоса (voice cloning)

Смежный, но отдельный критерий. Некоторые архитектуры поддерживают zero-shot voice cloning: новый голос создаётся из одного референсного аудиофайла, без дообучения. Это удобно для быстрого прототипирования и для ситуаций, когда записать полноценный датасет нет возможности.

Оговорка: качество и стабильность zero-shot клонирования сильно зависят от конкретной архитектуры и тренировочных данных. Ошибка в произношении может проявляться не в каждом прогоне — что само по себе делает тестирование нетривиальным.

5. Просодия и интонации

Это то, что «обычный человек» имеет в виду, когда говорит «голос звучит как робот». Технически — про несколько вещей одновременно:

  • Монотонность на уровне фразы и абзаца — нет повышений и понижений тона, характерных для живой речи,

  • Механический ритм — слова идут с одинаковой длительностью, без естественного растягивания гласных в ключевых местах,

  • Отсутствие смысловых пауз — у человека паузы несут информацию, у плохого TTS они либо механические, либо их нет вовсе,

  • Отсутствие вокальных заполнителей — «эм…», «так…» — это не баг речи, а сигнал обработки. Их отсутствие само по себе может выдавать робота.

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

6. Отсутствие «металлического» эффекта

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

Как мы приоритизировали

Наша цель — максимально человекоподобный голос для AI-агента именно в телефонии. Исходя из этого контекста:

Приоритет 1 — must-have:

  • Человекоподобность (просодия + отсутствие «металла»)

  • Фонетическое качество

  • Поддержка онлайн-режима

Приоритет 2 — важно, но итерируемо:

  • Корректность ударений

  • Лёгкость добавления нового голоса

  • Клонирование голоса

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

Как измерять: бенчмарк-датасет

С критериями разобрались — теперь нужно не спорить «на вкус», а сравнивать по одной линейке.

Мы подготовили бенчмарк-датасет следующим образом:

  1. Выбрали 5 клиентов, которые явно выражали озабоченность качеством речи наших агентов. До старта собственного решения мы использовали вендорские сервисы — Яндекс SpeechKit, Salute Speech, 11Labs.

  2. Из истории диалогов этих агентов выгрузили аудио и попросили аналитиков, сопровождающих этих клиентов, отобрать реплики, которые звучали хуже всего — то есть те, которые реально «болели» в продакшене.

  3. Каждую реплику синтезируем каждым проверяемым вендором или моделью минимум 3 раза. Причина: инференс части моделей не идемпотентен — ошибка, например в ударении, может проявиться не в каждом прогоне. Один прогон даёт ложно-оптимистичную картину.

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

Автор: dmzubr

Источник