Come gestire un modello di previsione "autolesionista"?

Stavo guardando una presentazione di uno specialista ML di un importante rivenditore, in cui avevano sviluppato un modello per prevedere eventi fuori stock.

Supponiamo per un momento che nel tempo il loro modello diventi molto preciso, non sarebbe in qualche modo "autolesionista"? Cioè, se il modello funziona davvero bene, allora saranno in grado di anticipare gli eventi esauriti ed evitarli, arrivando infine a un punto in cui hanno eventi scarsi o nulli. Ma in tal caso, non ci saranno abbastanza dati storici su cui eseguire il loro modello, o il loro modello verrà deragliato, perché gli stessi fattori causali utilizzati per indicare un evento di esaurimento non lo fanno più.

Quali sono le strategie per affrontare un simile scenario?

Inoltre, si potrebbe immaginare la situazione opposta: ad esempio un sistema di raccomandazione potrebbe diventare una "profezia che si autoavvera" con un aumento delle vendite di coppie di articoli guidate dall'output del sistema di raccomandazione, anche se i due articoli non sono proprio così relazionato.

Mi sembra che entrambi siano i risultati di una sorta di ciclo di feedback che si verifica tra l'output del predittore e le azioni che vengono eseguite sulla base di esso. Come si possono affrontare situazioni come questa?

Esistono due possibilità per cui un modello di rilevamento esaurito (OOS) potrebbe auto-deragliare:

