Migliaia di schede prodotto da cataloghi sporchi: com'è fatta una pipeline che non pubblica errori
Un rivenditore di illuminazione e arredo design, migliaia di SKU, decine di brand con dati sorgente incoerenti. Il caso reale di una pipeline dove l'AI scrive ma non decide: normalizzazione in codice, glossario tecnico, validazione automatica.
Un rivenditore di illuminazione e arredo design vende online migliaia di articoli di decine di brand. Ogni brand fornisce i dati a modo suo: campi diversi, unità diverse, la stessa finitura chiamata in tre modi. Le schede prodotto si facevano a mano — lente da produrre, e con un rischio che pesa più della lentezza: l'errore che finisce pubblicato, davanti ai clienti.
Il problema non era scrivere: era fidarsi
Generare testo oggi è facile. Chiunque abbia aperto ChatGPT sa ottenere una descrizione di prodotto in dieci secondi. Il problema di un e-commerce vero è un altro: su migliaia di schede, quante contengono una misura sbagliata, una potenza inventata, una finitura che non esiste? Chi lo scopre — il cliente, con il reso?
Per questo il progetto non è "usare l'AI per scrivere le schede". È costruire una catena in cui l'AI scrive, ma non decide.
La pipeline, in tre anelli
1. Normalizzazione — in codice, non nel modello
Prima che il modello veda una sola riga, i dati di ogni brand passano per una normalizzazione scritta in codice, deterministica: stessi campi, stesse unità, stessi nomi per le stesse cose. Il lavoro sporco — ed è la parte più grossa del progetto — non lo fa l'AI: lo fa codice che dà lo stesso risultato oggi, domani e alla riga centomila.
2. Generazione controllata — con un glossario tecnico
Solo a questo punto entra il modello, e scrive dentro binari: un glossario tecnico del settore definisce i termini corretti — le finiture, i materiali, le grandezze — e la generazione può usare quelli, non sinonimi inventati. Il testo esce naturale, ma il vocabolario è sotto controllo.
3. Validazione automatica — l'anello che conta
Ogni scheda generata viene ricontrollata da codice contro i dati sorgente: ogni valore tecnico deve coincidere. Quello che non passa non viene pubblicato — torna in coda, con il motivo. È la frase che riassume l'intero approccio: l'output è verificato da codice, non dal modello. La fiducia non si chiede al lettore: si costruisce nella pipeline.
I numeri
Il motore ha lavorato su dieci cataloghi di produttori, per un totale di 30.512 pagine prodotto scaricate. Sei di quei cataloghi sono stati portati fino ai file di import, e coprono due mondi merceologici diversi — illuminazione tecnica e arredamento — con lo stesso codice: cambia solo un modulo di configurazione per marchio.
In uscita: 2.548 schede prodotto con 8.644 combinazioni di varianti, e 5.517 descrizioni generate — ogni scheda esiste in italiano e in inglese, prodotte insieme perché il fact-check deve poter confrontare le due lingue. Il conteggio è prudente: sono solo i file di import canonici, senza le ondate successive di integrazione.
E qui il numero che conta davvero. Su 2.308 schede passate dal generatore, 48 sono uscite con la descrizione vuota: il 2,1%. Non è un tasso di errore — è il contrario. Sono le schede in cui il fact-check ha respinto il testo tre volte di fila e la pipeline ha deciso di non pubblicare niente piuttosto che pubblicare una frase che non aveva potuto verificare. Quarantotto descrizioni mancanti sono quarantotto errori che il cliente non ha mai visto online.
È la differenza tra questo e il «fatelo scrivere all'AI». Il modello non ha un margine di errore accettabile: ha un cancello davanti. Se una misura, un materiale o una temperatura di colore non compare nei dati sorgente, quella frase non esce. Sopra ci girano 22 controlli automatici sui file generati, più un controllo separato sulle immagini che su un solo marchio ha isolato 1.097 combinazioni in cui la foto associata era da guardare a mano.
Cosa rende questo caso ripetibile
Niente di quel che c'è sopra è specifico dell'arredo. Cataloghi fornitori, listini, distinte, anagrafiche articolo: ovunque ci siano dati sorgente sporchi e un output che non può permettersi errori, la struttura è la stessa — normalizzazione deterministica, generazione dentro binari, validazione che blocca invece di sperare. Se il vostro collo di bottiglia assomiglia a questo, ne parlo volentieri: automazioni su documenti e dati.
Domande frequenti
Il modello non inventa specifiche che non esistono?
È il rischio numero uno di questi progetti, ed è il motivo per cui la generazione è l'anello meno importante della catena. Ogni valore tecnico nella scheda finale viene riconfrontato da codice con il dato sorgente: se non coincide, la scheda non passa e torna in coda con il motivo. L'output è verificato da codice, non dal modello.
I nostri dati sorgente sono un disastro. Funziona lo stesso?
I dati sporchi non sono l'ostacolo del progetto: sono il progetto. La pipeline comincia proprio da lì — una normalizzazione scritta in codice, deterministica, che porta formati e campi incoerenti a uno schema unico prima che il modello veda una sola riga. Se i dati fossero puliti, questa pagina non esisterebbe.
E quando i brand cambiano listino?
Il sistema si riesegue: riprende le fonti, rifà normalizzazione e generazione solo su ciò che è cambiato, e la validazione segnala le differenze. È la differenza tra uno script una tantum e un sistema che regge nel tempo — e il motivo per cui questi progetti proseguono di solito con una manutenzione ricorrente.
Quanto costa un sistema così?
Dipende da quante fonti, in che stato sono e quanto è ricco il glossario di settore. L'ordine di grandezza si definisce in una call dopo aver visto un campione dei vostri dati — è mezz'ora, e serve prima di tutto a dirvi se il gioco vale la candela.