Home Fondamenti Storia dell'AI Reti Neurali Backpropagation Architetture Token Modelli AI Case Studies Tecniche RAG RAG Avanzato GraphRAG MCP Orchestrazione LangChain LangGraph Prompt Engineering Usare l'AI ChipsBot News

LLMs: Strumenti Inadeguati per le Previsioni

Computerwoche 13 ottobre 2026

La KI generativa aiuta le persone a scrivere più velocemente, a fare ricerche, a programmare o a valutare contenuti. Un enorme vantaggio, tuttavia con un problema grave: secondo uno studio di McKinsey, l'80% degli utenti di KI segnala una maggiore produttività personale, ma solo il 6% delle aziende afferma che la KI aumenta in modo significativo il proprio operativo guadagno. SAP crede di poter colmare questo divario con i Tabular Foundation Models (TFM). I modelli dovrebbero aiutare le aziende a riconoscere e gestire meglio rischi, domanda, guasti o sviluppi di liquidità in anticipo. Abbiamo chiesto a Philipp Herzig, Chief Technology Officer di SAP, di cosa si tratta esattamente questa tecnologia.

Dove gli LLMs raggiungono i loro limiti

Signor Herzig, da tre anni la KI generativa e i Large Language Models sono al centro dell'attenzione. L'intelligenza artificiale classica e il machine learning, sebbene ancora ampiamente utilizzati, sembrano quasi essere caduti nell'oblio. E ora arriva SAP con i Tabular Foundation Models? Come mai?

Philipp Herzig: Gli ultimi due, tre anni si sono naturalmente concentrati molto sui Large Language Models. Offrono possibilità straordinarie, non solo per l'elaborazione del linguaggio naturale, per cui sono stati originariamente sviluppati. Allo stesso tempo, però, per determinati compiti, per cui si dovrebbe piuttosto ricorrere al machine learning classico, rimangono inadeguati. Prendete, ad esempio, le previsioni per il cash flow, il credit scoring, la manutenzione predittiva o i ritardi nei pagamenti.

Quando si tratta di riconoscimento di pattern in serie temporali, classificazione o regressione, gli LLMs non sono lo strumento giusto. Per problemi più semplici, si potrebbe ancora ottenere qualcosa. Ma è al massimo inefficiente in termini di token, tentare ogni volta attraverso il linguaggio di effettuare una classificazione. In passato, la domanda sorgeva spesso: perché SAP non costruisce il suo Large Language Model? La nostra risposta era: questo non ha senso per noi. Il nostro core business sono i dati strutturati, che di solito si trovano in tabelle. Esattamente lì si trovano compiti come la classificazione, la regressione o le previsioni di serie temporali.

Cosa c'è dietro l'idea fondamentale?

Herzig: In pratica, vogliamo trasferire ciò che i Large Language Models hanno ottenuto per il linguaggio naturale ai dati tabellari. Invece di dover addestrare un modello per ogni caso d'uso, esiste un grande modello che può generalizzare su diverse attività. Può trattarsi di credit scoring in una banca, di trading finanziario o di previsioni mediche basate su marcatori proteici. Il principio è sempre lo stesso: do al modello dati storici in formato tabellare e può risolvere diverse attività predittive.

È proprio così che abbiamo iniziato. Il nostro modello RPT 1.6 lo abbiamo sviluppato negli ultimi tre anni, inizialmente come progetto di ricerca. Con l'acquisizione di Prior Labs, abbiamo ulteriormente rafforzato le nostre attività in questo settore, perché abbiamo visto che ci troviamo molto avanti a livello tecnologico.

Democratizzare le previsioni con i TFMs

Come funziona con i dati di training? Cosa è già pre-addestrato e qual è il ruolo dei dati reali delle aziende che utilizzano il modello?

Herzig: Abbiamo accesso a molti dati dei clienti, se i clienti ce ne danno l'autorizzazione. Non abbiamo però utilizzato questi dati per l'addestramento del modello. Per questo, abbiamo utilizzato dati tabellari generalmente disponibili e abbiamo lavorato molto con dati generati sinteticamente. I dati reali dei clienti li utilizziamo invece per la convalida. Questo è per noi il vero valore aggiunto: possiamo nel laboratorio prendere i dati di un cliente reale e verificare come si comporta il modello su di essi. Sebbene il modello non sia stato addestrato con questi dati, possiamo già testare quali risultati fornirebbe se lo utilizzassimo presso il cliente.

Come si comportano i TFMs in questo ambito?

Herzig: Abbiamo condotto molte validazioni interne. In particolare con dati aziendali da finanza, supply chain o HR, i modelli ottengono risultati molto buoni, perché sono ottimizzati anche per questi casi d'uso. E questo funziona senza che i dati reali dei clienti entrino nell'addestramento del Foundation Model.

La domanda chiave in questo caso è: come si comporta il Foundation Model rispetto alla migliore baseline di Narrow-AI? Lo confrontiamo cioè con un modello che un esperto di machine learning ha sviluppato e ottimizzato appositamente per questo singolo caso d'uso. Rispetto alle baselines di machine learning classico, vinciamo ormai quasi in tutti i casi. Anche rispetto a approcci AutoML molto potenti, ci troviamo circa nel 70-80% dei casi davanti.

La differenza fondamentale, però, è: questi modelli devono spesso essere addestrati per diverse ore per il rispettivo compito. Al nostro Foundation Model, invece, do solo poche migliaia di set di dati e posso iniziare direttamente con la previsione.

Reproducibilità invece di scatola nera

Nelle previsioni, si tratta della probabilità statistica, ma dal punto di vista della compliance è ancora più importante l'esplicabilità e la riproducibilità del risultato?

Herzig: Esatto. Se si inseriscono più volte lo stesso prompt negli LLM comuni, si possono ottenere - a seconda della temperatura - risposte diverse. Con i nostri modelli è diverso: se si inseriscono gli stessi campioni, si ottiene anche la stessa previsione e la stessa confidenza. Ancora più importante è la tracciabilità dei risultati, l'esplicabilità. È anche una delle innovazioni che abbiamo introdotto con RPT 1.6. Infine, si vuole sapere: ha senso questa previsione dal punto di vista dei contenuti? Perché il modello arriva a questo risultato?

Possiamo quindi mostrare da un lato quali colonne, ovvero caratteristiche della tabella hanno influenzato la previsione - ad esempio età, genere o altri attributi. Andiamo però oltre: oltre a "Explain by Feature" esiste anche "Explain by Example". Possiamo quindi mostrare quali altre righe, ovvero esempi del set di dati hanno contribuito alla previsione. Se, ad esempio, si tratta di una raccomandazione di prodotto, il cliente può comprendere che la previsione si basa tra l'altro sul fatto che clienti simili hanno acquistato questo prodotto. In questo modo, l'utente può valutare meglio se fidarsi o meno della previsione.

Per l'esplicazione in linguaggio naturale potrebbe essere utilizzata nuovamente la KI generativa?

Herzig: Assolutamente. Qui bisogna distinguere chiaramente i compiti. I Tabular Foundation Models non cambieranno il pattern di interazione con l'utente come Joule o ChatGPT e Claude. Per questo continueranno a essere utilizzati i Large Language Models. I TFMs sono piuttosto destinati ai compiti...

Leggi l'articolo originale →
← Torna alle news