Ultimo aggiornamento: 2026-06-22

Chunking per RAG

La generazione aumentata dal recupero (RAG) risponde a una domanda cercando prima i passaggi rilevanti in una raccolta di documenti e fornendoli poi a un modello linguistico. Poiché un intero documento è di solito troppo lungo per ricevere l'embedding ed essere recuperato come un'unica unità, ogni documento viene prima suddiviso in parti più piccole chiamate chunk. Il chunking è il passaggio che decide come tagliare quelle parti e influenza sia la qualità del recupero sia il costo degli embedding. Questo calcolatore indica quanti chunk produce un documento di una data lunghezza e quanti token vengono inviati al modello di embedding.

Come funziona il chunking

Uno splitter fa scorrere sul documento una finestra di dimensione fissa. La finestra è larga chunk_size token e, dopo aver emesso ogni chunk, avanza di un passo anziché dell'intera larghezza, così che i chunk consecutivi condividano una fascia di chunk_overlap token. La sovrapposizione esiste affinché un'informazione a cavallo di un confine compaia comunque intera in almeno un chunk: senza di essa, una frase tagliata in due potrebbe non essere recuperabile da nessuna delle due metà.

Il passo è la dimensione del chunk meno la sovrapposizione:

Un documento di $T$ token è coperto una volta che il primo chunk ha consumato $o$ token di vantaggio iniziale e i rimanenti $T - o$ token sono stati percorsi a passi di $s$, il che richiede

chunk. L'arrotondamento per eccesso tiene conto dell'ultima finestra, eventualmente più corta. Ognuno degli $n$ chunk riceve l'embedding alla sua dimensione piena, quindi i token totali inviati al modello di embedding sono

Poiché ogni chunk successivo al primo ripete $o$ token, $T_{emb}$ è maggiore del valore originale $T$ ogni volta che la sovrapposizione è diversa da zero.

Esempio svolto

Si consideri un documento di 8.000 token, suddiviso con una dimensione del chunk di 512 e una sovrapposizione di 64. La finestra avanza di

e il numero di chunk è

L'embedding di tutti i 18 chunk alla dimensione piena invia

al modello di embedding. La sovrapposizione ha gonfiato il volume con embedding da 8.000 a 9.216 token — circa il 15% in più — che è il prezzo pagato per mantenere intatti i passaggi a cavallo dei confini. Quel rapporto è vicino alla dimensione del chunk divisa per il passo, $512 / 448 \approx 1{,}14$.

Note e varianti

Gli splitter reali raramente tagliano in corrispondenza di confini di token esatti. La maggior parte rispetta le interruzioni di frase o di paragrafo, perciò i chunk variano in lunghezza e il conteggio differisce leggermente dalla stima a finestra uniforme proposta qui. Gli splitter ricorsivi e semantici adattano i confini alla struttura naturale, scambiando uniformità con coerenza. La frazione di sovrapposizione è la leva principale sul volume con embedding: una sovrapposizione del 50% raddoppia all'incirca i token con embedding, mentre una sovrapposizione nulla genera l'embedding esattamente della lunghezza del documento ma rischia di spezzare le informazioni.

Applicazioni

Il numero di chunk determina il dimensionamento a valle. Ogni chunk diventa un vettore, quindi alimenta direttamente l'occupazione dell'indice calcolata da Calcolatore della dimensione di un database vettoriale, e il totale dei token con embedding fissa la spesa una tantum per gli embedding stimata da Calcolatore del costo degli embedding. Regolare la dimensione del chunk e la sovrapposizione significa quindi bilanciare in un colpo solo la precisione del recupero rispetto sia allo spazio di archiviazione sia al costo degli embedding.