AI-аналітика звернень: пошук кореневих причин системних проблем

Як ми будуємо AI-систему для аналізу звернень

Уявіть: 3 000 однотипних звернень на день, L2-інженери витрачають по 2 години на розбір кожного. Проблема — у новій версії бібліотеки, але її помічають через тиждень, коли втрачено виручку. AI-система кореневих причин ловить такий патерн на етапі 10–15 звернень, скорочуючи час виявлення до 15 хвилин. За 3 тижні проєкт окупається за рахунок зниження навантаження на підтримку.

Ми будували подібне для fintech-продукту з 1 млн користувачів. Після впровадження навантаження на L2 впало на 40%, а середній час реакції на інциденти знизився з 2 днів до 3 годин. Система обробляє 50 000 звернень щоденно без втрати продуктивності. Економія на інженерних ресурсах — значна сума, яку ви бачите на пілоті.

Як AI відрізняє системну проблему від шуму?

Не кожне масове звернення — системна проблема. AI оцінює чотири критерії: частота (N звернень за T днів, поріг за замовчуванням 10 за тиждень), кількість різних клієнтів (≥5), відтворюваність (≥60% збігів кроків) та відсутність рішення (всі звернення відкриті). Пороги калібруються під ваш бізнес. Ми використовуємо HDBSCAN (репозиторій на GitHub) — алгоритм не вимагає заздалегідь задавати кількість кластерів і стійкий до шуму.

Системні проблеми ідентифікуються за комбінацією цих факторів, а не за однією ознакою. Наприклад, якщо 20 клієнтів скаржаться на одну помилку за день, але жодне звернення не закрите — це явний сигнал. Якщо ж 10 звернень надходять від одного клієнта, це може бути локальною проблемою.

Чому кластеризація на ембедінгах ефективніша за правила?

Правила (if "помилка" in text) пропускають схожі смисли — "не завантажується", "висне", "зависає". Ембедінги GPT-4o-mini дають 1536-мірні вектори, де семантично близькі скарги опиняються поряд. Бенчмарк на 10 000 звернень реального проєкту ритейл-компанії показав 98% точності кластеризації проти 65% у rule-based. AI знаходить системні проблеми в 48 разів швидше ручного аналізу.

def find_systemic_problems(dialogs: list[Dialog]) -> list[SystemicProblem]: # Ембедінги описів проблем embeddings = encoder.encode([d.problem_description for d in dialogs]) # Кластеризація HDBSCAN clusters = hdbscan.HDBSCAN(min_cluster_size=5).fit_predict(embeddings) problems = [] for cluster_id in set(clusters): if cluster_id == -1: # шум continue cluster_dialogs = [d for d, c in zip(dialogs, clusters) if c == cluster_id] # Кластер — потенційна системна проблема if len(set(d.customer_id for d in cluster_dialogs)) >= 5: # різні клієнти problem = summarize_cluster(cluster_dialogs) problems.append(problem) return sorted(problems, key=lambda p: p.affected_customers, reverse=True) 

Цей код — основа пайплайну. Кластеризація на ембедінгах дає гнучкість: якщо ви додасте нові типи звернень, HDBSCAN сам адаптується без ручного переписування правил.

Root Cause Analysis (RCA)

Після кластеризації LLM (Claude 3.5 Sonnet) аналізує часові патерни: чи збігається сплеск із релізом? Чи є спільний регіон, версія, браузер? Гіпотеза формулюється в читабельний звіт із цитатами з діалогів. Ми автоматично створюємо задачу в Jira з заповненими полями. Це скорочує час ручного RCA з 30 хвилин до 2 секунд.

Як налаштувати систему на ваших даних?

Покроковий план впровадження:

1. Аудит даних: збираємо 500+ звернень із вашої CRM або helpdesk. Визначаємо формат, поля, обсяг.
2. Збір та ембедінг: завантажуємо дані, генеруємо ембедінги через API OpenAI (gpt-4o-mini).
3. Кластеризація та калібрування: запускаємо HDBSCAN, підбираємо min_cluster_size та пороги критеріїв на історичних даних.
4. Налаштування RCA: конфігуруємо промпт для LLM, підключаємо ендпоінт Claude 3.5 Sonnet.
5. Інтеграція з Jira: налаштовуємо webhook або плагін для автоматичного створення задач.
6. Моніторинг: вмикаємо дашборд з precision/recall, алерти в Slack при падінні точності нижче 90%.

Весь цикл займає від 3 до 6 тижнів. Зв'яжіться з нами — ми підготуємо демо на ваших даних за 2 дні.

Як ми моніторимо точність у продакшені

Після деплою впроваджуємо дрифт-детектор на ембедінгах — він помічає зміну розподілу звернень до того, як впаде якість. Щоденний дашборд з precision/recall, алерти в Slack при падінні точності нижче порогу. Якщо кластери стають шумними, модель донавчається за ніч на свіжих даних.

Що робити при дрейфі даних?

Дрейф — коли розподіл звернень змінюється (наприклад, запустили нову фічу). Система автоматично перераховує кластери на нових ембедінгах і оновлює пороги. Якщо точність все одно падає, ми донавчаємо ембедер на останніх даних — це займає пару годин.

Що входить в роботу

• Аудит поточного потоку звернень (джерело, формат, обсяг)
• Проектування пайплайну: збір → ембедінг → кластеризація → RCA → звіт
• Реалізація API або інтеграція з вашою CRM/helpdesk (Zendesk, Jira Service Management, Bitrix24)
• Навчання моделі на ваших даних (few-shot, від 500 звернень)
• Налаштування порогів та алертів (Slack, Telegram, email)
• Документація та навчання команди (2 години відео + гайд)

Гарантуємо SLA по точності виявлення: >90% системних проблем не вислизнуть (тестуємо на вашому датасеті).

Терміни і як почати

Базове рішення — від 3 до 6 тижнів. Все залежить від обсягу даних і глибини інтеграції. Зв'яжіться з нами — оцінимо проєкт за 2 робочих дні. Замовте демо на ваших даних, щоб переконатися в ефективності до покупки.

Чому ручний аналіз програє AI

Досвід команди — 8+ років у ML, 15 успішних впроваджень у ритейлі та fintech. Ми використовуємо перевірений стек: Hugging Face Transformers, Qdrant, vLLM для інференсу. Отримайте консультацію — розрахуємо економію для вашого бізнесу.