AI-персоналізація стрічки контенту в мобільному додатку

Уявіть: ви запускаєте новинний додаток із мільйоном щоденних публікацій. Без персоналізації користувач бачить однотипні пости, швидко втрачає інтерес і йде. Хронологічна стрічка втрачає до 60% залученості — це експериментально підтверджена цифра. Наш ранжувальник вирішує задачу сортування кандидатів на основі сотень ознак, не генеруючи контент, а розставляючи пріоритети. Типовий приклад: стрічка новин перестає бути релевантною після двох тижнів використання — користувачі скаржаться на одноманітність. Пайплайн враховує динаміку інтересів і запобігає filter bubble. Гібридний підхід: колаборативна фільтрація доповнюється семантичним аналізом контенту. Це дозволяє враховувати як явні, так і неявні вподобання. Результат — кожен користувач бачить стрічку, яка адаптується під його мінливі інтереси в реальному часі. Такий підхід підвищує утримання на 30% і збільшує час сесії в півтора рази. Переходимо до деталей реалізації.

Як ми будуємо пайплайн ранжування?

Персоналізація стрічки — двоступеневий пайплайн: retrieval і ranking. На першому етапі з мільйонів публікацій відбираємо кілька сотень кандидатів через approximate nearest neighbours (ANN) на основі підписок та інтересів. На другому — ранжуємо цих кандидатів важчою моделлю з сотнями ознак. Розділення етапів критичне: ranking-модель занадто повільна для всього каталогу, retrieval — недостатньо точна для фінального порядку.

Ознаки для ранжування

Хороша ранжувальна модель використовує три групи ознак:

• Контекст користувача: час доби, день тижня, тип сесії (холодна або продовження), активність за 24 години.
• Характеристики контенту: вік публікації, engagement rate (лайки/перегляди), швидкість набору переглядів за першу годину, авторський follower count та історичний CTR.
• Перетин користувача і контенту: семантична схожість з історією взаємодій, тематичне перекриття з топ-інтересами, знайомство з автором.

# Feature vector для одного кандидата @dataclass class RankingFeatures: # Content features post_age_hours: float engagement_rate_24h: float viral_velocity: float # views_per_hour in first 2 hours # User-content interaction topic_affinity: float # cosine sim між профілем юзера та ембеддингом поста author_ctr_for_user: float # історичний CTR цього автора у цього юзера # Context hour_of_day: int is_weekend: bool session_depth: int # скільки постів вже переглянуто в сесії 

Чому LightGBM, а не нейромережа?

Нейромережеві ранжувальники дають вищу якість, але LightGBM з LambdaRank objective — швидший в inference (2–5 мс на 200 кандидатів) і простіший в ітерації. Для середнього масштабу це оптимальний вибір. При аудиторії понад 10 млн оптимальним може стати дворівнева модель з нейромережевим ретривером і LightGBM для ранжування. Вартість розробки нейромережевого рішення вища, але часто економічно виправдана при високому навантаженні.

import lightgbm as lgb model = lgb.LGBMRanker( objective='lambdarank', metric='ndcg', ndcg_eval_at=[5, 10, 20], n_estimators=500, learning_rate=0.05, num_leaves=63 ) model.fit( X_train, y_train, # y — relevance labels: 0=ignored, 1=viewed, 2=liked, 3=shared group=train_groups, # розмір груп запитів eval_set=[(X_val, y_val)], eval_group=[val_groups] ) 

Як забезпечити безшовний скрол на мобільному?

Реалізуємо prefetch: коли користувач доскролив до 70% поточного батча, фоново підвантажуємо наступні 20 постів. На Android використовуємо Paging 3 з prefetchDistance = 5. Приклад:

// Android: Paging 3 з prefetch для персоналізованої стрічки class FeedPagingSource( private val feedApi: FeedApi, private val userId: String ) : PagingSource<String, FeedPost>() { override suspend fun load(params: LoadParams<String>): LoadResult<String, FeedPost> { return try { val response = feedApi.getPersonalizedFeed( userId = userId, cursor = params.key, pageSize = params.loadSize ) LoadResult.Page( data = response.posts, prevKey = null, nextKey = response.nextCursor ) } catch (e: Exception) { LoadResult.Error(e) } } } // ViewModel val feed = Pager( config = PagingConfig(pageSize = 20, prefetchDistance = 5), pagingSourceFactory = { FeedPagingSource(feedApi, userId) } ).flow.cachedIn(viewModelScope) 

Склад робіт і терміни

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

Типові підводні камені

Перший — відсутність diversity. Без MPR (Maximum Marginal Relevance) стрічка стає однобокою. Рішення: не більше 2 постів одного автора в перших 10, плюс евристики за темами. Другий — неправильні лейбли. Використовувати лише перегляди — зміщення в клікбейт. Включайте лайки та шери. Третій — ігнорування cold start. Новий користувач без історії — показуємо популярне і швидко збираємо сигнали через bandit-алгоритми. Економія ресурсів досягається за рахунок використання готових компонентів і відкритих бібліотек.

Забезпечення різноманіття контенту

Ми використовуємо MPR-постобробку: після ранжування перераховуємо scores з урахуванням схожості кандидатів. Додатково застосовуємо глобальні евристики — наприклад, кожен наступний пост має відрізнятися за темою від попереднього, а кількість постів від одного автора обмежена.

Орієнтири за термінами

LightGBM ранжувальник з базовими ознаками + API — 2–3 тижні. Повна система з двоступеневим retrieval+ranking, diversity-постобробкою та A/B тестуванням — 6–10 тижнів.

Отримайте консультацію — ми зробимо швидку попередню оцінку за вашими даними. Зв'яжіться з нами, щоб обговорити деталі та оптимізувати бюджет.