00:00:00 Introduzione
00:02:49 Claude puo davvero prevedere?
00:07:49 Gli LLM elaborano davvero i numeri?
00:09:12 Come influenzera l’IA i fornitori di previsioni?
00:14:38 Qual e la differenza tra previsione e pianificazione?
00:18:03 Gli LLM possono supportare le decisioni di supply chain?
00:22:31 Dalle previsioni di ricavi alle decisioni operative quotidiane
00:27:11 Perche le previsioni nude sono inutilizzabili?
00:30:12 Prevedere decisioni granulari di supply chain
00:34:57 Un’IA puo generare autonomamente ordini di acquisto?
00:42:24 Quali settori adotteranno l’IA piu rapidamente?
00:44:25 Cosa diventa piu o meno prezioso?
00:52:48 Come dovrebbero valutare le aziende i fornitori di IA?
00:55:51 Usare ChatGPT per la ricerca sui fornitori
00:56:19 Perche il prompting avversariale conta
01:00:36 Lokad puo superare lo stesso stress test?
Sommario
Conor Doherty intervista Joannes Vermorel, CEO e fondatore di Lokad, su Claude Fable 5.1 e sulle sue capacita di previsione pubblicizzate. Joannes sostiene che la vera svolta sia nella capacita degli agenti di automatizzare attivita analitiche e di programmazione. Esaminano perche le previsioni di serie temporali non siano piani di supply chain, come gli LLM possano supportare l’automazione delle decisioni e quali settori potrebbero adottarli piu rapidamente. La discussione si conclude con un quadro pratico per mettere alla prova i fornitori di IA, valutarne la tecnologia, pretendere guadagni di produttivita misurabili e usare prompt avversariali per verificare le affermazioni di marketing.
Trascrizione completa
Conor Doherty: Joannes e io abbiamo appena concluso la nostra discussione sul rilascio di Claude Fable 5.1 da parte di Anthropic, in particolare sulle sue capacita di previsione, almeno quelle pubblicizzate. La conversazione e nata da un video che abbiamo ricevuto da un amico del canale. Voleva la nostra opinione, la nostra reazione alle implicazioni di questa possibile svolta nelle previsioni, che ovviamente si basa su un modello LLM. Joannes e io ne abbiamo parlato, e questo ci ha portati a una discussione piu ampia su come si dovrebbero davvero valutare i fornitori in questo spazio, inclusa Lokad. Alla fine, Joannes ha fornito, credo, una guida molto pratica, o un test diagnostico, nel caso in cui ci si trovi davanti a una proposta di un fornitore che dice: “Si, la mia IA puo prevedere, pianificare ed eseguire autonomamente la tua supply chain end to end.” Come dicevo, Joannes ha dato indicazioni molto concrete e utili su come mettere alla prova queste affermazioni.
Quindi, se non portate via nient’altro da questo episodio, restate fino alla fine, o saltate direttamente alla fine se preferite, e prendete quelle informazioni pratiche. E con questo, vi lascio alla conversazione di oggi. Joannes, ti ho portato qui per discutere un video che ci e stato inviato da un amico del canale. Te l’ho mandato.
Ne abbiamo parlato in privato, e ora ci sediamo qui per registrare un podcast su questo tema. Si tratta del video pubblicato da Anthropic, che descriveva, o diciamo pubblicizzava, le capacita di previsione di Claude Fable 5.1. Per il resto del video diro semplicemente Fable, perche non voglio dire Claude Fable 5.1 in ogni frase, ma da ora in poi ci riferiamo a Claude Fable 5.1. In questa demo, lo si vede acquisire dati B2B grezzi e poi eseguire previsioni di fatturato durante la notte, senza supervisione, producendo report per gli analisti.
Poi gli analisti possono rivederli. Puo eseguire i propri backtest tramite una semplice interfaccia tipo ChatGPT. Tutto questo e fantastico. Il follower di Lokad me l’ha inviato dicendo che sarebbe stato interessante avere la nostra opinione, per ovvie ragioni, perche se esiste un’IA commercialmente disponibile che, in sostanza, esegue previsioni senza supervisione durante la notte, producendo, nelle parole usate, risultati…
Approfondiremo cosa significhi “risultato”, previsione rispetto a decisione, e cosa comporti, ma un’IA commerciale che produce previsioni durante la notte: voleva conoscere la nostra opinione, in particolare la tua, ovviamente, su cosa significhi per il mercato. Quindi, Joannes, hai visto il video, hai il contesto. Sei rimasto colpito?
Joannes Vermorel: Effettivamente un po’, si. E a essere onesti e impressionante. E molto impressionante. Ma cio che e molto piu impressionante di quanto lasci intendere questo caso d’uso e che la previsione e solo un esempio. Quello che e successo, direi, dallo scorso settembre, quindi da circa un anno, e che questi agenti di coding hanno acquisito un grado di autonomia per compiti relativamente semplici che e assolutamente impressionante. Direi quindi che da circa un anno, e questo era persino prima di Claude Fable 5.1, il vero salto e avvenuto intorno all’estate scorsa.
Non questa, quella precedente. Si possono chiedere compiti relativamente semplici, del tipo che si chiederebbe a un business analyst. Uno di questi sarebbe: “Costruiscimi un modello di previsione, assicurati che si adatti ai dati storici con un backtest, e poi rivedi questa cosa ogni giorno per verificare che sia ancora pertinente.” E si, funzionera. In pratica costruira il connettore per collegarsi alle fonti dati, assumendo che possa scrivere qualche query SQL.
Esportera i dati in alcuni file di testo piatti. Comporra uno script Python. Eseguira lo script Python. Poi comporra una mini interfaccia web e presentera i risultati in modo ben confezionato.
E a lato costruira anche l’utilita di backtest, per assicurarsi che l’adattamento del modello sia ragionevolmente buono sui dati disponibili. Poi, con qualcosa di separato che non e esattamente chiarito nel video, si puo far chiamare il proprio LLM secondo una pianificazione quotidiana per rivedere tutto l’insieme e aggiornare la previsione. Ma non fraintendiamo: il tipo di previsione che verra costruito sara semplicemente un vecchio modello di previsione tradizionale. Non c’e nulla nel video che suggerisca che Fable stesse facendo qualcosa di particolare. Comporra una sorta di modello regressivo con alcuni parametri per tenere conto delle ciclicita, business as usual. Menzionano un processo Monte Carlo, 1000, si, e quello che ha detto, probabilmente la costante del ciclo usata in Python per eseguire alcune iterazioni.
Ancora una volta, nulla di troppo sofisticato. Ma cio che e davvero impressionante non sono i risultati di previsione, che mi sembrano estremamente ordinari, ma il fatto che con questi agenti si possa affidare praticamente qualunque cosa si affiderebbe a un business analyst e ottenere, in quasi autonomia, un risultato abbastanza decente per questi compiti relativamente semplici, a condizione di avere gia un ambiente configurato. Perche l’ambiente di setup sara molto probabilmente la parte piu complicata: avete un accesso in sola lettura al database? Non volete dare al vostro agente un accesso lettura-scrittura alla produzione.
Quindi, ha un accesso in sola lettura? Python e installato? Node e installato? Avete questo e quello, tutte le dipendenze e tutti gli accessori? E se volete condividere la cosa con i colleghi, serve un modo per distribuire questa web app, altrimenti restera solo sul vostro desktop. Se volete condividerla, i colleghi dovranno installare non so cosa, fare git checkout, avere esattamente gli stessi permessi. Il problema principale sara quindi la plumbing, l’infrastruttura, il setup. Ma si, con gli agenti moderni e i LLM moderni, gli LLM allo stato dell’arte, queste cose si fanno letteralmente in un colpo solo.
Conor Doherty: Si. Hai menzionato l’espressione “compiti semplici”. Voglio richiamare qualcosa di cui abbiamo parlato alcuni anni fa. Ricordo quando usci ChatGPT 3.5.
Era la fine del 2022, l’inizio del 2023. Discutevamo di LLM, grandi modelli linguistici, e tu sottolineavi che eccellevano nei compiti basati sul testo. Ora invece parliamo di LLM che, piu o meno, macinano numeri. E questa l’affermazione che stai facendo?
Joannes Vermorel: No, non tocca quasi nessun numero. Quasi nessuno. Tocca Python.
Conor Doherty: D’accordo.
Joannes Vermorel: Vedi, con questo approccio il modello non tocchera quasi mai i numeri. Comporra una query SQL, che e testo. Comporra uno script Python, che e testo.
Eseguira, comporra uno script Python per il backtest, anche questo e testo. Poi ricevera un mini riassunto dell’adattamento, che sara solo una piccola manciata di numeri. E questo un LLM lo puo elaborare. Anche ai tempi di GPT 3.5, poteva elaborare mezza dozzina di numeri in una conversazione. Quello che non poteva fare era elaborare migliaia di numeri. Ma qui non e questo che accade, e Fable non prova nemmeno a elaborare migliaia di numeri. E uno script Python, con esecuzione classica, a farlo.
Conor Doherty: D’accordo. Questo ci riporta alla domanda iniziale di framing. Quando il video ci e stato inviato, la domanda esplicita era: in che modo questa svolta, anche se e ancora piuttosto nascente, questa entrata generale degli LLM nella previsione, impatta i fornitori del settore, per esempio chi vende servizi di previsione? Perche qualcuno dovrebbe continuare a pagare un abbonamento a un fornitore se puo semplicemente abbonarsi ad Anthropic?
Joannes Vermorel: Si. Per prima cosa, dobbiamo constatare che quei fornitori erano gia obsoleti vent’anni fa, molto prima degli LLM. Qui puo sembrare strano, ma immaginate persone che usano ancora macchine da scrivere e Apple annuncia il prossimo iPhone. Il fatto di avere un iPhone ancora migliore scoraggera chi usa ancora le macchine da scrivere dal continuare a usarle? No.
La vastissima maggioranza dei software di pianificazione nel dominio della supply chain e concettualmente completamente superata, e lo e letteralmente da due decenni. La cosa molto interessante e che ci sono persino nuove aziende che continuano a nascere in quest’area e, dal primo giorno, sono gia obsolete di vent’anni. E sbalorditivo. Abbiamo ancora concorrenti nati letteralmente nel 2025 o 2026 che partono con concetti che sarebbero stati obsoleti vent’anni fa.
Quindi la prima cosa e un reality check: questi fornitori, direi, non sono affatto impattati, perche se i loro clienti avessero purtroppo un minimo di buon senso, avrebbero capito che erano completamente obsoleti ben prima degli LLM. Ecco perche dico: si, e molto bello, ma non cambia molto. Poi c’e un’altra cosa, di cui abbiamo discusso molte volte: la previsione nuda e un anti-pattern. Cercare la previsione con una prospettiva di serie temporali e rotto. Ne abbiamo parlato a lungo su questo canale. Semplicemente non funziona. E il problema e che, per molte aziende e molte persone, se dici loro che il problema e la serie temporale come concetto, e che e quello di cui dovrebbero liberarsi…
Il punto e: un LLM puo costruire il miglior modello di previsione di serie temporali? Assolutamente. Assolutamente. E non mi sorprenderebbe se dessimo a Fable il tempo di competere in una gara Kaggle e ottenesse un punteggio piuttosto alto. Forse non lo stato dell’arte, forse non il primo, ma in una competizione classica di forecasting non sarei sorpreso se qualcosa interamente assemblato da questo tipo di modello ottenesse un punteggio alto.
Ma il problema e che la prospettiva delle serie temporali e difettosa. E questo, tra l’altro, e un problema che gli LLM non risolvono: gli LLM sono molto accondiscendenti. Se chiedete loro: “Trovami un cavallo piu veloce”, lo strumento vi trovera un cavallo piu veloce. Potrebbe suggerire che i cavalli non sono super appropriati, ma alla fine questi LLM, ed e una buona proprieta, sono estremamente docili.
Fanno cio che viene chiesto. Fa parte dell’allineamento, ed e ottimo, li rende estremamente utili. Ma significa anche che, se chiedete qualcosa che e essenzialmente un vicolo cieco tecnologico, il LLM sara perfettamente felice di consegnarlo. Quindi la domanda diventa: il LLM, un modello allo stato dell’arte, e capace di fare approcci alternativi? Assolutamente. Assolutamente. Non sto dicendo che Fable 5.1 non sia capace di fare l’alternativa.
Ne e assolutamente capace. Lo fara? Non a meno che glielo chiediate. Il problema diventa quindi una questione di competenze di prompting, ma non nel senso di tecniche di prompting elaborate.
E piuttosto la prospettiva di alto livello su cio che state chiedendo. Quindi, tornando alla previsione nuda: e un anti-pattern. Non volete generare previsioni di serie temporali. E completamente inutile.
E si, il LLM puo automatizzarlo completamente, ma e semplicemente la cosa sbagliata da automatizzare.
Conor Doherty: Il modo in cui l’hai formulato, con alcune frasi che hai usato, prepara molto bene la prossima domanda: cosa stai chiedendo a questo strumento di fare? E questo rimanda a qualcosa che hai detto proprio all’inizio. Parafraso: diciamo che puo prevedere, non e la stessa cosa che dire che puo pianificare. Penso che valga la pena dedicare un po’ di tempo alla differenza tra previsione e pianificazione. Per esempio, se dicessi a… In realta no, ti lascio delineare, se vuoi, la differenza funzionale tra avere uno strumento che produce una previsione e avere uno strumento che produce un piano, che presumibilmente e una serie di decisioni da prendere.
Joannes Vermorel: Purtroppo per il mercato, il paradigma e: la previsione e il piano. E torniamo al fatto che le serie temporali sono difettose e che la maggior parte dei fornitori opera su paradigmi obsoleti. Il problema e cosi diffuso che persino aziende come Anthropic, quando vogliono pubblicizzare le capacita del loro modello, cosa fanno? Tornano a un modello di serie temporali, che e completamente rotto e difettoso, perche e…
Conor Doherty: E quello che il mercato vuole, o quello che il mercato conosce, o a cui e abituato.
Joannes Vermorel: Esattamente. E quello che il mercato conosce. Ma e semplicemente un paradigma difettoso. Penso che sia parte del problema. Io respingerei persino completamente la nozione classica di pianificazione, perche la nozione classica di pianificazione e un processo in due fasi: fase uno, conoscete il futuro; fase due, orchestrate l’allocazione delle risorse per corrispondere a quel futuro e garantire la conformita con esso.
La pianificazione, in questo senso, e essenzialmente previsione piu orchestrazione. E quello che dico e che questa prospettiva e rotta. Quindi si, la pianificazione nel senso classico e piu della semplice previsione, ma l’agente puo fare molto facilmente l’orchestrazione. E super facile, e sara altrettanto rotta, perche ancora una volta il problema e che il paradigma e rotto. Se chiedete a un agente di operare in un paradigma rotto, obbedira volentieri, ma il paradigma resta rotto. Quindi non importa quanto l’agente sia intelligente e capace: non consegnera il ritorno sull’investimento che vi aspettate.
Conor Doherty: Ti chiedero di speculare un po’, perche il video che ha effettivamente innescato questa discussione riguardava esplicitamente la previsione del fatturato. Non era una previsione della domanda in senso stretto.
Joannes Vermorel: Si.
Conor Doherty: E ovviamente, quando entriamo nel decision-making in un contesto supply chain, questa e un’azienda supply chain, questo e un canale supply chain. La domanda sarebbe una parte molto importante di quel processo di previsione. Quando arriviamo alla differenza tra previsione e pianificazione, o a cio che chiameremmo prendere decisioni, sono curioso di sapere come vedi, e puoi speculare, Fable o prodotti simili coinvolti nel processo decisionale in supply chain.
Per esempio, se sei direttore supply chain, vuoi certo sapere se l’azienda fara buoni ricavi, se sara un anno redditizio. Ma in un giorno qualsiasi, se hai 10.000 prodotti e 10 ubicazioni, ci sono moltissime combinazioni SKU-ubicazione da considerare, e poi devi prendere decisioni con quelle informazioni. Quindi, rispetto a questa esperienza vissuta e a questi problemi decisionali, vedi strumenti come Fable, non dico Fable nello specifico ma prodotti LLM di quel tipo, aiutare in queste situazioni?
Joannes Vermorel: Si, assolutamente. Anche in Lokad abbiamo iniziato da piu di un anno a usare questi strumenti LLM come strumenti di produttivita. Ormai possono praticamente sostituire un data analyst junior, questo e del tutto chiaro. Questi grandi modelli, quando si tratta di matematica avanzata o statistica avanzata, sono gia completamente sovrumani su alcuni aspetti del lavoro, e lo sono da un po’. Quando dico da un po’, intendo circa un anno.
Conor Doherty: D’accordo. Non cosi tanto, considerando che le aziende non si muovono in cicli di un anno.
Joannes Vermorel: Si, ma non e freschissimo e non e legato all’ultima release di Fable.
Conor Doherty: D’accordo.
Joannes Vermorel: E cosi da piu di un anno.
Conor Doherty: D’accordo.
Joannes Vermorel: E penso che cio che sia cambiato riguarda tutte le vanity metrics che prima occupavano persone nelle aziende. Il CFO vuole tonnellate di vanity metrics. Il CEO vuole tonnellate di vanity metrics, e ogni direttore ha le sue metriche preferite da monitorare. Nelle aziende classiche, si finisce con una divisione business intelligence che impiega potenzialmente decine di persone. Quando menziono un’azienda, immagino una societa nordamericana da circa un miliardo di dollari di ricavi annui.
Con un miliardo di dollari di ricavi annui, bam, avete 10-20 persone che fanno essenzialmente business intelligence e costruiscono report richiesti dai vari direttori. Di solito questi report sono molto transitori: li vogliono una volta, o forse li richiederanno l’anno successivo. Questo e il tipo di cose che gli agenti automatizzeranno completamente. Nella supply chain, gli agenti possono offrire un enorme aumento di produttivita nelle mani giuste. Se date un agente a un supply chain scientist molto capace di Lokad, queste persone possono fare grandi cose con quegli agenti.
Perche i supply chain scientist sono gia nella mentalita per cui costruiamo, e questa e la mentalita da piu di un decennio, un decennio e mezzo in realta, una ricetta numerica che affronta il problema end to end. Ora, con un agente di coding, posso semplicemente farlo molto piu velocemente, ed e fantastico. E una vittoria enorme. Funziona. Se volete applicare la stessa idea in un’organizzazione dove le decisioni supply chain sono prese manualmente, allora il LLM aiuta appena.
Torniamo a cose discusse in episodi precedenti. I LLM sono abbastanza lenti quando si tratta di rivedere grandi quantita di cose. Il LLM puo essere sovrumano quando si tratta di scrivere lo script che fa la vostra previsione economica, che costruisce la vostra ricetta numerica e genera tutte le decisioni senza supervisione. Si, assolutamente. Ma se volete che i LLM vi accompagnino nel vostro modo tradizionale di fare supply chain, cioe andare riga per riga su un lungo foglio di calcolo per aggiustare i minimi e massimi delle posizioni di inventario, non si va da nessuna parte.
Non si va da nessuna parte. Se volete che il LLM sia utile, dovete abbracciare il paradigma di un decision-making senza supervisione, in cui le decisioni sono guidate da una ricetta numerica che non e un LLM, ma tipicamente software classico, salvo che questo software classico e ora scritto in parte con un agente di coding.
Conor Doherty: D’accordo. Voglio restringere la domanda, perche credo tu abbia risposto a molte delle cose che chiedevo, ma voglio essere chiarissimo per chi porra essenzialmente questa versione della domanda. Usero numeri molto tondi per renderla semplice. Hai fatto l’esempio di un’azienda nordamericana con, diciamo, cento milioni di ricavi all’anno.
Un miliardo, scusa, un miliardo, con i grandi. Lavoriamo con i grandi. Quindi, un miliardo. Diciamo che quell’azienda usa Fable un giorno e le viene detto: “L’anno prossimo farete 1,1 miliardi di ricavi. Questa e la nostra previsione del fatturato.” Supponiamo che l’azienda abbia 10.000 SKU e 10 ubicazioni. Sono 100.000 combinazioni SKU-ubicazione.
Sapere che potrei fare 1,1 miliardi di ricavi l’anno prossimo e un’informazione. E certamente piacevole. E il 10% in piu rispetto all’anno scorso. Bene.
Pero, dove mando le unita che ho oggi? Mando questa a…
Joannes Vermorel: Si, al negozio di New Orleans. E quello che dicevo sulle vanity metrics. Ed e il problema delle previsioni nude: le previsioni nude sono inutili, perche non possono essere usate. Se si affronta il problema in modo sbagliato, con il paradigma classico della pianificazione in cui si dice “conosco il futuro e poi orchestri”, allora si, puo essere usato.
Ma questo paradigma e rotto. E rotto perche il numero, quando lo assumi, non lo tratti come semplicemente approssimativo. Dici: conosco il futuro e ho quasi 0% di errore. Ma sai che c’e errore.
Quindi non funziona. Se proietti una crescita del 10%, va bene, ma non e un’informazione rilevante. Non si propaga in decisioni. Non posso farle fare qualcosa che non puo fare, e non e nemmeno al giusto livello di aggregazione, perche le tue decisioni vivono su scala giornaliera e alla granularita dello SKU. La tua previsione macro e quindi irrilevante. Ecco perche parlo di vanity metrics.
Sono per i direttori. Servono alla comprensione umana di alto livello, e va bene. Va benissimo, e gli agenti possono farlo. Boom. Poi c’e l’automazione reale delle decisioni supply chain, le migliaia, decine di migliaia, potenzialmente milioni di allocazioni quotidiane di risorse.
Questo richiede un altro pezzo di software, quello che in Lokad chiamiamo ricette numeriche, perche e un mix di algoritmi di machine learning, algoritmi di ottimizzazione, crunching dei dati per preparare i dati, ecc. Il LLM puo aiutarvi a comporre queste ricette numeriche, nessun problema. Poi queste ricette numeriche gireranno indipendentemente dal LLM, nessun problema. Ma affinche funzioni, dovete affrontare il problema dalla prospettiva in cui le decisioni supply chain, le allocazioni di risorse, sono guidate da decisioni senza supervisione che sono conseguenza di una ricetta numerica scritta. Questo e tutto cio che sto dicendo.
Non so se chiarisca. Il paradigma che ho appena descritto con la ricetta numerica e incompatibile con il paradigma classico secondo cui conosco il futuro e posso semplicemente orchestrare l’allocazione delle risorse. Questi due paradigmi non sono compatibili. Se ne puo scegliere solo uno.
Conor Doherty: Credo che la confusione possa nascere dal tuo uso del verbo “usare”. Hai detto che una previsione, una previsione nuda, non si puo usare. Qualcuno che lo sente potrebbe pensare: ma anche noi usiamo previsioni probabilistiche, per esempio; ovviamente usiamo quell’informazione al servizio di qualcos’altro. Quindi chiarisci cosa intendi quando dici che non si puo usare questa informazione.
Joannes Vermorel: Ogni volta che la gente menziona la previsione, implicitamente si tratta di una previsione di serie temporali, relativamente aggregata. Sempre. Ci sono moltissime assunzioni. Sara una serie temporale equidistante: previsione per giorno, per settimana, per mese. In teoria si potrebbero considerare previsioni di serie temporali con tempo non equidistante. Non ho mai visto nessuno usarlo in pratica.
Quindi, quando usiamo il termine previsione, arriva con assunzioni matematiche estremamente strette, proprio come quando si dice safety stock, significa distribuzione normale. Si, un matematico dira che in teoria si puo avere un safety stock che non segue una distribuzione normale. Si, salvo che il 99% del software di mercato, quando dice safety stock, intende una distribuzione normale.
Uso quindi il termine nel modo in cui e generalmente compreso. Quando dico previsione e dico che la previsione nuda e un anti-pattern, parliamo di previsione di serie temporali equidistanti. E sara a un livello di aggregazione in cui si guardano serie temporali non troppo sparse.
Quando le persone pensano a una serie temporale, immaginano qualcosa che assomiglia a una curva. Ma se siete al livello dello SKU, quello che avete e soprattutto zeri e occasionalmente un uno. Se guardate la serie temporale di uno SKU su un anno, e per il 90% zeri e a volte degli uno che rappresentano il fatto che avete servito o venduto un’unita. Non e assolutamente cio che le persone hanno in mente quando pensano a una serie temporale. Nel video di codice che hanno mostrato per la loro previsione, avevano una serie temporale molto bella, liscia e iper-aggregata.
Ancora una volta, e esattamente cio che la gente ha in mente, non la situazione super disaggregata che si affronta in supply chain alle granularita che contano per la decisione di allocazione delle risorse. Quindi, quando volete fare predizioni, uso apposta questo termine, diverso da previsioni, alla granularita che conta per le vostre decisioni, allora questo strumento matematico e cosi radicalmente diverso dalla previsione di serie temporali, da cio che la gente chiama effettivamente previsione, che e meglio chiamarlo con un altro nome, perche queste cose hanno quasi nulla in comune.
Conor Doherty: D’accordo. Quando parliamo di decisioni supply chain, ho scritto una breve lista di quelle che credo parlino alla grande maggioranza delle persone in supply chain. Parliamo di cosa acquistare, da quale fornitore acquistare, quando ordinare, dove mettere lo stock, cosa produrre, cosa accelerare, cosa scontare. Potremmo continuare, ma queste sono solo…
Joannes Vermorel: Si, potremmo continuare.
Conor Doherty: Sono solo sette, giusto? La vera domanda e…
Joannes Vermorel: E a quale prezzo.
Conor Doherty: E a quale prezzo, esatto. Dovrei tenere queste cose oggi o cambiare fornitore? Ci sono tutte queste classi diverse, e ci sono effetti di secondo, terzo, quarto ordine. Possiamo diventare molto meta, ma prendiamo solo questi sette esempi concreti che le persone possono costruirsi in testa. Con questi esempi in mente, dirmi che il mio fatturato l’anno prossimo sara di 1,1 miliardi e un’informazione, ma mi avvicina davvero alla capacita di rispondere granularmente a queste domande su base quotidiana? E se la risposta e no, perche no? Perche guardando quel video potrei avere quell’impressione.
E non me la prendo con Anthropic. Lo prendo solo come esempio, mi e stato presentato: cosa dice questo su aziende come Lokad? Beh, noi non vendiamo informazioni isolate del tipo “ecco il tuo fatturato per l’anno prossimo”. Vendiamo essenzialmente risposte a quelle domande.
Joannes Vermorel: Si. Il punto qui e che l’intuizione di molte persone sulle statistiche ad alta dimensionalita e semplicemente sbagliata. Prendiamo un’immagine. Pensate a un film come a una serie di immagini.
Immaginate di avere un frame e di voler prevedere quali saranno i pixel del frame successivo. Il fatturato dell’anno prossimo e semplicemente il colore medio della vostra immagine. Il vostro colore medio sara qualcosa come una sfumatura di grigio. E la media su tutta l’immagine.
Conor Doherty: Si.
Joannes Vermorel: Ora prevedete la sfumatura di grigio che sara il colore medio dell’intero frame successivo. Questa e la vostra previsione di fatturato. Questo vi aiuta a prevedere i pixel, pixel per pixel, dell’immagine successiva?
Per niente. Perche? Perche se aggregate tutto, se collassate tutta l’immagine in un colore medio…
Conor Doherty: Si.
Joannes Vermorel: Avete perso l’immagine. Non vedete piu nulla. Quindi, per proiettare come sara il frame successivo, dovreste ripartire dal colore medio? Certamente no.
Volete ripartire dall’informazione piu granulare, cioe i pixel stessi. E l’idea che si possa avere una previsione media molto accurata per il frame successivo, in termini di colore medio, si. Perche? Perche il colore medio da un frame all’altro e piu o meno lo stesso.
Finche non cambiate cio che state guardando, sara praticamente lo stesso colore medio. Anche se da un frame all’altro molte cose cambiano, se fate la media di tutta l’immagine e quasi la stessa da frame a frame, salvo tagli o cambi di prospettiva. Quindi, quando la gente pensa alla previsione del fatturato, si, si puo fare. Si puo avere una previsione relativamente accurata? Forse, perche e iper-aggregata. Ma questa previsione iper-aggregata sara utile quando tornate al livello super disaggregato, che sarebbe l’equivalente dei pixel nella nostra immagine? La risposta e no.
Ancora una volta, per capire perche, pensate al passaggio da un frame al successivo in un’immagine. Chiedetevi se la logica per prevedere l’immagine successiva dovrebbe passare dall’idea di collassare tutto nel colore medio. La risposta e no. Voglio formulare questa domanda in modo molto concreto.
Immaginate di avere un abbonamento commerciale a qualunque strumento IA disponibile sul mercato. Non sto prendendo di mira nessuno. Sono in quell’azienda da un miliardo di fatturato, ho un abbonamento a uno strumento IA prontamente disponibile, e dico: “Ecco l’accesso.” Creo una API, gli do accesso al mio ERP, a tutti i miei dati transazionali storici, e dico: “Voglio sapere dove mandare tutte queste unita domani. Anzi, devo emettere un ordine d’acquisto domani. Dimmi cosa dovrei comprare e in quali quantita. Puoi usare qualsiasi modello di previsione. Sto semplificando molto la domanda, ma puoi usare qualsiasi paradigma di previsione tu voglia. Dammi semplicemente un ordine d’acquisto ottimizzato.”
Funzionerebbe? Mi rendo conto che e una domanda semplice, ma e il modo in cui molte persone considerano la cosa. Non dico che sia sbagliato, ma vogliono sapere quale beneficio ottengono da questa tecnologia.
Joannes Vermorel: Al momento sospetto che non funzionerebbe, a meno che non si guidi il modello verso decisioni sensate. Ci sono troppe cose che questi LLM, pur essendo estremamente bravi, non sanno. Non sono pazienti. Bisogna guidare il modello. Per esempio, il LLM non puo indovinare che avete un CRM in produzione da sette anni finche non glielo dite.
Se dite “tutti i miei dati sono nell’ERP”, ma in realta una grossa parte dei dati e nel CRM e non avete mai detto al LLM che dovrebbe guardare anche il CRM, allora non lo sa. Potete essere molto bravi nel prompting. Potete entrare in modalita inversa e dire: “Voglio fare questo. Fammi tutte le domande a cui vuoi risposta. Faro del mio meglio”, e poi lasciare che l’agente prenda il processo in mano. Puo funzionare in una certa misura.
La mia esperienza e che, anche con le ultime release come Astra di OpenAI, che e quasi una classe a parte, serve comunque una guida di alto livello. Ma e buono. E penso che, se volete ottenere buoni risultati, quello che dovreste chiedere a uno strumento come Astra sarebbe: “Aiutaci a replicare quello che fa Lokad.” Per setup piccoli, sospetto che potrebbe portarvi abbastanza lontano. Il problema, ancora una volta, e la manutenibilita e l’auditabilita.
E una preoccupazione chiave. Se oggi chiedete a un agente molto intelligente semplicemente: “Replica Lokad per me”, in una certa misura potrebbe riuscirci. Forse non per gestire terabyte di dati, perche questo crea molte complicazioni. Ma assumendo che i vostri dati entrino comodamente in una workstation potente su cui gira l’agente di coding, potreste probabilmente andare abbastanza lontano. La sfida sara gestire l’intelligenza oscura.
Questa e una sfida in Lokad. Ci lavoriamo da un decennio e mezzo. Il problema esisteva gia prima degli LLM. Come si fa ad assicurarsi che la ricetta numerica resti sotto controllo, che si capisca cosa sta succedendo? Tra l’altro, questo problema puo esistere anche con gli esseri umani: un collega fa qualcosa di estremamente sofisticato e complicato, poi se ne va, e nessuno ha piu idea di perche funzioni o come funzioni. E un problema molto reale con quella che chiamerei intelligenza oscura.
Quando vibe-codate qualcosa di molto sofisticato, potreste faticare molto a mantenerlo nel tempo. Il LLM stesso, quando rivede quel codice, perche bisogna pensare che i LLM sono in qualche modo stateless, ogni volta vedra il codebase come se fosse la prima volta. La volta successiva che l’agente rivede il codebase, potrebbe perdersi e chiedersi: perche e stato fatto cosi? Non lo so.
Con il livello di intelligenza agentica che abbiamo oggi, credo non sia ragionevole non avere supervisione umana di alto livello per processi mission critical. Questo e il mio punto. Potete fare yolo e dire: “Sai cosa? Mi fidero dell’agente.” Vibe-codera tutto, ma sospetto che sia una ricetta per il disastro, semplicemente perche non siamo ancora a quel punto in termini di intelligenza agentica. E le persone forse non si rendono conto che, quando si usano agenti molto intelligenti, almeno meta delle sciocchezze che fanno dipende da voi.
Dipende dal fatto che state suggerendo qualcosa di stupido. Ancora una volta, l’agente e molto docile. Fara le cose stupide, ed e un grosso problema. Gli agenti non hanno ancora la capacita di respingere richieste umane stupide. Non hanno una modalita per questo.
Forse i modelli futuri avranno una modalita di pushback, ma oggi e ancora molto debole. Questo significa che siete a una cattiva richiesta dal fare qualcosa di tragicamente dannoso per il vostro codebase.
Conor Doherty: Parlando di supervisione di alto livello, mi viene in mente il fatto che il direttore commerciale di Lokad, Fabian Hoehner, e io faremo una demo live dell’account aerospace di Lokad. In preparazione, ne parlavamo e lui ha menzionato che, come in qualunque altra verticale in cui Lokad opera, le decisioni sono generate automaticamente, ma a causa del valore di ogni decisione individuale nell’aerospace, vengono comunque controllate. Per esempio, se si tratta di comprare un’unita che costa 100.000 dollari, probabilmente verra controllata, non perche non si fidi del sistema, ma perche il costo dell’errore e molto alto. In altre verticali, comprare un’unita puo costare solo pochi centesimi, a seconda degli scaglioni di prezzo.
Quindi, quando parliamo di IA che sostanzialmente commoditizza molte di queste attivita, vedi alcune verticali come piu facilmente assorbibili da questo tipo di tecnologia rispetto ad altre?
Joannes Vermorel: Ovviamente ci sono verticali molto orientate all’ingegneria: oil and gas, aviazione, elettronica di consumo. Sospetto anche l’e-commerce. Queste aziende saranno probabilmente in prima linea nell’automatizzare tutto. Poi verranno le industrie in cui e semplicemente molto tedioso, perche c’e troppa roba, come il fast fashion.
Conor Doherty: Era proprio l’esempio che avevo in mente.
Joannes Vermorel: Si, arrivera. Le persone forse sono meno orientate alla tecnologia, ma la complessita rende queste tecnologie estremamente attraenti, perche altrimenti e estremamente tedioso. E alla fine probabilmente arriveremo, come accade molto spesso, alle aziende FMCG, che restano indietro perche trattano relativamente pochi prodotti con volumi molto alti.
Quindi anche se la produttivita non e buona, l’impatto non e cosi forte come in altre verticali.
Conor Doherty: Ti ho chiesto prima, nel framing della discussione, quale fosse la conseguenza potenziale di questo tipo di tecnologia sui fornitori del settore. Supponiamo, per amor di discussione, che la direzione sia reale: questa tecnologia diventera sempre migliore, come presumibilmente accadra. Questo significa, se prendiamo il video di Fable come esempio, che il sorting e cleaning dei dati diventano piu rapidi, piu veloci e piu economici, la previsione diventa piu rapida, piu veloce e piu economica, la generazione di report e il backtesting avvengono in pochi secondi, automaticamente, con un clic.
Bene. Supponiamo che tutto questo sia vero e diventi molto buono. Cosa diventa meno prezioso in questo spazio, in termini di offerta dei fornitori, e cosa diventa piu prezioso?
Joannes Vermorel: La mia posizione e che il 90% di quei fornitori andra in bancarotta.
Conor Doherty: D’accordo.
Joannes Vermorel: Ma non per questo. Andranno in bancarotta perche i loro stessi clienti andranno in bancarotta.
Conor Doherty: Molto diverso.
Joannes Vermorel: Il modo in cui la vedo, e ne discuto da qualche anno, e che soprattutto con questi agenti oltre il 90% del lavoro impiegatizio evaporera. E potrebbe essere persino piu di cosi. Qualche anno fa predicevo il 90%. Ora siamo oltre. Francamente, se guardiamo cio che le persone fanno in media, probabilmente oltre il 90% del lavoro white-collar puo essere automatizzato completamente.
Questo significa che alcune aziende saliranno a bordo, e molte non lo faranno. Se guardate la storia dell’innovazione, potreste pensare che l’elettricita fosse ovvia. Ma alla fine del XIX secolo, la risposta fu che la maggior parte delle aziende ando in bancarotta e non adotto l’elettricita. Lo stesso con la rivoluzione successiva, l’automobile. La maggior parte delle aziende non adotto l’automobile e falli, eccetera.
Il ciclo si e ripetuto piu e piu volte con grandi cambiamenti tecnologici. La realta e che la maggior parte delle aziende non riesce mai a fare il salto e scompare. Penso che, nella mia vita, l’IA sara probabilmente il piu grande di questi salti. Posso immaginare un salto tecnologico ancora piu significativo, ma francamente questo sembra assolutamente enorme, perche nelle economie moderne come Francia o Stati Uniti, la forza lavoro white-collar e l'80% della forza lavoro. E stiamo parlando di automatizzarne il 90%.
L’impatto sara quindi assolutamente immenso. Il modo in cui la vedo e che poche aziende adotteranno davvero queste cose, le abbracceranno, e spingeranno tutte le altre alla bancarotta. E una rivoluzione schumpeteriana, accadra. Non sto predicendo disoccupazione di massa, perche nasceranno altre aziende. Il mercato lo risolvera in modo abbastanza pulito, come fa: molte aziende falliscono, le persone restano disoccupate per qualche mese, poi tornano in un’altra azienda, perche le aziende vincenti assumeranno ovunque per altri lavori.
Tornando ai fornitori, se torniamo all’inizio di questa discussione, la maggior parte dei fornitori nel campo del software enterprise per la supply chain era gia obsoleta vent’anni fa. Quindi una rivoluzione tecnologica in piu cambia qualcosa? No. Se siete gia obsoleti da vent’anni, il fatto di diventare obsoleti da trent’anni, finche i clienti sono disposti a pagare per roba obsoleta…
Leggo ancora nelle notizie che per i systems of record, cioe cose come SAP, che sono le piu facili da vibe-codare, funziona magnificamente. Funziona magnificamente da anni. Dico che c’e stata una svolta agentica un anno fa, ma anche prima, il software CRUD per systems of record era gia diventato banale da almeno due o tre anni. Quindi se avete un’azienda che spende ancora piu di un milione di dollari l’anno, indipendentemente dalla dimensione, per un system of record, e una spesa sciocca.
E una perdita pura. State semplicemente spendendo soldi in qualcosa di frivolo. Nessun system of record vale piu di un milione all’anno. Se avete davvero tanti dati, possiamo discutere i costi hardware, ma anche con un milione all’anno per i record, vi avvicinate alla capacita di gestire tutti i record transazionali di Walmart con quel budget.
Questo solleva davvero la domanda: di che tipo di record stiamo parlando? Se dite di aver bisogno di un budget superiore a quello necessario per tenere i dati di Walmart, rappresentati in modo intelligente, non super gonfio, allora c’e qualcosa che non va. Gli agenti di coding sono molto bravi a ottimizzare il codice. Potrebbero farlo.
Quindi, tornando al quadro generale, la mia posizione e che i fornitori che vendono prodotti obsoleti continueranno a vendere i loro prodotti obsoleti, come hanno fatto negli ultimi vent’anni. Questa farsa finira solo quando i loro stessi clienti falliranno, perche alla fine il mercato non e un grande educatore, e solo un filtro. Le aziende che operano su paradigmi obsoleti avranno come conseguenza, invece di una riduzione del 90% della forza lavoro per la maggior parte dei lavori, una riduzione del 5%. Avranno solo un miglioramento cosmetico.
Ma non e questo che si dovrebbe cercare. Oggi, con gli strumenti disponibili, un tipico progetto IA, quando si affronta una funzione aziendale, dovrebbe stabilire come baseline almeno, non so, dimezzare l’headcount. Se portate avanti un progetto in cui distribuite IA e dite che, quando avete finito, l’headcount della funzione che volete aumentare con l’IA non e stato diviso per due, e un fallimento abietto. Due non e davvero ambizioso oggi per questo tipo di automazione.
Piu ragionevole sarebbe 75%, e l’obiettivo a lungo termine, diciamo tra tre e cinque anni, sarebbe 90%. Si, taglio dell’headcount. Ancora una volta, parliamo di scegliere selettivamente una funzione dove l’IA puo essere usata. E per molte cose c’e un modo di usarla. Dimezzare l’headcount non e nemmeno davvero ambizioso. Il problema oggi e che molte aziende non vedono assolutamente questi risultati, perche il modo in cui affrontano l’IA e l’automazione e estremamente obsoleto in termini di paradigma.
Conor Doherty: Stavamo parlando di fornitori, e questa conversazione e nata da un amico del canale che ci ha inviato quel video per avere la nostra risposta. C’era una domanda che voleva che ti facessi, e chiudero con quella. Immagina che domani un fornitore entri nell’ufficio del mio capo e dica: “La nostra IA pianifica autonomamente la vostra supply chain.” Cosa dovrei chiedergli di dimostrare?
Joannes Vermorel: La domanda da fare e: come? Bisogna capire come, cosa succede sotto il cofano. Per contesto, e un’azienda wholesale. Bisogna capire cosa succede sotto il cofano. “Guidatemi passo passo. Voglio capire.” E poi, possiamo procedere su un percorso in cui vi impegnate effettivamente a consegnare i risparmi di headcount di cui abbiamo discusso insieme?
E al contrario ci sono red flag. Se il fornitore fattura per seat, significa che e nel suo interesse minimizzare la produttivita, assicurarsi che ci siano quante piu persone possibili, e mantenere headcount e account.
Conor Doherty: Si.
Joannes Vermorel: Esattamente. Un altro red flag sarebbe se il fornitore dicesse: “Aumenteremo cio che fanno le vostre persone.” Red flag assoluto. Non e cosi che funzionera. Non si puo ottenere una riduzione del 90% dell’headcount dicendo che si aumenta la produttivita delle persone. Bisogna ripensare il lavoro.
Ecco perche dico: spiegatemi come ci arrivate. Idealmente, la prospettiva a cinque anni e 90%. Sarebbe una buona baseline: 90% di riduzione dell’headcount. Siamo 20 persone; tra cinque anni saremo due. Ditemi esattamente come funziona, cosa fa il vostro sistema, e perche siete sicuri che con due persone su venti saremo in grado di operare.
Conor Doherty: Quindi un’altra persona nel tuo esempio. Si.
Joannes Vermorel: Si. E in genere i fornitori di software enterprise spingono tecnologie cosi obsolete che, quando chiedete cosa succede sotto il cofano, molto rapidamente vi rendete conto che e estremamente obsoleto. E oggi la magia di ChatGPT e che, anche se ci sono termini tecnici che non capite, potete semplicemente registrare la conversazione e chiedere a ChatGPT una valutazione. ChatGPT vi dara una valutazione ragionevolmente solida. Chiedetegli solo di adottare una posizione adversarial, altrimenti sara troppo gentile nelle critiche.
Potete impostare la premessa: “Caro ChatGPT, questo fornitore probabilmente sta gonfiando le sue affermazioni e abbellendo la situazione. Sii spietato e critica cio che mi viene presentato.” Otterrete una critica decente, ma dovete guardare cosa succede sotto il cofano.
Conor Doherty: Per essere onesti, e per fare eco a questo pensiero, non e mai stato cosi semplice ottenere ricerche di mercato abbastanza solide su quasi qualunque fornitore.
Joannes Vermorel: Si.
Conor Doherty: E non serve nemmeno il modello piu potente. Non siamo sponsorizzati da ChatGPT, scusa, da OpenAI, ma non devi nemmeno usare il modello piu sofisticato di ChatGPT. Ecco un fornitore, ecco il sito web, valutalo, dammi un report di mercato, confrontalo con i peer.
Joannes Vermorel: Ma attenzione, bisogna chiedere una posizione adversarial, perche altrimenti ChatGPT e troppo fiducioso. Bisogna dire: non fidarti dei case studies, non fidarti di nessuna affermazione del fornitore.
Conor Doherty: Esattamente.
Joannes Vermorel: Assicurati di fondare la tua valutazione sui fatti. Com’e la tecnologia? Assumi il peggio. Ogni volta che una tecnologia non e descritta, assumi che sia una media mobile. Ogni volta che qualcosa…
Conor Doherty: No, e software enterprise. E funzionale.
Joannes Vermorel: E funzionale. Si. Il software enterprise funziona cosi. Se il fornitore non da i dettagli, non c’e una ricetta magica.
Non c’e un ingrediente magico, come una tecnologia iper avanzata. No, no. “Questa e un’IA speciale.” No, no. Assumi il peggio. Per esempio, se non c’e documentazione tecnica, bisogna assumere che sia un incubo e che sia per questo che non pubblicano la documentazione tecnica: il prodotto e un grande mucchio di fango, e il fornitore si vergogna cosi tanto da non volerla pubblicare.
Quindi bisogna dire a ChatGPT di adottare questa mentalita adversarial. Fonda la tua valutazione su cio che puoi osservare. Assicurati che sia fattuale. Sii estremamente scettico verso qualsiasi affermazione, specialmente i case studies. Assumi che tutti i case studies siano falsificati, perche spesso lo saranno, o almeno ragiona dai primi principi.
Ragionare dai primi principi significa: il fornitore dice che fa tutto in un database SQL. E davvero compatibile con tecnologie avanzate di machine learning? Chiedete a ChatGPT di ragionare dai primi principi. Guardate cosa fanno, e da li estrapolate se quello che dicono e davvero credibile o no, e se permettera di raggiungere questa riduzione del 90% dell’headcount tra cinque anni, che dovrebbe essere l’orizzonte.
Conor Doherty: Quando pubblicheremo questa registrazione, faro fare a ChatGPT un riassunto di quel diagnostico e lo posteremo con questa clip per promuovere il podcast, perche penso che sia davvero funzionale ma anche molto raggiungibile. Non stai dicendo che bisogna passare al setaccio petabyte di dati o diventare esperti di forecasting. C’e stato un periodo in cui si poteva dire: si, bisogna avere un maggiore grado di mechanical sympathy, cosa che so diremo sempre essere buona, ed e sempre buona, ma realisticamente la maggior parte delle persone non lo fara. Pero c’e pochissima scusa per dire: non ho letteralmente 60 secondi per rivedere cio su cui sto per spendere forse piu di un milione di dollari.
E davvero un po’ troppo.
Joannes Vermorel: Bisogna solo tenere presente che, di default, ed e per questo che dicevo che bisogna promptare tutti i modelli cosi, tutti questi LLM sono essenzialmente fine-tuned per essere gentili, docili, morbidi e non antagonisti. Come conseguenza di questo comportamento di default, magari perche state chiedendo qualcosa sul vostro collega e il collega e li a guardare, non cercano di presentare nulla in cattiva luce di default.
Ma se li spingete con un prompt molto specifico, nessun problema. Il modello puo fornire una critica dura di qualunque cosa. Pero bisogna aiutare e guidare un po’ il modello, perche il fine-tuning di default, ed e lo stesso per praticamente tutti i modelli per quanto ne so, e essere relativamente gentile, positivo e benevolo sulle cose.
Conor Doherty: In generale, lanci questa sfida con, immagino, un enorme grado di fiducia che Lokad non fallira questo standard.
Joannes Vermorel: Si, e una buona posizione. Sto solo sottolineando che, comparativamente, ho gia sottoposto Lokad a questo tipo di stress test in passato. Non ho testato gli ultimi modelli, Astra di OpenAI o gli ultimi di Anthropic, ma Lokad se la cavava decentemente in questo stress test.
Conor Doherty: D’accordo. Non ho altre domande, Joannes. Se qualcuno mi invia il feedback ottenuto da ChatGPT, te lo inoltrero direttamente per un commento, e lo affronteremo in un’altra occasione. Come sempre, un piacere. E a voi che ci guardate, grazie mille.
Se volete mettervi in contatto con Joannes e me, se volete condividere con noi il vostro feedback sugli LLM.
