RAG in produzione: cosa si rompe davvero quando iniziano a chiedere clienti veri

Una demo funzionante di Retrieval-Augmented Generation si costruisce in un pomeriggio. Si generano gli embedding di qualche documento, si mettono in un archivio vettoriale, si recuperano i cinque frammenti più simili per similarità coseno e li si incolla nel prompt. Risponde alle domande. In una registrazione dello schermo sembra magia.

Poi lo metti davanti a clienti veri, e la distanza si apre.

Qualcuno scrive nella terza lingua che supporti. Qualcuno chiede di una policy che sul tuo stesso sito esiste in due versioni contraddittorie. Qualcuno chiede una cosa che i tuoi contenuti davvero non coprono, e il sistema risponde comunque: fluido, sicuro di sé, sbagliato. Venti persone scrivono contemporaneamente mentre è in corso una nuova scansione. Un PDF scansionato anziché digitato diventa rumore di recupero che avvelena silenziosamente tutte le risposte vicine.

Niente di tutto questo compare in una demo, perché una demo usa documenti puliti, una lingua, un utente e domande di cui chi l'ha costruita conosce già le risposte. Tutto ciò che nel RAG costa caro vive nella distanza tra queste due situazioni.

Questa guida parla di quella distanza. Dà per scontato che tu sappia cos'è il RAG: se non lo sai, parti dalla nostra spiegazione di cos'è un chatbot RAG e come funziona, poi torna qui. Ciò che segue è lo strato superiore: l'ingegneria che decide se un sistema di recupero sopravvive al contatto con utenti reali.

Ogni volta che le finestre di contesto crescono, qualcuno dichiara il RAG superato. Non è successo, e le ragioni sono strutturali, non temporanee.

Il contesto utilizzabile è più piccolo di quello dichiarato. Un modello che accetta 200.000 token non ragiona altrettanto bene su tutti i 200.000. L'effetto è ben documentato: il lavoro "Lost in the Middle" di Liu et al. (2023) ha mostrato l'accuratezza calare per le informazioni sepolte a metà di input lunghi, e ogni generazione successiva di modelli a contesto lungo è arrivata con una versione dello stesso avvertimento. La qualità si degrada prima del limite duro. E la base di conoscenza reale di un'azienda media non è di 200 pagine: sono decine di migliaia.

Il fine-tuning cambia il comportamento, non la conoscenza. È l'equivoco più costoso del settore. Il fine-tuning è ottimo per insegnare a un modello un formato, un tono o uno schema di ragionamento. È un modo debole e inaffidabile per insegnargli dei fatti, e si degrada male quando i fatti cambiano — cosa che succede ogni settimana su prezzi, policy e scorte.

Il costo scala nella direzione sbagliata. Infilare l'intero corpus in ogni richiesta significa pagare l'intero corpus a ogni domanda. Recuperare significa pagare le poche migliaia di token pertinenti. A qualsiasi volume reale di messaggi, quella differenza è tutto il margine.

La tracciabilità è un requisito, non una funzionalità. In finanza, sanità e ambito legale, una risposta senza fonte tracciabile è inutilizzabile. Il recupero produce quella traccia gratis, perché il sistema sa già da quale documento arriva ogni passaggio.

La domanda interessante quindi non è più se recuperare. È perché tanti sistemi di recupero lo facciano male.

La causa più comune di risposte sbagliate non è il modello, né gli embedding, né il database vettoriale. È il corpus.

Abbiamo visto la base di conoscenza di un cliente in cui circa metà dei documenti erano quasi-duplicati dell'altra metà: la stessa policy ripubblicata con piccole differenze di formattazione su un sito marketing, un help center e un PDF archiviato. Il recupero restituiva diligentemente cinque frammenti che erano cinque copie dello stesso paragrafo, così il modello vedeva una fetta ristretta di evidenze invece di cinque prospettive, e il budget top-k se ne andava in ridondanza. Sistemarlo è stato lavoro manuale e per nulla glamour di data pipeline. Eppure ha migliorato la qualità delle risposte più di qualsiasi messa a punto del recupero fatta quel mese.

I recidivi:

