Dati pronti per l'AI: arricchire i dati grezzi per farla funzionare

Un assistente AI è bravo quanto i dati che riesce a leggere. Puoi collegare il modello migliore sul mercato a un'interfaccia conversazionale impeccabile: se sotto ha un catalogo incoerente, risponderà con sicurezza la cosa sbagliata. È il divario che separa una demo che entusiasma da un prodotto che regge in produzione.

Lo abbiamo visto da vicino costruendo una piattaforma di product fashion discovery basata su AI: un assistente conversazionale che trova i prodotti giusti a partire da una richiesta scritta o da un'immagine. Il cuore non è la chat. È il database proprietario sotto: oltre 2 milioni di prodotti raccolti da più di 250 fonti di terze parti, normalizzati e arricchiti in automatico così che il sistema multiagente capisca cosa proporre, e perché.

Negli ultimi due anni costruire un agente conversazionale è diventato quasi banale. Un LLM, un vector database, qualche tool, e in un pomeriggio hai un prototipo che parla bene. Ed è proprio per questa ragione che sappiamo che oggi il prototipo è la parte facile, mentre quella difficile è il dato che gli si dà in pasto.

Ed è anche il motivo per cui un sistema AI amplifica i difetti invece di nasconderli. Un dato sbagliato dentro un report lo corregge prima o poi una persona. Lo stesso dato dentro un sistema AI genera centinaia di risposte sbagliate in automatico, con la stessa sicurezza con cui ne darebbe di giuste. Il settore del fashion è solo l'esempio da cui partiamo: lo stesso problema vale per finance, industriale, logistica e per qualsiasi settore che porti l'AI su dati propri o di terzi.

Da dove nasce una risposta sbagliata

Quando una fonte esterna ti apre il catalogo, non ti consegna dati ordinati. Possiamo dire con serenità che nella nostra esperienza consolidata non li abbiamo mai trovati così. In più, nel caso specifico citato sopra, i feed arrivano dalle principali reti di affiliazione, da Awin a CJ, da Rakuten a Tradedoubler, e dietro c'erano oltre 250 partner di affiliazione, per oltre 2.000 brand, per oltre 2M di prodotti unici. E ogni feed porta le sue regole.

Concretamente, 250 fonti significano fino a 250 modi diversi di chiamare la stessa categoria. Lo stesso identico prodotto compare su più reti, in versioni che non si somigliano. Le descrizioni vanno da una scheda tecnica completa a tre parole buttate lì. Gli attributi che servono a un motore di ricerca semantico, come colore, materiale, vestibilità e occasione d'uso, a volte ci sono, spesso mancano, e quando ci sono sono in lingue diverse. Su 2 milioni di prodotti che si rinnovano ogni due settimane, non è un problema che risolvi a mano.

Lo stesso schema si ripete fuori dalla moda, in ogni settore. Un'assicurazione che vuole interrogare le sue polizze con l'AI trova gli stessi campi compilati in dieci modi da dieci filiali. Un industriale che mette l'AI sui dati di produzione scopre che il dato c'è ed è corretto, ma non dice in che condizioni è stato generato. Cambia il dominio, lo schema del problema resta.

Enrichment e augmentation: due parole abusate, un significato preciso

Nel gergo del machine learning "data augmentation" di solito vuol dire ruotare e ritagliare immagini per addestrare un modello di visione. Qui intendiamo qualcosa di diverso, e più vicino al problema reale di chi porta l'AI sui propri dati.

Enrichment è rendere coerente e completo un dato che arriva incoerente e incompleto. Normalizzare 250 tassonomie in una sola. Riconoscere che due schede di reti diverse sono lo stesso prodotto e fonderle. Inferire l'attributo mancante: il colore che nessuno ha compilato, la categoria sbagliata da correggere, partendo dal titolo e dall'immagine.

Augmentation, nel nostro senso, è generare segnale nuovo che il dato grezzo non portava. Il caso principale sono gli embedding multimodali: trasformare testo e immagine di ogni prodotto in vettori che vivono nello stesso spazio, così che la richiesta di un utente, scritta o fotografata, atterri vicino ai prodotti giusti. Sono dati che prima non esistevano, e che rendono possibile la ricerca semantica.

La distinzione ha conseguenze pratiche: cambia chi fa il lavoro. L'enrichment oggi lo affidiamo a una catena di agenti AI, modelli che leggono il dato sporco, lo classificano, completano gli attributi e marcano quello che non torna. È AI usata per preparare i dati di un'altra AI.

Come si costruisce una pipeline di enrichment che regga su scala

Pulire un milione di righe in un notebook è un esercizio. Farlo ogni due settimane, in automatico, senza che un essere umano tocchi nulla, è un sistema. Ecco com'è fatto quello che abbiamo costruito per il caso specifico citato all'inizio.

