AI Chunking nei sistemi RAG enterprise: strategie, modelli multimodali e architettura hardware

Quando un progetto di AI generativa non produce i risultati attesi, la causa raramente si trova nel modello scelto. Più spesso si trova a monte, nella qualità con cui i documenti aziendali vengono preparati per essere interrogati. È lì che il divario tra un sistema RAG efficace e uno che produce risposte imprecise si decide davvero.

L’AI chunking è il processo che governa questa fase. Capire come funziona, quali strategie esistono e come si traduce in scelte architetturali concrete è il punto di partenza per chi deve valutare, progettare o ottimizzare un sistema di intelligenza artificiale su documenti aziendali complessi.

Questo articolo affronta il tema dal punto di vista operativo: dalle strategie di segmentazione all’approccio multimodale, fino alla scelta strategica tra GPU o CPU per workload documentali enterprise. I dati presentati in questo articolo non sono teorici, ma provengono da una sperimentazione condotta insieme a Intel su architetture reali, con benchmark misurabili.

Scarica l’analisi estesa della sperimentazione: metodologia, architettura del sistema, dati di benchmark e considerazioni infrastrutturali per l’adozione in contesti aziendali.

Scarica il whitepaper

Cos’è l’AI chunking e perché determina la qualità dei sistemi RAG

Quando un modello di AI deve interrogare un documento, non può leggerlo come farebbe una persona. Per poter essere elaborato, il documento deve essere prima suddiviso in piccoli blocchi informativi, i chunk, che vengono poi trasformati in rappresentazioni vettoriali utilizzate nei sistemi RAG. 

Quando un utente formula una domanda, il sistema recupera i chunk più pertinenti alla query e li usa come contesto per generare la risposta. La qualità di questo recupero, e dunque la qualità della risposta finale, dipende direttamente da come i chunk sono stati costruiti. 

La qualità di questa fase è determinante: se i chunk vengono generati in modo impreciso, il sistema perde contesto e le risposte dell’AI diventano meno affidabili. In contesti enterprise, dove i documenti includono procedure operative, specifiche tecniche, contratti o report finanziari, questa imprecisione ha un impatto diretto sulle decisioni che vengono prese sulla base di quell’informazione.  

Le strategie di AI chunking: quale scegliere e quando

Non esiste una strategia di AI chunking universalmente valida. La scelta dipende dalla struttura dei documenti, dalla complessità semantica del contenuto e dalle esigenze operative del sistema RAG. Le metodologie principali si distinguono per il criterio con cui definiscono i confini tra un chunk e il successivo: 

Il fixed-size chunking suddivide il testo in segmenti di lunghezza uniforme, misurata in token o caratteri. È rapido da implementare e computazionalmente economico, ma soffre di un limite strutturale rilevante: non tiene conto del significato del testo, spezzando frequentemente concetti e frasi nel mezzo; 

Il recursive chunking usa una gerarchia di separatori — paragrafi, interruzioni di riga, confini di frase — per preservare la struttura del documento. È il punto di partenza consigliato per la maggior parte dei casi d’uso RAG, con una dimensione ottimale intorno ai 400-512 token: bilancia semplicità implementativa e qualità semantica su contenuti testuali strutturati; 

Il semantic chunking raggruppa il testo in base al significato, non ai confini fisici. Produce una qualità di retrieval superiore, ma richiede una pipeline di elaborazione più complessa e costi computazionali maggiori; 

L’agentic chunking porta l’approccio semantico a un livello ulteriore: invece di applicare regole predefinite, un agente basato su LLM analizza il documento, comprende le relazioni tra le sue parti e decide dinamicamente dove e come segmentare. È l’unico approccio che si adatta alla struttura specifica di ogni documento anziché applicare una logica uniforme, ed è quello che produce i risultati più precisi su archivi documentali enterprise eterogenei e complessi. 

Il rischio dell’overlap

Ogni strategia di chunking deve gestire un problema strutturale: i confini tra chunk spezzano inevitabilmente il flusso informativo. Quando un concetto si trova esattamente su quel confine, viene distribuito tra due blocchi e il modello fatica a ricostruirlo in modo coerente. 

L’overlap , ossia la sovrapposizione tra chunk adiacenti, è il meccanismo che attenua questo problema. La pratica raccomandata è mantenere una sovrapposizione tra il 10% e il 20% della dimensione del chunk: su un chunk da 512 token, significa conservare tra 50 e 100 token condivisi con il blocco successivo. Il valore ottimale non è fisso: va testato sul dataset reale, in funzione della densità semantica del contenuto e del tipo di query che il sistema dovrà gestire. 

Perché i documenti complessi richiedono un approccio multimodale

Le strategie di chunking tradizionali condividono un limite che diventa critico quando si lavora su documenti aziendali reali. Tradizionalmente, i sistemi di chunking trattano separatamente gli elementi di un documento: il testo viene analizzato come testo, le immagini come immagini e le tabelle come strutture isolate. Tuttavia, nei documenti reali questi elementi convivono nella pagina e contribuiscono insieme alla comprensione dell’informazione. 

