AI Pilots nella Supply Chain - Ep 159

00:00:00 Introduzione all’intervista
00:01:01 L’impatto dell’AI sui lavori tradizionali
00:04:36 Automazione AI in supply chain
00:09:08 Necessità di un sistema unificato nel 2012
00:10:30 Reinserimento delle decisioni nei sistemi
00:13:08 Evitare il problema delle allucinazioni nell’AI
00:16:11 Impatto e ritardi dovuti al backlog IT
00:20:04 Confronto tra le configurazioni di Lokad e quelle di altri fornitori
00:23:06 Discussione sulle allucinazioni e confabulazioni dei LLM
00:30:38 Enfatizzare il progresso piuttosto che la perfezione nell’AI
00:33:00 Recupero di informazioni mancanti e ETA dell’ordine
00:36:17 Compiti quantitativi e LLM in supply chain
00:38:28 Il futuro degli AI Pilots in supply chain
00:41:18 Il valore delle conversazioni e l’automatizzazione delle attività a basso valore
00:44:57 Utilizzo degli AI Pilots per ridurre il backlog
00:49:00 AI Pilot vs copilot e scenario di lockdown
00:53:36 Scetticismo verso l’AI conversazionale e l’analisi dei processi
00:57:18 Comprendere la realtà aziendale e l’AI che sostituisce i processi
01:00:12 Le sfide dell’open source di Envision
01:06:21 L’approccio dell’AI ai colli di bottiglia e supply chain
01:09:17 Inefficienza dei comandi verbali e automatizzazione degli ordini
01:14:12 Supply Chain Scientist come copilot per AI Pilot
01:17:32 Verifica della correttezza dei dati e automatizzazione dei controlli con LLM
01:20:15 Rendere Envision compatibile con git
01:21:14 Risorse gratuite per imparare Envision

Sommario

In un dialogo tra il CEO di Lokad, Joannes Vermorel, e il Responsabile della Comunicazione Conor Doherty, si discute l’impatto dell’AI sulla supply chain management. Vermorel evidenzia i progressi dell’AI e dei large language models, che hanno rivoluzionato l’automazione delle attività. Presenta gli AI Pilots, un’offerta di Lokad che automatizza il decision-making e le attività amministrative, facilitata dal linguaggio di programmazione proprietario di Lokad, Envision. Vermorel discute inoltre il potenziale dell’AI nell’automatizzare le attività relative ai Master data e confronta l’approccio di Lokad con quello dei concorrenti. Prevede che gli AI Pilots diventeranno la norma nella supply chain management, portando a miglioramenti significativi della produttività. La conversazione si conclude con una sessione di domande e risposte.

Sommario Esteso

In una recente conversazione tra Conor Doherty, Responsabile della Comunicazione di Lokad, e Joannes Vermorel, CEO e fondatore di Lokad, i due hanno approfondito il ruolo trasformativo dell’artificial intelligence (AI) nella supply chain management. La discussione, continuazione di una precedente conversazione sull’impatto dell’AI sull’occupazione, si è concentrata sul potenziale dell’AI di agire come un pilota autonomo per il decision-making nella supply chain.

Vermorel ha iniziato evidenziando il traguardo storico raggiunto nel 2023 grazie all’AI generativa e ai large language models (LLM). Questi progressi, ha spiegato, hanno rivoluzionato l’automazione delle attività che coinvolgono il testo, come la lettura delle email o la classificazione dei reclami. Il 2023 è stato particolarmente significativo in quanto ha visto una sostanziale riduzione dei costi operativi delle tecniche di elaborazione del linguaggio naturale per le aziende. Vermorel ha previsto che ciò avrebbe portato all’automatizzazione di molte funzioni di supporto interno, con le operazioni di supply chain in prima linea.

Vermorel ha poi presentato gli AI Pilots, un’offerta di Lokad che automatizza il processo di decision-making e gestisce le attività amministrative di routine. Ha sottolineato l’approccio unico di Lokad, in cui un Supply Chain Scientist può assumersi la piena responsabilità di un’iniziativa. Ciò è reso possibile dal linguaggio di programmazione proprietario di Lokad, Envision, dedicato all’ottimizzazione predittiva delle supply chains. Tuttavia, Vermorel ha ammesso che in precedenza Lokad aveva avuto difficoltà nella ricerca dei dati e nel gestire i vari dialetti SQL.

L’introduzione di GPT-4, ha spiegato Vermorel, ha rappresentato un punto di svolta per Lokad, permettendo all’azienda di automatizzare la composizione delle query SQL. Queste query possono poi essere revisionate da un Supply Chain Scientist e testate per garantire accuracy. Questo sviluppo, unito a una connessione cloud-to-cloud sicura, consente al team di Supply Chain Scientists di Lokad di inseguire autonomamente i dati dei clienti, riducendo così i ritardi.

Vermorel ha inoltre evidenziato il potenziale dei LLM nell’automatizzare molte attività legate ai Master data, inclusi il rilevamento, il monitoraggio e il miglioramento. Ha confrontato l’approccio di Lokad con quello dei concorrenti, affermando che Lokad solitamente coinvolge un numero minore di persone in un’iniziativa, con ciascuno in grado di operare in tutte le fasi del processo. Questo, ha sostenuto, rappresenta un netto contrasto con i concorrenti che spesso coinvolgono molte più persone, inclusi project manager, consulenti, UX designer, amministratori di database, specialisti di rete e programmatori.

La conversazione si è poi spostata sul ruolo dei Supply Chain Scientists nella validazione o nel monitoraggio degli script generati dai LLM. Vermorel ha riconosciuto che i LLM a volte possono produrre risultati inaccurati o “allucinati”, ma che solitamente sono corretti a grandi linee e possono essere rettificati con alcune iterazioni tramite un ciclo di feedback. Ha suggerito che, pur commettendo errori, i LLM possono comunque apportare molto valore e che il loro tasso di falsi positivi e falsi negativi può essere misurato.

Vermorel ha ulteriormente spiegato l’orchestrazione quotidiana tra il Supply Chain Scientist, l’AI Pilot e il cliente. L’AI Pilot, composto dal Supply Chain Scientist, gestisce le operazioni giornaliere del supply chain, occupandosi dei dettagli della data preparation e delle decisioni riguardanti gli ordini di acquisto. Il cliente, in questo contesto, viene paragonato al capitano, che fornisce indicazioni strategiche complessive.

In termini di spunti per i professionisti della supply chain e i team esecutivi, Vermorel ha previsto che in un decennio gli AI Pilots diventeranno la norma nel Supply Chain Management (SCM). Ciò, secondo lui, porterà a un enorme miglioramento della produttività, con una potenziale riduzione del 90% dei headcount per le funzioni precedenti. Ha esortato i professionisti della supply chain a dedicare più tempo al pensiero strategico e a conversazioni approfondite con fornitori e clienti.

La conversazione si è conclusa con una sessione di domande e risposte, durante la quale Vermorel ha affrontato questioni su una serie di argomenti, tra cui il ruolo degli AI Pilots nella riduzione del backlog IT, la differenza tra un AI Pilot e un copilot, l’importanza dell’analisi dei processi prima di implementare un modello di AI, i piani di Lokad per open source Envision, e come l’AI affronta i colli di bottiglia casuali. Ha inoltre confermato che Lokad sta lavorando su un copilot di Lokad e ha in programma di rendere Envision più compatibile con GitHub.

Trascrizione Completa

Conor Doherty: Benvenuti a Lokad live. Mi chiamo Conor. Sono il Responsabile della Comunicazione qui a Lokad. E sono accompagnato in studio dal fondatore di Lokad, Joannes Vermorel.

Today’s topic is how AI can act as a standalone pilot for supply chain decision-making. Feel free to submit your questions at any time in the YouTube chat, and we’ll get to them in approximately 30-35 minutes.

And with that, Joannes, AI Pilots in supply chain occurs to me that this conversation is very much an extension of one that we had, I think about four weeks ago, where we talked about the implications of AI on employment and the future of traditional jobs versus AI in supply chain.

So before we get into the specifics of AI Pilots, could you give for anyone who didn’t see that, could you give a refresher, just an executive summary, what is our perspective on traditional jobs versus AI in supply chain?

Joannes Vermorel: Il riepilogo è che è stato raggiunto un traguardo fondamentale, praticamente nel 2023. Questo traguardo è l’AI generativa e, più specificamente, i large language models (LLM). In termini di ricerca pura, è solo la continuazione di quasi quattro-cinque decenni di miglioramenti continui nel machine learning. Quindi, se lo si guarda da una prospettiva di ricerca, il 2023 è solo un anno come gli altri, con una lunga sequenza di progressi. E c’è stato un progresso relativamente rapido negli ultimi due decenni.

