RAG: come costruire una base di conoscenza che renda il vostro chatbot davvero utile

Nel 2026, la grande maggioranza dei chatbot IA implementati in azienda si basa su RAG (Retrieval-Augmented Generation). Eppure, nei nostri audit, constatiamo un enorme divario tra i progetti che funzionano e quelli che vegetano: non è quasi mai l'LLM a creare problemi. È la base di conoscenza. Uno stesso GPT-4 Turbo o uno stesso Mistral Large 2, collegato a due pipeline RAG diverse, può produrre un assistente brillante o un generatore di allucinazioni cortese. La differenza si gioca al 90% nell'ingegneria del retrieval.

Questo articolo è una guida tecnica per costruire un RAG che renda il vostro chatbot davvero utile. Dettagliamo sei passi: audit delle fonti, chunking, embedding, base vettoriale, reranking, valutazione. Ogni passo comporta un arbitraggio concreto con trade-off documentati e numeri tratti dai nostri progetti. L'obiettivo: darvi le domande giuste da porre prima di firmare un budget RAG, e i segnali giusti per rilevare che un progetto esistente sta deragliando.

Perché il RAG è diventato il passo decisivo nel 2026

Gli LLM di frontiera hanno fatto passi da gigante, ma restano fondamentalmente ignari del vostro business. Un assistente interno utile deve rispondere sulla base della vostra documentazione, delle vostre procedure, dei vostri contratti, dei vostri prodotti. Il fine-tuning resta pesante, costoso e poco agile di fronte a fonti che evolvono ogni settimana. Il RAG si è imposto perché offre il giusto compromesso: iniettare il contesto pertinente al momento della richiesta, senza toccare il modello, con un aggiornamento quasi in tempo reale possibile.

Ma il RAG è un sistema complesso a più livelli. Ogni livello può degradare l'insieme. Una fonte mal ripulita, un chunking grossolano, un embedding inadatto all'italiano, una base vettoriale mal configurata, l'assenza di reranking: la risposta finale sarà deludente anche se l'LLM è eccellente. Per questo trattiamo sempre il RAG come una disciplina ingegneristica a sé stante, con il suo ciclo di misurazione e miglioramento continuo.

1. Verificare e ripulire le fonti

Tutto inizia dal corpus. Un chatbot RAG non inventa nulla: seleziona, riformula e sintetizza ciò che gli date. Se la documentazione interna contiene tre versioni contraddittorie di una procedura, il RAG ne restituirà casualmente una delle tre. Se esiste un PDF obsoleto del 2019 dimenticato in uno SharePoint, finirà per citarlo. Il nostro primo passo, sistematico, è un audit documentale: mappare le fonti, identificare i duplicati, marcare i contenuti obsoleti, individuare le contraddizioni.

Concretamente, procediamo per lotti: 200-500 documenti passati in rassegna da un binomio business-tech, con una griglia di qualifica (fa autorità? aggiornato? coerente?). Questo lavoro è ingrato ma determinante. I progetti che saltano questa fase non recuperano mai il ritardo: accatastano livelli tecnici per compensare un corpus malato.

• Eliminare i duplicati esatti e quasi duplicati
• Marcare i contenuti obsoleti con una data di scadenza
• Risolvere le contraddizioni con il business (validazione esplicita)
• Normalizzare i formati (Markdown pulito piuttosto che PDF scansionati)

2. Scegliere una strategia di chunking

Il chunking è l'operazione che taglia ogni documento in frammenti indicizzabili. Tre parametri contano: la dimensione, l'overlap e la strategia. Troppo piccolo (sotto i 200 token), ogni chunk perde il suo contesto e il retrieval restituisce frammenti incoerenti. Troppo grande (oltre i 1500 token), i chunk diventano sfocati e l'embedding fa la media di troppe idee diverse. La nostra forbice di default: 512 token con un overlap di 64-128 token. Ma questo valore non è mai sacro: lo calibriamo sul golden dataset.

La strategia conta quanto la dimensione. Un chunking fixed (ogni N token) è rapido da implementare ma brutale sui documenti strutturati. Un chunking semantic (basato su embedding di frasi) rispetta meglio le unità di senso. Un chunking structure-aware (che sfrutta i tag HTML, i titoli Markdown, la struttura PDF) è quasi sempre superiore su documentazione tecnica. Per un sito e-commerce, una scheda prodotto deve restare un chunk. Per un manuale tecnico, ogni sezione H2 o H3 forma un chunk naturale.

3. Selezionare gli embedding

Gli embedding trasformano ogni chunk in vettore. È l'organo di ricerca del RAG. La scelta dipende da tre criteri: la qualità sulla vostra lingua (l'italiano resta meno coperto dei modelli puramente anglofoni), la dimensione (512-3072 a seconda dei modelli, impatto diretto su costo di storage e latenza) e il costo. I nostri quattro candidati ricorrenti nel 2026: OpenAI text-embedding-3-large (3072 dimensioni, qualità multilingue eccellente, ~0,13 € per milione di token), Cohere Embed v3 (1024 dimensioni, ottimo multilingue, supporta la ricerca semantica tipizzata), BGE-M3 open-source (1024 dimensioni, performance notevole, self-hostable), e i modelli specializzati per lingua come Solon o CamemBERT-large per corpus molto francofoni.

