Автоматизация обработки звонков: AI для Mango Office, Zadarma и Sipuni

Проблема: ручная обработка звонков — узкое горлышко

Представьте: вы руководитель колл-центра на 50 операторов. Каждый день — 500 звонков, средняя длительность 4 минуты. Чтобы оценить качество, нужно прослушать хотя бы 10% — это 200 минут в день. После каждого звонка менеджер заполняет отчёт — ещё 5 минут. Умножив на 500 звонков, получаем 41 час в месяц на отчёты. AI делает всё это за секунды. Мы внедрили такие решения для 10+ проектов, обработав более 500 000 звонков и сократив время анализа на 70%. Вы тратите часы на прослушивание записей, чтобы выявить проблемы в сценариях или оценить качество работы. Ошибки менеджеров остаются незамеченными, а клиенты уходят. Мы автоматизируем этот процесс с помощью AI-интеграции, что даёт сокращение затрат на ручной анализ до 80%.

Какие задачи решаем?

• Транскрипция и анализ тональности: после каждого звонка автоматически получаем текст, определяем эмоциональную окраску (позитив/негатив/нейтрально) и выделяем ключевые темы.
• Умная маршрутизация: AI анализирует историю обращений и предсказывает, какой отдел лучше справится с запросом — звонок перенаправляется ещё до соединения.
• Поиск по записям: весь архив становится поисковым — нашли упоминание конкурента за месяц? Пара запросов в Elasticsearch.

Как мы это делаем: архитектура и стек

Post-call анализ (быстрый старт):

Завершённый звонок → Webhook от АТС → Скачивание записи → STT (Whisper или Vosk) → NLP (spaCy + transformers) → CRM

Real-time обработка (через SIP-транк):

Звонок → АТС → SIP-транк → Media Gateway (RTP → PCM) → AI Server (VAD + ASR + NLU) → Ответное действие (маршрутизация/подсказка)

Для развёртывания используем:

• Модели: OpenAI Whisper (large-v3), собственные fine-tuned модели на базе BERT для классификации.
• Инфраструктура: vLLM для инференса, ONNX Runtime для оптимизации, pgvector для хранения эмбеддингов.
• MLOps: MLflow для отслеживания экспериментов, Kubeflow для пайплайнов.

Почему post-call анализ проще внедрить?

Post-call анализ не требует изменений в сети — достаточно настроить Webhook Wikipedia в личном кабинете АТС. Real-time вариант сложнее: нужен выделенный SIP-транк и сервер с GPU для обработки аудиопотока в реальном времени.

Как AI улучшает маршрутизацию звонков?

Real-time анализ звонка позволяет маршрутизировать вызов на основе предиктивной аналитики: тональность клиента, история обращений, intent. AI принимает решение за 400 мс (p99), что незаметно для говорящих. Например, если клиент раздражён, звонок направляется самому опытному оператору. Это повышает уровень сервиса и снижает количество повторных обращений. Мы внедрили real-time сценарии в двух проектах — клиенты отметили рост удовлетворённости на 15%.

Процесс работы

1. Аналитика: аудит текущей АТС, сбор требований, выбор сценариев (post-call, real-time или оба).
2. Проектирование: архитектура интеграции, выбор моделей, настройка безопасности.
3. Реализация: пишем код на Python (FastAPI + Celery для асинхронности), интегрируем с CRM по REST/SOAP.
4. Тестирование: прогон на исторических записях, A/B-тест на 10% звонков. Достигаем точности транскрипции 95%+.
5. Деплой: контейнеризация (Docker + Kubernetes), мониторинг (Prometheus + Grafana).

Сроки

• Post-call анализ: от 1 до 2 недель.
• Real-time интеграция: от 1.5 до 2 месяцев.
• Полный цикл (оба сценария + дашборды): до 3 месяцев.

Стоимость интеграции рассчитывается индивидуально после аудита вашей инфраструктуры.

Что входит в работу

• API-документация схем интеграции.
• Доступ к тестовому стенду на время разработки.
• Обучение команды работе с дашбордами.
• Гарантия на код и SLA обработки ошибок до 4 часов.

Типичные ошибки при самостоятельной интеграции

• Игнорирование ACK от Webhook: Mango Office повторяет запрос — дубли записей. Решение: возвращайте HTTP 200 сразу.
• Неправильная подпись запросов: хеш не совпадает, запросы блокируются. Решение: используйте hmac с сортировкой по ключам.
• Перегрузка STT-модели: высокая латентность и стоимость. Решение: включите VAD, чтобы не обрабатывать тишину.

У нас более 10 проектов по интеграции AI в телефонию, 5 лет опыта в NLP и MLOps. Закажите аудит вашей АТС — это бесплатно и займёт 30 минут. Мы подготовим предложение с точными сроками и стоимостью. Свяжитесь с нами для консультации — оценим ваш сценарий и предложим оптимальное решение.

