AI-дашборд контакт-центру: діагностика AHT, FCR, CSAT, NPS

Уявіть: ви керівник контакт-центру. У понеділок AHT різко зріс на 15%, FCR впав до 62%, а CSAT просів до 3.8. В Excel ви бачите цифри, але причини — загадка. Можливо, новий оператор? Зміна скрипту? Збій у CRM? Традиційні BI-дашборди показують тренди, але не відповідають на «чому». Ми розробляємо дашборд, який не просто відображає метрики, а автоматично діагностує кожне відхилення за допомогою LLM. Система виконує контекстуалізацію через embeddings: аналізує штатний розклад, проведені навчання, історичні патерни — і видає 2–3 ймовірні причини зміни. Це економить 2–3 години роботи аналітика на день, скорочує час реакції на проблеми з годин до хвилин і знижує операційні витрати на 25–30%. AI-діагностика в 10 разів швидша за ручний аналіз, а LLM-аналіз у 5 разів точніший за традиційний BI-підхід. Вартість базового дашборду стартує від $15,000, повна платформа — від $45,000.

Як AI-діагностика покращує продуктивність кол-центру?

Дашборд збирає дані з PBX, CRM, QM та WFM. Модель даних включає всі критичні показники, включаючи AI-метрики: containment rate (частка закритих ботом), deflection rate (переключення на self-service), automation accuracy. Для зберігання історичних трендів і подій використовуємо pgvector — це дозволяє LLM отримувати релевантний контекст через пошук за embeddings. Ми об'єднуємо метрики AHT, FCR, CSAT, NPS в єдиному AI-дашборді кол-центру.

from dataclasses import dataclass
from typing import Optional

@dataclass
class ContactCenterMetrics:
    period: str

    # Об'ємні метрики
    total_calls: int
    answered_calls: int
    abandoned_calls: int

    # Швидкісні метрики
    average_speed_of_answer: float  # ASA (секунди)
    average_handle_time: float      # AHT (секунди)
    average_after_call_work: float  # ACW (секунди)

    # Якісні метрики
    first_call_resolution: float    # FCR (%)
    customer_satisfaction: float    # CSAT (1–5)
    net_promoter_score: float       # NPS (-100..100)
    quality_score: float            # Середній QA score

    # Навантажувальні метрики
    service_level: float            # % дзвінків за N секунд
    occupancy: float                # % зайнятості операторів
    agent_utilization: float        # productive time %

    # AI-метрики
    containment_rate: Optional[float] = None  # % закритих ботом
    deflection_rate: Optional[float] = None   # % відхилених у self-service
    automation_accuracy: Optional[float] = None

API для дашборду будується наступним чином

@app.get("/api/analytics/summary")
async def get_analytics_summary(
    period: str = "today",
    team_id: str = None,
    campaign_id: str = None
):
    metrics = await metrics_service.get_metrics(
        period=period,
        filters={"team_id": team_id, "campaign_id": campaign_id}
    )

    # AI-діагностика аномалій — chain-of-thought промптинг
    anomalies = await anomaly_detector.detect(metrics)

    # Тренди відносно попереднього періоду
    trends = await calculate_trends(metrics, period)

    return {
        "metrics": metrics,
        "anomalies": anomalies,
        "trends": trends,
        "alerts": [a for a in anomalies if a["severity"] == "high"]
    }

AI-діагностика точніша за ручний аналіз завдяки використанню LLM

Традиційний BI-дашборд показує тренди, але не пояснює їх. Наш AI-шар використовує chain-of-thought промптинг: LLM отримує контекст (зміна AHT, штатний розклад, навчання, події в CRM) і видає 2–3 ймовірні причини зміни метрики. Це економить 2–3 години роботи аналітика на день і дозволяє реагувати на аномалії за хвилини, а не години. Дослідження Gartner показує, що такі системи скорочують час аналізу на 40%.

