Как мы научились определять продвинутые автоответчики

Как мы научились определять продвинутые автоответчики

Год назад мы начали использовать ASR для обработки записей телефонных звонков.

TL;DR: вместо бинарных правил и end-to-end ML мы выбрали скоринговую систему поверх ASR (T-One ^[1]): анализируем диалог и поведение ^[2], получаем ~98% точности при среднем времени обработки ~4.9 сек вместо 20+ сек на Whisper.
Задача казалась простой: понять, ответил ли абонент сам или сработал автоответчик, и на основании этого корректно завершить звонок и вернуть деньги пользователю при неудаче.

На практике всё оказалось сильно сложнее.

Мы работаем с телефонными розыгрышами. Записи стерео: слева абонент, справа оператор. Оператор – это заранее подготовленная аудиозапись. Первые версии системы выглядели очевидно: если абонент говорит что-то вроде «абонент сейчас недоступен», «оставьте сообщение», «говорит голосовой помощник» – это автоответчик.

Так мы и начали.

Этап 1. Когда автоответчики перестали быть тупыми

На старте мы использовали Whisper. Он решал сразу две задачи:

• расшифровка речи

• примитивная детекция автоответчиков по ключевым фразам

Пока автоответчики были классическими — всё работало.

Проблемы начались позже.

Современные автоответчики и голосовые ассистенты перестали говорить шаблонно. Они:

• отвечают короткими фразами («да», «слушаю», «говорите»)

• переспрашивают

• не палятся в начале разговора

• могут поддерживать иллюзию диалога

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

• реальным человеком

• умным автосекретарём

• IVR банка

Ошибка ^[3] стоила денег.

Whisper обрабатывал минутную запись около 20 секунд. Но даже при этом качество детекции упиралось не в ASR, а в логику ^[4].

Этап 2. Переход на T-One и тупик

С выходом модели T-One ^[1], обученной именно на телефонных разговорах, появилась надежда.

Мы:

• заменили Whisper на T-One

• получили более стабильную транскрипцию

• ускорили обработку

Для удобства я написал отдельный REST API ^[5]вокруг модели.

Отдельно важно про производительность. Среднее время полной обработки записи и детекции автоответчика с моделью T-One составляет около 4.9 секунды, против 20+ секунд при использовании Whisper. Это критично для нашей системы: результат нужен быстро, пока пользователь ещё ждёт исход звонка.

Важный нюанс – архитектура исполнения.

Whisper в нашем продакшене работал на GPU. Это означало отдельные GPU-ноды, очереди, более сложное масштабирование и чувствительность к пикам нагрузки. При росте количества звонков latency начинал «плыть», а стоимость обработки росла непропорционально.

T-One, в свою очередь, стабильно работает на CPU. Это позволило упростить инфраструктуру, отказаться от GPU для ASR и предсказуемо масштабироваться горизонтально. Для нашей задачи это оказалось критично: детекция должна работать быстро и стабильно, а не «иногда быстрее, иногда медленнее».

В итоге переход на T-One дал не только выигрыш по времени обработки, но и существенно упростил продакшен-эксплуатацию системы.

Но довольно быстро стало понятно: ASR – не решение задачи детекции.

Даже идеальный текст не отвечает на вопрос: это человек или бот.

Нужно было идти глубже.

ASR отвечает только за текст. Вся логика детекции вынесена в отдельные уровни.

Этап 3. Переход от правил к скорингу

Почему детекция по ключевым фразам ломается на современных автоответчиках.

Мы собрали датасет из ~7000 реальных звонков:

• классические автоответчики

• продвинутые ассистенты

• IVR операторов и банков

• реальные люди

Часть записей была размечена ещё во времена Whisper. Остальные — вручную, после анализа ошибок.

Изначально система принимала решения на основе жёстких пороговых правил: отдельные признаки напрямую давали ответ «да» или «нет».

Вместо этого мы перешли к скоринговой модели.

Идея простая:

• система извлекает признаки

• каждому признаку назначен вес

• итоговый скор определяет класс

Но реализация оказалась нетривиальной.

Этап 4. FeatureExtractor: 300+ паттернов против ботов

В центре системы появился FeatureExtractor.

Он анализирует только транскрипцию и тайминги, без аудио.

Мы выделили несколько групп признаков.

Базовые признаки

Они не говорят «это бот», но создают фон:

• отсутствие реакции ^[6] на абсурд, мат, угрозы

• репромпт-петли (“расскажите подробнее”, “что-то ещё?”)

• отсутствие контекстных ссылок

• ровный, неэскалирующий стиль

Сильные признаки

Это почти прямые маркеры автоответчика:

• самоидентификация бота

• IVR операторов

• стандартные автоответы

• умные секретари

• праздничные автоответы

• шаблонные бот-фразы

Человеческие признаки

Они уменьшают скор:

• активные вопросы

• эмоции ^[7]

• агрессия

• смех

Примеры фичей и их влияние на итоговый скор.

Всего в системе:

• 17 основных фичей

• 5 метаданных

• 310+ регулярных выражений

Этап 5. Детекция диалога, а не текста

Система учитывает не только текст, но и тайминги ответа и структуру вопрос–ответ.

Главное отличие человека от бота – диалог.

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

Turn-taking QA

Система ищет связки:

• оператор задал вопрос

• абонент ответил в разумное временное окно

• ответ не является коротким маркером

Двунаправленный диалог

Проверяем, что вопросы и ответы идут в обе стороны, а не только оператор → абонент.

Voicemail-like детекция

Жёсткий флаг автоответчика:

• длинная реплика в начале

• отсутствие диалога

• типичные фразы голосовой почты

Это позволило резко снизить ложные срабатывания.

Этап 6. Scorer и корректирующие правила

Показана логика принятия решений без деталей реализации.

После извлечения фичей вступает Scorer.

Алгоритм трёхуровневый:

1. Жёсткие маркеры
   Если найден прямой признак – сразу фиксированный скор.

2. Накопительный скоринг
   Суммирование весов всех фичей.

3. Корректирующие правила
   Контекстная компенсация:

• диалог снижает скор

• voicemail усиливает

• комбинации фичей фиксируют минимальный порог

Финальная классификация:

• = 0.5 — автоответчик

• 0.3–0.5 — сомнительно

• < 0.3 — человек

Этап 7. Результаты

На текущий момент:

• точность ~98%

• сильно снижены false positive

• система устойчива к «хитрым» ботам

Важно: это не ML-модель в классическом смысле. Это инженерная система с накопленной экспертизой.

И именно это даёт контроль и предсказуемость.

Вывод

В какой-то момент мы перестали пытаться «угадать», кто перед нами – человек или автоответчик. Вместо этого начали смотреть на поведение ^[8].

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

Поэтому задача детекции – это не задача распознавания речи и не задача машинного обучения ^[9] в вакууме. Это задача анализа структуры разговора, таймингов и реакции на контекст.

В нашем случае лучше всего сработала не магия и не end-to-end модель, а комбинация:

• ASR для текста

• набора объяснимых признаков

• скоринга

• и аккуратной логики принятия решений

Это дало нам контроль, предсказуемость и понятные ошибки – а для продакшена это важнее любой «умной» модели.