Social App
Stylemix
Virtual Try On
Visual Discovery
Feed Optimizer
La ricerca di prodotti all’interno degli e-commerce e in particolare, quelli dedicati al fashion, più in generale negli aggregatori, nei social e nelle piattaforme che hanno la necessità di trovare prodotti sulla base delle preferenze dell’utente, ha da sempre sofferto di un problema di fondo: dover interagire con database spesso relazionali, nei quali non era immediato né semplice individuare la similarità tra prodotti, se non sviluppando logiche difficili da mantenere nel tempo e ancor più difficili da implementare.
Grazie all’avvento delle nuove tecnologie di Deep Learning, e a quello che ormai è riconosciuto come stato dell’arte nel settore, la RAG, ovvero Retrieval-Augmented Generation, è possibile risolvere questo problema. Non solo permettendo all’utente di cercare prodotti all’interno di un e-commerce in modo più naturale, ma anche di farlo in maniera visiva.
Questo perché una RAG lavora con un database di vettori, spesso indicati con il termine “embeddings”, che non è tecnicamente sinonimo, ma viene usato come tale nel linguaggio corrente.
Il dato è nostro
Costruire una RAG su nostre indicazioni e con le nostre modalità non solo è una scelta tecnica ma anche strategica.
Il dato appartiene a noi e ai nostri partner. I feed e i prodotti che entrano su Bantoa non transitano attraverso piattaforme terze né alimentano modelli esterni: rimangono all’interno della nostra infrastruttura, sotto il nostro controllo. Per i brand e i retailer che ci forniscono i loro cataloghi, questo è una garanzia concreta: i loro dati non diventano patrimonio di qualcun altro.
Avere il controllo del dato significa anche poterlo lavorare nel modo più adatto ai nostri obiettivi. Ogni prodotto che entra nel sistema porta con sé informazioni visive e testuali, come immagini, titoli, descrizioni e categorie che possono provenire direttamente dal dealer oppure dalla nostra categorizzazione interna, costruita sulla tassonomia che abbiamo sviluppato nel tempo. Questa tassonomia è un asset: ci permette di produrre vettori più precisi e più coerenti rispetto a quelli che si otterrebbero da un dato grezzo e non strutturato.
Il risultato è un sistema che non dipende da come un fornitore decide di descrivere i propri prodotti, ma che interpreta, normalizza e arricchisce quei dati secondo una logica che è la nostra. È questo che rende la ricerca affidabile e scalabile nel tempo.
Due tipi di vettori
Per unire queste due modalità di ricerca, utilizziamo due tipi di modelli particolari. Non si tratta di LLM come quelli che ormai fanno parte della vita quotidiana, come ad esempio GPT-5 o Gemini, ma di modelli specifici, detti encoder, che prendono le informazioni visive e testuali e le trasformano in vettori numerici.
Il meccanismo che abbiamo adottato è il seguente: creiamo vettori per il testo, vettori per le immagini e vettori costruiti a partire dai metadati. I primi due sono densi, quelli dei metadati sono sparsi.
Vettori densi
I vettori densi sono adatti alla ricerca semantica: permettono di cercare scrivendo in linguaggio naturale quello che si vuole trovare. La query viene trasformata in vettori e confrontata con quelli già presenti nel database, stabilendo una vicinanza semantica. La stessa logica si applica alle immagini: fornendo un’immagine in input, viene cercata la similarità visiva all’interno del database.
Per questa tipologia di vettore abbiamo utilizzato un modello commerciale di Google, che è ovviamente multimodale e ha ottime performances, ovvero Gemini Embedding 2, che supporta fino a 3072 dimensioni e rappresenta testo e immagini con lo stesso linguaggio numerico, permettendo di cercare un’immagine partendo da una parola, e viceversa (spazio latente).
Vettori sparsi
I vettori densi, però, non sono efficienti con le keyword secche. Funzionano bene quando si dialoga con la ricerca in linguaggio naturale, ma nel momento in cui si specifica qualcosa di preciso e diretto, una parola come “jeans” o “blu”, entrano in gioco i vettori sparsi.
Il vettore sparso non riesce a distinguere due frasi semanticamente identiche ma lessicalmente diverse. Tuttavia ha una qualità precisa, ovvero quella di coprire il matching esatto: è efficace quando si cerca una parola specifica e migliora l’affidabilità della ricerca puntuale su un termine ben definito.
Per gli sparse vector la scelta è ricaduta sui ben noti BM25, tipologia di vector ormai più che collaudati. Esistono approcci più recenti e sofisticati, ma BM25 offre due vantaggi concreti che per il nostro caso d’uso hanno fatto la differenza: nessun vincolo di lingua e una velocità di esecuzione molto elevata.
Ricerca ibrida
Questa combinazione di vettori sparsi e vettori densi prende il nome di ricerca ibrida. I due tipi sono complementari: i densi da soli potrebbero bastare, ma risultano deboli sui termini secchi, sulle keyword dirette. Insieme, garantiscono la ricerca più affidabile possibile.
In pratica, il nostro sistema è in grado di rispondere sia a ricerche precise, come “sneakers bianche”, dove i vettori sparsi fanno il lavoro, sia a richieste vaghe e descrittive, come una foto caricata dall’utente, un’impressione visiva, o una frase come “qualcosa di elegante per una serata d’estate”: qui sono i vettori densi a trovare la risposta giusta.
Il sistema che abbiamo costruito è in grado di rispondere a un’ampia gamma di intenzioni di ricerca: dalla query più precisa, “sneakers bianche running taglia 42”, al caricamento di una semplice immagine.
In entrambi i casi, il motore trova prodotti realmente correlati, non per corrispondenza di parole chiave, ma per affinità semantica e visiva.
Questo cambia il modo in cui un utente può relazionarsi con un catalogo di prodotti: non è più costretto a conoscere le parole giuste, né a navigare categorie predefinite, può quindi cercare come pensa.
Sul fronte tecnico, il sistema è già in produzione e continua a evolvere. I modelli di embedding migliorano rapidamente, dato che le dimensioni aumentano ma la comprensione multimodale si affina, che porterà quindi ad un miglioramento della qualità della ricerca. La direzione è verso sistemi sempre più capaci di interpretare l’intenzione dell’utente, anche quando questa è parziale, ambigua o soltanto visiva.
La ricerca, in altre parole, sta diventando conversazione.
Fonti
Gemini Embedding 2 blog: https://blog.google/innovation-and-ai/models-and-research/gemini-models/gemini-embedding-2/
Enrico Antonini, Deep learning engineer @Bantoa
Compila il modulo per ricevere maggiori informazioni dal nostro team.