• PDF scansionati e danni da OCR. Un testo che all'occhio umano si legge bene può essere strutturalmente sbriciolato: ordine delle colonne mescolato, tabelle appiattite in zuppa di parole. Gli embedding di testo sbriciolato vengono recuperati in modo imprevedibile.
• Boilerplate e banner di consenso. Scansiona un sito in modo ingenuo e ogni pagina si porterà dietro lo stesso avviso cookie, lo stesso menu, lo stesso footer. Ora tutti i frammenti condividono un lungo prefisso identico, e la similarità semantica tra pagine senza alcun rapporto aumenta. Per questo il nostro crawler rimuove consenso e cornice prima di indicizzare qualsiasi cosa.
• Muri di login e pagine vuote. Una pagina di accesso contiene testo, quindi una pipeline ingenua la ingerisce. Non aggiunge nulla e diluisce tutto.
• Contraddizioni che nessuno ha notato. Due pagine indicano finestre di reso diverse. Il recupero le trova entrambe. Il modello ne sceglie una. Qualunque scelga, a qualcuno verrà detta la cosa sbagliata.

La regola pratica: un controllo di qualità va messo prima dell'indicizzazione, in esattamente un punto del codice, applicato da ogni percorso che può aggiungere contenuti. Quando le regole di ingestione vivono in tre posti diversi, divergono, e la differenza di qualità tra il tuo onboarding e la tua riscansione diventa un mistero che nessuno riesce a riprodurre. Per la versione pratica, vedi la nostra guida per costruire una base di conoscenza pulita.

Una singola ricerca vettoriale densa è la prima bozza del recupero. In produzione il recupero è una pipeline di quattro o cinque stadi, e ognuno risolve una modalità di guasto che gli altri non raggiungono.

Espansione della query. Le query reali sono corte, con errori di battitura e piene di gergo interno. Espandere la query con sinonimi e sigle sciolte prima di generarne l'embedding migliora il recall in modo misurabile, soprattutto per le domande di due o tre parole che dominano il traffico reale.

Ricerca ibrida: densa più sparsa. Gli embedding densi colgono il significato ma mancano i token esatti: SKU, codici di errore, numeri di modello, cognomi. La ricerca per parole chiave (nel nostro caso BM25 su un tsvector Postgres) colpisce esattamente quelli e manca le parafrasi. Eseguirle entrambe e fondere i risultati con la Reciprocal Rank Fusion è lo standard di produzione, non un'ottimizzazione.

Un dettaglio che pesa più di quanto dovrebbe: la ricerca per parole chiave dipende dalla lingua. Postgres riduce "prezzi" alla radice solo se gli dici che il testo è in italiano. Turco, tedesco, spagnolo, francese, italiano e portoghese hanno ciascuno bisogno della propria configurazione, e le lingue senza stemmer integrato — giapponese, coreano, cinese — richiedono un fallback deliberato e non accidentale. Un sistema RAG multilingue che applica lo stemming inglese a ogni query perde silenziosamente recall in tutte le altre lingue. Se servi più di un mercato, leggi insieme a questa sezione la nostra guida ai chatbot multilingue.

Reranking. La fusione ti lascia venti o trenta candidati plausibili. Un reranker cross-encoder valuta ciascuno rispetto alla domanda reale e porta abitualmente il passaggio davvero corretto dalla quindicesima posizione ai primi tre. Se il tuo sistema "cita sempre una pagina quasi giusta", il primo posto da guardare è lo stadio di reranking mancante.

Cache, con attenzione. Domande identiche non dovrebbero rieseguire l'intera pipeline. Ma metti in cache il risultato del recupero, con chiave query più top-k, non la risposta generata: altrimenti servirai una risposta obsoleta dopo che il documento sottostante è stato aggiornato.

Ogni sistema RAG serio valuta il proprio recupero prima di generare e usa quel punteggio per istruire il modello su quanto fidarsi del contesto: rispondere direttamente, rispondere con riserva, oppure declinare e passare a una persona. È la più importante difesa contro le allucinazioni che esista.

È anche il parametro che più probabilmente è sbagliato, perché i valori predefiniti di solito sono inventati anziché misurati.

