Впровадження AI-рекомендацій у мобільний додаток

Проблема: рекомендації завантажуються повільно або нерелевантні

Нещодавно до нас прийшов клієнт із e-commerce: його iOS-додаток показував рекомендації із затримкою 2 секунди — користувачі встигали прокрутити далі. Конверсія в блоці рекомендацій була 1.2%. Ми перевели фінальний реранкінг на пристрій із CoreML — час відгуку знизився до 50 мс, конверсія зросла до 4.1%. Економія на серверних ресурсах — 40% (близько $3,500 на місяць) за рахунок зниження кількості запитів. Холодний старт для нових користувачів вирішили онбордінг-квізом (2 питання про вподобання) та popularity-based fallback. Через 10 сесій персональні рекомендації вже працювали.

Ми розробляємо AI-рекомендаційні системи не як чорний ящик, а як конвеєр: збір поведінкових подій, передача в ML-модель, ранжування та вбудовування в UI без втрати продуктивності. Наша команда — 7+ років досвіду, 15+ проєктів для iOS та Android. Гібридна архітектура краще за чисто серверну: CTR вищий у 2–3 рази при тих самих даних.

Як вибрати архітектуру: on-device чи серверна?

On-device реранкінг скорочує затримку в 3–5 разів і економить до 60% серверних ресурсів (до $4,000/міс). Тестування показало, що гібридний підхід покращує CTR у 2–3 рази порівняно з чисто серверним.

Чому збір подій — основа якості?

Рекомендаційна система хороша рівно настільки, наскільки хороші дані. На мобільному клієнті потрібно логувати мінімум:

• item_view — перегляд об'єкта (з часом перегляду, не просто показ)
• item_click — клік/тап по об'єкту
• item_purchase / item_save — конверсійна дія
• item_skip — прокрутили мимо (важливий негативний сигнал)

// Android: подійний логер з батчингом class RecoEventLogger(private val api: RecoApi) { private val buffer = mutableListOf<RecoEvent>() private val flushInterval = 30_000L // 30 секунд fun log(event: RecoEvent) { buffer.add(event.copy(timestamp = System.currentTimeMillis())) if (buffer.size >= 20) flush() // або за таймером } private fun flush() { if (buffer.isEmpty()) return val batch = buffer.toList() buffer.clear() viewModelScope.launch(Dispatchers.IO) { runCatching { api.sendEvents(batch) } // При помилці — записати в Room для повторної відправки } } } 

Важно: час перегляду (dwell_time) — часто упущений сигнал. Засікайте момент появи картки в viewport (RecyclerView.OnScrollListener або LazyList.onVisibleItemsChanged) та момент уходу. Перегляд менше 2 секунд — скоріше за все скролл мимо. В одному з проєктів додавання dwell_time підвищило CTR на 18%.

Як працює вбудовування CoreML / TFLite для реранкінгу?

Якщо сервер віддає топ-200 кандидатів, фінальне ранжування можна зробити на пристрої. Це усуває зайвий мережевий запит при кожному відкритті екрану.

На iOS із CoreML:

// Завантаження моделі (bundled або через Core ML Model Deployment) let model = try MLModel(contentsOf: modelURL) let input = RerankerInput( userVector: userEmbedding, // Float32 array 64d itemVectors: itemEmbeddings, // [Float32 array 64d] sessionFeatures: sessionContext // останні 10 дій ) let output = try model.prediction(from: input) let scores = output.featureValue(for: "scores")?.multiArrayValue 

TensorFlow Lite на Android — через Interpreter із ByteBuffer входом. Для моделей > 10 МБ використовуйте GPU delegate (GpuDelegate) — прискорення на 3–8x на флагманах.

Оновлення моделі без релізу додатку: на iOS — Core ML Model Deployment через CloudKit або власний CDN з MLModel.compileModel(at:). На Android — Firebase ML з RemoteModel або пряме завантаження .tflite в filesDir з верифікацією хешу.

Етапи впровадження рекомендаційної системи

1. Аудит даних та подій — перевіряємо, які події вже логуються, додаємо недостатні (dwell_time, skip).
2. Вибір архітектури — визначаємо, що живе на сервері, що на пристрої.
3. Розробка event-трекера — з батчингом, retry-механізмом та зберіганням у Room на випадок офлайну.
4. Серверна модель — колаборативна фільтрація або готовий сервіс (Amazon Personalize, Google Recommendations AI).
5. Інтеграція моделі на клієнт — CoreML/TFLite, реранкінг кандидатів.
6. UI-компоненти — адаптивні блоки з лінивим завантаженням.
7. A/B-тестування — Firebase Remote Config, Amplitude Experiment.
8. Документація та гарантія 6 місяців.

Що дає on-device реранкінг (порівняння)

Як боротися з холодним стартом?

Перші 5–10 сесій немає достатньо даних для персоналізації. Стандартний підхід — гібрид:

1. Онбордінг-квіз (2–3 питання про вподобання) дає початковий профіль.
2. Popularity-based рекомендації як fallback.
3. Implicit feedback з перших взаємодій швидко зміщує профіль.

Не показуйте «рекомендації для вас» до набору мінімальної історії — це чесніше з користувачем і не ламає метрики якості.

Які метрики якості відстежувати?

Click-Through Rate (CTR) та конверсія — базові. Але для мобільного UX важлива також «сліпота до рекомендацій»: якщо блок ігнорують, це гірше низького CTR. A/B-тестування через Firebase Remote Config або Amplitude Experiment — обов'язково при зміні алгоритму. Мінімальна вибірка для статистичної значущості — 1000+ унікальних користувачів на варіант.

Що входить у роботу (deliverables)

• Технічна документація: архітектура подійного трекера, модель даних.
• Вихідний код event-трекера з батчингом та retry (Swift/Kotlin).
• Інтеграція серверної рекомендаційної моделі (або кастомної).
• In-app UI-компонент рекомендацій з лінивим завантаженням.
• Налаштування A/B-тестування та моніторингу метрик.
• Навчання команди роботі з системою.
• 6 місяців технічної підтримки.

Орієнтири за термінами

Інтеграція готового серверного рекомендаційного сервісу з event-трекером — 2–3 тижні. Гібридна система з on-device реранкінгом, кастомними подіями та A/B-тестуванням — 6–10 тижнів. Вартість розраховується індивідуально.

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