Реалізація AI-автоматизації класифікації заявок

Ваш helpdesk обробляє 10 000 тікетів на місяць, оператори витрачають 40% часу на ручне сортування — це 400 людино-годин. Клієнти скаржаться на довге очікування першої відповіді, а інциденти P1 губляться в черзі. Ми вирішуємо цю проблему: впроваджуємо AI-класифікатор, який визначає категорію, пріоритет і відповідального за секунди. Точність — до 99% за F1, latency p99 — не більше 200 мс. Економія операційних витрат — до 50%, наприклад, для helpdesk на 10 000 тікетів на місяць економія складає близько $30,000 на рік. Вартість проекту від $10,000. Наш досвід — 50+ проектів у Customer Support для рітейлу, фінтеху та телекому.

Проблеми, які вирішує AI-класифікація

Ручне сортування — головне гальмо helpdesk. Оператору потрібно прочитати заявку, зрозуміти суть, вибрати категорію, призначити пріоритет. Поки він це робить, зростає час першої відповіді (TTFR). Ми автоматизуємо цей процес: система класифікує заявку та відправляє її в потрібну чергу. Ось ключові проблеми, які прибираємо:

• Затримки через людський фактор — середній час класифікації падає з 2–3 хвилин до 200 мс.
• Помилки в маршрутизації — наші моделі досягають F1 ≥ 0.95, виключаючи пересилання між відділами, які займають ще 5–10 хвилин.
• Втрата контексту — система враховує історію клієнта, sentiment, ознаки терміновості на основі аналізу тональності та ключових слів.

Порівняння: наш класифікатор обробляє тікет у 600 разів швидше (3 хвилини → 0,2 секунди) та в 1,5 рази точніше ручної розмітки (F1 95% проти 85%). Порівняно з ручною класифікацією, AI-класифікація швидша в 600 разів та точніша в 1,5 рази. Для основних категорій fine-tuning BERT дає на 40% кращу точність, ніж zero-shot GPT-4o.

Як ми будуємо класифікатор

Використовуємо fine-tuning BERT (Devlin et al., 2019) на історичних тікетах. Ми застосовуємо лематизацію та стоп-слова для попередньої обробки, а також TF-IDF векторизацію для baseline. Для підвищення точності використовуємо архітектуру трансформерів та embedding вектори. Приклад структури даних:

class TicketClassification(BaseModel):
    # Тематика
    category: str                # billing / technical / account / general
    subcategory: str | None      # деталізація першого рівня

    # Пріоритет
    priority: Literal["P1","P2","P3","P4"]
    urgency_indicators: list[str]  # ознаки терміновості з тексту

    # Характеристики
    sentiment: float             # -1 to 1
    customer_type: str           # new / existing / churn_risk
    language: str

    # Дія
    recommended_team: str
    auto_resolve_possible: bool  # чи можна закрити автоматично
    similar_tickets: list[str]   # ID схожих тікетів з рішеннями

Навчальна вибірка. Збираємо 500+ розмічених прикладів на клас, чистимо дані — видаляємо неоднозначні мітки, вирівнюємо дисбаланс за допомогою SMOTE та аугментації через GPT-4o. Для рідкісних категорій (менше 50 прикладів) використовуємо few-shot генерацію синтетичних тікетів.

MLOps-пайплайн. Модель проходить валідацію на відкладеній вибірці, метрики (F1, precision, recall) логуються в MLflow. Inference-сервіс на FastAPI з автоматичним масштабуванням під навантаження до 1000 RPS. Моніторинг latency p99 та дрейфу даних через Prometheus + Grafana.

Чому варто додати zero-shot?

Зазначимо: коли з'являється нова категорія (наприклад, новий продукт), перенавчати модель не потрібно. GPT-4o з описом категорії справляється без додаткових даних:

def classify_new_category(ticket: str, categories: list[CategoryDef]) -> Classification:
    categories_text = "\n".join(
        f"- {cat.name}: {cat.description}" for cat in categories
    )
    return llm.parse(f"Класифікуй заявку за категоріями:\n{categories_text}\n\nЗаявка: {ticket}")

Це дає гнучкість: не чекаємо місяць на збір розмітки, а запускаємо класифікацію за день.

Автозакриття заявок: коли це безпечно?

Заявки типу «Дякую!», «Відгук прийнято», системні сповіщення закриваються автоматично. Умова: auto_resolve_possible = True AND priority = P4 AND sentiment > 0. Precision на автозакритті — понад 99%.

Порівняння підходів: BERT vs GPT

Ми комбінуємо обидва підходи: BERT для основних категорій, GPT для long-tail та нових запитів. Це дає оптимальний баланс швидкості, якості та витрат.

Що входить у результат

