Проактивные AI-уведомления: предотвращаем обращения в поддержку

Клиент ждёт заказ, но доставка задерживается. Вместо того чтобы звонить в поддержку, он получает SMS с новым ETA и ссылкой на трекер. Это и есть проактивное AI-уведомление — система сама находит проблему и решает её до того, как клиент заметит. Мы внедряем такие решения, и тикеты в контакт-центр падают на 20–35%.

Автоматическая детекция и генерация уведомлений

Система анализирует тысячи событий в реальном времени: статусы заказов, логистические данные, подписки, поведенческие паттерны. Как только детектор находит аномалию — задержку, риск отказа платежа, приближение лимита, — Large language model (например, Claude 3.5 Sonnet) генерирует персонализированное уведомление и отправляет его через подходящий канал: SMS, push, email или мессенджер. Всё происходит за секунды, без участия человека. Результат: клиент получает решение, а поддержка — меньше звонков.

Почему проактивные уведомления выгоднее реактивной поддержки?

Сравним прямые затраты на контакт-центр и на систему уведомлений. Типичный звонок в контакт-центр обходится компании в 200–400 рублей, а одно уведомление — в 1–2 рубля. При стоимости звонка в 100–300 раз выше уведомления достаточно предотвратить менее 1% обращений, чтобы система окупилась. На практике она отсекает 20–35% тикетов.

Какие каналы уведомлений эффективнее?

Выбор канала влияет на скорость реакции и стоимость. Вот сравнение основных вариантов:

Для критических событий (задержка доставки, сбой сервиса) мы используем SMS+push, для менее срочных — email.

Основные триггеры системы

Система покрывает пять основных сценариев, на которые приходится 80% обращений в поддержку:

• Задержки доставки: детекция заказов, где estimated_delivery превышена более чем на день. Клиент получает сообщение с новым ETA и, если нужно, предложение компенсации.
• Риск отказа платежа: за 30 дней до истечения карты — email с просьбой обновить данные. Это предотвращает 15–20% отказов подписок.
• Приближение лимита подписки: когда usage достигает 80%, клиенту предлагают расширить план. Upsell без участия поддержки.
• Сообщения о сбоях: если сервис в регионе клиента временно недоступен, уведомление приходит до того, как пользователь попытается зайти и создаст тикет.
• Аномальная активность: вход с нового устройства или местоположения — автоматическое уведомление с подтверждением.

Архитектура системы: как это работает под капотом

Основные компоненты: детектор событий на Python, LLM для генерации текста (Claude 3.5 Sonnet), модуль приоритизации на Pandas. Детектор анализирует логистические данные, подписки и поведенческие паттерны. Ниже — ключевые классы (полная реализация в репозитории).

import pandas as pd
import numpy as np
from anthropic import Anthropic
import json

