AI-классификация тикетов поддержки в мобильном приложении

TRUETECH занимается разработкой, поддержкой и обслуживанием мобильных приложений iOS, Android, PWA. Имеем большой опыт и экспертизу для публикации мобильных приложений в популярные маркеты Google Play, App Store, Amazon, AppGallery и другие.

Разработка и поддержка любых видов мобильных приложений:

Информационные и развлекательные мобильные приложения
Новостные приложения, игры, справочники, онлайн-каталоги, погодные, фитнес и здоровье, туристические, образовательные, социальные сети и мессенджеры, квиз, блоги и подкасты, форумы, агрегаторы
Мобильные приложения электронной коммерции
Интернет-магазины, B2B-приложения, маркетплейсы, онлайн-обменники, кэшбэк-сервисы, биржи, дропшиппинг-платформы, программы лояльности, доставка еды и товаров, платежные системы
Мобильные приложения для управления бизнес-процессами
CRM-системы, ERP-системы, управление проектами, инструменты для команды продаж, учет финансов, управление производством, логистика и доставка, управление персоналом, системы мониторинга данных
Мобильные приложения электронных услуг
Доски объявлений, онлайн-школы, онлайн-кинотеатры, платформы предоставления электронных услуг, платформы кешбека, видеохостинги, тематические порталы, платформы онлайн-бронирования и записи, платформы онлайн-торговли

Это лишь некоторые из типы мобильных приложений, с которыми мы работаем, и каждый из них может иметь свои специфические особенности и функциональность, а также быть адаптированным под конкретные потребности и цели клиента.

Услуги, которые мы предлагаем
Показано 1 из 1Все 1734 услуг
AI-классификация тикетов поддержки в мобильном приложении
Средний
~3-5 дней
Часто задаваемые вопросы

Наши компетенции:

Этапы разработки

Последние работы

  • image_mobile-applications_feedme_467_0.webp
    Разработка мобильного приложения для компании FEEDME
    858
  • image_mobile-applications_xoomer_471_0.webp
    Разработка мобильного приложения для компании XOOMER
    745
  • image_mobile-applications_rhl_428_0.webp
    Разработка мобильного приложения для компании RHL
    1162
  • image_mobile-applications_zippy_411_0.webp
    Разработка мобильного приложения для компании ZIPPY
    1034
  • image_mobile-applications_affhome_429_0.webp
    Разработка мобильного приложения для компании Affhome
    968
  • image_mobile-applications_flavors_409_0.webp
    Разработка мобильного приложения для компании FLAVORS
    563

Мы сталкивались с ситуацией, когда операторы поддержки вручную сортируют 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% на валидационной выборке. Закажите внедрение — получите решение под ключ с обучающей поддержкой. Убедитесь в эффективности: запросите консультацию уже сегодня.

AI и ML в мобильных приложениях: CoreML, TFLite и on-device модели

Мы различаем два принципиально разных подхода: приложение с on-device AI и приложение, которое просто вызывает облачное API. Первое работает без интернета, не отправляет данные пользователя на сторонние серверы и отвечает за 50 миллисекунд. Второе зависит от задержки сети и тарифного плана. Выбор архитектуры — ключевой этап, который напрямую влияет на стоимость, приватность и пользовательский опыт. Наш опыт показывает: в 70% проектов on-device инференс оказывается дешевле в долгосрочной перспективе за счёт исключения серверных затрат.

Как выбрать между CoreML и TFLite для on-device инференса?

CoreML — нативный фреймворк Apple для запуска ML-моделей на устройстве. Поддерживает Neural Engine (начиная с A11 Bionic), GPU и CPU как fallback. Модели конвертируются в формат .mlmodel через coremltools из PyTorch, ONNX или TensorFlow. Конвертация — не всегда тривиальна: кастомные слои требуют реализации MLCustomLayer, а квантизация до INT8 иногда заметно роняет точность на специфических данных. Мы гарантируем, что итоговая модель проходит валидацию на реальных данных до и после конвертации.

TensorFlow Lite — кросс-платформенная альтернатива для Android и Flutter. На Android использует NNAPI (Neural Networks API) для хардварного ускорения — с Android 10 NNAPI стабильнее, до этого лучше явно использовать GPU delegate через GpuDelegate. Типичная ошибка: модель обучена на нормализованных данных в диапазоне [0,1], а в приложении на вход подаётся [0,255] — инференс работает, но с бессмысленными результатами без ошибки. Мы включаем модуль автоматической валидации входных данных в SDK.