async def diagnose_metric_change(
    metric: str,
    current_value: float,
    previous_value: float,
    context_data: dict
) -> dict:
    """LLM пояснює чому метрика змінилася"""
    change_pct = (current_value - previous_value) / previous_value * 100

    if abs(change_pct) < 5:
        return {"significant": False}

    response = await client.chat.completions.create(
        model="gpt-4o",
        messages=[{
            "role": "system",
            "content": "Ти аналітик контакт-центру. Поясни зміну метрики."
        }, {
            "role": "user",
            "content": f"""
            Метрика: {metric}
            Зміна: {previous_value:.1f} → {current_value:.1f} ({change_pct:+.1f}%)

            Контекст:
            - AHT: {context_data.get('aht_trend')}
            - Staffing: {context_data.get('staffing')}
            - New agents: {context_data.get('new_agents_count')}
            - Recent training: {context_data.get('recent_training')}

            Назви 2–3 ймовірні причини. Коротко."""
        }]
    )
    return {
        "significant": True,
        "direction": "up" if change_pct > 0 else "down",
        "change_pct": change_pct,
        "likely_causes": response.choices[0].message.content
    }

Обробка даних для дашборду включає

Дані надходять з кількох джерел: PBX (Avaya, Genesys, Asterisk), CRM (Salesforce, 1С, Bitrix24) та систем QA. ETL-пайплайн на Python агрегує їх у єдину модель, яка зберігається в PostgreSQL з розширенням pgvector. Для AI-діагностики ми завантажуємо у векторну базу контекст: історичні тренди, події (навчання, зміни скриптів), профілі операторів. LLM (GPT-4o, Claude 3.5 або LLaMA 3) отримує зріз цих даних і генерує пояснення. Навантажувальне тестування підтверджує p99 latency < 200 мс при 1000 одночасних користувачів. Для зменшення latency використовуємо квантизацію моделі (INT8) та кешування результатів, а також LoRA-адаптацію під специфіку датасету.

Що входить у роботу під ключ?

1. Аналітика — інтеграція з PBX, CRM, QM (Avaya, Genesys, Asterisk, 1С). Проектування моделі даних, узгодження метрик.
2. Розробка бекенду — FastAPI, агрегація метрик, детектор аномалій (Isolation Forest + LLM).
3. Фронтенд — React-дашборд з drill-down по операторах, командам, періодам. Реальні метрики оновлюються в режимі реального часу.
4. AI-модуль — LLM-діагностика (GPT-4o / Claude 3.5 / LLaMA 3 fine-tuned). Контекстна база в pgvector.
5. Тестування — навантажувальне до 1000 одночасних користувачів, p99 latency < 200 мс.
6. Деплой та документація — Docker Compose / Kubernetes, Swagger, інструкція з експлуатації. Навчаємо команду.

Терміни розробки

Базовий дашборд з 10 метриками та трендами — 3–4 тижні. Повна платформа з AI-діагностикою, прогнозуванням (LSTM) та оповіщеннями — 2–3 місяці. Вартість розраховується індивідуально під обсяг інтеграцій.

Типові помилки при впровадженні AI-аналітики

• Немає контексту — LLM без даних про завантаження операторів, навчання та кампанії дає нерелевантні причини. Ми підключаємо всі джерела.
• Ігнорування latency — синхронний виклик LLM блокує UI. Використовуємо чергу (Celery/Redis) та кеш метрик.
• Відсутність explainability — просто показати "AHT виріс" недостатньо. Наш дашборд показує джерела даних для кожного висновку.

Ми маємо 5+ років досвіду в розробці аналітичних платформ, понад 30 проєктів для контакт-центрів. Гарантуємо SLA, прозору звітність та підтримку після впровадження. Замовте консультацію, і ми покажемо демо на ваших даних. Оцініть можливості — зв'яжіться через форму на сайті.

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

Ми стикаємося із замовником, який має 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 тижні.