Una recensione schietta 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 dell’inventario (indicata in seguito come DIM) che include sia il reinforcement learning che deep learning. Il paper afferma che la tecnica è stata utilizzata con successo per oltre 10.000 SKUs in contesti reali. Questo articolo è interessante sotto vari aspetti, e è in qualche modo simile a ciò che Lokad fa dal 2018. Di seguito discuto ciò che considero i meriti e i demeriti della tecnica DIM dal punto di vista specifico di Lokad, dato che abbiamo esplorato sentieri 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 risulta veritiero, e sono quindi incline a supportarne i risultati. L’impostazione complessiva risuona fortemente con i miei esperimenti e osservazioni personali. In effetti, la maggior parte degli articoli pubblicati sulla supply chain sono semplicemente una fandonia – per una ragione o per l’altra. Le supply chain affrontano un caso piuttosto grave di corruzione epistemica,² e un profondo scetticismo dovrebbe essere la posizione di default quando ci si confronta con un presunto modo “migliore” di affrontare un supply chain problem.

Il contributo più notevole della tecnica DIM è quello di bypassare completamente la fase di previsione e passare direttamente all’ottimizzazione dell’inventario. Il metodo classico per affrontare l’ottimizzazione dell’inventario consiste nello scomporre il problema in due fasi. Primo, prevedere la domanda; secondo, ottimizzare la decisione sull’inventario. Lokad segue ancora questo processo a fasi (per buone ragioni, vedi il action reward ³). Tuttavia, DIM unisce le due fasi mediante un approccio definito differentiable simulators.

Unire le fasi di “learning” e “optimization” è una strada promettente, non solo per supply chain, ma per l’informatica nel suo complesso. Negli ultimi due decenni, c’è stata una graduale convergenza tra learning e optimization da una prospettiva algoritmica. Infatti, la principale tecnica di learning utilizzata da Lokad ha un algoritmo di optimization al suo nucleo. Al contrario, una recente svolta (non pubblicata) di Lokad sull’ottimizzazione stocastica ruota attorno a un algoritmo di learning.

Immagino un futuro in cui la previsione autonoma viene considerata una pratica obsoleta, completamente superata da nuove tecniche; tecniche che fondono interamente le prospettive di “learning” e “optimization”. Lokad sta già percorrendo questa strada da tempo. Infatti, da quando siamo passati alle previsioni probabilistiche nel 2015, esportare le previsioni grezze da Lokad è stato considerato impraticabile, riducendo quindi il processo principalmente a una fase unica dal punto di vista del cliente. Tuttavia, il processo in due fasi esiste ancora all’interno di Lokad perché ci sono alcuni problemi profondi, ancora irrisolti, per permettere la unificazione.

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

La mia prima critica è che l’uso del deep learning da parte di DIM è deludente.

Dalla sezione Featurization (Appendice B) è chiaro che ciò che il modello “deep” sta apprendendo, prima di tutto, è prevedere la futura domanda nel lead time – cioè, la domanda variabile integrata sul lead time variabile.

La stima (implicita probabilistica) della domanda nel lead time non è un problema “difficile” che richieda il deep learning, almeno non nelle condizioni presentate da questo team di Amazon. Infatti, scommetto che l’intero miglioramento empirico sia la conseguenza di una valutazione migliore della domanda nel lead time. Inoltre, scommetterei anche che una valutazione comparabile, se non migliore, della domanda nel lead time possa essere ottenuta con un modello probabilistico parametrico di base, come fatto nella competizione M5⁴. Ciò eliminerebbe completamente il deep learning, mantenendo solo la parte “shallow” di differentiable programming della soluzione.

Se mettiamo da parte la stima della domanda nel lead time, DIM offre poco. Infatti, nelle impostazioni della supply chain presentate nel paper, tutti gli SKUs sono trattati in quasi isolamento con vincoli aziendali eccessivamente lievi – vale a dire 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 ai loro ritorni decrescenti dollaro su dollaro – o possibilmente i loro ritorni dollaro su unità – se la capacità dello stoccaggio caotico utilizzato da Amazon è il vero collo di bottiglia.

Per quanto riguarda i vincoli, i limiti a livello aziendale sono vincoli banali che non richiedono tecniche sofisticate per essere affrontati. Il deep learning risalterebbe realmente se gli autori fossero in grado di affrontare vincoli ardui che abbondano nelle supply chain. Ad esempio, MOQs (quantitativi minimi d’ordine) definiti a livello del fornitore, carichi completi di truck, sconti per quantità da parte del fornitore, prodotti deperibili, ecc., sono problematiche che non possono essere affrontate con tecniche naive come la prioritizzazione che ho menzionato sopra. Per tali vincoli complessi, il deep learning eccellerebbe davvero come ottimizzatore stocastico versatile – a patto che qualcuno riesca a farlo. Tuttavia, DIM evita completamente tali problematiche ed è del tutto poco chiaro se DIM possa essere esteso per affrontare tali questioni. La mia opinione è che non possa.

