Пауза в голосовом боте была не в том, где я искал
В голосовом обзвоне для компании в Казахстане была пауза 3-3.5 секунды между репликой клиента и ответом бота. Для диалога это много, но где копать - непонятно. Могла быть задержка в сети, SIP-задержка, LLM, синтез голоса, любое комбо.
Достал логи сеансов из Voximplant и разложил паузу по деталям. Вышло: VAD-debounce 1050 миллисекунд, синтез речи ElevenLabs 770 миллисекунд до первого звука, буфер плеера 500 миллисекунд. Сложил. А основной вес - LLM. На mini-модели медиана полтора-две секунды, но выбросы доходили до восьми. Вот что я пропустил бы, глядя только на среднее.
Переехал с mini на nano и потом на OpenAI Realtime. Realtime для этого и проектировался: семантический VAD вместо механического debounce, встроенный barge-in, speech-to-speech в одном вызове. Пауза упала до 800 миллисекунд. Живой звонок на казахском не пошел - миграция свежая в проде, WhatsApp под Realtime не проверена, откат готов. Заказчик сказал, что паузы отличные.
Два вывода на класс. Первый: латентность диагностировать по таймингам в логах, а не по интуиции. Второй: в диалоге выбросы часто опаснее средней скорости, стабильность дороже медианы. Туда и ставить оптимизацию.
#голосовойбот #Voximplant #OpenAI #латентность #оптимизация #телефония #разработка
