Ricerca Semantica per Catalogo B2B: l'Architettura RAG che Fa Trovare il Prodotto Giusto a Ogni Rivenditore, con il Suo Listino, in 200ms

29 luglio 2026 — Cosmio Team

Come un'architettura RAG basata su Supabase pgvector e LangChain converte le query in linguaggio naturale dei clienti B2B in risultati filtrati per disponibilità e listino personalizzato, riducendo il carico sul customer service.

Un commerciale che gestisce 200 clienti wholesale riceve in media una decina di chiamate al giorno con la stessa domanda travestita in modi diversi: "Ce l'avete in versione rinforzata?", "Cerco l'equivalente del codice RF-220 ma in acciaio", "Quello che mi avete mandato a marzo, c'è ancora?". Il catalogo esiste, i dati sono corretti, ma la ricerca per parola chiave esatta non li trova: sinonimi tecnici, codici prodotto diversi da fornitore a fornitore, varianti di materiale che nessuna tassonomia rigida riesce a prevedere. Il risultato è un reparto commerciale che funge da motore di ricerca umano — e un cliente che, dopo due tentativi falliti sul portale, chiama il concorrente.

TL;DR — Executive Summary - La ricerca per parola chiave esatta fallisce su cataloghi B2B complessi (20.000–200.000 SKU) per sinonimi, codici e varianti di materiale non previsti dalla tassonomia - Un'architettura RAG (Retrieval-Augmented Generation) converte ogni query in un vettore di embedding, cerca per similarità coseno in Supabase pgvector e filtra per disponibilità e listino del cliente autenticato - La pipeline tipica collega ERP/PIM (SAP, Odoo, Akeneo) → indicizzazione n8n → Supabase pgvector → query layer LangChain + Claude - Row Level Security (RLS) isola i dati commerciali per cliente: nessun listino di terzi finisce mai nel contesto del modello - Investimento indicativo per 10.000–100.000 SKU: setup una tantum + costi infrastruttura mensili, dettagliati nella matrice decisionale

Il tuo catalogo B2B ha questo problema?

1. Il tuo team commerciale dedica più di 2 ore al giorno a rispondere a domande su disponibilità o compatibilità di prodotto già presenti nel catalogo online?
2. Il tuo catalogo contiene famiglie di prodotto con più codici, sinonimi tecnici o varianti di materiale che i clienti cercano in modo diverso da come le hai categorizzate?
3. Il portale B2B mostra "nessun risultato" quando un cliente cerca per caratteristica tecnica (es. "resistente a 200 gradi") invece che per codice esatto?
4. Hai notato ordini persi o spostati sul concorrente dopo che un cliente non ha trovato l'alternativa a un prodotto esaurito?
5. Aggiorni prezzi o disponibilità più volte al giorno e il portale mostra dati non allineati in tempo reale per i clienti con listini personalizzati?

Se hai risposto Sì a 3 o più domande, il collo di bottiglia descritto in questo articolo sta probabilmente impattando la tua operatività — le sezioni seguenti mostrano come quantificarlo e affrontarlo. Se hai risposto Sì a meno di 2 domande, il tuo catalogo è già più maturo della media: le sezioni seguenti possono comunque rivelare ottimizzazioni incrementali sull'architettura.

Perché la ricerca a parola chiave sta bloccando le vendite

Un catalogo con 50.000+ SKU non fallisce per mancanza di dati, ma per rigidità della struttura di ricerca. Tre fattori concreti spiegano il costo operativo del problema:

Sinonimia tecnica non gestita. Lo stesso componente può essere chiamato "raccordo", "giunto", "connettore" a seconda del settore del cliente, del fornitore originario o della regione. Un indice a parola chiave (anche con fuzzy matching classico) non collega questi termini semanticamente, mentre un motore che lavora per similarità vettoriale li tratta come concettualmente vicini.

Codici prodotto non universali. Distributori che aggregano cataloghi da più fornitori ereditano nomenclature diverse per lo stesso articolo. Il cliente conosce il codice del produttore originale, il gestionale usa il codice interno: senza un livello di ricerca semantica, questa distanza si traduce in una telefonata.

