Привет, Хабр! Расскажу как я fine-tuned модель Qwen2.5-0.5B для автоматической классификации обращений в службу поддержки, сквантовал её до 350 MB и задеплоил нПривет, Хабр! Расскажу как я fine-tuned модель Qwen2.5-0.5B для автоматической классификации обращений в службу поддержки, сквантовал её до 350 MB и задеплоил н

Как я сделал классификатор обращений для телеком-поддержки на своей LLM за $10/месяц

Привет, Хабр! Расскажу как я 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 и извлечёнными сущностями.

Почему не облачный API?

  1. Стоимость. При 50K обращений/месяц облачные LLM (OpenAI, Claude, Gemini) обойдутся в ~$100-200. Своя модель на VPS — $10-20.

  2. Приватность. Банки, госы, телеком — данные клиентов нельзя отправлять на внешние серверы.

  3. Latency. Своя модель работает стабильно, без зависимости от внешнего API.

  4. Контроль. Модель можно дообучить под специфику конкретной компании.

Архитектура решения

Классическая схема: клиент отправляет тикет → FastAPI принимает запрос → LLM (GGUF Qwen 0.5B) классифицирует → результат логируется в SQLite и возвращается клиенту. Всё это крутится под nginx на VPS.

Модель

Выбор базовой модели

Выбрал Qwen2.5-0.5B-Instruct:

  • Маленькая (0.5B параметров) — быстрый инференс на CPU

  • Хорошо понимает инструкции

  • Поддерживает русский и английский

Датасет

Сгенерировал ~4000 примеров обращений с разметкой:

  • Технические проблемы (интернет, ТВ, мобильная связь)

  • Биллинг (вопросы по счетам, ошибки списания)

  • Отток (отмена подписки, угрозы уйти)

  • Общие вопросы

Каждый пример — это пара "входное сообщение → JSON с метками".

Fine-tuning

Использовал 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, качество почти не пострадало.

Бэкенд

FastAPI + llama-cpp-python

Простой API-сервер: загружаем GGUF-модель, принимаем POST-запросы на /api/v1/classify, формируем промпт с системным сообщением и текстом пользователя, парсим JSON из ответа модели.

Детекция мусора

Добавил эвристику для фильтрации нерелевантных запросов:

  • Проверка длины текста (< 10 символов = мусор)

  • Поиск телеком-ключевых слов (wifi, internet, bill, phone и т.д.)

  • Если нет ключевых слов и category=unknown — запрос помечается как нерелевантный

Деплой

Docker

Стандартный Python-образ, устанавливаем зависимости (fastapi, uvicorn, llama-cpp-python, sqlalchemy), копируем приложение, запускаем uvicorn.

VPS

  • Конфиг: 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 примеров) точность будет выше — модель лучше адаптируется под специфику конкретного бизнеса.

Почему 3-5 секунд на VPS — это ок

Мой VPS использует старый Xeon E5-2680 v2 (2013 год, без AVX2). На современном CPU будет 1-2 сек, на GPU — 100-200 мс.

Но для классификации тикетов это не критично:

  • Это не real-time чат

  • Классификация происходит при создании тикета

  • Можно обрабатывать асинхронно через очередь

Что дальше

  1. RAG — добавить базу знаний для ответов на типовые вопросы

  2. Мультиязычность — дообучить на казахском/узбекском для СНГ рынка

  3. Интеграции — коннекторы к популярным helpdesk системам

Выводы

Fine-tuning небольших моделей (0.5B-3B) имеет смысл когда:

  • Нужна приватность данных (on-premise)

  • Высокий объём однотипных запросов

  • Специфичная доменная область

Для остального — проще использовать GPT API.


Хотите такое решение для своей компании? Пишите в Telegram — обсудим задачу и сделаем MVP за неделю.

Демо | API

Источник

Отказ от ответственности: Статьи, размещенные на этом веб-сайте, взяты из общедоступных источников и предоставляются исключительно в информационных целях. Они не обязательно отражают точку зрения MEXC. Все права принадлежат первоисточникам. Если вы считаете, что какой-либо контент нарушает права третьих лиц, пожалуйста, обратитесь по адресу service@support.mexc.com для его удаления. MEXC не дает никаких гарантий в отношении точности, полноты или своевременности контента и не несет ответственности за любые действия, предпринятые на основе предоставленной информации. Контент не является финансовой, юридической или иной профессиональной консультацией и не должен рассматриваться как рекомендация или одобрение со стороны MEXC.