Голосовые ИИ-агенты, которые обзванивают клиентов или принимают заказы, часто перебивают собеседника или, наоборот, надолго замолкают. Причина — не в качестве речевых моделей, а в том, как эти системы определяют конец фразы. Все популярные платформы, включая OpenAI Realtime и Яндекс SpeechKit, используют детектор голосовой активности (VAD), который считает, что человек договорил, если тот замолчал на определённое число миллисекунд. Однако на живой русской речи такой подход даёт сбои: паузы возникают не только в конце мысли, но и когда говорящий подбирает слово, а акустически эти ситуации неразличимы. Различие лежит не в громкости или длительности тишины, а в том, что было сказано до паузы — именно это упускают все существующие VAD-решения.

Автор эксперимента, опубликованного в профильном потоке, синтезировал типовую фразу для входящего звонка и прогнал её через Yandex Realtime API, меняя только параметр silence_duration_ms. При пороге 400–800 миллисекунд ассистент мгновенно реагировал на приветствие и не слышал основной вопрос — VAD срабатывал в естественной паузе после «Здравствуйте!», и остаток реплики терялся. Только при 1200 миллисекундах фраза распознавалась целиком, но ценой 1,25 секунды тишины в трубке. При этом даже на большом пороге система периодически обрывала собеседника: из семи прогонов три раза ответ приходил на приветствие, а не по делу. Это показывает, что фиксированный таймер не просто медленный — он ещё и недетерминированный, поскольку естественные паузы в речи плавают от фразы к фразе.

Ключевая цифра эксперимента: из 1275 миллисекунд полной задержки 1200 миллисекунд — это заданный таймер, и лишь 75 миллисекунд уходит на распознавание, генерацию ответа и синтез речи. Это означает, что речевая модель работает почти мгновенно, а всё, что пользователь воспринимает как «тормоза», — это ожидание секундомера, который мы сами настроили. Ускорение модели или приближение серверов не даст эффекта, пока в схеме стоит фиксированный таймер. Проблема не в вычислениях, а в решении о том, что человек закончил говорить. Вывод автора однозначен: оптимизировать здесь нечего, пока не изменён сам принцип определения конца реплики.

Автор предлагает не отказываться от VAD, а дополнить его детектором на правилах русского синтаксиса, который анализирует уже распознанный текст и выбирает оптимальный таймер: если фраза явно завершена — 250 миллисекунд, если человек явно продолжает — 1400, а в сомнительных случаях — 700. Правила ловят висящие союзы и предлоги в конце («мне нужно два шкафа и»), инфинитивы без дополнения («сколько будет стоить»), заходы и приветствия («здравствуйте», «скажите пожалуйста»), заминки («ну это самое»), диктовку номеров телефонов и разговорные хвосты вопросов («это робот что ли»). Такой подход не требует обучения нейросети или GPU и полностью воспроизводим. Важно, что правила проверяются в определённом порядке — например, разговорные хвосты вопросов должны обрабатываться до общего правила о служебных словах, иначе они дадут ложное срабатывание.

На тестовом наборе из 72 реплик решение показало снижение средней задержки с 1200 до 316 миллисекунд, а число обрывов сократилось с 38 до двух. Для российского рынка, где голосовые роботы активно внедряются в колл-центры банков, телеком-операторов и интернет-магазинов, это особенно актуально. Сейчас клиенты часто жалуются на то, что «робот не даёт вставить слово» или «повисает на полминуты», что напрямую связано с настройками таймера. Предложенный метод позволяет радикально улучшить качество диалога без замены оборудования или моделей. В отличие от альтернатив, требующих больших вычислительных ресурсов и обучающих данных, правила работают мгновенно, легко настраиваются под конкретную предметную область и не зависят от дикции говорящего.

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

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