AI Pilots nella Supply Chain - Ep 159

00:00:00 Introduzione all’intervista
00:01:01 L’impatto dell’IA sui lavori tradizionali
00:04:36 Automazione dell’IA nella 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’IA
00:16:11 Impatto e ritardi dovuti al backlog IT
00:20:04 Confronto tra l’infrastruttura di Lokad e altri fornitori
00:23:06 Discussione sulle allucinazioni e confabulazioni di LLM
00:30:38 Sottolineare il progresso rispetto alla perfezione nell’IA
00:33:00 Recupero delle informazioni mancanti e ETA degli ordini
00:36:17 Compiti quantitativi e LLM nella supply chain
00:38:28 Futuro degli AI Pilots nella supply chain
00:41:18 Valore delle conversazioni e automazione dei compiti di basso valore
00:44:57 Sfruttare gli AI Pilots per ridurre il backlog
00:49:00 AI Pilot vs copilota e scenario di lockdown
00:53:36 Scetticismo verso l’IA conversazionale e l’analisi dei processi
00:57:18 Comprendere la realtà aziendale e l’IA che sostituisce i processi
01:00:12 Sfide dell’open source di Envision
01:06:21 Approccio dell’IA ai collo di bottiglia e alla supply chain
01:09:17 Inefficienza dei comandi verbali e automazione degli ordini
01:14:12 Supply Chain Scientist come copilota per AI Pilot
01:17:32 Verifica della correttezza dei dati e automazione dei controlli con LLM
01:20:15 Rendere Envision compatibile con git
01:21:14 Risorse gratuite per imparare Envision

Riassunto

In un dialogo tra il CEO di Lokad, Joannes Vermorel, e il Responsabile della Comunicazione, Conor Doherty, discutono dell’impatto dell’IA sulla gestione della supply chain. Vermorel evidenzia i progressi nell’IA e nei grandi modelli di linguaggio, che hanno rivoluzionato l’automazione dei compiti. Introduce AI Pilots, un’offerta di Lokad che automatizza la presa di decisioni e i compiti amministrativi, facilitati dal linguaggio di programmazione proprietario di Lokad, Envision. Vermorel discute anche del potenziale dell’IA nell’automatizzare compiti legati ai dati Master e mette a confronto l’approccio di Lokad con i concorrenti. Prevede che gli AI Pilots diventeranno la norma nella gestione della supply chain, portando a significativi miglioramenti di produttività. La conversazione si conclude con una sessione di domande e risposte.

Riassunto Esteso

In una recente conversazione tra Conor Doherty, Responsabile della Comunicazione presso Lokad, e Joannes Vermorel, CEO e fondatore di Lokad, il duo ha approfondito il ruolo trasformativo dell’intelligenza artificiale (IA) nella gestione della supply chain. La discussione, continuazione di una conversazione precedente sull’impatto dell’IA sull’occupazione, si è concentrata sul potenziale dell’IA di agire come un pilota autonomo per la presa di decisioni nella supply chain.

Vermorel ha iniziato evidenziando il traguardo storico raggiunto dall’IA generativa e dai grandi modelli di linguaggio (LLM) nel 2023. Questi progressi, ha spiegato, hanno rivoluzionato l’automazione dei compiti che coinvolgono il testo, come la lettura delle email o la categorizzazione dei reclami. L’anno 2023 è stato particolarmente significativo in quanto ha visto una riduzione sostanziale del costo operativo delle tecniche di elaborazione del linguaggio naturale per le aziende. Vermorel ha previsto che ciò porterà all’automazione di molte funzioni di supporto interne, con le operazioni della supply chain in prima linea.

Vermorel ha poi presentato AI Pilots, un’offerta di Lokad che automatizza il processo decisionale e gestisce compiti amministrativi noiosi. Ha sottolineato l’approccio unico di Lokad, in cui un Supply Chain Scientist può prendere piena proprietà di un’iniziativa. Ciò è reso possibile dal linguaggio di programmazione proprietario di Lokad, Envision, dedicato all’ottimizzazione predittiva delle supply chain. Tuttavia, Vermorel ha ammesso che Lokad ha avuto difficoltà in passato nella ricerca dei dati e nella gestione di vari dialetti SQL.

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

Vermorel ha anche evidenziato il potenziale dei LLM nell’automatizzare molti compiti legati ai dati Master, tra cui rilevamento, monitoraggio e miglioramento. Ha messo a confronto l’approccio di Lokad con quello dei concorrenti, affermando che Lokad coinvolge di solito meno persone in un’iniziativa, con ciascuna persona competente in tutto il processo. Questo, ha argomentato, è in netto contrasto con i concorrenti che spesso coinvolgono molte più persone in un’iniziativa, tra cui project manager, consulenti, designer UX, amministratori di database, specialisti di rete e programmatori.

La conversazione si è poi spostata sul ruolo dei Supply Chain Scientists nella convalida o nel monitoraggio degli script generati dai LLM. Vermorel ha riconosciuto che i LLM possono talvolta produrre risultati inaccurati o “allucinati”, ma di solito sono corretti in direzione e possono essere corretti con poche iterazioni attraverso un ciclo di feedback. Ha suggerito che, sebbene i LLM possano commettere errori, possono comunque fornire molto valore e il loro tasso di falsi positivi e falsi negativi può essere misurato.

Vermorel ha spiegato ulteriormente 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 quotidiane della supply chain, gestendo i dettagli della preparazione dei dati e le decisioni sugli ordini di acquisto. Il cliente, in questa configurazione, è paragonato al capitano, che fornisce le direzioni strategiche generali.

Per quanto riguarda gli insegnamenti per i professionisti della supply chain e i team esecutivi, Vermorel ha previsto che tra dieci anni gli AI Pilot saranno la norma nella gestione della supply chain (SCM). Questo, secondo lui, porterà a un enorme miglioramento della produttività, con una potenziale riduzione del 90% delle risorse umane per le funzioni precedenti. Ha incoraggiato i professionisti della supply chain a dedicare più tempo al pensiero strategico e alle conversazioni approfondite con fornitori e clienti.

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

Trascrizione completa

Conor Doherty: Benvenuti a Lokad live. Mi chiamo Conor. Sono il responsabile delle comunicazioni qui a Lokad. E sono qui in studio con il fondatore di Lokad, Joannes Vermorel.

L’argomento di oggi è come l’AI può agire come un pilota autonomo per la presa di decisioni nella supply chain. Sentitevi liberi di inviare le vostre domande in qualsiasi momento nella chat di YouTube e le affronteremo tra circa 30-35 minuti.

E con questo, Joannes, gli AI Pilot nella supply chain mi sembra che questa conversazione sia molto un’estensione di quella che abbiamo avuto, penso circa quattro settimane fa, in cui abbiamo parlato delle implicazioni dell’AI sull’occupazione e sul futuro dei lavori tradizionali rispetto all’AI nella supply chain.

Quindi, prima di entrare nei dettagli degli AI Pilot, potresti dare, per chi non l’avesse visto, un ripasso, un riassunto esecutivo, qual è la nostra prospettiva sui lavori tradizionali rispetto all’AI nella supply chain?

Joannes Vermorel: Il ripasso è che è stato raggiunto un traguardo praticamente nel 2023. Questo traguardo è l’AI generativa e più specificamente i large language models (LLM). In termini di pura ricerca, è solo una continuazione di quasi quattro-cinque decenni di miglioramento continuo nell’apprendimento automatico. Quindi se guardiamo a questo da una prospettiva di ricerca, il 2023 è solo un anno come gli altri con una lunga sequenza di progressi. E ci sono stati progressi relativamente rapidi negli ultimi due decenni.

Ora, nel 2023, ciò che arriva sul mercato è l’AI generativa confezionata per immagini e, cosa più importante, per il testo. E c’è un prodotto che ha reso popolare questo concetto, si tratta di ChatGPT di OpenAI. Cosa significa? Significa molto specificamente, soprattutto per quei large language models, che hai una macchina di modellazione universale resistente al rumore.

Ciò significa che tutti i passaggi per il software aziendale, sto parlando nel contesto dei lavoratori come se fossero lavoratori impiegati in ambienti aziendali, significa che tutti i passaggi che in passato non potevano essere automatizzati perché dovevamo gestire il testo in qualsiasi forma, significa leggere una e-mail, estrarre un riferimento o un prezzo da una e-mail o una quantità o categorizzare il tipo di reclamo o richiesta da un partner o fornitore cliente da una e-mail, identificare se una etichetta di prodotto è insensata, ad esempio se la descrizione del prodotto manca, okay abbiamo un problema, tutte queste cose in passato non potevano essere fatte facilmente. Potevano essere fatte in altri modi, ma non potevano essere facilmente automatizzate.

