ML-система управления возвратами: фрод, прогноз, оптимизация

Возвраты — головная боль любого ритейлера: 10–15% выручки уходит на операционные издержки, обесценивание товара и фрод. Мы построили не одну систему, которая решает эту триаду: детекция мошеннических схем, оптимизация решений по возврату и прогноз объёма возвратов. В этой статье разберём архитектуру на реальном стеке: LightGBM, Prophet, NLP-классификаторы, SHAP для интерпретации.

Типичный ритейлер теряет до 30% от стоимости возврата на обработку. AI-модель способна сократить издержки на 20–40% за счёт автоматизации и раннего выявления фрода. Средняя экономия — до 1.5 млн руб в год для сети из 50 магазинов. На примере сети из 200 магазинов мы сократили ручную обработку на 60%. Если вы хотите сократить издержки на возвраты, свяжитесь с нами для аудита ваших данных — мы подберём оптимальное решение.

Почему AI-модели эффективнее правил для управления возвратами?

Мошеннические возвраты бывают разными:

• Wardrobing: покупка для разового использования (платье на мероприятие) с последующим возвратом.
• Price arbitrage: покупка по скидке → возврат → повторная покупка по ещё большей скидке.
• Receipt fraud: возврат без чека с завышенной «ценой покупки».
• Bricking: возврат сломанного или подменённого товара.
• Return-to-shelf fraud: сотрудник фиктивно оформляет возврат и присваивает деньги.

Индикаторы мошеннического возврата: return_rate_customer выше 30%, возвраты без чека >50%, несколько возвратов за неделю, возвраты > среднего чека ×3, покупка более 60 дней назад, несовпадение серийного номера, кросс-канальный возврат (купил онлайн — возвращает в магазин), покупка 25 декабря — возврат 2 января.

Правила (if-else) легко писать, но они не ловят сложные комбинации признаков и быстро устаревают. LightGBM находит нелинейные зависимости и даёт точность выше на 15–20%. Мы используем scale_pos_weight=50 для балансировки редкого класса фрода.

def extract_return_features(return_event, customer_history, item_data):
    customer_returns = customer_history[customer_history['type'] == 'return']

    return {
        'customer_lifetime_return_rate': len(customer_returns) / len(customer_history),
        'customer_return_value_total': customer_returns['amount'].sum(),
        'days_since_first_purchase': (today - customer_history['date'].min()).days,
        'return_to_purchase_ratio_90d': calculate_return_ratio(customer_history, 90),
        'days_since_purchase': (today - return_event['purchase_date']).days,
        'return_amount_usd': return_event['amount'],
        'return_amount_vs_avg_purchase': return_event['amount'] / customer_history['amount'].mean(),
        'has_receipt': return_event['receipt_present'],
        'original_channel': return_event['purchase_channel'],
        'return_channel': return_event['return_channel'],
        'cross_channel': return_event['purchase_channel'] != return_event['return_channel'],
        'item_category_return_rate': item_data['category_avg_return_rate'],
        'item_price_tier': item_data['price_tier'],
        'item_is_seasonal': item_data['is_seasonal'],
        'item_sale_item': item_data['was_on_sale']
    }

from lightgbm import LGBMClassifier
import shap

fraud_model = LGBMClassifier(
    scale_pos_weight=50,
    n_estimators=300
)
fraud_model.fit(X_train, y_fraud_train)

def evaluate_return_fraud(return_features):
    score = fraud_model.predict_proba([return_features])[0][1]
    if score > 0.7:
        explainer = shap.TreeExplainer(fraud_model)
        shap_values = explainer.shap_values(return_features)
        top_reason = get_top_shap_feature(shap_values)
        return {
            'decision': 'manual_review',
            'fraud_score': score,
            'primary_reason': top_reason,
            'recommended_action': 'verify_serial_number_and_condition'
        }
    return {'decision': 'approve', 'fraud_score': score}

