Chunking: come si spezzano i documenti

Immagina di dover archiviare un libro ritagliandolo in schede. Se tagli in mezzo a una spiegazione, quando ritrovi quella scheda non capisci più niente: metà del ragionamento è rimasta nell’altra. Il chunking è esattamente questo, e decide cosa il tuo sistema potrà trovare.

È il passaggio che nel RAG viene liquidato in fretta, di solito lasciando i valori predefiniti di una libreria. Ed è anche il punto in cui la maggior parte dei sistemi si rompe: nessun modello di embedding, per quanto buono, recupera un concetto che è stato tagliato a metà.

Perché conta più del modello

Documento: 50 pagine di manuale

Chunking sbagliato   pezzi che spezzano i concetti
                     → il recupero trova mezze spiegazioni
                     → il modello risponde a metà, con sicurezza

Chunking sensato     pezzi che contengono un concetto intero
                     → il recupero trova spiegazioni complete
                     → il modello ha di che rispondere

La cosa importante: l’errore non si vede. Il sistema non segnala niente, restituisce comunque una risposta, e sembra semplicemente un po’ stupido. Quando un RAG “non funziona bene” senza una ragione evidente, il chunking è il primo posto dove guardare.

Le strategie, dalla peggiore alla migliore

A dimensione fissa. Taglia ogni N caratteri, senza guardare cosa c’è scritto.

"Il polimorfismo è un concetto che permette | a oggetti di classi diverse di..."
                              taglio qui ↑

pezzo 1: "Il polimorfismo è un concetto che permette"
pezzo 2: "a oggetti di classi diverse di..."      ← inizia nel vuoto

Semplice e veloce, ma taglia le parole a metà e produce pezzi che iniziano senza soggetto. Ha senso solo su testo senza nessuna struttura, tipo registri di log.

Con sovrapposizione. Come sopra, ma ogni pezzo ripete un po’ della coda del precedente.

|<------ pezzo 1 ------>|
                 |<-- sovrapposizione -->|
                 |<------ pezzo 2 ------>|

La sovrapposizione tipica è il 10-20% della dimensione del pezzo: su mille caratteri, dai cento ai duecento. Riduce il danno ai bordi, non risolve i concetti lunghi, e in cambio aumenta il numero di pezzi da archiviare nel database vettoriale.

Per struttura. Segue titoli, sezioni e paragrafi del documento: un pezzo per sezione. Ogni pezzo contiene un concetto compiuto, ma le dimensioni ballano parecchio — un paragrafo di tre righe e un capitolo di otto pagine diventano due pezzi molto diversi.

Ricorsivo. È il punto di partenza giusto per quasi tutto. Prova a dividere per il separatore più grande e scende solo se il pezzo resta troppo lungo:

1. doppio a capo   → separa i paragrafi
2. singolo a capo  → separa le righe
3. spazio          → separa le parole
4. carattere       → ultima spiaggia

Rispetta la struttura del testo quando c’è, e ha comunque un comportamento definito quando non c’è.

Per formato. Quando sai cosa stai indicizzando, uno strumento che capisce il formato batte tutti: Markdown per titolo, HTML per sezione, codice per funzione o classe, JSON per oggetto di primo livello.

Strategia	Complessità	Resa	Quando
Dimensione fissa	Minima	Bassa	Testo senza alcuna struttura
Con sovrapposizione	Bassa	Media	Log, chat, trascrizioni
Per struttura	Media	Alta	Documenti ben formattati
Ricorsivo	Bassa	Alta	Il default ragionevole
Per formato	Media	Molto alta	Quando il formato è noto

Quanto devono essere grandi

Non esiste il numero giusto, esistono due modi di sbagliare.

Troppo piccolo (sotto i duecento token): “Il polimorfismo è un concetto della programmazione a oggetti.” Il recupero lo trova, ma quel pezzo da solo non basta a rispondere: manca tutto il resto.

Troppo grande (oltre i duemila): un capitolo intero che parla di tre argomenti. Il suo vettore finisce per essere la media di tutto, quindi non è particolarmente vicino a nessuna domanda — e quando viene recuperato occupa un pezzo enorme di finestra di contesto per dire poco.

Come ordine di grandezza:

Dimensione	Adatta a
~500 token	Definizioni, domande frequenti, schede
~1000 token	Spiegazioni, documentazione tecnica, tutorial
~1500 token	Testi discorsivi, articoli lunghi, manuali

Un’avvertenza che fa perdere pomeriggi: i caratteri non sono token. Se la libreria conta caratteri e tu ragioni in token, i tuoi pezzi sono più corti di quello che credi — di circa un fattore quattro sull’italiano. Vale la pena configurare il conteggio in token, che è l’unità in cui ragiona il modello (il tema della lezione sulla tokenizzazione).

I metadati valgono quanto il testo

Ogni pezzo dovrebbe portarsi dietro da dove viene:

pezzo:
  testo: "Il polimorfismo permette a oggetti di classi diverse..."
  fonte: manuale-java.pdf
  pagina: 145
  capitolo: "5 - Programmazione a oggetti"
  sezione: "5.3 Polimorfismo"

Servono a quattro cose concrete: citare la fonte nella risposta, filtrare la ricerca su un solo capitolo, capire quale pezzo ha prodotto una risposta sbagliata, e riconoscere i doppioni quando lo stesso testo arriva da due file.

C’è anche un effetto meno ovvio: se al pezzo anteponi il titolo della sezione da cui viene, migliori il recupero. Un paragrafo che inizia con “5.3 Polimorfismo” è più vicino, nello spazio degli embedding, a una domanda sul polimorfismo di quanto non lo sia lo stesso paragrafo orfano.

Lo stesso testo, due tagli diversi

Prendiamo una pagina con tre parti: una definizione, un esempio di codice, un elenco di vantaggi.

Tagliata a lunghezza fissa da 200 caratteri:

pezzo 1: "## Polimorfismo\nIl polimorfismo è uno dei quattro pilastri della"
pezzo 2: " programmazione a oggetti. Permette a oggetti di classi diverse"
pezzo 3: " di rispondere allo stesso messaggio in modi diversi.\n\nEsistono due tipi: overloadi"

Il terzo pezzo finisce dentro una parola. Nessuna di queste schede risponde a una domanda.

Tagliata in modo ricorsivo, con sovrapposizione:

pezzo 1: definizione + i due tipi di polimorfismo
pezzo 2: l'esempio di codice completo
pezzo 3: i vantaggi

Tre schede, tre concetti interi. Alla domanda “fammi un esempio di polimorfismo” il recupero può restituire esattamente il pezzo 2.

Dove si sbaglia

Lasciare i valori predefiniti senza guardare i pezzi. Il rimedio costa cinque minuti: stampa i primi dieci pezzi e leggili. Se non si capiscono da soli, non li capirà nemmeno il modello.

Sovrapposizione a zero. È il valore iniziale di parecchie librerie, e ti fa perdere le frasi a cavallo fra due pezzi — cioè proprio quelle che collegano i concetti.

Un solo taglio per tutti i formati. Un manuale, una raccolta di conversazioni e un archivio di codice non si spezzano nello stesso modo. Se stai indicizzando roba eterogenea, la strategia va scelta per tipo di documento, non per l’intera collezione.

Reindicizzare senza svuotare l’archivio. Cambi la dimensione dei pezzi, rilanci l’indicizzazione e i vecchi pezzi restano lì: l’archivio si riempie di due versioni dello stesso testo, e il recupero peggiora invece di migliorare.

Provare a occhio invece che con domande vere. Il modo serio di regolare il chunking è prendere dieci domande a cui sai già rispondere, guardare quali pezzi vengono recuperati e correggere. Senza questo, si va a sensazione.

In sintesi

Concetto	In una riga
Chunking	Spezzare i documenti nei pezzi che verranno recuperati
Perché conta	Un concetto tagliato a metà non è recuperabile, punto
Default sensato	Ricorsivo, ~1000 token, sovrapposizione del 10-20%
Troppo piccolo	Il pezzo si trova ma non basta a rispondere
Troppo grande	Il vettore è la media di troppi argomenti e non è vicino a niente
Metadati	Fonte, pagina, sezione: servono a citare, filtrare e capire gli errori
Trucco utile	Anteporre al pezzo il titolo della sua sezione
Come si regola	Con domande vere, guardando quali pezzi tornano indietro