Классификация приоритета обращений

Автоматизация процесса приоритизации инцидентов для IT-сервис-деска с использованием методов машинного обучения.

Обзор проекта

Проект предназначен для автоматического назначения приоритета (Low, Medium, High) входящим тикетам на основе их характеристик

Критерии успеха:

• Высокое значение метрики F1-macro (учитывая дисбаланс классов).
• Минимизация критических ошибок: исключение ситуаций, когда тикеты высокого приоритета (High) ошибочно классифицируются как низкоприоритетные (Low).
• Интерпретируемость: понимание того, какие факторы заставляют модель принимать то или иное решение.

Данные

Используется синтетический набор данных Support Ticket Priority Dataset (50k), отражающий работу службы поддержки.

• Объем - 50 тысяч записей
• 33 исходных признака (операционные метрики, категориальные данные о клиентах, бинарные флаги критичных инцидентов, тональность текста и др.)
• Присутствует естественный дисбаланс классов (Low: ~50%, Medium: ~35%, High: ~15%).

ML Pipeline

1. Предобработка и EDA

Проведен разведочный анализ данных: выявлены асимметрии в распределениях и скоррелированные признаки.

• Мультиколлинеарность: удален признак org_users (corr = 0.94 с company_size_cat) для повышения устойчивости моделей.
• Удалены неинформативные идентификаторы (ID).
• Разделение данных выполнено с использованием stratify для сохранения баланса классов в выборках (Train 70% / Val 15% / Test 15%).

2. Обучение моделей и оптимизация гиперпараметров

В качестве baseline и основных решений были протестированы следующие алгоритмы:

• LogisticRegression
• RandomForestClassifier
• HistGradientBoostingClassifier
• XGBClassifier

Оптимизация гиперпараметров проводилась с помощью Optuna (50 trials) с кросс-валидацией. Целевой метрикой для оптимизации была выбрана F1-macro, так как она объективно оценивает качество работы с миноритарным классом (High priority).

3. Оценка и интерпретация

• Лучшая модель - XGBoostClassifier:
  • F1-Score (macro) = 0.98
• Анализ матрицы ошибок (Confusion Matrix) показал, что модель успешно справляется с минимизацией бизнес-рисков — критические инциденты (High) никогда не классифицируются как низкоприоритетные (Low).
• Для объяснения логики модели применен метод SHAP. Анализ показал, что модель опирается в первую очередь на измеримые последствия инцидента (customers_affected, downtime_min, error_rate_pct), а фоновые характеристики выступают как уточняющие сигналы. Это полностью согласуется с реальной бизнес-логикой.

Установка и запуск

Предварительные требования

• Python

1. Клонирование репозитория

git clone https://github.com/KnightKotOR/SupportTickets-Prioritization

2. Установка зависимостей

uv python install 3.10

uv sync --all-extras --dev

3. Обучение и инференс модели

support_tickets.ipynb

4. Тестирование

Ruff (linter and formatting):

uv run ruff check . --fix

uv run ruff format .

Pytests:

uv run pytest -n auto

Идея для развития проекта:

Создать искусственный поток данных на основе датасета, который бы проходил через обработку (ETL), и подавался в контейнезированную ML-систему с airflow+spark+mlflow+rabbitmq/kafka

Требуется

1. Разработать генератор запросов в службу поддержки на основе исходного набора данных

• Проанализировать структуру исходного датасета.
• Реализовать сервис генерации событий с регулируемой интенсивностью.
• Эмулировать поток обращений в реальном времени.
• Добавить возможность генерации сезонных всплесков нагрузки и аномалий, а также пропущенных/недостоверных значений.
• Публиковать события в Kafka/RabbitMQ.

2. Создать пайплайн предобработки потока в признаки для ML-модели

• Организовать прием сообщений из брокера.
• Реализовать ETL-процесс на Spark Structured Streaming.
• Выполнить очистку и валидацию данных.
• Реализовать сохранение обработанных данных в Feature Store или промежуточное хранилище.

3. Адаптировать решение XGBoost + Optuna под MLflow

• Интегрировать обучение модели с MLflow Tracking.
• Логировать параметры экспериментов, метрики и артефакты.
• Реализовать автоматический подбор гиперпараметров через Optuna.
• Организовать хранение лучших моделей в MLflow Registry.
• Подготовить механизм воспроизводимого переобучения модели.

4. Развернуть инфраструктуру в Docker Compose

• Контейнеризировать все компоненты системы.
• Настроить взаимодействие между:
  • Airflow;
  • Spark;
  • Kafka/RabbitMQ;
  • MLflow;
  • PostgreSQL;
  • сервисом генерации данных.
• Организовать единое сетевое пространство и тома для хранения данных.

5. Реализовать оркестрацию процессов через Airflow

• Создать DAG для запуска ETL-процесса.
• Создать DAG для периодического обучения модели.
• Создать DAG для валидации и регистрации новых моделей.
• Настроить мониторинг выполнения задач и уведомления об ошибках.

6. Реализовать сервис инференса модели

• Развернуть REST API (FastAPI).
• Загружать актуальную модель из MLflow Registry.
• Выполнять предсказания для новых обращений.
• Обеспечить возможность онлайн-обработки сообщений из брокера.

7. Настроить мониторинг и наблюдаемость

• Собирать технические метрики сервисов.
• Отслеживать качество модели на новых данных.
• Реализовать мониторинг data drift и concept drift.
• Настроить визуализацию через Grafana.

8. Провести нагрузочное тестирование

• Проверить устойчивость системы при различной интенсивности потока.
• Измерить задержки ETL и инференса.
• Оценить масштабируемость решения.

Желаемый итоговый результат

Контейнеризированная потоковая MLOps-платформа, демонстрирующая полный цикл: Генерация данных → Kafka/RabbitMQ → Spark ETL → Feature Engineering → Обучение XGBoost → MLflow Registry → API инференса → Мониторинг и обучение.