Nei manuali tecnici industriali, nei cataloghi prodotti, nei report finanziari con grafici e note a piè di pagina, questa separazione artificiale produce perdita di informazione misurabile. Un grafico è interpretabile correttamente solo in relazione alla didascalia che lo accompagna. Una tabella numerica acquista significato pieno solo nel contesto del paragrafo che la introduce. Scomporre questi elementi e analizzarli separatamente significa costruire chunk che contengono pezzi di informazione anziché unità semantiche complete. 

L’approccio alternativo consiste nel trattare ogni pagina del documento come una singola entità visiva, analizzandola nel suo insieme invece di scomporla artificialmente. Attraverso modelli multimodali, ogni pagina viene interpretata come un’unità completa che include testo, grafica, struttura e relazioni tra gli elementi, consentendo di generare chunk più coerenti dal punto di vista semantico e più fedeli al contenuto originale del documento. 

Per i sistemi RAG enterprise che devono rispondere a query complesse su archivi documentali eterogenei, questa differenza si traduce direttamente in una qualità di risposta superiore e in una riduzione delle allucinazioni generate dalla perdita di contesto tra elementi della stessa pagina. 

La domanda infrastrutturale: GPU o CPU per workload documentali?

Nel dibattito corrente sull’AI, la GPU viene spesso presentata come scelta predefinita per qualsiasi workload di inferenza, ma il caso dei workload documentali enterprise è uno di quelli in cui vale la pena mettere in discussione il pregiudizio architetturale prima di prendere decisioni di investimento. 

Molti workload documentali presentano caratteristiche diverse rispetto ai classici scenari di inferenza real-time. In molti casi, le operazioni di elaborazione dei documenti vengono eseguite in modalità batch, non richiedono tempi di risposta immediati e possono essere pianificate in modo asincrono. In questi contesti, la priorità diventa l’efficienza operativa più che la latenza. 

Le istanze GPU costano da 5 a 10 volte di più per ora rispetto alle CPU. Per workload asincroni in cui la latenza non è un requisito primario, questa differenza di costo non si giustifica automaticamente con un vantaggio operativo equivalente. La domanda che ogni IT Manager e CIO è: qual è il workload specifico e quali sono le sue reali priorità operative? 

È proprio questa domanda che abbiamo deciso di affrontare con dati reali. 

La sperimentazione WeAreProject & Intel: 1.000 pagine all’ora su architettura CPU

Abbiamo condotto una sperimentazione insieme a Intel con l’obiettivo di esplorare un approccio più efficace alla gestione di documenti complessi e, allo stesso tempo, verificare se nuove architetture CPU possano rappresentare un’alternativa concreta alle infrastrutture GPU nei workload documentali. 

Vuoi conoscere i dettagli tecnici completi della sperimentazione?

Scarica il whitepaper

Cosa abbiamo appreso dalla sperimentazione

Nei workload documentali basati su batch processing e architetture asincrone, le infrastrutture CPU possono rappresentare una soluzione estremamente efficace. In particolare, le nuove generazioni di processori offrono livelli di performance tali da rendere possibile l’esecuzione di modelli multimodali anche senza ricorrere a GPU dedicate, con benefici evidenti in termini di semplificazione infrastrutturale, riduzione dei costi e scalabilità operativa. 

L’esperienza maturata in questo progetto ci ricorda che la vera sfida dell’AI nelle organizzazioni non riguarda soltanto gli algoritmi: riguarda soprattutto le architetture che rendono queste soluzioni sostenibili. Saper scegliere quando utilizzare GPU e quando invece adottare soluzioni CPU-based, progettare pipeline asincrone e ottimizzare i workload documentali sono elementi fondamentali per portare l’AI fuori dai laboratori e dentro i processi aziendali. 

Domande frequenti sull’AI chunking

Quale strategia di AI chunking è più adatta per documenti aziendali complessi?

Dipende dalla struttura dei documenti. Per documenti prevalentemente testuali e ben strutturati, il recursive chunking tra 400 e 512 token è il punto di partenza più solido. Per documenti che includono tabelle, grafici e layout eterogenei — manuali tecnici, cataloghi, report finanziari — l’approccio multimodale con agentic chunking produce risultati significativamente superiori, perché tratta ogni pagina come un’unità semantica integrata invece di scomporla in livelli separati. 

Quando conviene valutare un’infrastruttura CPU invece di GPU per workload AI documentali? 

Quando il workload è batch e asincrono, ovvero quando l’elaborazione non richiede tempi di risposta immediati e può essere pianificata. In questi contesti, il vantaggio di latenza della GPU non si traduce in un beneficio operativo misurabile, a fronte di costi orari fino a 10 volte superiori. La sperimentazione WeAreProject & Intel ha dimostrato che, in questo tipo di scenario, un’architettura CPU-only su Intel Xeon 6 raggiunge obiettivi di throughput enterprise in modo efficace e con un profilo di costo significativamente più sostenibile. 

Il chunking influisce sui costi API del sistema RAG? 

In modo diretto. Una strategia inefficiente genera chunk ridondanti o con sovrapposizioni eccessive, aumentando il volume di token elaborati per ogni query. In un contesto enterprise con migliaia di documenti e centinaia di utenti, questa inefficienza si moltiplica sui costi operativi complessivi. Ottimizzare il chunking prima dell’indicizzazione riduce il rumore nella base vettoriale, migliora la precisione del retrieval e contiene la spesa per query — tre metriche che ogni CIO monitora. 

Compila il form e scarica i risultati completi della sperimentazione