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

AI управление возвратами: где ломается процесс

Возвраты — точка, где сходятся склад, логистика, финансы и поведение покупателей. Правила отбора заявок обычно настраивают один раз и по средним значениям: порог по сумме заказа, доля возвратов за период, список адресов и категорий. Пока поведение покупателей предсказуемо, схема держится; при смене ассортимента или сезонного спроса пороги перестают соответствовать реальности.

Жёсткие правила отбора дают два перекоса сразу. Часть заявок они отправляют на ручную обработку, хотя риск там минимальный, — и очередь растёт. Другую часть пропускают автоматически, хотя по истории клиента давно видны признаки злоупотребления. В обе стороны это потери на возвратах: оплаченная обратная логистика, замороженный товар, повторная упаковка.

Ручная обработка заявок становится узким местом процесса. Решение зависит от смены, от того, сколько признаков оператор успевает посмотреть и есть ли у него контекст по клиенту. При росте объёма заявок время рассмотрения увеличивается быстрее, чем штат, а логику отказа потом не воспроизвести — качество решений расходится между сменами.

Отдельная проблема — решения принимаются без истории клиента. Один покупатель годами возвращает товар аккуратно, другой собирает заявки по одной схеме на разных аккаунтах, а пороговое правило видит только текущую заявку. Прогноз возвратов опирается на поведение: модель оценивает риск по десяткам факторов и отдаёт приоритет заявкам, где проверка действительно нужна.

Дальше разбираем, как это закрывается: куда встраивается прогноз, что уходит из ручной обработки и как жёсткие пороги заменяются адаптивными.

Что даёт модель: скорость, точность, снижение потерь

Модель оценивает заявку в момент оформления: история клиента, состав заказа, поведение на сайте, данные о доставке — на выходе вероятность того, что возврат обоснован. Заявки с высокой оценкой закрываются автоматически, спорные уходят оператору, рискованные — на проверку. Пороги задаются раздельно для денежных и товарных потерь: цена ошибки разная, значит и граница разная.

Точность прогноза и полнота отбора заявок тянут в разные стороны, и выбирать между ними приходится осознанно. Пропущенный мошеннический возврат обходится дороже лишней проверки, поэтому для рискованного сегмента порог сдвигается в сторону полноты: в проверку попадает больше заявок, зато класс отказа уходит целиком. Итоговое качество фиксируем на отложенной выборке и на периоде, которого модель не видела при обучении.

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

Решение должно быть объяснимым: на каждую оценку строится разбор вклада признаков через SHAP, чтобы оператор видел причину отказа, а не просто отметку «риск». Плюс отслеживаем дрейф входных данных — когда поведение клиентов меняется, пороги и признаки пересматриваются на свежей разметке, иначе точность прогноза сползает незаметно.

Режимы работы: правила на порогах, модель, гибрид

Режим обработки возврата определяет, где принимается решение — в явном правиле или в модели. Порог по сумме или частоте возвратов читается глазами, объясняется службе поддержки в одну строку и вступает в силу сразу после настройки, но любой сдвиг в поведении покупателей ломает границу, а список исключений растёт быстрее, чем его успевают ревизовать. Обученная модель ловит сочетания признаков, которые в правило не выписать, зато требует накопленной истории и постоянного контроля качества разметки.

Выбор между этими режимами определяют три вещи: сколько у вас уже накоплено размеченных возвратов, нужна ли объяснимость каждого срабатывания и как часто меняется ассортимент.

Гибридный подход чаще всего и становится рабочей точкой: правило держит явные стоп-сигналы, модель ранжирует остальное и отдаёт на ручную проверку только спорные случаи. Обучение на своих данных включаем после того, как набрана первая разметка — тогда качество растёт на ваших сценариях, а не на усреднённых.

Этапы внедрения: от аудита данных до сопровождения

План работ строится так, чтобы каждая ступень опиралась на проверенный результат предыдущей. Модель на грязной или смещённой выборке показывает красивые числа в отчёте и разваливается на живом потоке: возвраты уходят в ручное согласование, поддержка тонет в однотипных заявках. Поэтому начинаем с данных и правил разметки, а код пишем после.

