Як впоратися з моделлю прогнозування, яка перемогла себе?

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

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

Які стратегії подолання такого сценарію?

Крім того, можна передбачити протилежну ситуацію: Наприклад, система рекомендацій може стати "самореалізуючимся пророцтвом" зі збільшенням продажів пар елементів, що керуються результатами системи рекомендації, навіть якщо ці два пункти насправді не такі пов'язані.

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

Є дві можливості, за допомогою яких модель виявлення поза запасом (OOS) може самостійно зірватися:

1. Зв'язок між входами та OOS може змінюватися з часом. Наприклад, рекламні акції можуть призвести до підвищення OOS (рекламні продажі важче передбачити, ніж звичайні продажі, частково тому, що не тільки середній приріст продажів, але і дисперсія продажів, а "складніше передбачити" часто перекладається в OOS), але система та її користувачі можуть цього навчитися та закласти додаткові запаси для просування. Через деякий час оригінальний зв’язок між рекламними акціями та OOS вже не тримається.

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

2. Навіть якщо взаємозв'язок між предиктором та OOS не зміниться, розподіл прогноктора може бути. Наприклад, кілька днів з нульовими продажами певної одиниці зберігання запасів (SKU) можуть сигналізувати про OOS - але якщо модель працює добре, то OOS може бути зменшений у всій смузі, і може просто не бути стільки послідовностей нульових продажів .

   Зміни в розподілі предиктора не повинні бути проблемою. Ваша модель просто виведе меншу ймовірність OOS.

Зрештою, вам, мабуть, не потрібно переживати багато. Ніколи не буде нульової ООС. Механізми зворотного зв’язку, як описані вище, є, але вони не працюватимуть до повного усунення OOS.

• Деякі очікувані OOS можуть просто не відвернути. "У мене є одна одиниця на полиці, і, ймовірно, виникне попит на п'ять протягом найближчого тижня, але наступна доставка відбудеться лише через тиждень з сьогоднішнього дня".
• Деякі OOS будуть дуже важко передбачити, навіть якщо вони є предотвратимими, якби вони були відомі під час. "Якби ми знали, що ми скинемо піддон з навантажувача і знищимо весь товар, ми замовили б ще один".
• Роздрібні торговці розуміють, що їм потрібно прагнути до високого рівня обслуговування, але 100% цього не можна досягти. Люди заходять і купують весь ваш запас певних продуктів. Це важко передбачити (див. Вище) і досить рідко, що ви не хочете заповнювати свої полки на випадок, якщо це може статися. Порівняйте закон Парето: рівень обслуговування 80% (або навіть 90%) досягти досить просто, але 99,9% набагато складніше. Деякі ООС свідомо дозволені.
• Щось схоже на закон Мура : чим краще стає ML, тим більше очікувань зростатиме, і чим важче люди зроблять життя для моделі. Хоча алгоритми виявлення (та прогнозування) OOS вдосконалюються, роздрібні торговці зайняті, щоб ускладнити наше життя.
  • Наприклад, шляхом поширення варіантів. Простіше виявити ООС на чотирьох смаках йогурту, ніж на двадцяти різних ароматах. Чому? Тому що люди не їдять п'ять разів більше йогурту. Натомість, майже незмінний загальний попит зараз розподіляється у п’ять разів більше ОКУ, а запаси кожного SKU на п'яту частину вище, ніж раніше. Довгий хвіст розширюється, а сигнали слабшають.
  • Або дозволити замовлення мобільного телефону за допомогою власного пристрою. Це може значно знизити психологічні бар'єри для крадіжок , тому системні запаси стануть ще гіршими, ніж вони є , і, звичайно, системні запаси, мабуть, є найкращим прогнозувачем для ООС, тому, якщо вони вимкнуться, модель погіршиться.

Я, мабуть, працюю над прогнозуванням роздрібних продажів вже більше дванадцяти років, тому я маю трохи уявлення про подібні розробки.

Я, можливо, песимістичний, але, думаю, дуже подібні ефекти діють для інших випадків використання ML, ніж виявлення OOS. А може, це не песимізм: це означає, що проблеми, ймовірно, ніколи не будуть "вирішені", тому робота буде для нас ще десятиліттями відтепер.

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

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

Імовірно, ви можете відслідковувати, коли відбуватимуться події з відновленням. Тоді це лише питання арифметики, щоб розібратися, коли запас буде виснажений, якби модель не використовувалася для поповнення запасів.

Це передбачає, що будь-який позитивний рівень запасів не залежить від рівня продажів. Коментолог каже, що це припущення не відповідає дійсності. Я не знаю жодного способу - я не працюю над наборами даних для роздрібної торгівлі. Але в якості спрощення запропонований нами підхід дозволяє робити висновки, використовуючи контрфактичні міркування; незалежно від того, чи є це спрощення надто нереальним, щоб дати змістовне розуміння.

Ваш сценарій дуже схожий на критику Лукаса в економіці. У машинному навчанні це називається " зсувом набору даних ".

Ви можете подолати це, як каже @Sycorax, чітко моделюючи його.

Варто пам’ятати, що ML - це інструментальна мета. Зрештою, ми не хочемо прогнозувати події на складі, ми хочемо запобігати подій, що не є на складі. Прогнозування подій на акціях - це просто засіб для досягнення цієї мети. Що стосується помилок типу II, це не проблема. Або ми продовжуємо мати OOSE, і в цьому випадку ми маємо дані для навчання нашої моделі, або ми не маємо цього, коли проблема, з якою була створена модель для вирішення. Що може бути проблемою - це помилки типу I. Легко потрапити в ведмежий патрульпомилковість, де у вас є система X, яка побудована для запобігання Y, ви не бачите Y, тому ви робите висновок, що X перешкоджає Y, а будь-які спроби закрити X відхиляються на основі "Але це робить дуже гарну роботу запобігання Y! " Організації можна зафіксувати в дорогих програмах, тому що ніхто не хоче ризикувати, що Y повернеться, і важко з’ясувати, чи справді потрібен X, не допускаючи такої можливості.

Тоді це стає компромісом того, скільки ви готові час від часу брати участь (відповідно до вашої моделі) неоптимальною поведінкою, щоб отримати контрольну групу. Це частина будь-якого активного дослідження: якщо у вас є препарат, який, на вашу думку, є ефективним, ви повинні мати контрольну групу, яка не отримує препарат, щоб підтвердити, що він насправді ефективний.