Голосовой ИИ для входящих звонков: как выбрать решение по задержке и качеству

Голосового ИИ «без задержки» не существует, поэтому выбирать нужно по измеренной задержке всего разговора в реальных звонках и по тому, насколько естественно система управляет очередностью реплик: когда начинает говорить, когда замолкает и как реагирует на перебивания. Цифра «время ответа модели — N миллисекунд» из демонстрации или с сайта поставщика описывает только один слой. Клиент слышит их сумму: определение конца фразы, распознавание речи, решение модели, запрос к CRM или календарю, синтез голоса и телефонную сеть.

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

Из чего складывается пауза в голосовом разговоре

Для клиента пауза — время между моментом, когда он замолчал, и моментом, когда услышал голос бота. За это время последовательно или частично параллельно происходят несколько шагов.

1. Определение конца реплики. Система должна понять, что человек закончил говорить, а не просто сделал паузу, чтобы подумать. Для этого используют детектор голосовой активности, анализ текста или отдельную модель определения очередности. Большинство платформ ждут минимальный период тишины, прежде чем закрыть реплику. Например, в одной из типовых конфигураций голосовой платформы минимальное ожидание составляет 0,5 секунды, максимальное — 3 секунды. Это пример настроек, а не универсальная норма или гарантия задержки.
2. Распознавание речи. Преобразование аудио в текст, если архитектура каскадная. Часть распознавания может происходить в потоке, пока человек ещё говорит.
3. Решение модели. Языковая модель формирует ответ. Важно не общее время генерации, а время до первых слов, которые уже можно произнести.
4. Обращение к внешним системам. Проверить свободное время в календаре, найти клиента в CRM, узнать статус заказа. Этот шаг часто добавляет больше времени, чем сама модель, и полностью зависит от скорости ваших систем.
5. Синтез речи. Преобразование текста в голос; здесь тоже важно время до первого звука.
6. Телефония и сеть. Передача аудио между оператором связи, платформой и серверами, где работают модели. Здесь имеют значение регион серверов и маршрут звонка.

Поэтому демонстрация в браузере с гарнитурой может казаться быстрее настоящего звонка: обычно в ней нет телефонной сети, шума, обращения к CRM и клиента, который говорит отрывками.

Какие архитектуры сравнивать

На рынке в основном встречаются два подхода.

Каскад «распознавание → модель → синтез». Для каждого шага используются отдельные компоненты, часто от разных поставщиков. Преимущества: можно отдельно выбрать лучшее распознавание для нужного языка, нужный голос и нужную модель; проще вести журнал текста каждого шага. Недостатки: каждое звено добавляет задержку и собственную точку отказа, а оркестрация между ними — отдельная инженерная задача.

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

Таблица не определяет победителя: она показывает, какие вопросы задать каждому кандидату.

Ни один подход нельзя назвать всегда лучшим. Realtime-модель может выиграть в коротком разговоре без интеграций и проиграть, когда для каждого ответа нужен запрос в CRM. Каскад может быть медленнее, но лучше распознавать названия улиц и фамилии на вашем языке. Ответ даст только тест на ваших сценариях.

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

Почему важно перебивание

В живом разговоре люди постоянно перебивают друг друга: «да-да», «нет, не тот», «подождите». Голосовой агент должен различать три ситуации:

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

У платформ есть отдельные настройки перебиваний: минимальная длительность речи, после которой бот останавливается, время восстановления после ложного перебивания, порог по числу слов или длительности голоса, а также пауза перед продолжением. Обнаружение голосовой активности обычно реагирует быстрее анализа распознанного текста, но может быть чувствительнее к фоновому шуму. Проверьте параметры именно выбранной версии платформы.

Есть ещё одна тонкость, которую легко упустить: бот должен помнить, что клиент действительно услышал. Если бот начал говорить «Ваша запись подтверждена на четверг в 15:00, а также…», а клиент перебил на слове «четверг», в истории разговора нельзя сохранять, будто клиент услышал и время, и всё, что должно было прозвучать дальше. Иначе следующий ответ будет опираться на информацию, которую человек не получил.

Тест настоящего звонка

Сравнивать кандидатов стоит по единому протоколу. Ниже предложен протокол пилота; в рамках этой статьи он не проводился, и результаты не представлены.

Предлагаемый протокол: 20 одинаковых сценариев

Сценарии. 20 сценариев, одинаковых для всех кандидатов, например:

