RAG per Cataloghi Prodotto nel 2026: Quando Funziona, Quando No, e Cosa Ho Imparato Costruendone Tre

1. La Domanda Scomoda: Ha Ancora Senso RAG nel 2026?

Mettiamola subito sul tavolo. Nel 2024, RAG era la risposta a tutto: i modelli avevano context window di 8-32K token, i costi per token erano alti, e l'unico modo per dare conoscenza specifica a un LLM era iniettarla via retrieval. Era una necessità tecnica, non una scelta architetturale.

Nel 2026, il panorama è cambiato. Claude ha una context window da 1 milione di token. GPT-5 gestisce 256K. Gemini 2.5 Pro arriva a 1M. Il costo per token di input si è ridotto di un ordine di grandezza rispetto al 2024. La domanda legittima è: perché non caricare l'intero catalogo nel prompt e farla finita?

La risposta non è "perché RAG è meglio". La risposta è: dipende dal catalogo, dal caso d'uso, e da quanto ti interessa il controllo sui risultati.

Ho costruito tre sistemi RAG per cataloghi prodotto nell'ultimo anno. Nessuno dei tre avrebbe funzionato meglio con un semplice context stuffing. Ma non perché RAG sia sempre la risposta - perché questi casi specifici avevano caratteristiche che lo rendevano la scelta corretta. In questo paper, analizzo onestamente quando RAG aggiunge valore e quando è overengineering.

2. Framework Decisionale: Quando RAG Ha Senso

Prima di descrivere le implementazioni, serve un framework onesto per decidere se RAG è la scelta giusta. L'ho distillato dall'esperienza con questi tre progetti e da un paio di altri dove ho deciso di non usarlo.

2.1 RAG è giustificato quando:

• Il catalogo supera i 500-1000 prodotti - sotto questa soglia, il context stuffing costa meno in complessità di quanto RAG costi in infrastruttura
• La ricerca è multilingue con entità specifiche del dominio - gli LLM generalisti non mappano "cromato satinato" a "satin chrome" senza supporto specifico
• Servono risposte sotto i 200ms - il context stuffing con 100K+ token aggiunge latenza significativa alla generazione
• Il catalogo cambia frequentemente - reindicizzare un vector store è incrementale, riscrivere prompt con l'intero catalogo no
• Serve tracciabilità - sapere esattamente quale prodotto ha contribuito alla risposta, con score di rilevanza

2.2 RAG è overengineering quando:

• Il catalogo ha meno di 200-300 prodotti - caricali nel prompt, fine
• Le query sono semplici e in una sola lingua - una ricerca full-text con pg_trgm o Elasticsearch è sufficiente
• Non serve generazione, solo recupero - stai costruendo un motore di ricerca, non un sistema RAG
• Il budget non giustifica l'infrastruttura - pgvector, embedding API, Redis cache, tutto ha costi operativi
• Il team non ha competenze di ML ops - un sistema RAG in produzione richiede monitoraggio degli embeddings, drift detection, re-indexing periodico

3. Implementazione #1: Catalogo Arredamento Multilingue

3.1 Il problema

Un catalogo di arredamento con prodotti in italiano e inglese. L'utente cerca in una lingua, i prodotti hanno metadati nell'altra. "Divano angolare grigio" deve trovare il prodotto catalogato come "Corner sofa, grey". La ricerca full-text fallisce qui - non per limiti di PostgreSQL, ma perché le parole sono diverse.

3.2 Architettura

Query utente (IT o EN)
    ↓
Language Detection (langdetect)
    ↓
Entity Extraction (60+ mappings dominio-specifici)
    ↓
Query Translation (IT ↔ EN)
    ↓
Embedding (Jina v3, 1024-dim, sulla traduzione EN)
    ↓
┌────────────────────┐
│  Hybrid Search     │
│  Vector: 70%       │
│  Full-text: 30%    │
│  RRF k=60          │
└────────────────────┘
    ↓
Risultati ranked con score di rilevanza

3.3 Scelte tecniche e motivazioni

Embedding model: Jina v3 (1024 dimensioni)

