Автоматизація дзвінків: 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 хвилин. Ми підготуємо пропозицію з точними термінами та вартістю. Зв'яжіться з нами для консультації — оцінимо ваш сценарій і запропонуємо оптимальне рішення.

Розпізнавання та синтез мовлення: перша лінія проблеми

Ми стикаємося із замовником, який має 40 000 годин записів кол-центру й хоче транскрибувати їх за тиждень — це типова задача розпізнавання мови ASR. Штатний хмарний 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 обрізає короткі вставки. Рішення — збільшити min_duration_on до 0.3 та додати overlap detection через pyannote-overlap-detection.

Клонування голосу — латентність чи якість. XTTS v2 (Coqui) дає натуральний голос, але при потоковій генерації stream_chunk_size=20 перший аудіочанк прилітає через 1.4–2.0 с — неприйнятно для інтерактивних сценаріїв. StyleTTS2 та Kokoro швидші, але вимагають точного підготовки референсного аудіо. Ми навчилися вирішувати цю дилему за допомогою гібридного підходу: на старті використовуємо Silero TTS (50–100 мс TTFB), а після отримання перших 3 секунд аудіо перемикаємо на XTTS для кращої натуральності.

Як вибрати ASR-модель під ваші дані?

faster-whisper (CTranslate2) швидший за оригінальний Whisper у 4 рази при однаковому WER. Для продакшену ми завжди використовуємо його.

Практичний приклад: fine-tuning Whisper на доменній лексиці

Фінтех-компанія з 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.50 за годину аудіо, що в 6 разів дешевше за хмарне рішення. Проєкт виконано за 6 тижнів, включаючи підготовку даних і валідацію.

Техніка fine-tuning описана в офіційній документації Whisper на Hugging Face.

Як донавчити 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 обов’язково заморожуйте encoder перші 1000 кроків (model.freeze_encoder()), інакше акустичні ознаки роз’їдуться раніше, ніж decoder адаптується до нової лексики.

Синтез мовлення: що обрати для вашого сценарію?

Для інтерактивних ботів з вимогою TTFB < 300 мс — Silero або Kokoro. Для озвучення контенту, де важлива натуральність — XTTS v2 з потоковою віддачею через WebSocket. Ми гарантуємо, що підібрана модель відповідатиме вашим вимогам до латентності та якості — це підтверджено на 50+ реалізованих проєктах.

Наш досвід та гарантії

10+ років досвіду в NLP та speech processing. 50+ успішних проєктів для fintech, telecom, медицини. Сертифіковані моделі (Model Card + bias audit). Ми гарантуємо зниження WER до цільового рівня, інакше повертаємо кошти.

Що входить у роботу з нами?

Клієнт отримує:

• Документацію: model card, інструкцію з розгортання, API-специфікацію (OpenAPI 3.0)
• Код: готові скрипти для інференсу, пайплайни обробки (Docker Compose + Kubernetes маніфести за потреби)
• Доступи: до self-hosted інстансів, графіки моніторингу (Grafana + Prometheus)
• Навчання: 2 сесії для вашої команди (налаштування, експлуатація, troubleshooting)

Ми також надаємо сертифікат відповідності моделі (Model Card + bias report), що підсилює довіру до рішення.

Процес роботи та терміни

1. Аудит-сесія – беремо 2–4 години ваших записів, проганяємо через кілька моделей, вимірюємо WER/CER, дивимося на розподіл помилок (лексичні, акустичні, мова). Займає 1–2 дні.
2. Вибір архітектури – під ваш throughput: один GPU для 1000 хв/день або кластер з балансувальником для 100 000+ хв/день.
3. Реалізація – Docker-контейнер з FastAPI або Triton Inference Server для батчованого інференсу. Інтеграція з чергою Kafka.
4. Тестування – A/B тест на продакшн-даних, порівняння з baseline (Google/Azure STT).
5. Деплой – CI/CD (GitHub Actions + ArgoCD), моніторинг (Grafana + WER/CER алерти).

Терміни:

• Базова інтеграція готової моделі – 1–2 тижні.
• Fine-tuning з підготовкою даних та валідацією – 4–8 тижнів.
• Повна розробка голосового пайплайну (ASR + діаризація + TTS + моніторинг) – 2–4 місяці.

Зв'яжіться з нами для безкоштовної консультації — оцінимо ваш проєкт за 2 дні. Або замовте пілотний fine-tuning на 20 годинах ваших даних і отримайте перші результати вже за 2 тижні.