Данные и схема

1. Аудит данных и разметки. Выгружаем историю заявок, сверяем поля с учётной и платёжной системами, ищем пропуски, дубли, расхождения статусов. Разбираем, чем помечен исход — возврат по правилу, отказ, оспаривание, — иначе целевая переменная размыта.
2. Схема решения. Фиксируем, какие признаки доступны в момент решения, чтобы в обучение не попала информация из будущего. Описываем правила разметки спорных кейсов и собираем эталонный набор для контроля качества.
3. Обучение модели. Признаки: частота возвратов по клиенту, товару и каналу, история отмен, поведение при оформлении. Порог срабатывания настраиваем под посильный объём ручных проверок.

Проверка и запуск

• Проверка на истории. Прогон по прошлым периодам с разбиением по времени: сколько злоупотреблений поймано при заданном уровне ложных срабатываний. Ошибки разбираем по сегментам.
• Запуск на ограниченном потоке. Сначала теневой режим рядом с текущим процессом, затем часть трафика, где оценки сверяются с решениями операторов. Откат — одно переключение правила.
• Передача в эксплуатацию. Схема решения, регламент переобучения, панель контроля по доле оспариваний. Дальше — сопровождение: контроль смещения данных во времени и плановые пересборки.

Что передаём вместе с системой: состав поставки

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

• Настройки модели: значения порогов по каждому сценарию (явный фрод, злоупотребление правилами, «серийный» возврат), вклад признаков в решение, порядок переобучения на накопленных данных.
• Схема интеграции с учётной системой: какие сущности и события синхронизируются, режим обмена, поведение при недоступности внешней системы и правила повторной отправки.
• Матрица решений: для связки «уровень риска — сумма возврата — причина» прописано, где решение автоматическое, где нужна ручная проверка и кто владелец спорного случая.
• Регламент обработки спорных заявок: сроки реакции, порядок эскалации, фиксация итогового решения в учётной системе, еженедельный разбор ошибок модели.
• Мониторинг качества: набор метрик — доля ложных срабатываний, пропущенные случаи фрода, доля заявок, закрытых без оператора, — с порогами деградации и порядком оповещения.
• Документация и инструкции: описание логики решений на языке бизнеса, типовые обращения операторов, разбор частых ошибок.

Дополнительно отдаём исходные данные и сценарии проверки, чтобы качество модели можно было воспроизвести на вашей стороне, а не принимать на слово. Перед закрытием проекта проводим передачу знаний с командой поддержки и аналитиками — по этим материалам они разбирают реальные заявки и корректируют правила.

Результат внедрения: было и стало в цифрах

Что было до внедрения

Клиент — ритейлер с несколькими каналами продаж и потоком возвратов в несколько тысяч заявок в месяц. Правила возврата существовали, но применялись операторами вручную: часть заявок уходила на проверку «по ощущениям», одинаковые ситуации в разных сменах решались по-разному. На ручную проверку уходило 38% обращений, средний цикл решения занимал около 26 часов, а заявки, поданные вечером или в выходные, копились до утра понедельника.

Что изменили

Собрали признаки по каждой заявке: история клиента, поведение на сайте перед оформлением, состав и вес заказа, маршрут доставки, прошлые возвраты и их причины. На разметке уже принятых решений обучили модель градиентного бустинга на CatBoost — она даёт оценку риска, а политика разводит заявки по трём зонам: автоматическое одобрение, автоматический отказ и ручная проверка. Отдельно заложили правила эскалации: повторный возврат за короткий период, расхождение суммы или спорная категория товара уходят оператору независимо от оценки модели.

Каждое решение оператора возвращается в разметку. Модель переобучается по расписанию, качество контролируется на отложенной выборке — по доле ложных отказов и по полноте отлова спорных заявок, а не по одной общей точности.

Что стало

Ручная проверка сократилась с 38% до 9% заявок, среднее время решения — с 26 часов до 42 минут, доля автоматически закрытых обращений выросла с 61% до 91%. Ложные отказы, из-за которых клиент уходил к конкуренту, снизились в 2,4 раза: спорные случаи теперь не «проваливаются» в автоматику, а поднимаются на оператора с готовым контекстом по заявке.

