Una recensione opinabile di Deep Inventory Management

Joannes Vermorel

Alla fine del 2022, un team di Amazon ha pubblicato una ricerca correlata alla supply chain intitolata Deep Inventory Management¹. Questo articolo presenta una tecnica di ottimizzazione delle scorte (denominata DIM di seguito) che utilizza sia l’apprendimento per rinforzo che l’apprendimento profondo. L’articolo afferma che la tecnica è stata utilizzata con successo su oltre 10.000 SKU in ambienti reali. Questo articolo è interessante sotto diversi aspetti ed è in qualche modo simile a ciò che Lokad ha fatto dal 2018. Di seguito, discuto ciò che vedo come i meriti e i difetti della tecnica DIM dal punto di vista specifico di Lokad, poiché abbiamo esplorato strade simili negli ultimi anni.

La funzione obiettivo e i vincoli (p.27, Appendice A), da "Deep Inventory Management", Nov. 2022

La mia prima osservazione è che questo articolo suona vero e quindi sono incline a supportare le sue conclusioni. L’impostazione generale risuona molto con i miei esperimenti e le mie osservazioni personali. Infatti, la maggior parte degli articoli pubblicati sulla supply chain sono solo falsi - per una ragione o per l’altra. Le supply chain affrontano un grave caso di corruzione epistemica,² e il sospetto profondo dovrebbe essere la posizione predefinita quando si affronta un presunto “miglior” modo di affrontare un problema di supply chain.

Il contributo più significativo della tecnica DIM è quello di bypassare completamente la fase di previsione e passare direttamente all’ottimizzazione delle scorte. Il modo classico di affrontare l’ottimizzazione delle scorte consiste nella decomposizione del problema in due fasi. Prima, prevedere la domanda; secondo, ottimizzare la decisione sulle scorte. Lokad segue ancora questo processo a due fasi (per buoni motivi, vedi l’azione ricompensa ³). Tuttavia, DIM unisce i due attraverso un approccio denominato simulatori differenziabili.

Unire le fasi di “apprendimento” e “ottimizzazione” è un percorso promettente, non solo per la supply chain, ma per l’informatica nel suo complesso. Negli ultimi due decenni, c’è stata una graduale convergenza tra apprendimento e ottimizzazione dal punto di vista algoritmico. Di fatto, la tecnica primaria di apprendimento utilizzata da Lokad ha un algoritmo di ottimizzazione al suo interno. Al contrario, una recente scoperta (non pubblicata) di Lokad sull’ottimizzazione stocastica si basa su un algoritmo di apprendimento.

Immagino un futuro in cui la previsione autonoma sia considerata una pratica obsoleta che è stata completamente sostituita da nuove tecniche; tecniche che fondono completamente le prospettive di “apprendimento” e “ottimizzazione”. Lokad ha già percorso questa strada da tempo. Infatti, da quando siamo passati alle previsioni probabilistiche nel 2015, l’esportazione delle previsioni grezze da Lokad è stata considerata impraticabile, quindi il processo è stato principalmente semplificato a una singola fase dal punto di vista del cliente. Tuttavia, il processo a due fasi esiste ancora all’interno di Lokad perché ci sono alcuni problemi profondi, ancora irrisolti, per permettere la loro unificazione.

Ora, discutiamo delle mie opinioni sulle carenze della tecnica DIM.

La mia prima critica è che l’uso dell’apprendimento profondo da parte di DIM è deludente.

Dalla sezione Featurization (Appendice B), è chiaro che ciò che il modello “profondo” sta imparando prima di tutto è prevedere la futura domanda di lead - ovvero, la domanda variabile integrata nel tempo di lead variabile.