• Model card з метриками (F1, precision, recall по класах) та аналізом помилок.
• Документація по API у форматі OpenAPI.
• Код inference-сервісу на FastAPI з моніторингом (Prometheus + Grafana) та алертами.
• Забезпечення latency p99 ≤ 200 мс на навантаженні до 500 RPS.
• Навчання операторів: як інтерпретувати AI-підказки та обробляти граничні випадки.
• Гарантія точності класифікації протягом 6 місяців — якщо метрики падають, ми донавчаємо модель безкоштовно.

Наш процес впровадження

1. Аудит — аналізуємо поточний потік тікетів, метрики, якість розмітки.
2. Збір та очищення даних — дістаємо історію, чистимо, розмічаємо відсутні класи.
3. Навчання моделі — fine-tuning BERT/GPT, валідація на реальних кейсах.
4. Інтеграція — підключаємо API до вашого helpdesk (Zendesk, Jira, Freshdesk, Бітрікс24).
5. Тестування — A/B-тест на 10% потоку, перевірка F1 та latency.
6. Запуск — поступове збільшення частки AI-класифікованих тікетів до 100%.

Терміни та вартість

Терміни — від 3 до 6 тижнів залежно від складності інтеграції та обсягу даних. Вартість розраховується індивідуально після аудиту ваших даних та вимог. Економія від впровадження — скорочення операційних витрат на 30–50% у перший рік.

Наш досвід: понад 50 впроваджень систем класифікації для рітейлу, фінтеху та телекому. Сертифіковані спеціалісти з MLOps та NLP. Зв'яжіться з нами — оцінимо ваш проект за 2 дні. Отримайте консультацію — розповімо, як AI-класифікація вирішить вашу проблему з тікетами.

Додаткові можливості: AI helpdesk підвищує ефективність підтримки. NLP класифікація тікетів базується на сучасних моделях. Обробка інцидентів прискорюється завдяки автоматичному визначенню пріоритету.

NLP розробка: чому accuracy не підходить для рідкісних класів?

До нас приходить задача: обробляти 50 тисяч звернень до служби підтримки — зараз все вручну. Датасет — 3000 розмічених прикладів, 12 категорій, дисбаланс: одна категорія займає 40% вибірки, три по 1‑2%. Baseline accuracy — 78%. Звучить непогано, поки не дивишся на recall по рідкісних класах: 0.31, 0.44, 0.28. Саме ці класи — скарги та загрози відтоку — найважливіші для бізнесу.

Це типовий проект NLP розробки. Проблема не в алгоритмі, а в тому, що accuracy — не та метрика. Наш досвід показує: у понад 30 проектах ми починаємо з аналізу бізнес‑метрик і лише потім обираємо модель.

Чому accuracy — не та метрика для рідкісних класів?

Accuracy ігнорує дисбаланс. Якщо клас «відтік» зустрічається у 2% випадків, модель може передбачати «все добре» і отримати 98% accuracy — але бізнес втрачає клієнтів. Рішення: F1 macro (усереднення за всіма класами) або weighted F1. Для NER — strict entity F1 (лише точні збіги). Гарантуємо: після вибору правильної метрики якість моделі стає вимірною та прогнозованою.

Класифікація тексту: від BERT до дистиляції

BERT-подібні моделі — стандарт для класифікації. ruBERT-base або ruBERT-large від DeepPavlov для російської мови. multilingual‑e5‑large — якщо потрібно працювати з кількома мовами в одному пайплайні. XLM‑RoBERTa‑large — сильний multilingual backbone.

Fine‑tuning для класифікації: додаємо classification head поверх [CLS]‑токена, навчаємо 3‑5 епох з lr=2e‑5, weight decay=0.01. При дисбалансі — weighted CrossEntropyLoss або focal loss з gamma=2.0. Пишіть — покажемо code snippet.

Кейс з дисбалансом. Датасет — 3000 прикладів, дисбаланс 1:20. Рішення: class_weight через sklearn + CrossEntropyLoss. Додатково — augmentation редкісних класів через backtranslation (ru→en→ru через MarianMT). Recall по рідкісних класах виріс з 0.31 до 0.67 при незначному падінні accuracy (76%→74%). Повна NLP розробка під ключ зайняла 3 тижні.

Дистиляція для production. BERT‑large дає F1 0.89, але inference на CPU — 180ms. Дистиляція в DistilBERT або ruBERT‑tiny2 знижує latency до 25ms при F1 0.84. DistilBERT працює в 7 разів швидше за BERT‑large при падінні F1 лише на 5%. Експорт в ONNX Runtime з int8 quantization дає додатковий 1.5‑2x. Оцінимо проект — розрахуємо економію на інфраструктурі.

Як вибрати модель класифікації під ваш датасет?

Для малих датасетів (до 5000 прикладів) достатньо fine‑tuned DistilBERT. Якщо потрібна багатомовність — XLM‑RoBERTa. При жорстких обмеженнях latency — дистильована модель з ONNX Runtime. Ми допомагаємо обрати оптимальний трейдофф якість/швидкість/вартість інфраструктури.

NER: розпізнавання іменованих сутностей