Filtraggio contestuale assente. Anche quando la ricerca testuale funziona, raramente incrocia in tempo reale disponibilità di magazzino, tempi di consegna e — soprattutto — il listino contrattuale del cliente autenticato. Il risultato è un elenco di prodotti tecnicamente corretto ma commercialmente inutile.

Secondo dati Forrester B2B Commerce 2025, un portale B2B con ricerca AI riduce del 35% le richieste al customer service e aumenta il tasso di conversione del catalogo del 28%. Il dato va contestualizzato: l'impatto reale dipende dal numero di SKU, dalla qualità delle schede prodotto di partenza e dal volume di query mensili — un catalogo con 15.000 SKU ben strutturati recupera valore più rapidamente di uno con 150.000 SKU e schede prodotto incomplete.

L'architettura RAG per catalogo B2B: da ERP a risposta contestualizzata

Lo schema architetturale che regge un motore di ricerca semantica su cataloghi wholesale segue quattro livelli:

1. Sorgente dati — WooCommerce B2B, SAP o Odoo restano il sistema di verità per anagrafica prodotto, stock e prezzi; PIM come Akeneo o Pimcore arricchiscono le schede con attributi tecnici, immagini e varianti.

2. Pipeline di indicizzazione (n8n) — un workflow schedulato estrae le schede prodotto, le segmenta (chunking) in unità semantiche coerenti (nome, descrizione tecnica, specifiche, compatibilità), genera l'embedding di ogni chunk e lo scrive in Supabase.

3. Storage vettoriale (Supabase + pgvector) — ogni chunk viene salvato con il vettore di embedding, i metadati di prodotto (SKU, categoria, disponibilità) e — cruciale — il riferimento al listino cliente tramite Row Level Security.

4. Query layer (LangChain + Claude) — la query del cliente viene trasformata in embedding, LangChain orchestra la ricerca per similarità coseno filtrata per disponibilità e permessi cliente, e Claude genera la risposta in linguaggio naturale a partire dai risultati recuperati.

Questa architettura — descritta più in dettaglio nella guida 2026 all'automazione IA per l'e-commerce B2B — si differenzia dalle soluzioni proprietarie come Planet B2B, sbarcata in Italia al Netcomm Forum 2026 con un'offerta di back-office AI integrata con SAP, Microsoft Dynamics, Akeneo e Pimcore: un'architettura custom su Supabase e LangChain richiede più setup iniziale, ma elimina il lock-in su un singolo vendor e permette di controllare interamente dove risiedono i dati commerciali sensibili.

Chunking delle schede prodotto. Una scheda prodotto lunga (specifiche tecniche, compatibilità, certificazioni) non va indicizzata come blocco unico: va segmentata in chunk da 200–400 token, ciascuno con metadati che ne preservano il contesto (SKU di riferimento, categoria, unità di misura). Chunk troppo grandi diluiscono la similarità semantica; chunk troppo piccoli perdono contesto tecnico.

Aggiornamenti incrementali di stock e prezzo. Rigenerare l'intero indice vettoriale ogni volta che cambia una disponibilità è inefficiente su cataloghi grandi. La pratica corretta separa i dati che richiedono re-embedding (descrizione, specifiche — cambiano raramente) dai dati dinamici (stock, prezzo — cambiano più volte al giorno), mantenuti come metadati filtrabili in query senza toccare il vettore. n8n gestisce questa sincronizzazione con webhook incrementali dall'ERP, non con un ricalcolo completo.

Rate limiting su cataloghi grandi. Con 100.000+ SKU, la generazione di embedding in batch va scaglionata per rispettare i limiti di rate delle API di embedding e i costi variabili all'aumentare dei chunk. Una coda con backoff esponenziale in n8n evita errori 429 e permette di ricostruire l'indice completo in finestre notturne senza saturare le API.

Esempio pratico: dalla query in linguaggio naturale alla risposta filtrata per cliente

Input: il buyer di "Rossi Impianti Srl" (listino B2B con sconto 18% sulla categoria raccorderia) digita nel portale: "raccordo per pompa acqua max 200 gradi norma FDA disponibile entro giovedì".

Workflow:

1. La query viene convertita in embedding tramite un modello dedicato
2. LangChain esegue una ricerca per similarità coseno nell'indice pgvector, limitata ai top-20 chunk più vicini
3. Un filtro SQL post-retrieval applica: disponibilità magazzino ≥10 pz, data di consegna stimata ≤ giovedì, categoria visibile per il profilo cliente (via RLS)
4. I chunk risultanti vengono passati a Claude con un prompt strutturato che include anche il listino contrattuale del cliente autenticato

Prompt strutturato (semplificato):

Sei l'assistente del portale B2B di [distributore]. Cliente autenticato: Rossi Impianti Srl (sconto 18% categoria raccorderia).
Risultati di ricerca semantica (top 3 per similarità e disponibilità):
[chunk 1: REF-8821, raccordo pompa acqua 200°C, norma FDA, 45 pz, consegna mercoledì, prezzo listino €5,12]
[chunk 2: REF-9034, raccordo pompa acqua 180°C, norma FDA, 12 pz, consegna giovedì, prezzo listino €4,80]
[chunk 3: REF-7712, raccordo pompa acqua 200°C, non certificato FDA, 200 pz, consegna martedì, prezzo listino €3,90]
Genera una risposta che raccomandi l'opzione più adatta, applica lo sconto contrattuale del cliente, e proponi l'aggiunta al carrello.

Output generato:

Risposta testuale: "Ho trovato 2 raccordi compatibili con norma FDA. Il più economico per la tua fascia di sconto è REF-8821 a €4,20 cadauno (vs. €5,12 listino), disponibile in 45 pezzi, consegna mercoledì — prima del termine richiesto. Vuoi aggiungere al carrello?"

Tempo di risposta tipico: sotto i 200-300ms su cataloghi da 100.000 SKU, a seconda della complessità del filtro post-retrieval e della latenza di rete verso l'API del modello.

Come usare l'IA Generativa per generare embedding e risposte contestualizzate