Ecco un errore da cui vale la pena imparare: è il nostro. La nostra soglia di "confidenza alta" era fissata a 0,82 di similarità coseno, un numero che suona adeguatamente severo. Poi l'abbiamo verificata sul traffico reale e abbiamo scoperto che meno del 2% delle risposte reali la superava. Le corrispondenze semantiche dense raramente vanno oltre circa 0,80, anche quando il passaggio recuperato è ovviamente ed esattamente quello giusto. Al modello veniva quindi detto "questo contesto è solo parziale" su quasi ogni domanda, e si cautelava: risposte corrette avvolte in un'incertezza inutile. Il recupero andava bene. A essere sbagliato era il metro.

La correzione non è stata allentare tutto. Abbiamo estratto un campione di conversazioni reali nella fascia ambigua e le abbiamo lette: tra 0,64 e 0,68 le risposte erano specifiche e corrette, citavano limiti di piano e regole esatti. Ma i vuoti autentici — domande su un'integrazione che non supportiamo — ottenevano punteggi nello stesso intervallo e si cautelavano giustamente. Così abbiamo abbassato l'asticella alta a un livello che le corrispondenze reali possono raggiungere, tenuto la fascia intermedia ambigua come "parziale" e lasciato esattamente dov'era la protezione inferiore del "non inventare".

Le lezioni trasferibili: calibra le soglie sulla tua distribuzione, non sull'intuito; leggi le conversazioni reali nella fascia che stai regolando, perché i punteggi aggregati nascondono la differenza tra una buona risposta e un errore ben valutato; e rendi ogni soglia una variabile d'ambiente, così una calibrazione sbagliata è un rollback di un minuto anziché un deploy.

Il chunking sembra una decisione di formattazione. In realtà è una decisione di recupero, ed è da lì che nasce una quota sorprendente delle lamentele del tipo "il bot non trova una cosa che nella nostra documentazione c'è di sicuro".

Tagliare a lunghezza fissa ogni 500 token spezzerà una tabella a metà, separerà un titolo dal paragrafo che introduce e dividerà una procedura numerata su due frammenti in modo che nessuno dei due sia utilizzabile da solo. Una suddivisione consapevole della struttura — prima rispettare titoli e confini di paragrafo, poi unire verso una dimensione obiettivo, poi spezzare i segmenti lunghi ai confini di frase — costa un giorno di implementazione e si ripaga subito. La nostra pipeline punta a circa 800 token per frammento con 200 di sovrapposizione: un punto di partenza ragionevole per contenuti aziendali prevalentemente discorsivi.

Il problema più sottile è che un frammento, una volta isolato, perde il contesto che lo rendeva significativo. "La spedizione standard richiede 3-5 giorni lavorativi" è un bersaglio di recupero inutile se il frammento non dice di chi è la spedizione, quale area o quale linea di prodotto. Recuperato da solo, il modello può applicarlo a una domanda completamente diversa.

La soluzione è arricchire ogni frammento con la propria provenienza prima di generarne l'embedding — titolo del documento, intestazione di sezione, fonte — così il testo incorporato porta con sé il contesto che un lettore umano avrebbe avuto dalla pagina circostante. Anthropic ha reso popolare una versione di questa idea con il nome di "contextual retrieval", riportando un calo sostanziale dei fallimenti di recupero. E non serve un passaggio con un LLM perché ne valga la pena: un prefisso deterministico costruito dai metadati del documento cattura gran parte del beneficio a costo marginale zero — è ciò che eseguiamo in produzione.

Un avvertimento dall'esperienza: se cambi strategia di chunking o di contestualizzazione, ti sei comprato una migrazione. Ogni frammento esistente è stato incorporato con lo schema vecchio. Pianifica una re-indicizzazione mirata, documento per documento, mai un re-embedding massivo e alla cieca di un corpus in produzione.

I team discutono di qualità del recupero. Ciò che manda giù i sistemi, però, è l'affidabilità.

L'ingestione è un processo lungo, a più stadi e in parte esterno: scaricare, estrarre, suddividere, incorporare (una chiamata API a pagamento che può incontrare limiti di frequenza), scrivere, marcare come completato. Tutto ciò che gira per minuti attraversando un confine di rete verrà interrotto, e le interruzioni non sono rare.