Ora, nel 2023, ciò che arriva sul mercato è l’AI generativa confezionata per le immagini e, soprattutto, per il testo. E c’è un prodotto che ha reso popolare questo concetto, ovvero ChatGPT di OpenAI. Cosa significa? Significa, in modo molto specifico, che soprattutto grazie a quei large language models, si dispone di una macchina di templating universale e resilient contro il rumore.

Ciò significa che tutte quelle fasi tipiche del software aziendale, inteso nel contesto di lavoratori d’ufficio in ambienti corporate, che in passato non potevano essere automatizzate a causa della necessità di trattare il testo in ogni sua forma — ad esempio leggere un’email, estrarre un riferimento o un prezzo da un’email, oppure una quantità, o categorizzare il tipo di reclamo o richiesta da un partner o cliente fornitore, identificare se un’etichetta di un prodotto è insensata, per esempio, se la descrizione del prodotto manca — tutte quelle cose in passato non potevano essere fatte facilmente. Potevano essere eseguite in altri modi, ma non potevano essere automatizzate con facilità.

Se dovessimo tornare indietro, diciamo, di cinque anni, il text mining era già una realtà. Era già possibile avere classificatori di testo e utilizzare tutte le tecniche di elaborazione del linguaggio naturale, ma erano costose. Il 2023 è stato un traguardo fondamentale perché tutti quei problemi, grazie al grado di confezionamento raggiunto essenzialmente con GPT-4 erogato tramite un’API, hanno comportato una riduzione dei costi operativi per le aziende relativo a quelle tecniche NLP di un fattore di 100, se non 1.000. Ciò significa che non solo i costi, ma anche i tempi necessari per impostare il sistema, sono stati drasticamente ridotti.

Quindi, in sintesi, e questa è la mia previsione, molte funzioni di supporto nelle aziende, che sono semplicemente funzioni interne che acquisiscono dati e producono un output per altre divisioni, saranno automatizzate. La supply chain è in prima linea perché non è esattamente una funzione a contatto con il cliente. È decisamente una funzione interna, importante, ma interna. E quindi i large language models sono stati il tassello mancante per automatizzare in gran parte, end-to-end, la stragrande maggioranza delle operazioni routinarie nelle supply chain.

Lokad automatizza l’analisi quantitativa e il processo decisionale quantitativo da un decennio, ma ci sono molte operazioni di routine che precedono e molte che seguono, e quelle possono essere automatizzate grazie ai large language models, in modo rapido ed economico.

Conor Doherty: Bene, grazie. E abbiamo già un video in cui ne abbiamo parlato, credo, per circa un’ora e mezza, quindi oggi non mi soffermerò ulteriormente su questo argomento, ma questo prepara il terreno per il resto della conversazione. Invito cordialmente chiunque desideri saperne di più a visionare il video precedente. A proposito, come si inseriscono gli AI Pilots in tutto ciò che hai appena detto? Cosa sono? Cosa fanno in realtà?

Joannes Vermorel: In generale, il termine AI è stato usato costantemente negli ultimi due decenni dai fornitori come una parola d’ordine e un termine ombrello per indicare tutto ciò che offrivano. Quindi, quando dico AI Pilots, mi riferisco a un’offerta di Lokad. È un’evoluzione dell’offerta, probabilmente la più grande che abbiamo avuto in anni. E qual è la differenza? Beh, la differenza sta nel fatto che un AI Pilot è qualcosa, è un piece of software, quello che definiamo una serie di ricette numeriche, che non solo esegue il processo decisionale, cioè l’aspetto puramente quantitativo della supply chain, determinando esattamente quanto ordinare, dove allocare lo stock, se è necessario alzare o abbassare i prezzi, e come pianificare la produzione con tutti i passaggi, ecc.

Quello che già facevamo, più tutto ciò che viene prima e dopo in termini di compiti amministrativi di routine, che sono per lo più la gestione dei Master data prima dell’analisi dei dati, e poi l’esecuzione della decisione che può coinvolgere canali non strutturati come le email, ad esempio, dove si desidera inviare un’email a un fornitore per richiedere l’accelerazione di una spedizione o, al contrario, posticipare un ordine.

E il succo di questa offerta sono chiaramente i large language models che Lokad non ha inventato, che utilizziamo ampiamente da 14 mesi, o poco più. E l’intuizione chiave nel modo in cui opera Lokad è che dovrebbe essere un unico Supply Chain Scientist in grado di assumersi la completa responsabilità di un’iniziativa.

Per aziende molto grandi, potremmo avere diverse persone al lavoro, ma a differenza della maggior parte dei nostri concorrenti, di solito non sono specializzate. Quindi non è come se formassimo una squadra di tre persone con il Sig. Database, il Sig. Algorithms e il Sig. UI e UX. Assolutamente non è così che opera Lokad. Un Supply Chain Scientist è in grado di fare tutto, dall’inizio alla fine.

Ed è uno dei motivi per cui Lokad ha progettato la propria tecnologia nel modo in cui lo fa, e dispone di un proprio linguaggio di programmazione, un linguaggio di dominio specifico chiamato Envision, dedicato all’ottimizzazione predittiva delle supply chains. Può sembrare strano aver inventato un linguaggio di programmazione su misura, ma il succo della questione è che noi, e questa è una decisione che ho preso nel 2012, avevamo davvero bisogno di qualcosa che fosse unificato in modo che una sola persona potesse occuparsi dell’intero processo, dall’inizio alla fine.

Fino a pochi anni fa, significava davvero ottenere i dati grezzi delle transazioni dagli ERPs, CRMs, EDI e tutti quei sistemi transazionali, integrandoli con una serie di fogli di calcolo per tutti i dati strutturati che purtroppo fanno parte della shadow IT anziché dell’IT regolare, e poi elaborare le ricette numeriche per il processo decisionale. Ed era responsabilità del Supply Chain Scientist occuparsi di tutto ciò, per poi realizzare tutta l’instrumentation, compresi i dashboards e i report, per assicurarsi di convincersi che i numeri fossero corretti ma anche per rassicurare i nostri clienti sulla validità di quanto facciamo, oltre a tutti gli strumenti per monitorare la qualità delle decisioni nel tempo e l’impianto necessario per estrarre i dati dai sistemi e reintrodurre le decisioni negli stessi.

Quindi quello era l’ambito in cui operava Lokad, e c’erano due cose che non potevamo davvero fare. Primo, dovevamo essere il destinatario dei dati, non potevamo proprio cercarli. E quando dico cercare, il Supply Chain Scientist poteva richiedere i dati; non stavamo chiedendo alle divisioni IT dei nostri clienti di effettuare trasformazioni sofisticate, si trattava semplicemente di scaricare le tabelle – sai, “select star from table”, bam, lo fai una volta al giorno e hai finito. Quindi si trattava di estrazioni super semplici, ma comunque era sostanzialmente la divisione IT dei nostri clienti a occuparsene.

Non ci si aspettava che i Supply Chain Scientists cercassero, nel panorama applicativo dei nostri clienti, i dati necessari per l’iniziativa. La ragione era molto semplice: esistono circa una ventina di dialetti SQL là fuori, come Oracle SQL, il dialetto T-SQL di Microsoft SQL Server, MySQL, PostgreSQL, DB2 di IBM, ecc. Quindi ci sono circa 20 dialetti SQL. Fino a pochi anni fa, un Supply Chain Scientist avrebbe avuto enormi difficoltà, perché anche se ciò che questa persona voleva realizzare era estremamente semplice, tipo scaricare una singola tabella, il problema era che avrebbe letteralmente impiegato decine di ore a cercare online query banali, e ogni volta che compariva un messaggio d’errore, spetterebbe ancora a questa persona intervenire; anche se era generalmente familiare con i database SQL, rappresentava, direi, un enorme ostacolo dover gestire dialetti di sistemi che non conoscevi.

Nel 2023, con ChatGPT, il problema è risolto. ChatGPT, in qualità di assistente programmatore, non è esattamente il massimo per farti comporre applicazioni sofisticate, ma quando si tratta di comporre query SQL super semplici in dozzine di dialetti, è rapidissimo. Un Supply Chain Scientist richiederà la composizione di una query SQL. Questa persona è anche intelligente e revisionerà la query per assicurarsi che rispecchi l’intento. Si tratta semplicemente di eliminare l’ostacolo della scoperta della sintassi, ma una volta che hai la sintassi corretta che ti viene presentata, è praticamente autoesplicativa.

Se vuoi provarlo tu stesso, basta chiedere a ChatGPT di fornirti una guida passo passo per configurare git sul tuo computer e impostare un repository git o qualsiasi altra cosa; vedrai che tipo di risposta di altissima qualità puoi ottenere.