La stima (implicitamente probabilistica) della domanda di lead non è un problema “difficile” che richiede l’apprendimento profondo, almeno non nelle impostazioni presentate da questo team di Amazon. Infatti, scommetto che l’intero miglioramento empirico è il risultato di una migliore valutazione della domanda di lead. Inoltre, scommetto anche che una valutazione comparabile, se non migliore, della domanda di lead può essere ottenuta con un modello probabilistico parametrico di base, come è stato fatto nella competizione M5⁴. Questo eliminerebbe completamente l’apprendimento profondo dall’immagine, mantenendo solo la parte “superficiale” della soluzione di programmazione differenziabile.

Se mettiamo da parte la stima della domanda di lead, DIM ha poco da offrire. Infatti, nelle impostazioni della supply chain come presentate nel paper, tutti gli SKU vengono elaborati in quasi-isolamento con vincoli aziendali eccessivamente lievi - ovvero limiti sul volume totale, sul capitale totale e sulle unità totali. Affrontare questi limiti superiori può essere fatto abbastanza facilmente, ordinando le unità da riordinare⁵ in base al loro ritorno in dollari su dollari decrescente - o eventualmente al loro ritorno in dollari per unità - se la capacità dello storage caotico utilizzato da Amazon è il vero collo di bottiglia.

Per quanto riguarda i vincoli, i limiti aziendali sono vincoli banali che non richiedono tecniche sofisticate per essere affrontati. L’apprendimento profondo sarebbe davvero brillante se gli autori fossero in grado di affrontare vincoli spinosi che abbondano nelle supply chain. Ad esempio, i quantitativi minimi di ordine (MOQ) definiti a livello di fornitore, i carichi completi di camion, le fasce di prezzo dei fornitori, i prodotti deperibili, ecc., sono preoccupazioni che non possono essere affrontate attraverso tecniche naive come la prioritizzazione che ho menzionato in precedenza. Per tali vincoli spinosi, l’apprendimento profondo sarebbe davvero eccellente come un ottimizzatore stocastico versatile - a condizione che qualcuno riesca a farlo. Tuttavia, DIM evita completamente tali preoccupazioni ed è del tutto chiaro se DIM potrebbe essere esteso per affrontare tali problemi. La mia opinione è che non possa.

A merito degli autori, i “vincoli tra prodotti” sono menzionati nell’ultima riga della loro conclusione come una “strada di ricerca eccitante”. Sebbene sia d’accordo con il sentimento, è un eufemismo. Non supportare quei vincoli onnipresenti della supply chain è un ostacolo immediato. I professionisti della supply chain tornerebbero alle loro tabelle in meno di un mese. Approssimativamente corretto è meglio che esattamente sbagliato.

Inoltre, abbiamo un intero problema con le azioni a valori reali, ovvero le quantità di ordine frazionarie, prodotte da DIM - vedere l’equazione (1) e l’Assunzione 1 (pagina 12). Infatti, nella supply chain, non puoi riordinare 0,123 unità, è o 0 o 1. Eppure, gli autori evitano completamente l’intera questione. La tecnica DIM produce quantità frazionarie e richiede che la funzione di ricompensa sia “ben comportata”. In pratica, è chiaro che questo approccio non funzionerà bene se la funzione di ricompensa non è strettamente monotona rispetto alla quantità ordinata.

Pertanto, ci troviamo con una caratteristica meno desiderabile (ordini frazionari) e un requisito meno desiderabile (monotonia della funzione di ricompensa), la combinazione dei due è la base del simulatore differenziabile proposto. Tuttavia, la supply chain è governata dalla legge dei piccoli numeri⁶. I problemi moderni di inventario sono dominati dalle loro caratteristiche discrete. Almeno questo aspetto avrebbe dovuto essere evidenziato dagli autori come una grave limitazione di DIM - qualcosa da perseguire in ricerche successive.

Combinare i gradienti e le politiche discrete è un problema fondamentale per l’ottimizzazione stocastica, non solo per i simulatori differenziabili proposti. Infatti, la discesa del gradiente stocastico (SGD) opera su parametri a valori reali e, come tale, non è ovvio come ottimizzare le politiche che governano decisioni fondamentalmente discrete.

