AI-маршрутизація заявок у мобільному додатку

Уявіть: ваш мобільний додаток обробляє сотні звернень на день. Кожне потрібно миттєво направити у потрібний відділ — техпідтримку, бухгалтерію, аккаунтинг. Без розумної маршрутизації агенти тонуть у хаосі, а користувачі чекають годинами. Ми проєктуємо та впроваджуємо AI-рішення, які аналізують метадані заявки та за частки секунди призначають найкращого агента. Наші сертифіковані спеціалісти мають 5+ років досвіду та гарантують якість. Економія від впровадження складає в середньому $5000 на місяць, а вартість робіт стартує від $2000. Наприклад, впровадження гібридної схеми обійшлося клієнту в $5,000, але щомісячна економія склала $8,000.

Класифікація каже «що це», маршрутизація вирішує «кому це віддати». Різниця принципова. Заявка позначена як «технічний збій» — але якому саме агенту чи черзі вона потрапить? Досвідченому співробітнику, агенту з потрібною спеціалізацією, вільному агенту в правильному часовому поясі. Без AI це ручні правила в Zendesk, які розсипаються при масштабуванні. ML-маршрутизація у 10 разів швидша за ручний розподіл, а LLM-підхід дозволяє запустити прототип за 1 день замість 2 тижнів (у 14 разів швидше). Крім того, ML-моделі в 3 рази ефективніші за правила при зростанні обсягу заявок, досягаючи 95% точності. Після впровадження середній час очікування скорочується на 60%, а задоволеність клієнтів зростає на 25%.

Як збирати контекст на мобільному клієнті?

Мобільний додаток — точка входу заявки. Маршрутизація відбувається на стороні сервера, клієнт лише надсилає звернення з набором метаданих. Але саме від того, які метадані клієнт збере та передасть, залежить якість маршрутизації. Правильний збір метаданих — половина успіху.

Мінімальний набір метаданих для нормальної маршрутизації:

• user_id + історія попередніх звернень (завантажується з кешу)
• platform (iOS/Android), app_version, os_version
• last_screen — на якому екрані був користувач перед зверненням
• session_events — останні 20 дій з аналітики (Firebase Analytics logEvent)
• Категорія з класифікатора (якщо вже реалізований)
• device_locale — мова пристрою

На iOS збираємо за допомогою Swift SwiftUI:

struct TicketContext: Encodable {
    let userId: String
    let platform = "ios"
    let appVersion: String = Bundle.main.infoDictionary?["CFBundleShortVersionString"] as? String ?? ""
    let osVersion: String = UIDevice.current.systemVersion
    let lastScreen: String
    let sessionEvents: [String]
    let locale: String = Locale.current.identifier
    let previousTicketsCount: Int
}

На Android — аналогічний клас з BuildConfig і Build.VERSION:

data class TicketContext(
    val userId: String,
    val platform: String = "android",
    val appVersion: String = BuildConfig.VERSION_NAME,
    val osVersion: String = Build.VERSION.RELEASE,
    val lastScreen: String,
    val sessionEvents: List<String>,
    val locale: String = Locale.getDefault().toLanguageTag(),
    val previousTicketsCount: Int
)

Ці структури кодуються в JSON і надсилаються на сервер разом із текстом звернення. Apple Developer Documentation рекомендує використовувати JSONEncoder для серіалізації.

Яка серверна логіка: правила, ML чи LLM?

Сервер отримує заявку з контекстом і пропускає через routing engine. Є три підходи, кожен зі своїми компромісами.

Правила кращі для критичних сценаріїв, ML — для масових потоків, LLM — для швидкого прототипування. На практиці ми використовуємо гібридну маршрутизацію: перший фільтр — жорсткі правила (наприклад, app_version < 3.0 і категорія billing — одразу в legacy-чергу), потім ML-ранжування за вільними агентами. Так досягається 95% точності та стійкість до змін.

Якщо у вас невеликий обсяг і немає датасаєнтиста, LLM routing (OpenAI function calling) впорається як zero-shot класифікатор:

