Interi e incertezza nella programmazione differenziabile
Markus Leopoldseder (Director of Knowledge - Global Manufacturing and Supply Chain Practice at McKinsey) ha sollevato due domande rilevanti riguardanti l’applicabilità della Differentiable Programming (DP) per scopi di supply chain. In questo post abbastanza tecnico, cercheremo di fornire alcune intuizioni su come i vincoli sugli interi e come l’incertezza vengano rispettivamente gestiti in DP. Questa è solo una prima occhiata all’approccio di Lokad. Abbiamo in programma di pubblicare, in una data successiva, ricette estese su docs.lokad.com.
Come si applica DP alle variabili intere? Infatti, se la funzione obiettivo accetta interi come input, potrebbe non essere differenziabile.
Da una prospettiva di supply chain, la maggior parte delle decisioni sono discrete: non possiamo ordinare 4,2 unità di un prodotto, sono o 4 o 5. Pertanto, cerchiamo - sia dal punto di vista dell’apprendimento sia dell’ottimizzazione - metodi che funzionino bene con interi. Come acutamente sottolineato dal nostro lettore, i parametri in DP sono numeri, e tali parametri non possono essere vincolati agli interi, perché questa prospettiva non è compatibile con la discesa stocastica del gradiente, che sta al cuore di DP.
Esistono diversi modi per ottenere decisioni discrete e le corrispondenti funzioni obiettivo discrete tramite DP, che spaziano da approcci naivi ma semplici, a soluzioni estremamente complicate ma senza rivali in termini di ottimizzazione numerica.
L’approccio più semplice consiste nell’interpolare la funzione obiettivo durante la fase di training, e nell’arrotondare i risultati al momento della valutazione. Ad esempio, se cerchiamo una quantità d’ordine - che ci aspettiamo sia un intero - la funzione obiettivo può essere estesa a numeri arbitrari tramite interpolazione. Questo funziona bene quando si considerano sistemi che, pur essendo discreti, mostrano comportamenti abbastanza lineari. Tuttavia, di fronte a una forte non-linearità come un vincolo MOQ (quantità minima d’ordine), ciò non funziona altrettanto bene.
Per affrontare tali situazioni, la funzione obiettivo può essere sostituita da una funzione surrogata, una funzione che approssima la funzione obiettivo originale, ma in maniera liscia e differenziabile. Ad esempio, la funzione a gradino tipicamente associata al costo di penalità di un vincolo MOQ può essere sostituita da una funzione sigmoide. Dopo epoche ed epoche, la funzione surrogata viene progressivamente deformata per avvicinarsi numericamente alla funzione obiettivo originale.
Da una prospettiva di supply chain, secondo la nostra esperienza, le funzioni surrogate funzionano sorprendentemente bene. Infatti, situazioni in cui non è possibile iterare in modo fluido verso buone soluzioni sono rare. I problemi di supply chain non sono rompicapo crittografici in cui modificare un singolo bit di una soluzione comprometta l’intera soluzione. Ad esempio, se un ordine d’acquisto di 490 unità è redditizio mentre esiste un MOQ a 500, è probabile che anche l’ordine d’acquisto di 500 unità sia redditizio.
Poi, esistono approcci più sofisticati ispirati agli autoencoder variazionali: le uscite frazionarie di un livello (come nei “livelli di deep learning”) vengono convertite in una devianza intera casuale ottenuta da una distribuzione arbitraria, per esempio una distribuzione di Poisson. Attraverso questo meccanismo, il programma, pur operando solo con parametri frazionari, produce output interi che possono poi essere iniettati nella funzione obiettivo. La discesa stocastica del gradiente ripete il processo un gran numero di volte, in stile Monte Carlo, garantendo che le leggi che governano la generazione delle devianze intere casuali siano adeguatamente calibrate.
Infine, gli approcci più complessi, come AlphaZero, si basano sull’introduzione di una lista complessa di livelli (ad esempio una rete computazionale “profonda”) che tipicamente si conclude con un livello simile a Softmax per generare decisioni discrete. Questi approcci offrono risultati all’avanguardia su problemi di ottimizzazione altamente non lineari, come dimostrato dalla vittoria di AlphaGo (in seguito ridefinito come AlphaZero) contro Lee Sedol. DP può anche sfruttare questi metodi, riducendo semplicemente la profondità e la complessità della rete per mantenere sotto controllo il sovraccarico computazionale. Fortunatamente, in pratica, sebbene risolvere un problema MOQ sia relativamente difficile, non è affatto paragonabile alla difficoltà di battere un campione del mondo a Go per quanto riguarda i problemi di ottimizzazione, e le reti “superficiali” (per gli standard del deep learning) ottengono già molto.
Offrire modalità più dirette e pratiche per affrontare situazioni discrete, come quelle comunemente riscontrate in ambito supply chain, è stata una delle ragioni principali che ci ha spinto in Lokad a sviluppare il nostro stack software DP, invece di adattare un framework esistente; precisamente per avere maggiore libertà nell’introdurre costrutti speciali progettati per adattarsi a tali situazioni.
Alcuni di questi costrutti non sono altro che una libreria “standard” di funzioni scritte con il linguaggio DP stesso - come modo per mitigare compiti ripetitivi ed evitare categorie di errori. Alcuni di questi costrutti, tuttavia, sono più sottili e intrecciati con la discesa stocastica del gradiente per offrire capacità specializzate che non avrebbero potuto essere implementate tramite una differenziazione automatica “pura”.
Come si gestisce l’incertezza con DP? Infatti, DP può ottimizzare qualsiasi funzione obiettivo complessa regolando i parametri utilizzando una discesa stocastica del gradiente per ottimizzare una rete neurale, che non è altro che una funzione speciale. Come vengono considerate le distribuzioni di probabilità?
L’approccio dominante che adottiamo per gestire l’incertezza in DP consiste nel generare traiettorie - time-series generate che riflettono flussi di eventi futuri - a partire da distribuzioni di probabilità sottostanti, per poi lasciare che la funzione obiettivo operi seguendo un modello Monte Carlo. Questo approccio offre la possibilità di modellare complesse interazioni discrete all’interno di un sistema - come la conseguenza delle BOMs a cascata (distinte base) anche se le distribuzioni di probabilità - utilizzate come input - erano disponibili solo per la domanda futura di prodotti finiti.
Questo approccio non è nuovo. Gli autoencoder variazionali - sebbene progettati da una prospettiva piuttosto diversa - impiegano una strategia simile, prendendo la parametrizzazione di una distribuzione (una gaussiana per VAE) come input e producendo devianze come output. Come discusso sopra, quando abbiamo già menzionato gli autoencoder variazionali, usiamo frequentemente distribuzioni di conteggio che producono devianze intere, anziché distribuzioni continue come le gaussiane.
Questo approccio generativo - in cui le distribuzioni vengono trasformate in osservazioni (cioè, traiettorie) - può essere completamente integrato nel processo DP. Invece di prendere le distribuzioni di probabilità come input e ottimizzare le decisioni a partire da esse, le distribuzioni stesse possono essere apprese mentre l’ottimizzazione viene eseguita contemporaneamente. Ad esempio, il forecasting demand può essere eseguito insieme all’pricing optimization, poiché la strategia di pricing ha un forte impatto sulla domanda, e i due aspetti non possono essere realmente analizzati isolatamente l’uno dall’altro.
La parte generativa della ricetta menzionata sopra si trova già nelle reti generative avversarie, che hanno riscosso un enorme successo nel generare immagini foto-realistici. Quando si considerano le serie temporali, l’LSTM e il GRU (un equivalente più semplice e moderno dell’LSTM) offrono modi per generare serie temporali complesse che non avrebbero potuto essere modellate esplicitamente tramite distribuzioni di probabilità.
DP offre maggiore flessibilità per sfruttare tali capacità da una prospettiva di supply chain, pur gestendo oggetti più eterogenei (grafici, serie temporali, dati relazionali) rispetto agli scenari solitamente considerati dalla prospettiva del deep learning. Ancora una volta, la maggior parte degli sforzi ingegneristici di Lokad si è concentrata sulla prospettiva di supply chain, per assicurarsi che gli strumenti fossero allineati con i requisiti specifici che sorgono nell’ottimizzazione di scorte, prezzi, acquisti, produzioni, assortimenti, ecc - invece che concentrarsi su immagini, voci e l’elaborazione del linguaggio naturale.
