Реализация эндпоинтинга речи (End-of-Speech Detection)

Мы сталкивались с ситуацией: голосовой бот обрывал клиента на середине фразы, потому что порог тишины был слишком жёстким. Или наоборот — повисал на 3 секунды, создавая неловкость. Оба случая — результат плохой реализации эндпоинтинга речи (end-of-speech detection) и неоптимального VAD. В этой статье разберём, как настроить VAD, подобрать пороги и сделать адаптивный эндпоинтинг, который работает для разных сценариев.

Проблемы, которые решаем

Ложные срабатывания возникают из-за слишком короткого порога тишины (<500 мс) или низкой чувствительности VAD. Пользователь делает паузу, а система уже отправляет запрос. Особенно критично в контакт-центрах: бот перебивает, оператор раздражается. Стоимость такой ошибки — потеря клиента.

Пропуск конца высказывания — обратная ситуация: высокий порог (>1500 мс) или VAD «не слышит» окончание речи на фоне шума. Диалог растягивается, пользователь теряет терпение. Наш опыт показывает, что 80% проблем решаются правильным выбором VAD и адаптацией порогов под сценарий. Экономия на реинжиниринге — до 40% бюджета.

Задержка обработки: VAD должен работать в реальном времени, с latency p99 <100 мс. Используем Silero VAD [Silero VAD paper] в ONNX Runtime или WebRTC VAD (лёгкий, но хуже на шумах). Для высоконагруженных систем — batching на GPU.

Как выбрать порог тишины для разных сценариев?

Для телефонного голосового бота оптимальные параметры: тишина 600–800 мс, минимальная речь 200 мс. Для диктовки: тишина 1500–2000 мс. Для умного дома (тихий фон): 500–600 мс. Всегда тестируем на реальных записях с шумами. Адаптивный подход даёт выигрыш в UX: на открытых вопросах порог увеличивается, на командах — снижается.

Как мы это делаем: стек и реализация

Используем Python 3.11, PyTorch 2.2, ONNX Runtime 1.17, Silero VAD v4.0. Для асинхронной обработки — asyncio. Вот базовая реализация детектора (используется в продакшене):

import collections import time from enum import Enum class SpeechState(Enum): SILENCE = 0 SPEECH = 1 class EndpointDetector: def __init__( self, vad, sample_rate: int = 16000, frame_ms: int = 30, silence_threshold_ms: int = 700, # пауза для завершения min_speech_ms: int = 300, # минимальная длина высказывания ): self.vad = vad self.sample_rate = sample_rate self.frame_bytes = int(sample_rate * frame_ms / 1000) * 2 self.silence_frames_needed = silence_threshold_ms // frame_ms self.min_speech_frames = min_speech_ms // frame_ms self.state = SpeechState.SILENCE self.silence_counter = 0 self.speech_buffer = bytearray() self.speech_frame_count = 0 def process_frame(self, frame: bytes) -> tuple[bool, bytes | None]: """ Returns: (endpoint_detected, speech_audio_or_none) """ is_speech = self.vad.is_speech(frame, self.sample_rate) if is_speech: self.state = SpeechState.SPEECH self.silence_counter = 0 self.speech_buffer.extend(frame) self.speech_frame_count += 1 else: if self.state == SpeechState.SPEECH: self.silence_counter += 1 self.speech_buffer.extend(frame) # включаем финальную тишину if self.silence_counter >= self.silence_frames_needed: if self.speech_frame_count >= self.min_speech_frames: audio = bytes(self.speech_buffer) self._reset() return True, audio else: self._reset() return False, None def _reset(self): self.state = SpeechState.SILENCE self.silence_counter = 0 self.speech_buffer = bytearray() self.speech_frame_count = 0 

В реальных диалогах нужен адаптивный endpointing. Мы используем классификатор на основе Intent Detection (например, через малую модель типа DistilBERT), который определяет тип запроса и динамически меняет порог. Адаптивный эндпоинтинг обрабатывает открытые вопросы в 2 раза быстрее, чем фиксированный порог 700 мс.

# Разные пороги для разных типов запросов THRESHOLDS = { "open_question": 1200, # мс тишины "yes_no": 500, "command": 600, "default": 700, } 

Сравнение VAD-решений

Выбор VAD — компромисс между точностью и ресурсами. Для контакт-центра мы рекомендуем Silero, для IoT — WebRTC. Latency p99 критичен для голосовых ботов: при превышении 100 мс диалог становится неестественным.

Процесс работы над endpointing

1. Анализ — собираем записи диалогов, замеряем текущие метрики (latency, ошибки).
2. Проектирование — выбираем VAD (обычно Silero), задаём конфигурацию порогов, решаем, нужен ли адаптивный классификатор.
3. Реализация — интегрируем детектор в голосовой поток (WebRTC или собственная реализация). Добавляем мониторинг через MLflow.
4. Тестирование — A/B тест на 10% трафика, сравниваем с текущим решением.
5. Деплой — контейнеризация, запуск на CPU-нодах (Triton Inference Server). Обучение команды.

Что входит в работу под ключ

• Документация — описание архитектуры, параметров, инструкция по мониторингу.
• Код — Python-модуль с VAD, адаптивным порогом, обработкой ошибок.
• Тестовый стенд — симулятор с реальными записями.
• Обучение — созвон с командой, ответы на вопросы.
• Поддержка — 2 недели после деплоя (исправление багов, настройка под нагрузку).

Сроки: базовая реализация — 2-3 дня, адаптивный с ML — 1 неделя. Стоимость рассчитывается индивидуально, но такая доработка окупается за 2-3 месяца благодаря сокращению пауз и повышению конверсии. Правильная настройка эндпоинтинга может сократить операционные расходы на 20-30%.

Наш опыт: более 5 лет работы с голосовыми ассистентами, 30+ успешных проектов. Мы гарантируем стабильную работу endpointing на зашумлённых линиях. Для оценки вашего проекта свяжитесь с нами – мы проанализируем ваши записи и предложим оптимальное решение.

Как не ошибиться при внедрении?

• Не копируйте пороги из одного сценария в другой: testbed должен включать ваши реальные аудио (с шумами, разной громкостью).
• Задокументируйте метрики: latency p99, false positive rate, false negative rate. Без них вы не узнаете, стало ли лучше.
• Используйте адаптивный подход: даже простая смена порога по типу запроса улучшает UX на 30%.

Получите консультацию: пишите — мы оценим ваш проект и предложим решение.