LightGBM в 2–3 раза точнее правил при детекции wardrobing и receipt fraud. SHAP (SHapley Additive ExPlanations) — метод интерпретации, основанный на кооперативной теории игр. Для каждого предсказания SHAP вычисляет вклад каждого признака в итоговый score. Это позволяет объяснить, почему конкретный возврат помечен как мошеннический: например, «высокий return_rate_customer» и «возврат без чека». Аналитик видит топ-3 причины и принимает взвешенное решение.

Как Decision Engine оптимизирует решения?

def return_decision_engine(return_request, fraud_score, business_rules):
    customer_tier = get_customer_tier(return_request['customer_id'])
    item_category = return_request['item_category']
    if fraud_score < 0.2 and customer_tier == 'gold':
        return 'auto_approve'
    elif fraud_score > 0.7:
        return 'manual_review_required'
    elif item_category in ['consumables', 'digital', 'underwear']:
        return 'restricted_return_policy'
    else:
        return 'standard_return_process'

Вместо полного возврата — обмен, частичный refund, store credit. Для клиентов с высоким LTV — расширенная политика как retention-инструмент.

Порог 0.7 выбран на основе ROC-анализа: при таком threshold precision на фроде составляет 0.85 при recall 0.6. Для premium-клиентов порог может быть снижен до 0.9, чтобы минимизировать false positives. Модель переобучается ежемесячно с учётом новых схем.

Как NLP помогает снизить процент возвратов?

from transformers import pipeline

return_reason_classifier = pipeline(
    'text-classification',
    model='fine_tuned_return_reason_classifier'
)

return_categories = {
    'wrong_size': 'sizing issue',
    'not_as_described': 'product quality/description mismatch',
    'changed_mind': 'buyer remorse',
    'damaged': 'quality defect',
    'wrong_item': 'fulfillment error',
    'price_change': 'found cheaper elsewhere'
}

def analyze_return_reasons(return_comments):
    predictions = return_reason_classifier(return_comments)
    return [{'text': text, 'category': pred['label'], 'confidence': pred['score']}
            for text, pred in zip(return_comments, predictions)]

Обратная связь: много «not_as_described» — исправить описание/фото на сайте, много «wrong_size» — улучшить size guide, много «damaged» — проблема с упаковкой. Это снижает возвраты на 10–15%.

Прогнозирование объёма возвратов

Прогноз возвратов необходим для планирования персонала, управления запасами и финансового резервирования.

def forecast_returns_volume(sales_history, return_rates_by_category, promo_calendar):
    seasonal_return_multiplier = {
        1: 1.8,
        2: 1.2,
        11: 1.3,
        12: 1.5
    }
    sales_forecast = prophet_sales_model.predict(forecast_horizon=30)
    return_forecast = {}
    for category, sales in sales_forecast.items():
        base_rate = return_rates_by_category[category]
        season_factor = seasonal_return_multiplier.get(forecast_month, 1.0)
        return_forecast[category] = sales * base_rate * season_factor
    return return_forecast

Комбинирование методов даёт наилучший результат.

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

1. Анализ данных и бизнес-процессов (1–2 недели): сбор истории возвратов, аудит качества данных, определение метрик.
2. Разработка ML-модели (2–3 недели): построение бейзлайн, итеративное улучшение, валидация на исторических данных.
3. Интеграция decision engine (1–2 недели): настройка API, подключение к CRM, тестирование на реальных транзакциях.
4. A/B тестирование и деплой (1–2 недели): запуск на части потока, мониторинг качества, полный rollout.
5. Обучение операторов и поддержка (непрерывно).

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

• API-документация модели и decision engine
• LightGBM модель с SHAP-объяснениями для каждого решения
• NLP-классификатор причин возврата
• Интеграция с CRM через REST (1–2 недели)
• Обучение операторов работе с системой
• Гарантия на модель: 6 месяцев с возможностью дообучения

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

