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

Повернення — головний біль будь-якого ритейлера: 10–15% виручки йде на операційні витрати, знецінення товару та фрод. Ми побудували не одну систему, яка вирішує цю тріаду: детекція шахрайських схем, оптимізація рішень щодо повернення та прогноз обсягу повернень. У цій статті розберемо архітектуру на реальному стеку: LightGBM, Prophet, NLP-класифікатори, SHAP для інтерпретації.

Типовий ритейлер втрачає до 30% від вартості повернення на обробку. AI-модель здатна скоротити витрати на 20–40% за рахунок автоматизації та раннього виявлення фроду. На прикладі мережі з 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 незаплановані зупинки зі значними збитками. Економія після впровадження — значна сума за півроку (звіт про пілот на об'єкті клієнта).

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

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

• 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-моніторингу. Отримайте консультацію — розкажемо, як вирішити вашу задачу.