Голосовой ИИ без магии: что проверить до подключения SIP-линии

Фраза «подключим голосового агента к телефону» звучит как один переключатель. В реальной эксплуатации это цепочка из нескольких систем, и каждая влияет на итоговый разговор. Телефонный оператор ведёт сигнализацию и медиапоток, SIP-стек устанавливает сессию, аудиоустройства передают звук, распознавание речи превращает его в текст, агент формирует ответ, синтез речи возвращает аудио, а бизнес-правила решают, когда продолжать диалог и когда остановиться или передать ситуацию человеку. Если назвать всю цепочку просто «ботом», ожидания станут опасно завышенными.

SIP — протокол управления сессиями, а не обещание одинакового поведения любого провайдера. В RFC 3261 описаны создание, изменение и завершение мультимедийных сессий. Но конкретный транк добавляет собственные требования: формат учётной записи, адрес регистратора, правила набора номера, доступные кодеки, DTMF, ограничения исходящих вызовов, NAT и сетевую политику. Поэтому формулировка «работает с любой телефонией» плоха даже тогда, когда интеграция провайдер-нейтральна по замыслу. Честнее говорить: совместимость подтверждается тестом с выбранным оператором и его конфигурацией.

Из каких участков состоит маршрут

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

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

Третий участок — STT и TTS. AiHummer описывает отдельный контур распознавания и синтеза речи, однако его наличие не отменяет настройки и проверки качества. Локальный голосовой путь работает по репликам: система ждёт завершения фразы, распознаёт её, получает ответ агента и синтезирует звук. Это не то же самое, что непрерывный разговор с мгновенным перебиванием. Realtime-режим может поддерживать barge-in, но зависит от выбранного внешнего движка, ключей и его условий. Значит, в требованиях надо записать желаемую модель диалога, а не абстрактное «естественно разговаривает».

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

Где нужен человек

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

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

Практический пилот

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

Измеряйте минимум четыре группы сигналов. Технические: доля успешных регистраций и звонков, односторонний звук, обрывы, задержка по участкам. Речевые: доля непонятых реплик, повторные вопросы, ошибки в именах и числах. Процессные: корректно созданные заявки, полнота полей, доля эскалаций и причины. Пользовательские: завершил ли человек цель и пришлось ли ему повторять сказанное. Среднее значение не должно скрывать хвосты; отдельно смотрите длинные задержки и проблемные типы звонков.

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

Ограничения, которые стоит назвать заранее

Голосовой контур требует совместимой инфраструктуры и настройки. Локальный режим диалога пошаговый и не обещает barge-in; realtime-возможности зависят от выбранного движка. DTMF и навигация по IVR не универсальны для каждого режима. Внешние STT/TTS или телефонный оператор могут иметь собственные тарифы, лимиты и правила обработки данных. Работоспособная установка не равна готовому бизнес-процессу: нужны тесты сценариев, разрешений, эскалации и качества звука. Наконец, время ответа, доступность и результат разговора нельзя гарантировать без измеренного SLO и реальной эксплуатации.

Чек-лист перед запуском

1. Зафиксировать оператора, SIP-параметры, кодеки, DTMF и правила набора.
2. Проверить регистрацию, входящий и исходящий звонок, звук в обе стороны.
3. Выбрать и настроить STT/TTS, измерить задержку и качество на реальных голосах.
4. Ограничить инструменты и права для неизвестных звонящих.
5. Описать точные условия и маршрут эскалации человеку.
6. Решить вопрос записи, уведомления, доступа и срока хранения до включения.
7. Подготовить эталонные и отказные диалоги, владельцев и стоп-критерии.
8. Снимать технические, речевые и процессные метрики отдельно.
9. Расширять поток только после разбора ошибок пилота.

Голосовой агент становится полезным не тогда, когда его называют «живым», а когда вся цепочка предсказуема, её границы видны, а оператор знает, что произойдёт при сбое. Если вы планируете пилот, начните со схемы маршрута и требований выбранного SIP-провайдера, а затем сравните их с документацией AiHummer — без обещаний до проверки.