Реалізація AI-рекомендаційної системи з гібридним підходом у мобільному додатку

TRUETECH займається розробкою, підтримкою та обслуговуванням мобільних додатків iOS, Android, PWA. Маємо великий досвід та експертизу для публікації мобільних додатків до популярних маркетів Google Play, App Store, Amazon, AppGallery та інші.

Розробка та підтримка будь-яких видів мобільних додатків:

Інформаційні та розважальні мобільні програми
Новинки, ігри, довідники, онлайн-каталоги, погодні, фітнес та здоров'я, туристичні, освітні, соціальні мережі та месенджери, квіз, блоги та подкасти, форуми, агрегатори
Мобільні програми електронної комерції
Інтернет-магазини, B2B-додатки, маркетплейси, онлайн-обмінники, кешбек-сервіси, біржі, дропшиппінг-платформи, програми лояльності, доставка їжі та товарів, платіжні системи
Мобільні програми для управління бізнес-процесами
CRM-системи, ERP-системи, управління проектами, інструменти для команди продажів, облік фінансів, управління виробництвом, логістика та доставка, управління персоналом, системи моніторингу даних
Мобільні програми електронних послуг
Дошки оголошень, онлайн-школи, онлайн-кінотеатри, платформи надання електронних послуг, платформи кешбеку, відеохостинги, тематичні портали, платформи онлайн-бронювання та запису, платформи онлайн-торгівлі

Це лише деякі з типів мобільних додатків, з якими ми працюємо, і кожен із них може мати свої специфічні особливості та функціональність, а також бути адаптованим під конкретні потреби та цілі клієнта.

Послуги, які ми пропонуємо
Показано 1 з 1Усі 1735 послуг
Реалізація AI-рекомендаційної системи з гібридним підходом у мобільному додатку
Складний
~2-4 тижні
Часті запитання

Наші компетенції:

Етапи розробки

Останні роботи

  • image_mobile-applications_feedme_467_0.webp
    Розробка мобільного додатка для компанії FEEDME
    792
  • image_mobile-applications_xoomer_471_0.webp
    Розробка мобільного додатку для компанії XOOMER
    671
  • image_mobile-applications_rhl_428_0.webp
    Розробка мобільного додатку для компанії RHL
    1097
  • image_mobile-applications_zippy_411_0.webp
    Розробка мобільного додатку для компанії ZIPPY
    969
  • image_mobile-applications_affhome_429_0.webp
    Розробка мобільного додатку для компанії Affhome
    914
  • image_mobile-applications_flavors_409_0.webp
    Розробка мобільного додатку для компанії FLAVORS
    495

AI-рекомендаційна система з гібридним підходом в мобільних додатках

Чистий Collaborative Filtering ломається на холодному старті. Чистий Content-Based ігнорує соціальні сигнали та застає в filter bubble. Гібридні системи комбінують обидва — саме вони стоять за лентами великих платформ: Netflix, Spotify, Amazon.

Головний інженерний питання не "потрібен гібрид", а "як саме комбінувати".

Три стратегії комбінування

Weighted Hybrid — взвешена сума скорів

Найпростіший варіант: остаточний скор = α × CF_score + (1−α) × CB_score. Параметр α можна робити динамічним — для нового користувача α = 0,2 (CF слабкий, довіряємо CB), для досвідченого α = 0,7.

class WeightedHybridRecommender:
    def __init__(self, cf: CFRecommender, cb: CBRecommender):
        self.cf = cf
        self.cb = cb

    def recommend(self, user: User, candidates: list[str], n: int = 20) -> list[str]:
        alpha = self._compute_alpha(user.interaction_count)

        cf_scores = self.cf.score(user.id, candidates)   # dict[item_id -> float]
        cb_scores = self.cb.score(user.profile, candidates)

        hybrid_scores = {
            item_id: alpha * cf_scores.get(item_id, 0) + (1 - alpha) * cb_scores.get(item_id, 0)
            for item_id in candidates
        }
        return sorted(hybrid_scores, key=hybrid_scores.get, reverse=True)[:n]

    def _compute_alpha(self, interaction_count: int) -> float:
        # лінійний ріст: 0.2 при 0 взаємодіях, 0.8 при 100+
        return min(0.2 + (interaction_count / 100) * 0.6, 0.8)