Questo cambia veramente le carte in tavola perché significa che improvvisamente Lokad, che sta formando Supply Chain Scientists, può assumersi la responsabilità di cercare i dati. E so che grazie a ChatGPT disponiamo degli strumenti per non sovraccaricarci promettendo che ci occuperemo noi stessi della ricerca dei dati. È un cambiamento rivoluzionario. Invece di chiedere all’IT di inviarci i dati, possiamo semplicemente avere un indirizzo IP in whitelist e stabilire una connessione cloud-to-cloud molto sicura, lasciando così al team dei Supply Chain Scientists il compito di inseguire i propri dati.

Perché questo fa una tale differenza? Beh, la realtà è che anche se per una determinata iniziativa Lokad necessita solo di pochi giorni di lavoro, stiamo parlando magari di 10-20 giorni per un’iniziativa consistente per ottenere le 20-50 tabelle di cui abbiamo bisogno – si tratta solo di scaricare le tabelle, senza join, senza filtri sofisticati, è molto semplice – il problema è che molti dei nostri clienti hanno le proprie divisioni IT con enormi arretrati. Intendo letteralmente anni di arretrati e quando hai, ad esempio, tre anni di arretrati, anche se Lokad richiede solo 10 giorni, si tratta di 10 giorni più tre anni di arretrati; quindi, anche se non siamo esattamente in fondo alla coda, se siamo semplicemente nel mezzo, quei 10 giorni di lavoro dell’IT potrebbero impiegare persino un anno per essere completati, e direi che una delle frustrazioni che abbiamo avuto è stata il fatto che la maggior parte dei ritardi derivava non dall’inefficienza o dalla lentezza dell’IT, ma semplicemente dal fatto che avevano così tanti arretrati che era molto difficile per loro dedicare quei 10 giorni.

Qui abbiamo un caso in cui, invece di richiedere 10 o 20 giorni di lavoro, si parla di qualcosa come meno di una giornata, tipo solo un paio d’ore, per aprire un accesso molto sicuro e ristretto ai pochi sistemi di cui abbiamo bisogno. E poi i Supply Chain Scientists stessi si occuperanno di esaminare le tabelle, impostare la logica di estrazione dei dati e assicurarsi che le estrazioni siano, direi, leggere.

Il modo in cui possiamo farlo è generalmente monitorando le prestazioni. Ogni volta che le prestazioni del database calano, significa che c’è molta attività sul database e quindi, solitamente, vuoi alleviare la pressione e posticipare il processo di recupero dei dati. Perché, tipicamente, a Lokad dobbiamo aggiornare i dati quotidianamente, ma non è una questione super urgente. Voglio dire, dipende: ci sono situazioni in cui abbiamo scadenze molto serrate, ma molto frequentemente, per quanto riguarda le supply chain, se ritardiamo il recupero di 30 minuti giusto perché c’è un picco di attività su quel database, non è un problema.

Il primo impegno consiste nell’inseguire noi stessi i dati, eliminando così la causa principale del ritardo e accelerando enormemente le iniziative. Ancora una volta, quei ritardi divenivano molto spesso la parte maggiore del tempo d’attesa dell’intera iniziativa Lokad per passare in produzione, dovuto semplicemente all’attesa che l’IT potesse dedicare quei giorni.

Il secondo impegno riguarda il miglioramento dei Master Data. E qui, ancora, in passato, quando si aveva a che fare con un catalogo in cui c’erano, diciamo, 100.000 descrizioni di prodotto, alcune delle quali erano inutilizzabili, magari l'1%, era un lavoro enorme esaminare quelle 100.000 referenze, identificare le descrizioni o le etichette dei prodotti errate o a volte si trattava semplicemente di un prezzo completamente incoerente con la descrizione. Se si parla di una vite e il prezzo è di 20.000 dollari, probabilmente non si tratta solo di una vite, ma di qualcos’altro, ecc. C’erano moltissimi controlli basilari che sembravano ovvi e semplici, ma era molto difficile automatizzarli, e frequentemente non c’era altra alternativa che far visionare le voci a una persona per individuare gli errori più gravi.

Con un LLM, e potenzialmente anche un LLM capace di elaborare immagini, si possono fare molte cose per quanto riguarda la verifica, il monitoraggio e il miglioramento di tutto ciò che riguarda i Master Data. Nel caso specifico di Lokad, la parte di Master Data necessaria per pilotare le supply chain.

Conor Doherty: Beh, c’è molto da dire, grazie. Ho molte domande che vorrei approfondire. Farò un piccolo passo indietro, perché se posso riassumere tutto quello che stai descrivendo, e correggimi se sbaglio, un Supply Chain Scientist con accesso a un buon LLM può fare un lavoro enorme. Un lavoro che fino a questo momento avrebbe richiesto molto tempo e coinvolto molte persone. Ora, in un setup non in stile Lokad, quante persone in più sarebbero coinvolte? Quante più mani in pasta ci sarebbero? E poi puoi parlare dell’efficienza, ma solo in termini di organico: qual è la differenza tra Supply Chain Scientists con LLM e, non so, S&OP per esempio?

Joannes Vermorel: I nostri clienti sono tipicamente sbalorditi dal fatto che anche un’iniziativa di grandi dimensioni coinvolga solo due o tre persone, e sempre le stesse. Abbiamo Lokad, e sono molto orgoglioso che Lokad, come datore di lavoro, riesca a mantenere le persone per un bel po’ di tempo. Quindi, in sostanza, Lokad opera solitamente con l'1% dell’organico dall’inizio alla fine. Se abbiamo più persone, è sempre per avere una ridondanza. Un giorno ti concentri su questa parte della pipeline e io su quest’altra, e il giorno successivo ci scambiamo i ruoli. Non è che le persone non si specializzino; ognuno possiede competenze su tutta la pipeline. Ci sono alcune variazioni e alcune persone hanno specialità particolari, ma nel complesso, le persone possono davvero sostituirsi l’una con l’altra.

I nostri concorrenti, invece, sono molto diversi. Anche un’iniziativa piccola coinvolge letteralmente mezza dozzina di persone. Avrai il project manager, che serve solo a coordinare gli altri, poi il consulente, il UX designer, il configuratore, l’amministratore di database, lo specialista di rete e, potenzialmente, un programmatore, un software engineer per le personalizzazioni non native. Ancora una volta, Lokad è una piattaforma programmatica, mentre la maggior parte dei nostri concorrenti ha piattaforme che non lo sono. Quindi, ogni volta che desideri qualcosa con un comportamento programmatico, devi avere un software engineer a tutti gli effetti che implementi, letteralmente, con un linguaggio di programmazione general-purpose come Java o Python le parti mancanti. Quindi, Lokad non è affatto così. Direi che i nostri concorrenti, per impostazione predefinita, sono circa una dozzina. Le iniziative S&OP possono coinvolgere diverse decine di persone, ma non necessariamente con così tante competenze diverse; si tratta principalmente di persone provenienti da vari dipartimenti e, molto frequentemente, non sono fortemente guidate dall’IT.

Quindi, parlando di Lokad, quando dico una persona contro una dozzina, paragono questo al nostro modello rispetto a quello dei concorrenti che vendono APS, sistemi di advanced planning o sistemi di ottimizzazione dell’inventario, quel genere di software enterprise.

Conor Doherty: Grazie. E per tornare a un altro punto che hai menzionato all’inizio, quando parlavi dei Supply Chain Scientists, hai fatto l’esempio dei vari dialetti SQL e poi del Supply Chain Scientist che potrebbe o meno essere fluente in quel dialetto specifico del cliente e che validerebbe o monitorerebbe gli script generati automaticamente, perché ogni tanto gli LLM hallucinano.

Beh, a questo proposito, gli LLM hallucinano molto spesso. Ora, è vero che stanno migliorando, ma puoi chiedere a un LLM, con un pezzo di testo, “Trova questa parola nascosta, la vedi?” e lui risponderà di sì, anche se in realtà non c’è. Io so che non c’è, sai bene che non c’è. Come puoi, su larga scala, garantire sicurezza e monitorare il controllo di qualità quando sfrutti gli LLM in maniera automatizzata?

Joannes Vermorel: Le allucinazioni, o meglio le confabulazioni come preferisco chiamarle, si verificano davvero quando utilizzi l’LLM come una base di conoscenza per tutto. Se usi gli LLM come una base di conoscenza di tutto, allora succede. Se chiedi articoli medici e dici “Dammi una lista di articoli su questa patologia”, ti darà qualcosa che è, in linea di principio, corretto. Gli autori esistono frequentemente, hanno pubblicato, hanno materiale in quell’area, hanno articoli pubblicati che sono in qualche modo affini, anche se non perfettamente. È, ancora una volta, come se chiedessi a uno scienziato di ricordare a memoria delle informazioni.

