Intent Detection для чат-бота: таксономія, модель, моніторинг

«Хочу замовити піцу», «статус мого замовлення», «як повернути гроші» — три різних інтенти. Якщо чат-бот не відрізнить їх, користувач піде. Без якісного intent detection бот не зможе коректно маршрутизувати запит, обробляти помилки та підтримувати діалог. Невірна класифікація намірів призводить до втрати клієнтів та збільшення навантаження на операторів. Ми вирішуємо це завдання, проектуючи таксономію, обираючи модель (BERT, LLM або гібридний підхід) та впроваджуючи моніторинг.

Результат — точність >90% на цільових інтентах, p99 latency <200 мс. Наші рішення з intent detection протестовані на реальних навантаженнях: до 10 000 запитів на добу, спад якості не більше 3% через пів року. Досвід — понад 10 років у NLP, більше 40 проєктів, включаючи ботів для e-commerce, фінтеху та техпідтримки. Економія на обробці запитів для клієнтів: до 60% зниження витрат на ручну підтримку. Швидка окупність.

Проектування таксономії інтентів

Правило: кожен інтент — одна конкретна намірена дія з чітким обробником. Типові помилки:

• Занадто широкий інтент: help — незрозуміло, що робити.
• Дублювання: order_status і check_my_order — один інтент.
• Нечіткі межі: complaint vs negative_feedback — часто неочевидні.

Для чат-бота середньої складності: 20–50 інтентів. Більше 100 — ознака поганої архітектури; перегляньте ієрархію.

Чому гібридний підхід кращий за класичний?

Класичний підхід (Rasa NLU, Dialogflow) навчається на labeled прикладах: детермінований, швидкий (<10 ms), але потребує 50–200 прикладів на інтент і не адаптується без перенавчання. LLM-based (GPT-4o-mini з few-shot) не потребує навчання, гнучкий, але повільніший (200–500 ms) і дорожчий за cost per token. Гібрид — BERT як перший прохід (швидкий, дешевий), LLM як fallback для low-confidence та нестандартних випадків. У наших проєктах ми використовуємо саме таку схему: вона дає баланс швидкості та покриття.

Порівняння за ключовими метриками: гібрид у 10 разів швидший за чистий LLM при порівнянному покритті. Детальніше про модель BERT.

Як ми реалізуємо гібридний класифікатор?

1. Аудит і проектування таксономії. Аналізуємо історію діалогів, виділяємо часті теми, будуємо карту намірів. Проводимо воркшоп з вашою командою, щоб визначити межі інтентів. Результат — документ з ієрархією, слотами та правилами fallback.

2. Розмітка датасету. Збираємо 100–300 прикладів на інтент (реальні фрази користувачів). Додаємо confusion matrix-негативні приклади — фрази зі схожих інтентів, щоб «розтягнути» межі класів. Приклад: «я хочу змінити замовлення» vs «я хочу скасувати замовлення» — різні інтенти, але в датасеті мають бути обидва.

3. Навчання та калібрування. Fine-tuning BERT (наприклад, DeepPavlov/rubert-base-cased) з крос-ентропією. Калібруємо confidence threshold (зазвичай 0.6): при меншій впевненості — передаємо запит LLM.

from transformers import pipeline intent_classifier = pipeline( "text-classification", model="./intent_classifier", tokenizer="DeepPavlov/rubert-base-cased", top_k=3 ) def detect_intent(text: str) -> IntentResult: results = intent_classifier(text) top = results[0] if top["score"] < 0.6: # Fallback до LLM return llm_classify_intent(text) return IntentResult(intent=top["label"], confidence=top["score"]) 

4. Інтеграція та деплой. Деплоїмо модель через Triton Inference Server або ONNX Runtime — latency p99 <50 ms на GPU. Налаштовуємо моніторинг: confusion matrix раз на тиждень, логи OOS, пайплайн зворотного зв'язку. Гарантуємо, що модель не «просідає» на нових даних: якщо метрика accuracy падає нижче 85% — автоматичний тригер на донавчання.

Моніторинг confusion matrix та запобігання дрейфу

Confusion matrix — головний інструмент для виявлення проблемних пар інтентів. Якщо, наприклад, order_status та change_order часто плутаються, додаємо в датасет більше confusing negatives. Регулярний аналіз OOS-логів допомагає виявити нові наміри користувачів, які варто винести в окремі інтенти. В результаті точність класифікації не падає з часом.

Deliverables проєкту

• Документація таксономії інтентів (Google Docs / Confluence)
• Датасет з розміткою (формат JSONL, CSV)
• Навчена модель + Docker-образ для деплою
• Інтеграція з вашим ботом (REST API, gRPC)
• Навантажувальне тестування (результат: p99 latency <200 ms)
• Моніторинг та алертинг (Grafana dashboards)
• Навчання двох ваших інженерів роботі з пайплайном

Терміни та як замовити

Терміни розробки — від 2 до 6 тижнів залежно від складності таксономії та обсягу датасету. Вартість розраховується індивідуально після аудиту. Оцінимо ваш проєкт безкоштовно — зв'яжіться з нами для консультації. Замовте розробку intent detection та отримайте зниження помилок інтерпретації на 30–70%. Отримайте консультацію — ми підберемо оптимальний стек під ваш бюджет.