Ho scelto Jina v3 per due motivi: supporto multilingue nativo (italiano e inglese con lo stesso modello) e dimensionalità a 1024 che bilancia qualità semantica e costi di storage/query su pgvector. Con 10.000 prodotti e indice HNSW, le query restano sotto i 50ms.

Hybrid search: perché 70/30 e non 50/50

Il peso 70% vettoriale / 30% keyword non è arbitrario. Il Reciprocal Rank Fusion con k=60 combina i risultati delle due ricerche. Nel dominio dell'arredamento, la similarità semantica è più importante della corrispondenza esatta perché gli utenti descrivono i prodotti con vocabolario diverso da quello del catalogo. "Poltrona per leggere" non contiene nessuna keyword del prodotto "Reading Chair, Fabric, Ergonomic" - solo il vettore li collega.

Il 30% keyword serve come guardrail: quando l'utente specifica un codice prodotto, una dimensione esatta, o un nome brand, la corrispondenza esatta deve vincere sulla similarità semantica.

Entity extraction: 60+ mapping di dominio

Questa è la parte che ha richiesto più lavoro manuale e che ha prodotto il miglioramento più significativo. Ho costruito un dizionario di 60+ termini specifici dell'arredamento con la loro traduzione: divano→sofa, cromato→chrome, angolare→corner, bagno→bathroom. Quando l'utente cerca "mobile bagno sospeso", l'entity extractor identifica tre entità (mobile=furniture, bagno=bathroom, sospeso=wall-mounted) e le usa per arricchire la query.

Senza questo layer, la precisione della ricerca cross-language scendeva del 30-35%. Gli embeddings generalisti non mappano terminologia tecnica di nicchia con sufficiente precisione.

Cache: Redis con TTL 5 minuti

Le query nel dominio arredamento hanno distribuzione long-tail ma con head concentrato. "Divano" e "tavolo" coprono il 40% delle ricerche. Il caching con TTL di 5 minuti riduce le chiamate all'embedding API del 60% in un giorno tipico, mantenendo i risultati freschi per aggiornamenti catalogo.

4. Implementazione #2: Catalogo B2B con Configurazione Prodotto

4.1 Il problema

Un catalogo B2B dove il prodotto non è un singolo articolo ma una configurazione modulare. Ogni codice prodotto si decompone in un sistema a componenti dove ogni segmento rappresenta una parte distinta. Ogni componente ha decine di varianti di finitura con matrici di prezzo diverse. Il catalogo copre più collezioni con centinaia di combinazioni possibili.

Qui il retrieval classico non basta. Non cerchi "un prodotto cromato" - cerchi una configurazione specifica con materiali, finiture e compatibilità precise. È un problema di ricerca semantica + logica di business.

4.2 Architettura

Query utente (codice prodotto o descrizione)
    ↓
RAG Agent → interpreta codice prodotto
    ↓
Decomposizione componenti
    ↓
Per ogni componente:
  → Retrieval varianti disponibili
  → Matrice prezzi
  → Compatibilità
    ↓
Configuratore visuale
    ↓
Generazione preventivo PDF

4.3 Lezione chiave: RAG è solo il retrieval layer

Questo progetto ha chiarito un punto che molti tutorial RAG omettono: il retrieval è solo il primo step. Dopo aver trovato il prodotto giusto, serve un layer di business logic che gestisca compatibilità tra varianti, matrici di prezzo, e regole di configurazione.

Il RAG agent interpreta la query e trova il prodotto nel catalogo. Ma il preventivo finale richiede logica deterministica: certe finiture costano il 40% in più su tutti i componenti, e non tutte le varianti sono compatibili tra loro. Questa logica non è compito dell'LLM - è codice.

Errore comune: delegare logica di business all'LLM perché "è più facile". No. Il modello allucina sui prezzi, inventa compatibilità, e ogni errore in un preventivo B2B è un danno economico reale. Il RAG trova il prodotto. Il codice genera il preventivo.

4.4 Data extraction: crawl4ai per i dati di catalogo

