Qual è la dimensione migliore dei chunk per il RAG?

Non esiste una risposta universale, ma un buon punto di partenza sono 400–512 token con una sovrapposizione del 10–20 %. Poi ottimizza in base al tipo di query: 128–256 token per la ricerca precisa di fatti, e 512–1024 token per query analitiche o di sintesi. Confronta alcune dimensioni con le tue domande reali invece di affidarti a un unico valore predefinito.

Il chunking semantico è migliore di quello a dimensione fissa?

Non in modo affidabile. Il chunking semantico raggruppa le frasi per argomento, il che sembra meglio, ma i benchmark mostrano che i suoi guadagni rispetto al chunking ricorsivo o a dimensione fissa sono inconsistenti e spesso non giustificano il calcolo di embedding aggiuntivo. Il chunking fisso e ricorsivo restano linee di base solide ed economiche: parti da lì e passa al semantico solo se la tua valutazione mostra un miglioramento reale.

Cos'è il late chunking e quando dovrei usarlo?

Il late chunking calcola prima l'embedding dell'intero documento con un modello di embedding a contesto lungo e poi raggruppa gli embedding dei token in chunk, in modo che il vettore di ogni chunk porti il contesto dell'intero documento, non solo del proprio testo. Usalo per documenti lunghi con dipendenze a lungo raggio, dove un passaggio ha senso solo con il contesto precedente.

Il recupero contestuale migliora davvero la precisione?

Sì, in modo misurabile. Anthropic ha riferito che anteporre a ogni chunk una nota di contesto generata da LLM ha ridotto i fallimenti di recupero nel top-20 del 35 % con embedding contestuali, del 49 % combinato con BM25 contestuale, e del 67 % con il reranking aggiunto, il tutto a circa 1,02 $ per milione di token di documento usando il caching dei prompt. Conviene soprattutto per corpus ad alto valore dove un passaggio mancato è costoso.

Da quale strategia di chunking dovrei iniziare?

Dal chunking ricorsivo con circa 500 token e il 15 % di sovrapposizione. Rispetta i confini naturali, è economico ed è una linea di base solida per la maggior parte dei contenuti. Aggiungi la divisione sensibile alla struttura per PDF e manuali, il recupero del documento padre quando le risposte necessitano di più contesto, e il recupero contestuale solo dove la posta in gioco giustifica il costo aggiuntivo.

← Resources

By Priya Shah — Senior Engineer, RAG + Knowledge · 2026-05-22 · TUTORIAL

Strategie di chunking per il RAG: dimensioni, sovrapposizione e cosa funziona

Il chunking stabilisce il tetto di qualità del RAG ancora prima che parta il recupero. Questa guida confronta le sei strategie che dominano la pratica, fornisce numeri concreti su dimensione e sovrapposizione e spiega quale si adatta a ciascun tipo di query.

Perché il chunking determina la qualità del RAG

Il chunk è l'unità che il tuo retriever recupera davvero, quindi i confini dei chunk stabiliscono il tetto di tutto ciò che viene dopo. Chunk troppo piccoli fanno sì che a ogni embedding manchi segnale sufficiente per essere trovato in modo affidabile; chunk troppo grandi diluiscono il segnale del passaggio rilevante, al punto che il vettore non corrisponde più alla query. Se sbagli il chunking, nessun reranker né un modello più grande recupererà il recall: il passaggio giusto non è mai stato recuperato. Ecco perché il chunking, e non la scelta del modello, è di solito il primo parametro da ottimizzare.

Le sei strategie che dominano la pratica

La pratica attuale si raggruppa in sei approcci:

