Разработка AI-системы автоматической классификации обращений по тематике и приоритету
Ваш сервис-деск обрабатывает 500+ заявок ежедневно. Треть — критичные P1, но ручная сортировка затягивает первый ответ и множит SLA-нарушения. Клиенты уходят, LTV падает. Мы решаем это через двумерную AI-классификацию: модель одновременно определяет тему обращения и его приоритет. Такой подход ускоряет обработку в 3 раза по сравнению с ручной сортировкой. Один из клиентов в ритейле сократил SLA-нарушения на 40% после внедрения. Система использует квантизированные LLaMA 3 с INT4 для экономии GPU-памяти.
Как AI-система определяет приоритет обращения?
Приоритет вычисляется не по ключевым словам, а по композитному сигналу: сегмент клиента (VIP → повышенный), повторность (третье обращение по одной теме → эскалация), эмоциональный фон (гнев → P1) и финансовый ущерб (упоминание потерь). Все сигналы взвешиваются в едином запросе к LLM с JSON-выходом:
class TicketClassification(BaseModel): topic: str subtopic: str | None priority: Literal["P1", "P2", "P3", "P4"] sentiment: Literal["positive", "neutral", "negative", "angry"] is_escalation_required: bool reasoning: str def classify_ticket(text: str, customer_profile: dict) -> TicketClassification: prompt = f"""Классифицируй обращение. Учти контекст клиента: {format_profile(customer_profile)} Обращение: {text}""" return llm.parse(prompt, response_format=TicketClassification) Почему важна двумерная классификация?
Однозначная классификация темы или приоритета в отрыве друг от друга приводит к ошибкам маршрутизации. Например, не могу оплатить может быть биллингом (P2) или срочным платежом (P1), если клиент VIP. Двумерная классификация даёт точность 95% (по экспертной разметке) и снижает ложные эскалации на 30%.
Сравнение: правило-базированная vs AI-классификация
| Параметр | Правила (регулярки, логи) | AI-классификация |
|---|---|---|
| Точность определения темы | 60–70% | 90–95% |
| Обработка сложных неоднозначностей | Требует ручного кейса | Few-shot за 5 примеров |
| Время внедрения новых правил | 1–2 дня (код + тесты) | 30 минут (дополнить промпт) |
| Стоимость эксплуатации | Низкая, но растёт с числом правил | Средняя, масштабируется |
Мы используем гибридный подход: правила для чётких паттернов («не работает сайт» → P1), AI — для неоднозначных случаев.
Выбор модели: GPT-4o vs Claude 3.5 vs LLaMA 3
| Модель | Точность (F1) | Latency p99 (500 токенов) | Стоимость за 1K токенов |
|---|---|---|---|
| GPT-4o | 96% | 1.2 с | высокая |
| Claude 3.5 | 95% | 0.8 с | средняя |
| LLaMA 3 70B | 93% | 2.1 с (локально) | низкая (с квантизацией) |
Выбор модели зависит от ваших SLA по latency и бюджета. Для high-load систем рекомендуем LLaMA 3 с INT4 квантизацией — это даёт экономию средств до 60% без значительной потери точности. Подробнее о моделях читайте на Wikipedia: Large language model.
Как строится система классификации под ключ
Процесс включает 5 этапов:
- Аудит данных — собираем и размечаем выборку (500–1000 обращений). Типичные ошибки — путаница между темой и подтемой («жалоба» vs «претензия»).
- Выбор модели — тестируем GPT-4o, Claude 3.5 Sonnet или локальную LLaMA 3 70B под ваши объёмы и latency. Применяем квантизацию INT4 для снижения cost-per-token на 60%.
- Интеграция — подключаем модель к API, добавляем кэширование на ChromaDB для однотипных запросов, настраиваем мониторинг accuracy и latency p99.
- Динамическая переклассификация — если обращение не обработано за X часов, система автоматически повышает приоритет на один уровень. При изменении тональности с негативной на агрессивную — пересчёт с эскалацией.
- Деплой и поддержка — разворачиваем через vLLM или Triton Inference Server. Опыт нашей команды — 5+ лет в ML-продакшене, десятки внедрений в ритейле и финтехе.
Чек-лист для разметки данных
- Минимум 500 размеченных обращений, равномерно по темам.
- Каждое обращение с метками: тема, подтема, приоритет, тональность.
- Для редких классов используйте синтетическую генерацию.
- Проведите inter-annotator agreement (не менее 80%).
Что входит в работу
- Обученная модель с точностью 90%+ на ваших данных
- REST API с OpenAPI-документацией
- Интеграционный модуль для вашей CRM (Bitrix24, AmoCRM, Zendesk)
- Дашборд мониторинга в Grafana: распределение тем, приоритетов, violation-статистика
- Двухнедельная поддержка после релиза с коррекцией модели
Ориентировочный срок проекта — от 3 до 5 недель в зависимости от объёма данных и сложности интеграции. Точную оценку дадим после бесплатного аудита. Закажите разработку системы и получите консультацию по вашим данным. Свяжитесь с нами, чтобы начать.