RAG-Chunking per chatbot IA: suddividere i contenuti in modo efficace

Un chatbot per siti web può rispondere in modo affidabile solo se trova i contenuti corretti al momento giusto. È qui che entra in gioco il RAG-Chunking: pagine lunghe, manuali e testi di supporto vengono suddivisi in unità più piccole che un componente di ricerca può recuperare in modo mirato. Blocchi troppo grandi contengono molte informazioni irrilevanti. Blocchi troppo piccoli perdono il contesto. Una buona suddivisione, quindi, non segue ciecamente un numero, ma si adatta alla struttura, al significato e all'uso futuro del contenuto.

Questa guida si rivolge ai team che gestiscono siti web, supporto e contenuti. Spiega come dividere i contenuti in modo semantico, conservare i metadati, ridurre le duplicazioni e verificare la strategia scelta tramite domande di ricerca reali. L'approccio è indipendente dal fornitore e può essere applicato sia alla ricerca vettoriale classica sia ai metodi di retrieval ibridi.

Perché il RAG-Chunking influisce sulla qualità delle risposte

Nella Retrieval-Augmented Generation, il sistema cerca prima i blocchi di conoscenza rilevanti e poi li trasmette al modello linguistico. I limiti dei chunk determinano quindi ciò che può essere trovato e utilizzato come contesto. Se una condizione di prezzo viene separata dalla sua eccezione, una ricerca formalmente corretta può comunque fornire una base incompleta. Se invece un chunk contiene un'intera pagina prodotto con navigazione, varianti e piè di pagina, il passaggio fondamentale entrerà in competizione con molto rumore di fondo.

Il chunking influisce su diverse dimensioni di qualità contemporaneamente:

• Rintracciabilità: l'informazione cercata rientra chiaramente in un'unità compatta?
• Coerenza: titolo, spiegazione, limitazioni ed esempi rimangono uniti?
• Precisione: il risultato contiene il minor numero possibile di elementi fuori tema?
• Tracciabilità: lo stralcio può essere attribuito a una fonte, una lingua e una versione valide?

Microsoft descrive metodi fissi, variabili e semantici, sottolineando come i titoli e altri elementi di layout possano essere usati per definire confini sensati. Anche AWS distingue tra strategie fisse, gerarchiche e semantiche. L'insegnamento pratico comune è semplice: la divisione tecnica dovrebbe seguire la struttura dei contenuti ogni volta che quest'ultima è presente in modo affidabile.

Iniziare con sezioni semantiche anziché tagli arbitrari

Un ottimo punto di partenza è la struttura della pagina già esistente. Titoli H2 e H3, paragrafi, elenchi, domande FAQ, tabelle e avvisi ben delimitati portano già con sé un significato. Una sezione sui termini di reso non dovrebbe interrompersi a metà frase o tra la regola e l'eccezione. Una domanda FAQ deve rimanere nello stesso chunk della sua risposta. In una guida, i passaggi operativi, i prerequisiti e gli avvisi dovrebbero, per quanto possibile, stare insieme.

Una logica pratica per definire i confini

1. Dividere prima in base ai titoli principali del documento e della pagina.
2. Verificare se una sezione tratta esattamente un argomento principale comprensibile.
3. Suddividere solo le sezioni troppo grandi per il retrieval o per il contesto del modello.
4. Unire frammenti molto brevi alla sezione adiacente più pertinente.
5. Aggiungere il titolo e il percorso della struttura come contesto a ciascuna parte.

Con un HTML o Markdown pulito, questo metodo è facilmente automatizzabile. PDF non strutturati, esportazioni non omogenee e documenti scansionati richiedono spesso un riconoscimento preventivo del layout o del testo. In questi casi, controllare attentamente tabelle, colonne, intestazioni e interruzioni di pagina: ciò che appare affiancato visivamente potrebbe finire nell'ordine errato durante l'estrazione.

Trattare la dimensione del chunk come valore di test, non come un dogma

Non esiste una dimensione ideale universale per i chunk. Microsoft indica 512 token con una sovrapposizione del 25% come possibile punto di partenza per determinati scenari, ma precisa che l'impostazione ottimale dipende dal contenuto e dal modello. Anche AWS documenta dimensioni e sovrapposizioni configurabili. Questi valori sono ipotesi di partenza utili, non una garanzia di qualità.

