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

Реализация 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 для реранкинга на устройстве

Если сервер отдаёт топ-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 сессий нет достаточно данных для персонализации. Стандартный подход — гибрид:

1. Онбординг-квиз (2–3 вопроса о предпочтениях) даёт начальный профиль
2. Popularity-based рекомендации как fallback
3. 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 недель.