I dati passano per strati successivi: un primo strato accoglie il feed grezzo così com'è, un secondo lo porta a uno schema unico e validato, un terzo lo arricchisce con attributi inferiti ed embedding. Ogni strato ha un controllo di schema: se un feed cambia formato senza avvisare, e succede di continuo, la pipeline lo intercetta invece di propagare spazzatura a valle.

L'enrichment è affidato a una catena di agenti specializzati, ognuno con un compito stretto: normalizzare le categorie, deduplicare, inferire gli attributi mancanti, generare gli embedding. È una pipeline serverless: gira come job su Google Cloud Run orchestrata da Cloud Workflows, scala quando arriva il refresh e si spegne quando ha finito, così viene pagato il calcolo solo quando serve.

A questi volumi il problema diventa il throughput. Distribuiamo il lavoro in partizioni indipendenti ed entro ogni partizione lavoriamo in parallelo, con pool dedicati: 32 worker sugli upload delle immagini, 16 sulle scritture verso il vector database. Scriviamo a blocchi, 5.000 righe per volta su BigQuery, con backoff esponenziale quando un servizio esterno rallenta. Perché i colli di bottiglia, a regime, sono quasi sempre esterni: l'endpoint che calcola gli embedding e la velocità di scrittura del vector database. Il resto lo governi tu.

Il dato arricchito finisce in due posti: un data warehouse per l'analisi (BigQuery) e un vector database (Weaviate) da cui il sistema multiagente pesca in tempo reale quando un utente fa una richiesta.

Il dato lavorato è il vero MOAT

Collegare un LLM a un vector database lo fanno tutti, e in fretta. Mantenere 2 milioni di prodotti puliti e arricchiti mentre cambiano ogni due settimane non lo fa quasi nessuno, perché è lavoro complesso e continuo, di quelli che non si vedono in una demo.

Eppure è lì che si costruisce il vantaggio (MOAT). Senza enrichment, l'assistente recupera prodotti sbagliati o irrilevanti e l'utente smette di fidarsi alla seconda risposta. Con l'enrichment, la stessa richiesta atterra sui prodotti giusti. Il modello a monte è lo stesso, l'esperienza è un'altra.

E a differenza del modello, che chiunque può prendere dallo stesso fornitore, il dataset arricchito è tuo. Si accumula, migliora a ogni ciclo, e non si copia con un weekend di lavoro. È l'asset che resta quando il prossimo modello, più bravo del tuo, sarà disponibile a tutti.

Conclusione

Quando un progetto AI parte, budget e attenzione vanno quasi sempre allo strato che si vede: il modello, l'agente, l'interfaccia che fa scena nella prima demo. È umano, ed è anche il motivo per cui tanti progetti pilota muoiono al passaggio in produzione.

Lo strato che decide il risultato è quello che non si vede: il dato reso affidabile, e tenuto tale nel tempo. Costruirlo è un lavoro di ingegneria, ripetibile e misurabile, da mettere in conto fin dall'inizio del progetto.

La domanda da farsi prima di scrivere una riga di codice è semplice: la tua prossima iniziativa AI ha un problema di modello, o un problema di dati? Nella nostra esperienza, quasi sempre la seconda.

Domande frequenti

Qual è la differenza tra data enrichment e data augmentation?

L'enrichment rende coerente e completo un dato che arriva sporco: normalizza le categorie, fonde i duplicati, inferisce gli attributi mancanti. L'augmentation genera segnale nuovo che il dato non conteneva, ad esempio gli embedding multimodali che permettono la ricerca semantica. Spesso lavorano insieme nella stessa pipeline.

Perché la qualità dei dati conta più del modello in un progetto AI?

Perché il modello migliore, alimentato con dati incoerenti, produce risposte sbagliate con la stessa sicurezza di quelle giuste, e un sistema AI mette quei difetti su scala. Cambiare modello è facile e immediato, mentre rendere i dati affidabili è il lavoro che pochi fanno e che separa una PoC da un prodotto a prova di scala enterprise.

Si può usare l'AI per arricchire i dati che servono all'AI?

Sì, ed è l'approccio che usiamo. Una catena di agenti legge il dato grezzo, lo classifica, deduplica, completa gli attributi mancanti e marca le anomalie. È un uso dell'AI a monte, sui dati, prima e indipendentemente dall'AI che parla con l'utente.

Come si mantiene la qualità del dato nel tempo?

Con automazione e controlli di schema a ogni strato della pipeline. Nel caso raccontato in questo articolo, il catalogo si rinnova ogni due settimane e l'enrichment riparte da solo, senza intervento manuale. Se una fonte cambia formato, il controllo di schema lo intercetta prima che il dato sbagliato arrivi al sistema in produzione.

Questo approccio vale solo per l'e-commerce o anche per altri settori?

Vale per qualsiasi settore che porti l'AI su dati propri o di terzi: finance, industria, logistica, sanità, eccetera. La forma del problema è la stessa, schemi incoerenti, attributi mancanti, duplicati e fonti eterogenee. Cambia solo il dominio.