Dimensione fissa: segmenti uguali di token o caratteri con sovrapposizione. La più antica, economica e riproducibile, e una linea di base sorprendentemente solida.
Ricorsivo: divide secondo una gerarchia di separatori (paragrafo → riga → frase) per restare sotto un limite di dimensione rispettando i confini naturali. L'impostazione predefinita consigliata.
Semantico: raggruppa le frasi per similarità di embedding in modo che ogni chunk tratti un unico argomento. I guadagni rispetto al ricorsivo sono inconsistenti e richiedono un costo computazionale aggiuntivo per l'embedding.
Sensibile alla struttura: divide in base alla struttura del documento (intestazioni, sezioni, pagine, markdown). La migliore per PDF, manuali e documenti finanziari.
Late chunking: calcola prima l'embedding dell'intero documento con un modello a contesto lungo e poi raggruppa gli embedding dei token in chunk, in modo che ogni chunk porti un contesto globale.
Recupero contestuale: antepone a ogni chunk una nota di contesto generata da un LLM prima dell'indicizzazione.

Inizia con il ricorsivo; passa agli altri quando i tuoi documenti o tipi di query lo richiedono.

Dimensione dei chunk e sovrapposizione: numeri concreti

Non esiste una dimensione universalmente ottimale, ma ci sono buoni punti di partenza. Inizia con circa 400–512 token e una sovrapposizione del 10–20 % (circa 50–100 token su un chunk da 500 token). Poi adatta la dimensione al tipo di query: i chunk piccoli (128–256 token) favoriscono la ricerca precisa di fatti e parole chiave, mentre i chunk più grandi (512–1024 token) favoriscono le query analitiche e di sintesi, dove conta il filo narrativo.

La sovrapposizione evita che il significato venga troncato a un confine: troppo poca frammenta il contesto, troppa gonfia l'indice e duplica i recuperi. Il benchmark di NVIDIA ha rilevato che una sovrapposizione di circa il 15 % era ottimale sui documenti finanziari, e che il chunking a livello di pagina forniva la precisione più alta e più costante su corpus misti, con le query fattuali che toccano il picco tra 256–512 token e quelle analitiche oltre 1024.

Avanzato: recupero contestuale e late chunking

Due tecniche più recenti affrontano lo stesso problema: un chunk che dice "i ricavi sono aumentati del 15 %" è inutile se non si sa di quale azienda o trimestre si tratti.

Il recupero contestuale di Anthropic antepone a ogni chunk una nota di contesto di 50–100 token generata da un LLM, prima sia dell'embedding sia dell'indicizzazione BM25. Rispetto a un tasso di fallimento di base del 5,7 % nel top-20, gli embedding contestuali riducono i fallimenti del 35 %, aggiungere BM25 contestuale li riduce del 49 %, e aggiungere il reranking li riduce del 67 %, il tutto a circa 1,02 $ per milione di token di documento con caching dei prompt.

Il late chunking di Jina inverte il processo: calcola l'embedding dell'intero documento con un modello a contesto lungo (fino a ~8192 token), poi raggruppa gli embedding contestualizzati dei token in chunk, in modo che ogni embedding di chunk porti già il contesto tra chunk. Usalo per documenti lunghi con dipendenze a lungo raggio.

Recupero del documento padre e metadati

Due perfezionamenti pagano quasi ovunque. Il recupero del documento padre ("dal piccolo al grande") disaccoppia la granularità del recupero da quella della generazione: indicizza piccoli chunk figli (≈100–500 token) per una corrispondenza precisa, ma restituisce al modello la sezione padre più grande (≈500–2000 token) in modo che abbia il contesto circostante. E l'arricchimento dei metadati — allegare fonte, intestazione di sezione, numero di pagina e timestamp a ogni chunk — migliora il filtraggio, abilita le citazioni e aumenta la precisione del recupero indipendentemente dalla dimensione del chunk.

Scegliere e ottimizzare in osFoundry

Una guida decisionale rapida: il ricorsivo è l'impostazione predefinita sicura; sensibile alla struttura o a livello di pagina per documenti strutturati; semantico per prosa tematicamente densa; late chunking per documenti lunghi con un embedder a contesto lungo; recupero contestuale per corpus ad alto valore dove la perdita di contesto è costosa; documento padre quando ti servono sia precisione sia contesto.