Se dovessimo tornare indietro di cinque anni, il text mining era già una cosa. Era già possibile avere classificatori di testo e utilizzare tutte le tecniche di elaborazione del linguaggio naturale, ma erano costose. Il 2023 è stato un punto di svolta perché tutti quei problemi dovuti al grado di confezionamento che è stato raggiunto con essenzialmente GPT-4 servito tramite un’API, significava che tutti quei problemi di tecniche di NLP, tecniche di elaborazione del linguaggio naturale, avevano i loro costi operativi per le aziende ridotti di un fattore di 100, se non di 1.000. Ciò significa che non solo il costo, ma anche il tipo di tempistica necessaria per configurare la cosa.

Quindi la conclusione, e questa è la mia previsione, è che molte funzioni di supporto nelle aziende che sono solo funzioni interne, che prendono alcuni dati in ingresso e producono un output per altre divisioni, saranno automatizzate. La supply chain è in prima linea perché non è esattamente una funzione rivolta al cliente. È molto più una funzione interna, importante ma interna. E quindi i casi in cui i large language models erano il mattone mancante per automatizzare in gran parte le operazioni noiose end-to-end nella maggior parte delle catene di approvvigionamento.

Lokad ha automatizzato l’analisi quantitativa e il processo decisionale quantitativo da un decennio, ma ci sono molte operazioni noiose che vengono prima e molte operazioni noiose che vengono dopo, ed è quella che può essere automatizzata grazie ai large language models, e in modo rapido ed economico.

Conor Doherty: Beh, grazie. E abbiamo già un video in cui abbiamo parlato, credo, per circa un’ora e mezza su questo argomento, quindi non dedicherò altro tempo di oggi a questo, ma questo prepara il terreno per il resto della conversazione. Invito cortesemente chiunque voglia saperne di più a rivedere il video precedente. Ora, su questo argomento, i piloti di intelligenza artificiale, come si inseriscono in tutto ciò che hai appena detto? Chi sono? Cosa fanno nella realtà?

Joannes Vermorel: L’intelligenza artificiale, in generale, è stata utilizzata costantemente negli ultimi due decenni dai fornitori come un termine generico per lanciare ciò che avevano. Quindi quando dico piloti di intelligenza artificiale, è molto un’offerta di Lokad. È un’evoluzione dell’offerta, è probabilmente la più grande che abbiamo avuto negli ultimi anni. E qual è la differenza? Beh, la differenza è che un pilota di intelligenza artificiale è qualcosa, è un pezzo di software, quello che chiamiamo una serie di ricette numeriche, che non solo esegue il processo decisionale, quindi questo è l’aspetto puramente quantitativo della supply chain, quindi letteralmente capire esattamente quanto ordinare, dove allocare le scorte, se devi alzare o abbassare i prezzi, come pianificare esattamente la produzione con tutti i passaggi, ecc.

Quindi quello che stavamo già facendo, più tutto ciò che viene prima e dopo in termini di compiti amministrativi noiosi che sono principalmente la gestione dei dati principali prima dell’analisi dei dati, e poi l’esecuzione della decisione che può coinvolgere canali non strutturati come le e-mail, ad esempio, dove si vuole inviare una e-mail a un fornitore per richiedere che qualcosa venga accelerato o, al contrario, che un ordine venga posticipato.

E l’essenza di questa offerta sono ovviamente i large language models che Lokad non ha inventato, che abbiamo utilizzato ampiamente per 14 mesi, un po’ più di quello adesso. E l’idea chiave del modo in cui Lokad opera è che dovrebbe essere uno scienziato della supply chain che è in grado di prendere piena proprietà di un’iniziativa.

Per le aziende molto grandi, potremmo avere diverse persone sul caso, ma a differenza della maggior parte dei nostri concorrenti, di solito non sono specializzate. Quindi non è come se prendessimo un team di tre persone con il signor Database, il signor Algoritmi e il signor UI e UX user experience. Questo è assolutamente non il modo in cui Lokad opera. Uno scienziato della supply chain è in grado di fare tutto dall’inizio alla fine.

E questo è uno dei motivi per cui Lokad ha progettato la propria tecnologia nel modo in cui lo ha fatto, e abbiamo il nostro proprio linguaggio di programmazione, un linguaggio di programmazione specifico del dominio chiamato Envision, dedicato all’ottimizzazione predittiva delle supply chain. Può sembrare molto strano aver creato un linguaggio di programmazione personalizzato, ma l’idea principale è che, e questa è una decisione che ho preso nel 2012, avevamo davvero bisogno di qualcosa che fosse unificato in modo che una persona potesse fare tutto, dall’inizio alla fine.

Fino a qualche anno fa, consisteva nel ottenere i dati di transazione grezzi dagli ERPs, CRMs, EDI e tutti quei sistemi transazionali, completarli con una serie di fogli di calcolo per tutti i dati strutturati che purtroppo fanno parte dell’IT ombra piuttosto che dell’IT regolare, e quindi creare le ricette numeriche per la presa di decisioni. E questa era responsabilità dello scienziato della supply chain fare tutto questo, quindi creare tutti gli strumenti, inclusi dashboard e report, per assicurarsi di convincersi che i numeri fossero corretti, ma anche per rassicurare i nostri stessi clienti sulla validità di ciò che stiamo facendo, oltre a tutti gli strumenti per monitorare la qualità delle decisioni nel tempo, oltre alla gestione dei dati per estrarli dai sistemi ma anche reinserire le decisioni nei sistemi stessi.

Quindi quello era lo scopo che aveva Lokad, e c’erano due cose che non potevamo davvero fare. Prima di tutto, dovevamo essere i destinatari dei dati, non potevamo davvero cercare i dati. E quando dico cercare, lo scienziato della supply chain poteva richiedere i dati, non chiedevamo alle divisioni IT dei nostri stessi clienti di fare alcun tipo di trasformazione complicata, era solo una questione di estrarre le tabelle, per esempio, select star from table, bam, lo fai una volta al giorno e sei a posto. Quindi erano solo estrazioni molto semplici, ma comunque era l’IT delle divisioni dei nostri clienti che faceva questo.

Non si aspettava che gli scienziati della supply chain cercassero nel panorama applicativo dei nostri clienti i dati necessari per l’iniziativa. Il motivo era molto semplice, ci sono circa 20 dialetti SQL là fuori, come Oracle SQL, Microsoft SQL Server T-SQL, MySQL, PostgreSQL, DB2 di IBM, ecc. Quindi ci sono circa 20 dialetti SQL. Fino a qualche anno fa, uno scienziato della supply chain avrebbe avuto enormi difficoltà anche solo perché anche se quello che questa persona voleva realizzare era estremamente semplice, come semplicemente estrarre una singola tabella, il problema era che questa persona avrebbe passato letteralmente decine di ore a cercare online di comporre query banali, e ogni volta che c’era un messaggio di errore, sarebbe stata di nuovo questa persona, anche se in generale era familiare con i database SQL, direi che era un ostacolo enorme dover affrontare dialetti di sistemi che non conoscevi.

Nel 2023, con ChatGPT, il problema è risolto. ChatGPT, come assistente programmatore, non è naturalmente super bravo a permetterti di comporre app sofisticate, ma quando si tratta di comporre query SQL molto semplici in dozzine di dialetti, è super veloce. Uno scienziato della supply chain richiederà di comporre una query SQL. Questa persona è anche intelligente e rileggerà la query per assicurarsi che rifletta l’intento. Si tratta solo di rimuovere 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, chiedi a ChatGPT di guidarti nella configurazione di git sulla tua macchina e di creare un repository git o qualsiasi altra cosa, vedrai che tipo di risposta di altissima qualità puoi ottenere.

Questo è davvero un cambiamento epocale perché significa che improvvisamente Lokad, che sta formando gli scienziati della supply chain, può assumersi la responsabilità di cercare i dati. E so che abbiamo, attraverso ChatGPT, gli strumenti per non sovraccaricarci dicendo che andremo a cercare i dati. È un cambiamento epocale. Invece di chiedere all’IT di inviarci i dati, possiamo semplicemente avere un indirizzo IP in whitelist e poi avere una connessione molto sicura da cloud a cloud, e quindi lasciare che il team di scienziati della supply chain cerchi i propri dati.