Operare su spazi fondamentalmente discreti attraverso processi guidati dal gradiente può certamente essere fatto, come brillantemente dimostrato dai LLM (large language models), ma richiede una serie di trucchi. Fino a quando non verranno scoperti trucchi equivalenti per la classe di situazioni affrontate dalle supply chain, i simulatori differenziabili sono un’idea promettente, ma non una soluzione pronta per la produzione.

La mia seconda critica è che ci sono tonnellate di casi limite che non vengono nemmeno menzionati dagli autori di DIM.

In particolare, gli autori rimangono estremamente vaghi su come hanno selezionato (…cherry-picked) i loro 10.000 SKU. Infatti, mentre stavo conducendo esperimenti presso Lokad nel 2018 e 2019, ho utilizzato strategie di caratterizzazione stranamente simili (Appendice B) per modelli di deep learning utilizzati da Lokad.

Da quegli esperimenti, propongo che:

• I nuovi prodotti e quelli recenti non funzioneranno bene, poiché la ridimensionamento suggerito dalle equazioni (13), (30) e (31) si comporterà in modo erratico quando i dati storici sono troppo scarsi.
• I prodotti a lenta rotazione si imbatteranno in rimedi impropri per le loro passate rotture di stock, poiché la tecnica assume che esista una domanda corretta “ragionevole” (non il caso per i prodotti a lenta rotazione).
• I prodotti intermittenti (non pubblicati o non disponibili per lunghi periodi, come 2+ mesi) si imbatteranno anche nella presunta domanda corretta.
• Gli SKU dei rivali, dove i clienti scelgono aggressivamente il prezzo più basso, saranno sottovalutati, poiché il modello non può riflettere l’impatto drastico quando gli SKU superano (in termini di prezzo) un concorrente.

Questi casi limite sono, infatti, la maggior parte della sfida della supply chain. In un articolo, è tentante selezionare gli SKU che si comportano bene: non troppo recenti, non troppo lenti, non troppo erratici, non intermittenti, ecc. Tuttavia, se dobbiamo ricorrere a tecniche sofisticate, è un po’ inutile concentrarsi sugli SKU facili. Sebbene si possano ottenere miglioramenti economici su quegli SKU, il guadagno assoluto è minore (modesto al massimo) - proprio perché quegli SKU si comportano bene comunque. La maggior parte delle inefficienze della supply chain si trova agli estremi, non al centro.

Affrontare frontalmente quegli SKU mal comportati è esattamente dove ci si aspetterebbe che il deep learning venga in soccorso. Purtroppo, DIM fa esattamente il contrario e affronta gli SKU che si comportano bene e che possono essere affrontati con tecniche molto meno sofisticate con pochi o nessun inconveniente.

La mia terza critica è che DIM ha una configurazione tecnica piuttosto complicata.

Questo è probabilmente uno dei problemi più sottovalutati nella comunità della scienza dei dati. La complessità è nemica dell’affidabilità e dell’efficienza. Sebbene il deep learning sia fantastico, poche aziende possono permettersi gli ingegneri necessari per gestire una configurazione come DIM. Questo non è come ChatGPT, dove tutte le stranezze dell’ingegneria sono mutualizzate su tutta la base clienti del fornitore di software. Qui, considerando la quantità di dettagli che vanno in DIM, ogni azienda cliente deve sostenere i costi operativi completi associati alla propria istanza della soluzione.

Dal lato hardware, abbiamo una macchina virtuale EC2 p3.16xlarge[^termini-comuni], attualmente al prezzo di 17.000 USD al mese su AWS. Per 10.000 SKU, è… ripido.