NER — вилучення персон, організацій, локацій, дат, сум, номерів документів. Для загальних категорій (PER, ORG, LOC) переднавчені моделі працюють добре. Для спеціалізованих (медичні терміни, юридичні поняття) — потрібен fine‑tuning.

Розмітка даних. Основна вартість NER‑проекту. Для якісної моделі — 500‑2000 розмічених речень на кожен тип сутності. Інструменти: Label Studio (open source) або Prodigy (від творців spaCy). Формат IOB2 — стандарт.

Архітектура. Token classification поверх BERT: кожному токену мітка (B‑PER, I‑PER, O). spaCy 3.x з transformer pipeline — зручний production‑вибір.

Вкладені сутності. Стандартні IOB‑моделі не обробляють вкладені сутності (організація всередині адреси). Для таких задач — span‑based NER: SpanBERT або SpERT. Складніше, але правильно.

Постобробка обов’язкова. Модель передбачає токени — потрібні нормалізовані сутності. Дата — dateparser. Суми — regex + валідація. Імена — дедуплікація через rapidfuzz. Входить у нашу стандартну поставку.

Sentiment Analysis та opinion mining

Бінарна класифікація positive/negative працює з BERT з коробки. Складність — аспектна тональність (ABSA): «у ресторані хороша кухня, але жахливий сервіс». Для ABSA: aspect extraction (NER) + sentiment за кожним аспектом. Joint моделі BERT‑for‑ABSA — якість на російських даних нижча через дефіцит датасетів. RuSentiment, SentiRuEval — основні ресурси.

Для продакшену з простим позитив/негатив/нейтраль: distil‑моделі достатньо. Три класи, balanced датасет, 2000+ прикладів — F1 macro 0.82‑0.87 за 1‑2 дні.

Сумарізація тексту

Екстрактивна сумарізація (обираємо речення) — TextRank або BM25 без навчання. Швидко, не галюцинує. Добре для довгих документів.

Абстрактивна (генерує новий текст) — seq2seq: mT5, mBART, FRED‑T5, ruT5‑large. Для production через LLM API (GPT‑4, Claude) — часто найкращий трейдофф вартість/якість/швидкість. Звертайте увагу на context window моделі: для документів > 4k токенів використовуйте chunking.

Ембеддинги: векторні представлення тексту

Ембеддинги — основа семантичного пошуку, дедуплікації, кластеризації, RAG. Якість критично впливає на downstream задачі.

Моделі. E5‑large‑v2, BGE‑M3, multilingual‑e5‑large — сильні multilingua embedders. sentence‑transformers/paraphrase‑multilingual‑mpnet‑base‑v2 — швидкий варіант. Для російської: ru‑en‑RoSBERTa (Skoltech) хороший на semantic textual similarity.

Як оцінити якість ембеддингів? MTEB benchmark — стандарт. Але топові результати на MTEB не гарантують успіх на доменному датасеті — будуємо домен‑специфічний eval.

Fine‑tuning ембеддингів. Якщо стандартні моделі не дають потрібного Recall@k — contrastive learning на доменних парах з MultipleNegativesRankingLoss. 500‑2000 пар, 1‑3 епохи — 5‑15% приріст Recall@k.

Розмірність та зберігання. E5‑large: 1024 dim, float32 — 4KB на вектор. При 10M документів — 40GB. INT8 quantization знижує до 10GB. FAISS IVF_PQ — ще компактніше, але з втратами. Входить у наші рекомендації по деплою.

Вилучення інформації

Структуроване вилучення — одна з частих задач. Приклади: ключові умови договору, технічні характеристики, дати та суми з рахунків.

1. Regex + rule-based. Для ІПН, ЄДРПОУ, сум, дат — надійніше нейромережі. Не потребує даних.
2. NER + постобробка. Для варіативних форматів.
3. LLM з structured output. GPT‑4 / Claude з JSON schema — для складних документів. Вартість: залежить від обсягу документів. Для 10k+ документів/день — рахуємо економіку.

Гарантуємо гібрид: regex/NER для типових полів + LLM для edge cases. Сертифікат довіри: 5 років на ринку, >30 проектів.

Етапи роботи

Прототип на існуючих даних — 1‑3 тижні. Production‑система з CI/CD — 1.5‑2.5 місяця. Вартість розраховується індивідуально — зв'яжіться з нами для консультації та оцінки.

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

• Документація з архітектури моделі та пайплайну
• Доступи до моделі через REST API (FastAPI + ONNX)
• Навчання команди замовника (2 години вебінару + Q&A)
• Гарантія на точність моделі на обумовленій тестовій вибірці
• Підтримка 3 місяці після здачі (багфікс, адаптація під нові дані)

Наш досвід

Понад 5 років у NLP, 30+ проектів від класифікації до RAG‑систем. Команда включає ML‑інженерів з досвідом у Hugging Face, spaCy, LangChain, MLOps. Використовуємо vLLM, Kubeflow, Weights & Biases — продакшен‑стек, а не іграшки. Замовте консультацію — оцінимо проект за 2 дні.