{"id":1999,"date":"2026-03-19T16:07:10","date_gmt":"2026-03-19T15:07:10","guid":{"rendered":"https:\/\/userbot.ai\/blog\/?p=1999"},"modified":"2026-04-01T10:25:06","modified_gmt":"2026-04-01T08:25:06","slug":"chunking-la-decisione-che-cambia-tutto","status":"publish","type":"post","link":"https:\/\/userbot.ai\/blog\/chunking-la-decisione-che-cambia-tutto\/","title":{"rendered":"Chunking: la decisione che nessuno vede ma che cambia tutto"},"content":{"rendered":"\n

Come abbiamo imparato, che dividere i documenti in blocchi non \u00e8 un dettaglio tecnico, ma una scelta che determina la qualit\u00e0 di ogni risposta del sistema RAG.<\/em><\/strong><\/p>\n\n\n\n

\n\n\n\n

Quando abbiamo costruito il nostro primo sistema RAG, eravamo convinti che la parte difficile fosse il modello linguistico. Il chunking, cio\u00e8 come dividere i documenti sorgente in blocchi prima di indicizzarli, sembrava una formalit\u00e0. “Taglia a 500 caratteri e vai”, ci dicevamo.<\/p>\n\n\n\n

Qualche mese di produzione ci ha convinti del contrario. La qualit\u00e0 delle risposte che un sistema RAG produce dipende in modo diretto da come i documenti vengono spezzati: chunk troppo piccoli perdono il contesto, chunk troppo grandi introducono rumore. Un PDF tagliato a met\u00e0 frase restituisce risposte incomprensibili. Una tabella Excel frammentata diventa inutilizzabile. E nessuno di questi problemi \u00e8 visibile finch\u00e9 non si guarda il comportamento del sistema su casi reali.<\/p>\n\n\n\n

Questo articolo racconta come abbiamo affrontato il problema, le soluzioni che abbiamo adottato, i parametri che teniamo sotto controllo, e le lezioni che abbiamo imparato nel tempo. Non \u00e8 una guida teorica: \u00e8 quello che facciamo ogni giorno in produzione.<\/p>\n\n\n\n

Il punto di partenza: non esiste un chunking universale<\/strong><\/strong><\/h3>\n\n\n\n

La prima cosa da tenere presente \u00e8 che trattare tutti i documenti allo stesso modo \u00e8 il sistema pi\u00f9 rapido per ottenere risultati mediocri su tutti. Un contratto in PDF ha una struttura completamente diversa da un file JSON con dati strutturati. Un articolo in Markdown con tabelle e immagini non \u00e8 semplicemente “testo da dividere”. Un foglio Excel non pu\u00f2 essere frammentato senza logica.<\/p>\n\n\n\n

Abbiamo quindi costruito un sistema di ingestion che riconosce il tipo di documento<\/strong> e applica una strategia di chunking specifica<\/strong>. Oggi gestiamo sei strategie diverse, ognuna ottimizzata per un formato. Non \u00e8 la soluzione definitiva, continuiamo a iterare, ma \u00e8 una base molto pi\u00f9 solida del “taglia ovunque” con cui eravamo partiti.<\/p>\n\n\n\n

\n

Il chunking giusto non \u00e8 quello pi\u00f9 elegante tecnicamente. \u00c8 quello che preserva il significato che l’utente cercher\u00e0 quando far\u00e0 una domanda.<\/em><\/p>\n<\/blockquote>\n\n\n\n

I diversi tipi di documento<\/strong>: quale chunking e quali parametri?<\/strong><\/h3>\n\n\n\n
1. PDF e documenti testuali<\/strong><\/h5>\n\n\n\n

Quelli che a prima vista sono semplici testi, in realt\u00e0 camuffano uno scoglio che sembra insormontabile: documenti densi, paragrafi lunghi, a volte tabelle e figure nel mezzo. Il taglio fisso, chiaramente, spezzava le frasi a met\u00e0 e le risposte erano incomprensibili. <\/p>\n\n\n\n

La soluzione che abbiamo adottato si chiama Sentence Window Retrieval<\/strong>: dividiamo per frasi complete, e attorno a ogni chunk manteniamo una finestra di contesto (sei frasi, tre prima e tre dopo). Questo garantisce che nessun chunk sia mai una frase monca e che il modello abbia sempre abbastanza contesto per rispondere in modo coerente. Abbiamo aumentato la finestra da tre a sei frasi nel gennaio 2025, e la differenza sulla qualit\u00e0 del retrieval \u00e8 stata immediata!<\/p>\n\n\n\n

\n
    \n
  1.  Are sunbeds and umbrellas subject to charges?<\/em> <\/strong>No, there is no charge for the pool area sunbeds and umbrellas.<\/li>\n<\/ol>\n\n\n\n
      \n
    1.  <\/strong>Is the swimming pool area only open in high season?<\/em> The swimming pool area is open from May to the end of September, with different times depending on the season.<\/li>\n<\/ol>\n\n\n\n
        \n
      1.  <\/strong>Are the swimming pools heated?<\/em> No.<\/mark><\/li>\n<\/ol>\n\n\n\n
          \n
        1.  <\/strong>Is the use of bathing cap mandatory?<\/em> Yes.<\/mark> It is mandatory to wear a cap, both for adults and children. If you have forgotten it, they can be purchased at pool bar.<\/li>\n<\/ol>\n\n\n\n
            \n
          1.  <\/strong>Which are the swimming pool area opening hours?<\/em> The swimming pool area is open continuously from approximately 10:00 AM to 6:00 PM. Hours may vary depending on seasonality.<\/mark> In case of bad weather, the area may remain closed.<\/li>\n<\/ol>\n<\/div><\/div>\n\n\n\n

            Prendiamo ad esempio il testo riportato qui sopra, un semplicissimo documento di FAQ.<\/p>\n\n\n\n

            La finestra di contesto permette alle frasi compiute evidenziate in giallo di avere un contesto adeguato in cui inserirle. Senza la finestra di contesto, infatti, sarebbero frasi semanticamente prive di significato o con un significato parziale.<\/p>\n\n\n\n

            2. Il formato markdown<\/strong><\/h5>\n\n\n\n

            Il formato markdown con la sua formattazione di tabelle e immagini<\/strong> ci ha insegnato che “\u00e8 solo testo” \u00e8 una semplificazione pericolosa. Le tabelle spezzate a met\u00e0 diventano incomprensibili; le immagini, se non trattate separatamente, spariscono.<\/p>\n\n\n\n

            Abbiamo, quindi, costruito un chunker specifico<\/strong> per Markdown che identifica ed estrae le tabelle come chunk autonomi, preserva gli URL delle immagini nei metadata, e divide il testo rimanente per frasi. \u00c8 pi\u00f9 complesso da mantenere, ma molto efficace. Ci permette, infatti, di trattare documenti ricchi senza perdere informazioni.<\/p>\n\n\n\n

               **\\#PRICELIST\\_EXTRA\\_SERVICE**  
               **\\*\\*Questions\\*\\***  
            1. **How much does a service cost?**  
            2. **I need information about services' costs**  
            3. **Can you provide me with the price list?**  
               **\\*\\*Response\\*\\***  
                <\/pre>\n\n\n\n
            | SERVICE | PRICE | MORE INFO | 
            |—————|—————|—————————–| 
            | SWIMMING CAP | \u20ac 2,50 | To buy at pool bar | 
            | TOWELS SET | \u20ac 12,00 | One big towel and one small | 
            | WASHING MACHINE | \u20ac 5,00 | To pay in Euro coins, in the machine. Soap not provided | 
            | DRYER | \u20ac 5,00 | To pay by credit\/debit card, at machine | 
            | SUNBEDS AND UMBRELLA | \u20ac 25,00 \\- \u20ac 35,00 | The price is for 2 sunbeds and 1 umbrella for an entire day at bathing beach Lido. 35\u20ac is the price in the first line, 25\u20ac from the third row. Service subject on availability. | 
            | BUFFET BREAKFAST | \u20ac 15,00 | per person per day | 
            | SHUTTLE BUS | \u20ac 2,00 | per person, one way | 
            | WiFi | \u20ac 1,00 (1 h) \u20ac 3,00 (24h) \u20ac 7,00 (3 days \/ 3 giorni) \u20ac 10,00 (7 days \/ 7giorni) | One code is for 2 devices at the same time. | <\/p>\n\n\n\n
            In questo esempio vediamo come il testo \u00e8 stato nettamente diviso tra la parte puramente testuale e la parte tabellare.<\/p>\n\n\n\n
            3. JSON e dati strutturat<\/strong>i<\/h5>\n\n\n\n
            Con i json o i dati strutturati non lavoriamo per frasi ma per token<\/strong>: chunk da 1000 token ciascuno, senza sovrapposizione. La scelta di zero overlap \u00e8 deliberata: per dati strutturati, la prevedibilit\u00e0 sui costi di embedding e la pulizia della struttura contano pi\u00f9 della continuit\u00e0 tra chunk adiacenti. I metadata compensano la potenziale perdita di contesto, tracciando ogni chunk al documento e alla posizione originale.<\/p>\n\n\n\n
            4. Gli intenti (Q&A)<\/h5>\n\n\n\n
            I Q&A configurati <\/strong>dai clienti (domande e risposte precise che definiscono come il bot deve rispondere a certi input) vengono gestiti in modo diverso a seconda del tipo. I casi di corrispondenza esatta o per parole chiave vengono risolti fuori dal sistema RAG con delle logiche di stemming. <\/p>\n\n\n\n
            Nel caso della similitudine invece, dove entra in gioco l’analisi semantica, raggruppiamo le diverse frasi di esempio dell’input con la risposta. Quindi indicizziamo ogni intento (Q&A) come chunk indipendente<\/strong> e lo confrontiamo singolarmente con la domanda utente.<\/p>\n\n\n\n
            5. Excel<\/h5>\n\n\n\n
            Infine, Excel<\/strong>: ogni riga conta. <\/strong>Suddividiamo l’intero foglio in righe. La logica \u00e8 semplice: la chiave, in ogni tabella, \u00e8 la combinazione di ogni riga con l’intestazione di ogni colonna. Ecco perch\u00e9 facciamo un chunking per riga + intestazione.<\/p>\n\n\n\n
            Name<\/td>Typology<\/td>Description<\/td>Cost<\/td><\/tr>
            Product 1<\/td>Base<\/td>Product 1 is a product for requirement number 1.<\/td>1\u20ac<\/td><\/tr>
            Product 2<\/td>Base<\/td>Product 2 is a product for requirement number 2.<\/td>2\u20ac<\/td><\/tr>
            Product 3<\/td>Advanced<\/td>Product 3 is a product for requirement number 3.<\/td>3\u20ac<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
            In questo caso, per esempio, avremo tre chunk in output cos\u00ec composti:<\/p>\n\n\n\n
            Name: Product 1<\/td>Typology: Base<\/td>Description: Product 1 is a product for requirement number 1.<\/td>Cost: 1\u20ac<\/td><\/tr>
            Name: Product 2<\/td>Typology: Base<\/td>Description: Product 2 is a product for requirement number 2.<\/td>Cost: 2\u20ac<\/td><\/tr>
            Name: Product 3<\/td>Typology: Advanced<\/td>Description: Product 3 is a product for requirement number 3.<\/td>Cost: 3\u20ac<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
            6. I casi speciali<\/h5>\n\n\n\n
            Ovviamente le cinque tipologie di formato non coprono tutti casi. Per ora, quindi, per formati proprietari o non standard<\/strong>, abbiamo infine una strategia configurabile<\/strong>: un delimitatore personalizzato \u2014 per esempio un simbolo specifico come “|” \u2014 che permette di adattare il chunking a qualsiasi formato che i clienti potrebbero portare nel sistema.<\/p>\n\n\n\n
            Definire la strategia per tipo di documento \u00e8 solo il primo livello del percorso.  <\/p>\n\n\n\n
            \n
            Il bello dei parametri  \u00e8 che non sono scolpiti nella pietra. Li possiamo integrare e migliorare continuamente sulla base dei feedback reali degli utenti <\/em>.<\/p>\n<\/blockquote>\n\n\n\n
            I trade-off che abbiamo imparato<\/strong><\/strong><\/h3>\n\n\n\n
            Come abbiamo visto, ogni scelta di chunking \u00e8 un compromesso<\/strong>. Non esiste la configurazione ottimale in assoluto, ma esiste quella pi\u00f9 adatta al caso d’uso specifico. Avere chiarezza sui trade-off che si stanno accettando \u00e8 il modo per prendere decisioni consapevoli e prevenire e mitigare le conseguenze in produzione.<\/p>\n\n\n\n
            Chunk pi\u00f9 piccoli<\/strong> migliorano la precisione del retrieval ma aumentano i costi di embedding e riducono il contesto disponibile. <\/p>\n\n\n\n
            Chunk pi\u00f9 grandi<\/strong> preservano pi\u00f9 contesto semantico ma introducono rumore e rallentano il sistema. Per esempio, la finestra di sei frasi che usiamo per i documenti testuali (PDF, word, txt) \u00e8 un equilibrio deliberato tra questi due estremi.<\/p>\n\n\n\n
            Stesso discorso per lo zero overlap sui JSON, un’altra scelta consapevole. Sappiamo che al confine tra due chunk consecutivi pu\u00f2 esserci perdita di contesto. Abbiamo accettato questo rischio perch\u00e9 per dati strutturati la prevedibilit\u00e0 e l’efficienza contano pi\u00f9 della continuit\u00e0 narrativa. <\/p>\n\n\n\n
            Come vedremo nel prossimo paragrafo, i metadata, che tracciano ogni chunk alla sua posizione nel documento originale, mitigano parzialmente il problema.<\/p>\n\n\n\n
            I metadata: la parte invisibile che tiene tutto insieme<\/strong><\/h3>\n\n\n\n
            Ogni chunk non \u00e8 un’entit\u00e0 isolata: porta con s\u00e9 un set di informazioni che permettono di tracciarlo, contestualizzarlo e, quando qualcosa va storto, diagnosticarlo. Sono proprio i metadati<\/strong>.<\/p>\n\n\n\n
            Nel nostro sistema, ogni chunk contiene diversi metadati: <\/p>\n\n\n\n
              \n
            • gli identificatori del documento originale, <\/li>\n\n\n\n
            • gli identificatori del flusso e del bot a cui appartiene; <\/li>\n\n\n\n
            • il contesto delle frasi adiacenti (in base al tipo di documento); <\/li>\n\n\n\n
            • il tipo di contenuto (testo, tabella, immagine). <\/li>\n<\/ul>\n\n\n\n
              Queste informazioni vengono aggiunte prima del chunking e preservate durante tutto il processo di embedding e retrieval.<\/p>\n\n\n\n
              Sembra un dettaglio implementativo. In realt\u00e0 \u00e8 quello che rende il sistema governabile<\/strong>. Senza metadata, quando un agente restituisce una risposta sarebbe impossibile risalire a quale chunk l’ha generata, da quale documento proveniva, e perch\u00e9 \u00e8 stato recuperato. Con metadata ricchi, queste informazioni sono sempre recuperabili e permettono di agire sull’agente con governance e trasparenza.<\/p>\n\n\n\n
              Nella nostra piattaforma, infatti, \u00e8 possibile mostrare sia sulla chat di conversazione che nella parte di analisi, quali sono le fonti utilizzate dall’agente per rispondere e i singoli chunk recuperati dal RAG.<\/p>\n\n\n\n
              \n
              \n
              \"\"
              Fonti della risposta<\/figcaption><\/figure>\n<\/div>\n\n\n\n
              \n
              \"\"
              Chunking utilizzati nella risposta<\/figcaption><\/figure>\n<\/div>\n<\/div>\n\n\n\n
              \n
              Un chunk senza metadata \u00e8 come una citazione senza fonte: manca di trasparenza. Puoi usarla, ma non puoi verificarla, correggerla, n\u00e9 capire perch\u00e9 \u00e8 l\u00ec.<\/em><\/p>\n<\/blockquote>\n\n\n\n
              Le lezioni che abbiamo imparato e che vogliamo condividere<\/strong><\/strong><\/strong><\/h3>\n\n\n\n
              Guardando indietro all’evoluzione del nostro sistema, ci piace l’idea di aver imparato tanto. Ecco le nostre “lessons learned”:<\/p>\n\n\n\n
              La lezione pi\u00f9 importante \u00e8 che il chunking \u00e8 una decisione architettonica<\/strong>, non un parametro di configurazione. Cambiare la dimensione dei chunk o la strategia di overlap dopo che il sistema \u00e8 in produzione non \u00e8 un aggiustamento: \u00e8 una migrazione. Richiede di re-indicizzare tutto, di riverificare il comportamento del retrieval, di testare nuovamente i casi limite. Il valore di questa decisione \u00e8 immenso e vale la pena investire all’inizio in fase di analisi.<\/p>\n\n\n\n
              La seconda lezione \u00e8 che la qualit\u00e0 del chunking<\/strong> non si vede nei test. Si vede quando un utente reale pone una domanda che nessuno aveva previsto e il sistema non riesce a rispondere; non perch\u00e9 l’informazione non ci sia, ma perch\u00e9 il chunk che la contiene \u00e8 stato tagliato nel posto sbagliato. I test controllati non coprono mai abbastanza la variet\u00e0 del linguaggio naturale in produzione.<\/p>\n\n\n\n
              La terza \u2014 e forse la pi\u00f9 controintuitiva \u2014 \u00e8 che migliorare il chunking spesso vale pi\u00f9 che migliorare il modello<\/strong>. Un sistema RAG con chunking ottimizzato e un modello buono performa meglio di un sistema con chunking approssimativo e un modello eccellente. La qualit\u00e0 dell’output dipende dalla qualit\u00e0 dell’input che arriva al modello, e quella dipende dal chunking. <\/p>\n\n\n\n
              \n
              Iterare sul chunking \u00e8 probabilmente l’intervento con il miglior rapporto tra sforzo e impatto in un sistema RAG maturo. \u00c8 meno visibile che cambiare modello, ma quasi sempre pi\u00f9 efficace.<\/em><\/p>\n<\/blockquote>\n\n\n\n
              Una decisione che vale la pena fare bene<\/strong><\/strong><\/h3>\n\n\n\n
              Chi commissiona o supervisiona un sistema RAG raramente ha motivo di entrare nel dettaglio del chunking. <\/p>\n\n\n\n
              Il processo di chunking, infatti, non \u00e8 una manopola che pu\u00f2 essere regolata a piacere dal cliente o da chi implementa il progetto. \u00c8 una decisione architetturale<\/strong>, che richiede competenze specifiche e che impatta tutto il prodotto. \u00c8 una scelta tecnica<\/strong>, delegata al team che costruisce il sistema. <\/p>\n\n\n\n
              Ma \u00e8 utile sapere che quella scelta esiste, che ha un impatto diretto sulla qualit\u00e0 delle risposte, e che “funziona” nei test non \u00e8 necessariamente la stessa cosa che “funziona” in produzione.<\/p>\n\n\n\n
              La chiave quindi sono le domande giuste da farsi, quando si valuta o si supervisiona un sistema RAG: <\/p>\n\n\n\n
                \n
              • come vengono trattati i diversi tipi di documento? <\/li>\n\n\n\n
              • su quali parametri si \u00e8 iterato, e perch\u00e9? <\/li>\n\n\n\n
              • quando il sistema sbaglia, \u00e8 possibile risalire al chunk che ha generato l’errore? <\/li>\n<\/ul>\n\n\n\n
                Se il team ha risposte chiare a queste domande, \u00e8 probabile che il chunking sia stato affrontato con la seriet\u00e0 che merita. Se le risposte sono vaghe, vale la pena approfondire.<\/p>\n\n\n\n
                Non \u00e8 tutto oro quel che luccica e, anche noi, abbiamo speso mesi di analisi e parecchi errori per arrivare a un sistema che consideriamo robusto. Non \u00e8 perfetto \u2014 continuiamo a iterare \u2014 ma \u00e8 costruito su scelte consapevoli, parametrizzate e documentate. Ed \u00e8 esattamente da l\u00ec che, nella nostra esperienza, si parte per costruire un sistema RAG che funziona davvero. Considerato che \u00e8 infatti una scelta strutturale e spesso irreversibile nel breve periodo, \u00e8 una decisione che vale la pena fare bene.<\/p>\n","protected":false},"excerpt":{"rendered":"Come abbiamo imparato, che dividere i documenti in blocchi non \u00e8 un dettaglio tecnico, ma una scelta che…","protected":false},"author":7,"featured_media":2038,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_monsterinsights_skip_tracking":false,"_monsterinsights_sitenote_active":false,"_monsterinsights_sitenote_note":"","_monsterinsights_sitenote_category":0,"csco_display_header_overlay":false,"csco_singular_sidebar":"","csco_page_header_type":"","csco_page_load_nextpost":"","csco_page_reading_time":"","csco_page_toc_navigation":"","csco_post_video_location":[],"csco_post_video_location_hash":"","csco_post_video_url":"","csco_post_video_bg_start_time":0,"csco_post_video_bg_end_time":0,"csco_post_video_bg_volume":false,"footnotes":""},"categories":[1,109,41,24],"tags":[],"class_list":{"0":"post-1999","1":"post","2":"type-post","3":"status-publish","4":"format-standard","5":"has-post-thumbnail","7":"category-senza-categoria","8":"category-ai-business","9":"category-intelligenza-artificiale","10":"category-tecnologia","11":"cs-entry","12":"cs-video-wrap"},"_links":{"self":[{"href":"https:\/\/userbot.ai\/blog\/wp-json\/wp\/v2\/posts\/1999","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/userbot.ai\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/userbot.ai\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/userbot.ai\/blog\/wp-json\/wp\/v2\/users\/7"}],"replies":[{"embeddable":true,"href":"https:\/\/userbot.ai\/blog\/wp-json\/wp\/v2\/comments?post=1999"}],"version-history":[{"count":11,"href":"https:\/\/userbot.ai\/blog\/wp-json\/wp\/v2\/posts\/1999\/revisions"}],"predecessor-version":[{"id":2050,"href":"https:\/\/userbot.ai\/blog\/wp-json\/wp\/v2\/posts\/1999\/revisions\/2050"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/userbot.ai\/blog\/wp-json\/wp\/v2\/media\/2038"}],"wp:attachment":[{"href":"https:\/\/userbot.ai\/blog\/wp-json\/wp\/v2\/media?parent=1999"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/userbot.ai\/blog\/wp-json\/wp\/v2\/categories?post=1999"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/userbot.ai\/blog\/wp-json\/wp\/v2\/tags?post=1999"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}