A credito degli autori, i cross-product constraints sono menzionati nell’ultima riga della loro conclusione come un appassionante percorso di ricerca. Pur essendo d’accordo con il sentimento, è un eufemismo. Non supportare quei vincoli ubiqui nelle supply chain è un ostacolo immediato. I professionisti della supply chain tornerebbero ai loro fogli di calcolo in meno di un mese. Approssimativamente corretto è meglio che esattamente sbagliato.

Inoltre, abbiamo un vero e proprio groviglio di problemi con le azioni a valori reali, cioè quantità d’ordine frazionarie, come prodotto da DIM – vedi l’equazione (1) e l’Assunzione 1 (pagina 12). Infatti, nella supply chain non si può riordinare 0.123 unità, o si ordina 0 oppure 1. Eppure, gli autori eludono completamente il problema. La tecnica DIM produce quantità frazionarie e richiede che la funzione reward sia “ben comportata”. In pratica, è chiaro che questo approccio non funzionerà bene se la funzione reward non è strettamente monotona rispetto alla quantità ordinata.

Così, ci troviamo ad avere una caratteristica poco desiderabile (ordini frazionari) e un requisito altrettanto poco desiderabile (monotonia della funzione reward), la cui combinazione costituisce la pietra angolare del simulatore differenziabile proposto. Eppure, la supply chain è dominata dalla legge dei piccoli numeri⁶. I problemi moderni di inventario sono dominati dalle loro caratteristiche discrete. Per lo meno, questo aspetto avrebbe dovuto essere evidenziato dagli autori come una grave limitazione di DIM – un punto da approfondire in ricerche successive.

Integrare gradienti e politiche discrete è un problema fondamentale per l’ottimizzazione stocastica, non solo per i simulatori differenziabili proposti. Infatti, lo stochastic gradient descent (SGD) opera su parametri a valori reali e, in quanto tale, non è evidente come ottimizzare politiche che regolano decisioni fondamentalmente discrete.

Operare su spazi fondamentalmente discreti attraverso processi guidati dal gradiente può certamente essere fatto, come dimostrato in modo brillante dai LLM (large language models), ma richiede una serie di stratagemmi. Finché non verranno scoperti stratagemmi equivalenti per le tipologie di situazioni affrontate nelle supply chain, i simulatori differenziabili sono un’idea promettente, 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 abbiano selezionato (ossia scelto a vaso) i loro 10.000 SKUs. Infatti, mentre conducevo esperimenti presso Lokad nel 2018 e 2019, ho utilizzato strategie di featurizzazione inquietantemente simili (Appendice B) per i modelli di deep learning usati da Lokad.

Da quegli esperimenti, propongo che:

• I prodotti nuovi e recenti non funzioneranno bene, poiché il ricalibro suggerito dalle equazioni (13), (30) e (31) si comporterà in modo erratico quando i dati storici sono troppo scarsi.
• Gli articoli a lento movimento incorreranno in rimedi inadeguati per le loro passate rotture di stock, poiché la tecnica presume che esista una domanda rettificata “ragionevole” (cosa che non vale per i prodotti a lento movimento).
• I prodotti intermittenti (non pubblicati o non disponibili per lunghi periodi, come 2+ mesi) incorreranno anch’essi in errori nella domanda presumibilmente rettificata.
• Gli SKUs dei concorrenti, dove i clienti scelgono aggressivamente il prezzo più basso, saranno sottovalutati, poiché il modello non può riflettere l’impatto drastico quando gli SKUs superano (in termini di prezzo) un concorrente.

Quei casi limite sono, in effetti, la parte sostanziale della sfida della supply chain. In un articolo, è allettante selezionare SKUs ben comportati: non troppo recenti, non troppo lenti, non troppo erratici, non intermittenti, ecc. Eppure, se dobbiamo ricorrere a tecniche sofisticate, focalizzarci sugli SKUs facili diventa un po’ irrilevante. Sebbene si possano ottenere miglioramenti economici su quegli SKUs, il guadagno assoluto è minimo (modesto nel migliore dei casi) – proprio perché quegli SKUs sono comunque ben comportati. La maggior parte delle inefficienze della supply chain risiede negli estremi, non nel centro.