Switching Hybrid — вибір стратегії за контекстом

Замість змішування скорів — переключення між рекомендерами цілком. Логіка переключення може бути складною: CF для залогінених користувачів з історією, CB для гостей, popularity-based для нових користувачів без onboarding.

// Android: стратегія за контекстом користувача
sealed class RecommendationContext {
    object Guest : RecommendationContext()
    data class NewUser(val preferences: List<String>) : RecommendationContext()
    data class ActiveUser(val userId: String, val interactionCount: Int) : RecommendationContext()
}

class HybridRecommenderRepository(
    private val cfApi: CFRecommendationApi,
    private val cbApi: CBRecommendationApi,
    private val popularApi: PopularityApi
) {
    suspend fun getRecommendations(context: RecommendationContext): List<Product> {
        return when (context) {
            is RecommendationContext.Guest ->
                popularApi.getTopProducts(count = 20)
            is RecommendationContext.NewUser ->
                cbApi.getByPreferences(context.preferences, count = 20)
            is RecommendationContext.ActiveUser -> {
                if (context.interactionCount < 15) {
                    // змішуємо: 30% CF + 70% CB
                    mergeRecommendations(
                        cfApi.getPersonalized(context.userId, count = 6),
                        cbApi.getSimilarToHistory(context.userId, count = 14)
                    )
                } else {
                    cfApi.getPersonalized(context.userId, count = 20)
                }
            }
        }
    }
}

Feature-level Hybrid через нейросеть (Two-Tower модель)

Продвинутий варіант: CF-embeddings користувача та товару конкатенуються з CB-ознаками та подаються в shallow нейросеть (2–3 dense шари). Модель навчається end-to-end передбачувати ймовірність клику. Це Two-Tower архітектура, яку використовують Google та Airbnb.

# Two-Tower модель (спрощена)
class TwoTowerModel(nn.Module):
    def __init__(self, user_emb_dim=64, item_emb_dim=64, cb_features_dim=50):
        super().__init__()
        self.user_tower = nn.Sequential(
            nn.Linear(user_emb_dim, 128), nn.ReLU(),
            nn.Linear(128, 64)
        )
        self.item_tower = nn.Sequential(
            nn.Linear(item_emb_dim + cb_features_dim, 128), nn.ReLU(),
            nn.Linear(128, 64)
        )

    def forward(self, user_emb, item_emb, cb_features):
        user_out = self.user_tower(user_emb)
        item_input = torch.cat([item_emb, cb_features], dim=-1)
        item_out = self.item_tower(item_input)
        return torch.sigmoid((user_out * item_out).sum(dim=-1))

На мобільному клієнті Two-Tower serving працює через передвичислення item-embeddings + FAISS ANN.

Мобільна інтеграція: кешування та оновлення рекомендацій

// iOS: кеш рекомендацій з TTL та фоновим оновленням
class RecommendationCache {
    private let cache = NSCache<NSString, CachedRecommendations>()
    private let ttl: TimeInterval = 300  // 5 хвилин

    func get(userId: String) -> [Product]? {
        guard let cached = cache.object(forKey: userId as NSString),
              Date().timeIntervalSince(cached.timestamp) < ttl
        else { return nil }
        return cached.products
    }

    func set(userId: String, products: [Product]) {
        cache.setObject(
            CachedRecommendations(products: products, timestamp: Date()),
            forKey: userId as NSString
        )
    }
}

Рекомендації оновлюються у фоні через BGAppRefreshTask (iOS) / WorkManager (Android) — користувач бачить свіжий контент при відкритті додатка без очікування.

Процес роботи

Аудит даних: доступність CF-сигналів, якість CB-метаданих, обсяг користувальницької бази.

Вибір стратегії комбінування в залежності від складності завдання та ресурсів.

Розробка serving-шару з кешуванням на клієнті.

A/B тест: гібрид vs найкращий одиночний рекомендер → CTR, час у додатку, конверсія.

Ориентири за часовими рамками

Weighted Hybrid з готовими CF та CB компонентами — 1–2 тижні. Two-Tower модель з нуля — 4–6 тижнів включаючи збір навчальних даних, навчання та деплой.