Chunking per RAG: come dividere i documenti per risposte migliori

Il chunking è l'operazione che divide un documento in frammenti (chunk) prima di indicizzarli per la ricerca semantica. È probabilmente la scelta tecnica che più influenza la qualità delle risposte di un sistema RAG, più del modello di embedding o del motore vettoriale scelto. Un chunk troppo piccolo perde il contesto, uno troppo grande diluisce la risposta in mezzo a informazioni irrilevanti: in questo articolo vediamo le strategie principali, come gestire l'overlap e quali dimensioni usare per tipo di documento.

Perché il chunking decide la qualità delle risposte

In un sistema RAG (Retrieval-Augmented Generation), il modello non legge mai l'intero documento: riceve solo i chunk che la ricerca ha giudicato più pertinenti alla domanda. Se il chunking è stato fatto male, due problemi tipici compromettono tutto il resto della pipeline, indipendentemente da quanto sia bravo il motore di ricerca o il modello linguistico usato per generare la risposta.

Il primo problema è la frammentazione del contesto: una clausola contrattuale tagliata a metà, una tabella di dati spezzata su due chunk, una procedura in tre passaggi divisa tra due frammenti diversi. Il modello riceve pezzi incompleti e produce risposte parziali o, peggio, inventa la parte mancante. Il secondo problema è il rumore: chunk troppo grandi contengono informazioni eterogenee, e la ricerca semantica fatica a capire quale porzione del testo è davvero rilevante per la domanda posta. Per capire come questi frammenti vengono poi recuperati e trasformati in risposta, può essere utile rileggere come funziona il RAG, passo dopo passo.

Prima ancora di scegliere la dimensione, conviene capire cosa rappresenta davvero un chunk a livello matematico: un testo trasformato in un vettore numerico tramite embedding. Un chunk incoerente (che mescola due argomenti diversi) produce un embedding ambiguo, che non assomiglia bene a nessuna delle due query che dovrebbe soddisfare.

Le quattro strategie di chunking a confronto

Chunking a dimensione fissa (fixed-size)

È la strategia più semplice: si taglia il testo ogni N caratteri o token, con o senza rispetto dei confini di parola. Rapida da implementare e prevedibile nei costi di indicizzazione, ma ignora completamente la struttura logica del documento. Un chunk fisso può tagliare una frase a metà o separare una domanda dalla sua risposta in un manuale tecnico. È accettabile per prototipi veloci, sconsigliata per documenti che devono restare leggibili e citabili.

Chunking per frase o paragrafo (sentence-based)

Qui il taglio avviene sui confini naturali del testo: punti, a capo, paragrafi. Si raggruppano frasi intere fino a raggiungere una dimensione target, senza mai spezzare un'unità grammaticale completa. È il miglior compromesso tra semplicità di implementazione e qualità del risultato, ed è la base di quasi tutte le pipeline di produzione affidabili.

Chunking semantico

Il chunking semantico misura la similarità tra frasi consecutive (tramite embedding) e inserisce un taglio solo quando il contenuto cambia argomento in modo significativo. Produce chunk di lunghezza variabile ma coerenti dal punto di vista del significato: ogni frammento tratta un solo concetto. Il costo è computazionale (serve calcolare embedding anche solo per decidere dove tagliare) e la resa dipende molto dalla qualità del modello di embedding usato a monte.

Chunking strutturale (structure-aware)

Sfrutta la struttura esplicita del documento: titoli, sottotitoli, elenchi puntati, righe di tabella, intestazioni Markdown, articoli e commi di un testo normativo. Ogni chunk corrisponde a una sezione logica reale (un articolo di legge, un paragrafo di un contratto, una riga di una FAQ). È la strategia più efficace per documenti ben formattati come contratti, normative, manuali tecnici o documentazione Markdown, perché preserva il significato di citazione: quando il sistema risponde, può indicare esattamente «Articolo 12, comma 3» invece di un generico «pagina 4».

L'overlap tra chunk: a cosa serve e quanto impostarlo

L'overlap (sovrapposizione) consiste nel far ripetere una piccola porzione di testo tra un chunk e il successivo, in modo che un'informazione a cavallo tra due frammenti non venga persa interamente in nessuno dei due. Senza overlap, una frase come «questa procedura si applica solo ai veicoli immatricolati dopo il 2019» rischia di finire isolata dal contesto che la introduce, rendendola inutilizzabile o fuorviante se recuperata da sola.

• Un overlap del 10-15% della dimensione del chunk è un buon punto di partenza per la maggior parte dei documenti testuali.
• Per testi molto densi di riferimenti incrociati (contratti, normative), un overlap più alto (20-25%) riduce il rischio di perdere il contesto di una clausola.
• Un overlap troppo alto (oltre il 30%) aumenta i costi di indicizzazione e di archiviazione senza benefici proporzionali, e può generare risultati di ricerca duplicati.
• Con il chunking strutturale, l'overlap è spesso meno necessario perché ogni chunk è già un'unità logica completa.

