Chunk RAG: più contesto può peggiorare qualità e costi

Per scegliere la dimensione dei chunk in un sistema RAG, confronta le configurazioni sul tuo corpus e misura sia i passaggi recuperati sia la qualità delle risposte. Più testo in ogni risultato può conservare una spiegazione completa, ma anche diluire l’informazione utile e aumentare i token inviati al generatore: uno studio su testi di diversa struttura mostra che la granularità più efficace cambia con il materiale e con la domanda.

Non c’è quindi un numero valido per tutti i documenti. Un passaggio breve può far emergere un dato preciso; uno più ampio può mantenere insieme le premesse necessarie a una risposta articolata. La scelta dipende da quante prove entrano nel contesto disponibile, da quanto spesso il sistema risponde correttamente e dal costo sostenibile per indicizzazione e risposta.

Prepara domande e prove prima di creare gli indici

Parti da domande rappresentative dell’uso previsto, non da esempi scelti perché funzionano bene. La guida di Pradhumn Gupta propone un campione di 30–50 domande reali e un confronto fra chunk da 256, 512 e 1024 token, con overlap attivo o disattivo. Sono configurazioni iniziali per un esperimento, non dimensioni consigliate a ogni corpus.

Per ciascuna domanda, annota la risposta attesa e i punti esatti dei documenti che la giustificano. Se una risposta richiede due passaggi, etichettali entrambi: recuperarne uno solo non basta. Includi domande puntuali e domande che richiedono di collegare informazioni separate, nelle proporzioni in cui compaiono nell’uso reale. Se il sistema deve anche riconoscere quando i documenti non contengono la risposta, aggiungi casi senza prova e valuta se si astiene.

Conserva il testo originale e la posizione dei passaggi di riferimento. Questo permette di confrontare risultati prodotti da segmentazioni diverse anche quando i confini dei chunk non coincidono. Una risposta di riferimento da sola non basta a diagnosticare un errore: occorre sapere se la prova esisteva nel corpus, se è stata recuperata e se il generatore l’ha usata.

Varia dimensione e overlap, mantieni ferma la pipeline

Crea un indice distinto per ogni combinazione da confrontare, usando sempre gli stessi documenti, la stessa estrazione del testo e lo stesso tokenizer per contare i token. Mantieni fissi modello di embedding, metodo di ricerca, eventuale reranker, prompt e modello generativo. Se cambia anche uno di questi elementi, la differenza nelle risposte non può essere attribuita con chiarezza al chunking.

Definisci l’overlap come una quota costante del chunk nelle prove in cui è attivo e registra il valore usato. Mantieni anche la stessa regola di taglio: per esempio, quando possibile, rispetta i confini delle frasi anziché interromperle a metà. I titoli delle sezioni e l’identità del documento possono restare associati ai passaggi come metadati; così una frase non perde il soggetto soltanto perché finisce in un segmento separato.

Per ogni indice registra il numero di chunk, lo spazio occupato e il lavoro necessario per produrre gli embedding. Chunk più piccoli possono generare più unità da memorizzare; la sovrapposizione replica parte del testo in unità adiacenti. Chunk più grandi possono invece ridurre il numero di unità indicizzate e aumentare i token elaborati quando vengono recuperati. Il costo dell’indice e quello di ogni risposta vanno quindi tenuti distinti.

Misura recupero e risposta con due prove separate

Prima valuta il retrieval senza coinvolgere il generatore. Per una domanda con più prove, recall@k è la quota dei passaggi necessari presenti nei primi k risultati; puoi poi calcolarne la media sulle domande. Quando serve un solo passaggio, la misura coincide con la quota di domande in cui la prova compare nei primi k. Registra anche le domande per cui arrivano tutte le prove richieste: una media buona può nascondere risposte impossibili da comporre.

Usa lo stesso k per confrontare l’ordinamento dei risultati, ma registra quanti token contengono i passaggi recuperati. A parità di k, segmenti più lunghi occupano più spazio. Esegui poi una seconda prova con lo stesso limite di token ammessi nel prompt: mostra quali prove riescono davvero a entrare nel contesto del generatore. Le due letture rispondono a domande diverse, perché un risultato ben classificato può restare fuori dal budget.

Valuta la risposta finale contro il riferimento, distinguendo correttezza e sostegno nei passaggi recuperati. Se la prova era disponibile ma la risposta è sbagliata, il problema può stare nella generazione; se la prova non è arrivata, va esaminato il recupero. Rendere visibili le citazioni dei passaggi usati aiuta a individuare risposte plausibili che non poggiano sul contesto fornito.

Misura infine il tempo dalla domanda alla risposta, separando se possibile ricerca e generazione. Registra i token effettivamente inviati al modello e il costo stimato per risposta con le tariffe della tua pipeline. In questo modo un guadagno di correttezza si può confrontare con la latenza e con la spesa che comporta, senza confonderlo con il costo una tantum dell’indice.

Controlla se più contesto e overlap aiutano davvero

Nell’esperimento di Sofia Bennani e Charles Moslonka su Natural Questions, con ricerca SPLADE e generazione tramite Ministral-8B-Instruct-2410, l’overlap non ha dato benefici misurabili nelle metriche valutate e ha aumentato il costo dell’indice; la qualità è diminuita oltre un budget di circa 2.500 token di contesto. Il risultato riguarda quella combinazione di corpus, retriever, modello e procedura di riempimento del prompt: la soglia va misurata di nuovo in un’altra pipeline.

L’overlap può recuperare una frase tagliata sul confine fra segmenti, ma può anche far comparire quasi lo stesso testo in più risultati. Guarda gli errori: se manca sistematicamente la frase precedente a quella recuperata, la continuità è un problema reale; se i primi risultati ripetono la stessa prova, la sovrapposizione sta consumando spazio che potrebbe ospitare informazioni diverse.

Esamina allo stesso modo i chunk grandi. Se conservano un ragionamento completo ma impediscono l’ingresso di un secondo passaggio necessario, il limite è il budget complessivo del prompt. Se contengono molta materia estranea e i passaggi pertinenti scendono nella classifica, il limite è già nel recupero. Questa distinzione indica se regolare la dimensione dei segmenti, l’overlap o la quantità di contesto inviata al generatore.

Scegli in base agli errori e al costo totale

Confronta prima le configurazioni che recuperano le prove e producono risposte corrette; fra quelle vicine, preferisci la latenza e il costo compatibili con il carico previsto. Se le domande puntuali e quelle articolate favoriscono segmentazioni diverse, considera una strategia che recuperi passaggi brevi e restituisca al generatore una porzione più ampia del documento. Anche questa scelta richiede la stessa valutazione sul corpus.

Conserva insieme alle misure le domande, le prove etichettate, le versioni dei documenti e le impostazioni della pipeline. Quando cambiano i contenuti o il modello, lo stesso campione permette di capire se la configurazione scelta continua a funzionare: la dimensione utile è una proprietà del sistema valutato, non del numero di token preso isolatamente.