00:00:00 Introduzione all’intervista
00:01:00 Il percorso di Lokad di Rinat e le sfide della supply chain
00:03:59 L’evoluzione di Lokad e approfondimenti sulle simulazioni
00:07:07 Complessità della simulazione e decisioni basate su agenti
00:09:15 L’introduzione degli LLMs e le ottimizzazioni della simulazione
00:11:18 L’impatto di ChatGPT e le categorie di modelli
00:14:14 Gli LLMs come strumenti cognitivi nelle imprese
00:17:10 Gli LLMs per migliorare le interazioni con i clienti e le inserzioni
00:20:30 Il ruolo limitato degli LLMs nei calcoli della supply chain
00:23:07 Gli LLMs per migliorare la comunicazione nelle supply chain
00:27:49 Il ruolo di ChatGPT nell’analisi dei dati e nelle intuizioni
00:32:39 L’elaborazione del testo da parte degli LLMs e le sfide dei dati quantitativi
00:38:37 Perfezionare la ricerca aziendale e concludere con le intuizioni sull’AI
Riepilogo
In un recente dialogo, Conor Doherty di Lokad ha conversato con Joannes Vermorel e Rinat Abdullin sull’impatto dell’AI generativa sulle supply chain. Vermorel, CEO di Lokad, e Abdullin, un consulente tecnico, hanno discusso dell’evoluzione dalla previsione delle serie temporali all’utilizzo dei Large Language Models (LLMs) come ChatGPT. Hanno esplorato il potenziale degli LLMs per automatizzare compiti, aumentare la produttività e supportare l’analisi dei dati senza eliminare posti di lavoro. Sebbene Vermorel sia rimasto cauto nell’utilizzo degli LLMs per la pianificazione, entrambi hanno riconosciuto la loro utilità nel comporre soluzioni. L’intervista ha evidenziato il ruolo trasformativo dell’AI nella supply chain management e l’importanza di integrare gli LLMs con strumenti specializzati.
Riepilogo Esteso
In una recente intervista, Conor Doherty, il Responsabile delle Comunicazioni di Lokad, ha intrapreso una discussione stimolante con Joannes Vermorel, l’amministratore delegato e fondatore di Lokad, e Rinat Abdullin, un consulente tecnico presso Trustbit e ex CTO di Lokad. La conversazione si è incentrata sul fiorente campo dell’AI generativa e sulle sue implicazioni per la supply chain management.
Rinat Abdullin, riflettendo sul suo periodo in Lokad, ha raccontato le prime sfide affrontate dall’azienda, in particolare nell’allineare la tecnologia con le esigenze dei clienti e nel rendere comprensibili e affidabili i complessi dati della supply chain. Joannes Vermorel ha confermato che le radici di Lokad erano nella previsione delle serie temporali, un elemento critico nell’ottimizzazione della supply chain.
Man mano che il dialogo proseguiva, Abdullin ha approfondito l’evoluzione della tecnologia di Lokad, evidenziando la tensione tra la spiegabilità e le prestazioni dei modelli di machine learning. Ha condiviso le sue esperienze nell’utilizzo delle simulazioni per demistificare sistemi complessi, aprendo la strada a metodi computazionali più ottimizzati.
La conversazione poi si è spostata sui Large Language Models (LLMs), con Vermorel che ha osservato il loro recente aumento di popolarità. Abdullin ha condiviso le sue prime esperienze con i modelli linguistici e la loro evoluzione in strumenti intuitivi come ChatGPT. Ha enfatizzato il potenziale trasformativo degli LLMs, paragonandoli a un reparto personale di assistenti in grado di eseguire una varietà di compiti, dalla redazione di documenti all’automazione della ricerca di informazioni all’interno di grandi silos.
Abdullin ha affrontato le preoccupazioni sul fatto che gli LLMs possano sostituire i lavoratori, affermando che essi aumentano l’efficienza dei dipendenti piuttosto che sostituirli. Ha citato esempi in cui la produttività è aumentata da dieci a cento volte. Ha anche osservato che, mentre le supply chain sono state lente nell’adottare gli LLMs, i dipartimenti di marketing sono stati rapidi nell’utilizzarli per le interazioni con i clienti e per la riduzione dei costi.
Joannes Vermorel ha approfondito il potenziale degli LLMs nell’automatizzare comunicazioni aperte con i partner della supply chain, risparmiando tempo sulle email di routine e permettendo di concentrarsi su compiti più complessi. Ha elogiato gli LLMs per la loro finezza linguistica nell’adattare il tono delle comunicazioni, un compito che può richiedere molto tempo per gli esseri umani.
Abdullin ha evidenziato le avanzate capacità di analisi dei dati di ChatGPT, che consentono ai decisori aziendali di analizzare dati complessi senza necessitare di competenze di programmazione. Tuttavia, Joannes Vermorel ha mantenuto il suo scetticismo riguardo all’AI generativa nella pianificazione della supply chain, sottolineando che gli LLMs sono più adatti per generare analisi e rapporti monouso.
Rinat Abdullin ha suggerito che gli LLMs potrebbero essere utilizzati in combinazione con strumenti specializzati per ottenere risultati migliori, in particolare all’intersezione tra domini numerici, testuali e di codice. Joannes Vermorel ha concordato, chiarendo che gli LLMs sono più adatti per comporre programmi per risolvere problemi piuttosto che risolverli direttamente.
In conclusione, Rinat Abdullin ha incoraggiato le aziende ad adottare gli LLMs, poiché possono aggiungere un valore significativo quando combinati con strumenti specializzati. Conor Doherty ha concluso l’intervista ringraziando Joannes e Rinat per le loro intuizioni sul dinamico campo dell’AI generativa e sul suo ruolo nel plasmare il futuro della supply chain management.
Trascrizione Completa
Conor Doherty: Bentornati a Lokad TV. I progressi compiuti nell’AI generativa negli ultimi 12 mesi sono un’impresa straordinaria di progresso tecnologico. Gli LLMs, o large language models, sono passati da nicchia a corrente principale in meno di un anno. Qui per spiegare il significato, in particolare nel contesto della supply chain, c’è il primissimo CTO di Lokad, Rinat Abdullin. Rinat, benvenuto in Lokad.
Rinat Abdullin: È un piacere e un onore essere tornato. Ero in Lokad quando stava appena iniziando in una piccolissima stanza, credo, all’università. E di tutte le aziende con cui ho lavorato da allora, comprese sette startup, Lokad è stato il posto più stimolante e gratificante della mia vita.
Conor Doherty: Non devi dire nulla direttamente su Joannes, ma quando affermi che è stato il più stimolante, cosa ha reso Lokad così impegnativo? E poi, in contrasto, la difficoltà dei progetti futuri?
Rinat Abdullin: All’epoca eravamo una startup, ed era una combinazione interessante di tentare di trovare una corrispondenza tra le tecnologie e ciò che il cliente voleva e di cui aveva effettivamente bisogno. Equilibrare questo triangolo è sempre stato una sfida perché le tecnologie all’epoca erano agli inizi. Siamo stati uno dei primi grandi clienti di Azure, iniziando appena a costruire una libreria scalabile per elaborare numerose serie temporali provenienti dai clienti. Non c’era supporto; tutto doveva essere costruito da zero, e quel percorso è durato molti anni. È continuato con la creazione di un DSL personalizzato per potenziare gli esperti di Lokad, e continua ancora. Quella è una parte del triangolo. La seconda parte riguardava il fatto che i clienti vogliono numeri migliori; desiderano che la loro attività funzioni in modo prevedibile senza denaro bloccato nell’inventario. Allo stesso tempo, vogliono che questi numeri siano comprensibili perché se fornisci ai clienti dei numeri che escono da una scatola nera magica, gli esecutivi potrebbero dire: “Sì, funziona”, ma gli esperti della supply chain nei warehouses locali direbbero: “Non capisco questi numeri. Non mi fido delle formule, e il mio intuito, basato su 10-20 anni di esperienza, mi dice che no, non funzionerà, quindi li ignorerò.” E ovviamente non puoi licenziare tutti.
Joannes Vermorel: Ascoltando Rinat, lavoravamo con le serie temporali, giusto?
Rinat Abdullin: Sì, Lokad è stata letteralmente fondata come un servizio di previsione delle serie temporali, quindi ne so qualcosa sulle serie temporali, anche se in seguito ci siamo allontanati da quella strada. Abbiamo lavorato con le serie temporali, che rappresentano un elemento di base. La tensione menzionata da Rinat riguardo alla spiegabilità è stata anch’essa affrontata, ma più di un decennio dopo la fondazione di Lokad. Abbiamo dovuto adottare la programmazione differenziabile in modo da avere finalmente modelli di machine learning che fossero spiegabili. È arrivata molto tardi. Per anni, abbiamo dovuto scegliere tra modelli crud che erano white box ma non molto validi, o modelli di machine learning che erano migliori ma black box, creando un sacco di problemi operativi. A volte non erano naturalmente migliori in tutte le dimensioni del problema. È stata una lotta immensa, e il percorso di Lokad è stato quasi un decennio di battaglie in salita. Rinat ha affrontato i primi cinque anni di queste battaglie in salita, e poi ci sono state altre persone che hanno continuato a combattere per le rimanenti. È stata una lunga serie di enormi problemi da affrontare.
Conor Doherty: Grazie, Rinat. Tornando a te, quando cerchiamo di spiegare cosa fa Lokad, lo facciamo attraverso una serie di articoli molto lunghi, lezioni, discussioni come questa. Ma quando si cerca di rendere trasparente il machine learning in questo contesto, come lo affronti?
Rinat Abdullin: Uno degli approcci che ha funzionato piuttosto bene, quando aiutavo a creare un hackathon per un’azienda di logistica internazionale, è stato attraverso le simulazioni. Quando si parla di logistica internazionale, ci sono molte variabili in gioco. Ci sono merci che devono essere trasportate tra più località utilizzando diverse modalità di trasporto. Ci sono compagnie di camion e altre aziende che competono sul mercato aperto per le consegne di merci dalla località A alla località B. Poi ci sono le vere vie di consegna come le strade, le reti ferroviarie, forse la consegna dell’ultimo miglio in qualche luogo. Mentre i camion trasportano le merci tra queste località, si verificano ritardi, ingorghi, e la merce potrebbe arrivare in un magazzino al di fuori degli orari di lavoro, oppure l’area di scarico del magazzino potrebbe essere sovraffollata.
Volevamo modellare tutta questa complessità in un modo accessibile per gli studenti o i nuovi assunti nell’azienda. Quello che abbiamo fatto è stato piuttosto brutale. È forse molto simile a come gli antichi ricercatori cercavano di modellare il numero pi lanciando una moneta attraverso una simulazione. Così abbiamo creato una mappa virtuale dell’Europa con strade principali, e in questa mappa virtuale, le strade avevano una lunghezza, il tempo scorreva, i camion andavano avanti e indietro, e le compagnie di camion potevano decidere quale merce raccogliere e se consegnarla in tempo. Quello è stato il punto di ingresso per i partecipanti all’hackathon perché potevano programmare agenti che prendevano decisioni come, “Sono l’autista A, e andrò a raccogliere questa merce dalla località A alla località B.” Ma c’era un trucco: quando un camion trasporta merce da una località all’altra, proprio come nel mondo reale, ha un costo. Per guadagnare denaro, devi pagare le tasse, il carburante, e devi assicurarti che l’autista si riposi.
Essendo una simulazione, non servivano formule complesse; stavi applicando brutalmente la realtà. Esegui semplicemente come uno script batch per NPC o per un gioco in sequenza, e puoi avere molte regole spiegabili su un foglio di carta. Questo intero mondo era così comprensibile per le persone che abbiamo effettivamente creato due livelli di difficoltà. Nel primo livello, le aziende guidavano semplicemente camion cercando di guadagnare il massimo. Nel secondo livello, i prezzi del gas salivano un po’, le aziende dovevano compensare le emissioni di CO2, e gli autisti potevano stancarsi. Se l’autista guidava per più di 12 o 14 ore, aumenta la possibilità di un incidente. Quando si verifica un incidente, l’autista si riposa, e quella macchina non fa nulla, facendo essenzialmente perdere tempo. Abbiamo costruito questo ambiente, i partecipanti hanno potuto programmare i loro agenti, e quando si esegue una simulazione a eventi discreti ad una velocità accelerata, si ottengono essenzialmente mesi di tempo virtuale che passano in secondi di tempo reale.
Siamo riusciti rapidamente a far girare molte simulazioni e dire: “Ehi team, le decisioni che i vostri agenti stavano prendendo in questo mondo virtuale, questa era la lead time distribuizione, questo era il prezzo, questi erano i margini, e questo era il numero di incidenti che i vostri agenti accumulavano.” In sostanza, questo è l’approccio che normalmente adotto quando devo spiegare un ambiente complesso. Si inizia con la simulazione perché ha un aspetto ludico, è facile spiegare le regole, non serve ricorrere alla programmazione differenziale. Ma quando esegui questa simulazione, è essenzialmente un’analisi Monte Carlo che traccia le dipendenze in sistemi complessi. Significa che, ad esempio, in alcuni casi, non si ottiene una distribuzione semplice all’esterno, ma a causa dell’interferenza tra molteplici elementi del sistema, si ottengono schemi di interferenza nelle distribuzioni esterne. Sembra una scatola nera, ma le persone possono comprendere le regole, possono cambiarle, e poi, ad esempio, se un’azienda finalmente capisce come funziona questo ambiente e apprezza i numeri che escono in maniera lenta perché la simulazione richiede tempo, allora c’è un modo per ottimizzare il calcolo, dicendo: “Okay, questi sono i numeri che otteniamo dalla simulazione, e passiamo alla programmazione differenziale direttamente con le probabilità per ottenere gli stessi numeri ma in modo più veloce.” È solo un’ottimizzazione delle prestazioni. Quindi è così che normalmente lo affronto.
Joannes Vermorel: Ciò che è molto interessante è che nell’ultimo anno è emersa una nuova classe di strumenti, gli LLM, e questo è particolarmente interessante perché si tratta letteralmente di un’intera classe di tecnologie che esistono da circa cinque anni, ma che erano molto di nicchia e solo gli esperti potevano davvero comprenderne il potenziale, visto che all’epoca si parlava principalmente di potenzialità. Forse, Rinat, come vedi che cambia l’introduzione di questa classe di strumenti degli LLM? Come la paragoni? Avevamo varie classi di strumenti per il machine learning per le aziende, come la classificazione, la regressione, le simulazioni Monte Carlo. Erano classi di strumenti che potevano essere integrate, e ora abbiamo un’altra classe di strumenti completamente diversa, gli LLM. Forse per il pubblico che potrebbe non conoscere gli LLM oltre a ChatGPT, come li interpreti in un contesto di enterprise software, dei flussi di lavoro aziendali? Qual è la tua visione di insieme a riguardo?
Rinat: Sono in contatto con i modelli linguistici dal 2015, prima che i chatbot uscissero e li rendessero popolari. Hai ragione, erano davvero di nicchia. Venivano usati nei traduttori linguistici, nel riconoscimento vocale e in modelli linguistici che correggevano errori di ortografia o aiutavano a trovare testi in grandi corpora. Quando sono apparsi tramite ChatGPT, la loro popolarità è esplosa. Uno dei motivi è che sono stati addestrati per essere utili e obbedienti alle persone.
Ed è proprio per questo che a volte risultano così irritanti: quando vuoi ottenere risultati dal modello, e questo inizia a scusarsi ripetutamente dicendo “mi dispiace”, diventa frustrante. Personalmente, divido i modelli su larga scala in due categorie. Una categoria di modelli lavora principalmente con i numeri, parliamo di regressioni, Monte Carlo, reti neurali. L’altra categoria, quella dei large language models, sì, lavora con i numeri, ma in apparenza opera sul testo, su lunghi testi non strutturati, ed è da qui che deriva la loro usabilità fondamentale.
Questi modelli permettono di collegare una macchina o un’automazione direttamente alle interazioni umane. Ad esempio, con le regressioni o le serie storiche, è necessario inserire il modello da qualche parte all’interno dei processi digitali aziendali. Da un lato c’è un database, al centro un motore di previsione e, forse, dall’altro lato un database o un CRM o ERP. Nel migliore dei casi, ottieni un report, ma resta comunque un insieme di numeri. Con gli LLM, ti colleghi direttamente al centrodello processo aziendale, nel mezzo dei flussi di lavoro umani.
Questo apre innumerevoli possibilità, soprattutto perché non serve molto sforzo per implementare qualcosa che un decennio fa sarebbe stato completamente impossibile o troppo costoso. Ad esempio, personalmente, quando lavoro con gli LLM, ho la sensazione di avere il mio dipartimento privato di assistenti. Sono poliglotti, full-stack, magari a volte ingenui, ma sono anche intelligenti e non si lamentano mai. Ad esempio, chiedere loro di spostare un pulsante in un layout o di riscrivere una lettera a un magistrato in Germania è estremamente utile, molto obbediente, a volte stupido, ma sono in grado di fare grandi cose.
Nelle classi aziendali di adozione degli LLM che ho osservato, ciò avviene principalmente in quella che viene chiamata digitalizzazione aziendale. Aiuta le aziende ad automatizzare flussi di lavoro che ruotano attorno alla ricerca di testi in grandi corpora. Per esempio, un’azienda possiede una quantità enorme di dati, ha le proprie basi di conoscenza, ma queste basi sono sostanzialmente dei silos. Potrebbero consistere in RFC, questionari o una Wikipedia che nessuno aggiorna realmente, e le persone devono svolgere attività che a volte richiedono di cercare informazioni in luoghi poco noti. Questo richiede tempo, sforzo ed energia cognitiva.
Ciò che gli LLM possono fare è eseguire un lavoro preparatorio. Possono redigere articoli, possono fare ricerche sui dati privati di un’azienda, dicendo: “Okay, stai compilando questa risposta per l’azienda, quindi basandomi sui flussi di lavoro della tua azienda e sui prompt codificati, questa è la mia bozza.” Per ogni voce in questa checklist di risposta, possono indicare da dove hanno tratto l’informazione. Così, la persona non deve più compiere il lavoro di routine e può concentrarsi sull’attività intellettualmente più impegnativa di verificare se il modello ha ragione. Questo consente di incrementare in modo massiccio l’efficienza dell’azienda.
Quando ChatGPT è uscito, la gente aveva davvero paura che gli LLM e l’IA avrebbero portato via i loro lavori, ma non è così. Fidatevi, aiuto i clienti a realizzare prodotti basati su LLM e ML da parecchio tempo, e richiede un grande impegno produrre qualcosa in grado di sostituire un essere umano. È quasi impossibile. Ma ciò che gli LLM possono fare è rendere gli impiegati attuali molto più efficienti, a volte anche da 10 a 100 volte. Questi sono casi eccezionali. Rendono semplicemente le persone più efficienti, ma non potranno mai sostituirle. Deve esserci sempre un essere umano nel processo.
Conor: Grazie, Rinat. Joannes, i tuoi pensieri? Voglio dire, quando osservo le supply chain, direi che funzionano per metà e per metà. Metà delle persone utilizza i fogli di calcolo e l’altra metà si occupa di comunicazioni quotidiane con partner, fornitori, clienti e altri. I fogli di calcolo servono davvero ad automatizzare la decisione sulla quantità, ed è questo che Lokad fa da un decennio. La seconda parte, invece, per lo più non era automatizzata perché, fino all’avvento degli LLM, non esisteva una tecnologia plausibile per risolvere quel problema.
Rinat: Nella mia esperienza, le supply chain sono un po’ lente ad adottare gli LLM come nucleo del processo. Gli LLM iniziano piuttosto a insinuarsi dall’esterno. Quindi, un caso comune è che i reparti marketing sono di solito i primi ad adottarli. Quando un’azienda, per esempio, si interfaccia direttamente con gli utenti, il confine tra l’azienda e i clienti è dove ho visto la maggiore adozione. Ad esempio, esistono marketplace che vendono prodotti ai propri clienti, e vogliono rendere questa interazione più gradevole e magari ridurre il costo della gestione di tale interazione.
È già abbastanza fattibile costruire sistemi che scansionano automaticamente i cataloghi dei prodotti uno ad uno, instancabilmente, 24/7, e notano: “Okay, questo è un prodotto, ma è stato inserito in modo errato dal fornitore della supply chain.” Perché? Perché ho setacciato internet, ho trovato le specifiche di questo prodotto, che sono simili, ho anche rinvenuto la descrizione in PDF del produttore, e secondo me, dato che circa metà di internet riporta questo numero correttamente e tu lo hai sbagliato. Queste sono le referenze. Per favore, decidi se correggerlo automaticamente. “Oh, caro manager, ho visto che hai corretto la descrizione di questo prodotto, questa sua caratteristica. Vuoi che rigeneri la descrizione per includere il numero aggiornato, non solo il numero ma anche il testo?” E, nel frattempo, ho creato tre descrizioni di prodotto così puoi scegliere quella che ha più senso. Ho anche preparato un testo per il marketing SEO, aggiornato le parole chiave sul tuo motore di pubblicazione, e creato un annuncio su Twitter e uno su LinkedIn.
Un altro punto di contatto tra i clienti e i rivenditori che si collegano alla supply chain è la scheda prodotto sui marketplace. Immagina di essere un fornitore che deve operare con numerosi marketplace, e il tuo catalogo consiste di 10.000 articoli con piccole variazioni, come parti di automobili o di aerei. Vuoi automatizzare questo processo, specialmente se il tuo inventario cambia abbastanza rapidamente. È del tutto fattibile, e l’ho già visto realizzato. Ad esempio, ricevi un paio di immagini del prodotto, soprattutto se si tratta di prodotti di seconda mano, particolarmente nella moda, e funziona davvero bene. Le fai analizzare con il riconoscimento delle immagini, che funziona al meglio quando è addestrato su moda e stile. Ottieni i testi, le descrizioni, selezioni i box, ridimensioni automaticamente le immagini, e da tutto ciò generi una descrizione per i clienti.
E poi arriva una delle parti più belle. Crei anche una descrizione nascosta potenziata dagli LLM, che viene usata per la ricerca semantica. Cosa significa? Quindi quando un cliente di una piattaforma di moda cerca un capo d’abbigliamento, non cercherà sempre, per esempio, una camicia in stile boho con draghi, taglia M e sotto i 10 dollari. Cercherà: “Ehi, stasera vado a una festa, e i miei amici ci saranno, cosa posso indossare che completi i miei shorts?” Se hai descrizioni di prodotto e spiegazioni semantiche estratte dagli LLM dal prodotto, e le cerchi, non per il testo completo – perché chissà come scrivono “boho” le persone – ma usi una ricerca basata su embedding, che è essenzialmente una ricerca vettoriale, ovvero una ricerca sul significato del testo e non sulle parole esatte, allora ottieni dei risultati che, esteriormente, sembrano magici perché il modello in qualche modo inizia a suggerire ciò che intendevi chiedere, non quello che hai effettivamente detto.
Conor: Grazie, Rinat. Joannes, il tuo parere? Voglio dire, quando osservo le supply chain, direi che operano per metà e per metà. Metà del tempo le persone si occupano dei fogli di calcolo, e l’altra metà della gestione quotidiana di partner, clienti, trasportatori, fornitori e simili. I fogli di calcolo servono davvero ad automatizzare la decisione sulla quantità, ed è questo che Lokad fa da un decennio. La seconda parte, invece, per lo più non era automatizzata perché, fino all’avvento degli LLM, non esisteva una tecnologia credibile a rispondere a quella necessità.
Joannes: Cioè, le attività che richiedono comunicazione, se erano parte di un flusso di lavoro molto stretto, potevano essere automatizzate – ad esempio tramite EDI per trasmettere un ordine. Avremmo un ponte che trasmette l’ordine, e poi si presenterebbe un problema non testuale. Ma non è esattamente questo che si intende quando si dice che si trascorre metà del tempo sui fogli di calcolo e l’altra metà gestendo partner, clienti, trasportatori, fornitori. È più una situazione del tipo: “Potresti accelerare questo ordine, e se sì, a quale prezzo?” È qualcosa di più sfumato e aperto.
Bisogna prendere questo caso limite e scrivere un’email relativa, chiarendo in qualche modo l’intento, cosa è in gioco, e questo richiede mezz’ora. Poi ripeti con una situazione diversa, un problema differente, e produci un’altra email. Così finisci con un dipartimento acquisti in cui ognuno, nell’arco di otto ore lavorative, passa quattro ore sui fogli di calcolo e quattro ore a scrivere 20 email a 20 partner. Qui vedo un enorme potenziale di miglioramento. Lokad sta letteralmente automatizzando già la prima parte, ma con gli LLM c’è un enorme potenziale per automatizzare in larga parte, anche se non completamente, la seconda parte. Sostanzialmente, permettendo alle persone, direi, di avere supporto nell’auto-comporre comunicazioni che verranno ricevute dai loro partner. L’LLM è stato utilizzato per fornire una versione ragionevolmente contestualizzata della dichiarazione del problema e di ciò che ci aspettiamo dal partner.
Se la dichiarazione del problema ha confini ben definiti, allora si usa l’EDI; diventa semplicemente parte del flusso di lavoro completamente automatizzato. Ma sto parlando del resto, delle situazioni non perfettamente allineate, per esempio quando ordini 1.000 unità e ne consegnano 1.050. Non rifiuterai l’ordine solo perché hanno consegnato 50 unità in più. Ti piace questo fornitore, quindi accetterai e convaliderai l’ordine, lo riceverai e pagherai per 1.050 unità invece di 1.000. Però vorresti comunicare in modo educato al tuo fornitore che preferiresti che rispettasse l’accordo iniziale, ovvero spedire 1.000 unità e non 1.050. C’è una certa sfumatura qui, dove senza interrompere il flusso di lavoro – che è quasi corretto – vuoi comunque far capire che non è accettabile consegnare sempre il 5% in più affinché il fornitore possa addebitarti un po’ di più.
Questo è il tipo di situazione in cui gli LLM eccellono davvero, in quella comunicazione soft dove devi trasmettere un messaggio. Ci vorrebbe tempo per bilanciare la formulazione in modo che non sia troppo aggressiva, pur facendo capire al partner che hai una forte preferenza affinché si attenga rigorosamente alla quantità inizialmente concordata. È il tipo di cosa per cui qualcuno potrebbe rimuginare su un’email per un’ora per scrivere quel passaggio, e con gli LLM moderni è esattamente questo il genere di attività che non richiede una super-intelligenza. L’intelligenza che possiedono questi LLM è quella linguistica, e se vuoi impostare il tono giusto, hanno capacità quasi sovrumane. Non sono necessariamente super-intelligenti nel senso di cogliere il quadro generale o orientarsi nella direzione giusta, ma se vuoi avere lo stesso testo con una sfumatura più cupa, se vuoi lo stesso testo ma leggermente più aggressivo, o al contrario più delicato o più di supporto, sono eccezionalmente bravi in questo.
Potrebbero volerci forse 20 minuti per farlo per mezza pagina, mentre un LLM può farlo letteralmente in pochi secondi. È proprio questo il tipo di operazione in cui si può ottenere un enorme incremento di produttività per quelle attenzione sottili su cui le persone letteralmente impiegano ore. Se portiamo il concetto ad un livello superiore, immagina un’azienda che ha migliaia di comunicazioni del genere sui casi limite durante la giornata. È una nuova capacità che gli LLM offrono. Per gli imprenditori, per gli stakeholder, ottenere una visione d’insieme richiede impegno, ma ora abbiamo gli LLM, che sono molto bravi a scansionare enormi quantità di testi non strutturati e a trovare schemi ricorrenti. Immagina che un LLM possa effettivamente leggere centinaia di rapporti, email o comunicazioni di andata e ritorno riguardanti il non invio del 5% in più e, alla fine della giornata, fornire un riassunto conciso ai dirigenti dicendo: “Ehi, sembra che ci sia un modello ricorrente in cui sempre più fornitori nell’ultima settimana stanno cercando di inviarci più scorte.”
Come sapete, ChatGPT ha una straordinaria capacità chiamata advanced data analytics, ed è letteralmente come avere un intero dipartimento di analisti di dati sotto il vostro controllo. Non sono esperti di supply chain, quindi avrete comunque bisogno di Lokad per quello, ma potete chiedere loro domande semplici come: “Ecco il mio file di database, ecco il mio file Excel, esegui un’analisi per me e individua le tendenze.” Questa è la parte sorprendente che è possibile soprattutto online. Non puoi farlo localmente o tramite l’API, ma ChatGPT svilupperà teorie, scriverà un codice, lo eseguirà, magari incontrerà errori, li correggerà, stamperà i risultati e perfino creerà un grafico per te. L’intero processo, dal momento in cui invii un foglio Excel e una domanda fino al bel grafico, è completamente automatizzato. È auto-correggente, auto-riparante, e ottieni risultati soddisfacenti. Ciò dà ai decisori aziendali la capacità di analizzare i dati da soli, anche se sono archiviati in sistemi complessi, e di visualizzarli senza dover conoscere Python, JavaScript, C o SQL. Penso che sia davvero empowering, apra nuove opportunità di business e crei nuovo valore aziendale.
Conor: Circa sei mesi fa abbiamo discusso di AI generativa e del suo ruolo nella supply chain, e nel complesso eravamo un po’ scettici. Quando ascolti ciò che è stato descritto riguardo ai progressi avvenuti solo negli ultimi sei mesi, mantieni la stessa prospettiva o ti sei un po’ ammorbidito?
Joannes: La mia posizione rimane fortemente scettica su alcuni aspetti. Il mio scetticismo è nato essenzialmente in reazione alla maggior parte dei concorrenti di Lokad che dicono: “Applicheremo ChatGPT direttamente a terabyte di dati transazionali, e funzionerà.” Secondo me, no, non credo proprio. Sono ancora molto scettico perché non è affatto così. Se dici che ciò che puoi fare è elencare un paio di tabelle con i relativi schemi, o far sì che lo strumento esegua automaticamente un’indagine dello schema del database per eseguire analisi usa e getta come la dimensione media del carrello, quella è una proposta completamente diversa. In passato, questo avrebbe dovuto essere gestito dal team di business intelligence. Sto parlando di cose basilari come qual è la dimensione media del carrello, per quanto tempo in media tratteniamo i clienti, quante unità abbiamo venduto in Germania—domande molto elementari. Nelle grandi aziende, di solito ci sono decine di persone nelle divisioni BI che producono report usa e getta tutto il giorno. Per questo tipo di cose, credo che gli LLM possano davvero aiutare, ma non è assolutamente quello che i nostri concorrenti propongono. Dicono: “Avete questi modelli, dategli il vostro database da un terabyte, dategli accesso a Twitter e Instagram, e avrete la vostra pianificazione, la vostra decisione, tutto, ed è completamente automatizzato.” Io dico no, neanche lontanamente. Siamo in un mondo di fantasia.
Rinat: Per quanto riguarda la tua risposta a questa sfida, ho due considerazioni da condividere. Innanzitutto, riguardo il processo di utilizzo degli LLM per elaborare grandi quantità di dati, lavoro con vari LLM da parecchio tempo. Una delle prime domande che i clienti in genere pongono è se possano eseguire qualcosa come ChatGPT localmente, nelle loro sedi. Per rispondere a ciò, è necessario effettuare dei benchmark degli LLM in diverse configurazioni e calcolare i costi. Gli LLM sono piuttosto costosi. Per far elaborare un megabyte di testo attraverso gli LLM per la previsione, potrebbe costare un paio di euro, a seconda del modello. Se vuoi eseguirlo localmente sui migliori modelli disponibili, potrebbe costarti €10 o forse €20.
Ed è quello che fa GPT-3.5; è molto economico. Ma il punto è che non è nemmeno possibile far passare terabyte o petabyte di dati attraverso gli LLM. In secondo luogo, gli LLM sono pessimi con i numeri. Se qualcuno chiede a un LLM di effettuare calcoli matematici o di elencare numeri primi, si tratta di un uso improprio. Gli LLM sono modelli linguistici; dispongono di una vasta base di conoscenza e sono molto intelligenti, sebbene presentino ancora dei limiti. Non si chiede a un LLM di risolvere un problema matematico; piuttosto, gli si chiede di formulare il problema, e poi il calcolo viene affidato a un kernel Python specializzato o a qualcosa che lo faccia molto meglio invece di sprecare l’operazione su un LLM.
Le cose più interessanti accadono nel punto di contatto tra diversi domini. Ad esempio, abbiamo da una parte il vasto dominio numerico, dall’altra il testo o casi limite soft e fuzzy, e infine il codice come terzo elemento. Il codice non è numeri, non è testo, è strutturato ma verificabile, e gli LLM sono eccezionalmente bravi a gestirlo. Questo crea nuovi casi che potrebbero essere applicabili alla supply chain, spingendo ulteriormente l’applicabilità di soluzioni come Lokad.
Ad esempio, un caso in cui ho applicato gli LLM per analizzare grandi quantità di testo oltre le capacità degli stessi è stato formulare il problema per l’LLM. Per esempio, trovare del testo in centinaia di gigabyte di report annuali in tutto il mondo o aiutare a risolvere un problema numerico senza eseguire il calcolo vero e proprio. Arrivi a una teoria su come affrontarlo perché sei intelligente, conosci il contesto, e questi sono i controlli che ti fornisco.
Quando si parla di cercare all’interno di un enorme database, chiedo all’LLM con una sintassi specifica di elaborare ricerche embedding su cui lavorerò, di generare una lista di parole chiave da escludere, o una whitelist di parole chiave che potenziano la ricerca. Poi un altro sistema, dedicato a questo e molto efficace nell’elaborazione su larga scala, prenderà questa richiesta ben formulata dall’LLM ed eseguirà l’operazione. È da qui che viene il punto forte, perché gli LLM sono capaci di affinare le ricerche.
Ritorni dall’LLM e dici: “Questo era il mio problema originale, questo è ciò che ne hai pensato, questa è la query che hai formulato, e questo è lo spam che ha restituito. Per favore, aggiusta e adatta.” Poiché lavorare con gli LLM costa praticamente nulla, puoi iterare magari dieci volte, magari sviluppando una chain of thought, o un tree of thought, con decisioni buone e cattive, fino a migliorare. Lo stesso vale per i domini numerici. Ad esempio, i responsabili delle scorte vogliono avere un’idea di come bilanciare meglio il loro magazzino. In teoria, potrebbero dire: “Ecco una piccola simulazione del mio ambiente, che forse è abbastanza buona, e questo è come puoi modificarla. Ora, per favore, esegui un fuzzy constraint solving e prova a proporre idee che potrebbero aiutarmi a bilanciare meglio le mie scorte.”
Questa è la possibilità che si apre quando inizi a collegare più domini: numerico, codice e testo, e utilizzi insieme i migliori strumenti disponibili per ogni dominio.
Conor: Grazie, Rinat. Joannes, cosa ne pensi a riguardo?
Joannes: Solo per chiarire per il pubblico, la cosa interessante è che per molti problemi il modo in cui si vuole affrontarli con un LLM è dire: “Per favore, componi un programma che risolva il problema.” Non direte: “Voglio che tu risolva il problema.” Direte: “Componga un programma, e poi io lo imparerò.” Ci sono ulteriori stratagemmi, come fornire all’LLM un compilatore per verificare se il programma si compila o uno strumento che ti permetta di eseguire il programma per controllare che l’output abbia senso.
Non si tratta di far risolvere il problema direttamente all’LLM; è una soluzione mediata. L’LLM produce un programma, poi utilizza qualcos’altro che, essendo ancora un output testuale, se usi un compilatore, tenterà di compilare il programma. Se non funziona, fornirà un messaggio di errore. Gli LLM adorano elaborare i messaggi d’errore e correggere i problemi associati. Siamo decisamente nel regno del testo.
Per la supply chain, la maggior parte delle situazioni saranno mediate. Vogliamo che l’LLM componga il programma che risolverà ciò che stiamo cercando di fare. Ad esempio, con il problema iniziale di trovare il fatturato in Belgio dell’anno scorso per clienti con oltre 1 milione di EUR, l’LLM non preleverà i dati dal database per farlo. Compilerà una query SQL che verrà eseguita dallo stesso database. Ancora, si tratta di mediazione.
Cosa significa ciò per il software aziendale? Hai, come parte del tuo ambiente software aziendale, piattaforme che supportano l’esecuzione della supply chain, almeno il livello decisionale, con capacità programmatiche? L’LLM non preleverà i dati grezzi delle transazioni per produrre l’output; prenderà la dichiarazione del problema, produrrà un programma, ed è molto versatile nel tipo di programma che può produrre. Ma poi qualcosa nel tuo ambiente deve eseguire il programma. Che tipo di ambiente di programmazione puoi fornire all’LLM?
La maggior parte del software aziendale classico non fornisce alcun ambiente. Hanno solo un database con un linguaggio che puoi utilizzare, ma l’unico modo per interagire con, ad esempio, un grande ERP che dovrebbe permetterti di ottimizzare il tuo inventario, è impostare manualmente i livelli minimi e massimi delle scorte o i parametri di safety stock prodotto per prodotto. L’LLM può dirti la ricetta da applicare, ma se vuoi applicarla dovrai passare attraverso le impostazioni manuali dell’ERP. Se l’ERP fornisce un’API, può comporre un programma che ti permetta di farlo su larga scala tramite l’API, ma è comunque molto macchinoso rispetto ad avere una soluzione programmatica nativa. Rimarrà comunque mediato dal framework.
Ciò richiede alcuni cambiamenti profondi e introduce la programmabilità della soluzione come elemento di primo piano. Senza mezze misure, Lokad dispone di una piattaforma programmatica. Non l’abbiamo fatto per gli LLM; è stato in gran parte un colpo di fortuna, ma l’abbiamo fatto 10 anni fa per avere questa mentalità programmatica come nucleo della piattaforma e come elemento di primo piano. È stato caso, non un’intuizione visionaria su ciò che sarebbe successo tra un decennio con gli LLM.
Conor: Grazie, Joannes. Tengo conto del tempo di tutti, quindi come da consuetudine, Rinat, ti passo la parola per un pensiero conclusivo. C’è qualcosa che vuoi dire a tutti quelli che ci stanno guardando?
Rinat: Ci sono state un paio di bolle in passato, come la bolla dot-com e quella finanziaria. Gli LLM e l’AI potrebbero essere anch’essi una bolla, o potrebbero non esserlo. Persino mia madre conosce ChatGPT e come usarlo, il che è interessante. Invito tutti a non avere paura dei nostri signori macchine, perché Skynet non funzionerà così facilmente. Come qualcuno che cerca di stabilizzare queste cose in produzione, so che richiede molto impegno e non funziona facilmente in modo affidabile. Quindi, prima di tutto, non fatevi intimidire dagli LLM, e in secondo luogo, abbracciateli. Gli LLM, insieme agli esseri umani e alle aziende, possono creare molto più valore, specialmente se integrati con strumenti specializzati come la previsione di Lokad che si adatta davvero bene all’ambiente.
Conor: Grazie, Rinat. Joannes, grazie mille per il tuo tempo. Rinat, grazie infinite per essere tornato con noi. E grazie a tutti voi per averci seguito. Ci vediamo la prossima volta.