Perché fa così tanta differenza? Beh, la realtà è che anche se Lokad ha bisogno solo di giorni di lavoro per una determinata iniziativa, stiamo parlando di forse 10-20 giorni di lavoro per un’iniziativa di una certa entità per ottenere le 20-50 tabelle di cui abbiamo bisogno, è solo un dump della tabella, nessun incrocio, nessun join, nessun filtro complicato, è molto semplice. Tuttavia, il problema è che molti dei nostri clienti hanno le proprie divisioni IT che hanno enormi backlog. Voglio dire, letteralmente anni di backlog e quando hai come tre anni di backlog, anche se Lokad chiede solo 10 giorni, sono 10 giorni più tre anni di backlog, quindi anche se non siamo esattamente messi alla fine della coda, se siamo solo in mezzo alla coda, quei 10 giorni di lavoro dall’IT potrebbero richiedere un anno per essere completati e questo era, direi, una frustrazione che avevamo, ovvero che la maggior parte dei ritardi che stavamo ottenendo proveniva dall’IT che non era incompetente o lento, è solo che avevano così tanto backlog che era molto difficile per loro allocare quei 10 giorni.

Quindi qui abbiamo qualcosa in cui invece di richiedere 10-20 giorni di lavoro, stiamo parlando di qualcosa come meno di un giorno di lavoro, qualcosa come solo un paio d’ore, solo per aprire un accesso molto sicuro e stretto ai pochi sistemi di cui abbiamo bisogno. E poi gli stessi scienziati della supply chain si occuperanno di esaminare la tabella, impostare la logica di estrazione dei dati e assicurarsi che le estrazioni dei dati siano davvero, direi, leggere.

Il modo in cui possiamo farlo è tipicamente monitorando le prestazioni. Ogni volta che le prestazioni del database diminuiscono, significa che c’è molto in corso sul database e quindi di solito si vuole alleviare la pressione e ritardare il proprio processo di recupero dei dati. Perché tipicamente, da Lokad, abbiamo bisogno di aggiornare i dati su base giornaliera, ma non è super urgente. Voglio dire, di nuovo, dipende. Ci sono alcune situazioni in cui abbiamo scadenze molto strette, ma molto spesso, per quanto riguarda le supply chain, se ritardiamo il recupero di dati di 30 minuti solo perché c’è come un picco di attività su questo database in questo momento, non è un problema.

Il primo blocco di impegno è quello di cercare i dati noi stessi ed eliminare così la causa principale dei ritardi e accelerare notevolmente le iniziative. Di nuovo, questi ritardi diventavano molto spesso la maggior parte del ritardo per l’intera iniziativa di Lokad per arrivare in produzione era solo l’attesa che l’IT fosse in grado di allocare quei giorni.

Il secondo blocco di impegno è il miglioramento dei dati master. E qui, di nuovo, in passato, quando ci si trova di fronte a un catalogo in cui ci sono, diciamo, 100.000 descrizioni di prodotti, alcune di esse sono spazzatura, sai, forse l'1%. È molto lavoro passare attraverso queste 100.000 referenze, identificare le descrizioni o le etichette dei prodotti che sono errate o a volte può essere solo un prezzo completamente incoerente con la descrizione. Se dice una vite e il prezzo è di 20.000 dollari, probabilmente non è solo una vite, è probabilmente qualcos’altro, ecc. C’erano molti controlli di sanità di base che sembravano ovvi e semplici ma era molto difficile automatizzarli e spesso non c’era altra alternativa se non quella di far esaminare le voci a una persona per cercare cose che erano davvero sbagliate.

Con un LLM e potenzialmente un LLM in grado di elaborare anche le immagini, è possibile fare molte cose quando si tratta di analizzare, monitorare e migliorare tutto ciò che è correlato ai dati master. Nel caso specifico di Lokad, la parte dei dati master necessaria per pilotare le catene di approvvigionamento.

Conor Doherty: Beh, c’è molto da dire, grazie. Ho molte domande a cui vorrei approfondire. Voglio fare un piccolo passo indietro, perché se posso riassumere tutto ciò che hai detto, e correggimi se sbaglio, un Supply Chain Scientist con accesso a un buon LLM può fare un’enorme quantità di lavoro. Un lavoro che fino a questo momento avrebbe richiesto molto tempo e coinvolto molte persone. Ora, in un contesto non di tipo Lokad, quante persone in più sarebbero coinvolte? Quanti altri sarebbero coinvolti? E poi puoi parlare dell’efficienza, ma solo in termini di organico, qual è la differenza tra i Supply Chain Scientist con LLM e, ad esempio, S&OP?

Joannes Vermorel: I nostri clienti sono di solito stupiti 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 definitiva, Lokad è tipicamente l'1% dall’inizio alla fine. Se abbiamo più persone, è di nuovo per avere una ridondanza. Un giorno ti concentri su questa parte del processo e io faccio quest’altra parte del processo, e il giorno dopo invertiamo i ruoli. Non è che le persone non si specializzino, ogni persona ha competenze in tutto il processo. Ci sono alcune variazioni e alcune persone hanno una particolare specializzazione, ma comunque, nel complesso, le persone possono davvero sostituirsi a vicenda.

I nostri concorrenti, è molto diverso. Anche una piccola iniziativa coinvolge letteralmente mezza dozzina di persone. Avrai il project manager che è solo lì per coordinare gli altri ragazzi, poi hai il consulente, il designer UX, il configuratore, l’amministratore del database, lo specialista di rete e potenzialmente un programmatore, un ingegnere del software per le personalizzazioni che non sono native. Di nuovo, Lokad è una piattaforma programmabile, la maggior parte dei nostri concorrenti, le loro piattaforme non sono programmabili. Quindi ogni volta che vuoi avere qualcosa che abbia un comportamento programmabile, devi avere un ingegnere del software a tutto tondo che implementerà letteralmente con un linguaggio di programmazione generale come Java o Python le parti mancanti. Quindi, Lokad non è proprio così. Direi che i nostri concorrenti, per impostazione predefinita, sono una dozzina. Le iniziative S&OP possono coinvolgere diverse dozzine di persone, ma non è necessariamente così tante competenze diverse, sono principalmente persone diverse provenienti da diversi dipartimenti e molto spesso non è molto guidato dall’IT.

Quindi, Lokad sarebbe, quando dico una persona contro una dozzina, confronto questo con i nostri concorrenti che vendono APS, sistemi di pianificazione avanzata o sistemi di ottimizzazione delle scorte, questo tipo di software aziendale.

Conor Doherty: Grazie. E per tornare a un altro punto che hai menzionato all’inizio quando hai parlato dei Supply Chain Scientist, hai dato l’esempio di diversi dialetti SQL e poi il Supply Chain Scientist che potrebbe o meno essere fluente in quel dialetto specifico del cliente convaliderebbe o monitorerebbe gli script che sono stati generati automaticamente perché gli LLM a volte possono avere delle allucinazioni.

Bene, a questo proposito, gli LLM hanno spesso delle allucinazioni. Ora, migliorano, ma puoi chiedere a un LLM con un pezzo di testo: “Trova questa parola nascosta, riesci a vederla?” e dirà di sì, ma non è lì. So che non è lì, tu sai che non è lì. Come puoi garantire la sicurezza e il controllo di qualità su larga scala quando si parla di sfruttare gli LLM in modo automatizzato?

Joannes Vermorel: Le allucinazioni, o confabulazioni come preferisco chiamarle, accadono davvero quando si utilizza l’LLM come una base di conoscenza di tutto. Se stai usando gli LLM come una base di conoscenza di tutto, allora succede. Se chiedi documenti medici e dici: “Dammi un elenco di documenti su questa patologia”, ti darà qualcosa che è direzionalmente corretto. Gli autori esistono frequentemente, hanno pubblicato, hanno materiale che era in questa area, hanno pubblicato documenti che erano un po’ nella stessa vena ma non del tutto. Di nuovo, pensa a come se chiedessi a uno scienziato di ricordare cose a memoria.

È molto difficile, diresti, e se dici che devi farlo, probabilmente troveranno qualcosa che è plausibile a metà con nomi corretti di colleghi o ricercatori, titoli corretti o semi-corretti, questo tipo di cose. Quindi è una situazione in cui si ottengono confabulazioni, ma le stai quasi chiedendo. Voglio dire, stai chiedendo agli LLM di comportarsi come un database di tutto, quindi è molto difficile, avrai questo tipo di problema.