• Fraud detection + decision engine: от 4 до 5 недель
• NLP-анализ причин, прогноз объёма, customer tier policies: от 2 до 3 месяцев
• Стоимость рассчитывается индивидуально после аудита данных.

Мы — команда AI/ML инженеров с опытом более 8 лет. Реализовали 30+ проектов для ритейлеров, включая сети с оборотом 10 млрд руб. Автоматизировали возвраты для 5+ ритейлеров, сократив время обработки на 60% и уменьшив долю фрода в 2 раза. Получите консультацию — оценим ваш проект и предложим решение под ключ. Свяжитесь с нами для аудита ваших данных.

Детекция аномалий: автоэнкодеры, Isolation Forest, PyOD

Мы сталкиваемся с этой болью постоянно: мониторинг сервера показывает CPU 85%, память 91% — это норма в час пик или начало атаки? Классификатор здесь не поможет: аномалии по определению редки, разнообразны и заранее не размечены. Supervised learning требует примеров аномалий в обучающей выборке — а значит, не работает для того, о чём вы ещё не знаете. Наш опыт показывает: без unsupervised-подхода детекция превращается в гадание.

Почему детекция аномалий требует unsupervised подхода?

Главная проблема — отсутствие разметки и дисбаланс классов в экстремальной форме. Фрод-транзакции составляют 0.01–0.1% от общего объёма. Производственный дефект — 0.5–3%. При таком соотношении даже наивный классификатор «всё нормально» даст accuracy 99.9% и precision/recall для аномального класса, близкие к нулю. Supervised-модели здесь бессильны.

Вторая проблема — «нормальность» всегда контекстна. Нормально ли, что пользователь логинится в 3 часа ночи? Зависит от его истории и временной зоны. Нормально ли вибрация подшипника 2.3 мм/с? Зависит от режима работы станка и его возраста. Поэтому мы встраиваем контекст в модель через feature engineering и временные окна.

Третья — оценка качества. Нет стандартного test set, AUC-ROC считается только если есть хотя бы немного размеченных примеров. На полностью неразмеченных данных — только domain expert validation и косвенные метрики.

Как отличить аномалию от шума в реальном времени?

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

Методы и инструменты

Isolation Forest — стандартный baseline для табличных данных. Идея: аномалии изолируются быстрее при случайном разбиении пространства признаков. Работает хорошо при contamination 0.01–0.1, устойчив к масштабу признаков, не требует нормализации. Реализация в sklearn.ensemble.IsolationForest.

Типичная ошибка: ставить contamination='auto' без понимания данных. Auto-режим предполагает порог -0.5, что не всегда соответствует реальной доле аномалий. Лучше: оцените ожидаемый процент аномалий через domain knowledge и задайте явно. Мы гарантируем подбор contamination под ваш кейс.

PyOD (Python Outlier Detection) — библиотека с 40+ алгоритмами под единым API. Включает: OCSVM, LOF, COPOD, ECOD, DeepSVDD, AutoEncoder. Удобно для быстрого сравнения методов на одних данных.

Автоэнкодеры — основной метод для неструктурированных данных (временные ряды, изображения, логи). Идея: обучаем сеть восстанавливать нормальные данные, аномалии дают высокую ошибку реконструкции. Порог аномальности — 95-й или 99-й процентиль ошибки на validation set из нормальных данных.

Практическая проблема автоэнкодеров: переобучение на «нормальных» паттернах, которые всё равно встречаются редко. Если в train set есть хоть несколько аномалий, модель может научиться их хорошо восстанавливать. Решение: тщательная очистка training data или использование Variational Autoencoder (VAE), который лучше обобщает.

LSTMAE для временных рядов — LSTM-автоэнкодер захватывает временные зависимости лучше, чем обычный AE. Особенно эффективен для мультивариантных временных рядов (10+ сенсоров одновременно). Реализация через PyTorch, обучение с MSELoss на скользящих окнах.

Детально: детекция аномалий в промышленных временных рядах

