Ancora sul rapporto tra software e AI
Sul perchè oggi i sistemi applicativi (a cominciare dai SaaS) e l'AI sono complementari. Oggi, ovviamente; domani non lo sappiamo. Ma una analisi seria parte dai fatti, non dai sogni.
I grandi sistemi applicativi (oggi spesso erogati in cloud, come SaaS - Software as a Service) sono alla base di tutti i servizi che usiamo, sia come imprese che come singoli. È possibile che questi sistemi vengano sostituiti nel prossimo futuro da sistemi di AI?
Per rispondere a questa domanda bisogna affrontare molte questioni: la rappresentazione della conoscenza applicativa, la gestione dell’interazione con gli utenti, la memorizzazione e la gestione delle informazioni, nonché la gestione dei processi che le generano e le aggiornano. E non basta sapere se i sistemi di AI possono fare “le stesse cose”. Bisogna anche capire se garantiscono le stesse proprietà (per esempio integrità e coerenza dei dati), prestazioni sufficienti e costi competitivi.
In questo post vorrei solo accennare ad alcuni dei temi tecnologici più critici, mettendo da parte, per un attimo, tutti gli altri.
Il mio intento è far comprendere anche ai non tecnici la complessità e la delicatezza dei temi che abbiamo di fronte.
Quindi, i tecnici perdonino qualche semplificazione.
Un po’ di storia
Negli anni ‘60 e ‘70, ricercatori come Jim Gray e Leslie Lamport hanno studiato i fondamenti teorici dell’elaborazione distribuita delle informazioni. Per capirci, hanno studiato come gestire l’accesso concorrente ad una stessa informazione. Se, per esempio, due diverse operazioni richiedono di prelevare fondi da un conto corrente, ciascuna di esse deve prima verificare il saldo per essere certa della disponibilità dei fondi e, se disponibili, procedere al prelievo. Queste due operazioni (controllo e prelievo) devono essere eseguite in modo atomico: o tutto o niente. Se due prelievi si sovrappongono in modo incorretto (tutti e due controllano, ricevono una risposta positiva e poi procedono con il prelievo), può accadere che il saldo venga portato sotto zero. Questa tematica definisce il two-phase commit e il modello ACID (Atomicity, Consistency, Isolation e Durability), principi fondamentali di tutti i sistemi OLTP. OLTP sta per On Line Transaction Processing e sono i processi di aggiornamento e gestione dei dati dei sistemi che usiamo quotidianamente (dal banking alla gestione della produzione allo shopping online).
Queste caratteristiche devono essere garantite con elevata affidabilità, a costi contenuti e con volumi enormi. Per cui, non basta dire che “si può fare la stessa cosa con l’AI”. Sarebbe come chiedersi se si possa andare a fare la spesa al supermercato con un carro armato o trainare un aratro in un campo di grano con una Ferrari. Magari si può fare, ma ha senso?
Tre domande a Perplexity Pro
Per capire quali sono gli snodi tecnici, ho fatto tre domande a Perplexity Pro:
Quali sono le strutture dati utilizzate dai LLM per costruire sistemi come Claude o ChatGPT?
Quali sono le differenze o similitudini strutturali rispetto ai sistemi di gestione di DB utilizzati nei sistemi transazionali?
Per transazioni business le prestazioni delle due tipologie di architetture sono confrontabili o esistono ancora differenze?
Benché da giovane studente del Politecnico lavorai per Syntax e Olivetti sullo sviluppo di un B-Tree (una tecnologia ancora oggi utilizzata per gestire i dati nei sistemi transazionali che utilizziamo quotidianamente), devo confessare che faccio fatica a comprendere tutti i dettagli tecnici che Perplexity Pro mi ha fornito in risposta alle prime due domande. Questo per dire che questi aspetti tecnologici e architetturali sono molto sofisticati e complessi. Fatico quindi a comprendere molte affermazioni categoriche e semplicistiche fatte sul tema.
Ma la risposta alla terza domanda, quella chiave, peraltro, mi pare comprensibile anche a non tecnici o a “vecchi” come me.
Eccola di seguito (ho inserito due linee orizzontali per identificarla). Le enfasi in bold sono di Perplexity Pro, non mie.
Inizio della risposta di Perplexity Pro.
Per transazioni business “classiche” (OLTP: ordini, pagamenti, anagrafiche, inventory…) le prestazioni di LLM e DB transazionali non sono confrontabili: i DB restano ordini di grandezza più veloci, efficienti e affidabili, mentre gli LLM hanno costi e latenze molto superiori e non offrono garanzie ACID.
Lato prestazioni pure (latenza, throughput, costo)
Studi che confrontano LLM usati per interrogare piccoli dataset transazionali mostrano che, anche per compiti di sola lettura, un LLM consuma molte più risorse ed energia rispetto a un motore SQL tradizionale.
Anche con modelli piccoli e quantizzati (es. Llama2 7B, Optimus‑7B) si ottengono tempi di risposta e consumi che “si avvicinano” a SQLite, ma non lo superano in efficienza; gli autori sconsigliano esplicitamente di sostituire i DB relazionali con LLM per le query operative.
I sistemi transazionali industriali OLTP sono ottimizzati da decenni per migliaia/milioni di transazioni al secondo con latenze di pochi millisecondi, spesso su hardware commodity; gli LLM necessitano di GPU costose, hanno tipicamente latenze nell’ordine delle centinaia di millisecondi o secondi e throughput espresso in token/s, non in TPS.
In pratica: per la stessa “transazione business” un DB fa un’operazione I/O + un po’ di CPU, un LLM esegue miliardi di operazioni floating‑point; i costi non sono comparabili.
Garanzie di correttezza e affidabilità
Un DB transazionale implementa ACID: atomicità, consistenza, isolamento, durabilità, journaling, recovery, locking/MVCC, ecc., essenziali per transazioni business affidabili.
Un LLM è un motore statistico: non garantisce correttezza strutturale (es. può “allucinare” risultati), non ha concetto di commit/rollback, non mantiene log di redo/undo e non offre isolamento tra operazioni concorrenti.
L’uso di LLM “come database in‑context” (encoding dei dati nel prompt e CRUD con testo) è stato testato sperimentalmente: la qualità e la robustezza restano nettamente inferiori a un RDBMS e non coprono i requisiti di un sistema transazionale reale.
Quindi, anche ignorando la performance, gli LLM non soddisfano i vincoli di sicurezza e coerenza tipici dei sistemi di business.
Dove ha senso usarli insieme
Lo scenario oggi realistico è ibrido, non sostitutivo:
LLM per interfaccia e logica “intelligente” (es. interpretare richieste in linguaggio naturale, generare SQL, validare o arricchire dati).
DB transazionale per persistenza, concorrenza, performance OLTP e integrità dei dati.
Lavori come “Can LLMs substitute SQL?” concludono che la soluzione pratica è usare LLM per rendere più accessibili i DB, non per rimpiazzarli come motore di transazione.
Regola pratica per un sistema business
Transazioni core (pagamenti, ordini, contabilità, logistica, anagrafiche): usare sempre DB OLTP (SQL o NoSQL secondo il caso); gli LLM possono al massimo generare/validare le query o orchestrare processi.
Funzioni cognitive (spiegazioni, riassunti, raccomandazioni, assistenti conversazionali): usare LLM + accesso al DB per i dati “di verità”, ma il commit dei dati deve passare da un motore transazionale classico.
In sintesi: per carichi transazionali di business, oggi un LLM è un ordine di grandezza peggiore in efficienza, costo e affidabilità rispetto a un DB OLTP, e il pattern architetturale corretto è LLM sopra al database, non al posto del database.
Fine della risposta di Perplexity Pro.
Peraltro, poiché non tutto è nuovo sotto il sole, questa differenza tra tecnologie classiche e AI riflette una distinzione che esiste da decenni tra OLTP e OLAP, cioè On Line Analytical Processing. OLTP gestisce le transazioni di aggiornamento e la gestione delle basi di dati. OLAP fa valutazioni ed elaborazioni statistiche o di analisi. Per dare un po’ di prospettiva, io imparai e applicai questi concetti nel 1995, quando con altri colleghi di Cefriel e Politecnico di Milano lavorammo sui sistemi digitali per la dichiarazione dei redditi.
Che poi in futuro possano nascere tecnologie che integrano tutte queste caratteristiche in un unico sistema è certamente possibile. Ma ciò appartiene alle possibilità che, ad oggi, ancora non conosciamo.
Conclusioni
Non è certo con qualche riga di testo, peraltro generata da uno di quei strumenti di cui tanto si parla, che si possono riassumere decenni di ricerca e sviluppo su questi temi. Ma è proprio per questo che mi sorprendo di tante affermazioni che circolano in questi giorni.
Per cui, “slow down, relax e stop talking nonsense.”