Affrontare frontalmente quegli SKUs mal comportati è esattamente dove ci si aspetterebbe che il deep learning venga in nostro soccorso. Ahimè, DIM fa il contrario e si concentra sugli SKUs ben comportati che possono essere gestiti con tecniche molto meno sofisticate con poche o nessuna controindicazione.

La mia terza critica è che DIM presenta una configurazione tecnica piuttosto contorta.

Questo è probabilmente uno dei problemi più sottovalutati nella community di data science. La complessità è il nemico dell’affidabilità e dell’efficienza. Sebbene il deep learning sia fantastico, poche aziende possono permettersi gli ingegneri necessari per gestire un setup come DIM. Non è come ChatGPT, dove tutte le complicazioni ingegneristiche sono mutualizzate su tutta la base clienti del fornitore del software. Qui, considerando la quantità di dettagli che compongono DIM, ogni azienda cliente deve sostenere l’intero costo operativo associato alla propria istanza della soluzione.

Dal lato hardware, abbiamo una macchina virtuale EC2 p3.16xlarge⁷, attualmente prezzata a 17k USD/mese su AWS. Per 10.000 SKUs, il costo è… esorbitante.

Lokad ha molti clienti che gestiscono individualmente milioni di SKUs, e la maggior parte di essi ha un fatturato inferiore a 1 miliardo di USD. Sebbene possa essere possibile ridurre un po’ le dimensioni di questa VM e spegnerla quando non viene utilizzata, da Lokad abbiamo imparato che queste opzioni raramente sono idonee per un ambiente di produzione.

Ad esempio, le piattaforme di cloud computing devono affrontare le proprie carenze: a volte, la VM che avrebbe dovuto essere disponibile on-demand impiega ore per essere attivata. Inoltre, non dare mai per scontato che quei modelli possano essere semplicemente “pretrained”: ci sarà un giorno – come il prossimo martedì – in cui l’intero sistema dovrà essere riaddestrato da zero per ragioni imperative⁸. Inoltre, un setup di livello produzione non solo richiede ridondanza ma anche ambienti extra (testing, 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 training dataset – con 80.000 SKUs aggregati settimanalmente per sole 104 settimane – dovrebbe pesare meno di 100MB (se i dati sono rappresentati in modo sensato).

Mentre gli autori di DIM rimangono abilmente vaghi, riferendosi a una “grande quantità di dati” (pagina 32), è ovvio che la strategia di featurizzazione ingrandisce l’impronta dei dati originali di 3 ordini di grandezza (circa 1000 volte). Tieni presente che l’EC2 p3.16xlarge vanta non meno di 488 GB di RAM, che dovrebbero essere sufficienti per elaborare un dataset da 100MB (circa 100 GB dopo l’inflazione applicata)… Beh, ci sono passato, l’ho fatto e ho affrontato lo stesso problema.

Per esempio, un dataset supply chain di dimensioni realistiche supererebbe solitamente 1 terabyte dopo l’inflazione dei dati – come richiesto dall’approccio DIM. In questo caso, un data scientist tipico non può riprodurre un bug localmente perché la sua workstation ha solo 64GB di RAM. Oltre a ciò, c’è anche la questione del confine Python/Plasma, dove le cose possono andare storte.

Oltre alle critiche principali sopra menzionate, vi sono preoccupazioni secondarie. Ad esempio, la programmazione dinamica⁹ – menzionata nell’introduzione e nella conclusione come baseline e avversario di DIM – è semplicemente una baseline povera. La programmazione dinamica è una tecnica antica (che risale agli anni ‘50) e non riflette lo stato dell’arte per quanto riguarda la fusione tra ottimizzazione e learning.

È vero, la letteratura sulla supply chain è carente su questo fronte, ma ciò significa che gli autori devono trovare baseline rilevanti al di fuori del loro campo di studio. Ad esempio, AlphaGo Zero¹⁰ è una baseline intellettualmente molto migliore quando si tratta di un’applicazione notevole del deep learning a scopi di ottimizzazione – sicuramente se confrontata con 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 differentiable programming è un ottimo strumento per supply chain. Lokad lo utilizza da anni, ma non abbiamo ancora esaurito ciò che può essere fatto con questo paradigma programmatico.

C’è molto altro da esplorare, come dimostra DIM. I simulatori differenziabili sono un’idea interessante, e non sembra così solitario quando giganti tecnologici come Amazon sfidano i dogmi fondamentali della teoria mainstream della supply chain – proprio come facciamo noi. Da Lokad, abbiamo il progetto di, in qualche modo, fondere montecarlo e autodiff¹¹ in modi che si adattano perfettamente a quei simulatori differenziabili.

Rimanete sintonizzati!