Risposte brevi nelle FAQ funzionano spesso come unità autonome. Istruzioni operative dettagliate richiedono più contesto. I testi legali o contrattuali non dovrebbero separare la regola, il campo di applicazione e l'eccezione. I confronti tra prodotti, d'altra parte, possono essere strutturati per righe o sezioni, a patto di includere le intestazioni delle colonne e il riferimento al prodotto.

Come riconoscere chunk troppo grandi o troppo piccoli

Un chunk è tipicamente troppo grande quando mescola diversi intenti di ricerca, quando la frase rilevante scompare tra la navigazione e le informazioni secondarie, o quando molti risultati restituiscono lo stesso blocco esteso. È troppo piccolo quando i pronomi perdono il loro riferimento, mancano i titoli, le condizioni vengono separate dalle affermazioni o sono necessari più frammenti per comprendere una semplice domanda.

Confrontare quindi almeno due o tre varianti utilizzando lo stesso set di domande. Modificare un solo parametro alla volta, ad esempio la dimensione target o la logica dei confini. In questo modo sarà chiaro cosa migliora effettivamente la qualità dei risultati e le fonti delle risposte.

La sovrapposizione protegge il contesto, ma crea anche duplicati

Una piccola sovrapposizione può evitare che una frase fondamentale vada persa proprio sul confine di un chunk. È particolarmente utile quando la suddivisione tecnica basata sulla lunghezza è inevitabile. Tuttavia, un'eccessiva sovrapposizione presenta controindicazioni: risultati quasi identici occupano più posizioni, aumentano la dimensione del contesto e rischiano di dominare artificialmente un'affermazione.

Utilizzare la sovrapposizione in modo mirato. Per le sezioni basate sulla struttura, spesso è sufficiente includere il titolo, il percorso della struttura e una breve transizione. Per i testi estesi, può essere utile mantenere una piccola percentuale della sezione precedente. Misurare poi se le diverse fonti rilevanti rimangono tra i primi risultati o se vengono scalzate dai duplicati.

I metadati rendono il chunk pronto per l'uso operativo

Il testo puro è raramente sufficiente per una knowledge base aziendale. Ogni chunk dovrebbe mantenere la propria origine e il proprio ambito di validità. AWS descrive i metadati come base per i filtri nelle query. In una knowledge base per siti web, i seguenti campi sono particolarmente utili:

• URL canonico della fonte e titolo della pagina,
• percorso delle intestazioni all'interno della pagina,
• lingua o locale,
• tipo di contenuto (es. FAQ, guida, policy o scheda prodotto),
• data di pubblicazione o di modifica,
• prodotto, regione o pubblico target, se rilevanti dal punto di vista aziendale,
• stato di accesso e autorizzazioni per i contenuti non pubblici.

Questo permette, ad esempio, di cercare solo tra i contenuti di supporto in italiano attualmente approvati. La fonte può anche essere inserita come link nella risposta e rielaborata in modo mirato in caso di aggiornamenti. Per scoprire come garantire l'aggiornamento sistematico, consultare la guida Mantenere aggiornata la knowledge base del chatbot IA.

Rimuovere boilerplate e duplicati prima dell'indicizzazione

Navigazione, banner dei cookie, blocchi di contatto ripetuti e piè di pagina globali non devono finire in ogni chunk. In caso contrario, si creerebbero centinaia di voci quasi identiche in grado di scalzare i contenuti reali. Rimuovere gli elementi ricorrenti della pagina prima della suddivisione e normalizzare spazi inutili, caratteri decorativi e frammenti tecnici.

Anche le duplicazioni di contenuto richiedono attenzione. Se la stessa regola di reso è formulata diversamente nelle pagine di aiuto, di prodotto e di spedizione, è necessario definire una fonte primaria ufficiale. Le copie obsolete devono essere rimosse, reindirizzate o deprioritizzate in modo chiaro. Nessun processo di chunking può trasformare fonti contraddittorie in una conoscenza affidabile.