Un sotto-problema era popolare il database delle varianti disponibili per ogni prodotto. Questa informazione era sul sito del produttore, ma non in un formato strutturato. Ho usato crawl4ai per fare scraping delle pagine prodotto ed estrarre la mappatura prodotto→varianti via regex sui link di navigazione.

Il risultato è un CSV strutturato che mappa ogni codice prodotto alle sue varianti. Niente LLM, niente embeddings - solo uno scraper mirato e una regex. Non tutto deve essere AI.

5. Implementazione #3: Documenti Non Strutturati con Knowledge Graph

5.1 Il problema

Documenti PDF, immagini scannerizzate, e file di testo in vari formati. Non un catalogo strutturato ma un archivio eterogeneo: contratti, specifiche tecniche, report, manuali. Sei tipi di documento (legale, tecnico, finanziario, medico, accademico, generico) con esigenze di retrieval diverse.

5.2 Perché knowledge graph e non vector search

Per documenti non strutturati, la similarità vettoriale da sola è insufficiente. Un contratto che menziona "penale di €50.000 per ritardo consegna" e un altro che dice "clausola risarcitoria: cinquantamila euro per inadempimento tempistiche" sono semanticamente vicini - ma la relazione che conta è che entrambi si riferiscono allo stesso progetto con lo stesso fornitore.

LightRAG costruisce un knowledge graph dalle entità estratte dai documenti: aziende, persone, importi, date, clausole. Le query attraversano il grafo seguendo relazioni, non solo similarità vettoriale. "Tutti i contratti con penali sopra €10.000 per il fornitore X" richiede graph traversal, non cosine similarity.

5.3 Stack e pipeline

5.4 Adattamento per tipo di documento

Un aspetto che ha migliorato significativamente la qualità delle risposte: prompt diversi per tipi di documento diversi. Quando il sistema sa che sta lavorando con contratti legali, il prompt enfatizza precisione terminologica e citazione delle clausole. Per documenti tecnici, enfatizza specifiche numeriche e tolleranze.

Non è una feature sofisticata - è un parametro che cambia il system prompt. Ma la differenza nella qualità percepita è enorme. Un documento legale analizzato con prompt generico produce risposte vaghe. Lo stesso documento con prompt legale produce citazioni precise con riferimenti alle sezioni.

6. Confronto tra le Tre Implementazioni

7. Il Vero Competitor di RAG nel 2026: Context Stuffing e Grounding

Parliamo dell'elefante nella stanza. Google Gemini offre grounding nativo: colleghi il tuo data store e il modello cerca da solo. OpenAI ha file search integrato negli Assistants. Claude con 1M di context può ingerire un catalogo intero senza bisogno di chunking, embedding, o vector store.

Se fossi un entusiasta RAG, farei finta che queste alternative non esistano. Invece le uso. E onestamente, per certi casi d'uso sono migliori.

7.1 Quando il context stuffing vince

• Catalogo piccolo (< 500 prodotti): carichi tutto nel prompt, risposte immediate, zero infrastruttura
• Prototipazione: quando devi validare un'idea, un vector store è overhead che rallenta l'iterazione
• Query che richiedono ragionamento su tutto il catalogo: "qual è il prodotto più economico in ogni categoria" - serve visione globale, non retrieval puntuale

7.2 Quando RAG vince ancora

• Scale: con 10.000+ prodotti, il context stuffing diventa costoso e lento - il token cost non è trascurabile quando moltiplichi per migliaia di query/giorno
• Precisione: il retrieval con score ti dice quanto è sicuro il match - il context stuffing no
• Tracciabilità: in un sistema RAG sai esattamente quale chunk ha generato la risposta - fondamentale per debug e compliance
• Latenza: cercare in un indice vettoriale è ordini di grandezza più veloce che processare 100K+ token di contesto
• Aggiornamenti incrementali: aggiungi un prodotto, aggiorni un embedding - non ricostruisci l'intero prompt
• Privacy e controllo: i dati restano nel tuo database, non transitano interamente attraverso API di terze parti ad ogni query

7.3 La mia posizione

