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

AI управління поверненнями: де ламається процес

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

Поки поведінка покупців передбачувана, схема тримається; у разі зміни асортименту або сезонного попиту пороги перестають відповідати реальності.

Жорсткі правила відбору дають одразу два перекоси. Частину заявок вони скеровують на ручну обробку, хоча ризик там мінімальний, — і черга зростає. Іншу частину пропускають автоматично, хоча з історії клієнта давно видно ознаки зловживання.

В обидва боки це втрати на поверненнях: оплачена зворотна логістика, заморожений товар, повторне пакування.

Ручна обробка заявок стає вузьким місцем процесу. Рішення залежить від зміни, від того, скільки ознак оператор встигає переглянути й чи є в нього контекст щодо клієнта.

У разі зростання обсягу заявок час розгляду збільшується швидше, ніж штат, а логіку відмови потім не відтворити — якість рішень різниться між змінами.

Окрема проблема — рішення ухвалюються без історії клієнта. Один покупець роками повертає товар акуратно, інший збирає заявки за однією схемою на різних акаунтах, а порогове правило бачить лише поточну заявку.

Прогноз повернень спирається на поведінку: модель оцінює ризик за десятками факторів і надає пріоритет заявкам, де перевірка справді потрібна.

Далі розбираємо, як це закривається: куди вбудовується прогноз, що виходить з ручної обробки й як жорсткі пороги замінюються адаптивними.

Що дає модель: швидкість, точність, зниження втрат

Модель оцінює заявку в момент оформлення: історія клієнта, склад замовлення, поведінка на сайті, дані про доставку — на виході ймовірність того, що повернення обґрунтоване.

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

Точність прогнозу й повнота відбору заявок тягнуть у різні боки, і вибирати між ними доводиться усвідомлено.

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

Підсумкову якість фіксуємо на відкладеній вибірці й на періоді, якого модель не бачила під час навчання.

Зниження втрат іде з двох боків: частка ручних перевірок падає в рази — типові повернення з чистою історією обробляються без оператора, а час обробки заявки скорочується з годин до секунд на автоматичному маршруті.

Окремо виходить клас відмов, який регламент не ловить: серійні заявки з однієї адреси, підміна товару, повернення за замовленнями, оформленими на чужі дані. Модель бачить зв’язки між заявками, а не лише саму заявку.

Рішення має бути зрозумілим: на кожну оцінку будується розбір внеску ознак через SHAP, щоб оператор бачив причину відмови, а не просто позначку «ризик».

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

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

Режим обробки повернення визначає, де ухвалюється рішення — у явному правилі чи в моделі.

Поріг за сумою або частотою повернень читається очима, пояснюється службі підтримки одним рядком і набирає чинності одразу після налаштування, але будь-який зсув у поведінці покупців ламає межу, а список винятків зростає швидше, ніж його встигають переглядати.

Навчена модель ловить поєднання ознак, які в правило не виписати, зате потребує накопиченої історії та постійного контролю якості розмітки.

Вибір між цими режимами визначають три речі: скільки у вас уже накопичено розмічених повернень, чи потрібна зрозумілість кожного спрацювання й як часто змінюється асортимент.

Гібридний підхід найчастіше й стає робочою точкою: правило тримає явні стоп-сигнали, модель ранжує решту й віддає на ручну перевірку лише спірні випадки.

Навчання на власних даних вмикаємо після того, як набрано першу розмітку — тоді якість зростає на ваших сценаріях, а не на усереднених.

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

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

Дані та схема

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

Перевірка та запуск

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

Що передаємо разом із системою: склад постачання

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

Пакет збирається так, щоб через місяць після запуску ви могли змінювати пороги, розбирати спірні заявки й бачити, чи не деградувала модель.

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

Додатково віддаємо вихідні дані та сценарії перевірки, щоб якість моделі можна було відтворити на вашому боці, а не приймати на слово.

Перед закриттям проєкту проводимо передачу знань із командою підтримки та аналітиками — за цими матеріалами вони розбирають реальні заявки й коригують правила.

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

Що було до впровадження

Клієнт — рітейлер із кількома каналами продажів і потоком повернень у кілька тисяч заявок на місяць. Правила повернення існували, але застосовувалися операторами вручну: частина заявок ішла на перевірку «за відчуттями», однакові ситуації в різних змінах вирішувалися по-різному.

На ручну перевірку йшло 38% звернень, середній цикл рішення займав близько 26 годин, а заявки, подані ввечері або у вихідні, накопичувалися до ранку понеділка.

Що змінили

Зібрали ознаки за кожною заявкою: історія клієнта, поведінка на сайті перед оформленням, склад і вага замовлення, маршрут доставки, минулі повернення та їхні причини.

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

Окремо заклали правила ескалації: повторне повернення за короткий період, розбіжність суми або спірна категорія товару йдуть оператору незалежно від оцінки моделі.

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

Що стало

Ручна перевірка скоротилася з 38% до 9% заявок, середній час рішення — з 26 годин до 42 хвилин, частка автоматично закритих звернень зросла з 61% до 91%.

Хибні відмови, через які клієнт ішов до конкурента, знизилися в 2,4 раза: спірні випадки тепер не «провалюються» в автоматику, а піднімаються на оператора з готовим контекстом за заявкою.

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

Чим прогноз повернень відрізняється від правил на порогах?

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

Підступ у тому, що поріг добирають під минулу поведінку покупців і не перераховують, коли змінюється асортимент або сам сценарій повернення.

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

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

Модель деградує вимірно — падає якість ранжування, зростає частка пропусків, і привід для перенавчання з’являється заздалегідь.

Пояснюваність — плата за це: правило пояснюється цитатою умови, для моделі потрібен шар пояснення, які сигнали підняли бал. Тримати це в порядку допомагає життєвий цикл CRISP-DM — оновлення описується регламентом, а не разовим проєктом.

На практиці підходи поєднують: жорсткі правила залишаються для регуляторних вимог і санкцій, прогноз закриває масовий потік.

Технічні питання та типові сумніви

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

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

Наскільки точна розмітка потрібна на вході?

Причини повернення часто зазначають формально або зі слів покупця. Робимо аудит вибірки, фіксуємо правила розмітки, рахуємо згоду між розмітниками, а спірні випадки виводимо окремо й не використовуємо в навчанні.

Чи зможемо пояснити рішення оператору й покупцю?

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

Що якщо якість знизиться після запуску?

Стежимо за часткою хибних спрацювань і пропусків на потоці та за зсувом розподілу ознак у разі зміни асортименту або умов доставки. Коли метрики виходять за межі, схема відкочується на попередню версію правил.

Чи можна почати з одного каналу?

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

Обговоримо задачу: що потрібно з вашого боку

Щоб повернутися з оцінкою та планом, а не із загальними словами, нам потрібна реальна картина повернень: як заявки з’являються, хто їх обробляє і що ви вважаєте результатом. Нижче — те, що допомагає стартувати без довгого листування.

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

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