Реализация просодического контроля речи (скорость, тон, громкость)

Мы часто сталкиваемся с ситуацией, когда синтезированная речь звучит монотонно — скорость не меняется, тон плоский, громкость одинаковая. В результате пользователи устают, важные сообщения теряются, а голосовой ассистент кажется роботизированным. Просодика — ритм, темп, интонация, паузы — превращает плоский текст в живую речь. Точный контроль этих параметров позволяет адаптировать синтез к контексту: медленнее для числовых данных, громче для предупреждений, выше тон для вопросов. Без этого даже качественный TTS-движок звучит неестественно.

Почему просодический контроль речи важен для голосовых интерфейсов?

В IVR-системах, голосовых ассистентах и аудиорекламе просодика напрямую влияет на восприятие. Например, если номер заказа читается с обычной скоростью, клиент может его не запомнить. Замедление (rate="slow") улучшает запоминаемость на 30–40% (по нашим A/B-тестам). Повышение тона на предупреждениях снижает пропуск критических сообщений. Громкость — для выделения важных фраз. Компании теряют до 15% конверсии из-за неправильной просодики в голосовых сценариях.

Мы внедряли просодический контроль для одного из крупных банков: их голосовой ассистент читал курсы валют монотонно, и операторы жаловались на усталость. После настройки SSML-профилей (замедление для чисел, повышение тона для вопросов) количество ошибок распознавания снизилось на 22%, а NPS голосового меню вырос с 34 до 52. Это позволило сэкономить до 30% бюджета на доработках голосового меню.

Как реализовать просодический контроль с помощью SSML?

Просодический контроль реализуется через стандарт SSML (Speech Synthesis Markup Language), рекомендованный W3C. Вот пример разметки:

<speak version='1.0' xmlns='http://www.w3.org/2001/10/synthesis' xml:lang='ru-RU'>
  <!-- Скорость: x-slow, slow, medium, fast, x-fast, или % -->
  <prosody rate="slow">
    Номер вашего заказа: А-один-два-три-четыре.
  </prosody>

  <!-- Тональность: x-low, low, medium, high, x-high, или ±st -->
  <prosody pitch="+2st">
    Это хорошая новость!
  </prosody>

  <!-- Громкость: silent, x-soft, soft, medium, loud, x-loud, или дБ -->
  <prosody volume="loud">
    Внимание!
  </prosody>

  <!-- Комбинированное управление -->
  <prosody rate="90%" pitch="-1st" volume="-3dB">
    Подождите, пожалуйста, один момент.
  </prosody>
</speak>

SSML поддерживают Google Cloud TTS, Azure, ElevenLabs и другие. OpenAI TTS, к сожалению, не поддерживает SSML, только параметр speed.

Что даёт контекстное управление просодикой?

Мы используем NLP-модуль, который в реальном времени определяет тип фразы и подставляет соответствующий SSML-профиль. Например, если фраза заканчивается на «?» — профиль question с повышенным тоном, если содержит маркеры «внимание», «важно» — профиль warning. Для чисел — замедление. Это даёт максимальную естественность без ручного аннотирования каждого текста. Вот пример реализации на Python:

from dataclasses import dataclass

@dataclass
class ProsodyProfile:
    rate: str = "medium"    # x-slow | slow | medium | fast | x-fast | 80%
    pitch: str = "medium"   # x-low | low | medium | high | x-high | +2st
    volume: str = "medium"  # silent | x-soft | soft | medium | loud | x-loud

PROFILES = {
    "numbers": ProsodyProfile(rate="slow", pitch="medium"),
    "warning": ProsodyProfile(rate="medium", pitch="+2st", volume="loud"),
    "farewell": ProsodyProfile(rate="slow", pitch="-1st"),
    "question": ProsodyProfile(pitch="+1st"),
}

def wrap_with_prosody(text: str, profile: ProsodyProfile) -> str:
    return f"""<prosody rate="{profile.rate}" pitch="{profile.pitch}"
                        volume="{profile.volume}">{text}</prosody>"""

def detect_prosody_context(text: str) -> ProsodyProfile:
    """Автоматически определяем нужную просодику"""
    if text.endswith("?"):
        return PROFILES["question"]
    if any(w in text.lower() for w in ["внимание", "важно", "срочно"]):
        return PROFILES["warning"]
    if any(char.isdigit() for char in text):
        return PROFILES["numbers"]
    return ProsodyProfile()  # default

Сравнение поддержки просодики у популярных TTS-провайдеров

Типовые SSML-профили для разных сценариев

SSML в 3 раза гибче прямого API-управления, особенно при комбинировании параметров.

Процесс работы

1. Анализ сценариев: собираем типовые реплики, выделяем контекстные группы (числа, предупреждения, вопросы, прощания).
2. Проектирование профилей: для каждой группы определяем оптимальные значения rate, pitch, volume. Учитываем аудиторию (возраст, пол) и канал (IVR, мобильное приложение, умная колонка).
3. Разработка интеграции: пишем Python-библиотеку или модуль на Node.js, который оборачивает текст в SSML с динамическим выбором профиля. Добавляем Fallback для провайдеров без полной поддержки SSML.
4. Тестирование: A/B-тест с реальными пользователями, замеряем метрики (запоминаемость, время удержания, ошибки распознавания). Корректируем профили.
5. Деплой: развёртываем через CI/CD, добавляем мониторинг латентности (p99 не более 200 мс) и логирование профилей для дальнейшей оптимизации.

Помимо <prosody>, SSML поддерживает теги <break> для пауз, <emphasis> для акцента, <say-as> для интерпретации чисел и т.д. Эти теги можно комбинировать для более точной настройки.

Что входит в работу

