AI-система персонализации email-рассылок для медиа

Массовые рассылки с одинаковым контентом для всей базы — это устаревший подход: open rate 15–20%, а отток подписчиков достигает 5–8% в месяц. Наши инженеры замечают, что медиа теряют до 70% потенциала вовлечения из-за игнорирования поведенческих сигналов. Мы строим pipeline персонализации на базе LLM и event streaming, который поднимает open rate до 35–50%: профиль читателя → скоринг статей → генерация темы письма через большую языковую модель. Технически это цепочка, включающая Apache Kafka для событий, Redis для профилей и batch-обработку за 1–2 часа до отправки. В результате каждый подписчик получает дайджест, релевантный его интересам, что сокращает отток в 2–3 раза и экономит до 40% бюджета на email-маркетинг за счёт снижения числа нецелевых отправок.

Какие данные критичны для персонализации?

Для качественного профиля требуется минимум 10–15 прочитанных статей. Собираем события: просмотры, время на странице, лайки, шеринг. До этого порога используем категорийную персонализацию — выбираем разделы на основе последних интересов. Данные хранятся в Redis с TTL 30 дней; топики взвешиваются с экспоненциальным затуханием. Без достаточной истории алгоритм переключается на fallback, чтобы не ухудшать опыт.

Почему массовые рассылки проигрывают персонализации?

Однотипные дайджесты игнорируют поведенческие сигналы: какой раздел читатель открывает чаще, какие темы пропускает. LLM-персонализация учитывает свежесть контента, редакционную оценку и даже время суток. Сравните:

После внедрения персонализации open rate вырос с 18% до 41% за три месяца, — отмечает технический директор одного из клиентов.

Как мы строим pipeline персонализации?

Шаг 1. Профилирование читателя. Собираем события через Apache Kafka: просмотры, лайки, время на статье. Сохраняем в Redis с TTL 30 дней. Топики взвешиваем с экспоненциальным затуханием. Для каждого читателя формируем 1536-мерный embedding на основе истории просмотров.

Шаг 2. Скоринг статей. Для каждого непрочитанного материала рассчитываем комбинированный score:

• Соответствие топикам (50%)
• Свежесть (30%) — чем моложе статья, тем выше
• Редакционная оценка (20%)

Шаг 3. Генерация темы письма. Используем Claude 3.5 Sonnet с few-shot промптом. Модель получает три лучшие статьи и интересы читателя, выдаёт заголовок до 55 символов на русском. Пример кода:

from anthropic import Anthropic

def generate_personalized_digest(user_profile, available_articles, n_articles=5):
    llm = Anthropic()
    read_ids = user_profile.get('read_ids', set())
    unread = [a for a in available_articles if a['id'] not in read_ids]
    topics = user_profile.get('topics', {})
    scored = []
    for article in unread:
        topic_score = topics.get(article.get('topic', 'general'), 0.05)
        freshness = max(0, 1.0 - article.get('hours_old', 24) / 48)
        quality = article.get('editorial_score', 0.7)
        scored.append({**article, 'score': topic_score*0.5 + freshness*0.3 + quality*0.2})
    top_articles = sorted(scored, key=lambda x: -x['score'])[:n_articles]
    article_titles = [a['title'] for a in top_articles]
    response = llm.messages.create(
        model="claude-3-5-sonnet-20241022",
        max_tokens=80,
        messages=[{
            "role": "user",
            "content": f"Write a compelling email subject line for a news digest in Russian.\nArticles: {article_titles[:3]}\nReader's main interests: {list(topics.keys())[:3]}\nMax 55 chars. No clickbait."
        }])
    return {'articles': top_articles, 'subject': response.content[0].text.strip()}

Порог запуска персонализации — 10–15 прочитанных статей. Иначе включается категорийная персонализация (выбор раздела) без статейного уровня. При необходимости используем fine-tuning модели на корпусе редакционных материалов с помощью LoRA.

Какие результаты даёт персонализация?

Персонализированные дайджесты в 2–3 раза эффективнее массовых рассылок по основным метрикам. Мы проводим A/B-тестирование для каждой модели, фиксируя lift на уровне p99 latency менее 200 мс. Опыт нашей команды в MLOps и NLP позволяет быстро адаптировать pipeline под любую редакцию. Экономия на нецелевых отправках достигает 30–40% при сохранении качества контента.

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

• Архитектура решения с блочной схемой
• Код pipeline на Python с использованием LangChain и Redis
• Интеграция с CRM и ESP через REST API
• Документация и обучение команды
• Гарантия на 3 месяца и поддержка при релизах

Сроки и стоимость

Срок внедрения: от 2 до 6 недель в зависимости от сложности интеграций. Стоимость рассчитывается индивидуально после аудита текущего стека. Оценим проект бесплатно — получите консультацию через форму на сайте.

Как начать?

Расскажите о вашей базе подписчиков, текущих метриках и задачах. Мы подготовим предложение с точным составом работ и календарным планом. Свяжитесь с нами — поможем поднять open rate до 50%.

Разработка рекомендательных систем: от 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 для сессионных рекомендаций.

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

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

Гибридная архитектура на 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.

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

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‑тестирование и фиксацию улучшения метрик.

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

from implicit.als import AlternatingLeastSquares

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

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