È molto difficile, diresti, e se devi farlo, probabilmente otterrai qualcosa di per metà plausibile, con nomi corretti di colleghi o ricercatori, titoli corretti o semi-corretti, cose del genere. Quindi, quella è una situazione in cui si verificano confabulazioni, ma ce le meriti in un certo senso. Voglio dire, stai chiedendo agli LLM di comportarsi come un database di tutto, quindi è molto difficile, e questo genere di problema si presenterà.

La stessa cosa vale per i dialetti SQL: provi e ottieni qualcosa, che sarà approssimativamente corretto. Se chiedi “Voglio leggere una tabella”, eseguirà un “select star from table” e così via. Non ti restituirà, ad esempio quando usi GPT-4 e chiedi di leggere una tabella, il comando “drop table”. Potrebbe fornirti una sintassi leggermente inadeguata, così testi la query SQL, ricevi un messaggio d’errore, fai una piccola modifica e funziona. Ma vedi, è comunque direzionalmente corretta. Se chiedi di leggere il database, non produrrà un comando che elimini una tabella o modifichi le autorizzazioni del database.

La stessa cosa succede quando chiedi conoscenze inventate. Per esempio, se chiedi, “Okay, ho un compressore industriale da 20 kilowatt di potenza, qual è il suo prezzo?” Se chiedi a GPT, potrebbe dire probabilmente qualcosa come $10.000. È solo una stima. Questo è letteralmente inventato. È plausibile, ma è corretto? Probabilmente no, e dipende da centinaia di varianti perché esistono tantissimi compressori diversi per varie situazioni.

Quindi, in sostanza, le confabulazioni non avvengono a caso. Ci sono compiti specifici in cui si verificano molto più frequentemente. Direi quindi che, quando le solleciti, ovvero quando usi l’LLM come un database di tutto, è meglio ricontrollare. Può essere estremamente utile, ad esempio per i dialetti SQL ti suggerirà quali parole chiave usare, come appare la sintassi, e potrà commettere un piccolo errore, dimenticare una virgola o qualcosa del genere, ma con qualche iterazione la query verrà corretta. Soprattutto perché, una volta ottenuta la query SQL, puoi testarla sul database, vedere l’output e validarla, creando così un ciclo di feedback istantaneo.

Se vuoi rilevare, diciamo, etichette di prodotto strane, etichette di prodotto che sembrano sospette, per esempio quando manca la descrizione di un prodotto, quella è la tua etichetta di prodotto, ok, è chiaramente sbagliato. Ma possono verificarsi ogni sorta di errori. Per esempio, puoi avere un’etichetta di prodotto che dice “tournevis cruciforme” (è in francese) e quindi il problema è che è solo in francese, è un cacciavite con punta Phillips, credo. E quindi, di nuovo, puoi richiedere certe cose, ma a un certo punto non è perfetto, è una questione di giudizio. Un essere umano commetterebbe lo stesso errore, quindi non puoi aspettarti che l’LLM sia un oracolo finale in grado di rispondere correttamente a ogni domanda. A un certo punto, se stai svolgendo un compito come quello di esaminare i 100.000 prodotti del tuo catalogo per anomalie nelle etichette, l’LLM avrà falsi positivi e falsi negativi proprio come un essere umano. Ma la cosa interessante è che puoi effettivamente misurare il tasso di falsi positivi e falsi negativi e poi decidere se ne vale la pena o meno. E molto spesso, ottieni qualcosa di piuttosto valido, qualcosa che ti offre molto valore anche se commette ancora alcuni errori.

Conor Doherty: Progresso, non perfezione.

Joannes Vermorel: Esatto. Se puoi ridurre del 90% i problemi dei dati master con qualcosa di molto economico e che può essere rieseguito in poche ore senza supervisione, è davvero ottimo.

Conor Doherty: C’è anche il valore del tempo risparmiato, il tempo che altrimenti sarebbe stato speso manualmente e che potresti impiegare in altro che genera o aggiunge valore. Quindi, di nuovo, ci sono fattori diretti e indiretti che guidano questo valore.

Joannes Vermorel: Inoltre, la realtà è che quando svolgi un compito estremamente ripetitivo per un’ora, puoi mantenere un certo livello di qualità. Quando lo fai per 100 ore, tipo all’ora 67, voglio dire, in genere, gli esseri umani non sono motori di prestazione costante. Dopo poche ore, la concentrazione cala e quindi il numero di falsi positivi e falsi negativi probabilmente salirà alle stelle, anche con un impiegato abbastanza diligente.

Conor Doherty: Grazie. E tengo presente il fatto che abbiamo effettivamente alcune domande dal pubblico che toccano argomenti che stavo per chiedere, quindi salterò alcune cose, ma verranno affrontate nelle domande del pubblico. Ma un ultimo pensiero qui: quando parli dei Supply Chain Scientists, dell’AI Pilot – e torneremo su questo nelle domande – ma il Supply Chain Scientist, un AI Pilot e il cliente, come funziona concretamente questa orchestrazione nel quotidiano? Il cliente ha accesso? Interagisce con l’LLM?

Joannes Vermorel: In genere, consideriamo che tutte le ricette numeriche create dai Supply Chain Scientists costituiscono l’AI Pilot. Questa è la componente che pilota la supply chain quotidianamente. Funziona senza supervisione e genera le decisioni. Ora, con gli LLM, gestisce anche le minutiae della preparazione dei dati e le decisioni sugli ordini (PO). Per esempio, la pre-decisione consisterebbe nel chiedere ai fornitori il loro MQS. Devi recuperare queste informazioni, se mancano o non sono aggiornate, bisogna cambiarle. Gli LLM possono aiutarti a farlo. La post-decisione consisterebbe nel mandare un’email per chiedere un ETA, ovvero il tempo stimato di arrivo, per gli ordini se non hai un EDI in atto o se non hai un bridge, oppure per sollecitare un ordine o posticiparlo. Queste sono le minutiae che seguono, dove Lokad può generare la decisione di sollecitare un ordine ma non occuparsi dei particolari, che consistono semplicemente nel comporre un’email e inviarla.

È tutto fondamentalmente l’AI Pilot ed è la grande ricetta numerica che esegue il processo end-to-end. Tutto ciò è implementato dal Supply Chain Scientist. Quindi, questa è un’estensione dell’ambito per Lokad. Il Supply Chain Scientist è, in realtà, il copilota. E pensa a questo come quando dico pilota: intendo davvero un pilota automatizzato in un aereo. E, tra l’altro, negli aerei di oggi le manovre più difficili vengono eseguite in autopilota. Quando hai aeroporti davvero spaventosi, come l’aeroporto legacy di Hong Kong, insieme a uno nuovo che è molto più facile, ma se ce n’è uno letteralmente in mezzo a grattacieli, allora l’autopilota per quelle manovre diventa obbligatorio. Quindi, viene fatto, è tutta la macchina; le persone si limitano a monitorare.

Qui, il Supply Chain Scientist ingegnerizza le ricette numeriche ed è il copilota. Decide, praticamente si occupa della navigazione per dirigere le cose e poi progetta il piano e il percorso per il pilota. Ma fondamentalmente, il Supply Chain Scientist ricopre il ruolo di copilota, determinando le direzioni, pensando in anticipo e assicurandosi che il pilota possa operare nel modo più fluido possibile. Tuttavia, tutti gli aggiustamenti ad alta frequenza spettano al pilota, non al copilota. E poi il cliente assume il ruolo del capitano.

Sai, un po’ come nelle vecchie serie TV, Star Trek, dove il capitano è seduto sulla sedia e fornisce al personale istruzioni di altissimo livello. Quindi, in questa configurazione, il cliente definisce la strategia e le indicazioni complessive. Successivamente, spetta al Supply Chain Scientist implementare ciò, mentre il ruolo del pilota è semplicemente eseguire tutti i micro aggiustamenti necessari o tutte le decisioni quotidiane indispensabili per la supply chain e farla funzionare.

Conor Doherty: E questo è anche, per essere chiari – perché non ne abbiamo parlato – un’aggiunta a tutte le attività quantitative automatizzate che sono già in corso da anni. Quindi, nel caso qualcuno ascolti e pensi, “Oh, beh, queste sono solo attività qualitative”, stiamo parlando di un processo end-to-end. Sì, quantitativo, come il factoring degli economic drivers, la generazione dell’allocazione, gli acquisti, la determinazione dei prezzi, è già guidato dall’AI e automatizzato.

Quindi il Supply Chain Scientist supervisiona entrambe le console, quella quantitativa e quella qualitativa.