Stessa cosa con i dialetti SQL, provi e ottieni qualcosa, questa cosa sarà approssimativamente corretta. Se chiedi, “Voglio leggere una tabella”, farà un “select star from table” questo e quello. Non ti darà, quando chiedi, diciamo con GPT-4, quando chiedi di leggere una tabella, non ti darà “drop table”. Può darti una sintassi leggermente inadeguata, quindi testi la tua query SQL e ottieni un messaggio di errore e fai una piccola modifica e funziona. Ma vedi, è ancora direzionalmente corretto. Se chiedi di leggere il database, non produrrà un comando che elimina una tabella o modifica i tassi di autorizzazione del database.

Stessa cosa quando chiedi una conoscenza inventata. Ad esempio, se chiedi: “Ok, ho un compressore industriale da 20 kilowatt di potenza, qual è il punto di prezzo di quello?” Se chiedi a GPT, potrebbe dire probabilmente qualcosa come $10.000. È solo un’ipotesi. Questo è letteralmente inventato. È plausibile, ma è corretto? Probabilmente no, e dipende da centinaia di varianti perché ci sono così tanti compressori diversi per varie situazioni.

Quindi, in definitiva, le confabulazioni non accadono a caso. Ci sono veramente specifici tipi di compiti in cui accadono molto più frequentemente. Quindi direi che quando le stai quasi chiedendo, quando stai usando l’LLM come un database di tutto, allora è meglio fare un doppio controllo. Può essere estremamente utile, ti dà, ad esempio, per i dialetti SQL, ti darà un suggerimento sui tipi di parole chiave che dovresti usare, su come appare la sintassi, e potrebbe commettere un piccolo errore, mancare una virgola o qualcosa del genere, ma con poche iterazioni, lo otterrai giusto. Soprattutto perché una volta che hai la query SQL, puoi effettivamente testarla sul database, vedrai l’output e lo convaliderai, quindi hai un ciclo di feedback istantaneo per convalidarlo.

Se vuoi rilevare, diciamo, etichette di prodotto strane, etichette di prodotto che sembrano sospette come questa descrizione del prodotto mancante, quella è la tua etichetta di prodotto, ok, è ovviamente sbagliata. Ma puoi avere tutti i tipi di errori. Ad esempio, puoi avere un’etichetta di prodotto che dice “tournevis cruciforme” ed è in francese e quindi il problema è che è solo in francese, è un cacciavite con testa Phillips, penso. E quindi di nuovo, puoi chiedere cose ma ad un certo punto, non è perfetto, è una questione di giudizio. Anche un essere umano farebbe un errore allo stesso modo, quindi non puoi aspettarti che l’LLM sia un oracolo finale che è in grado di rispondere a ogni domanda correttamente. Ad un certo punto, se stai svolgendo un compito come la revisione dei 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 decidere se ne vale la pena o no. E molto spesso, ottieni qualcosa che è abbastanza buono, qualcosa che ti dà molto valore anche se fa ancora alcuni errori.

Conor Doherty: Progresso, non perfezione.

Joannes Vermorel: Esattamente. Se puoi ridurre del 90% i problemi dei tuoi dati principali con qualcosa che è molto economico e può essere eseguito nuovamente in poche ore senza supervisione, è molto buono.

Conor Doherty: C’è anche il valore del tempo che non è stato speso per fare ciò manualmente che avresti potuto fare qualcos’altro che genera o aggiunge valore. Quindi ancora una volta, ci sono driver diretti e indiretti di valore.

Joannes Vermorel: Inoltre, la realtà è che quando fai un compito super ripetitivo per un’ora, puoi avere un certo livello di qualità. Quando lo fai per 100 ore, l’ora 67, voglio dire, tipicamente, gli esseri umani non sono motori di prestazione costanti. Dopo qualche ora, la concentrazione diminuirebbe e quindi la quantità di falsi positivi, falsi negativi probabilmente aumenterebbe, anche con un dipendente abbastanza diligente.

Conor Doherty: Grazie. E voglio essere consapevole del fatto che abbiamo effettivamente alcune domande dal pubblico che affrontano cose che stavo per chiedere, quindi salterò alcune cose ma verranno affrontate nelle domande del pubblico. Ma un’ultima riflessione qui, quando parli degli Scienziati della Supply Chain, del Pilota AI, e torneremo su questo argomento più avanti nelle domande, ma come funziona effettivamente questa orchestrazione giorno per giorno tra il cliente, il Pilota AI e l’LLM? Il cliente ha accesso, interagisce con l’LLM?

Joannes Vermorel: Tipicamente, vediamo che tutte le ricette numeriche composte dagli Scienziati della Supply Chain sono il Pilota AI. Questa è la cosa che pilota la supply chain quotidianamente. È senza supervisione e genera le decisioni. Ora, con gli LLM, gestisce i dettagli della preparazione dei dati e le decisioni sugli ordini d’acquisto. Ad esempio, la pre-decisione sarebbe chiedere ai fornitori i loro MQS. Devi recuperare queste informazioni, sono mancanti o non sono aggiornate, devi cambiarle. Gli LLM possono aiutarti a ottenerle. La post-decisione sarebbe inviare una e-mail per chiedere un ETA, tempo stimato di arrivo, per gli ordini se non hai un EDI in atto o se non hai un ponte, o chiedere di accelerare un ordine o posticiparlo. Questo è il tipo di dettagli che viene dopo, dove Lokad può generare la decisione di richiedere di accelerare un ordine ma non fare i dettagli che consistevano nel comporre una e-mail e inviarla.

Tutto questo è praticamente il Pilota AI e questa è la grande ricetta numerica che gestisce il processo dall’inizio alla fine. Tutto questo è implementato dagli Scienziati della Supply Chain. Quindi questa è un’estensione di ambito per Lokad. Lo Scienziato della Supply Chain è il copilota in realtà. E quando dico pilota, intendo veramente come un pilota automatico in un aereo. E a proposito, oggigiorno gli aerei, le manovre più difficili vengono fatte in pilota automatico. Quando hai aeroporti molto pericolosi come l’aeroporto storico di Hong Kong, con uno nuovo che è molto più facile, ma ne hanno uno che è letteralmente in mezzo a grattacieli, allora il pilota automatico per quelle manovre è obbligatorio. Quindi è fatto, è la macchina tutto il tempo, le persone solo monitorano.

Quindi qui, lo Scienziato della Supply Chain sta progettando le ricette numeriche e sono il copilota. Decidono, fanno praticamente la navigazione per dirigere le cose e poi progettano il piano e il piano di corso per il pilota. Ma fondamentalmente, lo Scienziato della Supply Chain svolge il ruolo del copilota, pensando alle direzioni, pensando in anticipo e assicurandosi che il pilota possa operare nel modo più fluido possibile. Ma fondamentalmente, tutti gli aggiustamenti ad alta frequenza, è il pilota, non il copilota. E poi il cliente sarebbe il ruolo del capitano.

Sai, un po’ come nella vecchia serie TV, Star Trek, dove il capitano è seduto sulla sedia e dà istruzioni a livello molto alto all’equipaggio. Quindi il cliente in questa configurazione sta dando la strategia e dando le direzioni generali. Poi è compito dello Scienziato della Supply Chain implementare tutto questo e il compito del pilota è solo eseguire tutti gli aggiustamenti microscopici che sono necessari o tutte le decisioni quotidiane che sono necessarie per la supply chain e poi eseguire la supply chain in sé.

Conor Doherty: E questo è anche, ancora una volta, solo per essere chiari perché non ne abbiamo parlato, ma questo è in aggiunta a tutti i compiti quantitativi automatizzati che vengono già eseguiti. Sono stati fatti per anni. Quindi nel caso in cui qualcuno stia ascoltando e pensando, “Oh bene, sono solo i compiti qualitativi”, stiamo parlando di tutto il processo. Sì, quantitativo come il factoring dei driver economici, generazione di allocazione, acquisti, prezzi, tutto questo è già guidato dall’IA e automatizzato.

Quindi lo Scienziato della Supply Chain supervisiona entrambe queste console, quella quantitativa e quella qualitativa.

Joannes Vermorel: Esattamente. E il motivo per cui Lokad ha iniziato ad abbracciare questa parola chiave AI alla fine, che è un termine ombrello, è perché stiamo aggiungendo, gettando nel mix, gli LLM. Avevamo già il machine learning con la programmazione differenziabile e l’ottimizzazione stocastica, ma ora stiamo gettando gli LLM in cima. E quindi è letteralmente un toolkit molto completo.