Gestire con attenzione i casi particolari

Contenuti FAQ

Salvare domanda e risposta insieme. Per risposte molto brevi, integrare l'argomento generale di riferimento. Le varianti della stessa domanda possono aiutare la ricerca, ma non dovrebbero essere indicizzate come testo di risposta duplicato.

Tabelle ed elenchi

Una riga di tabella senza intestazioni di colonna è solitamente incomprensibile. Ripetere o richiamare i termini di intestazione rilevanti all'interno del chunk. Per gli elenchi lunghi, ogni parte dovrebbe mantenere il titolo dell'elenco e l'introduzione comune. Dopo l'estrazione, verificare che i valori siano ancora associati alla caratteristica corretta.

Pagine multilingue

Separare i contenuti per locale e salvare la lingua come metadato. Una query in italiano non dovrebbe restituire per errore una sezione in inglese obsoleta solo perché contiene termini simili. Identificatori comuni di traduzione o di pagina aiutano a collegare le varianti senza mescolarle nello stesso blocco di testo.

Eseguire test di retrieval prima di valutare la risposta

Valutare prima se la ricerca restituisce il passaggio corretto. Solo successivamente giudicare la formulazione generata dal modello linguistico. Un piccolo Golden Set composto da domande reali degli utenti dovrebbe includere quesiti chiari, sinonimi, richieste articolate, casi limite e domande prive di risposta nei documenti. Per ogni domanda, definire in anticipo quale fonte o sezione ci si aspetta di trovare.

Verificare almeno:

• se la sezione attesa appare tra i primi risultati,
• se risultati irrilevanti o duplicati scalzano fonti importanti,
• se tutte le condizioni e le eccezioni necessarie sono presenti nel contesto fornito,
• se la fonte e il suo stato di aggiornamento rimangono tracciabili,
• se il sistema evita in modo sicuro di inventare risposte in mancanza di informazioni.

L'articolo Misurare la qualità delle risposte dei chatbot IA con Golden Set e test RAG descrive il processo di verifica idoneo. Per riferimenti trasparenti, la guida Supportare le risposte del chatbot con le fonti integra la prospettiva sulla verifica dei link e sulla gestione dell'incertezza.

Checklist per l'implementazione

1. Mappare i contenuti: catalogare tipi di pagina, lingue, formati e fonti di riferimento.
2. Verificare l'estrazione: controllare titoli, tabelle e ordine di lettura su campioni rappresentativi.
3. Definire i confini: privilegiare le sezioni semantiche e usare dimensioni fisse solo come logica di riserva.
4. Preservare il contesto: includere titolo della pagina, percorso dei titoli e transizioni necessarie.
5. Pianificare i metadati: salvare in modo strutturato URL, locale, data di aggiornamento, tipo di contenuto e autorizzazioni.
6. Rimuovere i duplicati: pulire boilerplate e copie contraddittorie prima dell'indicizzazione.
7. Testare le varianti: confrontare dimensioni e sovrapposizioni utilizzando lo stesso Golden Set.
8. Monitorare la gestione: analizzare regolarmente i mancati recuperi, le fonti obsolete e il feedback degli utenti.

Conclusione: i buoni chunk sono unità di conoscenza chiare

Il RAG-Chunking non è un'impostazione tecnica una tantum, ma una vera e propria architettura dei contenuti per il retrieval automatico. I chunk efficaci rispondono a un'esigenza specifica, mantengono il contesto necessario e si ricollegano a una fonte valida. Titoli, metadati e una sovrapposizione controllata sono importanti tanto quanto la semplice lunghezza del testo.

Iniziare con pochi tipi di contenuto rappresentativi, misurare il retrieval prima dello stile di risposta e documentare ogni modifica. Se desideri creare un chatbot per il tuo sito web basato su una knowledge base ben strutturata, troverai il punto di partenza ideale nella panoramica delle funzionalità di ChatReact.

Fonti

• Microsoft Learn: Chunk large documents for vector search solutions in Azure AI Search
• Microsoft Learn: Chunk and vectorize by document layout
• AWS Bedrock: How content chunking works for knowledge bases
• AWS Bedrock: Include metadata in a data source