Lokad ha molti clienti che gestiscono individualmente milioni di SKU, e la maggior parte di loro ha un fatturato inferiore a 1 miliardo di USD. Sebbene potrebbe essere possibile ridimensionare leggermente questa macchina virtuale e spegnerla quando non in uso, da Lokad abbiamo imparato che queste opzioni raramente sono adatte per la produzione.

Ad esempio, le piattaforme di cloud computing affrontano anche loro delle carenze: a volte, la macchina virtuale che dovrebbe essere disponibile su richiesta impiega ore per essere avviata. Inoltre, non assumere mai che quei modelli possano essere semplicemente “preallenati”, ci sarà un giorno - come il prossimo martedì - in cui l’intero sistema dovrà essere riaddestrato da zero per ragioni imperative[^urgenza]. Inoltre, una configurazione di produzione non richiede solo ridondanza, ma anche ambienti aggiuntivi (test, pre-produzione, ecc.).

Dal lato software, la necessità di qualcosa come il Plasma Object Store è l’archetipo di quelle complicazioni accidentali che derivano dal deep learning. Consideriamo che il dataset di addestramento - con 80.000 SKU aggregati settimanalmente per soli 104 settimane - dovrebbe pesare meno di 100 MB (se i dati sono rappresentati correttamente).

Mentre gli autori di DIM rimangono abilmente vaghi, facendo riferimento a una “grande quantità di dati” (pagina 32), è ovvio che la strategia di featurization gonfia l’originale dimensione dei dati di 3 ordini di grandezza (1000 volte, circa). Tieni presente che l’EC2 p3.16xlarge dispone di ben 488 GB di RAM, che dovrebbero essere sufficienti per elaborare un dataset di 100 MB (circa 100 GB dopo che l’inflazione è applicata)… Beh, ci siamo passati, abbiamo fatto questo e abbiamo affrontato lo stesso problema.

Ad esempio, un dataset di catena di approvvigionamento di dimensioni realistiche di solito supera 1 terabyte dopo l’inflazione dei dati - come richiesto dall’approccio DIM. In questo caso, un tipico data scientist non può riprodurre un bug localmente perché la sua workstation dispone solo di 64 GB di RAM. Oltre a ciò, c’è anche la questione della frontiera Python/Plasma dove le cose possono andare storte.

Oltre alle critiche principali sopra, ci sono preoccupazioni secondarie. Ad esempio, la programmazione dinamica[^dinamica] - menzionata nell’introduzione e nella conclusione come il punto di riferimento e il contendente di DIM - è solo un povero punto di riferimento. La programmazione dinamica è una tecnica antica (risalente agli anni ‘50) e non riflette lo stato dell’arte per quanto riguarda l’ottimizzazione e l’apprendimento combinati.

Va detto che la letteratura sulla catena di approvvigionamento è carente su questo fronte, ma ciò significa che gli autori devono trovare punti di riferimento rilevanti al di fuori del loro campo di studio. Ad esempio, AlphaGo Zero⁷ è un punto di riferimento intellettuale molto migliore quando si tratta di un’applicazione notevole del deep learning per scopi di ottimizzazione - certamente se confrontato con le tecniche di programmazione dinamica che hanno quasi 80 anni.

In conclusione, contrariamente a quanto potrebbe suggerire la mia critica, è un articolo migliore della maggior parte e assolutamente degno di essere criticato. La programmazione differenziabile è uno strumento eccellente per le catene di approvvigionamento. Lokad lo utilizza da anni, ma non abbiamo esaurito ciò che può essere fatto con questo paradigma programmabile.

C’è di più da esplorare, come dimostra DIM. I simulatori differenziabili sono un’idea interessante, e ci si sente meno soli quando i giganti della tecnologia come Amazon mettono in discussione i dogmi fondamentali della teoria mainstream della catena di approvvigionamento - proprio come facciamo noi. Da Lokad, abbiamo il progetto di combinare in qualche modo montecarlo e autodiff⁸ in modi che si adattino bene a questi simulatori differenziabili.

Restate sintonizzati!