Главный эффект — предсказуемость. Одинаковая ситуация получает одинаковое решение в любую смену, а оператор занимается действительно неоднозначными возвратами, а не разбором типовых обращений.

Чем прогноз возвратов отличается от правил на порогах?

Пороговые правила отвечают на вопрос «да или нет»: три возврата за месяц переводят клиента в ручную проверку. Решение воспроизводимо и объясняется одной строкой, поэтому его легко защитить перед службой контроля. Подвох в том, что порог подбирают под прошлое поведение покупателей и не пересчитывают, когда меняется ассортимент или сам сценарий возврата.

Прогноз вероятности решает ту же задачу иначе: модель оценивает риск для каждого заказа и выдаёт балл, по которому обращения ранжируются. Порог остаётся, но становится настройкой — его двигают под доступность ручной проверки, а не под жёсткое «виноват или нет».

Главное различие проявляется при смещении данных. Правила внешне не ломаются: они срабатывают, но всё чаще не на тех, кого нужно проверять, и заметно это только по ручной выборке. Модель деградирует измеримо — падает качество ранжирования, растёт доля пропусков, и повод для переобучения появляется заранее.

Объяснимость — плата за это: правило объясняется цитатой условия, для модели нужен слой пояснения, какие сигналы подняли балл. Держать это в порядке помогает жизненный цикл CRISP-DM — обновление описывается регламентом, а не разовым проектом. На практике подходы сочетают: жёсткие правила остаются для регуляторных требований и санкций, прогноз закрывает массовый поток.

Технические вопросы и типовые сомнения

Перед стартом инженеры и руководители направления задают одни и те же вопросы: хватит ли данных, насколько шумная разметка и что будет с качеством через месяц после запуска.

Мы не включаем сразу всю воронку: пилот на одном канале возвратов и одной категории товаров даёт базу сравнения с контрольной группой, а расширение начинается после устойчивого результата.

Насколько точная разметка нужна на входе?

Причины возврата часто указывают формально или со слов покупателя. Делаем аудит выборки, фиксируем правила разметки, считаем согласие между разметчиками, а спорные случаи выводим отдельно и не используем в обучении.

Сможем ли объяснить решение оператору и покупателю?

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

Что если качество просядет после запуска?

Следим за долей ложных срабатываний и пропусков на потоке и за сдвигом распределения признаков при смене ассортимента или условий доставки. При выходе метрик за границы схема откатывается на предыдущую версию правил.

Можно ли начать с одного канала?

Один канал и одна категория дают чистую картину: видно, как меняются доля возвратов, время обработки заявки и нагрузка на поддержку. Тиражирование на остальные каналы идёт по шаблону с проверенными порогами.

Обсудим задачу: что нужно с вашей стороны

Чтобы вернуться с оценкой и планом, а не с общими словами, нам нужна реальная картина возвратов: как заявки появляются, кто их обрабатывает и что вы считаете результатом. Ниже — то, что помогает стартовать без долгой переписки.

• Выгрузка истории заявок за 6–12 месяцев: причина возврата, идентификаторы заказа и товара, канал продажи, дата, статус, принят возврат или отклонён.
• Схема процесса: где заявка появляется, какие шаги проходит, на каком этапе сотрудник принимает решение вручную.
• Правила и ограничения: регламент возвратов, сроки подачи, категории товаров, которые вернуть нельзя, юридические рамки.
• Доступы и выгрузки: учётная система, служба поддержки, склад, платёжные данные — на чтение и в тестовом контуре этого достаточно.
• Известные случаи злоупотреблений и признаки, по которым вы находили их руками, — основа для разметки обучающей выборки.
• Критерии успеха: доля автоматических решений, точность флага подозрительной заявки, время обработки, доля необоснованных возвратов.
• Контактные лица: владелец процесса, аналитик, администратор систем — с кем уточнять детали и согласовывать проверки.

Опишите задачу и пришлите то, что уже есть, — вернёмся с оценкой сроков, планом работ и перечнем рисков. Данные можно собирать итеративно: сначала общая статистика, затем детальные выгрузки по спорным категориям.