Il nostro metodo: testare almeno due modelli di embedding sul golden dataset del cliente. Misurare recall@5 e recall@10. Lo scarto è talvolta spettacolare — abbiamo visto BGE-M3 battere OpenAI su un corpus giuridico molto specifico, e l'inverso su un corpus tecnico multilingue. Nessun modello è universalmente migliore.

4. Scegliere la base vettoriale

La base vettoriale memorizza gli embedding ed esegue la ricerca per similarità (coseno, dot-product, L2). Dominano cinque opzioni. Pinecone managed resta imbattibile in time-to-market: poche righe di codice, scaling automatico, ma costo ricorrente e dipendenza da un fornitore USA. Qdrant open-source, self-hostable, performante, scritto in Rust: la nostra scelta di default quando conta la sovranità. pgvector se avete già Postgres: non serve aggiungere un servizio, perfetto fino a qualche milione di vettori. Weaviate per gli schemi ricchi e la ricerca ibrida avanzata. Chroma per i POC rapidi in locale.

Costo indicativo: 50-500 € al mese a seconda del volume e della modalità (managed vs self-host). Oltre i 10 milioni di vettori o con forti vincoli di sovranità, il self-host diventa quasi obbligatorio. Sconsigliamo di concatenare gli strumenti: un solo vector store ben padroneggiato vale più di tre mal integrati.

5. Implementare il reranking

Il reranking è la fase più sottovalutata del RAG. Il retrieval iniziale restituisce tipicamente un top-20 o top-50 di chunk candidati per similarità vettoriale. Ma la similarità di embedding è un'approssimazione grossolana della pertinenza reale. Un reranker — modello più pesante, tipo cross-encoder — riordina questi candidati valutando finemente ogni coppia (domanda, chunk). Sui nostri progetti, aggiungere un reranking porta il 10-15% di precisione in più sul top-3, che è esattamente ciò che verrà iniettato nel prompt finale.

Dominano due opzioni. Cohere Rerank v3 è un servizio managed eccellente, multilingue, circa 1 € per 1 000 richieste. BGE-reranker è open-source, self-hostable, quasi altrettanto performante, ideale in contesto sovrano. L'investimento è minimo — qualche ora di integrazione, qualche decina di millisecondi di latenza — per un guadagno di qualità largamente superiore a un cambio di LLM.

6. Valutare in continuo

Un RAG senza valutazione è una scatola nera che deriva silenziosamente. Il nostro standard: costruire fin dall'inquadramento un golden dataset interno di 50-100 coppie domanda-risposta validate dal business, e misurare a ogni iterazione le metriche strutturanti con RAGAS: faithfulness (la risposta aderisce alle fonti?), answer relevance (risponde alla domanda?), context precision, context recall. Queste quattro metriche tracciano l'intera pipeline e permettono di localizzare precisamente dove appare una regressione.

A ciò si aggiunge la valutazione in produzione: feedback utente (pollice su/giù con commento), monitoring delle domande senza risposta soddisfacente, A/B testing tra due configurazioni (ad esempio chunking 512 vs 768, con o senza reranker). LangChain e LlamaIndex offrono ormai hook di strumentazione nativi per queste misurazioni, e strumenti come Langfuse o Phoenix di Arize li aggregano in modo pulito.

Le trappole che fanno fallire un RAG

Quattro errori tornano sistematicamente nei nostri audit. Primo, un chunking troppo fine o troppo ampio, definito una volta per tutte senza mai ricalibrarlo. Secondo, embedding scelti di default senza test sull'italiano, mentre la lingua fa una differenza importante su certi corpus. Terzo, l'assenza di reranking — fase più redditizia della pipeline, eppure regolarmente omessa. Quarto, l'assenza di una pipeline di aggiornamento: la base di conoscenza è congelata alla data del deploy e il chatbot risponde a domande su prodotti che non esistono più.

A queste trappole tecniche si aggiunge una trappola metodologica: giudicare un RAG « a occhio ». Senza golden dataset, senza RAGAS, senza A/B, qualunque discussione sulla qualità è soggettiva e quindi ingestibile. Imponiamo la misurazione fin dalla prima iterazione, perché si migliora solo ciò che si misura.

E adesso?

Un RAG performante non è un progetto di qualche giorno. È un sistema che si progetta, si misura e si mantiene. Ma è proprio questo investimento a fare la differenza tra un chatbot che i vostri team usano davvero e un gadget abbandonato dopo tre settimane. In DevHighWay, trattiamo il RAG come la colonna vertebrale di ogni chatbot che consegniamo: fonti verificate, chunking calibrato, embedding testati, reranker in piedi, valutazione continua.

• Contattateci per un inquadramento RAG (workshop di 1 giorno, piano di battaglia tecnico quantificato)
• Consultate le nostre tariffe — i nostri pacchetti includono la manutenzione e la valutazione continua del RAG
• Il nostro audit può coprire anche la visibilità del vostro assistente sul fronte SEO e GEO

Se ricorderete una sola idea di questo articolo: la qualità di un chatbot RAG non si gioca nella scelta dell'LLM, si gioca nell'ingegneria del retrieval. I sei passi descritti qui non sono opzionali, formano un sistema. Saltarne uno significa accettare un degrado sistemico della qualità finale. Trattarli seriamente, con metodo e misurazione, significa darsi i mezzi per consegnare un assistente che i vostri team useranno ogni giorno — e che, nel tempo, diventerà un asset strategico della vostra organizzazione.