Introduzione al problema dell’abbinamento prodotti

Immagina di avere due cataloghi di prodotti: il primo contiene 10.000 articoli, il secondo 50.000. Il compito è trovare i prodotti corrispondenti, nonostante fornitori diversi usino nomi, abbreviazioni e formati differenti.

Sembra il lavoro ideale per un modello di linguaggio di grandi dimensioni (LLM). I moderni modelli comprendono il contesto, riconoscono sinonimi e gestiscono testo non strutturato. Basta fornire al modello le due liste, chiedere di trovare le corrispondenze e il gioco è fatto.

In realtà non è così semplice. Un LLM può capire correttamente i nomi dei prodotti e comunque restituire l’abbinamento sbagliato. Il motivo è semplice: nomi simili, prodotti identici e sostituti commercialmente accettabili sono tre concetti differenti.

Durante la risoluzione di problemi di matching automatico abbiamo incontrato diverse difficoltà che non si risolvono semplicemente passando a un modello più potente o scrivendo un prompt migliore. Analizziamo cosa va storto e come costruire un processo di abbinamento più affidabile.

1. Nomi simili non equivalgono a prodotti identici

Partiamo da un esempio elementare. Il catalogo A contiene:

    • Apple Juice, 1L, No Added Sugar

Il catalogo B contiene:

    • Apple Juice Drink, 1L, Sweetened

La similarità lessicale è alta: molte parole coincidono, il volume è lo stesso e entrambi i prodotti sono bevande a base di mela. Semanticalmente sono vicini.

Tuttavia non sono prodotti identici: il primo è succo senza zucchero aggiunto, il secondo è una bevanda dolcificata. Se cerchiamo una corrispondenza esatta, questa coppia dovrebbe essere scartata.

Consideriamo ora la situazione opposta:

    • Extra Virgin Olive Oil, 750 ml
    • EVOO, 0.75L

I nomi sembrano diversi, ma EVOO è l’abbreviazione comune per Extra Virgin Olive Oil e i volumi coincidono una volta normalizzati. Se gli altri attributi rilevanti corrispondono, questa coppia può essere considerata una corrispondenza valida.

Questi esempi semplificati mostrano un problema fondamentale: un algoritmo può eccellere nel misurare la similarità testuale senza capire se due prodotti sono davvero equivalenti. Per farlo occorre analizzare gli attributi del prodotto e i requisiti specifici del compito di matching.

Inoltre, a volte il business non richiede un prodotto identico, ma un sostituto accettabile. In tal caso, due articoli possono avere marchi diversi o qualche attributo differente e comunque essere considerati una corrispondenza valida.

Di conseguenza dobbiamo separare due domande:

    • Quanto sono simili i nomi di questi prodotti?
    • Questi prodotti dovrebbero essere considerati una corrispondenza?

Non sono la stessa cosa.

2. Talvolta la risposta non è nei dati disponibili

Consideriamo un prodotto elencato così:

    • Premium Coffee, 250g

Sappiamo che si tratta di caffè e del peso della confezione, ma queste informazioni non bastano per abbinarlo con certezza a un prodotto specifico in un altro catalogo. Mancano il produttore, il livello di torrefazione, la varietà di caffè e altri dettagli potenzialmente importanti.

Un operatore umano, davanti al catalogo, potrebbe aprire la pagina del fornitore, cercare le informazioni mancanti e poi decidere. Un LLM che riceve solo il nome originale non dispone di questi dati. Potrebbe indovinare gli attributi mancanti basandosi sulla sua conoscenza generale, ma un’ipotesi non è la stessa cosa di dati verificati.

Questo è cruciale quando i risultati di matching vengono usati per acquisti, confronti di prezzo o aggiornamenti di sistemi ERP. Un abbinamento errato può provocare ordini sbagliati, confronti di prezzo non validi o dati incoerenti in un sistema aziendale.

Per questo è importante verificare se le informazioni disponibili sono sufficienti prima di tentare una decisione di matching. Se un attributo chiave manca, il sistema dovrebbe:

    • Recuperare informazioni aggiuntive da fonti esterne.
    • Richiedere una revisione umana.
    • Segnalare l’incertezza per una gestione successiva.

Non tutti gli errori di IA si risolvono con un prompt migliore; a volte è semplicemente necessario più dato.

3. Perché un unico prompt gigantesco è una cattiva idea

Il modo più ovvio per automatizzare il matching è dare all’LLM due liste e chiedere di restituire le coppie corrispondenti. Questo può funzionare per piccoli set di dati, specialmente quando i nomi sono chiari e ricchi di informazioni.

Con l’aumentare delle dimensioni dei cataloghi la situazione si complica:

    • Il modello deve svolgere più compiti contemporaneamente: trovare candidati potenziali, interpretare gli attributi e decidere le corrispondenze.
    • I costi di elaborazione crescono. Inviare interi cataloghi nel contesto del modello per ogni richiesta è costoso e spesso impraticabile.
    • Il debugging diventa più difficile. Se il modello restituisce un prodotto errato, cosa è andato storto? Ha frainteso un’abbreviazione? Ha trascurato un attributo importante? Ha applicato una regola sbagliata?

