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

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

Collaborative Filtering строится на одной идее: если два пользователя похоже оценили товары в прошлом, их будущие предпочтения тоже совпадут. Никакой информации о самом товаре не нужно — только матрица взаимодействий «пользователь × айтем». Именно поэтому CF работает там, где Content-Based пасует: в рекомендациях фильмов, музыки, контента с неструктурированными метаданными.

Техническая суть и основные сложности

Matrix Factorization как основа

Классический CF через dot-product поиска ближайших соседей не масштабируется при >100K пользователей. Рабочий подход — разложение матрицы взаимодействий на два embedding-пространства: пользователи и товары представляются векторами фиксированной размерности (обычно 64–256). Рекомендация — это поиск товаров, чьи эмбеддинги ближе всего к эмбеддингу пользователя.

Библиотеки для тренировки: Implicit (Python, специализирована на implicit feedback), LightFM (гибридный CF+content), RecBole (исследовательский фреймворк с 70+ алгоритмами). Для продакшн-деплоя чаще выбирают Implicit + FAISS для ANN-поиска.

Cold Start — главная проблема CF

Новый пользователь без истории взаимодействий — типичный cold start. Стандартное решение: первые 5–10 взаимодействий используем правило «популярные товары из категории интереса» (onboarding flow с выбором предпочтений). После накопления минимальной истории переключаемся на персонализированную модель.

В коде это выглядит как стратегический паттерн:

// Android: стратегия рекомендаций в зависимости от истории
interface RecommendationStrategy {
    suspend fun getRecommendations(userId: String, count: Int): List<Product>
}

class ColdStartStrategy(private val api: RecommendationApi) : RecommendationStrategy {
    override suspend fun getRecommendations(userId: String, count: Int) =
        api.getPopularByPreferences(userId, count)
}

class CFStrategy(private val api: RecommendationApi) : RecommendationStrategy {
    override suspend fun getRecommendations(userId: String, count: Int) =
        api.getPersonalized(userId, count)
}

class RecommendationRepository(private val api: RecommendationApi) {
    suspend fun getRecommendations(user: User): List<Product> {
        val strategy = if (user.interactionCount < 10) {
            ColdStartStrategy(api)
        } else {
            CFStrategy(api)
        }
        return strategy.getRecommendations(user.id, count = 20)
    }
}

Implicit vs Explicit feedback

В большинстве мобильных приложений пользователи не ставят оценки товарам явно. Implicit feedback — просмотры, клики, добавление в корзину, время просмотра карточки товара — гораздо информативнее, но требует правильного взвешивания: просмотр без клика ≠ интерес, клик без покупки ≠ удовлетворение.

Схема весов, которую используем на практике:

Логирование событий на клиенте

Качество CF напрямую зависит от полноты и точности логирования:

// iOS: логирование взаимодействий с точностью до времени просмотра
class ProductInteractionTracker {
    private var viewStartTime: Date?
    private let analytics: AnalyticsService

    func trackViewStart(productId: String) {
        viewStartTime = Date()
    }

    func trackViewEnd(productId: String) {
        guard let start = viewStartTime else { return }
        let duration = Date().timeIntervalSince(start)

        if duration > 3.0 {
            analytics.log(InteractionEvent(
                productId: productId,
                type: .view,
                weight: min(Int(duration / 3), 3),  // cap at weight 3
                timestamp: start
            ))
        }
        viewStartTime = nil
    }

    func trackAddToCart(productId: String) {
        analytics.log(InteractionEvent(productId: productId, type: .addToCart, weight: 7))
    }
}

Трекинг времени просмотра через viewStartTime позволяет различать случайные просмотры от реального интереса. Без этого сигнала матрица взаимодействий зашумляется случайными данными.

Serving: FAISS для ANN-поиска эмбеддингов

Обученная модель экспортирует эмбеддинги товаров в FAISS-индекс. При запросе рекомендаций для пользователя: получаем его эмбеддинг → ищем K ближайших товаров в FAISS → фильтруем уже купленные → возвращаем список. Latency при 1M товаров — 5–15 мс на сервере.

Процесс работы

Аудит данных: объём матрицы взаимодействий, спарсность, наличие cold start проблемы.

Настройка event-логирования на клиентах iOS/Android.

Обучение модели (Implicit ALS или LightFM) на исторических данных.

Разработка recommendation API + FAISS serving.

A/B тест: CF-рекомендации vs популярные товары → измерение CTR и конверсии.

Ориентиры по срокам

MVP с Implicit ALS + базовым serving — 2–3 недели. Полная система с event-логированием, cold start fallback, A/B тестированием и мониторингом — 6–8 недель.