Barge-in и latency budget: человечный диалог

Диагностика задержки в продакшне

Бюджет из второго шага — это план. В продакшне нужно видеть реальную задержку каждого звонка, иначе оптимизация идёт вслепую: непонятно, какой компонент тормозит и помог ли вообще внесённый приём.

Таймстемпы по компонентам

Достаточно зафиксировать момент каждой передачи между блоками пайплайна. Минимальный набор на одну реплику клиента:

• speech_end — end-of-turn зафиксировал конец реплики клиента
• stt_final — финальный транскрипт готов
• llm_first_token — пришёл первый токен ответа
• tts_first_audio — синтез выдал первый аудиочанк
• playback_start — клиент услышал первый звук ответа

Разности между соседними таймстемпами и есть бюджет, измеренный на живом звонке, а не оценочный:

t = {}
t["speech_end"]      = now()   # end-of-turn сработал
t["stt_final"]       = now()   # транскрипт финализирован
t["llm_first_token"] = now()   # первый токен ответа
t["tts_first_audio"] = now()   # первый чанк синтеза
t["playback_start"]  = now()   # клиент услышал ответ

log_latency(call_id, {
    "stt_ms": t["stt_final"]      - t["speech_end"],
    "llm_ms": t["llm_first_token"] - t["stt_final"],
    "tts_ms": t["tts_first_audio"] - t["llm_first_token"],
    "total_ms": t["playback_start"] - t["speech_end"],
})

Почему среднее обманывает

По одному числу — среднему — задержку оценивать нельзя: оно прячет хвосты. Холодный старт, сетевой всплеск, неожиданно длинный ответ LLM бьют по отдельным звонкам, и именно эти звонки портят впечатление, а в среднем растворяются. Поэтому задержку смотрят по перцентилям: p50 (медиана — типичный звонок), p95 и p99 (хвост — худшие случаи).

Если p50 равен 700 мс, а p95 — 3 секунды, значит каждый двадцатый клиент ждёт три секунды и думает, что его не услышали. Оптимизировать нужно именно p95, а не среднее: подтянуть хвост важнее, чем сдвинуть и без того приемлемую медиану.