Привет, Хабр! Расскажу как я fine-tuned модель Qwen2.5-0.5B для автоматической классификации обращений в службу поддержки, сквантовал её до 350 MB и задеплоил на дешёвый VPS.
TL;DR: Модель классифицирует обращения клиентов по intent, category, urgency, sentiment и автоматически определяет куда маршрутизировать тикет. Работает на CPU, данные не покидают ваш сервер.
Демо | API Docs
В типичной службе поддержки телеком-оператора:
60% времени оператора уходит на понимание "а что вообще хочет клиент"
Тикеты маршрутизируются вручную и часто попадают не в тот отдел
Срочные проблемы теряются среди рутинных вопросов
Задача: Автоматически классифицировать входящее обращение и выдать структурированный JSON с intent, category, urgency, sentiment, route_to и извлечёнными сущностями.
Стоимость. При 50K обращений/месяц облачные LLM (OpenAI, Claude, Gemini) обойдутся в ~$100-200. Своя модель на VPS — $10-20.
Приватность. Банки, госы, телеком — данные клиентов нельзя отправлять на внешние серверы.
Latency. Своя модель работает стабильно, без зависимости от внешнего API.
Контроль. Модель можно дообучить под специфику конкретной компании.
Классическая схема: клиент отправляет тикет → FastAPI принимает запрос → LLM (GGUF Qwen 0.5B) классифицирует → результат логируется в SQLite и возвращается клиенту. Всё это крутится под nginx на VPS.
Выбрал Qwen2.5-0.5B-Instruct:
Маленькая (0.5B параметров) — быстрый инференс на CPU
Хорошо понимает инструкции
Поддерживает русский и английский
Сгенерировал ~4000 примеров обращений с разметкой:
Технические проблемы (интернет, ТВ, мобильная связь)
Биллинг (вопросы по счетам, ошибки списания)
Отток (отмена подписки, угрозы уйти)
Общие вопросы
Каждый пример — это пара "входное сообщение → JSON с метками".
Использовал Full Fine-Tuning (не LoRA) на Google Colab T4:
3 эпохи
Learning rate: 2e-5
Batch size: 4 (с gradient accumulation)
Время обучения: ~40 минут
Конвертировал в GGUF и сквантовал до Q4_K_M с помощью llama.cpp.
Результат: 350 MB вместо 1+ GB, качество почти не пострадало.
Простой API-сервер: загружаем GGUF-модель, принимаем POST-запросы на /api/v1/classify, формируем промпт с системным сообщением и текстом пользователя, парсим JSON из ответа модели.
Добавил эвристику для фильтрации нерелевантных запросов:
Проверка длины текста (< 10 символов = мусор)
Поиск телеком-ключевых слов (wifi, internet, bill, phone и т.д.)
Если нет ключевых слов и category=unknown — запрос помечается как нерелевантный
Стандартный Python-образ, устанавливаем зависимости (fastapi, uvicorn, llama-cpp-python, sqlalchemy), копируем приложение, запускаем uvicorn.
Конфиг: 2 vCore, 4 GB RAM, 60 GB SSD
Стоимость: ~$10-15/месяц
OS: Ubuntu 24.04 + Docker + nginx + Let's Encrypt
|
Метрика |
Значение |
|---|---|
|
Accuracy (intent) |
~92% |
|
Accuracy (category) |
~89% |
|
Inference time (VPS CPU) |
3-5 сек |
|
Inference time (Mac M4) |
150-300 мс |
|
Модель размер |
350 MB |
|
RAM usage |
~700 MB |
Важно: Это результаты на синтетическом датасете (~4000 примеров). На реальных данных компании и большем объёме (5-10K примеров) точность будет выше — модель лучше адаптируется под специфику конкретного бизнеса.
Мой VPS использует старый Xeon E5-2680 v2 (2013 год, без AVX2). На современном CPU будет 1-2 сек, на GPU — 100-200 мс.
Но для классификации тикетов это не критично:
Это не real-time чат
Классификация происходит при создании тикета
Можно обрабатывать асинхронно через очередь
RAG — добавить базу знаний для ответов на типовые вопросы
Мультиязычность — дообучить на казахском/узбекском для СНГ рынка
Интеграции — коннекторы к популярным helpdesk системам
Fine-tuning небольших моделей (0.5B-3B) имеет смысл когда:
Нужна приватность данных (on-premise)
Высокий объём однотипных запросов
Специфичная доменная область
Для остального — проще использовать GPT API.
Хотите такое решение для своей компании? Пишите в Telegram — обсудим задачу и сделаем MVP за неделю.
Демо | API
Источник


