L’impatto dell’AI generativa e dei Large Language Model (LLM) oggi è innegabile. Quasi ogni giorno vengono annunciati nuovi modelli linguistici o soluzioni innovative che combinano l’AI generativa per rivoluzionare flussi di lavoro critici, come il customer care o la produzione di asset digitali. In questa “corsa all’oro” della Gen-AI, i dati rimangono il cuore pulsante. Tuttavia, c’è una tipologia di dati che è rimasta quasi in disparte: i vecchi dati tabellari. Database SQL accumulati in decenni di sottoscrizioni, transazioni e ricerche di mercato che ora non hanno lo stesso fascino delle loro controparti non strutturate, come documenti, immagini, video e audio.
È importante ricordare come questi dati tabellari siano ancora alla base della sopravvivenza di molte aziende e contribuiscano a mantenerne florida la presenza e la competitività sul mercato.
Questo ci porta a chiedere: cosa può offrire l’AI generativa ai dati tabellari, invece di lasciarli in un angolo come “strumenti del passato”? Cosa succede quando l’AI generativa incontra le tabelle?
Indice degli argomenti:
Documenti vs. tabelle
A prima vista, l’AI generativa e i dati tabellari sembrano appartenere a due mondi diversi. Prendiamo i Large Language Model (LLM). Questi modelli linguistici sono addestrati su libri, articoli e post, con l’obiettivo di replicare pattern comunicativi. Per questo motivo, vengono spesso descritti come “versioni sotto steroidi del T9”. Il completatore di testo, non un Terminator. Dall’altro lato, abbiamo i database: enormi cataloghi che raccolgono informazioni personali degli utenti o registri di prodotti venduti. Dominio incontrastato del Machine learning tradizionale. Cruccio e delizia di analisti, consulenti e organi di regolamentazione. Tuttavia, basta cambiare leggermente prospettiva per intuire che i LLM possono spingere i dati tabellari verso nuovi orizzonti.
Proprio perché i LLM sanno replicare pattern comunicativi, hanno la capacità di emulare forme più o meno complesse di ragionamento critico. In che modo questo si può combinare con i dati tabellari? Chiunque abbia mai mantenuto un database o lo abbia utilizzato come fonte di dati per analisi, sa che spesso serve un notevole lavoro di revisione. Dati duplicati, informazioni scritte male o completamente assenti, per poi scoprire che l’informazione cercata è suddivisa in innumerevoli tabelle con campi che seguono nomenclature solo parzialmente conciliabili.
Ma, se i dati tabellari richiedono tanto sforzo, perché non utilizzare le capacità emergenti di ragionamento dei LLM per aumentarne la qualità e facilitarne l’accesso da parte di analisti e data scientist? Negli ultimi tempi, abbiamo approfondito questo quesito e in questo articolo presentiamo una sintesi di alcuni ambiti in cui i LLM hanno fatto la differenza, come ad esempio l’arricchimento o la validazione dei dati, e il caso di agenti con cui interagire in chat per effettuare complesse analisi sui dati tabellari. Prima però serve capire come far interagire questi dati strutturati con i LLM.
Preparare i dati tabellari per un LLM: dalla struttura al contesto
Per sfruttare i dati tabellari con un Large Language Model è fondamentale preparare questi in un formato che possa essere facilmente compreso e processato dal modello: i dati tabellari sono spesso organizzati in modo rigoroso, con righe e colonne che rappresentano rispettivamente entità e attributi. Tuttavia, per un LLM, una tabella in formato grezzo potrebbe risultare difficile da interpretare senza un contesto adeguato. Per avvicinare i dati tabellari a un LLM è quindi opportuno compiere alcuni passaggi.
- Tradurre delle tabelle in linguaggio naturale: una tabella può essere convertita in testo descrittivo, dove ogni riga rappresenta una “frase” e le colonne diventano attributi contestualizzati. Ad esempio, una riga in una tabella di ordini potrebbe essere tradotta in: “L’ordine numero 123, effettuato il 20 gennaio 2025 da Mario Rossi, include 3 unità del prodotto X al costo totale di 150 euro.” Questa rappresentazione testuale rende i dati tabellari più accessibili a un LLM, che può quindi analizzarli, estrarre pattern o rispondere a domande specifiche. La specifica rappresentazione come frase varia in base al caso d’uso. Tuttavia, è chiaro che tradurre così tutte le righe di una tabella può generare testi molto lunghi, soprattutto per tabelle con molti dati.
- Arricchire i dati tabellari con metadati: i dati tabellari spesso mancano di contesto esplicito. Per esempio, una colonna denominata “Data” potrebbe riferirsi alla data di un ordine, alla data di spedizione o a quella di pagamento. Per aiutare il LLM a comprendere il significato di ogni campo, è importante arricchire le tabelle con metadati descrittivi, come “Data ordine” o “Data di pagamento”. Questo arricchimento migliora l’accuratezza delle analisi, e consente al modello di generare risposte più pertinenti.
- Unificare le nomenclature: dataset provenienti da fonti diverse spesso utilizzano nomi di campi differenti per indicare la stessa cosa. Ad esempio, una tabella potrebbe utilizzare “ID_cliente” mentre un’altra usa “Cod_cliente”. Un LLM potrebbe non essere in grado di disambiguare le due. Per risolvere, serve applicare uno schema coerente e documentato a tutte le tabelle che si vogliono passare a un LLM
- Prioritizzare i dati: non tutti i dati tabellari sono ugualmente rilevanti per un task specifico. Prima di passare una tabella di dati a un LLM, è utile segmentare le informazioni e selezionare solo quelle più pertinenti. Solitamente è l’unità di business a definire quali dati servono per un dato compito e quali no.
A seconda dell’applicazione, non tutti i passaggi sopra elencati sono necessari. Indipendentemente, appena i dati tabellari sono stati avvicinati a un LLM si può finalmente iniziare a “giocare”.
Un assistente di vendita che aggiusta il linguaggio
Uno degli utilizzi più comuni dei LLM sono i RAG (Retrieval Augmented Generation), ovvero dei sistemi con cui aggiungere conoscenza di dominio a un LLM. Quando si parla di insegnare policy aziendali a un LLM per farli agire come dei consulenti HR, o quando serve specializzare un LLM per scrivere puntuali bozze di documenti legali, solitamente c’è di mezzo una RAG. Molto in breve, una RAG combina la potenza di un motore di ricerca con la capacità di generazione del linguaggio naturale dei LLM. Il motore di ricerca trova porzioni di testo all’interno di una base documentale che siano pertinenti con la richiesta fatta dall’utente. A valle, un LLM utilizza le informazioni recuperate per rispondere alla domanda originale, fornendo spiegazioni dettagliate, analisi o previsioni.
Questo approccio può trovare utilizzo anche con i dati tabellari. Per esempio, uno potrebbe volere realizzare tramite RAG un assistente di vendita eCommerce che aggiusta il linguaggio utilizzato con un utente sulla base dei prodotti che ha acquistato in passato. Per ottenere questo è sufficiente che ciascuna riga delle tabelle degli utenti registrati e dei loro acquisti sia una porzione di testo recuperabile dal motore di ricerca della RAG. Se questa condizione sussiste, allora l’utilizzatore finale beneficia dell’interattività che ormai ci si aspetta dai chatbot generativi: fare domande in linguaggio naturale e ottenere risposte dettagliate e personalizzate. Inoltre, questo approccio permette di gestire dataset ampi, richiamando solo le porzioni di testo (ovvero acquisti) necessarie per rispondere.
Tuttavia, convertire tutte le righe di una tabella in una porzione di testo può essere oneroso, sia in termini di tempo che di costi. Inoltre, la visione d’insieme del RAG dipende da quante porzioni di testo vengono recuperate per rispondere all’utente. Fare domande statistiche tipo “quanto è la spesa totale degli utenti” a una RAG sui dati tabellari potrebbe richiedere anche milioni di porzioni di testo, e questo diventa velocemente ingestibile. Tuttavia, qui non stiamo più parlando di creare un assistente alla vendita, ma un analista sempre disponibile.
Un analista sempre a portata di mano
LLM e dati tabellari aprono la strada anche a un altro caso d’uso: avere un analista sempre a portata di mano. La scena, idealmente, potrebbe essere questa. Mancano venti minuti al meeting per decidere come riallocare il budget di spesa trimestrale e nella presentazione mancano i costi di gestione di un ufficio. Tutti gli analisti sono occupati. Eppure, niente panico. Basta aprire un chatbot aziendale e chiedergli “quanto hanno speso gli uffici X ed Y nel Q2?”. Venti secondi dopo la risposta è pronta, e così la presentazione.
Richieste di sviluppo di questi sistemi stanno diventando frequenti e sono un esempio di come il confine tra dati tabellari e LLM sia sempre più sfumato. Metodologicamente, si parla di modelli SQL Agent. Questi modelli linguistici fanno da ponte tra l’utente e un dataset tabellare. Di base ricevono una richiesta di analisi dall’utente, scritta in linguaggio naturale, e utilizzano un LLM per tradurla in una query SQL, ovvero un linguaggio nato per interagire direttamente con i database tabellari. Dopo di che, eseguono la query SQL sul database e ritornano all’utente il risultato.
Questo approccio presenta molti vantaggi:
- Accesso diretto ai dati: le query SQL vengono eseguite direttamente sul database, eliminando le necessità di un motore di ricerca separato e di tradurre le righe del database in testo.
- Adattabilità: può essere utilizzato con database preesistenti, senza richiedere trasformazioni significative dei dati. Operazioni unificazione di nomenclatura e riduzione delle colonne visibili dal SQL agent possono aiutare a seconda del tipo di applicazione e dell’analisi da creare.
- Precisione: visto che la richiesta dell’utente è tradotta in query SQL, i risultati tendono a riflettere con maggiore fedeltà le richieste dell’utente. Inoltre, l’utente può aprire il cofano e validare la query SQL usata dal modello.
- Estrazione di statistiche d’insieme: SQL possiede un vasto arsenale di strumenti ottimizzati per analizzare i dati in modo aggregato ed evidenziare pattern e tendenze altrimenti difficili da individuare. Con questo approccio, un utente potrebbe chiedere di calcolare metriche globali, come la media delle vendite mensili o la distribuzione delle preferenze dei clienti su un sotto-perimetro specifico della base dati.
L’efficienza di questi sistemi dipende molto dalla capacità del modello LLM di tradurre la richiesta dell’utente in una query SQL. A tal fine, una grossa differenza la fa il prompt utilizzato internamente dall’agente per tradurre la richiesta dell’utente in query SQL. Per esempio, quale è il comportamento desiderato quando si chiede un andamento trimestrale? Cosa si intende per record “non valido”? Quali sono valori legittimi su cui filtrare le righe del database? Queste caratteristiche possono tutte essere impiantate nel processo di traduzione con esempi few-shot, o spiegando bene nel prompt cosa fare.
Un aiutante per manutenere i propri dati
Un modo diverso di utilizzare un LLM sui dati tabellari è per fare arricchimento di dati e migliorare la qualità del dato. Questo è un caso d’uso raramente percepibile dall’utente finale, ma che può avere enormi impatti economici. Chiunque lavora con i dati sa che spesso i dati possono avere buchi o errori. Questo può nascere da una negligenza, da possibili problemi tecnici, o semplicemente quando si cerca di aggiungere nuove colonne al dataset. Nel migliore dei casi, è un problema marginale; nel peggiore, può completamente invalidare strategie di vendita o rendere impossibile approcciare nuove linee di business.
Solitamente per risolvere queste situazioni si fa grosso lavoro manuale, o si sviluppano algoritmi dedicati di imputazione e classificazione. Gli LLM ampliano il tipo di strumenti che si possono utilizzare. Per esempio, un LLM può agire come modello di categorizzazione dandogli in pasto una riga di un dataset e le possibili etichette da assegnare. In alternativa, si può lasciare autonomia decisionale al LLM e far generare a lui le etichette da assegnare. Similarmente, un LLM può andare a de-duplicare le righe di un dataset ricercando quelle coppie di righe che contengono informazioni semanticamente complementari.
Questi approcci funzionano meglio per tabelle dove le colonne numeriche sono poche, o hanno un chiaro significato semantico. Inoltre, passare interi dataset a un LLM potrebbe avere costi elevati, soprattutto per dataset grandi, o presentare problemi di compliance GDPR. A seconda del caso d’uso, potrebbe aver senso optare per l’utilizzo di un LLM per l’arricchimento dei dati e della qualità del dato stesso, oppure si possono preferire strategie più tradizionali.
Conclusioni
Sebbene i dati non strutturati come documenti, video e file audio siano al centro dell’odierna onda di AI generativa, non bisogna dimenticare che i dati tabellari strutturati costituiscono ancora la maggioranza dei dati gestiti internamente alle aziende. Serve garantire la loro manutenzione e qualità, nonché padroneggiare come si combinano tra loro per poter beneficiare appieno del loro potenziale.
L’AI generativa, e più nello specifico gli LLM, possono facilitare questo compito: possono arricchire le basi dati già esistenti con processi di etichettamento flessibili, validare la qualità dei dati esistenti, correggere errori, ma anche costruire complesse analisi tramite richieste in linguaggio naturale.
Per farlo, serve “tradurre” i dati tabellari in un modo che gli LLM possano interpretare come testo, assicurarsi che l’output generato dagli LLM sia consistente, e controllare che eventuali analisi fatte con l’aiuto di un LLM corrispondano all’effettiva richiesta fatta dall’utente.