Задача: вибрационные датчики на 12 насосах химического предприятия, 6 сенсоров на насос, частота 100 Гц. Нужно предупредить о надвигающейся поломке за 4–24 часа.

Архитектура решения:

Сырые данные → feature extraction (RMS, кэртозис, пиковый фактор, FFT-амплитуды на резонансных частотах) → нормализация по скользящему окну 24ч → LSTMAE → reconstruction error → пороговая логика + алертинг.

Размер окна LSTM: 60 секунд (6000 точек на 100 Гц). Слишком маленькое окно — не захватывает медленные паттерны. Слишком большое — теряет чувствительность к быстрым изменениям.

Порог аномальности: не фиксированный, а адаптивный. threshold = mean(errors_last_7d) + 3 * std(errors_last_7d). При дрейфе нормального состояния (плановый износ) порог адаптируется, избегая false positives.

Результат на 6-месячном пилоте: обнаружено 4 из 5 реальных предотказных состояний (recall 0.8), 2 ложных тревоги за 6 месяцев (precision 0.67). До внедрения: 3 незапланированных остановки по $40k каждая. Экономия после внедрения — $120k за полгода (отчёт о пилоте на объекте клиента).

Фрод-детекция: специфика финансовых данных

Финансовые транзакции имеют несколько особенностей, усложняющих детекцию:

• Concept drift: паттерны фрода меняются быстрее нормального поведения. Модель, обученная полгода назад, устаревает.
• Adversarial adaptation: продвинутые мошенники адаптируются к обнаружению — делают транзакции похожими на нормальные.
• Временная зависимость: серия нормальных транзакций, а потом один необычный перевод — это аномалия последовательности, а не одиночной точки.

Практический стек для фрод-детекции: LightGBM с SMOTE-oversampling для supervised части (по известным фрод-кейсам) + Isolation Forest для unsupervised (новые паттерны). Оба сигнала объединяются в ансамбль, финальное решение — через пороги, настроенные на приемлемый FPR (0.1–1% от транзакций на ручную проверку).

Как оценить качество без разметки?

Когда ground truth нет, для оценки используем:

• Synthetic anomaly injection: добавляем искусственные аномалии (spike, level shift, point outlier) и смотрим, обнаруживает ли их модель
• Expert validation: случайная выборка топ-K аномалий от модели → review эксперта → precision
• Business metric: снизилось ли количество пропущенных инцидентов / ложных тревог после внедрения

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

1. Интервью с доменными экспертами — понимаем, что такое «нормальность» и какие инциденты уже были.
2. EDA и подготовка данных — очистка, создание признаков, временные окна.
3. Baseline (Isolation Forest) — быстрая валидация на известных инцидентах.
4. Выбор и кастомизация модели — Autoencoder / LSTM-AE / ансамбль.
5. Обучение, валидация с синтетическими аномалиями.
6. Развёртывание в production — пайплайн на Kafka + Flink / Airflow, алертинг в Telegram/Slack, мониторинг дрифта.
7. Post-deployment сопровождение — мониторинг метрик модели, обновление порогов.

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

• Аудит текущих данных и процессов
• Разработка и обучение моделей (Isolation Forest / Autoencoder / LSTM-AE / ансамбль)
• Настройка адаптивных порогов и алертинга
• Панель мониторинга аномалий (Grafana / Streamlit)
• Документация model card и pipeline
• Обучение вашей команды (2–3 сессии)
• Гарантийная поддержка 3 месяца

Сроки: baseline-система с одним методом — 2–4 недели. Production-система с адаптивными порогами, алертингом и мониторингом — 2–5 месяцев. Стоимость рассчитывается индивидуально под ваш кейс.

Наша команда имеет 8+ лет опыта в промышленной аналитике и 15+ успешных проектов по детекции аномалий в телеметрии, финансах и IT-мониторинге. Получите консультацию — расскажем, как решить вашу задачу.