Мы сталкивались с ситуацией, когда операторы поддержки вручную сортируют 500+ тикетов в день: биллинг, технические проблемы, жалобы. Это узкое место, которое ведёт к задержкам и ошибкам. Наша команда предлагает AI-решение для автоматической классификации обращений прямо в мобильном приложении — на клиенте или на сервере. Внедрение под ключ с гарантией точности и обучающей поддержкой. Средняя экономия бюджета на поддержку после внедрения AI-классификации составляет 30–50%.
Как AI распределяет тикеты поддержки?
Процесс классификации начинается с преобразования текста обращения в числовой вектор с помощью предобученной NLP-модели (например, bert-base-multilingual-cased). Затем модель вычисляет вероятности принадлежности к каждой категории. Выбирается метка с максимальной вероятностью — это и есть предсказанная категория. Результат может отображаться пользователю или направлять тикет в нужный отдел автоматически.
Где живёт классификация: на устройстве или на сервере?
Самый частый вопрос — нужна ли on-device модель или достаточно вызова API. Ответ зависит от двух вещей: объёма трафика и требований к латентности.
Для большинства приложений с поддержкой схема выглядит так: текст обращения уходит на backend, там классифицируется через LLM или fine-tuned BERT, ответ возвращается за 300–800 мс. На мобильном клиенте это просто URLSession/OkHttp запрос. Никакой Core ML не нужно.
Если нужна работа без интернета или минимальная задержка — тогда on-device. На iOS подходит CoreML с дистиллированной моделью (MobileNet-class, ~10–20 MB). На Android — TensorFlow Lite с делегатом GPU или NNAPI. Окупаемость решения наступает в течение 2–3 месяцев за счёт снижения нагрузки на операторов.
Как строим классификатор
Fine-tuned BERT через Hugging Face Inference API
Самый быстрый путь к продакшну — взять bert-base-multilingual-cased или distilbert-base-multilingual-cased, дообучить на датасете из ваших исторических тикетов (минимум 200–300 примеров на категорию) и задеплоить через Hugging Face Inference Endpoints.
Мобильный клиент шлёт POST:
// iOS struct ClassifyRequest: Encodable { let inputs: String } struct ClassifyResponse: Decodable { let label: String let score: Float } func classifyTicket(_ text: String) async throws -> ClassifyResponse { var request = URLRequest(url: URL(string: "https://api-inference.huggingface.co/models/your-model")!) request.httpMethod = "POST" request.setValue("Bearer \(apiKey)", forHTTPHeaderField: "Authorization") request.setValue("application/json", forHTTPHeaderField: "Content-Type") request.httpBody = try JSONEncoder().encode(ClassifyRequest(inputs: text)) let (data, _) = try await URLSession.shared.data(for: request) return try JSONDecoder().decode([ClassifyResponse].self, from: data).first! } На Android аналог через Retrofit + kotlinx.serialization. Результат — экономия времени операторов в 3–5 раз.
On-device через CoreML (iOS)
Если работа офлайн критична, экспортируем модель в .mlpackage. Вход — токенизированный текст, выход — probability vector по N категориям.
import CoreML import NaturalLanguage // Токенизация через NLTokenizer + embedding let model = try TicketClassifier(configuration: MLModelConfiguration()) let prediction = try model.prediction( input_ids: inputIds, // MLMultiArray attention_mask: attentionMask ) let categoryIndex = prediction.logits.argmax() // кастомный extension Тонкость: NLEmbedding даёт готовые word embeddings без серверного вызова, но для классификации по 10+ категориям точность будет ниже fine-tuned модели.
Предобработка текста
До отправки в модель обязательно:
- Обрезать до 512 токенов (лимит BERT) — длинный текст обрезаем с хвоста, оставляем начало где обычно суть проблемы
- Нормализовать Unicode:
text.folding(options: .diacriticInsensitive, locale: .current)— кириллица с ятями или латинские буквы в русском тексте ломают токенизатор - Удалить персональные данные перед отправкой на сервер: номера карт, телефоны через regex ещё на клиенте
Fine-tuning BERT на доменных данных даёт прирост точности до 10–20% по F1 по сравнению с универсальными моделями. — Devlin et al., 2019
Интеграция в UI форму обращения
Классификация запускается не по нажатию «Отправить», а с дебаунсом по onChange поля ввода — за 1.5–2 секунды паузы в наборе. Пользователь видит предложенную категорию и может скорректировать вручную.
// Android, Compose val ticketText by viewModel.ticketText.collectAsState() val suggestedCategory by viewModel.suggestedCategory.collectAsState() // ViewModel private val _ticketText = MutableStateFlow("") init { _ticketText .debounce(1500) .filter { it.length > 20 } .mapLatest { text -> classifyUseCase(text) } .onEach { _suggestedCategory.value = it } .launchIn(viewModelScope) } mapLatest отменяет предыдущий запрос при новом вводе — не накапливаем лишние сетевые вызовы.
Типичные ошибки
Слишком мало классов. Категория «другое» не должна превышать 15% от реального трафика — иначе в неё валится всё непонятное и классификатор теряет смысл. Если «другое» > 30%, нужен аудит таксономии категорий.
Не логируете confidence score. Если score < 0.6 — показывайте пользователю выбор вручную, не навязывайте категорию. Это видно в Firebase Crashlytics events, если правильно проставить кастомные атрибуты.
Модель не переобучается. Классификатор деградирует с ростом продукта: появляются новые типы обращений, старые категории меняются. Настройте пайплайн переобучения хотя бы раз в квартал по накопленным исправлениям операторов.
Почему fine-tuned BERT лучше готовых API?
Готовые API (OpenAI, Google NLP) работают «как есть» — вы не контролируете таксономию и платите за каждый запрос. Fine-tuned BERT на ваших данных даёт точность на 10-20% выше по метрике F1, не утекает данные третьим лицам, а стоимость инференса (через Hugging Face Inference Endpoints) в 2-3 раза ниже при 500+ запросах в день. Если важен офлайн — CoreML/TFLite обеспечивает 5-10 мс на классификацию без сети.
Процесс работы
| Этап | Содержание | Срок (диапазон) |
|---|---|---|
| Аудит таксономии тикетов | Сбор исторических данных, выявление 5-20 категорий | 1-2 дня |
| Разметка обучающей выборки | Аннотация 500-1000 примеров на категорию | 2-5 дней |
| Выбор архитектуры | API vs on-device: анализ требований к скорости и безопасности | 1 день |
| Обучение и валидация | Fine-tuning BERT, тестирование (80/20 split), достижение F1 > 0.9 | 5-8 дней |
| Интеграция в клиент | Код для iOS/Android, дебаунс, UI подсказка | 3-5 дней |
| A/B тест | Ручная vs AI-классификация на 10% трафика | 3-7 дней |
| Деплой и мониторинг | Запуск, логирование, оповещение при падении точности | 2 дня |
Сравнение архитектур
| Критерий | Серверная (API) | On-device (CoreML/TFLite) |
|---|---|---|
| Задержка | 300–800 мс | 5–10 мс |
| Офлайн-доступ | Требуется интернет | Полностью офлайн |
| Размер модели | Не ограничен | 10–20 МБ |
| Точность | 90–95% (fine-tuned) | 80–90% (дистиллированная) |
| Стоимость инференса | Плата за запрос | Нулевая |
Что входит в работу
Состав deliverables
- Документация: описание архитектуры, спецификация API, инструкция для операторов
- Код интеграции для iOS (Swift) и Android (Kotlin) с комментариями
- Обучение команды: 2 онлайн-сессии по настройке и поддержке
- Техническая поддержка на 1 месяц после деплоя
- Пайплайн переобучения модели (автоматизация с GitHub Actions)
Ориентиры по срокам
Интеграция с готовым API классификации (OpenAI, Hugging Face) — 3–5 дней. Fine-tuning собственной модели + интеграция — 2–4 недели. On-device CoreML/TFLite с экспортом модели — плюс 1 неделя сверху. Мы оценим ваш проект бесплатно и предложим оптимальный план.
Как начать?
Свяжитесь с нами: мы проанализируем ваш поток тикетов, подберём модель и сроки. Опыт нашей команды — 5+ лет в мобильной разработке, более 20 проектов с AI-классификацией. Мы гарантируем точность не ниже 90% на валидационной выборке. Закажите внедрение — получите решение под ключ с обучающей поддержкой. Убедитесь в эффективности: запросите консультацию уже сегодня.