1. La relazione tra input e OOS potrebbe cambiare nel tempo. Ad esempio, le promozioni potrebbero portare a una maggiore OOS (le vendite promozionali sono più difficili da prevedere rispetto alle vendite normali, in parte perché non solo l' aumento medio delle vendite, ma anche la varianza delle vendite e "più difficile da prevedere" si traduce spesso in OOS), ma il sistema e i suoi utenti potrebbero apprenderlo e disporre di risorse aggiuntive per promozioni. Dopo un po ', la relazione originale tra promozioni e OOS non regge più.

   Questo è spesso chiamato "cambio di modello" o simile . Puoi superarlo adattando il tuo modello. Il modo più comune è di ponderare gli input in modo diverso, dando un peso inferiore alle osservazioni più vecchie.

2. Anche se la relazione tra un predittore e OOS non cambia, la distribuzione del predittore potrebbe. Ad esempio, più giorni con zero vendite di una particolare unità di scorta (SKU) potrebbero segnalare un OOS - ma se il modello funziona bene, allora l'OOS potrebbe essere ridotto su tutta la linea e potrebbe semplicemente non esserci altrettante sequenze di zero vendite .

   I cambiamenti nella distribuzione di un predittore non dovrebbero essere un problema. Il tuo modello genererà semplicemente una probabilità inferiore di OOS.

Alla fine, probabilmente non dovrai preoccuparti troppo. Non ci sarà mai zero OOS. Si verificano meccanismi di feedback come quelli sopra, ma non funzioneranno fino a quando OOS non sarà completamente sradicato.

• Alcuni OOS in sospeso potrebbero non essere mediabili. "Ho una unità sullo scaffale e probabilmente dovrò affrontare una domanda per cinque nella prossima settimana, ma la prossima consegna è prevista solo per una settimana da oggi."
• Alcuni OOS saranno molto difficili da prevedere, anche se sono calcolabili, se fossero stati conosciuti in tempo. "Se avessimo saputo che avremmo lasciato cadere il pallet dal carrello elevatore e distrutto tutto il prodotto, ne avremmo ordinato un altro."
• I rivenditori comprendono che devono puntare a un livello di servizio elevato, ma che il 100% non è raggiungibile. Le persone entrano e acquistano tutto il tuo magazzino per determinati prodotti. Questo è difficile da prevedere (vedi sopra) e abbastanza raro che non vuoi riempire i tuoi scaffali nel caso ciò accada. Confronta la legge di Pareto: un livello di servizio dell'80% (o addirittura del 90%) è abbastanza facile da raggiungere, ma il 99,9% è molto più difficile. Alcuni OOS sono consentiti consapevolmente.
• Qualcosa di simile alla legge di Moore vale: più ML diventa alta, più le aspettative aumenteranno e più le persone più difficili daranno vita al modello. Mentre gli algoritmi di rilevamento (e previsione) di OOS migliorano, i rivenditori sono impegnati a rendere la nostra vita più difficile.
  • Ad esempio attraverso la proliferazione di varianti. È più facile rilevare OOS su quattro gusti di yogurt che su venti gusti diversi. Perché? Perché le persone non mangiano cinque volte più yogurt. Invece, la domanda totale pressoché invariata è ora distribuita su cinque volte il numero di SKU e ogni stock di SKU è un quinto più alto di prima. La coda lunga si sta espandendo e i segnali si stanno indebolendo.
  • O consentendo il checkout mobile utilizzando il proprio dispositivo. Ciò potrebbe ridurre le barriere psicologiche al taccheggio , quindi gli inventari di sistema saranno persino peggiori di quelli che sono già e, naturalmente, gli inventari di sistema sono probabilmente il miglior predittore di OOS, quindi se sono spenti, il modello peggiorerà.

Mi è capitato di lavorare nella previsione delle vendite al dettaglio da oltre dodici anni, quindi ho un po 'di idea su sviluppi come questo.

Potrei essere pessimista, ma penso che effetti molto simili siano in atto per altri casi d'uso ML rispetto al rilevamento OOS. O forse questo non è pessimismo: significa che i problemi probabilmente non saranno mai "risolti", quindi ci sarà ancora lavoro per noi anche tra decenni.

Se si utilizza un modello per supportare le decisioni relative all'intervento in un sistema, logicamente, il modello dovrebbe cercare di prevedere il risultato condizionato su un determinato intervento. Quindi separatamente, è necessario ottimizzare per scegliere l'intervento con il miglior risultato atteso. Non stai cercando di prevedere il tuo intervento.

In questo caso, il modello potrebbe prevedere la domanda (la variabile che non controlli direttamente) e questo, in combinazione con la scelta dello stock, comporterebbe un evento esaurito o meno. Il modello dovrebbe continuare a essere "ricompensato" per prevedere correttamente la domanda poiché questo è il suo lavoro. Out-of-magazzino eventi dipenderà da questa variabile con la vostra scelta calza.

Presumibilmente puoi tenere traccia degli eventi di riassortimento. Quindi è solo una questione di aritmetica capire quando lo stock sarebbe esaurito se il modello non fosse utilizzato per rifornire l'inventario.

Ciò presuppone che qualsiasi livello di scorte positivo sia indipendente dal livello delle vendite. Un commentatore afferma che questo assunto non vale nella realtà. Non lo so in entrambi i modi - non lavoro su set di dati al dettaglio. Ma come una semplificazione, il mio approccio proposto consente di fare inferenze usando il ragionamento controfattuale; se questa semplificazione sia troppo irrealistica per dare una visione significativa dipende da te.

Il tuo scenario somiglia molto alla critica di Lucas in economia. Nell'apprendimento automatico, questo si chiama " spostamento del set di dati ".

Puoi superarlo, come dice @Sycorax, modellandolo esplicitamente.

Una cosa da ricordare è che ML è un obiettivo strumentale. In definitiva, non vogliamo prevedere eventi fuori stock, vogliamo prevenire eventi fuori stock. La previsione di eventi esauriti è semplicemente un mezzo a tal fine. Per quanto riguarda gli errori di tipo II, questo non è un problema. O continuiamo ad avere OOSE, nel qual caso abbiamo i dati per addestrare il nostro modello, oppure no, in cui il problema che il modello è stato creato per risolvere è stato risolto. Ciò che può essere un problema è errori di tipo I. È facile cadere in una pattuglia dell'orsoerrore, in cui hai un sistema X creato per impedire Y, non vedi Y, quindi concludi che X impedisce Y e qualsiasi tentativo di arrestare X viene respinto sulla base "Ma sta facendo un ottimo lavoro impedendo Y! " Le organizzazioni possono essere bloccate in programmi costosi perché nessuno vuole rischiare che Y ritorni, ed è difficile scoprire se X è davvero necessario senza consentire tale possibilità.

Diventa quindi un compromesso di quanto sei disposto a impegnarti occasionalmente (secondo il tuo modello) in un comportamento non ottimale per ottenere un gruppo di controllo. Fa parte di qualsiasi esplorazione attiva: se hai un farmaco che ritieni efficace, devi avere un gruppo di controllo che non sta ottenendo il farmaco per confermare che è effettivamente efficace.