Il nostro guasto più istruttivo è stato silenzioso. Un'utente ha avviato la scansione del proprio sito e poi è passata a un'altra pagina. La funzione serverless che gestiva la richiesta è stata uccisa a metà volo: dopo che frammenti ed embedding erano stati scritti, ma prima che il documento venisse marcato come processato. Nessuna eccezione. Nessun errore nel monitoraggio. Solo un documento completamente indicizzato ma mostrato in permanenza come "in indicizzazione", e un'utente che ha riscansionato lo stesso sito quattro volte in diciannove ore per far cambiare un'etichetta, e poi se n'è andata.

Quella classe di bug ci ha insegnato tre invarianti da rubare:

• Ordina le scritture in modo che la verità visibile all'utente venga fissata per prima. Alza il flag "processato" subito dopo che il contenuto è stato scritto in modo durevole; statistiche, invalidazione della cache e altra contabilità vengono dopo, ciascuna limitata nel tempo e best effort. Non lasciare mai un passo facoltativo tra il lavoro vero e il flag che lo registra.
• Rendi idempotente ogni handler dei job, poi rimetti in coda con generosità. Se un worker muore a metà, la scansione successiva deve poter rieseguire l'intero job in sicurezza. Gli handler che "cancellano e reinseriscono" rendono i retry gratuiti.
• Aggiungi una spazzata auto-riparante. Un job periodico che cerca documenti bloccati in uno stato incompleto e li rimette in coda trasforma un guasto permanente e visibile in un ritardo di pochi minuti. È l'intervento di affidabilità con il rendimento più alto in una pipeline RAG, e quasi nessuno lo costruisce prima di essersi scottato.

Sotto carico concorrente aggiungi anche l'infrastruttura noiosa: una coda vera al posto di promesse lanciate e dimenticate, limiti del pool di connessioni che tengano conto del fatto che le chiamate di embedding tengono aperte le connessioni, e isolamento per tenant perché la scansione da 900 pagine di un cliente non affami la chat dal vivo di tutti gli altri.

La qualità di un RAG non si valuta a occhio. Ogni team crede di poterlo fare, e ogni team sbaglia, perché la modalità di guasto di un RAG scadente è una risposta fluida, plausibile e ben formattata che però è falsa. Si legge esattamente come una buona.

Il setup minimo di valutazione è più piccolo di quanto si tema:

Un golden set. Da trenta a cento domande reali con risposte corrette note, prese dal tuo storico di assistenza e non inventate. Rieseguilo dopo ogni modifica a recupero, chunking, prompt o versione del modello. È un test di regressione e deve fallire rumorosamente.

Separa il punteggio del recupero da quello della risposta. Quando la qualità cala devi sapere se il passaggio giusto non è stato recuperato oppure è stato recuperato e ignorato. Le soluzioni sono completamente diverse, e un singolo punteggio end-to-end non le distingue.

Monitora nel tempo la distribuzione della confidenza. Uno spostamento nell'istogramma dei punteggi di recupero è un allarme precoce: di solito qualcuno ha aggiunto un grosso lotto di contenuti di bassa qualità, oppure il traffico si è spostato su temi che il tuo corpus non copre.

Tratta il "non lo so" come la tua telemetria più preziosa. Ogni risposta a bassa confidenza e ogni passaggio a un operatore è un vuoto di contenuto già etichettato. I team i cui assistenti migliorano visibilmente nei mesi sono quasi sempre quelli che leggono quell'elenco ogni settimana e scrivono la pagina mancante. La nostra guida agli analytics dei chatbot illustra le metriche che vale la pena seguire.

E misura la deflection con onestà. Una conversazione non è risolta perché il cliente ha smesso di scrivere; è risolta perché un'ora dopo non ti ha mandato un'email. Se la tua piattaforma non collega questi due eventi, stai ottimizzando un numero che ti lusinga.

Due sistemi RAG con architettura identica possono avere esito opposto nello stesso settore. La differenza di solito non è nella pipeline.

