Voicemail-детектирование в исходящих AI-звонках: разбор Vapi, Retell, Bland, Pipecat, LiveKit и почему мы написали своё

Запустить AI-голосового агента сегодня - проект на выходные. Поднимаете Vapi или Retell, прописываете промпт, привязываете SIP - и бот звонит. А вот распознать, кто реально взял трубку, и подключиться достаточно быстро, чтобы не упустить живого человека - это та часть, на которой ломается каждый outbound-стек.

Если вы строите outbound (продажи, ресерч, поддержку) - это решение принимается первым. Промахнётесь с детектированием - агент будет питчить голосовую почту. Промахнётесь со скоростью - человек уже положил трубку.

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

Когда вы делаете исходящий звонок, трубку может взять:

Каждый случай требует разной реакции. Если ваш агент думает, что говорит с человеком, а на линии IVR - вы сжигаете минуты разговора, портите статистику и легко получаете жалобы. Если же на линии живой человек, а агент ждёт три-пять секунд "подтверждения" - человек кладёт трубку, потому что слышит тишину.

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

Vapi - один из самых популярных voice-AI-сервисов. Voicemail Detection из коробки умеет работать через несколько провайдеров:

Источник: docs.vapi.ai. Удобно, что можно переключаться, но непрозрачно, когда что-то ломается. Если детектирование промахивается, ваш агент уже разговаривает с автоответчиком, а вы узнаёте об этом по логам.

Retell - конкурент Vapi с собственным real-time-классификатором. Из их документации: добавляет менее 30 мс задержки. Цифру по точности они официально не публикуют - в комьюнити встречаются жалобы на ~15% ложных срабатываний, но проверить это нечем.

Источник: docs.retellai.com/build/handle-voicemail.

Bland пошли путём собственной модели - дообучили Wav2Vec2 на voicemail-данных. Модель опубликована на Hugging Face одним из их инженеров: huggingface.co/jakeBland/wav2vec-vm-finetune.

Ограничения, заявленные ими самими:

То есть на стандартных голосовых почтах работает хорошо, на edge cases - проседает.

Если вы хотите рулить стеком сами, есть два основных фреймворка.

Open-source-фреймворк от Daily. Из коробки есть класс VoicemailDetector - он работает через STT + LLM-гейтинг: транскрибируем приветствие, скармливаем LLM, она решает.

Источник: docs.pipecat.ai/pipecat/fundamentals/voicemail.

Встроенного детектора у LiveKit нет. Зато есть prewarm - функция, которая предзагружает модели в worker'ы один раз при старте. Это удобно, чтобы держать классификатор горячим и не платить latency на холодный запуск. Сам классификатор - ваш.

В их же документации есть пример, где human/machine/IVR детектируется через LLM-классификацию транскрипта приветствия.

Если вы используете Vapi через Twilio - под капотом часто работает классический Twilio Answering Machine Detection. Вопреки распространённому мифу, это уже не чистый DSP - Twilio в маркетинге пишут, что под AMD сидит ML-классификатор с заявленной точностью ~94% на США/Канаде.

Что важно знать:

Если посмотреть на список целиком - все они отвечают по сути на один бинарный вопрос: это голосовая почта или нет.

IVR, колл-скриннеры, Hiya, человек в шумной обстановке, человек с длинной паузой перед "Hello" - всё это сваливается в один класс "не-voicemail". А реакция на эти случаи нужна разная.

Это не упрёк - просто наблюдение о форме рынка. Большинство сценариев исходящего AI-звонка действительно сводятся к "автоответчик или человек". Но если ваш сценарий шире (например, нужно отдельно различать колл-скриннер и человека, чтобы выбрать тактику разговора) - готового решения сейчас нет.

Мы оценили все эти варианты - часть погоняли в проде, часть пристально изучили. Ни один не вытянул нашу планку. Поэтому собрали свой decision-слой. Три ключевые вещи.

Стандартный подход: дождаться полного приветствия ("Hi, you've reached John, leave a message after the beep"), отправить в классификатор, получить ответ. Это секунды.

Мы пошли иначе. Каждый частичный фрагмент транскрипта пролетает через полный цикл принятия решения. Накопили достаточно сигнала - подключаемся. Именно отсюда берётся "подключение с первой фразы".

Это потребовало серьёзной оптимизации latency на каждом шаге - но окупилось.

Мы пробовали попросить AI спроектировать правила. Получили ~200 строк ветвлений, которые в итоге заменили двумя.

Объясню, почему это важно. AI хорошо генерирует "разумно выглядящий" код, но fusion-логика для real-time decision-making требует понимания того, какие сигналы в каком порядке и с каким весом приходят. Без этого получаются деревья if/else, которые работают на тестовых данных и разваливаются на любом нестандартном кейсе.

Это, кстати, и есть та часть продукта, которую "AI не может написать сам" - просто потому, что не имеет ни доменного контекста, ни тестовой базы реальных звонков.

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

Новая версия алгоритма выкатывается только если она:

Все три критерия одновременно. Это позволяет уверенно итерировать - каждое изменение можно сравнить с предыдущим по понятным метрикам.

Когда на линии живой человек, наш агент входит в разговор после первой же его фразы, а не после "Hello, this is John, who's calling?". Это убирает 1-3 секунды задержки, которые в outbound-сценариях критичны для конверсии.

Готовые сервисы - не плохие. Они построены под медианный кейс. Outbound в проде - это не медианный кейс.

Если вы только начинаете и у вас 1-1 dial без особых требований к скорости - возьмите Vapi или Retell, не тратьте время на свой стек. Они нормально решают 80% проблем.

Если вы делаете высоконагруженный outbound, где конверсия зависит от того, услышит ли человек первую секунду речи - готовые решения упрутся в потолок. Нужен либо собственный fusion-слой поверх их сигналов, либо полностью свой стек.

Какое у вас детектирование сейчас и где оно ломается? Особенно интересно, как вы решаете проблему колл-скриннеров в США - кажется, в публичном пространстве она почти не обсуждается.

#AI #VoiceAI #Стартапы #Разработка #Технологии #TwinsAI