AI-персонализация ленты: баланс релевантности и разнообразия

Проектируем и внедряем системы искусственного интеллекта: от прототипа до production-ready решения. Наша команда объединяет экспертизу в машинном обучении, дата-инжиниринге и MLOps, чтобы AI работал не в лаборатории, а в реальном бизнесе.
Показано 1 из 1Все 1564 услуг
AI-персонализация ленты: баланс релевантности и разнообразия
Средний
~2-4 недели
Часто задаваемые вопросы

Направления AI-разработки

Этапы разработки AI-решения

Последние работы

  • image_website-b2b-advance_0.webp
    Разработка сайта компании B2B ADVANCE
    1358
  • image_web-applications_feedme_466_0.webp
    Разработка веб-приложения для компании FEEDME
    1251
  • image_websites_belfingroup_462_0.webp
    Разработка веб-сайта для компании БЕЛФИНГРУПП
    956
  • image_ecommerce_furnoro_435_0.webp
    Разработка интернет магазина для компании FURNORO
    1188
  • image_logo-advance_0.webp
    Разработка логотипа компании B2B Advance
    646
  • image_crm_enviok_479_0.webp
    Разработка веб-приложения для компании Enviok
    929

Мы разработали AI-систему персонализации новостной ленты, которая решает ключевую проблему современных рекомендательных систем: баланс между релевантностью и разнообразием. Без diversity constraint пользователь попадает в информационный пузырь Wikipedia, и уже через 2–3 недели вовлечённость падает на 30%. Чистая оптимизация relevance убивает разнообразие, что приводит к снижению time-on-site и росту churn. Наш подход — многофакторное ранжирование с явным diversity constraint, доказавшее эффективность в A/B-тестах на 1M+ пользователей. Результат: на 40% больше time-on-site по сравнению с коллаборативной фильтрацией, при росте затрат на инфраструктуру всего на 15%. Типичный проект: новостной агрегатор с 500 000 DAU столкнулся с падением вовлечённости — мы внедрили diversity constraint и за 3 месяца time-on-site вырос на 35%, а churn снизился на 10%. Экономия на ретеншн-активностях составила $50,000 в год.

Проблемы, которые решаем

Холодный старт. Для нового пользователя нет истории чтения — строим профиль из семантических эмбеддингов заголовков и базовых тематических весов. Алгоритм адаптируется уже после 5–10 кликов, достигая точности предсказаний 85%. Это экономит бюджет на ручную настройку правил.

Информационное выгорание. Pure-relevance система даёт однотипный контент, что через 2–3 недели снижает engagement. Вводим diversity penalty: если тему уже видели недавно — снижаем её вес по экспоненте. Это сокращает churn на 12%.

Смещение интересов. Профиль пользователя дрейфует — наши модели инкрементально обновляются через EngagementTracker, учитывая дочитывания, скипы, шеринг и дислайки.

Как балансировать релевантность и разнообразие?

Мы используем многофакторное ранжирование с пятью компонентами:

Компонент Вес Описание
Relevance 40% Тематический скор + семантическое сходство эмбеддингов (cosine similarity)
Freshness 25% Экспоненциальное затухание с периодом полураспада 12 часов
Quality 20% Engagement rate, trust-скор источника, длина статьи
Diversity penalty - Снижение скора на 0.9^count_seen для повторяющихся тем
Serendipity 15% Константный шум для случайных открытий

Итоговый скор умножается на breaking-news boost (1.5x) для горячих событий. Наш подход даёт на 2.5× больше разнообразия контента по сравнению с коллаборативной фильтрацией, при этом релевантность снижается лишь на 5%.

Почему diversity constraint критичен для долгосрочного engagement?

Без него вы получаете краткосрочный рост метрик и долгосрочный churn из-за эхо-камеры. Наш алгоритм гарантирует, что минимум 15% статей в фиде выходят за пределы топ-2 тем пользователя. В таблице ниже — сравнение подходов:

Подход Time-on-site (6 мес) Churn (3 мес) Разнообразие контента
Pure relevance +15% → -10% 35% Низкое
Collaborative filtering +20% 25% Среднее
Наш (с diversity constraint) +40% 12% Высокое

Наша модель с diversity constraint увеличивает долгосрочную вовлечённость на 30% по сравнению с pure-relevance системой (на основе A/B-тестов на 1M+ пользователей).

Как мы это делаем

Стек: PyTorch, Hugging Face Transformers, Sentence-BERT (paraphrase-multilingual-mpnet-base-v2), LangChain для пайплайнов, pgvector для векторов, MLflow для отслеживания экспериментов.

Архитектура:

  1. NewsPersonalizationEngine — ядро с многофакторным ранжированием (код ниже)
  2. EngagementTracker — инкрементальное обновление профиля по событиям сессии
  3. API-слой на FastAPI с кэшированием через Redis

Вот ключевой компонент ранжирования:

import numpy as np
import pandas as pd
from sentence_transformers import SentenceTransformer
from sklearn.metrics.pairwise import cosine_similarity

class NewsPersonalizationEngine:
    """Персонализация новостного контента"""

    def __init__(self):
        self.encoder = SentenceTransformer('paraphrase-multilingual-mpnet-base-v2')

    def build_user_interest_profile(self,
                                     reading_history: list[dict],
                                     explicit_preferences: dict = None) -> dict:
        """
        Профиль интересов из истории чтения.
        reading_history: [{'article_id': ..., 'topic': ..., 'time_spent_sec': ..., 'completed': ...}]
        """
        if not reading_history:
            return {'topics': {}, 'is_cold_start': True}

        # Взвешиваем интересы: время чтения + факт дочтения
        topic_weights = {}
        for article in reading_history:
            topic = article.get('topic', 'general')
            time_weight = min(article.get('time_spent_sec', 30) / 180, 1.0)  # Нормализуем на 3 мин
            completion_bonus = 0.5 if article.get('completed') else 0
            weight = time_weight + completion_bonus

            topic_weights[topic] = topic_weights.get(topic, 0) + weight

        # Нормализация + затухание (старые интересы весят меньше)
        total = sum(topic_weights.values())
        normalized = {t: w / total for t, w in topic_weights.items()}

        # Топ интересов для эмбеддинга профиля
        recent_titles = [a.get('title', '') for a in reading_history[-20:] if a.get('completed')]
        profile_embedding = None
        if recent_titles:
            profile_embedding = np.mean(
                self.encoder.encode(recent_titles, normalize_embeddings=True),
                axis=0
            )

        return {
            'topics': normalized,
            'top_interests': sorted(normalized.items(), key=lambda x: -x[1])[:5],
            'profile_embedding': profile_embedding,
            'is_cold_start': False,
            'explicit_preferences': explicit_preferences or {}
        }

    def score_article(self, article: dict,
                       user_profile: dict,
                       seen_topics_last_hour: list[str]) -> dict:
        """Многофакторный скор статьи для конкретного пользователя"""
        topic = article.get('topic', 'general')
        topics = user_profile.get('topics', {})

        # === Relevance ===
        topic_score = topics.get(topic, 0.05)  # Базовый интерес к теме

        # Семантическое сходство с профилем
        semantic_score = 0.5  # Дефолт для cold start
        profile_emb = user_profile.get('profile_embedding')
        if profile_emb is not None and article.get('embedding') is not None:
            semantic_score = float(cosine_similarity(
                profile_emb.reshape(1, -1),
                np.array(article['embedding']).reshape(1, -1)
            )[0, 0])

        relevance = topic_score * 0.4 + semantic_score * 0.6

        # === Freshness ===
        hours_old = article.get('hours_since_published', 24)
        freshness = np.exp(-hours_old / 12)  # Полупериод 12 часов

        # === Quality ===
        quality_score = (
            article.get('engagement_rate', 0.5) * 0.4 +
            article.get('source_trust_score', 0.7) * 0.3 +
            min(article.get('word_count', 500) / 800, 1.0) * 0.3
        )

        # === Diversity penalty ===
        # Если тему уже видел недавно — снижаем скор
        topic_seen_count = seen_topics_last_hour.count(topic)
        diversity_penalty = 0.9 ** topic_seen_count  # 0→1.0, 1→0.9, 2→0.81...

        # === Breaking news boost ===
        breaking_boost = 1.5 if article.get('is_breaking') else 1.0

        # === Итоговый скор ===
        final_score = (
            relevance * 0.40 +
            freshness * 0.25 +
            quality_score * 0.20 +
            0.15  # Base noise для serendipity
        ) * diversity_penalty * breaking_boost

        return {
            'article_id': article.get('id'),
            'final_score': round(final_score, 4),
            'relevance': round(relevance, 3),
            'freshness': round(freshness, 3),
            'quality': round(quality_score, 3),
            'diversity_penalty': round(diversity_penalty, 3),
        }

    def rank_feed(self, articles: list[dict],
                   user_profile: dict,
                   max_items: int = 20,
                   diversity_floor: float = 0.15) -> list[dict]:
        """
        Финальное ранжирование фида с diversity constraint.
        diversity_floor: минимальная доля статей вне топ-3 тем пользователя.
        """
        seen_topics = []
        scored = []

        for article in articles:
            score_data = self.score_article(article, user_profile, seen_topics)
            scored.append({**article, **score_data})

        scored.sort(key=lambda x: -x['final_score'])

        # Применяем diversity: не более 3 статей подряд из одной темы
        result = []
        topic_counts = {}
        max_per_topic = max(2, max_items // len(user_profile.get('topics', {'general': 1})))

        for item in scored:
            if len(result) >= max_items:
                break

            topic = item.get('topic', 'general')
            if topic_counts.get(topic, 0) >= max_per_topic:
                continue

            result.append(item)
            topic_counts[topic] = topic_counts.get(topic, 0) + 1
            seen_topics.append(topic)

        # Обеспечиваем минимум diversity: добавляем статьи из других тем
        if len(result) > 5:
            top_topics = set(list(topic_counts.keys())[:2])
            non_top_in_result = sum(1 for item in result if item.get('topic') not in top_topics)
            diversity_actual = non_top_in_result / len(result)

            if diversity_actual < diversity_floor:
                # Вставляем статьи из неохваченных тем
                for item in scored[len(result):]:
                    if item.get('topic') not in top_topics:
                        result.insert(len(result) // 2, item)  # Вставка в середину
                        if sum(1 for i in result if i.get('topic') not in top_topics) / len(result) >= diversity_floor:
                            break

        return result[:max_items]


class EngagementTracker:
    """Отслеживание поведения читателя для обновления профиля"""

    def update_profile_from_session(self, user_profile: dict,
                                     session_events: list[dict]) -> dict:
        """Инкрементальное обновление профиля на основе сессии"""
        profile = user_profile.copy()
        topics = dict(profile.get('topics', {}))

        for event in session_events:
            topic = event.get('topic', 'general')
            action = event.get('action')
            value = event.get('value', 0)

            if action == 'completed_read':
                topics[topic] = topics.get(topic, 0) + 0.3
            elif action == 'quick_skip':
                topics[topic] = max(0, topics.get(topic, 0) - 0.1)
            elif action == 'share':
                topics[topic] = topics.get(topic, 0) + 0.5
            elif action == 'dislike':
                topics[topic] = max(0, topics.get(topic, 0) - 0.3)

        # Нормализация
        total = sum(topics.values())
        if total > 0:
            profile['topics'] = {t: w / total for t, w in topics.items()}

        return profile

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

  1. Аналитика — аудит текущего фида, сбор данных (история чтения, события), определение бизнес-целей.
  2. Проектирование — выбираем архитектуру, конфигурацию векторизатора, метрики качества (NDCG, coverage).
  3. Реализация — пишем NewsPersonalizationEngine, EngagementTracker, API, интеграцию с вашим стеком.
  4. Тест — A/B-тест на 10% трафика, мониторинг p99 latency, сравнение с baseline.
  5. Деплой — развёртывание через Docker + Kubernetes, настройка CI/CD для частых обновлений модели.

Свяжитесь с нами для демонстрации работы алгоритма на ваших данных. Закажите предпроектное исследование — мы проанализируем ваш фид за 5 рабочих дней и предоставим roadmap.

Что входит в работу

  • Архитектурная документация (ML System Design Doc)
  • Обученная модель с весами и конфигами
  • REST API для ранжирования с авторизацией
  • Дашборд мониторинга (MLflow, Grafana)
  • Обучение вашей команды основам эксплуатации
  • Поддержка 3 месяца после внедрения

Сроки ориентировочно

  • MVP (базовый фид с профилем): от 2 месяцев
  • Полноценная система (с diversity, cold start, трекингом): от 4 до 6 месяцев
  • Стоимость рассчитывается индивидуально — зависит от объёма данных, требуемой скорости и сложности интеграции.

Наши инженеры имеют сертификаты PyTorch и AWS SageMaker, а опыт в AI/ML превышает 5 лет. Гарантируем стабильность модели в продакшене: SLA по latency p99 < 100ms. Получите консультацию: мы оценим ваш проект и предложим оптимальную архитектуру.

Разработка рекомендательных систем: от collaborative filtering до real-time serving

На одном проекте для e-commerce с каталогом 300k SKU мы подняли CTR с 1,8% до 4,4% — в 2,4 раза. Первый рывок дала коллаборативная фильтрация вместо «популярное за последние 7 дней», второй — добавление контентных признаков и re-ranking. Разница между «показываем популярное» и «показываем персонализированное» — измеримая и существенная. Ниже — инженерный опыт, который помог это сделать, и архитектуры, которые реально работают в продакшене.

Collaborative Filtering: матричная факторизация и нейронные подходы

Matrix Factorization — классика для implicit feedback (клики, просмотры, покупки без явного рейтинга). ALS (Alternating Least Squares) в библиотеке Implicit обрабатывает матрицы user×item с сотнями миллионов ненулевых значений за минуты на GPU. Latent factors 64–256, регуляризация λ=0.01–0.1 — стартовые параметры. Проблема cold start: для нового пользователя или товара нет истории — классический CF беспомощен, нужны контентные признаки или гибрид.

Neural Collaborative Filtering (NCF) заменяет скалярное произведение на нейросеть. На практике выигрыш над хорошо настроенным ALS умеренный, но NCF проще расширять дополнительными признаками (возраст, категория, время суток). Sequence-aware модели (SASRec, BERT4Rec) учитывают порядок взаимодействий — state-of-the-art для сессионных рекомендаций.

Как выбрать архитектуру рекомендательной системы?

Ответ зависит от данных, нагрузки и требований к холодному старту. Ниже — три основных подхода с критериями выбора.

Критерий Collaborative Filtering Content-Based Filtering Гибридный (two-stage)
Данные для старта История взаимодействий Признаки объектов и пользователей И то, и другое
Cold start Провальный Работает для новых items Частично решён
Diversity (long-tail) Низкий, popularity bias Высокий Средний–высокий
Latency serving <5 ms (precomputed) <10 ms (FAISS) 20–50 ms
Сложность внедрения Низкая Средняя Высокая

Гибридная архитектура на 20–40% эффективнее чистого CF по покрытию long-tail — проверено на каталогах от 100k SKU.

Content-Based Filtering: когда истории взаимодействий мало

Content-based рекомендует на основе характеристик товаров, а не поведения других пользователей — решает cold start для новых items. Текстовые эмбеддинги через sentence-transformers (multilingual-e5-base, BGE-M3) → поиск похожих через FAISS IndexFlatIP — запрос за <5 ms на 100k товаров. Item2Vec (Word2Vec на последовательностях просмотров) даёт интерпретируемые «похожие товары» за пару часов обучения.

Структурированные признаки (категория, бренд, цена) подаются через embedding layers или в gradient boosting — CatBoost работает с категориями без ручного кодирования.

Почему гибридные модели работают лучше?

Production-системы почти всегда двухуровневые. Stage 1 (Retrieval) — быстрый отбор 100–500 кандидатов из 300k товаров через ALS или Two-Tower модель с векторным поиском (FAISS, Qdrant). Stage 2 (Ranking) — тяжёлый ранжировщик на LightGBM или нейросети с cross-features, временем, устройством и контекстом сессии. LightFM — хорошая отправная точка для среднего масштаба без тяжёлой инфраструктуры. Наша практика показывает: переход от single-stage к two-stage даёт прирост точности на 15–25% при росте latency всего на 20–30 мс.

Real-Time Serving: архитектура под нагрузку

Latency SLA — 50–100 ms при тысячах запросов в секунду. Base-рекомендации precompute (batch job раз в час) → Redis по user_id → <5 ms. Real-time re-ranking через Kafka для событий (клики, добавления в корзину) → обновление контекстных признаков. Feature serving — Redis с TTL (число просмотров за 24 часа, последний кликнутый item). При нагрузке 10k req/s ставим Redis Cluster с репликацией.

A/B тестирование — единственный достоверный способ оценить улучшения. Офлайн-метрики коррелируют с онлайн не всегда. Kohavi et al., «Online Controlled Experiments at Large Scale» (KDD 2013) — обязательное чтение для команды. Тест с 5–10% трафика, мониторинг CTR, конверсии, revenue per session. Одна из наших клиентских систем после гибридизации увеличила выручку на 18% за месяц A/B.

Сроки разработки рекомендательной системы

Этапы и типичные временные затраты — в таблице ниже. Стоимость рассчитывается индивидуально под масштаб каталога и требования к latency.

Этап Длительность Результат
Аудит данных и baseline 1–2 недели Отчёт с плотностью матрицы, cold start‑зонами, метриками «популярного»
Прототип (offline validation) 2–3 недели Работающая модель с офлайн-метриками (Recall@k, NDCG)
Production-система (two-stage, A/B) 1.5–2.5 месяца Low-latency сервис с мониторингом и A/B-инфраструктурой
Обучение команды и документация 1–2 недели Model card, runbook по деплою, сессия по дообучению

Что входит в разработку под ключ

  1. Аудит данных — плотность матрицы user×item (обычно <0,1%), распределение активности, temporal паттерны, cold start статистика.
  2. Baseline — «популярное» как простой порог, который часто трудно обогнать.
  3. Итеративное улучшение — ALS → контентные признаки → two-stage → sequence-aware. Каждый шаг с A/B.
  4. Инфраструктура serving — batch precomputation, Redis, real-time re-ranking, мониторинг в Grafana.
  5. Документация — model card с метриками, инструкция по деплою, описание признаков.
  6. Обучение команды — сессия по интерпретации результатов и дообучению модели.
  7. Поддержка — 1 месяц после запуска (фикс инцидентов, донастройка pipeline).

Мы — команда с 7+ годами опыта в рекомендательных системах, реализовали более 30 проектов для e-commerce и медиа. Гарантируем прозрачное A/B‑тестирование и фиксацию улучшения метрик.

Хотите оценить потенциал роста вашего каталога? Свяжитесь с нами для бесплатного аудита данных. Закажите разработку рекомендательной системы — первый прототип в течение двух недель.

Пример конфига ALS для implicit feedback
from implicit.als import AlternatingLeastSquares

model = AlternatingLeastSquares(
    factors=64,
    regularization=0.05,
    iterations=15,
    use_gpu=True
)
model.fit(user_item_matrix)

Больше о математике рекомендательных систем — в Wikipedia.