• запись на услугу с выбором даты и времени;
• перенос существующей записи;
• вопрос о цене, ответ на который берётся из справочника;
• просьба соединить с сотрудником;
• произнесение номера телефона или заказа по цифрам;
• название улицы, фамилия, название препарата или товара, которые трудно распознать.

Усложнения. Для части звонков добавьте фоновый шум (улица, офис, автомобиль) и паузу в середине реплики, когда клиент замолчал подумать, но ещё не закончил фразу.

Условия. Настоящая телефония, а не браузерная демонстрация; регион серверов, который вы планируете использовать; язык или языки ваших клиентов.

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

Повторения. 20 звонков на кандидата недостаточно для стабильного 95-го перцентиля. Каждый сценарий стоит повторить несколько раз с разными голосами участников теста.

Таблица для фиксации каждого звонка:

Задержку лучше измерять по записи звонка со стороны абонента, а не по системным журналам: журналы показывают время обработки, но не то, что слышит человек.

Метрики: что сравнивать

Время до первой слышимой реакции. От конца речи клиента до первого звука бота, который слышит абонент. Это главная метрика воспринимаемой скорости.

p50 и p95. p50 — медиана: половина ответов быстрее, половина медленнее. p95 — значение, медленнее которого лишь 5% ответов. Среднее здесь подходит плохо: несколько очень длинных пауз могут скрываться за хорошим средним, а клиент запоминает именно их. Для p95 нужно достаточно измерений: при двадцати звонках это фактически одно-два самых медленных значения.

Ложные и пропущенные перебивания. Сколько раз бот остановился из-за шума и сколько раз продолжал говорить, когда клиент пытался его перебить.

Качество распознавания критических данных. Имена, номера, даты, адреса. Ошибка в номере телефона дороже ошибки в слове приветствия.

Успешное выполнение задачи. Записан ли клиент, перенесена ли запись, соединён ли он с нужным сотрудником.

Передача оператору. Сколько времени занимает, проходит ли звонок и получает ли оператор краткое описание разговора.

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

Выбор и бюджет

Цена минуты одного компонента не равна стоимости звонка. Типичные расходы состоят из нескольких слоёв:

• телефония: номер, входящие минуты, переадресация;
• платформа оркестрации голосового агента, если она отдельная;
• распознавание речи;
• языковая или realtime-модель — часто оплата зависит от объёма аудио- и текстовых токенов, а не от минут;
• синтез речи;
• вызовы инструментов и внешних сервисов;
• хранение записей и транскриптов;
• время сотрудников на звонки, переданные оператору.

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

Практически стоимость типового звонка удобно считать как сумму слоёв для одного и того же разговора:

> стоимость звонка = телефония × длительность + платформа × длительность + распознавание (за минуту или объём) + модель (за объём входящего и исходящего аудио или текста) + синтез (за объём речи бота) + вызовы инструментов × количество + доля звонков, переданных оператору × стоимость минуты оператора × средняя длительность после передачи

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

Остальные критерии выбора:

• качество для вашего языка и словаря — по итогам теста, а не по списку поддерживаемых языков;
• поведение на p95, а не только в среднем;
• интеграции с вашей телефонией, CRM и календарём и их вклад в задержку;
• передача оператору вместе с контекстом;
• журналы и записи для разбора проблемных звонков;
• условия обработки данных: где обрабатываются записи, используются ли они для обучения и как их удалить;
• поддержка поставщика и предсказуемость изменений API и тарифов.

Что сделать в своём процессе

1. Выберите 15–20 типичных сценариев входящих звонков, в том числе соединение с сотрудником и данные, которые трудно распознать.
2. Задайте критерии приёмки до теста: допустимые p50 и p95 времени до первой слышимой реакции, долю выполненных задач и долю правильно распознанных номеров.
3. Проведите одинаковый тест для двух-трёх кандидатов через настоящую телефонию, с шумом и паузами, с CRM и без неё.
4. Измеряйте со стороны абонента и сохраняйте записи для разбора.
5. Рассчитайте стоимость типового звонка по всем слоям для каждого кандидата.
6. Отдельно оцените настройки пауз и перебиваний: иногда они влияют на опыт сильнее, чем смена модели.
7. Принимайте решение по совокупности: качество, p95, интеграции, стоимость и поддержка, а не только по минимальной медиане.

Частые вопросы