class ProactiveNotificationEngine:
    """Детекция событий, требующих проактивного уведомления"""

    NOTIFICATION_TRIGGERS = {
        'delivery_delay': {
            'threshold': 'expected_delivery exceeded by 1 day',
            'channel': 'sms+push',
            'priority': 'high'
        },
        'payment_failure_risk': {
            'threshold': 'card expires within 30 days',
            'channel': 'email',
            'priority': 'medium'
        },
        'service_disruption': {
            'threshold': 'user in affected region',
            'channel': 'push+sms',
            'priority': 'critical'
        },
        'subscription_limit_approaching': {
            'threshold': 'usage > 80% of plan limit',
            'channel': 'in_app+email',
            'priority': 'medium'
        },
        'anomalous_account_activity': {
            'threshold': 'login from new location',
            'channel': 'email+sms',
            'priority': 'high'
        }
    }

    def detect_delivery_issues(self, orders: pd.DataFrame,
                                logistics_data: pd.DataFrame) -> pd.DataFrame:
        """Детекция заказов с риском задержки"""
        merged = orders.merge(logistics_data, on='tracking_id', how='left')
        today = pd.Timestamp.now()

        merged['days_delayed'] = (
            merged['estimated_delivery_updated'] - merged['expected_delivery']
        ).dt.days

        at_risk = merged[
            (merged['days_delayed'] > 0) &
            (~merged['delivered']) &
            (~merged['notification_sent'])
        ].copy()

        at_risk['urgency'] = pd.cut(
            at_risk['days_delayed'],
            bins=[-np.inf, 1, 3, np.inf],
            labels=['minor', 'moderate', 'significant']
        )

        return at_risk

    def detect_usage_limit_alerts(self, subscriptions: pd.DataFrame) -> pd.DataFrame:
        """Клиенты, приближающиеся к лимитам подписки"""
        subscriptions = subscriptions.copy()
        subscriptions['usage_pct'] = subscriptions['current_usage'] / subscriptions['plan_limit']

        return subscriptions[
            (subscriptions['usage_pct'] > 0.80) &
            (subscriptions['usage_pct'] < 1.0) &
            (~subscriptions['upsell_shown'])
        ].sort_values('usage_pct', ascending=False)

    def generate_notification(self, trigger_type: str,
                               customer: dict,
                               event_data: dict) -> dict:
        """Персонализированный текст уведомления"""
        llm = Anthropic()

        trigger_config = self.NOTIFICATION_TRIGGERS.get(trigger_type, {})

        response = llm.messages.create(
            model="claude-3-5-sonnet-20241022",
            max_tokens=150,
            messages=[{
                "role": "user",
                "content": f"""Write a proactive customer notification in Russian.

Trigger: {trigger_type}
Customer: {customer.get('first_name', 'Клиент')}
Event details: {json.dumps(event_data, ensure_ascii=False)[:200]}

Write:
1. Short subject/title (push notification style, max 50 chars)
2. Body (2-3 sentences: what happened, what we're doing, what customer should do if anything)

Be empathetic and solution-focused. No corporate speak.
Return JSON: {{"title": "...", "body": "..."}}"""
            }]
        )

        try:
            content = json.loads(response.content[0].text)
        except Exception:
            content = {'title': 'Важная информация о вашем заказе', 'body': ''}

        return {
            'customer_id': customer.get('id'),
            'channel': trigger_config.get('channel', 'email'),
            'priority': trigger_config.get('priority', 'normal'),
            'title': content.get('title'),
            'body': content.get('body'),
            'trigger_type': trigger_type
        }

    def prioritize_notifications(self, pending_notifications: pd.DataFrame) -> pd.DataFrame:
        """Приоритизация с учётом усталости от уведомлений"""
        priority_order = {'critical': 0, 'high': 1, 'medium': 2, 'low': 3}
        pending_notifications['priority_num'] = pending_notifications['priority'].map(priority_order)

        sorted_notifs = pending_notifications.sort_values(
            ['customer_id', 'priority_num']
        )

        result = sorted_notifs.groupby('customer_id').head(2)
        return result

Как мы внедряем систему: процесс работы

1. Анализ данных: исследуем историю обращений и логов, выявляем основные триггеры недовольства.
2. Проектирование триггеров: определяем 5–10 типов событий, которые должны вызывать уведомление.
3. Интеграция с API: подключаемся к CRM, OMS, логистической платформе.
4. Реализация детекторов: пишем код для выявления событий в реальном времени.
5. Настройка LLM: калибруем промпты для генерации человечного и эмпатичного текста.
6. A/B-тестирование: запускаем пилот на 10% аудитории, сравниваем метрики (NPS, тикеты, уведомления).
7. Деплой и мониторинг: разворачиваем на Kubernetes (Triton Inference Server) с дашбордом в Grafana.

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

• Исходный код детекторов и интеграций (ваш форк репозитория).
• Документация по архитектуре и API.
• Настроенные шаблоны уведомлений для 5+ сценариев.
• Инструкция по эксплуатации и добавлению новых триггеров.
• Поддержка на этапе пилота (2 недели после деплоя).
• Обучение команды (2–4 часа воркшопа).

Сроки и как начать

Пилот с одним триггером и 1000 клиентов — от 14 дней. Полноценное внедрение с 10 триггерами и масштабированием — 1–2 месяца. Стоимость рассчитывается индивидуально под ваш объем данных и количество сценариев. Свяжитесь с нами — оценим проект за один рабочий день и предложим план внедрения. Наш опыт в AI-коммуникациях — 5+ лет, мы реализовали более 50 проектов в ритейле, финтехе и телекоме. Гарантируем снижение обращений в поддержку минимум на 15% после первого этапа. Получите консультацию — узнайте, как проактивные уведомления повлияют на ваши метрики.

Исследование Gartner показывает, что компании, использующие проактивные уведомления, снижают количество обращений в поддержку на 20–35%.

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