Il linguaggio di dominio è lavoro vero. Abbreviazioni sanitarie, nomi di strumenti finanziari, formati di citazione legale e convenzioni sugli SKU rompono il recupero generico in modi molto specifici. Un cliente della finanza chiede "il triennale" e intende un prodotto preciso; un embedding generico pensa al tempo. Si risolve con dizionari di sinonimi, filtri sui metadati e contenuti scritti anche per la macchina, non con un modello più grande.

La disciplina di perimetro batte la potenza. Il modo più rapido per distruggere la fiducia in un assistente è lasciargli rispondere a domande fuori da ciò che sa davvero. Un confine esplicito — questo agente risponde su prodotti, policy e documentazione nostri, e passa tutto il resto a una persona — riduce le risposte imbarazzanti più di qualsiasi miglioramento del recupero. È anche la correzione che abbiamo rilasciato dopo aver visto assistenti reali scivolare su terreno generico e inutile.

L'adozione è un requisito di lancio. Un assistente di cui nessuno ha parlato al team di assistenza finisce sabotato dal team di assistenza. Qualcuno deve farsi carico dei vuoti di contenuto, leggere gli inoltri e decidere cosa l'assistente può promettere.

La fiducia enterprise ha una checklist. Accesso basato sui ruoli perché il recupero rispetti chi sta chiedendo, audit trail che mostrino quale fonte ha prodotto quale risposta, residenza dei dati chiara, controlli di conservazione e una dichiarazione inequivocabile che le conversazioni dei clienti non vengono usate per addestrare modelli pubblici. Non sono funzionalità da aggiungere dopo una revisione di sicurezza: sono il motivo per cui quella revisione passa o non passa. La nostra guida a sicurezza e privacy dei chatbot elenca cosa verificare in un fornitore.

Se lo costruisci in casa, l'ambito onesto non è "un database vettoriale e un prompt". È un controllo di qualità sui contenuti, una pipeline di recupero a più stadi, soglie di confidenza calibrate, una coda di job con handler idempotenti e spazzata auto-riparante, un banco di valutazione e un ciclo di analytics — più l'esercizio continuo di tutto questo. Vale la pena quando la qualità del recupero è il tuo prodotto. È un pessimo uso dell'anno di un piccolo team quando il recupero è solo il mezzo per rispondere ai clienti.

Se compri, la checklist di questo articolo diventa la tua due diligence. Chiedi al fornitore: usate recupero ibrido o solo denso? C'è uno stadio di reranking? Come viene impostata la soglia del "non lo so" e posso cambiarla? Cosa succede a un documento se l'ingestione si interrompe a metà? Posso vedere quale fonte ha prodotto una certa risposta? Cosa succede alla ricerca per parole chiave nella mia lingua? Quali domande l'assistente non è riuscito a soddisfare la settimana scorsa? Un fornitore che non sa rispondere ha costruito una demo.

Questo è lo strato che Chatloom esiste per presidiare. La pipeline descritta in tutto l'articolo — chunking consapevole della struttura con arricchimento contestuale, espansione della query, recupero ibrido denso più sparso con stemming per lingua, fusione RRF, reranking cross-encoder, confidenza calibrata con un "non lo so" autentico, job di ingestione idempotenti con spazzata auto-riparante e una dashboard che mostra esattamente quali domande sono rimaste senza risposta — è ciò che gira dietro ogni agente della piattaforma, in dieci lingue, senza un team di ML dalla tua parte del tavolo.

Provalo oggi sui tuoi contenuti. Crea un account gratuito, incolla l'URL del tuo sito e guarda l'intero ciclo scorrere — scansione, controllo qualità, chunking, embedding, recupero ibrido — più o meno nel tempo che ti è servito per leggere questo articolo. Fagli le cinque domande che i tuoi clienti fanno davvero. Se le risposte poggiano sui tuoi contenuti e ammette ciò che non sa, hai la tua valutazione. Il piano gratuito non richiede carta di credito.

Preferisci prima i dettagli? Guarda come funziona il nostro motore RAG o leggi l'articolo pratico complementare su come addestrare un assistente sui tuoi dati.