RAG nel 2026 non è più una necessità tecnica. È una scelta architetturale. La differenza è importante. Nel 2024 non avevi alternative reali - le context window erano troppo piccole. Oggi hai alternative. Scegli RAG quando ti serve controllo, scala, e tracciabilità. Scegli il context stuffing quando ti serve semplicità e velocità di sviluppo.

L'errore che vedo fare più spesso è costruire un sistema RAG perché "è la best practice" - senza chiedersi se il caso d'uso lo giustifica. L'altro errore, simmetrico, è scartare RAG perché "i modelli ora hanno context grandi" - ignorando che il costo, la latenza, e il controllo non scalano linearmente con la context window.

8. Pattern e Anti-Pattern dai Tre Progetti

8.1 Pattern che hanno funzionato

• Hybrid search sempre: il puro vector search perde su query con codici prodotto, dimensioni esatte, o nomi brand. Il 30% keyword è un guardrail essenziale.
• Entity extraction di dominio: 80 mapping manuali hanno migliorato la precisione più di qualsiasi ottimizzazione sugli embeddings. Il dominio conta più dell'algoritmo.
• Separare retrieval da business logic: il RAG trova, il codice decide. Mai delegare calcoli, compatibilità o prezzi all'LLM.
• Cache aggressiva sulle query frequenti: distribuzione Zipf - il 20% delle query copre il 60% del traffico.
• Prompt per tipo di documento: un parametro che cambia il system prompt migliora la qualità percepita più di un embedding model migliore.

8.2 Anti-pattern da evitare

• RAG per cataloghi piccoli: sotto 200-300 prodotti, il context stuffing è più semplice e ugualmente efficace.
• Chunking aggressivo su dati strutturati: un prodotto è un'unità atomica - non spezzarlo in chunk. Il chunking serve per documenti lunghi, non per record di database.
• Fidarsi ciecamente degli embeddings generalisti per terminologia tecnica: "cromato satinato" e "satin chrome" sono lontani nello spazio vettoriale di un modello generico.
• Ignorare il cold start: la prima query dopo il deploy richiede warm-up dell'indice - pianifica un pre-heating.
• Delegare prezzi e calcoli al modello: un'allucinazione su un preventivo B2B non è un bug - è un danno economico.

9. Costi Reali di un Sistema RAG in Produzione

Un aspetto che i tutorial raramente coprono: quanto costa mantenere un sistema RAG in produzione. Non il costo di sviluppo - quello è un investimento una tantum. Il costo operativo mensile per il sistema di arredamento, che è il più maturo dei tre:

Per confronto, il context stuffing dello stesso catalogo costerebbe circa $0.10-0.15 per query (con un catalogo di ~50K token). A 50K query/mese, sono $5.000-7.500. A 1K query/mese, sono $100-150 - paragonabile al costo RAG ma senza infrastruttura.

Il punto di break-even è intorno alle 500-1.000 query/mese, a seconda del modello scelto per il context stuffing. Sotto questa soglia, il context stuffing è probabilmente più economico se consideri il costo totale (infrastruttura + manutenzione + monitoring). Sopra, RAG diventa progressivamente più conveniente.

10. Cosa Porto a Casa da Questi Tre Progetti

Tre progetti RAG, tre domini diversi, una lezione comune: la tecnologia è matura, ma non è universale. RAG è uno strumento, non una religione.

Il sistema di arredamento ha dimostrato che l'hybrid search con entity extraction di dominio produce risultati che il puro vector search non raggiunge. Il progetto B2B ha dimostrato che RAG è solo il layer di retrieval - la business logic deve essere codice deterministico, non prompt. I documenti hanno dimostrato che per relazioni complesse, i knowledge graph attraversano il limite dei vector store.

Nel 2026, la domanda non è più "devo usare RAG?" ma "quale layer del mio sistema ha bisogno di retrieval semantico?" Rispondi a questa domanda con onestà - misurando costi, complessità, e alternative - e avrai la risposta giusta. Che sia RAG, context stuffing, o una ricerca full-text con PostgreSQL.

L'errore più costoso non è scegliere la tecnologia sbagliata. È scegliere la tecnologia alla moda senza chiedersi se serve.