Мы сталкивались с ситуацией: голосовой бот обрывал клиента на середине фразы, потому что порог тишины был слишком жёстким. Или наоборот — повисал на 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: на открытых вопросах порог увеличивается, на командах — снижается.
| Тип запроса | Порог тишины (мс) | Пример |
|---|---|---|
| Открытый вопрос | 1200 | «Расскажи о себе» |
| Да/нет | 500 | «Включи свет?» |
| Команда | 600 | «Отключи музыку» |
Как мы это делаем: стек и реализация
Используем 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,
}
Подробнее об адаптивном классификаторе
Классификатор намерений — это lightweight модель (DistilBERT или TinyBERT), которую мы запускаем на первых 300 мс аудио. Она предсказывает тип запроса до того, как пользователь закончит речь. Это позволяет заранее установить порог тишины и сократить общее время ожидания. Средняя точность предсказания — 94% на наших данных.
Сравнение VAD-решений
| VAD | Точность на шумах | Latency (p99) | CPU Load |
|---|---|---|---|
| Silero VAD (ONNX) | 0.97 | 50 мс | Низкая |
| WebRTC VAD | 0.85 | 10 мс | Очень низкая |
| RNNoise | 0.91 | 30 мс | Средняя |
Выбор VAD — компромисс между точностью и ресурсами. Для контакт-центра мы рекомендуем Silero, для IoT — WebRTC. Latency p99 критичен для голосовых ботов: при превышении 100 мс диалог становится неестественным.
Процесс работы над endpointing
- Анализ — собираем записи диалогов, замеряем текущие метрики (latency, ошибки).
- Проектирование — выбираем VAD (обычно Silero), задаём конфигурацию порогов, решаем, нужен ли адаптивный классификатор.
- Реализация — интегрируем детектор в голосовой поток (WebRTC или собственная реализация). Добавляем мониторинг через MLflow.
- Тестирование — A/B тест на 10% трафика, сравниваем с текущим решением.
- Деплой — контейнеризация, запуск на 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%.
Получите консультацию: пишите — мы оценим ваш проект и предложим решение.