Joannes Vermorel: Esattamente. E il motivo per cui Lokad ha finalmente iniziato ad abbracciare questa parola chiave AI – che è un termine ombrello – è perché ora stiamo aggiungendo, introducendo nella miscela, gli LLM. Avevamo già il machine learning con la programmazione differenziabile e l’ottimizzazione stocastica, ma ora stiamo aggiungendo gli LLM. E quindi è letteralmente una cassetta degli attrezzi molto completa.

Il risultato è, letteralmente, per i clienti: supply chains che possono operare senza supervisione per settimane. La gente resta sorpresa da quanto a lungo, una volta messi in moto quegli economic drivers, sia possibile operare completamente in modalità unattended. La bellezza sta nel fatto che non devi effettuare alcun tipo di micro aggiustamento. Per esempio, gli aggiustamenti alle previsioni, per la maggior parte dei nostri clienti, sono completamente inesistenti. E la maggior parte degli altri aggiustamenti avviene in modo completamente automatico, come l’introduzione di new products, il phase-out dei vecchi prodotti, l’introduzione di nuovi fornitori e il phase-out dei fornitori non performanti.

Quindi, tutto ciò è praticamente una routine e, quando le ricette sono realizzate correttamente, in passato non richiedevano molti interventi. Ma con questo AI Pilot che include gli LLM, l’aggiunta di un nuovo fornitore nella miscela, tutte queste operazioni possono richiedere ancora meno intervento manuale rispetto a prima.

Conor Doherty: Ok, Joannes, grazie. Siamo arrivati a circa 40 minuti. Ci sono domande a cui rispondere, quindi adesso ci sposteremo su quello. Ma prima di farlo, come riepilogo o pensiero conclusivo, sempre nel contesto della conversazione molto più ampia che abbiamo avuto un mese fa e ora quella che stiamo avendo oggi, qual è il punto fondamentale sia per il professionista della supply chain sia, diciamo, per i team esecutivi che supervisionano il tipico operatore della supply chain? Qual è il messaggio o l’invito all’azione per loro?

Joannes Vermorel: Credo che tra un decennio questa visione degli AI Pilots, magari sotto un nome diverso, diventerà la norma. Forse diventerà così la norma che le persone diranno semplicemente supply chain e non AI Pilots per la supply chain. Ed è scontato che, nella supply chain, ci siano quegli AI Pilots. Proprio come quando dici di avere un computer, non dici “ho una CPU, ho della memoria”, è implicito che un computer abbia una CPU, quindi non la menzioni nemmeno.

La mia opinione è che, fra circa un decennio, queste funzioni saranno ampiamente automatizzate e Lokad, con quegli AI Pilots, offrirà un pacchetto che lo fa assieme a un Supply Chain Scientist. Per i nostri clienti, ciò significa che la pratica della supply chain cambia per natura. Significa che disporranno di quegli AI Pilots che possono liberare molta capacità. E stavamo già liberando banda per il processo decisionale o per i calcoli complessi. Ma ora stiamo anche liberando il tempo che era speso per monitorare la lista degli SKUs, la lista dei fornitori, la lista dei clienti, solo per mantenere i master data corretti, puliti e in ordine. Tutto ciò sparirà, eliminando la necessità di quegli interventi manuali che, molto spesso, non erano nemmeno veramente quantitativi per natura. Bisognava correggere un’etichetta, sistemare un’inserzione, rimuovere un duplicato o qualcosa del genere. E tutto ciò, ancora una volta, Lokad se ne occuperà.

Quindi, in sostanza, si tratta di un enorme miglioramento della produttività. Penso che con alcuni clienti stiamo letteralmente ottenendo questa riduzione del 90% in termini di personale per le attività ripetitive. La realtà è che ora hai più tempo da dedicare a fare quelle cose che sono molto più difficili da automatizzare e credo che ciò aggiunga ulteriore valore. Vale a dire, pensare attentamente alla strategia, dedicare molto più tempo a riflettere sulle opzioni, su cosa dovresti esplorare invece di sprecare nuovamente il tuo tempo con i fogli Excel.

Quindi, dedica molto tempo a riflettere intensamente sui problemi difficili e poi parla con i fornitori e con i clienti, intraprendi conversazioni veramente approfondite in modo da poter organizzare la tua supply chain per rendere felice il tuo fornitore, e così questi sarà disposto a offrirti prezzi migliori, qualità superiore, maggiore affidabilità, ecc. Se ti organizzi per soddisfare le esigenze dei tuoi fornitori, può sembrare all’inizio il contrario, come se dicessi “Oh, fornitori, io sono il cliente, dovete accontentarmi”. Ma se riesci ad accontentare meglio i tuoi fornitori, si crea un lavoro di squadra e otterrai maggiore affidabilità e prezzi migliori.

E puoi fare lo stesso anche con il tuo cliente, perché deve esserci quella medesima collaborazione. E, ancora, ci vuole molta discussione intelligente ed è proprio in queste situazioni che gli LLM attuali non riescono a fornire. Quindi credo che Lokad possa automatizzare i compiti che hanno poco valore, le minutiae e le attività clericali banali, lasciando alle persone il compito, di livello superiore e semi-strategico. Dico semi-strategico perché parlerai con un cliente alla volta e poi elaborerai la strategia, che consiste nel riassumere tutto, creare una visione e poi supportare la leadership della supply chain affinché abbiano una strategia molto chiara e ben fondata per la loro azienda.

Conor Doherty: Quindi, ancora, per fare due esempi per concettualizzare: le decisioni di basso livello, passare in rassegna un foglio Excel dicendo, “Oh, c’è scritto ‘block in colors’ e quindi deve essere nero”, come se lo stessi autocorreggendo, sono banali, sono mundani, non valgono il tuo tempo. “Dovrei aprire un warehouse ad Amburgo?” Strategico.

Joannes Vermorel: Sì, è strategico. Inoltre, il problema è che ci sono così tante opzioni. Potresti dire: per un warehouse, dovrei comprare o affittare, che tipo di contratti stipulare, qual è il grado di meccanizzazione, ho bisogno di un contratto per l’attrezzatura che mi consenta di restituirla, oppure dovrei noleggiare l’attrezzatura o meno. Voglio dire, ci sono letteralmente centinaia di domande e, molto spesso, quando le persone devono spendere il 99% della loro capacità mentale in compiti clericali, non hanno tempo per dedicarsi a quelle grandi questioni.

Vedi, se applicassi la Legge di Parkinson, la gente direbbe: ho visto molte aziende in cui, se dovessi calcolare la somma totale dei minuti spesi in qualcosa come le ABC classes, ogni anno si parla di anni-uomo investiti nelle ABC classes. E quando si tratta di decidere per un nuovo warehouse, si parla di settimane di tempo. Ma vedi l’imbalzo in cui, collettivamente, le persone sprecano letteralmente anni di tempo umano per qualcosa di completamente insensato come le ABC classes. E quando si tratta di un investimento di 50 milioni di euro per aprire un warehouse, sono letteralmente settimane di tempo e poi, bam, viene presa una decisione. Dovrebbe essere al contrario.

Conor Doherty: Bene, grazie per questo. Su questa nota, passo alle domande del pubblico. Grazie mille. Sentitevi liberi di inviarle finché, fondamentalmente, non interrompo. Quindi, Joannes, questa domanda viene da Massimo. Potresti elaborare per favore su come l’IT può sfruttare gli AI Pilots per ridurre l’arretrato e perché credi che questo approccio debba essere proposto?

Joannes Vermorel: Gli AI Pilots non servono a ridurre l’arretrato dell’IT, ma a far fronte al fatto che l’IT ha anni di arretrato. Quindi, il nostro piano in Lokad non è quello di ridurre l’arretrato dell’IT. Richiede di ripensare l’IT come ha fatto Amazon. Questo sarebbe un altro episodio. Direi di cercare il memo del 2002 di Jeff Bezos sulle API in Amazon. In sostanza, tutti i reparti di un’azienda moderna hanno bisogno di una marea di software. Ogni divisione – marketing, finanza, contabilità, supply chain, vendite – vuole un sacco di strumenti software e tutto ciò ricade sulle spalle dell’IT. L’IT sta crollando sotto questo peso.

Quindi, il mio punto è che in Lokad siamo specialisti della supply chain. Non ci occuperemo di tutto ciò che riguarda marketing, vendite, contabilità e simili. Quello che diciamo è che, con gli LLM, possiamo liberare l’IT dalla gestione di Lokad. In sostanza, passiamo dal bisogno, diciamo, di 10-20 giorni di lavoro da parte dell’IT per far partire l’iniziativa Quantitative Supply Chain e costruire il pipeline, a sole poche ore. Quindi, non stiamo risolvendo l’arretrato. L’IT fa quello che sa fare. Anche loro possono beneficiare degli LLM, ma nel loro caso le situazioni sono molto più diverse, molto più difficili.