Для задач классификации изображений, детекции объектов и сегментации доступны готовые оптимизированные модели. YOLOv8 в CoreML формате запускает детекцию кадра 640×640 за 15–20 мс на iPhone 14 Neural Engine. MobileNetV3 на TFLite с GPU delegate — около 8 мс на Pixel 7 при классификации.

Параметр CoreML TFLite
Платформы iOS, macOS, watchOS Android, iOS, Linux, embedded
Хардварное ускорение Neural Engine, GPU, CPU NNAPI, GPU (OpenCL/OpenGL), CPU
Поддержка квантизации FP16, INT8 (с coremltools) FP16, INT8, dynamic range
Кастомные операции Через MLCustomLayer (Swift) Через делегаты (Java/Kotlin)
Размер бандла модели ~3–5 МБ (MobileNetV2 quantized) ~2–4 МБ

Что делать, если нужна генерация текста на устройстве?

Запуск небольших языковых моделей на устройстве стал реальностью в последние несколько лет. Apple Intelligence использует собственные модели через Private Cloud Compute, но для сторонних разработчиков доступны другие пути.

llama.cpp с Metal backend на iOS — работающий подход для phi-3-mini (3.8B параметров, 4-bit квантизация, ~2.3 ГБ). Инференс: 15–25 токенов/секунду на iPhone 15 Pro. Для интеграции в Swift используем Swift Package llama.swift или обёртку через C-интерфейс llama.h. Бинарник к приложению не прикладываем — модель скачивается при первом запуске и хранится в Application Support. Наши сертифицированные разработчики настраивают инкрементальную загрузку, чтобы не блокировать первый запуск.

На Android аналог — Google AI Edge (бывший MediaPipe LLM Inference API) с поддержкой Gemma-2B. Работает через GPU delegate, на Tensor G3 чипе Pixel 8 Pro — около 20 токенов/секунду.

Ограничения реальны: модели больше 4B параметров на мобильных устройствах по-прежнему медленны. Для сложных задач рассуждения on-device LLM уступает GPT-4o в качестве. Гибридный подход — on-device для коротких задач и приватных данных, облако для сложных запросов — часто оптимален. Оценим ваш кейс и предложим баланс производительности и приватности — пишите.

Интеграция OpenAI API и других облачных моделей

Для сценариев, где cloud inference допустим, интеграция OpenAI, Anthropic или Google Gemini — это HTTP клиент + streaming SSE. В Swift удобно через AsyncThrowingStream для стриминговых ответов. В Kotlin — через Flow.

Критически важно: API-ключи никогда не хранятся в бандле приложения. Даже обфусцированный ключ извлекается из IPA за 10 минут через strings или frida. Правильная архитектура: мобильное приложение → собственный backend → OpenAI API. Backend контролирует rate limiting, логирует запросы, защищает ключ.

Что входит в работу (deliverables)

  • Обученная и квантизированная модель под целевое устройство (документация по метрикам)
  • SDK для интеграции (Swift/Kotlin/Flutter) с примерами вызова
  • Тесты производительности на 3–5 реальных устройствах
  • Инструкция по обновлению модели OTA
  • Поддержка при прохождении модерации App Store / Google Play (проверка соответствия Guidelines 4.2, 5.1)
  • 2 недели технической поддержки после релиза

Типичный пайплайн проекта

  1. Анализ задачи — замеряем latency, privacy, size, поддерживаемые устройства.
  2. Прототипирование модели — в Python, оценка accuracy на целевых данных.
  3. Конвертация и квантизация — под CoreML/TFLite с валидацией.
  4. Интеграция в приложение — модель оборачивается в сервисный слой (легко подменять CoreML → TFLite → облако).
  5. Тестирование — на реальных девайсах, замер FPS, RAM, батареи.
  6. Деплой — через TestFlight / Firebase App Distribution, мониторинг метрик.

Сроки: интеграция готовой CoreML/TFLite модели — 1–2 недели, разработка кастомной модели с мобильной оптимизацией — от 6 недель, on-device LLM чат с персонализацией — 4–8 недель.

Почему мы беремся за сложные кейсы?

10+ лет опыта в мобильной разработке, 50+ внедрённых AI/ML решений, гарантия совместимости с актуальными версиями iOS и Android. Все проекты проходят code review и нагрузочное тестирование. В стоимость уже входит подготовка документации для модерации и обучение вашей команды.

Свяжитесь с нами — мы поможем выбрать архитектуру и внедрить ML в ваше приложение под ключ. Закажите аудит существующего решения — бесплатно оценим потенциал экономии серверных затрат (в некоторых проектах экономия достигает $10k в месяц).