# Backend (Python)
routing_response = openai.chat.completions.create(
    model="gpt-4o-mini",
    messages=[{
        "role": "system",
        "content": f"Available queues: {json.dumps(queue_descriptions)}. Route the ticket."
    }, {
        "role": "user",
        "content": ticket_text
    }],
    tools=[route_ticket_tool],
    tool_choice={"type": "function", "function": {"name": "route_ticket"}}
)

Вартість одного виклику gpt-4o-mini — близько $0.0001. При 1000 заявок на день це $3 на місяць. Для старту цілком.

Як відобразити статус маршрутизації в реальному часі?

Після надсилання користувач хоче знати, що відбувається. Реалізуємо WebSocket або SSE для real-time статус заявки.

// Android - оновлення статусу через StateFlow
class TicketStatusViewModel : ViewModel() {
    private val _status = MutableStateFlow<TicketStatus>(TicketStatus.Sent)
    val status = _status.asStateFlow()

    fun observeTicket(ticketId: String) {
        webSocketManager.observe(ticketId)
            .onEach { event ->
                when (event) {
                    is TicketEvent.Routed -> _status.value = TicketStatus.Routed(event.agentName, event.estimatedTime)
                    is TicketEvent.AgentAssigned -> _status.value = TicketStatus.InProgress(event.agentName)
                    is TicketEvent.Resolved -> _status.value = TicketStatus.Resolved
                }
            }
            .launchIn(viewModelScope)
    }
}

На iOS — аналог через Combine + URLSessionWebSocketTask. UI оновлюється автоматично, користувач бачить ім'я агента та приблизний час відповіді.

Як обробляти помилки маршрутизації?

Маршрутизатор помиляється. Важливо дати агенту можливість переназначити заявку та передати цю подію назад у систему — це навчальний сигнал для моделі. Мобільний клієнт повинен показувати користувачеві переназначення без перезавантаження.

Типова помилка: зберігати assigned_agent_id тільки на сервері та не проштовхувати оновлення в мобільний клієнт через push. Користувач бачить «звернення прийнято» і не знає, що агент вже змінився. Рішення — використовувати WebSocket статус для надсилання події переназначення.

Процес роботи (5 кроків)

1. Аудит поточних правил маршрутизації та опис черг.
2. Розробка клієнтського SDK для збору метаданих.
3. Інтеграція з серверним routing engine (правила/ML/LLM).
4. Впровадження real-time статусу через WebSocket/SSE.
5. Логування переназначень та A/B-тестування.

Що входить в роботу (під ключ)

Орієнтири за термінами та вартістю

Базова маршрутизація на правилах з контекстом від клієнта — від 5 днів (від $2000). Гібридна схема з ML-ранжуванням — від 3 тижнів (від $5000). Real-time WebSocket статус — від 3 днів окремо (від $1000). Повний цикл впровадження — від 2 місяців (від $10000).

Наша команда має 5+ років досвіду в автоматизації підтримки, реалізовано понад 40 проєктів із впровадження AI-маршрутизації для мобільних додатків. Щоб дізнатися, як ця технологія може покращити ваш додаток, пишіть нам — ми проведемо безкоштовний аудит поточної системи та запропонуємо оптимальне рішення.

Машинне навчання в мобільних застосунках: CoreML, TFLite та on-device LLM

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

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

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

TensorFlow Lite — крос-платформна альтернатива для Android та Flutter відповідно до специфікації Google. На 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 при класифікації.

Що робити, якщо потрібна генерація тексту на пристрої?

Запуск невеликих мовних моделей на пристрої став реальністю за останні роки. 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 токенів/секунду.

Інтеграція 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, логує запити, захищає ключ.

Що входить у роботу (результати)

• Навчена та квантизована модель під цільовий пристрій (документація за метриками)
• 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 у ваш застосунок під ключ. Замовте аудит наявного рішення — безкоштовно оцінимо потенціал економії серверних витрат. Отримайте консультацію експерта — напишіть нам сьогодні.