So, la mia proposta non è che gli LLM possano effettivamente aiutare l’IT a ridurre i ritardi. È solo un modo per Lokad, in questo caso specifico, di dire: “Beh, invece di aggiungere 20 giorni in più al ritardo, ne aggiungiamo qualcosa come quattro ore e basta.” È così che affrontiamo il ritardo. E poi, più in generale, la soluzione a quegli anni di ritardo è che ogni singola divisione deve internalizzare la maggior parte delle questioni software. Vedi, gli anni di ritardo derivano dal fatto che, in generale, le aziende richiedono troppo all’IT. Dovrebbe esserci una pratica digitale in ogni divisione – marketing, vendite, contabilità e via dicendo. Non dovresti chiedere all’IT di risolvere tutti quei problemi per te. Dovresti avere esperti digitali in ogni area per farlo. Ed è esattamente l’essenza di questo memo del 2002, se non confondo, di Jeff Bezos per il suo team. È un memo molto famoso. Puoi cercare “famous memo Bezos” perché stava dicendo, in sostanza, “Avete due settimane per avere un piano che permetta a ogni divisione di esporre tutti i vostri dati in modo da non avere questo tipo di siloing e giochi di potere in atto nell’azienda, in Amazon.”

E Bezos stava concludendo, “Ogni singolo manager che non avrà un piano sulla mia scrivania tra due settimane viene licenziato o qualcosa del genere.”

Conor Doherty: Va bene, grazie. Questo commento successivo – ed è una domanda che non ho posto perché ho visto che era menzionata nei commenti, quindi è formulata come commento ma va preso come domanda – è di Jesse. “One Supply Chain Scientist plus one LLM still sounds like a copilot. So again, delineate AI Pilot versus copilot.”

Joannes Vermorel: Il motivo per cui diciamo che è un pilot è perché abbiamo alcuni clienti per i quali, per settimane, tutte le decisioni vengono generate e poi eseguite senza supervisione. E quando dico senza supervisione, lo intendo davvero. Durante i lockdown del 2020, abbiamo addirittura avuto un’azienda in cui, per 14 mesi, tutti i lavoratori impiegatizi rimanevano letteralmente a casa, senza lavorare, pagati dallo Stato perché lo Stato concedeva sussidi in Europa. Diversi stati concedevano sussidi per restare fondamentalmente a casa e non lavorare. E così, quella era la situazione. Quindi, abbiamo avuto quel caso e, quando hai una supply chain che opera praticamente senza supervisione per 14 mesi, io la chiamo pilot, non copilot. Se non c’è nessuno a supervisionare i numeri generati dal sistema, penso davvero che sia un pilot.

Ma allora non stavamo utilizzando un LLM. E si trattava di una situazione in cui i dati erano puliti e non c’era una necessità drammatica di migliorare questa gestione dei dati master. E quel cliente aveva una maturità molto elevata in termini di integrazione EDI e simili. Quindi, le cose di questo tipo richieste prima e dopo erano molto, molto limitate.

Comunque, tornando alla questione del copilot. La maggior parte dei concorrenti di Lokad sostiene di realizzare un copilot. E infatti, il modo in cui lo fanno – ed è una cosa completamente diversa – è che Lokad, the Supply Chain Scientist, utilizza un linguaggio di programmazione. Quindi, quando usiamo un LLM, è per generare, per aiutarci a generare parti di un programma. È a questo che lo usiamo.

Quindi, l’LLM viene utilizzato per generare essenzialmente parti di programmi che possono essere i dialetti SQL o alcune altre cose. E poi costruiamo il pilot e il pilot funziona senza supervisione.

I nostri concorrenti, specialmente quelli che sostengono di voler portare sul mercato l’AI conversazionale, l’interfaccia utente conversazionale, fanno qualcosa di completamente diverso. Quello che fanno è tipicamente il retrieval augmented generation (RAG). Quindi, quello che fanno è comporre un prompt. Comporranno – ed è letteralmente questo che fanno tutti i nostri concorrenti che dichiarano di fare AI con LLM attualmente nello spazio della supply chain – una dozzina di prompt adatti a vari scenari. Poi, dopo il prompt, iniettano dati recuperati dal database, sai, che possono essere delle statistiche descrittive di base. Iniettano quindi alcune decine di numeri, vendite medie della scorsa settimana, dell’ultimo mese, dell’ultimo anno, o qualunque altra statistica di base adatta allo scenario. E poi aggiungono l’ulteriore query dell’utente e l’LLM completerà la risposta.

Vedi, dunque ancora una volta, gli LLM si limitano al completamento di testo. Componi un testo e lui lo completa. E il retrieval augmented generation – la parte di retrieval – consiste semplicemente nel recuperare alcuni numeri dal database per poi comporre. Ma il punto fondamentale è che, ok, ora ottieni qualcosa su cui puoi fare una domanda. Ma la realtà è che, se non sei completamente inesperto, puoi leggere i numeri direttamente dallo schermo. Non c’è magia. Quindi, l’LLM vede semplicemente i numeri proprio come li vedi nel report. Fondamentalmente, può rispondere solo a domande che vengono immediatamente risposte da un dashboard.

Quindi sì, se non conosci bene la definizione di ogni numero, lui può chiarirtela. Ma puoi anche avere – ed è qui che Lokad lo fa – una sorta di cheat sheet che fornisce una descrizione sintetica associata a ogni dashboard, per ogni numero presente sul dashboard. E questo svolgerà esattamente lo stesso ruolo, senza che venga utilizzata AI.

Quindi, in sostanza, sono molto, molto scettico riguardo a quelle AI conversazionali, quei copilots, perché essenzialmente sono stratagemmi che si aggiungono sopra sistemi esistenti, che non sono mai stati progettati per alcun tipo di sistema di machine learning, neppure del tipo classico, per non parlare degli LLM.

Per questo dico che, per quanto ne so, tutti i nostri concorrenti realizzano dei copilot in cui sostanzialmente hanno qualcosa che è, diciamo, un chatbot posto sopra dei dashboard. Ma non fa alcuna automazione. Non ti permette di automatizzare nessun tipo di AI Pilot. È, sì, un trucco su un sistema legacy.

Conor Doherty: Va bene, grazie. Proseguo. Questa è di Kyle. “Puoi per favore discutere l’importanza dell’analisi dei processi prima di istituire un modello AI?” La interpreterò nel contesto della supply chain.

Joannes Vermorel: Per sorprendere quanto possa sembrare, l’analisi dei processi è molto importante. Ma non necessariamente nei modi in cui la gente la pensa. La realtà è che, soprattutto nelle supply chain, le aziende hanno avuto quattro o cinque decadi per inventarsi una marea di processi inventati – e dico “inventati” intenzionalmente. La supply chain è un gioco di burocrazia. Ha un nucleo burocratico. Il gioco della supply chain negli ultimi cinquant’anni è stato un modo per organizzare il lavoro, perché non si può avere una sola persona che si occupa di tutti gli SKU, di tutti i magazzini, di tutte le sedi, di tutti i prodotti. Quindi, occorre dividere e conquistare il problema, distribuendo il carico di lavoro su dozzine, possibilmente centinaia di persone in aziende grandi, molto grandi.

Quindi, finisci per trovarti in una situazione in cui il 90% dei tuoi processi riflette semplicemente le complicazioni emergenti dovute al fatto che il carico di lavoro è distribuito su molte persone. Vedi, si tratta di processi accidentali, non essenziali. Quindi, direi che sì, occorre fare l’analisi dei processi, ma attenzione: il 90% dei processi esistenti non affronta il problema fondamentale che la tua supply chain deve risolvere, bensì problemi accidentali creati dal fatto che occorrono molte persone per risolvere il 10% del problema che invece necessita di essere risolto.

In industrie come quella della lavorazione chimica, dove ci sono molti flussi e dipendenze, è molto complicato. Ad esempio, quando hai reazioni chimiche, si generano sottoprodotti. Quindi, ogni volta che produci un composto, ne produci anche un altro. Quest’altro può essere venduto o utilizzato per un altro processo. Devi coordinare tutto ciò. Hai innumerevoli vincoli, processi che operano a lotti e processi che operano in modo continuo. È molto complicato.

Ma la realtà è che la maggior parte dei processi, anziché concentrarsi sulla fisicità del problema – sul fatto che, diciamo, in un’industria di processo, le reazioni chimiche hanno input e output molto specifici e tutto ciò è chiaramente definito e noto – invece di concentrarsi sul livello base della realtà fisica della tua attività, l’analisi dei processi potrebbe semplicemente fare il reverse engineering di processi che scompariranno quando verrà implementato l’AI Pilot.

La cosa interessante è che, quando lo fai in stile AI Pilot, non serve più questo approccio divide et impera. È un insieme unificato di ricette numeriche che risolvono il problema end-to-end. Quindi, tutti quei problemi di coordinamento che venivano risolti attraverso innumerevoli processi spariscono.