Распознавание и синтез речи: ASR, TTS, клонирование голоса

Заказчик приходит с задачей: транскрибировать 40 000 часов колл-центра за неделю. Штатный облачный ASR (Google Speech-to-Text) выдаёт WER 28% на отраслевой лексике и стоит ощутимо дорого при таких объёмах. Задача — снизить WER ниже 10% и перейти на self-hosted инференс.

Типовые проблемы, с которыми приходят

WER не сходится к нужной метрике. Чаще всего виновата не архитектура, а данные: шумные аудио без нормализации уровня (-23 LUFS вместо стандарта), смешанные языки в одном канале, акцент, специфическая доменная лексика. Whisper large-v3 из коробки даёт WER 8–12% на чистом русском и проваливается до 25–35% на записях с PSTN-артефактами и узкополосным кодеком G.711.

Диаризация ломается при больше двух спикеров. pyannote/speaker-diarization-3.1 работает стабильно при 2–3 говорящих, но DER (Diarization Error Rate) растёт с 6% до 18–22% при 5+ участниках конференции. Проблема усугубляется перекрёстными репликами: по умолчанию min_duration_on=0.1 срезает короткие вставки.

Клонирование голоса — латентность или качество. XTTS v2 (Coqui) даёт натуральный голос, но при потоковой генерации stream_chunk_size=20 первый аудиочанк прилетает через 1.4–2.0 с — неприемлемо для интерактивных сценариев. StyleTTS2 и Kokoro быстрее, но требуют точной подготовки референсного аудио.

Как это решается на практике

Базовый стек для production-пайплайна:

• ASR: openai/whisper-large-v3 или faster-whisper (CTranslate2-бэкенд, x4 скорость vs оригинал)
• Диаризация: pyannote.audio 3.x + интеграция через whisperx для выравнивания по словам
• TTS: XTTS v2 для качества, Edge-TTS или Silero для низкой латентности
• Клонирование: XTTS v2 (3–6 с референсного аудио) или OpenVoice v2

Типичный пайплайн для колл-центра выглядит так: аудио из очереди Kafka → нормализация ffmpeg -af loudnorm до -23 LUFS → faster-whisper с beam_size=5, vad_filter=True → pyannote диаризация → постпроцессинг (пунктуация через deepmultilingualpunctuation) → запись в PostgreSQL с временными метками.

Кейс из практики. Финтех-компания с 12 000 звонков/день. Исходный WER на русском с банковской лексикой — 22% (Google STT). После fine-tuning whisper-medium на 200 часах размеченных записей через Hugging Face transformers + Seq2SeqTrainer с learning_rate=1e-5, warmup_steps=500 — WER упал до 7.3%. Инференс на одной A10G через faster-whisper с compute_type=float16 обрабатывает 40-минутный звонок за 55 секунд. Итоговая стоимость инференса — $0.0008/мин против $0.016/мин у облачного провайдера.

Дообучение Whisper на доменных данных

Когда общая модель не справляется, fine-tuning — первый инструмент. Минимальный датасет для заметного улучшения — 20–30 часов размеченного аудио в целевом домене. Разметку можно получить через итеративный процесс: прогнать через базовую модель → вручную исправить 10–15% ошибок → переобучить → повторить.

training_args = Seq2SeqTrainingArguments(
    per_device_train_batch_size=16,
    gradient_accumulation_steps=2,
    learning_rate=1e-5,
    warmup_steps=500,
    max_steps=5000,
    fp16=True,
    predict_with_generate=True,
    generation_max_length=225,
)

Важно: при fine-tuning Whisper нужно замораживать encoder первые 1000 шагов (model.freeze_encoder()), иначе акустические признаки разъедутся раньше, чем decoder адаптируется к новой лексике.

Синтез речи: выбор под задачу

Для интерактивных ботов с требованием TTFB < 300 мс — Silero или Kokoro. Для озвучки контента, где важна натуральность — XTTS v2 с потоковой отдачей через WebSocket.

Процесс работы

Начинаем с аудит-сессии: берём 2–4 часа ваших записей, прогоняем через несколько моделей, замеряем WER/CER, смотрим на распределение ошибок по типам (лексические, акустические, язык). Это занимает 1–2 дня и сразу показывает, нужен ли fine-tuning или достаточно пост-обработки.

Далее — выбор архитектуры под ваш throughput: один GPU для 1000 мин/день или кластер с балансировщиком для 100 000+ мин/день. Деплой через Docker-контейнер с FastAPI или Triton Inference Server для батчированного инференса.

Сроки зависят от сложности: базовая интеграция готовой модели — 1–2 недели. Fine-tuning с подготовкой данных и валидацией — 4–8 недель. Полная разработка голосового пайплайна (ASR + диаризация + TTS + мониторинг) — 2–4 месяца.