Quando Perplexity cita il tuo sito, non ha letto tutta la pagina. Ha letto un blocco di 200-500 parole, ritagliato in modo algoritmico. Se la risposta alla domanda dell'utente è spalmata su tre sezioni diverse della tua pagina, nessun blocco la contiene completa e l'AI passa ad un'altra fonte. Ti spiego come strutturare ogni sezione perché funzioni da sola.
Perplexity cita il tuo sito. ChatGPT richiama un tuo articolo. Sembra che funzioni.
Ma cosa ha letto davvero il sistema AI? Non la tua pagina. Nemmeno una sezione intera. Ha letto un frammento — un blocco di testo di 200-500 token, ritagliato in modo algoritmico, confrontato con migliaia di altri frammenti, e selezionato perché in quel momento era il più rilevante per quella query specifica.
Il resto della tua pagina, per il modello, non esiste.
Ne ho parlato introducendo il RAG e la ricerca ibrida — in questo articolo ti spiego in parole semplici come funziona il chunking, perché è un vincolo fisico e non una scelta, e cosa comporta per chi vuole farsi trovare nelle risposte AI.
Prima di tutto: è meccanica, non opinione
Il chunking non è una scelta stilistica dei team che costruiscono sistemi RAG. È un vincolo fisico del modo in cui i modelli linguistici funzionano.
I modelli hanno una context window limitata — ti ho parlato di questo nell’articolo sul context window. Non puoi passare 50.000 token di contenuto web ogni volta che un utente fa una domanda: sarebbe lento, costoso, e spesso inutile. La soluzione è fare retrieval: recuperare solo le parti rilevanti, tenerle piccole, passarle al modello.
Da qui nasce il chunk. Non come concetto astratto, ma come unità operativa concreta che entra nel prompt.
Nel mondo della ricerca, Gao et al. (2024) lo descrivono così nella loro survey sul Retrieval-Augmented Generation:
“These chunks are subsequently used as the expanded context in prompt.”
Tradotto in termini pratici: il tuo contenuto non finisce mai davanti al modello per intero. Finisce dentro al prompt come contesto espanso, un pezzo alla volta — e solo i pezzi che il sistema ha giudicato rilevanti per quella query.
Da questo segue che la qualità del tuo contenuto, misurata da un modello AI, non è la qualità media dell’intera pagina. È la qualità del chunk più forte che quella pagina riesce a produrre su una domanda specifica.
Come vengono tagliati i chunk
La domanda concreta è: dove avviene il taglio?
Zhao et al. (2024), in uno studio sull’architettura del retrieval, descrivono la struttura base in modo che vale la pena visualizzare:
“Left: simplified version where a sequence of length n = 12 is split into l = 3 chunks of size m = 4.”
L’esempio usa numeri piccoli per chiarezza. Nella realtà, una sequenza di 1.200 token potrebbe diventare 4 chunk da 300 token, oppure 6 chunk da 200 con overlap di 50. Il punto è che il taglio è sistematico e parametrizzato — non “intelligente” nel senso di capire cosa stai dicendo.
Esistono tre strategie principali che i sistemi RAG usano in produzione:
Chunking a dimensione fissa. Ogni n token — tipicamente 300-500 — si taglia. Senza riguardo per la struttura sintattica o semantica. Semplice da implementare, veloce, ma brutale: può spezzare una frase a metà.
Chunking strutturale. Il sistema usa i punti di separazione naturale del documento — titoli di sezione, interruzioni di paragrafo, tag HTML specifici — come punti di taglio. Più intelligente, ma dipende da quanto il tuo markup è pulito e coerente.
Chunking ibrido con overlap. Si taglia ai punti strutturali, ma si mantiene un numero fisso di token di overlap tra chunk adiacenti per preservare il contesto ai bordi. Questo mitiga il problema del taglio che spezza un ragionamento.
La maggior parte dei sistemi in produzione usa una variante ibrida: taglia ai titoli di sezione, con un limite massimo di token per chunk e un overlap configurabile. I tuoi heading non sono solo per la leggibilità umana — sono segnali di taglio per i motori di retrieval.
La metrica che non conoscevi: la dimensione del chunk come segnale di qualità
C’è un aspetto del chunking che raramente viene discusso fuori dalla letteratura accademica, e che ha implicazioni dirette per chi vuole farsi trovare grazie ai propri contenuti.
Zhu et al. (2024) lo mostrano in modo netto in uno studio sulla valutazione della generazione aumentata da retrieval:
“In an extreme case where the generated texts exactly match the reference texts, the number of chunks is only 1.”
Cosa significa? Quando un testo generato da un modello coincide perfettamente con il testo di riferimento, il sistema non ha bisogno di assemblare frammenti da sorgenti diverse: trova tutto in un singolo chunk.
Da questo segue una cosa interessante: un contenuto ben strutturato — che risponde a una domanda specifica in modo completo e autonomo all’interno di una singola sezione — tende a produrre chunk più “forti” nel senso retrieval del termine. Il sistema non deve cercare altrove perché ha già tutto lì.
Il numero di chunk necessari per rispondere a una query è, indirettamente, un proxy della qualità del tuo contenuto per quella query. Meno frammenti servono, più il tuo chunk è autosufficiente.
L’errore strutturale che quasi tutti fanno
Ho analizzato la struttura di decine di pagine di contenuto professionale — guide, articoli pillar, landing page con sezioni informative. Il problema ricorrente non è la qualità della scrittura. È la dipendenza tra sezioni.
Funziona così. Scrivi una guida completa su un argomento complesso. La sezione 3 introduce un concetto. La sezione 5 lo approfondisce. La sezione 7 lo applica con esempi. Ogni sezione, isolata, è incompleta — perché l’autore presupponeva che il lettore avesse già letto le sezioni precedenti.
Per un lettore umano che scorre la pagina dall’inizio, funziona. Per un sistema di retrieval che estrae la sezione 5 senza leggere la sezione 3, è un vicolo cieco.
Esempi concreti di costruzioni che uccidono un chunk:
- “Come abbiamo visto nella sezione precedente…”
- “Riprendendo il concetto introdotto sopra…”
- “Per chi ha già letto la guida all’inizio…”
- “Questo si collega a quanto detto riguardo a [termine non ridefinito]”
Ogni volta che usi una costruzione del genere, stai producendo un chunk che ha bisogno di contesto esterno per avere senso. Il sistema di retrieval non ha quel contesto. Il tuo chunk viene scartato o, peggio, genera una risposta parziale e imprecisa che non ti attribuisce.
Struttura che funziona per il retrieval
La regola operativa è semplice da enunciare, meno semplice da applicare: ogni sezione deve funzionare come un mini-articolo autonomo.
Questo non significa ripetere tutto dall’inizio in ogni sezione. Significa che ogni titolo di sezione pone una domanda implicita, e quella sezione la risponde in modo completo — senza rimandare ad altro, senza presupporre lettura pregressa, con il contesto chiave incluso.
Una sezione che funziona come chunk include:
- Il soggetto esplicito: non “questo meccanismo”, ma “il chunking nel RAG”. Non “la tecnica descritta sopra”, ma il nome completo del concetto.
- La risposta nella prima frase o nel primo paragrafo: le pipeline di retrieval tendono a dare più peso alle prime frasi di un chunk. Non costruire fino alla risposta — aprici con la risposta.
- Contesto sufficiente per essere capito senza il titolo della pagina: se il tuo chunk viene estratto e letto da solo, chi legge capisce di cosa si tratta? Includi il contesto della pagina nella sezione, non solo nell’header.
- Il tuo brand o la tua firma, se rilevante: se il sistema AI estrae solo questa sezione, il tuo nome o il tuo sito deve comparire lì, non solo nel footer o nel titolo.
La dimensione target è 200-500 token per sezione. Sotto i 200 token, il chunk spesso non ha abbastanza contesto per essere rilevante. Sopra i 500, rischi che il sistema tagli a metà la tua risposta in modo arbitrario.
Come farsene un’idea (primo passo)
Non servono strumenti professionali per fare una verifica iniziale. Basta un test di lettura isolata.
Prendi una pagina importante del tuo sito. Scegli una sezione nel mezzo — non la prima, non l’ultima. Leggila senza guardare il titolo della pagina e senza leggere le sezioni precedenti. Poi rispondi a queste domande:
- Di cosa parla questa sezione? (senza guardare il contesto)
- Risponde a una domanda specifica e completa?
- Il tuo brand o il nome del tuo sito compare da qualche parte?
- Contiene almeno una frase che potrebbe essere citata letteralmente come risposta a una query?
Se una delle risposte è no, hai trovato un chunk debole. Riscrivilo come se fosse il primo e unico paragrafo che un lettore — o un sistema AI — vedrà mai.
Vale la pena chiarire: questo test manuale dà un’idea di direzione, non una misurazione precisa. I sistemi di retrieval reali usano scoring vettoriale, BM25, reranking — variabili che non si replicano guardando una pagina nel browser. Per un’analisi seria del tuo profilo di chunk retrieval, servono strumenti professionali e test su più motori AI.
Il passaggio successivo nella pipeline
Il chunking è la fase di preparazione. Ma dopo che i chunk vengono recuperati, la pipeline non è finita. Nel prossimo articolo ti parlo del reranking — il passaggio in cui il sistema decide quali chunk meritano davvero di entrare nel prompt. E poi nel pezzo su grounding e citazione chiudo il cerchio: come il modello decide cosa citare e a chi attribuire.
Strutturare il contenuto per il chunk retrieval è un lavoro che si fa una volta sola ma cambia le probabilità in modo persistente. Non per ogni query — la stocasticità dei modelli è reale e nessuno può garantire un’apparizione specifica. Ma chi produce chunk autocontenuti e ben strutturati vede le probabilità crescere su tutte le query pertinenti, non solo su alcune.