La mia esperienza è che il 90% di quei processi scomparirà una volta terminato il lavoro. Per questo dico che è molto importante mantenere un focus netto sul livello fisico di base della tua supply chain, piuttosto che sui processi inventati che servono solo a coordinare numerosi team. Quelle cose non verranno aggiornate, saranno sostituite dall’AI Pilot.

Conor Doherty: Grazie. E, infatti, un esempio che hai citato in quella risposta fornisce un bel collegamento qui. Quindi, da un utente, Durvesh, hai in programma di rendere open source Envision per uso educativo o per piccole imprese? E può essere programmato con regole per avvantaggiare aziende B2B, come quelle chimiche che richiedono un ingresso manuale estensivo?

Joannes Vermorel: Sì, abbiamo in programma di rendere open source Envision a un certo punto. Ma lascia che spieghi prima il perché. In questo mondo del software aziendale, disponiamo di una documentazione pubblica per Envision. La maggior parte dei miei colleghi ha linguaggi specifici di dominio (DSL), ma questi non sono documentati pubblicamente. Dassault Systèmes ha acquistato un’altra azienda chiamata Quintiq. All’epoca, veniva fornito con un DSL, non documentato pubblicamente. Quindi, letteralmente, nello spazio della supply chain, ci sono altre aziende che possiedono DSL e non sono pubblici. In Lokad documentiamo tutto pubblicamente e abbiamo un free sandbox environment per Envision. Abbiamo anche free workshops disponibili in modo che tu possa effettivamente insegnare o imparare Envision con esercizi. Quindi stiamo facendo molto di più.

Ora, per quanto riguarda il rendere open source un linguaggio, fa parte del piano, ma è troppo presto. Perché? Perché Envision è ancora in rapida evoluzione. Vedi, uno dei problemi che hai quando rendi open source un compilatore – il compilatore è un software che ti permette di tradurre il tuo script in qualcosa che si esegue – è che non appena rendi open source il compilatore, significa che le persone opereranno il codice Envision, nel caso di Lokad, liberamente. E Lokad perde la possibilità di aggiornare automaticamente quegli script. La realtà è che, nell’ultimo decennio, Lokad ha modificato centinaia di volte il linguaggio di programmazione Envision. Questo linguaggio non è stabile. Se dai un’occhiata al mio libro, il libro Quantitative Supply Chain che ora ha circa sei anni, vedrai che la sintassi di Envision è cambiata in modo drastico. Puoi addirittura notare una sintassi vestigiale che non esiste più in Envision.

Allora, come gestiamo questo costante cambiamento di sintassi? Beh, ogni settimana in Lokad rilasciamo aggiornamenti il martedì e applichiamo delle riscritture automatiche per tutti gli script Envision eseguiti sulle piattaforme Lokad. Quindi, una delle proprietà chiave di Envision è avere – direi – una forte affinità per l’analisi statica. E l’analisi statica è, tra l’altro, un ramo della progettazione e dell’analisi dei linguaggi. Quando dico linguaggio, intendo il linguaggio informatico, che ti permette di ottenere informazioni sui programmi senza eseguirli. E, attraverso l’analisi statica, possiamo letteralmente riscrivere automaticamente uno script esistente dalla vecchia sintassi a quella nuova. E lo facciamo automaticamente il martedì. E, tipicamente, quando facciamo un aggiornamento, per alcuni giorni accettiamo sia la vecchia che la nuova sintassi. Effettuiamo le riscritture automatiche e poi, quando notiamo che la sintassi antica non esiste più, noi, mediante un feature flag, fissiamo il fatto che esista solo la nuova sintassi.

E Lokad, abbiamo già implementato centinaia di quelle riscritture automatiche. Di solito, le rilasciamo ogni martedì, ma in media ne facciamo circa due al mese, e lo facciamo da un decennio. Quindi, fintanto che questo processo continua, in Lokad non possiamo realisticamente rilasciare Envision come open source. Verrà rilasciato a tempo debito, ma non voglio ripetere il massiccio errore di Python. L’aggiornamento da Python 2 a Python 3 ha richiesto alla comunità Python un decennio ed è stato incredibilmente doloroso. Voglio dire, le aziende hanno passato anni ad aggiornarsi; è stato un incubo che è durato un decennio. Quindi, è stato davvero, davvero sbagliato. Persino Microsoft, con l’aggiornamento da C# e il .NET framework a .NET core, ha impiegato mezzo decennio ed è stato un grande, grande dolore. E questo, ancora una volta, evidenzia il problema: una volta che hai un compilatore open source in libertà, non controlli il codice. Quindi, se vuoi apportare modifiche al linguaggio, devi collaborare con la tua comunità. Questo rende il processo estremamente lento, doloroso e, alla fine, non elimini mai veramente tutte le cattive caratteristiche del tuo linguaggio.

Se guardiamo a Python, per esempio, il modo in cui è stata introdotta la programmazione orientata agli oggetti, la sintassi – ah, è goffa. Si percepisce davvero che Python non è stato progettato con la programmazione orientata agli oggetti in mente. È stata un’aggiunta successiva alla fine degli anni ‘90 e la sintassi è piuttosto scadente, ed ora ci sta per sempre. E, tra l’altro, ogni linguaggio ha questo problema. In C#, hai la parola chiave volatile che ormai non ha più una funzione. Il C++ è bloccato per sempre con l’ereditarietà multipla. È stato un errore. Avere l’ereditarietà multipla è stata una decisione di design sbagliata che complica tutto, ecc. L’unico modo per poter evitare quegli errori gravi – in Lokad abbiamo commesso molti grandi errori nel design di Envision, ma li correggiamo uno dopo l’altro, e siamo ancora in fase di aggiustamento, soprattutto quando arrivano nuovi paradigmi. Ad esempio, la differentiable programming è stato un grande nuovo paradigma e abbiamo dovuto riprogettare il linguaggio stesso per adattarlo a questo paradigma.

A proposito, c’è una grande mega proposta per Swift, proposta da Apple, per rendere la differentiable programming un cittadino di prima classe in Swift. Ma probabilmente non succederà nel prossimo futuro. È come un grande, grande rinnovamento. Al momento, il linguaggio più vicino ad avere la differentiable programming come cittadino di prima classe sarebbe Julia e, anche lì, è fatto per lo più con molto nastro adesivo.

Conor Doherty: Grazie ancora. Restano ancora tre domande da affrontare. La prossima è di Victor. Si tratta fondamentalmente di AI. Come fa l’AI ad affrontare colli di bottiglia casuali, dato che opera su grandi data set per prevedere scenari plausibili o problemi ricorrenti?

Joannes Vermorel: Sia chiaro, quando parliamo di AI, intendiamo un insieme di tecniche. In Lokad, tipicamente usiamo LLMs, programmazione differenziabile e ottimizzazione stocastica. La programmazione differenziabile serve per apprendere, l’ottimizzazione stocastica per ottimizzare sotto vincoli in presenza di incertezza, il modello probabilistico che viene solitamente ricavato con la programmazione differenziabile, e gli LLMs servono per realizzare questo motore di templating universale, resistente al rumore.

Quando si affronta la supply chain con strumenti probabilistici, la maggior parte dei compiti impliciti in questa domanda semplicemente sparisce. Questa è la bellezza della previsione probabilistica: quelle previsioni non sono più accurate, ma sono molto più resistenti al rumore ambientale della supply chain. Quando abbini la previsione probabilistica con l’ottimizzazione stocastica, elimini in gran parte la necessità di interventi manuali. E quando dico “in gran parte”, intendo dire che, per la maggior parte dei clienti, viene completamente eliminata. E ora rimaniamo con compiti che richiedono di analizzare il testo e gestirlo, ed è qui che entrano in gioco gli LLMs. Inoltre, quanto descritto corrisponde a Lokad: abbiamo quegli AI Pilots che sono veramente automatizzati e, se c’è un intervento manuale, non serve per fare una semplice immissione clericale nel sistema, ma per inserire una revisione strategica della ricetta numerica, che di solito comporta una modifica profonda della logica stessa per riflettere la strategia rivista. Non sarà una questione di poco conto; sarà qualcosa di fondamentale che cambia la struttura della logica implementata.

Conor Doherty: Questa domanda è di Ahsan. Potresti spiegare come l’AI, in particolare, accelererebbe un ordine? Sarebbe in grado di eseguire transazioni nel sistema ERP basandosi su comandi vocali?