L’effetto è letteralmente per i clienti, supply chain che possono funzionare senza supervisione per settimane. Le persone sono sorprese per quanto tempo, quando hai quei driver economici, puoi effettivamente operare completamente senza supervisione. La bellezza di tutto ciò è che non è necessario fare alcun tipo di aggiustamento microscopico. Ad esempio, gli aggiustamenti alla previsione sono per la maggior parte dei nostri clienti completamente inesistenti. E la maggior parte degli altri aggiustamenti vengono fatti completamente automaticamente, come l’introduzione di nuovi prodotti, la fase di eliminazione dei vecchi prodotti, l’introduzione di nuovi fornitori e la fase di eliminazione dei fornitori non performanti.

Quindi tutto questo è un po’ la routine e quando le ricette sono fatte correttamente, richiedono già nel passato, non richiedevano così tanti interventi. Ma con questo AI Pilot che include gli LLM, l’aggiunta di un nuovo fornitore nel mix, tutte queste cose possono richiedere ancora meno intervento manuale rispetto a prima.

Conor Doherty: Ok, Joannes, grazie. Siamo stati qui per circa 40 minuti. Ci sono delle domande a cui rispondere, quindi adesso ci spingerò verso quelle. Ma prima di farlo, come riassunto o pensiero finale, ancora una volta nel contesto della conversazione molto più ampia che abbiamo avuto un mese fa e che stiamo avendo oggi, qual è il punto principale sia per il praticante della supply chain che per le squadre esecutive che supervisionano il praticante medio, la supply chain normale? Qual è il call to action o il messaggio principale per loro?

Joannes Vermorel: Credo che tra una decina d’anni, questa visione degli AI Pilot, magari con un nome diverso, sarà la norma. Forse sarà la norma e quindi la gente dirà semplicemente supply chain e non AI Pilot per la supply chain. E sarà ovvio che la supply chain abbia questi AI Pilot. Proprio come quando dici un computer, non dici ho una CPU, ho una memoria, è scontato che tu abbia una CPU nel tuo computer quindi nemmeno lo menzioni.

La mia opinione è che tra una decina d’anni, queste funzioni saranno ampiamente automatizzate e Lokad, con questi AI Pilot, è un pacchetto che lo fa semplicemente con un Supply Chain Scientist. Per i nostri clienti, significa che la pratica della supply chain cambia di natura. Significa che hanno questi AI Pilot che possono liberare molta banda. E stavamo già liberando la banda per il processo decisionale o il calcolo complesso. Ma ora stiamo anche liberando il tempo che veniva speso per monitorare l’elenco degli SKU, l’elenco dei fornitori, l’elenco dei clienti, solo per mantenere corretti, puliti e sani i dati principali. Tutto questo sta anche scomparendo e rimuove la necessità di avere quegli interventi manuali che erano molto spesso non quantitativi nella natura. Dovevi sistemare una etichetta, sistemare un’entrata, rimuovere un duplicato o qualcosa del genere. Tutto questo, ancora una volta, Lokad se ne occuperà.

Quindi il punto principale è che è un miglioramento della produttività enorme. Penso che con alcuni clienti stiamo raggiungendo letteralmente questa riduzione del 90% in termini di personale per i compiti ripetitivi. La realtà è che ora hai più tempo e fai effettivamente ciò che è molto più difficile da automatizzare e credo che aggiunga più valore. Cioè pensare attentamente alla strategia, dedicare molto più tempo a pensare alle opzioni, a cosa dovresti esplorare invece di sprecare ancora il tuo tempo su fogli di calcolo.

Quindi dedica molto tempo a pensare a lungo e duramente ai problemi difficili e poi parla con i fornitori e parla con i clienti e avere conversazioni genuine approfondite in modo da poter organizzare la tua supply chain per rendere felice il tuo fornitore e quindi sarà disposto a darti prezzi migliori, avrai una migliore qualità, una maggiore affidabilità, ecc. Se ti organizzi per soddisfare le esigenze dei tuoi fornitori, potrebbe sembrare un po’ il contrario, “Oh fornitori, io sono il cliente, devono adattarsi a me”. Ma se puoi soddisfare meglio i tuoi fornitori, è un lavoro di squadra e puoi avere maggiore affidabilità e prezzi migliori.

E puoi fare lo stesso sforzo con il tuo cliente perché c’è la stessa collaborazione che dovrebbe avvenire. E ancora una volta, ci vuole molta discussione intelligente e questo è il tipo di cose che vanno oltre ciò che questi LLM possono fare al giorno d’oggi. Quindi credo che Lokad possa automatizzare i compiti che ci piacciono, le minuzie di basso valore e i compiti amministrativi banali, e far fare alle persone le cose semistrategiche di alto livello. Dico semistrategiche perché parlerai con un cliente alla volta e poi farai la strategia che consiste nel riassumere tutto ciò, creare una visione e poi supportare la leadership della supply chain in modo che abbiano una strategia molto chiara e ben fondata per la loro azienda.

Conor Doherty: Quindi, ancora una volta, prendiamo due esempi solo per concettualizzare, come le decisioni di basso livello, passando attraverso un foglio di calcolo Excel dicendo, “Oh dice blocco in colori che deve essere nero”, come se stessi correggendo automaticamente, è banale, è banale, non vale il tuo tempo. “Dovrei aprire un magazzino ad Amburgo?” Strategico.

Joannes Vermorel: Sì, è strategico. Inoltre, il problema è che ci sono così tante opzioni. Potresti dire un magazzino, dovrei comprare, dovrei affittare, che tipo di contratti, qual è il grado di meccanizzazione, devo avere un contratto per l’attrezzatura in modo da poterla restituire, dovrei noleggiare l’attrezzatura o no. Voglio dire che ci sono centinaia di domande e molto spesso tutte queste domande, voglio dire ancora una volta quando le persone devono dedicare il 99% della loro capacità mentale al compito amministrativo, non hanno più tempo da dedicare a queste grandi domande.

Vedi, se dovessi applicare la legge di Parkinson, le persone direbbero, ho visto molte aziende in cui se dovessi calcolare la somma totale dei minuti spesi per qualcosa come le classi ABC, il tempo sarebbe ogni anno stiamo parlando di anni-uomo investiti nelle classi ABC. E quando si tratta di decidere per un nuovo magazzino, stiamo parlando di settimane di tempo. Ma vedi lo squilibrio in cui le persone spendono letteralmente collettivamente anni di tempo umano per qualcosa che è completamente insensato come le classi ABC. E quando si tratta di un investimento di 50 milioni di euro per aprire un magazzino, sono letteralmente settimane di tempo e poi bum, viene presa una decisione. Vedi, dovrebbe essere il contrario.

Conor Doherty: Bene, grazie per questo. Su questa nota, passerò alle domande del pubblico. Grazie mille. Sentitevi liberi di inviarle fino a quando praticamente smetto. Quindi, Joannes, questa è di Massimo. Potresti spiegare meglio come IT può sfruttare i piloti di intelligenza artificiale per ridurre il backlog e perché credi che dovrebbe essere proposto questo approccio?

Joannes Vermorel: I piloti di intelligenza artificiale non si tratta di ridurre i backlog dell’IT. Si tratta di far fronte al fatto che l’IT ha anni di backlog. Quindi, il nostro piano in Lokad non riguarda la riduzione del backlog dell’IT. Richiede di ripensare l’IT come ha fatto Amazon. Questo sarebbe un altro episodio. Direi di cercare la nota del 2002 di Jeff Bezos riguardante le API di Amazon. Il punto principale è che tutti i dipartimenti di un’azienda moderna hanno bisogno di tonnellate di software. Ogni singola divisione - marketing, finanza, contabilità, supply chain, vendite - vogliono tutti tonnellate di strumenti software e tutto ciò ricade sulle spalle dell’IT. L’IT sta collassando sotto questo peso.

Quindi, il mio punto è che in Lokad siamo specialisti della supply chain. Non affronteremo tutte le questioni di marketing, vendite, contabilità e così via. Quello che diciamo è che con LLM, possiamo liberare l’IT dal prendersi cura di Lokad. In sostanza, passiamo dal bisogno di, diciamo, 10-20 giorni di lavoro da parte dell’IT per avviare l’iniziativa Quantitative Supply Chain, costruire il flusso di lavoro, a solo poche ore. Quindi, non stiamo risolvendo il backlog. L’IT fa ciò che fa l’IT. Possono anche beneficiare di LLM, ma nel loro caso, le situazioni sono molto più diverse, molto più difficili.