Un errore comune nell'implementazione di questa architettura è usare lo stesso LLM sia per generare gli embedding sia per la risposta finale. Su cataloghi grandi, è preferibile separare i due ruoli: un modello dedicato all'embedding come text-embedding-3-small di OpenAI ottimizza i costi di indicizzazione su centinaia di migliaia di chunk (il costo per token di un embedding dedicato è una frazione di quello di un LLM generalista), mentre Claude — nella sua versione più recente disponibile — viene riservato al layer di generazione della risposta finale, dove il contesto esteso e la capacità di seguire istruzioni strutturate (come l'applicazione dello sconto cliente) fanno la differenza.

Per cataloghi sotto i 20.000 SKU dove il volume di re-indicizzazione è limitato, l'ultimo modello di Gemini può essere un'alternativa se l'infrastruttura è già su Google Cloud e serve integrazione nativa con BigQuery per l'analisi dei log di ricerca. Per team che preferiscono un'unica piattaforma end-to-end senza gestire due API separate, l'ultimo modello di ChatGPT con le sue funzioni di embedding integrate resta un'opzione valida, a costo di una minore flessibilità architetturale rispetto alla separazione embedding/generazione.

Il gestionale (SAP, Odoo) resta il sistema di verità per stock e prezzo: l'LLM non sostituisce l'ERP, colma il gap tra query in linguaggio naturale del cliente e i dati strutturati che l'ERP già possiede.

Azioni immediate (questa settimana, senza cambiare software)

1. Esporta il catalogo come CSV (nome prodotto, categoria, descrizione) e caricalo in Claude o ChatGPT con il prompt: "Identifica le 10 famiglie di prodotti con maggiore ambiguità terminologica — dove un cliente potrebbe cercare lo stesso articolo con 3+ termini diversi". Il risultato è la lista delle priorità di indicizzazione, non un'analisi generica.
2. Conta le chiamate/email della scorsa settimana riguardanti disponibilità o compatibilità prodotto già presente a catalogo. Calcola il tempo commerciale totale dedicato: è la baseline da confrontare dopo un'eventuale implementazione.
3. Crea un account Supabase gratuito, attiva l'estensione pgvector e segui il tutorial ufficiale con 200 prodotti reali del tuo catalogo: una demo funzionante è ottenibile in poche ore senza scrivere codice di produzione, ed è il modo più rapido per valutare la qualità dei risultati sui tuoi dati specifici prima di un investimento più ampio.

Hai ora una mappa delle famiglie prodotto più ambigue e una stima del tempo commerciale che ci gira intorno. Il questionario di Analisi IA incrocia questi dati con benchmark tecnici di settore per stimare l'effort di implementazione nel tuo caso specifico.

Quale approccio per la tua realtà

Per distributori oltre 100.000 SKU e 300+ clienti enterprise, la scelta si sposta su Elasticsearch dedicato con modello fine-tuned sul vocabolario di settore, o su piattaforme come Planet B2B: la previsione riordini multi-agente su 100.000 SKU affronta un caso di questa scala.

Dubbi Frequenti

I dati dei listini dei clienti sono al sicuro? Le denominazioni aziendali e i prezzi contrattuali sono dati commerciali riservati. In Supabase, la Row Level Security (RLS) isola i dati per singolo cliente a livello di database: nessuna query può restituire il listino di un cliente diverso da quello autenticato, e il contesto passato al LLM contiene solo i dati del cliente in sessione.

Cosa succede se l'LLM genera una risposta imprecisa? Il modello non inventa prezzi o disponibilità: genera testo a partire esclusivamente dai chunk recuperati dal database, che riflettono i dati reali dell'ERP. Il rischio di allucinazione va comunque monitorato con un log delle risposte generate e un processo di revisione umana periodica sulle categorie ad alto valore, mantenendo l'operatore come arbitro finale sulle configurazioni di prodotto complesse.

Quanto è complesso implementare questa architettura? Richiede competenze di integrazione tra ERP/PIM, un workflow n8n per la sincronizzazione e una configurazione LangChain per il query layer — un progetto tipicamente affidato a un system integrator o a uno sviluppatore interno con esperienza API, non un'attività da reparto marketing.

Per l'uso di LLM con dati commerciali, valgono alcune regole non negoziabili: usare esclusivamente versioni Enterprise (Claude for Work, ChatGPT Enterprise, Gemini for Google Workspace) che non utilizzano i dati per l'addestramento dei modelli; non caricare mai listini o anagrafiche clienti su versioni consumer gratuite; verificare il DPA (Data Processing Agreement) del fornitore, perché l'azienda distributrice rimane titolare del trattamento anche quando affida l'elaborazione a un LLM terzo. Per settori con obblighi normativi più stringenti (es. dispositivi medici, prodotti regolamentati) va valutata anche una soluzione on-premise per il layer di generazione.

Dove questo approccio ha dei limiti. La ricerca semantica RAG non funziona bene su schede prodotto povere di testo descrittivo: se il catalogo ha solo codice e prezzo senza specifiche tecniche, l'embedding non ha materiale semantico su cui lavorare e il beneficio si riduce drasticamente. Non è adatta a query che richiedono calcoli configurativi complessi (es. dimensionamento tecnico con vincoli multipli) — in quei casi serve un configuratore dedicato, non un motore di ricerca. Le condizioni minime per un'implementazione efficace: almeno 5.000 SKU con descrizioni tecniche di almeno 2-3 frasi, un ERP con API accessibili per la sincronizzazione incrementale, e una competenza interna (o un system integrator) capace di manutenere la pipeline nel tempo. Sotto queste soglie, il rapporto costo/beneficio di un'architettura RAG dedicata cala sensibilmente rispetto a soluzioni più semplici.

Chiusura

L'esempio di Rossi Impianti Srl mostrato in questo articolo — una query vaga in italiano tecnico che diventa in meno di un secondo un confronto tra alternative disponibili, prezzate al listino corretto — è la differenza tra un portale che genera ordini e uno che genera telefonate. Il valore non sta nella tecnologia in sé, ma nel colmare la distanza tra il linguaggio con cui i clienti pensano ai prodotti e la struttura rigida con cui i cataloghi li classificano. Prima di investire in un'architettura completa, vale la pena verificare quanto quella distanza pesi davvero sui numeri della propria azienda: il questionario di Analisi IA è pensato proprio per tradurre i sintomi descritti in questo articolo — telefonate ripetitive, ricerche fallite, ordini persi — in una mappa di priorità concreta.