Habr AI→ оригинал

"Soluciones de Pago Avanzadas" lanzó asistente de voz con IA para llamadas en piloto sin equipo de ML

"Soluciones de Pago Avanzadas" demostró un caso raro en el mercado: un asistente de voz con IA para llamadas fue construido no por ingenieros de ML, sino por 12

"Soluciones de Pago Avanzadas" lanzó asistente de voz con IA para llamadas en piloto sin equipo de ML
Источник: Habr AI. Коллаж: Hamidun News.

Компания «Передовые Платежные Решения» рассказала, как вывела в пилот голосового ИИ-ассистента для звонков без собственной ML-команды. За шесть месяцев 12 backend-разработчиков собрали систему, которая в реальном времени подсказывает менеджеру, как отвечать клиенту, и укладывается в задержку около двух секунд.

Как собрали MVP Внутри компании проект получил название «Суфлёр».

Его задача — слушать уже расшифрованный разговор, понять, о каком продукте идёт речь, заметить возражение клиента и сразу показать менеджеру текстовую подсказку. Финальный стек собрали на Python, FastAPI и PostgreSQL, а за классификацию и генерацию отвечали BERT-классификаторы и локальная Qwen 8B. Для бизнеса это способ снизить нагрузку на наставников и быстрее выводить новых сотрудников на KPI, особенно когда в экосистеме больше 35 продуктов и менеджеру нужно держать в голове слишком много сценариев.

Ключевое ограничение было жёстким: на ответ у системы есть лишь 1,5–2 секунды, иначе подсказка теряет смысл прямо во время живого диалога. До рабочего прототипа команда дошла быстро. За первые три недели разработчики взяли текстовые транскрипты звонков, обучили два BERT-классификатора на примерно 1,5 тысячи диалогов, собрали простые базы знаний со скриптами и связали всё через промпты с облачной GPT-моделью.

Интерфейс сделали за день на Django. Такой proof-of-concept работал медленно, с задержкой 10–15 секунд, но его хватило, чтобы защитить идею перед бизнесом и получить зелёный свет на MVP. Дальше уже началась инженерная работа по сокращению задержек, стабилизации и интеграциям.

Почему всё упростили

Сначала команда, как это часто бывает в ИИ-проектах, спроектировала слишком амбициозную систему: собственный аудиоконвейер, несколько сложных классификаторов, fine-tuning большой языковой модели, векторную базу и даже контур самообучения. Но довольно быстро стало ясно, что такой путь растянет запуск на 12–18 месяцев и резко повысит шанс провала. Вместо попытки построить «идеальную» архитектуру разработчики начали последовательно выкидывать всё, без чего можно обойтись в первом релизе.

«Мы не боролись с проблемами, а перепроектировали систему так, чтобы

эти проблемы в ней не возникали».

  • Отказались от fine-tuning в пользу RAG, чтобы не тратить месяцы на разметку и снизить риск галлюцинаций.
  • Не стали писать свою транскрибацию и взяли готовые текстовые сегменты из Voximplant.
  • Упростили классификатор возражений: вместо 15+ классов оставили бинарную схему «есть возражение / нет возражения».
  • Не стали тянуть тяжёлую векторную БД для нескольких мегабайт данных и загрузили структурированные JSON-файлы прямо в память.
  • Ушли от облачных API к локальной Qwen 8B на GPU-сервере, чтобы уложиться в задержку и не выносить чувствительные данные за периметр. Этот набор компромиссов оказался ключевым. Облачные модели давали ответ за 7–20 секунд, а Qwen 32B хоть и отвечала качественнее, всё равно не проходила по времени. Более компактная Qwen 8B оказалась достаточно хорошей для подсказок менеджеру и стабилизировала латентность примерно на двух секундах. Параллельно локальное развёртывание закрыло вопросы ИБ: транскрипты разговоров не нужно отправлять во внешние сервисы, а значит не пришлось строить отдельный слой маскировки персональных данных и платить за это дополнительными задержками.

Что показал пилот Самой недооценённой проблемой оказались не модели, а данные.

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

По итогам пилота система вышла на среднюю задержку около двух секунд, лишь в 2–3% случаев поднимаясь до трёх. Классификация услуг дала точность выше 70%, а распознавание речи — от 92% в зависимости от качества связи. Команда пишет, что пилот уже дал качественный эффект: появились первые сигналы по удобству, снижению нагрузки на наставников и общей полезности для операторов.

Но статистически значимых выводов по конверсии и KPI пока нет — для этого продукту нужно масштабирование и бесшовная интеграция прямо в CRM.

Что это значит

Этот кейс хорошо показывает, что внутренний ИИ-продукт не всегда требует готовой ML-команды с нуля. Если у компании есть сильные backend-инженеры, понятная бизнес-боль и доступ к процессам, MVP можно собрать быстрее за счёт жёсткого упрощения архитектуры и отказа от лишних «умных» компонентов. Главный вывод здесь не в выборе конкретной модели, а в дисциплине: сначала решать проблему бизнеса, затем проверять ограничения по скорости и безопасности, и только потом усложнять стек.

ЖХ
Hamidun News
AI‑новости без шума. Ежедневный редакторский отбор из 400+ источников. Продукт Жемала Хамидуна, Head of AI в Alpina Digital.
Загружаем комментарии…