Quindi, la mia proposta non è che LLM possa effettivamente aiutare l’IT a ridurre i loro backlog. È solo un modo per Lokad, in questo caso specifico, per dire: “Beh, invece di aggiungere altri 20 giorni al backlog, aggiungiamo solo circa quattro ore e abbiamo finito.” Ecco come affrontiamo il backlog. E poi, in generale, la soluzione a questi anni di backlog è che ogni singola divisione deve internalizzare la maggior parte delle questioni software. Vedi, gli anni di backlog sono dovuti al fatto che le aziende in generale richiedono troppo all’IT. Ogni divisione dovrebbe avere pratiche digitali - marketing, vendite, contabilità e così via. Non dovresti chiedere all’IT di risolvere tutti questi problemi per te. Dovresti avere esperti digitali in ogni area per farlo. Ed è esattamente l’essenza di questa nota del 2002, se non confabulo, di Jeff Bezos al suo team. È una nota molto famosa. Puoi digitare “famous memo Bezos” perché diceva, in sostanza: “Hai due settimane per avere un piano per consentire a ogni divisione di esporre tutti i tuoi dati in modo che non abbiamo questo tipo di isolamento e giochi di potere all’interno dell’azienda, in Amazon.”

E Bezos concludeva: “Ogni singolo manager che non ha un piano sulla mia scrivania entro due settimane da adesso è licenziato o qualcosa del genere.”

Conor Doherty: Ok, grazie. Questo prossimo commento, ed è una domanda che non ho fatto perché ho visto che è stata menzionata nei commenti, quindi è formulata come un commento ma prendila come una domanda. Questo è di Jesse. “Un Supply Chain Scientist più un LLM sembra ancora un copilota. Quindi, ancora una volta, delinea il pilota di intelligenza artificiale rispetto al copilota.”

Joannes Vermorel: Il motivo per cui diciamo che è un pilota è perché abbiamo alcuni clienti in cui per settimane, tutte le decisioni vengono generate e poi eseguite senza supervisione. E quando dico senza supervisione, intendo davvero così. Durante i lockdown del 2020, abbiamo persino avuto un’azienda in cui per 14 mesi, tutti i lavoratori impiegati erano letteralmente a casa, senza lavorare, pagati dallo Stato perché lo Stato forniva sovvenzioni in Europa. Diversi Stati fornivano sovvenzioni per essenzialmente stare a casa e non lavorare. E quindi, quella era la situazione. Quindi, abbiamo avuto quella situazione e quando hai una supply chain che funziona praticamente senza supervisione per 14 mesi, la chiamo un pilota, non un copilota. Se non c’è nessuno a supervisionare i numeri generati dal sistema, penso davvero che sia un pilota.

Ma allora non stavamo usando un LLM. Ed era una situazione in cui i dati erano puliti e non c’era una necessità drammatica di migliorare questa gestione dei dati principali. Ed era un cliente che aveva una maturità molto alta in termini di integrazione EDI e così via. Quindi, le cose che erano necessarie prima e dopo erano molto, molto limitate.

Comunque, tornando alla questione del copilota. La maggior parte dei concorrenti di Lokad afferma di fare un copilota. E in effetti, il modo in cui lo fanno è una cosa completamente diversa. Lokad, il Supply Chain Scientist, utilizza un linguaggio di programmazione. Quindi, quando usiamo un LLM, è per generare, per aiutarci a generare pezzi di un programma. È per questo che lo usiamo.

Quindi, LLM viene utilizzato per generare essenzialmente pezzi di programmi che possono essere i dialetti SQL, possono essere altre cose. E poi progettiamo il pilota e poi il pilota viene eseguito senza supervisione.

I nostri concorrenti, soprattutto quelli che dicono di voler portare l’IA conversazionale, l’interfaccia utente conversazionale, sul mercato, fanno qualcosa di completamente diverso. Quello che fanno è tipicamente il recupero aumentato dalla generazione (RAG). Quindi quello che fanno è comporre un prompt. Lo faranno, letteralmente, tutti i nostri concorrenti che dicono di fare IA con LLM nello spazio della supply chain. Compongono, diciamo, una dozzina di prompt adatti a vari scenari. Poi, dopo il prompt, iniettano dati recuperati dal database, sai, possono essere statistiche descrittive di base. Inietterebbero alcune dozzine di numeri, vendite medie dell’ultima settimana, dell’ultimo mese, dell’ultimo anno, o qualsiasi altra cosa, sai, statistiche di base che si adattano allo scenario. E poi aggiungono la query extra dall’utente e poi LLM completerà la risposta.

Vedi, quindi anche in questo caso, gli LLM si limitano al completamento del testo. Quindi componi un testo e lo completa. E il recupero aumentato dalla generazione, la parte di recupero consiste semplicemente nel recuperare alcuni numeri dal database e poi comporre. Ma la sostanza è che, ok, ora hai qualcosa in cui puoi fare una domanda. Ma la realtà è che se non sei ignorante, puoi leggere i numeri direttamente dallo schermo. Non c’è magia. Quindi gli LLM vedono i numeri esattamente come li puoi vedere nel tuo report. Fondamentalmente, possono rispondere solo a domande che possono essere facilmente risposte da un cruscotto.

Quindi sì, se non sei davvero familiare con la definizione di ogni numero, può chiarirtelo. Ma puoi anche avere, ed è qui che Lokad lo fa, una sorta di foglio di trucchi che ti fornisce la descrizione in una riga collegata a ogni cruscotto, per ogni numero presente nel cruscotto. E questo svolgerà effettivamente lo stesso ruolo, senza coinvolgere l’IA.

Quindi, in definitiva, sono molto, molto scettico riguardo a queste IA conversazionali, questi copiloti, perché fondamentalmente sono trucchi sovrapposti a sistemi esistenti che non sono mai stati progettati per alcun tipo di sistema di apprendimento automatico, nemmeno il classico tipo di apprendimento automatico, figuriamoci gli LLM.

Ecco perché dico, a mia conoscenza, tutti i nostri concorrenti stanno facendo copiloti in cui hanno essenzialmente qualcosa che è, diciamo, un chatbot che si trova sopra i cruscotti. Ma non fa alcuna automazione. Non ti consente di automatizzare alcun tipo di pilota di IA. È, sì, un trucco sopra un sistema legacy.

Conor Doherty: Ok, grazie. Continuerò. Questa domanda è di Kyle. “Puoi discutere dell’importanza dell’analisi dei processi prima di istituire un modello di IA?” Lo prenderò in considerazione nel contesto della supply chain.

Joannes Vermorel: Sorprendentemente, l’analisi dei processi è molto importante. Ma non necessariamente nei modi in cui le persone pensano. La realtà è che, soprattutto nelle supply chain, le aziende hanno avuto quattro o cinque decenni per inventare molti processi inventati. E dico “inventati” intenzionalmente. La supply chain è un gioco di burocrazia. Ha un nucleo burocratico. Il gioco della supply chain negli ultimi cinque decenni è stato un modo per organizzare il lavoro perché non puoi avere una persona che si occupa di tutti gli SKU, tutti i magazzini, tutte le sedi, tutti i prodotti. Quindi, devi dividere e conquistare il problema, distribuendo il carico di lavoro su decine, possibilmente centinaia di persone per grandi aziende, molto grandi.

Quindi, finisci per avere una situazione in cui il 90% dei tuoi processi riflette semplicemente le complicazioni emergenti che hai a causa del fatto che il carico di lavoro è distribuito su molte persone. Quindi, vedi, sono processi accidentali, non processi essenziali. Quindi, direi sì, è necessario fare l’analisi dei processi, ma attenzione, il 90% dei processi esistenti non affronta il problema fondamentale che la tua supply chain affronta, ma problemi accidentali creati dal fatto che hai bisogno di molte persone per risolvere il 10% del problema che deve essere affrontato.

In settori come la lavorazione chimica, dove ci sono molti flussi e dipendenze, è molto complicato. Ad esempio, quando hai reazioni chimiche, avrai sottoprodotti. Quindi, ogni volta che produci un composto, produci anche qualcos’altro. Questo qualcos’altro può essere venduto o utilizzato per un altro processo. Devi coordinare tutto questo. Hai tonnellate di vincoli, hai processi che operano attraverso lotti e processi che operano in modo continuo. È molto complicato.

Ma la realtà è che la maggior parte dei processi, invece di concentrarsi sulla fisicità del problema, sul fatto che diciamo, in un’industria di processo, hai reazioni chimiche che hanno input e output molto specifici e tutto ciò è molto, molto chiaramente definito e conosciuto. Invece di concentrarsi sul livello di base della realtà fisica della tua attività, l’analisi dei processi potrebbe semplicemente invertire l’ingegnerizzazione dei processi che scompariranno quando si configura il pilota di IA.

