La maggior parte dei tutorial RAG termina esattamente dove inizia la produzione. Si dividono i documenti in chunk da 512 token, si passano attraverso un singolo modello di embedding e si interroga un database vettoriale con un semplice recupero top-k. In una demo, questo sembra convincente. Chiedi al bot la politica aziendale sulle ferie e lui restituirà un paragrafo coerente. Tutti annuiscono. Purtroppo, le demo mentono.

La produzione espone ogni scorciatoia. I chunk a dimensione fissa tagliano i contratti legali nel mezzo delle clausole di indennizzo. La documentazione API si trasforma in un rumore sovrapposto che annega il segnale di cui hai realmente bisogno. La latenza aumenta finché gli utenti abbandonano la query prima che arrivi la risposta. Abbiamo sbattuto contro questo muro e abbiamo dovuto ricostruire tutto. Il nostro livello di recupero si è evoluto da "ricerca semantica e speranza" a una pipeline misurata e strumentata. Il risultato è stato un recall del 95% e una riduzione della latenza del 40%. Ecco cosa ha funzionato davvero.

Adatta la strategia di chunking al documento

Il default di 512 token persiste perché è facile, non perché sia corretto. Documenti diversi trasmettono il significato in modi diversi, e la tua strategia di chunking dovrebbe riflettere questo aspetto.

Per i contratti legali, usa il chunking ricorsivo che rispetti i confini strutturali. Il linguaggio legale è annidato. Una clausola dipende dalla sezione sovrastante, e un taglio fisso a metà frase distrugge la logica di un obbligo. Il chunking ricorsivo tenta prima di dividere in base ai separatori naturali — paragrafi, poi frasi — prima di imporre un limite di token. Questo mantiene intatte le clausole di indennizzo o di responsabilità.

Per la documentazione API, usa il chunking basato sulle funzioni. Gli sviluppatori non cercano paragrafi casuali; cercano endpoint, parametri e firme di errore. Un chunk dovrebbe contenere l'intera firma della funzione, la sua descrizione e lo schema di ritorno come un'unica unità logica. Se dividi quel blocco a metà, il sistema di recupero restituirà metà del contesto e il modello di generazione allucinerà il resto.

Per i ticket di supporto, affidati al chunking semantico che segua gli scambi di conversazione. I thread di supporto sono lineari e ripetitivi. Un cliente ripete il problema, un agente chiede i log, il cliente li allega. Ogni turno è una propria unità semantica. Il chunking per turni preserva chi ha detto cosa e quando, il che è fondamentale quando l'utente chiede: "Cosa ha suggerito l'agente martedì?".

Per le wiki aziendali, prova il chunking agentico. Fornisci una sezione a un LLM e chiedigli di decidere dove finisce un argomento e ne inizia un altro. Questo costa di più durante la fase di ingest, ma le wiki sono disordinate. Le pagine contengono aggiornamenti non correlati di team diversi, e un confine definito da un essere umano raramente aiuta. Lasciare che un modello tracci i confini in base ai cambi di argomento riduce drasticamente il rumore.

Eseguire più strategie in una singola pipeline richiede l'etichettatura dei documenti per tipo durante l'ingest. Quel piccolo sforzo di disciplina nello schema ripaga immediatamente.

Combina i metodi di ricerca, non sceglierne uno solo

La ricerca vettoriale comprende l'intento, ma fallisce regolarmente sulle corrispondenze esatte. Se chiedi un codice di errore ERR_CONNECTION_REFUSED o uno SKU specifico, gli embedding densi spesso restituiscono risultati concettualmente simili ma fattualmente errati. Il BM25, il classico metodo di recupero sparse basato su parole chiave, gestisce magnificamente le stringhe esatte ma manca le sfumature semantiche. Hai bisogno di entrambi.

Usa il recupero ibrido. Esegui la ricerca vettoriale e il BM25 in parallelo. Poi combinateli con il Reciprocal Rank Fusion (RRF). L'RRF premia i documenti su cui entrambi i metodi concordano sulla rilevanza, pur facendo emergere candidati validi da entrambi gli approcci. La matematica è semplice e il risultato è stabile: nessun singolo metodo di recupero domina il ranking finale.

