Колаборативна фільтрація для рекомендацій у мобільному додатку
Вступ
Уявіть: у вас 500 000 користувачів, каталог 100 000 товарів, а конверсія в рекомендаціях — лише 2%. Причина? Стандартні популярні товари не персоналізовані. Ми вирішуємо це завдання за допомогою колаборативної фільтрації (Collaborative Filtering, CF), яка аналізує матрицю взаємодій «користувач × товар» і видає персоналізовані результати. Жодної інформації про сам товар не потрібно — лише поведінкові сигнали. Саме тому CF працює там, де Content-Based пасує: у рекомендаціях одягу, книг, контенту з неструктурованими метаданими. Згідно з дослідженням Amazon, впровадження CF збільшує продажі на 20–30% у перші місяці. Наш досвід впровадження показує, що правильне налаштування ваг і A/B тестування дозволяють досягти стабільного приросту CTR на 30–50%.
Колаборативна фільтрація: технічна суть та основні складнощі
Matrix Factorization як основа
Класичний CF через dot-product пошуку найближчих сусідів не масштабується при >100K користувачів. Робочий підхід — розкладання матриці взаємодій на два embedding-простори: користувачі та товари представляються векторами фіксованої розмірності (зазвичай 64–256). Рекомендація — це пошук товарів, чиї ембеддинги найближчі до ембеддингу користувача.
Бібліотеки для тренування: Implicit (Python, спеціалізована на implicit feedback), LightFM (гібридний CF+content), RecBole (дослідницький фреймворк з 70+ алгоритмами). Для продакшн-деплою частіше обирають Implicit + FAISS для ANN-пошуку. За швидкістю Implicit у 3 рази швидший за LightFM на розріджених матрицях.
| Бібліотека | Тип даних | Швидкість навчання | Гнучкість | Продакшен-готовність |
|---|---|---|---|---|
| Implicit | Implicit/Explicit | ★★★★★ | ★★★ | ★★★★★ |
| LightFM | Гібридний | ★★★★ | ★★★★★ | ★★★★ |
| RecBole | Дослідницький | ★★★ | ★★★★ | ★★★ |
Як колаборативна фільтрація вирішує проблему холодного старту?
Новий користувач без історії взаємодій — типовий 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 Feedback вигідніший за Explicit?
У більшості мобільних додатків користувачі не ставлять оцінок. Implicit feedback — перегляди, кліки, додавання в кошик, час перегляду картки товару — набагато інформативніший, але потребує правильного зважування: перегляд без кліка ≠ інтерес, клік без покупки ≠ задоволення.
Схема ваг, яку використовуємо на практиці:
| Дія | Вага |
|---|---|
| Перегляд картки > 3 сек | 1 |
| Клік «детальніше» | 3 |
| Додавання в обране | 5 |
| Додавання в кошик | 7 |
| Покупка | 10 |
| Повернення | -5 |
CF з правильними вагами дає приріст CTR на 30–50% порівняно з Content-Based за достатнього обсягу даних. В одному з проєктів для рітейлера одягу ми впровадили Implicit ALS з вагами, наведеними вище. Через 2 тижні A/B тесту CTR виріс на 40%, а конверсія в покупку — на 15%. Гарантуємо, що при ваших даних результат буде не нижче.
Логіювання подій на клієнті
Якість 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),
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 мс на сервері. FAISS пошук у 10 разів швидший за лінійний пошук для 1M товарів.
Архітектура serving на FAISS
Індекс будується offline після навчання моделі. Для інференсу використовується REST API (Ktor/Kotlin або Vapor/Swift). При кожному запиті користувача його ембеддинг обчислюється на льоту або кешується. Пошук top-K виконується через `IndexIVFFlat` з nprobe=10 для швидкості. Результати пост-обробляються: видаляються вже куплені товари, застосовується бізнес-логіка (наприклад, різноманітність категорій).Що входить в роботу
- Аудит даних: обсяг матриці взаємодій, спарсність, наявність cold start проблеми.
- Налаштування event-логіювання на клієнтах iOS/Android з урахуванням App Store Review Guidelines та Google Play Console.
- Навчання моделі (Implicit ALS або LightFM) на історичних даних.
- Розробка recommendation API + FAISS serving з використанням Ktor (Kotlin) або Vapor (Swift).
- A/B тест: CF-рекомендації vs популярні товари → вимірювання CTR та конверсії.
- Документація та навчання команди.
- Підтримка після запуску, моніторинг дрейфу даних.
Орієнтири за термінами
MVP з Implicit ALS + базовим serving — 2–3 тижні. Повна система з event-логіюванням, cold start fallback, A/B тестуванням та моніторингом — 6–8 тижнів. Вартість MVP: від $3 000, повна система: від $10 000. У нас понад 10 років досвіду в мобільній розробці, і ми гарантуємо прозорий процес з регулярними демо.
Підніміть конверсію рекомендацій — отримайте консультацію нашого інженера з налаштування CF під ваші дані. Замовте аудит матриці взаємодій — ми оцінимо потенціал. Зв'яжіться з нами для старту проєкту.