La cosa interessante è che quando lo fai in stile pilota di IA, non hai più bisogno di questo approccio di dividere e conquistare. È un insieme unificato di ricette numeriche che risolvono il problema dall’inizio alla fine. Quindi, tutti quei problemi di coordinamento che sono stati risolti da molti processi sono semplicemente scomparsi.

La mia esperienza è che il 90% di quei processi scomparirà quando avremo finito. Ecco perché dico che è molto importante mantenere un focus preciso sul livello fisico di base della tua supply chain, rispetto ai processi inventati che sono solo lì per coordinare numerose squadre. Queste cose non verranno aggiornate, verranno sostituite dal pilota di IA.

Conor Doherty: Grazie. E in realtà, un esempio che hai elencato in quella risposta fornisce un bel collegamento qui. Quindi, da un telespettatore Durvesh, hai intenzione di rendere open source Envision per scopi educativi o per le piccole imprese? E può essere programmato con regole a beneficio delle aziende B2B come le aziende chimiche che richiedono un’ampia immissione manuale?

Joannes Vermorel: Sì, abbiamo intenzione di rendere open source Envision in qualche momento. Ma lasciatemi spiegare prima il motivo. In questo mondo del software aziendale, abbiamo la documentazione pubblica per Envision. La maggior parte dei miei colleghi ha linguaggi specifici del dominio (DSL), ma non sono documentati pubblicamente. Dassault Systèmes ha acquistato un’altra azienda chiamata Quintiq. Al momento, viene fornito con un DSL, che non è documentato pubblicamente. Quindi, nel settore della supply chain, ci sono altre aziende che hanno un DSL e non sono pubblici. Da parte nostra, presso Lokad, documentiamo tutto pubblicamente e abbiamo un ambiente sandbox gratuito per Envision. Abbiamo persino workshop gratuiti disponibili in modo da poter insegnare o imparare Envision con esercizi. Quindi stiamo facendo molto di più.

Ora, per quanto riguarda l’open source di un linguaggio, fa parte del piano ma è troppo presto. Perché? Perché Envision è ancora in rapida evoluzione. Vedete, uno dei problemi che si hanno quando si rende open source un compilatore, il compilatore è un pezzo di software che consente di compilare il proprio script in qualcosa che viene eseguito. Non appena si rende open source il proprio compilatore, significa che le persone opereranno codice Envision, nel caso di Lokad, nel mondo reale. E Lokad perde la possibilità di aggiornare automaticamente quegli script. La realtà è che negli ultimi dieci anni, Lokad ha modificato centinaia di volte il linguaggio di programmazione Envision. Questo linguaggio non è stabile. Se guardate il mio libro, il libro sulla supply chain quantitativa che ha ormai circa sei anni, la sintassi di Envision è evoluta in modo significativo. Potete dare un’occhiata alla sintassi vestigiale che non esiste più in Envision.

E quindi, come affrontiamo questo costante cambiamento di sintassi? Beh, ogni settimana presso Lokad, abbiamo rilasci settimanali il martedì e ciò che applichiamo sono riscritture automatiche per tutti gli script Envision che vengono utilizzati sulle piattaforme Lokad. Quindi è una delle proprietà chiave di Envision essere molto, direi, avere una grande affinità con l’analisi statica. E l’analisi statica è, a proposito, un ramo del design e dell’analisi del linguaggio. Quando dico linguaggio, intendo linguaggio informatico, che consente di avere proprietà dei programmi senza eseguirli. E attraverso l’analisi statica, possiamo letteralmente riscrivere automaticamente uno script esistente dalla vecchia sintassi alla nuova sintassi. E lo facciamo automaticamente il martedì. E di solito, quando facciamo un aggiornamento, avremo per alcuni giorni sia la vecchia sintassi che la nuova sintassi che vengono entrambe accettate. Facciamo le riscritture automatiche e poi quando vediamo che la sintassi antica non esiste più, con un flag di funzionalità, blocciamo il fatto che esista solo la nuova sintassi.

E a Lokad, abbiamo già implementato oltre 200 di queste riscritture automatiche. Di solito, lo facciamo come rilascio ogni martedì, ma di solito abbiamo circa due riscritture al mese e lo facciamo da un decennio. Quindi, finché questo processo è in corso, Lokad non può realisticamente rilasciare Envision come open source. Arriverà nel momento opportuno, ma non voglio ripetere l’enorme errore di Python. L’aggiornamento da Python 2 a Python 3 ha richiesto alla comunità di Python un decennio ed è stato incredibilmente doloroso. Voglio dire, le aziende sono entrate in anni di aggiornamenti, è stato un incubo che è durato un decennio. Quindi, è stato davvero, davvero sbagliato. Anche Microsoft con l’aggiornamento da C# al framework .NET a .NET Core ha impiegato mezzo decennio ed è stato un grande, grande dolore. Quindi, questo è di nuovo il problema di una volta che hai un compilatore che è open source nel mondo, non controlli il codice. Quindi, se vuoi apportare modifiche al linguaggio, devi collaborare con la tua comunità. Rende il processo super lento, super doloroso e alla fine, non elimini mai davvero tutte le caratteristiche negative del tuo linguaggio.

Se guardiamo a Python, il modo in cui ad esempio è stato introdotto la programmazione orientata agli oggetti in Python, la sintassi, ah, è goffa. Si può sentire 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 è un po’ scadente e ora è lì per sempre. E a proposito, ogni linguaggio ha qualcosa del genere. In C#, hai la parola chiave volatile che non serve più a nulla. C++ è bloccato per sempre con l’ereditarietà multipla. È stato un errore. Avere l’ereditarietà multipla è stata una cattiva decisione di progettazione che complica tutto, ecc. L’unico modo per evitare questi grandi errori, Lokad, abbiamo commesso molti grandi errori nella progettazione di Envision, ma li correggiamo subito e siamo ancora nel processo, specialmente quando arrivano nuovi paradigmi. Ad esempio, la programmazione differenziabile è stato un grande nuovo paradigma e abbiamo dovuto rielaborare il linguaggio stesso per adattarlo a questo paradigma.

A proposito, c’è una proposta mega importante per Swift, proposta da Apple, per rendere la programmazione differenziabile un cittadino di prima classe in Swift. Ma probabilmente non accadrà presto. È come una ristrutturazione importante, importante. Al momento, il linguaggio che è più vicino ad avere la programmazione differenziabile come cittadino di prima classe sarebbe Julia e anche lì, c’è molta carta adesiva.

Conor Doherty: Grazie ancora. Ancora tre domande da affrontare. La prossima è di Victor. Riguarda in generale l’IA. Come affronta l’IA i collo di bottiglia casuali dato che opera su grandi set di dati per prevedere scenari plausibili o problemi ricorrenti?

Joannes Vermorel: Sia chiaro, quando diciamo IA, si tratta di una collezione di tecniche. A Lokad, di solito abbiamo LLM, programmazione differenziabile e ottimizzazione stocastica. La programmazione differenziabile serve per l’apprendimento, l’ottimizzazione stocastica serve per ottimizzare sotto vincoli in presenza di incertezza, il modello probabilistico che di solito viene regredito con la programmazione differenziabile e LLM serve per fare questo motore di modellazione universale e resistente al rumore.

Quando si affronta la supply chain con strumenti probabilistici, la maggior parte dei compiti suggeriti da questa domanda scompare. Questa è la bellezza delle previsioni probabilistiche, queste previsioni non sono più accurate, sono semplicemente molto più resilienti al rumore ambientale della supply chain. Quando si accoppia la previsione probabilistica all’ottimizzazione stocastica, si elimina in gran parte la necessità di intervento manuale. E quando dico in gran parte, intendo che per la maggior parte dei clienti, viene completamente eliminata. E ora ci troviamo con compiti che richiedono di analizzare il testo e di occuparsene, e qui entrano in gioco gli LLM. E ancora una volta, quello che ho descritto è Lokad, abbiamo questi AI Pilots che sono veramente automatizzati e se c’è un intervento manuale, non si tratta di inserire una voce di registro nel sistema, ma di inserire una revisione strategica della ricetta numerica che di solito comporta una modifica profonda della logica stessa per riflettere la strategia rivista. Non si tratta di una cosa minore. Di solito si tratta di qualcosa di fondamentale che cambia la struttura stessa della logica implementata.