osFoundry tratta tutto questo come configurazione, non come codice. Il chunking automatico fornisce un valore predefinito ricorsivo sensato, e la pipeline RAG personalizzata consente di regolare dimensione, sovrapposizione e strategia per base di conoscenza, con il reranking e il recupero del documento padre come interruttori di fase della pipeline. Poiché le fasi sono configurabili, puoi fare test A/B delle impostazioni di chunking sulla tua distribuzione di query — fattuale contro analitica — mantenendo fisso il resto dello stack, che è esattamente il flusso di lavoro a parametri ottimizzabili raccomandato dalla ricerca.

Frequently asked questions

Qual è la dimensione migliore dei chunk per il RAG?: Non esiste una risposta universale, ma un buon punto di partenza sono 400–512 token con una sovrapposizione del 10–20 %. Poi ottimizza in base al tipo di query: 128–256 token per la ricerca precisa di fatti, e 512–1024 token per query analitiche o di sintesi. Confronta alcune dimensioni con le tue domande reali invece di affidarti a un unico valore predefinito.
Quanta sovrapposizione dovrebbero avere i chunk?: Dal dieci al venti per cento della dimensione del chunk, cioè circa 50–100 token su un chunk da 500 token. La sovrapposizione evita che il significato venga troncato a un confine; troppo poca frammenta il contesto nella divisione, e troppa gonfia l'indice e causa recuperi quasi duplicati. NVIDIA ha rilevato che circa il 15 % era ottimale sui documenti finanziari.
Il chunking semantico è migliore di quello a dimensione fissa?: Non in modo affidabile. Il chunking semantico raggruppa le frasi per argomento, il che sembra meglio, ma i benchmark mostrano che i suoi guadagni rispetto al chunking ricorsivo o a dimensione fissa sono inconsistenti e spesso non giustificano il calcolo di embedding aggiuntivo. Il chunking fisso e ricorsivo restano linee di base solide ed economiche: parti da lì e passa al semantico solo se la tua valutazione mostra un miglioramento reale.
Cos'è il late chunking e quando dovrei usarlo?: Il late chunking calcola prima l'embedding dell'intero documento con un modello di embedding a contesto lungo e poi raggruppa gli embedding dei token in chunk, in modo che il vettore di ogni chunk porti il contesto dell'intero documento, non solo del proprio testo. Usalo per documenti lunghi con dipendenze a lungo raggio, dove un passaggio ha senso solo con il contesto precedente.
Il recupero contestuale migliora davvero la precisione?: Sì, in modo misurabile. Anthropic ha riferito che anteporre a ogni chunk una nota di contesto generata da LLM ha ridotto i fallimenti di recupero nel top-20 del 35 % con embedding contestuali, del 49 % combinato con BM25 contestuale, e del 67 % con il reranking aggiunto, il tutto a circa 1,02 $ per milione di token di documento usando il caching dei prompt. Conviene soprattutto per corpus ad alto valore dove un passaggio mancato è costoso.
Cos'è il recupero del documento padre (dal piccolo al grande)?: Disaccoppia come effettui la corrispondenza da cosa restituisci. Indicizzi piccoli chunk figli per una corrispondenza precisa, ma quando uno corrisponde consegni al modello la sezione padre più grande in modo che abbia il contesto circostante. Questo ti dà il recall dei chunk piccoli e la coerenza di quelli grandi senza rinunciare a nessuno dei due.
Da quale strategia di chunking dovrei iniziare?: Dal chunking ricorsivo con circa 500 token e il 15 % di sovrapposizione. Rispetta i confini naturali, è economico ed è una linea di base solida per la maggior parte dei contenuti. Aggiungi la divisione sensibile alla struttura per PDF e manuali, il recupero del documento padre quando le risposte necessitano di più contesto, e il recupero contestuale solo dove la posta in gioco giustifica il costo aggiuntivo.