Реалізація AI-рекомендаційної системи у мобільному додатку
Рекомендації в мобільному додатку — це не один алгоритм, а конвеєр: збір поведінкових подій, передача в ML-модель, отримання ранжованого списку та вбудовування в UI без втрати продуктивності. Складність залежить від розташування моделі: на пристрої або на сервері, та глибини персоналізації.
Архітектура: On-Device vs Server-Side
Серверна рекомендаційна система (Collaborative Filtering, Matrix Factorization, двобашенні моделі) дають кращу якість — модель бачить поведінку всіх користувачів. Мінус: затримка мережі та неможливість роботи офлайн. Клієнтська (CoreML/TFLite) — швидша, приватніша, працює офлайн. Мінус: обмежений контекст (тільки дані цього пристрою) та складність оновлення моделі.
Типова гібридна схема: сервер раз на день генерує персональний список із 100–200 кандидатів, мобільний клієнт зберігає локально та переранжує в реальному часі за свіжими сесійними подіями.
Збір подій — основа якості
Рекомендаційна система гарна настільки, наскільки гарні дані. На мобільному клієнті логуйте мінімум:
-
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 секунд — швидше за все прокрутка повз.
CoreML / TFLite Re-ranking на пристрої
Якщо сервер повертає топ-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 з верифікацією хешу.
Холодний старт для нових користувачів
Перші 5–10 сесій немає достатньо даних для персоналізації. Стандартний підхід — гібрид:
- Onboarding-квіз (2–3 питання про переваги) дає початковий профіль
- Популярність-базовані як fallback
- Implicit feedback від перших взаємодій швидко змінює профіль
Не показуйте «рекомендації для вас» до набору мінімальної історії — чесніше для користувача та не ламає метрики якості.
Метрики якості у виробництві
Click-Through Rate (CTR) та конверсія — базові. Для мобільного UX також важливо отслідити «сліпоту до рекомендацій»: якщо блок ігнорують, гірше, ніж низький CTR. A/B-тестування через Firebase Remote Config або Amplitude Experiment — обов'язково при змінах алгоритму. Мінімальна вибірка для статистичної значущості — 1000+ унікальних користувачів на варіант.
Процес реалізації
Аудит поточних даних та подій. Вибір архітектури (on-device / server / hybrid). Розробка event-трекера з батчингом та retry. Серверна частина або інтеграція готового ML-сервісу (Amazon Personalize, Google Recommendations AI). Інтеграція моделі у мобільний клієнт, переранжування. UI-компоненти рекомендаційних блоків. A/B-тестування та аналітика.
Орієнтири за часом
Інтеграція готового серверного рекомендаційного сервісу з event-трекером — 2–3 тижні. Гібридна система з on-device переранжуванням, користувацькими подіями та A/B-тестуванням — 6–10 тижнів.