Joannes Vermorel: I comandi vocali non sono l’approccio giusto a questo problema. Se ciò che desideri è una maggiore velocità nell’inserimento dei dati, la voce rappresenta un canale a larghezza di banda molto bassa. Si digita più rapidamente che si parla, a meno che non si sia veramente pessimi nella digitazione. Quindi, questo non è il tipo di vantaggio che puoi ottenere. Se la tua interfaccia utente è progettata correttamente con una tastiera, sarai più veloce rispetto ai comandi vocali. Lo so molto bene, perché 20 anni fa lavoravo in AT&T Labs, all’avanguardia dei sistemi di riconoscimento vocale di livello industriale. C’erano innumerevoli applicazioni in cui non funzionava. Il riconoscimento vocale funzionava, ma la realtà era che le mani sulla tastiera erano semplicemente più veloci. Le situazioni in cui si ricorre alla voce erano quando le mani erano sporche o occupate. Altrimenti, la tastiera è nettamente più rapida.

Tornando alla domanda, innanzitutto bisogna filtrare gli ordini. Qui abbiamo un processo decisionale in cui si deve decidere quali ordini necessitano di essere accelerati. È il classico esempio di Lokad, un processo decisionale puramente quantitativo. Devi decidere, sì o no, se un ordine in corso giustifica una richiesta di accelerazione del processo. Lo faremmo utilizzando la programmazione differenziabile e l’ottimizzazione stocastica. È così che arriviamo alle decisioni corrette.

Una volta fatto ciò, otteniamo automaticamente, ogni giorno, le decisioni per gli ordini. Non si tratta di avere qualcuno che dia ordini vocali per questo. Farà parte del set di ricette numeriche con cui calcoleremo gli ordini ottimizzati. Col passare del tempo, ci accorgeremo che alcuni ordini hanno superato o non raggiunto il target e richiederemo, rispettivamente, un rinvio o un’accelerazione. La parte degli LLMs consiste semplicemente nel trasformare questa decisione quantitativa, in cui hai una bandiera binaria che indica “per favore, accelera”, in un’email con il contesto appropriato, da inviare al fornitore con un messaggio del tipo “per favore, conferma che puoi farlo”, e poi il fornitore, si spera, risponderà “sì”, “no”, “forse posso” o “questo è ciò che posso offrire”.

Gli LLMs automatizzeranno la chat con il fornitore. L’AI non si occupa di decidere di accelerare l’ordine. Quella è una decisione puramente quantitativa che deve essere affrontata con strumenti quantitativi, come la programmazione differenziabile e l’ottimizzazione stocastica. Gli LLMs sono utilizzati per l’interazione con il fornitore, che frequentemente utilizza un canale non strutturato, come l’email.

Se stai pensando ai comandi vocali, non funzioneranno. Sono troppo lenti. Ho avuto il privilegio di lavorare con i team che, letteralmente, hanno portato sul mercato i primi sistemi di riconoscimento vocale di livello industriale 20 anni fa. Ma in definitiva, non userai quelle tecnologie AI per questo scopo. I comandi vocali non hanno la larghezza di banda per fare ciò che desideri.

Conor Doherty: A proposito, quando parliamo di ottimizzazione stocastica e programmazione differenziabile, abbiamo ampie risorse video su questi argomenti. Non ne entriamo nei dettagli perché si tratta di una serie in tre parti (parte 1, parte 2 e parte 3) sulla programmazione differenziabile, ma non li trascuriamo. Sono stati trattati e indirizzo cortesemente gli spettatori che desiderano approfondire l’argomento a consultarli e poi mettere insieme i vari elementi.

Ultima domanda, ed è di Isaac. In qualità di cliente che sta attualmente imparando Envision, sono interessato alle capacità di integrazione, in particolare con GitHub. Potresti illustrare il potenziale di Envision nel supportare l’integrazione con GitHub, in particolare per applicazioni quali spiegare blocchi di codice in linguaggio naturale o identificare le differenze tra versioni? Infine, è previsto l’introduzione di un copilot per Envision nel prossimo futuro?

Joannes Vermorel: La risposta breve è sì, sì e sì. Le tempistiche variano molto a seconda dei componenti di cui si parla. Per quanto riguarda l’utilizzo degli LLMs per realizzare fondamentalmente un copilot, simile al GitHub copilot, ma che sarà il Lokad copilot per i codici Envision, ci stiamo già lavorando. La cosa molto interessante è che, essendo un DSL su cui abbiamo controllo completo, controlliamo interamente i materiali di addestramento. Questo è estremamente positivo, perché significa che nel giorno in cui riusciremo a portare questo LLM in produzione, ogni volta che cambieremo la sintassi, rilanceremo il processo di addestramento con la sintassi aggiornata e avremo sempre un copilot che ti fornirà la sintassi Envision più aggiornata. A differenza del GitHub copilot, che ti offre una sintassi per Python, per C# o per Java.

Perché, vedi, Java esiste da 25 anni, Python da oltre 30 anni, e C# da circa 22 anni o giù di lì. Quindi, ogni volta che chiedi al compilatore di GitHub di scrivere codice per te, il problema è che ti fornisce una versione semi-recente di quei linguaggi, ma non una versione veramente aggiornata. E talvolta non vuoi la versione recente, perché il tuo ambiente non è in linea con quelle versioni super recenti che ancora non supporti.

Stiamo lavorando su una serie di funzionalità davvero innovative, come “commenta il mio codice”, “spiega il mio codice”, “completa il mio codice”. Stiamo inoltre pianificando numerose azioni estese sul codice che sono molto specifiche per i flussi di lavoro che si verificano all’interno di Lokad. Ad esempio, ci stiamo adoperando per automatizzare la generazione di dashboard per la salute dei dati. È un compito molto tipico.

Le dashboard per la salute dei dati sono essenzialmente strumenti che verificano che i dati che riceviamo siano attendibili. Abbiamo una notevole esperienza e competenza su cosa controllare, perché i tipi di problemi che si incontrano nei dati degli ERP sono in qualche modo sempre gli stessi. Quando verifichiamo la correttezza dei dati provenienti da un ERP, i Supply Chain Scientists hanno sviluppato, letteralmente, metodi di addestramento propri per sapere cosa cercare e abbiamo le nostre ricette, insomma ricette umane, di cosa implementare e controllare, e potremmo automatizzare in gran parte questo processo con gli LLMs. Quindi, questo è un aspetto su cui stiamo lavorando in Lokad.

Stiamo lavorando su un Lokad copilot. Per rendere Envision più fruibile con GitHub, abbiamo già rilasciato un open-source Visual Studio code extension. Puoi già inserire il codice Envision in un repository git. Basta creare un file .nvn, fare il commit e il gioco è fatto. Se desideri modificare il codice con una bella colorazione, avrai bisogno di un’estensione per Visual Studio Code. Se cerchi l’estensione Lokad per Visual Studio Code per Envision, ce n’è una completamente open source che fornisce la colorazione del codice.

In futuro, prevediamo di esporre il codice Envision presente in un account Lokad come un repository git. Il modo in cui il codice Envision è memorizzato in un account Lokad è molto simile a un repository git; è versionato praticamente nello stesso modo. Non è organizzato esattamente come git – e, di nuovo, non entrerò troppo nei dettagli tecnici. Git è estremamente agnostico rispetto al linguaggio. Se ti occupi solamente di un linguaggio in particolare, puoi adottare soluzioni più intelligenti e fare molte cose che non sarebbero possibili nel caso generale. Ma, in definitiva, il codice Envision è interamente versionato. Potremmo esporre un repository git che ti permetta di esportare tutto il tuo codice da un account Lokad a un repository git e, forse in seguito, di realizzare una sincronizzazione bidirezionale. Git è un sistema decentralizzato, in cui ogni repository git è come l’intero sistema: hai una copia completa, quindi puoi ricevere modifiche da un repository remoto e inviare le tue modifiche a tale repository. E così, a un certo punto, potremmo introdurre – probabilmente prima l’esportazione e poi la reimportazione – ma ci vorrà del tempo. Non siamo ancora a quel punto. Fa parte della roadmap, ma non abbiamo ancora una tempistica definita.

Conor Doherty: Vale la pena sottolineare che alcune persone nei commenti hanno affermato di star imparando Envision. Produciamo una serie di tutorial realizzati in collaborazione con l’Università di Toronto e altri, attualmente in preparazione. Esistono risorse gratuite e possiamo fornire ulteriori risposte a chi lo desidera. Per chiunque voglia imparare, i nostri Supply Chain Scientists mettono un enorme impegno in quei workshop. Sono liberamente disponibili sul nostro sito web.

Joannes Vermorel: Per coloro che non sono interessati a diventare Supply Chain Scientists, Lokad può fornire il Supply Chain Scientist come parte dell’offerta AI Pilot.

Conor Doherty: Sono tutte le domande, Joannes. Grazie mille per il tuo tempo e grazie a tutti per averci seguito. Spero che sia stato utile e alla prossima.