Come la dimensione del chunk influenza la qualità delle risposte

Non esiste una dimensione universalmente «giusta»: dipende dal tipo di domanda che gli utenti porranno. Una domanda puntuale («qual è la coppia di serraggio del dado ruota?») è servita meglio da chunk piccoli e precisi. Una domanda di sintesi («quali sono gli obblighi del datore di lavoro secondo questo capitolo?») richiede chunk più ampi che contengano il ragionamento completo.

Il fenomeno del «lost in the middle» (perso nel mezzo) è documentato nella letteratura sui modelli linguistici a contesto lungo: quando un chunk è troppo esteso, l'informazione rilevante posizionata al centro del testo ha più probabilità di essere ignorata rispetto a quella posizionata all'inizio o alla fine. Questo è uno dei motivi per cui ridurre le allucinazioni dell'IA passa anche da un chunking disciplinato, non solo da un prompt ben scritto.

Default pratici per iniziare

Se deve partire da zero senza fare troppi esperimenti, questi valori funzionano bene nella maggior parte dei casi reali, in attesa di un'ottimizzazione successiva basata sui riscontri degli utenti:

1. Documenti testuali generici (PDF, Word, relazioni): chunking per paragrafo, dimensione target 300-500 token, overlap 10-15%.
2. Documentazione tecnica e manuali con titoli chiari: chunking strutturale sulle intestazioni, con un chunk per sottosezione.
3. Contratti e testi normativi: chunking strutturale su articoli e commi, overlap leggero per mantenere i riferimenti incrociati.
4. FAQ e knowledge base di supporto: un chunk per coppia domanda-risposta, senza overlap necessario.
5. Tabelle di dati: estrazione riga per riga o gruppo di righe correlate, mai un taglio a metà tabella.

Un errore comune è applicare la stessa configurazione di chunking a tutti i documenti di una base di conoscenza, indipendentemente dal loro formato. Un contratto e un manuale tecnico hanno strutture logiche molto diverse: trattarli allo stesso modo produce risultati mediocri su entrambi. Quando carica documenti eterogenei su Kopik, ad esempio, conviene separare le basi per tipo di documento proprio per poter tarare il chunking in modo coerente con il contenuto.

Casi particolari: tabelle, codice e documenti lunghi

Alcuni formati meritano un trattamento specifico perché il chunking generico li danneggia sistematicamente. Le tabelle, se tagliate a metà, perdono l'intestazione di colonna e diventano illeggibili per il modello: meglio ripetere l'intestazione in ogni chunk derivato dalla stessa tabella. Il codice sorgente va diviso per funzione o blocco logico, mai per numero di righe, altrimenti si rischia di separare una dichiarazione dal suo utilizzo. I documenti molto lunghi (centinaia di pagine) beneficiano di un chunking gerarchico: prima si indicizza un riassunto per capitolo, poi i chunk di dettaglio, in modo che la ricerca possa prima individuare il capitolo giusto e poi scendere nel dettaglio.

Per chi vuole semplicemente verificare se una risposta generata si basa davvero sul chunk corretto, prima di fidarsi ciecamente di una citazione conviene seguire un metodo di controllo: lo abbiamo descritto in dettaglio in come verificare una risposta dell'IA sui propri documenti. Lo stesso principio vale per chi lavora quotidianamente con PDF lunghi: la guida su chattare con i PDF approfondisce come ottenere risposte affidabili e con fonti citate anche su documenti densi.

Chunking fai-da-te o piattaforma gestita?

Implementare una pipeline di chunking strutturale, con overlap calibrato per tipo di documento e indicizzazione ibrida (full-text più semantica), richiede tempo e manutenzione continua, soprattutto quando i formati dei documenti caricati cambiano nel tempo. Su Kopik, caricando un documento su una base di conoscenza, l'estrazione, il chunking e l'indicizzazione ibrida avvengono automaticamente, con risposte che citano i passaggi esatti usati per generarle. Questo evita di dover scegliere manualmente dimensione e overlap per ogni tipo di file, pur restando possibile interrogare le basi via API o tramite server MCP per chi vuole integrare il tutto nei propri strumenti, come descritto nella documentazione per sviluppatori. Chi valuta diverse opzioni di RAG gestito può confrontarle nel nostro approfondimento sulle piattaforme RAG as a service, mentre chi si chiede quanto costi mantenere un'infrastruttura di ricerca vettoriale propria troverà utile l'articolo sul costo di un database vettoriale.

Domande frequenti