Dopo la fusione, aggiungi un reranker cross-encoder. La prima fase — ricerca vettoriale più sparse — è veloce e ampia. Il cross-encoder assegna quindi un punteggio a ogni coppia query-documento con piena attenzione, il che significa che legge effettivamente il candidato rispetto alla domanda originale. Sì, questo aggiunge latenza. Nel nostro caso, circa cinquanta o cento millisecondi. Ma il guadagno in precisione è così netto che il compromesso è evidente. Non puoi permetterti di saltare questo passaggio se tieni al recall.

Correggi la query prima di correggere l'indice

Gli utenti non scrivono query per il tuo motore di ricerca. Le scrivono per gli esseri umani. "Non funziona" è una query di supporto comune. Una vaga descrizione di una funzionalità è una ricerca comune nelle wiki aziendali. Se interroghi l'indice con quell'input grezzo, otterrai solo spazzatura.

Trasforma la query prima che raggiunga il retriever.

Use query expansion to generate multiple versions of the user’s question. If someone types “server down,” your system should also search for “service unavailable,” “502 error,” and “connection timeout.” Covering these intent variants moved our recall from 78% to 96%. It is a single step, and it costs almost nothing compared to the gain.

Use query decomposition for complex questions. When a user asks something like “How do I migrate from the legacy billing API to the new one and what breaking changes affect enterprise accounts?,” break it into sub-questions. One sub-question targets migration steps. Another targets enterprise-specific breaking changes. Each hits a different part of the index. The downstream language model synthesizes the final answer from well-retrieved chunks rather than guessing across a noisy context window.

Stop Guessing Hyperparameters

Once you have multiple chunking strategies, hybrid retrieval, and query transformation, you face a combinatorial problem. Chunk size, overlap, fusion weights, reranker depth, and expansion count all interact. Tweaking one in isolation breaks another. Grid search across this space is wasteful and slow.

Use Bayesian optimization instead. Treat this like a machine learning tuning job. Define your objective clearly: maximize recall while keeping latency under a ceiling. Build a golden dataset — a few hundred representative questions where you know precisely which chunks should be retrieved. Then let the Bayesian search explore the configuration space efficiently. It builds a probabilistic model of what works and tests the most promising regions next.

Every candidate configuration must pass the golden dataset before it reaches staging. If a new chunk size drops recall or a heavier reranker pushes you past the latency budget, the optimization catches it automatically. This removes opinion from the room. You stop debating whether 256 or 512 tokens is “better” and start reading the results.

The Outcome

The pipeline changes compounded exactly as we hoped.

  • Recall@10 climbed from 78% to 95%.
  • P95 latency dropped from 850 ms to 320 ms.
  • Hallucination rate fell from 12% to 3%.
  • Cost per query dropped by 38%, largely because better retrieval let us use a smaller generation model and fewer prompt tokens.

The latency reduction surprised some people on the team. Adding rerankers and query expansion sounds like it should slow things down. But because retrieval quality improved, the generation model needed less prompting, less speculation, and fewer retries. Good retrieval makes everything downstream cheaper.

Treat Retrieval Like Infrastructure

Retrieval is not a notebook you run once and forget. It is infrastructure, and it should be managed like code. Version your chunking strategies. When the legal team releases a new contract template, test your recursive splitter before it reaches production. Maintain your golden dataset as living documents, not a static CSV from last quarter. Automate your evaluations in CI so that a pull request modifying an embedding model or a fusion weight gets a comment with recall and latency numbers before a human ever reviews it.

Your users will never ask which embedding model you run. They will not care about your chunking heuristic or your reranker architecture. They care if the answer is correct, if it arrives fast, and if they can trust it. Build a pipeline that earns that trust, measure it honestly, and stop treating retrieval like an afterthought.

Source: Optimizing RAG At Scale
Join the discussion: GyaanSetu AI Community