Conor Doherty: Questa domanda è di Ahsan. Potresti spiegare come l’IA, nello specifico, accelererebbe un ordine? Sarebbe in grado di eseguire transazioni nel sistema ERP basate su comandi verbali?

Joannes Vermorel: I comandi verbali non sono l’approccio corretto a questo problema. Se quello che vuoi sono inserimenti dati più veloci, la voce è un canale a bassa larghezza di banda. Scrivi più velocemente di quanto parli, a meno che tu non sia molto bravo a scrivere. Quindi, questo non è il tipo di vantaggio che puoi ottenere. Se la tua interfaccia utente è progettata correttamente con una tastiera, sarai più veloce dei comandi vocali. Lo so molto bene perché 20 anni fa lavoravo presso AT&T Labs sulle tecnologie di riconoscimento vocale di produzione. C’erano tonnellate di applicazioni in cui non funzionava. Il riconoscimento vocale funzionava, ma la realtà è che le tue mani sulla tastiera erano semplicemente più veloci. Le situazioni in cui la voce era utile erano o quando le mani erano sporche o occupate. Altrimenti, la tastiera è semplicemente più veloce.

Tornando alla domanda, prima devi filtrare gli ordini. Qui abbiamo un processo decisionale in cui devi decidere quali ordini devono essere accelerati. Questo è il classico Lokad, un processo decisionale puro, quantitativo. Devi decidere sì o no, se questo ordine in corso richiede una richiesta di accelerazione del processo. Lo faremmo con la programmazione differenziabile, l’ottimizzazione stocastica. Ecco come arriviamo alle decisioni corrette.

Una volta che abbiamo questo, abbiamo automaticamente ogni giorno le decisioni per gli ordini. Non si tratta di avere qualcuno che dà ordini verbali per questo. Farà parte dell’insieme di ricette numeriche che calcoleremo gli ordini ottimizzati. Man mano che il tempo passa, ci rendiamo conto che alcuni ordini erano sovrastimati o sottostimati e chiederemo di posticipare o accelerare rispettivamente. La parte degli LLM riguarda semplicemente l’utilizzo di questa decisione quantitativa, in cui hai una bandiera binaria che dice “per favore accelera”, per generare una e-mail con un contesto adeguato, inviarla al fornitore con qualcosa del tipo “per favore conferma che puoi farlo”, e quindi il fornitore dovrebbe confermare dicendo “sì”, “no”, “forse posso” o “questo è quello che posso offrire”.

LLM automatizzerà la chat con il fornitore. L’IA non riguarda la decisione di accelerare l’ordine. Si tratta di una decisione puramente quantitativa che deve essere affrontata con strumenti quantitativi, programmazione differenziabile, ottimizzazione stocastica. L’LLM è lì per l’interazione con il fornitore, che spesso utilizzerà un canale non strutturato come l’e-mail.

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

Conor Doherty: A proposito, quando parliamo di ottimizzazione stocastica e programmazione differenziabile, abbiamo a disposizione ampi video di approfondimento su questi argomenti. Non stiamo sviscerando questi argomenti perché si tratta di una serie di tre parti (parte 1, parte 2 e parte 3) sulla programmazione differenziabile, ma non li stiamo ignorando. Sono stati trattati e invito cortesemente gli spettatori che vogliono saperne di più a rivedere quei video e poi mettere insieme questi pezzi.

Ultima domanda, da Isaac. Come cliente che sta imparando Envision, sono interessato alle sue capacità di integrazione, in particolare con GitHub. Potresti discutere delle potenzialità di Envision nel supportare l’integrazione con GitHub, in particolare per applicazioni come spiegare blocchi di codice in linguaggio naturale o identificare le modifiche tra le versioni? Infine, c’è qualche piano per introdurre un copilota di Envision in futuro?

Joannes Vermorel: La risposta breve è sì, sì e sì. I tempi variano molto a seconda dei componenti di cui stiamo parlando. Per quanto riguarda l’utilizzo degli LLM per fare essenzialmente il copilota, come il copilota di GitHub ma che sarà il copilota di Lokad su codici Envision, stiamo già lavorando su questo. La cosa molto interessante è che, grazie al fatto che è un DSL in cui abbiamo il controllo completo sui materiali di formazione, il giorno in cui riusciremo con successo a portare questo LLM in produzione, ogni volta che cambieremo la sintassi, eseguiremo nuovamente il nostro processo di formazione con la sintassi aggiornata e avremo sempre un copilota che ti darà la sintassi Envision aggiornata. A differenza del copilota di GitHub che ti dà una sintassi Python, una sintassi C#, una sintassi Java.

Perché vedi, ancora una volta, Java è stato intorno per 25 anni, Python è stato intorno per più di 30 anni, C# è stato intorno per 22 anni o qualcosa del genere. Quindi quando chiedi al compilatore di GitHub di scrivere codice per te, il problema è che ti dà un’unica versione semi-recente di quei linguaggi, ma non effettivamente super recente. E a volte non vuoi la versione recente perché il tuo ambiente non è in linea con quelle versioni super recenti che non supporti ancora.

Stiamo lavorando su una serie di funzionalità sovrannaturali come commentare il mio codice, spiegare il mio codice, completare il mio codice. Stiamo anche pensando a molte azioni di codice estese che sono molto specifiche per il tipo di flussi di lavoro che avvengono all’interno di Lokad. Ad esempio, stiamo lavorando per automatizzare la generazione di dashboard sulla salute dei dati. È un compito molto tipico.

Le dashboard sulla salute dei dati sono essenzialmente strumenti che verificano che i dati che acquisiamo siano corretti. E abbiamo molte indicazioni e conoscenze su cosa verificare perché i tipi di problemi che troverai nei dati degli ERP sono sempre gli stessi. Quando verifichiamo la correttezza dei dati provenienti da un ERP, noi Supply Chain Scientists abbiamo coltivato, letteralmente, i nostri metodi di formazione per sapere cosa cercare e abbiamo le nostre ricette, intendo ricette umane, su cosa dovrei implementare, cosa dovrei verificare, e potremmo automatizzare in gran parte tutto ciò con gli LLM. Quindi è qualcosa che è in corso presso Lokad.

Stiamo lavorando su un copilota di Lokad. Per rendere Envision più amichevole con GitHub, abbiamo già rilasciato un’estensione open-source per Visual Studio code. Puoi già inserire il codice di Envision in un repository git. Basta creare un file .nvn e fare il commit e sei a posto. Se vuoi modificare il codice con una bella colorazione del codice, avrai bisogno di un’estensione per Visual Studio code. Se cerchi l’estensione di Lokad per Visual Studio code per Envision, ce n’è una completamente open source e otterrai la colorazione del codice.

In futuro, abbiamo intenzione di esporre il codice di Envision che si trova in un account Lokad come un repository git. Il modo in cui il codice di Envision è archiviato in un account Lokad è praticamente lo stesso di un repository git. È versionato praticamente allo stesso modo. Non è organizzato esattamente allo stesso modo di git, di nuovo non andrò troppo in profondità sulle ragioni tecniche. Git è molto agnostico al linguaggio. Se stai gestendo solo un linguaggio in particolare, puoi essere più intelligente e fare tutte le cose che non sono possibili nel caso generale. Ma in definitiva il codice di Envision è completamente versionato. Potremmo esporre un repository git che ti consente di esportare tutto il tuo codice da un account Lokad in un repository git e forse in seguito anche il contrario per avere una sincronizzazione bidirezionale. Git è un sistema decentralizzato in cui ogni repository git è come una cosa completa, hai una copia completa e quindi puoi ottenere modifiche da un repository remoto ma inviare le tue modifiche a un repository remoto. E quindi ad un certo punto, potremmo introdurre, probabilmente prima introdurre l’esportazione e poi introdurre la reimpostazione, ma ci vorrà tempo. Non siamo ancora arrivati lì. Fa parte della roadmap, ma non abbiamo ancora una tempistica per questo.

Conor Doherty: Vale la pena sottolineare che alcune persone nei commenti hanno detto che stavano imparando Envision. Realizziamo una serie di tutorial in collaborazione con l’Università di Toronto e alcuni altri che sono in fase di sviluppo. Ci sono risorse gratuite e possiamo fornire risposte se le persone lo desiderano. Per chiunque voglia imparare, i nostri Supply Chain Scientists dedicano molto impegno a quei workshop. Sono liberamente disponibili sul nostro sito web.

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

Conor Doherty: Queste sono tutte le domande, Joannes. Grazie mille per il tuo tempo e grazie mille per aver guardato. Spero che sia stato utile e ci vediamo la prossima volta.