Lotook
Per suddividere efficacemente i documenti in chunk per RAG, dividi prima i file seguendo la struttura esistente, applica alle sezioni troppo grandi un limite di lunghezza in token con sovrapposizione a livello di frase e associa a ogni passaggio i metadati della fonte. La scelta tra suddivisione per token, semantica e basata sulla struttura dipende dal fatto che il corpus contenga prosa uniforme, argomenti variabili oppure tabelle e titoli formattati.
Perché la suddivisione in chunk per RAG determina la qualità del recupero?
Retrieval-Augmented Generation (RAG) divide i documenti di origine in passaggi più piccoli prima di generare i loro embedding e memorizzarli in un indice di ricerca. Al momento della query, il sistema recupera i chunk più pertinenti e li passa a un modello linguistico insieme alla domanda dell’utente. La suddivisione determina l’unità di recupero perché un documento intero è di solito troppo ampio per corrispondere bene a una domanda specifica e troppo grande per entrare insieme ad altri candidati nella finestra di contesto del modello.
Quando Patrick Lewis e colleghi presentarono il framework nel loro articolo NeurIPS del 2020 (Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks), l’esperimento divideva ogni articolo Wikipedia in chunk non sovrapposti di circa 100 parole, producendo circa 21 milioni di passaggi. Quella suddivisione in blocchi da 100 parole era un’impostazione sperimentale del 2020 per Wikipedia, non un valore predefinito di produzione per il 2026. A novembre 2026, il RAG moderno in produzione funziona solitamente come pipeline ingegneristica modulare (suddivisione, embedding, indicizzazione, recupero e generazione), anziché con la configurazione originale DPR e BART differenziabile end-to-end.
Quali sono i tre principali metodi di suddivisione per RAG?
I metodi di suddivisione per RAG rientrano in tre famiglie: per token, semantica e basata sulla struttura. Ciascuna determina dove un passaggio inizia e finisce usando lunghezza, significato o markup del documento.
| Metodo di suddivisione | Segnale di divisione | Ideale per | Rischio principale | Costo di indicizzazione |
|---|---|---|---|---|
| Suddivisione per token (o lunghezza) | Finestra fissa di token o caratteri con sovrapposizione scorrevole | Prosa uniforme, testo semplice o limite di lunghezza dopo divisioni strutturali | Taglia a metà frasi, righe di tabelle, blocchi di codice o definizioni | Basso |
| Suddivisione semantica | Calo della somiglianza tra embedding di frasi adiacenti | Prosa senza formattazione in cui gli argomenti cambiano a metà documento senza titoli | Indicizzazione più lenta e costosa; chunk di dimensioni disomogenee | Alto |
| Suddivisione basata sulla struttura | Titoli, paragrafi, elenchi, tabelle, blocchi di codice o pagine | Markdown, HTML, documentazione API, clausole legali e manuali strutturati | Struttura debole nei PDF scansionati; singole sezioni possono essere enormi | Da basso a medio |
1. Suddivisione per token e caratteri
La suddivisione per token divide il testo in finestre di lunghezza fissa misurata in token o caratteri, spesso con una sovrapposizione scorrevole. Misurare in token rispecchia il funzionamento dei modelli: i modelli di embedding e gli LLM hanno limiti rigorosi in token, le API sono tariffate in token e lo stesso paragrafo può essere tokenizzato diversamente tra famiglie di modelli. Il numero di caratteri è solo un’approssimazione.
I team partono di solito da una finestra che rientra nel limite del modello di embedding (i tutorial iniziano spesso da qualche centinaio di token) e la regolano dopo aver esaminato i mancati recuperi. Il rischio principale di una finestra fissa è ignorare sintassi e impaginazione, tagliando una frase, una riga di tabella, un blocco di codice o una definizione ed escludendo la proposizione che risponde alla domanda.
2. Suddivisione semantica
La suddivisione semantica divide il testo quando cambia il significato, per esempio quando cala la somiglianza tra gli embedding di frasi adiacenti o compare un confine discorsivo, anziché a un numero rigido di token. Mantenere un’idea completa in un chunk aiuta il recupero quando gli argomenti cambiano a metà di un documento senza titoli.
La suddivisione semantica è però più lenta e costosa da indicizzare perché la divisione stessa può richiedere chiamate per gli embedding. Una soglia di somiglianza disturbata può anche dividere troppo o troppo poco il testo, creando dimensioni disomogenee; inoltre la somiglianza tra frasi non è automaticamente migliore per tabelle, moduli o codice.
3. Suddivisione basata sulla struttura
La suddivisione basata sulla struttura usa come primo taglio la struttura esistente del documento: titoli Markdown o HTML, paragrafi, elenchi, sezioni, pagine, blocchi di codice delimitati o confini delle tabelle. Come osservato in AWS Prescriptive Guidance su RAG, preservare la struttura del documento mantiene intatto il contesto logicamente correlato. Un chunk che inizia da un titolo sulla politica di rimborso e contiene l’intera sezione è più facile da recuperare e citare di una finestra che parte a metà frase.
Poiché molti PDF e documenti scansionati non hanno titoli chiari (e un solo titolo può coprire 20 pagine), le pipeline di produzione combinano solitamente i metodi:
- Dividi prima gerarchicamente per struttura: Suddividi il documento per sezione o titolo, poi per paragrafo o blocco, mantenendo intatti blocchi di codice, tabelle ed elenchi.
- Applica poi un limite di lunghezza in token: Se una sezione è ancora troppo grande, dividila con una finestra di token.
- Usa divisioni alternative per il testo non strutturato: Per PDF scansionati o lunghe sezioni non strutturate, ricorri a divisioni per pagina, finestre di token o confini semantici.
Come configurare la sovrapposizione dei chunk e i metadati RAG?
La sovrapposizione dei chunk e i metadati dei passaggi evitano di perdere proposizioni ai confini e collegano gli estratti recuperati ai documenti di origine.
Configurare la sovrapposizione dei chunk
La sovrapposizione ripete la fine di un chunk all’inizio del successivo, affinché una frase o definizione sul confine compaia interamente in almeno un passaggio recuperato. È una semplice precauzione quando finestre fisse o divisioni alternative tagliano un pensiero a metà.
Dimensiona la sovrapposizione per coprire una o due frasi tipiche del corpus, mantenendola abbastanza piccola da non memorizzare due volte quasi lo stesso chunk. La sovrapposizione aumenta i token da incorporare, memorizzare e recuperare, ingrandendo l’indice e aggiungendo ai risultati elementi quasi duplicati. Se il recupero restituisce spesso chunk quasi duplicati, riduci la sovrapposizione o la dimensione dei chunk, oppure aggiungi una fase di deduplicazione dopo il recupero.
Associare metadati RAG
I metadati RAG sono campi strutturati memorizzati accanto a ogni chunk, tra cui:
- ID o URL del documento di origine e titolo
- Percorso della sezione o dei titoli e numero di pagina
- Data di creazione o aggiornamento e tipo di documento (politica, ticket, riferimento API)
- Etichette di accesso e autorizzazione, lingua e ID stabile del chunk
I team possono escludere i metadati dall’embedding quando ID grezzi o timestamp altererebbero la somiglianza, oppure anteporre campi selezionati (come il titolo di una sezione) al testo incorporato quando migliorano il recupero. I metadati soddisfano tre esigenze di produzione:
- Citazioni: L’interfaccia o il modello può citare file, titolo e numero di pagina invece di un semplice passaggio.
- Filtri per autorizzazioni e versioni: Recupera solo la versione più recente di una politica, un prodotto specifico o i documenti che l’utente è autorizzato a vedere. Le autorizzazioni vanno nei filtri dell’indice e non solo nel prompt, poiché inserire documenti privati in un indice RAG senza filtri li espone a chiunque possa interrogare il sistema.
- Debug e aggiornamenti: Quando cambia un documento di origine, suddividilo e genera di nuovo i suoi embedding, quindi ritira i vecchi ID dei chunk affinché dati obsoleti non causino errori fattuali.
Come capire se i chunk sono troppo grandi o troppo piccoli?
Esaminare i chunk recuperati per domande reali degli utenti rivela se i passaggi sono troppo grandi o frammentati.
Segnali che i chunk sono troppo grandi
- Risposte nascoste: Il recupero restituisce una lunga sezione che menziona il termine cercato ma nasconde la risposta effettiva, costringendo il modello a cercarla o a perderla.
- Prompt affollati: Solo pochi chunk entrano nel prompt, quindi una corrispondenza mediocre esclude quelle migliori.
- Costi e latenza maggiori: Inviare molti token irrilevanti aumenta la spesa e il tempo di risposta.
- Maggiore distrazione: Il rumore aggiuntivo peggiora il context rot, in cui il modello ha il fatto corretto in un prompt ampio ma si affida alla memoria dell’addestramento o a una frase adiacente errata.
Segnali che i chunk sono troppo piccoli
- Frammenti privi di contesto: Un chunk recuperato non si capisce senza la frase precedente (per esempio una frase che indica un’eccezione per i piani aziendali senza nominare la regola).
- Risposte articolate divise: Una definizione e la sua eccezione, una funzione e i suoi parametri oppure una politica e la sua data di entrata in vigore finiscono in chunk separati e top-k restituisce un solo pezzo.
- Frammenti quasi identici: Recuperi molti estratti ripetitivi senza ottenere un pensiero completo, mentre le citazioni diventano confuse perché ogni frase è una fonte a sé.
Per regolare le dimensioni nella pratica, esamina domande reali e chunk recuperati, e chiediti se una persona con i soli passaggi potrebbe rispondere. Se la frase necessaria si trova in un chunk vicino non recuperato, modifica sovrapposizione, regole strutturali o dimensione. Se si trova nel chunk recuperato circondata da testo non pertinente, dividi in parti più piccole o recupera meno chunk, più mirati.
Come influisce la suddivisione per RAG sul context rot?
La suddivisione per RAG è una leva diretta contro il context rot, ossia il calo della qualità del ragionamento, del rispetto delle istruzioni e della capacità di richiamo di un modello quando un prompt diventa più lungo o disordinato, anche ben al di sotto del limite di contesto dichiarato.
RAG esiste per evitare di inserire l’intero corpus nel prompt. Tuttavia, recuperare chunk troppo grandi o aumentare top-k per sicurezza e riempire il prompt di molti chunk vagamente simili ricrea un contesto lungo e rumoroso. Più contesto non significa automaticamente maggiore precisione. Mantenere i chunk mirati riduce il disordine nel prompt, ma una buona suddivisione da sola non può correggere un modello di embedding scadente né eliminare le allucinazioni dell’IA quando un modello ignora il testo recuperato.
FAQ
Devo misurare la dimensione dei chunk RAG in token o caratteri?
Misura la dimensione dei chunk RAG in token ogni volta che è possibile. I modelli di embedding e linguistici impongono limiti di contesto in token e l’uso delle API è fatturato per token. Il numero di caratteri è solo un’approssimazione, perché lo stesso paragrafo può produrre numeri diversi di token a seconda di lingue, blocchi di codice e famiglie di modelli. Usare il tokenizer del modello di embedding evita troncamenti imprevisti durante l’indicizzazione.
La suddivisione semantica è sempre migliore di quella per token?
La suddivisione semantica non è automaticamente migliore di quella per token o basata sulla struttura. Dividere quando cala la somiglianza tra frasi aiuta a mantenere unite le idee nella prosa non strutturata, ma richiede lavoro aggiuntivo per gli embedding durante l’indicizzazione, crea chunk di dimensioni disomogenee e può dividere troppo o troppo poco con una soglia disturbata. Per documenti formattati, dividere lungo titoli, tabelle e blocchi di codice è più rapido e segue i confini previsti dall’autore.
Come devo suddividere tabelle e blocchi di codice per RAG?
Tabelle, fatture, clausole legali e codice richiedono regole basate sulla struttura che mantengano intatti i blocchi. Una divisione ingenua per caratteri o token attraverso una tabella Markdown o il corpo di una funzione produce chunk inutilizzabili che separano i valori dalle intestazioni delle colonne o rompono la sintassi. Mantieni interi blocchi di codice, tabelle ed elenchi quando possibile e applica alternative basate sulla struttura solo quando un singolo blocco supera i limiti del modello.
I metadati devono essere inclusi nell’embedding del chunk?
Includere i metadati nel testo incorporato è una scelta progettuale che dipende dal campo. Anteporre un titolo del documento o un percorso di titoli di sezione al testo del chunk aiuta spesso il recupero quando i paragrafi dipendono dal titolo per il contesto. Identificatori grezzi, timestamp ed etichette di accesso dovrebbero restare in campi di metadati separati e filtrabili, per non alterare la somiglianza degli embedding.
Cosa succede quando cambia un documento di origine?
Quando cambia un documento di origine, la pipeline di acquisizione deve suddividerlo e generarne nuovamente gli embedding, ritirando dall’indice i vecchi ID dei chunk. Lasciare attivi chunk obsoleti insieme a quelli aggiornati induce il sistema di recupero a mostrare politiche superate o passaggi contraddittori, trasformando una svista nella manutenzione dell’indice in un errore fattuale nella risposta finale.