Quando tutto avviene dentro un unico prompt, rispondere a queste domande è complicato. Per questo troviamo più pratico suddividere il matching su larga scala in più passaggi specialistici.

Algoritmi tradizionali possono occuparsi della pulizia e normalizzazione del testo. La ricerca lessicale e semantica può identificare candidati potenziali. Un LLM può interpretare nomi ambigui ed estrarre attributi. Le decisioni finali di matching possono poi basarsi su caratteristiche strutturate, regole di business e un algoritmo di ranking separato.

Non c’è motivo di usare un LLM per ogni operazione quando un metodo più semplice può svolgere il compito in modo affidabile e a costi inferiori.

4. Un approccio pratico al matching di cataloghi

Di seguito un flusso generale che può guidare la progettazione di un sistema di matching prodotti.

4.1. Trovare i candidati

Invece di confrontare ogni prodotto con tutti gli altri usando un LLM, è più efficiente restringere lo spazio di ricerca. Un approccio comune combina similarità lessicale e semantica.

    • La ricerca lessicale funziona bene per parole simili, codici prodotto e convenzioni di denominazione.
    • La ricerca semantica aiuta a trovare elementi con significati correlati, anche quando la formulazione differisce.

Un limite importante: se il prodotto corretto non entra nella lista dei candidati, le fasi successive non potranno selezionarlo. Perciò la qualità del recupero dei candidati deve essere valutata separatamente dalla qualità del ranking finale.

Alcuni sistemi richiedono una lista breve dei match più probabili; altri devono trovare il maggior numero possibile di alternative accettabili. Sono requisiti diversi che richiedono strategie di recupero differenti.

4.2. Confrontare gli attributi del prodotto

Una volta ottenuta una serie di candidati, si estraggono e normalizzano gli attributi necessari per il matching. Per prodotti alimentari, ad esempio, potrebbero includere tipo, ingredienti, peso e confezione. Per componenti elettronici, i campi rilevanti potrebbero essere produttore, modello, specifiche tecniche e compatibilità.

Gli LLM risultano particolarmente utili in questa fase perché possono interpretare nomi non strutturati difficili da gestire con espressioni regolari o dizionari.

Tuttavia, l’estrazione è solo metà del lavoro. È necessario confrontare correttamente gli attributi:

    • “750 ml” e “0.75 L” devono essere considerati volumi equivalenti.
    • “Sugar‑free” e “sweetened” indicano una differenza importante.
    • Nomine diverse per lo stesso paese non devono automaticamente generare conflitto.
    • Non tutti gli attributi hanno lo stesso peso: in alcune categorie un produttore diverso è inaccettabile, in altre può essere un sostituto valido.

Perciò verificare che ogni attributo corrisponda non è sufficiente; occorre ponderare l’importanza di ciascuno secondo il dominio.

4.3. Separare ranking dalla comprensione linguistica

Dopo aver estratto e confrontato gli attributi, si costruisce un set di feature per ogni coppia di prodotti. Le feature possono includere:

    • Similarità lessicale
    • Similarità semantica
    • Concordanza del produttore
    • Numero di attributi corrispondenti
    • Altri segnali specifici del business

Un classificatore separato o un sistema basato su regole può quindi valutare quanto la coppia soddisfi i requisiti di matching. In questo modo l’LLM non deve gestire l’intera decisione, ma solo la comprensione e l’estrazione.

Questo approccio consente di valutare indipendentemente il recupero, l’estrazione e il ranking. Quando qualcosa va storto, è più semplice isolare il componente responsabile anziché riscrivere un unico prompt gigantesco.

5. Conclusioni e consigli pratici

Un LLM è uno strumento potente per interpretare testo non strutturato, ma da solo non garantisce corrispondenze corrette. Le principali cause di errori sono:

    • Confondere similarità testuale con equivalenza reale.
    • Lavorare con dati incompleti o ambigui.
    • Affidarsi a un unico prompt che deve svolgere troppe funzioni contemporaneamente.

Per ottenere un processo di matching robusto è consigliabile:

    • Separare la ricerca dei candidati dalla valutazione finale.
    • Utilizzare algoritmi tradizionali per pulizia, normalizzazione e ricerca preliminare.
    • Sfruttare l’LLM principalmente per l’estrazione di attributi da nomi complessi.
    • Costruire un modello di ranking o regole di business che combinino le feature estratte.
    • Implementare meccanismi di fallback (richiesta di dati aggiuntivi o revisione umana) quando gli attributi chiave mancano.

Seguendo questi principi, le organizzazioni possono ridurre gli errori di abbinamento, contenere i costi computazionali e mantenere un elevato livello di affidabilità nei processi di integrazione dei cataloghi.