Голосовой агент обрывает клиента на паузе: настройка конца реплики

Клиент говорит: «Запишите меня на…» — и останавливается, чтобы посмотреть календарь. Агент немедленно спрашивает дату. Клиент продолжает: «…четверг после трёх», но два голоса уже накладываются. Распознавание слов может работать правильно, модель умеет записывать на приём, а разговор всё равно неудобен. Система слишком рано решила, что клиент закончил свою реплику.

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

Найдите момент, когда разговор свернул не туда

Возьмите несколько обезличенных тестовых записей с паузами. Для каждой отметьте конец последнего звука первой части, начало продолжения, реальный конец всей реплики и начало ответа агента. Сопоставьте их с событиями input_audio_buffer.speech_started и input_audio_buffer.speech_stopped, а также с созданием ответа. Используйте одну временную шкалу записи или приведённые к ней события.

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

Пауза сама по себе не содержит ответа на вопрос, закончил ли человек. После «да» она часто означает завершение, после «я хотел бы уточнить…» — продолжение. Поэтому единый таймаут приходится подбирать под реальные реплики, а не под одну красивую демонстрацию.

Выберите способ определения конца хода

В OpenAI Realtime режим server_vad опирается на тишину. Параметр silence_duration_ms задаёт её длительность для определения остановки. Увеличение значения помогает пережить более длинные паузы, но замедляет ответ после короткой законченной фразы. Параметр threshold относится к порогу обнаружения речи: его изменение не заменяет настройку ожидания.

Режим semantic_vad учитывает завершённость сказанного. Для неспешной записи на приём разумно проверить eagerness: low. Начните с него как с кандидата, затем сравните с текущей конфигурацией на одинаковых записях. Доступность режима проверьте для выбранной сессии и модели.

В установленной speech-to-speech сессии отправьте через управляющий канал следующее JSON-событие. Это настройка входного аудио; она не меняет ваш инструмент записи в календарь.

{
  "type": "session.update",
  "session": {
    "type": "realtime",
    "audio": {
      "input": {
        "turn_detection": {
          "type": "semantic_vad",
          "eagerness": "low",
          "create_response": true,
          "interrupt_response": true
        }
      }
    }
  }
}

Дождитесь подтверждения обновления сессии и проверьте фактически принятые параметры. Здесь create_response включает создание ответа после обнаруженного конца хода, а interrupt_response разрешает прерывание ответа при новой речи. Эти поля относятся к разговорной сессии. Если приложение само вызывает создание ответа, согласуйте этот путь с настройкой, чтобы не получить конкурирующие решения.

Проверьте две ошибки одновременно

Подготовьте набор фраз, похожих на целевые звонки: законченный короткий ответ, длинное описание проблемы, размышление с паузой, исправление даты и диктовку нескольких значений. Включите спокойную речь и типичный для вашего канала фон. Для реплики с паузой заранее отметьте, где человек действительно закончил мысль; иначе ранний ответ легко ошибочно посчитать быстрым.

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

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

Не позволяйте паузе запускать запись в CRM

Даже хороший определитель конца хода иногда ошибается. До вызова инструмента проверьте, что собраны обязательные поля и человек подтвердил итог. В примере с записью агент должен сначала повторить выбранные дату и время. Фрагмент «на четверг… нет, лучше пятницу» нельзя превращать в две записи только потому, что аудиопоток был разбит на два хода.

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

В платном курсе Voice AI Agents PRO вы разберёте VAD, end-of-turn detection, barge-in, Realtime-сессии и оценку качества звонков. Это следующий шаг от настройки одного таймаута к управляемому разговору с инструментами. Откройте программу и пробный урок о VAD.

Если после исправления конца хода клиент всё ещё слышит устаревшую реплику, переходите к разбору позднего аудио после перебивания. Там нужно проверять воспроизведение и отмену уже созданного ответа.