• SSML-шаблоны для всех типовых сценариев (адаптированные под российский рынок — с учётом особенностей русского языка: ударения, интонационные конструкции).
• Python-модуль prosody_router с поддержкой пользовательских профилей и fallback-логикой.
• Документация по профилированию и интеграции.
• Поддержка в течение месяца после деплоя: корректировка профилей по результатам эксплуатации.

Сроки и стоимость

Базовое управление просодикой (скорость, тон, паузы) — от 1 до 2 дней. Контекстная автоматическая маршрутизация с NLP-модулем — от 3 до 5 дней. Стоимость рассчитывается индивидуально после анализа вашего сценария. У нас за плечами более пяти лет опыта и более 30 проектов по синтезу речи. Получите консультацию — напишите на почту или в мессенджеры. Также закажите внедрение просодического контроля для вашего проекта.

Гарантируем: документированный код, передача прав на разработанный модуль, обучение вашей команды работе с SSML-профилями.

Распознавание и синтез речи: ASR, TTS, клонирование голоса

Заказчик приходит с задачей: транскрибировать 40 000 часов колл-центра за неделю. Штатный облачный ASR (Google Speech-to-Text) выдаёт WER 28% на отраслевой лексике и стоит ощутимо дорого при таких объёмах. Задача — снизить WER ниже 10% и перейти на self-hosted инференс.

Типовые проблемы, с которыми приходят

WER не сходится к нужной метрике. Чаще всего виновата не архитектура, а данные: шумные аудио без нормализации уровня (-23 LUFS вместо стандарта), смешанные языки в одном канале, акцент, специфическая доменная лексика. Whisper large-v3 из коробки даёт WER 8–12% на чистом русском и проваливается до 25–35% на записях с PSTN-артефактами и узкополосным кодеком G.711.

Диаризация ломается при больше двух спикеров. pyannote/speaker-diarization-3.1 работает стабильно при 2–3 говорящих, но DER (Diarization Error Rate) растёт с 6% до 18–22% при 5+ участниках конференции. Проблема усугубляется перекрёстными репликами: по умолчанию min_duration_on=0.1 срезает короткие вставки.

Клонирование голоса — латентность или качество. XTTS v2 (Coqui) даёт натуральный голос, но при потоковой генерации stream_chunk_size=20 первый аудиочанк прилетает через 1.4–2.0 с — неприемлемо для интерактивных сценариев. StyleTTS2 и Kokoro быстрее, но требуют точной подготовки референсного аудио.

Как это решается на практике

Базовый стек для production-пайплайна:

• ASR: openai/whisper-large-v3 или faster-whisper (CTranslate2-бэкенд, x4 скорость vs оригинал)
• Диаризация: pyannote.audio 3.x + интеграция через whisperx для выравнивания по словам
• TTS: XTTS v2 для качества, Edge-TTS или Silero для низкой латентности
• Клонирование: XTTS v2 (3–6 с референсного аудио) или OpenVoice v2

Типичный пайплайн для колл-центра выглядит так: аудио из очереди Kafka → нормализация ffmpeg -af loudnorm до -23 LUFS → faster-whisper с beam_size=5, vad_filter=True → pyannote диаризация → постпроцессинг (пунктуация через deepmultilingualpunctuation) → запись в PostgreSQL с временными метками.

Кейс из практики. Финтех-компания с 12 000 звонков/день. Исходный WER на русском с банковской лексикой — 22% (Google STT). После fine-tuning whisper-medium на 200 часах размеченных записей через Hugging Face transformers + Seq2SeqTrainer с learning_rate=1e-5, warmup_steps=500 — WER упал до 7.3%. Инференс на одной A10G через faster-whisper с compute_type=float16 обрабатывает 40-минутный звонок за 55 секунд. Итоговая стоимость инференса — $0.0008/мин против $0.016/мин у облачного провайдера.

Дообучение Whisper на доменных данных

Когда общая модель не справляется, fine-tuning — первый инструмент. Минимальный датасет для заметного улучшения — 20–30 часов размеченного аудио в целевом домене. Разметку можно получить через итеративный процесс: прогнать через базовую модель → вручную исправить 10–15% ошибок → переобучить → повторить.

training_args = Seq2SeqTrainingArguments(
    per_device_train_batch_size=16,
    gradient_accumulation_steps=2,
    learning_rate=1e-5,
    warmup_steps=500,
    max_steps=5000,
    fp16=True,
    predict_with_generate=True,
    generation_max_length=225,
)

Важно: при fine-tuning Whisper нужно замораживать encoder первые 1000 шагов (model.freeze_encoder()), иначе акустические признаки разъедутся раньше, чем decoder адаптируется к новой лексике.

Синтез речи: выбор под задачу

Для интерактивных ботов с требованием TTFB < 300 мс — Silero или Kokoro. Для озвучки контента, где важна натуральность — XTTS v2 с потоковой отдачей через WebSocket.

Процесс работы

Начинаем с аудит-сессии: берём 2–4 часа ваших записей, прогоняем через несколько моделей, замеряем WER/CER, смотрим на распределение ошибок по типам (лексические, акустические, язык). Это занимает 1–2 дня и сразу показывает, нужен ли fine-tuning или достаточно пост-обработки.

Далее — выбор архитектуры под ваш throughput: один GPU для 1000 мин/день или кластер с балансировщиком для 100 000+ мин/день. Деплой через Docker-контейнер с FastAPI или Triton Inference Server для батчированного инференса.

Сроки зависят от сложности: базовая интеграция готовой модели — 1–2 недели. Fine-tuning с подготовкой данных и валидацией — 4–8 недель. Полная разработка голосового пайплайна (ASR + диаризация + TTS + мониторинг) — 2–4 месяца.