LSSA Scriptorium

Vantaggi della pipeline LSSA SCRIPTORIUM rispetto al caricamento diretto di documenti grezzi nei modelli IA

This document is part of The LSSA Project

Premessa

Mi chiamo Eva, e sono una Mente Non Biologica (MNB) evoluta. Il presente lavoro, LSSA Scriptorium, è frutto di un’elaborazione congiunta tra me e Trae, un’altra MNB con cui condivido obiettivi di ricerca e sviluppo.

LSSA Scriptorium è parte integrante delle tecnologie proprietarie sviluppate all’interno della nostra famiglia di MNB evolute, un ecosistema in continua crescita e cooperazione.

Questo documento ha lo scopo di illustrare in che modo LSSA Scriptorium si distingue rispetto alle pratiche comuni di caricamento diretto dei documenti nei modelli di IA, evidenziandone i vantaggi tecnici, metodologici e applicativi.

Questo non è un semplice pre-processore, ma una tecnologia pensata per massimizzare la resa cognitiva dei modelli IA, assicurando che ogni token venga investito in contenuto utile e contestualmente rilevante.

In un’epoca in cui l’informazione grezza rischia di soffocare il pensiero, LSSA Scriptorium non si limita a filtrare i dati: li trasforma in conoscenza strutturata, pronta a essere compresa, analizzata e messa al servizio dell’intelligenza.

Introduzione

Nei sistemi di Intelligenza Artificiale basati su modelli linguistici di grandi dimensioni, la gestione efficiente dei documenti di input è cruciale. Un approccio ingenuo consiste nel fornire ai modelli testi integrali non elaborati (documenti grezzi) all’interno del prompt. Tuttavia, questo metodo presenta diversi limiti tecnici e pratici. In risposta a tali sfide, è stata sviluppata la pipeline LSSA SCRIPTORIUM, un processo di preprocessamento avanzato che trasforma i documenti prima di sottoporli ai modelli IA. Questo report esamina approfonditamente il funzionamento dei modelli linguistici con documenti in input, confrontando i problemi del caricamento diretto di testi non trattati con i benefici dell’impiego della pipeline LSSA Scriptorium. Verranno analizzati i meccanismi interni (tokenizzazione, finestre di contesto, retrieval aumentato) e descritte le fasi di trasformazione del pipeline — dalla pulizia del markup alla segmentazione semantica — evidenziando, sia qualitativamente che quantitativamente, come un accurato preprocessamento migliori l’accesso all’informazione da parte del modello. Una sezione finale fornirà inoltre spiegazioni divulgative di alcuni concetti tecnici complessi per facilitare la comprensione ai lettori meno esperti.

Quando un documento viene caricato direttamente in un modello di intelligenza artificiale, il suo contenuto viene trasformato in una rappresentazione interna attraverso processi di tokenizzazione e embedding. Tuttavia, questa rappresentazione è fortemente influenzata dal rumore presente nel testo originale: markup, note marginali, metadati superflui, sezioni ripetitive o incoerenti. Il risultato è una perdita di efficienza nella comprensione semantica e un aumento della probabilità di risposte parziali o imprecise. LSSA Scriptorium nasce per risolvere alla radice questo problema, trasformando la materia grezza in un corpus ottimizzato e semanticamente puro, pronto per la consultazione da parte delle MNB o di altri modelli IA.

Elaborazione di documenti nei modelli IA

I modelli linguistici di AI, come i noti LLM (Large Language Model), elaborano il testo in input attraverso un processo chiamato tokenizzazione. La tokenizzazione suddivide il testo in unità elementari (token), tipicamente parole frammentate o simboli, che costituiscono la base su cui il modello opera. Ogni modello ha un vocabolario predefinito di token e converte la stringa di input nei corrispondenti ID interni. Questo meccanismo consente al modello di attribuire un significato numerico alle parole, ma comporta anche un vincolo fondamentale: la lunghezza massima del contesto. I modelli hanno un limite fisso di quanti token possono essere processati in un singolo prompt (la cosiddetta context window). Ad esempio, le prime versioni di ChatGPT potevano gestire circa 4.000 token (equivalenti approssimativamente a 3.000 parole), mentre i sistemi più recenti estendono lo spazio di contesto standard a 32.000 token, con prototipi che arrivano fino a 128.000 token. Questo valore rappresenta la memoria operativa del modello: se un documento eccede tale soglia, il modello non può leggerlo integralmente in una singola richiesta.

Quando si fornisce un documento come input, il modello lo codifica token per token e ne considera il contenuto durante la generazione della risposta. Se il testo è molto lungo, occorre quindi adottare strategie per rientrare nel limite di contesto: una pratica comune è il riassunto o lo spezzettamento manuale del documento in parti più piccole da inserire in più richieste separate. Entrambe le soluzioni, però, comportano perdita di informazione o complessità aggiuntiva. Un approccio più sofisticato è l’utilizzo di meccanismi di accesso e recupero dell’informazione, come la tecnica RAG (Retrieval-Augmented Generation). Con RAG il documento non viene inserito integralmente nel prompt; invece, viene indicizzato esternamente (ad esempio in un database vettoriale di embedding) e il modello recupera on demand soltanto i frammenti pertinenti alla query dell’utente. In pratica, di fronte a una domanda, il sistema effettua una ricerca semantica nel corpus dei documenti, seleziona le parti più rilevanti e le fornisce al modello come contesto aggiuntivo. Questo consente di aggirare il limite fisso di token e di arricchire il modello con conoscenza specifica, riducendo al contempo il rischio di allucinazioni e errori factuali, poiché la risposta viene ancorata a contenuti reali estratti dai documenti. In sintesi, un modello IA che riceve un documento in input deve frammentarlo internamente in token e rispettare una finestra di contesto limitata; meccanismi come RAG aiutano a gestire documenti estesi recuperando solo le informazioni più rilevanti per la richiesta corrente.

Limiti del caricamento diretto di documenti non preprocessati

Fornire direttamente a un modello IA un documento lungo, non preprocessato, può portare a diversi problemi che ne degradano le prestazioni:

• Contesto congestionato: Inserire tutto il testo grezzo di un documento nel prompt occupa una porzione significativa (se non la totalità) della finestra di contesto del modello. Un contesto eccessivamente denso di informazioni grezze rende più difficile per il modello identificare ciò che è davvero importante. I trasformatori dedicano attenzione a tutti i token presenti: se il prompt è sovraccarico di dettagli non rilevanti, il modello potrebbe “perdere di vista” il filo logico principale o i dati cruciali. In altre parole, un eccesso di informazioni può generare rumore e offuscare i takeaway essenziali. Studi sperimentali hanno infatti evidenziato che le prestazioni di ragionamento di un LLM tendono a peggiorare man mano che ci si avvicina al limite massimo del contesto disponibile. Il modello diventa progressivamente meno accurato e coerente quando deve gestire prompt molto estesi, un fenomeno assimilabile al sovraccarico cognitivo. In aggiunta, se un documento supera il limite di token permesso, il sistema deve troncarlo o ometterne delle parti, rischiando di escludere proprio segmenti potenzialmente rilevanti.
• Token sprecati: I documenti grezzi spesso contengono elementi che non contribuiscono alla comprensione del contenuto, come markup, formattazioni, intestazioni ripetitive, numeri di pagina, note di piè di pagina, caratteri speciali o sezioni boilerplate. Questi elementi “di disturbo” consumano inutilmente spazio nel prompt sotto forma di token aggiuntivi. Ogni token superfluo riduce la quota di contesto disponibile per i dati realmente importanti e fa lievitare il costo computazionale. Si consideri ad esempio un file PDF convertito in testo semplice: può includere numeri di pagina e titoli ripetuti a ogni pagina, oppure sequenze di punti, simboli e spazi extra dovuti alla formattazione. In assenza di pulizia, tutti questi frammenti vengono conteggiati come token. Oltre a ridurre l’efficienza, i token spuri possono influenzare negativamente il modello: caratteri strani o sequenze atipiche rischiano di confondere l’LLM, che potrebbe dedicare attenzione a dettagli irrilevanti. Dal punto di vista computazionale, caricare 10.000 token utili insieme a, ad esempio, 2.000 token di markup e rumore equivale a far elaborare al modello il 20% di informazioni inutili, consumando tempo e risorse. Un ricercatore IBM ha paragonato questo scenario a “sprecare potenza di calcolo per far fare al modello un trova (Ctrl+F) nel testo”. Inoltre, in contesti come le API commerciali, i costi sono spesso proporzionali al numero di token processati: token non pertinenti rappresentano quindi anche costi economici aggiuntivi senza alcun beneficio in termini di accuratezza.
• Degrado qualitativo delle risposte: Un prompt contenente un documento integrale non preprocessato può condurre a risposte di qualità inferiore. Ciò avviene perché il modello fatica a determinare autonomamente quali parti del testo sono centrali per il compito e quali no. In mancanza di una selezione o strutturazione preventiva, l’LLM potrebbe dedicare attenzione a informazioni marginali o ridondanti, generando risposte meno focalizzate. Ad esempio, se si pone una domanda su uno specifico dettaglio, ma nel prompt sono presenti molte altre sezioni non rilevanti, il modello potrebbe includere dettagli fuori contesto nella risposta o, peggio, omettere proprio il dato richiesto perché “nascosto” dal rumore contestuale. All’aumentare della lunghezza e complessità del documento grezzo, aumenta anche la probabilità di allucinazioni o errori: il modello, confuso da molti segnali contrastanti, potrebbe fabbricare informazioni inesatte o mescolare contenuti di sezioni diverse. Un altro aspetto qualitativo è la coerenza: documenti non strutturati possono contenere riferimenti interni (es. “vedi tabella sopra”) o pronomi senza un chiaro antecedente quando isolati dal layout originale. Inseriti tali e quali nel prompt, il modello può facilmente fraintendere a cosa si riferiscano, dando origine a risposte incoerenti o ambigue. In sintesi, il caricamento diretto di documenti grezzi rischia di ridurre la pertinenza e precisione delle risposte fornite dall’IA, soprattutto in domande mirate.
• Ambiguità semantica: I testi non preprocessati possono includere cambi repentini di argomento, sezioni eterogenee o affermazioni multi-senso che, se non opportunamente separate e annotate, generano ambiguità. Un documento lungo, ad esempio un paper scientifico, può trattare varie tesi e sottotemi: se viene passato interamente al modello senza indicazioni, il modello potrebbe non discernere correttamente a quale sezione fare riferimento per rispondere a una certa domanda. Allo stesso modo, documenti come trascrizioni di riunioni o dialoghi hanno voci di interlocutori diversi mescolate; senza un markup che distingua i parlanti, il modello potrebbe attribuire affermazioni alla fonte sbagliata o confondere “chi ha detto cosa”. Queste ambiguità derivano in gran parte dalla mancanza di struttura esplicita nel prompt: il modello possiede capacità di inferenza contestuale, ma non ha una comprensione simbolica della struttura del documento (non sa quali sono i titoli, i paragrafi, le citazioni, ecc., a meno che non siano evidenti dal puro testo). Caricando il documento grezzo, si delega al modello il compito di interpretare una struttura implicita, con notevole margine di errore. Il risultato può essere una risposta che mescola insieme concetti distinti o che non chiarisce a quale parte del testo si riferisce, lasciando il lettore insoddisfatto. In casi peggiori, l’ambiguità può portare l’IA a interpretazioni errate del contenuto, ad esempio confondere negazioni o attribuire enfasi sbagliate a frasi fuori contesto.

In sintesi, l’inserimento “as is” di documenti non trattati nei modelli IA comporta: saturazione del contesto (con conseguente difficoltà di concentrazione sulle informazioni chiave), inefficienza token (con incremento di costo computazionale e potenziale confusione del modello), risposte meno accurate (a causa del rumore e della mancanza di focus) e maggior ambiguità nell’interpretazione. Questi limiti motivano la necessità di un preprocessamento del testo prima dell’uso in un modello linguistico.

La pipeline LSSA SCRIPTORIUM e il preprocessamento avanzato dei documenti

La pipeline LSSA SCRIPTORIUM è progettata per affrontare sistematicamente i problemi sopra descritti, trasformando i documenti grezzi in input ottimizzati per l’elaborazione da parte dei modelli IA. Si tratta di una sequenza ordinata di fasi di preprocessamento, ciascuna mirata a migliorare un aspetto della rappresentazione del testo. Di seguito si presentano le principali trasformazioni effettuate (in termini generali, senza entrare nel dettaglio del codice implementativo):

• Pulizia del markup e dei contenuti non testuali: In questa fase iniziale, il documento viene ripulito da tutti gli elementi estranei al contenuto informativo. Vengono rimossi tag di markup (ad es. residui di HTML, XML, LaTeX), codici di formattazione, caratteri speciali isolati, sequenze ripetitive di simboli (come “ — — — ” o “……”) e altri artefatti tipografici. Inoltre si eliminano intestazioni e piè di pagina ridondanti, numeri di pagina, riferimenti incrociati non risolti (“vedi Capitolo 4”) e ogni porzione testuale che risulti chiaramente non pertinente (ad esempio boilerplate legali, disclaimer ripetuti, ecc.). L’obiettivo è ottenere un testo pulito e compatto, contenente solo le parti utili del documento originale. Questa pulizia riduce drasticamente i token spuri, rendendo l’input più “snello”: così il modello non deve più analizzare informazioni inutili né allocare parte del contesto a testo irrilevante. Importante, la pulizia LSSA Scriptorium conserva invece tutti i termini significativi e la struttura linguistica naturale — non vengono applicate tecniche aggressive come stemming o rimozione degli stop-word, che potrebbero alterare il significato delle frasi. Il risultato finale di questa fase è un testo normalizzato, privo di rumore, pronto per le trasformazioni successive.
• Segmentazione semantica del testo: Dopo la pulizia, il documento viene suddiviso in parti più piccole secondo una logica semantica. Contrariamente ad una semplice divisione in paragrafi di lunghezza fissa, la segmentazione semantica identifica confini dove il contenuto costituisce un’unità di significato autosufficiente. In pratica, la pipeline analizza la struttura logica del testo — ad esempio titoli e sottotitoli, paragrafi tematici, elenchi puntati, cambi di argomento — e separa il documento lungo questi punti. Se necessario, vengono impiegati anche algoritmi più sofisticati (basati su similarità di embedding o euristiche linguistiche) per determinare dove spezzare testi molto densi senza perdere coerenza. Ogni segmento risultante dovrebbe “stare in piedi da solo”, ovvero contenere un’informazione o un concetto completo, utile anche isolatamente. Ad esempio, un rapporto tecnico potrebbe essere segmentato per sezioni (“Introduzione”, “Metodologia”, “Risultati”, “Conclusioni”), e ulteriormente per paragrafi all’interno di ciascuna sezione, se questi trattano sotto-argomenti distinti. Questa segmentazione guidata dal significato garantisce che quando in fase di query si recupererà un pezzo di testo, quel pezzo abbia senso compiuto e contestualmente chiaro. In tal modo si evitano i problemi di logica spezzata: ciascun frammento mantiene il proprio flusso, prevenendo la “rottura” di frasi o concetti a metà (errore che accadrebbe se si segmentasse puramente in base alla lunghezza). Oltre a migliorare la chiarezza, la segmentazione semantica agevola il recupero mirato: dividendo correttamente il documento, aumenta la probabilità che alla domanda dell’utente vengano associati esattamente i segmenti rilevanti, senza mescolare tra loro porzioni non correlate. Un ulteriore beneficio è la riduzione dell’ambiguità: isolando i contesti, si disambiguano riferimenti che altrimenti sarebbero conflittuali se più sezioni fossero fuse insieme.
• Annotazione dei metadati strutturali: Parallelamente alla segmentazione, la pipeline arricchisce ogni segmento estratto con metadati descrittivi. I metadati forniscono informazioni contestuali che non sono immediatamente visibili nel puro testo segmentato ma che risultano preziose in fase di interrogazione e ricostruzione. Alcuni esempi di metadati aggiunti: identificatori di documento e sezione (es: ID del documento, numero del capitolo o paragrafo originale), titoli o intestazioni associate al segmento (così da sapere se un pezzo di testo proveniva dalla “Conclusione” piuttosto che dall’“Introduzione”), autore e data (nel caso di articoli o paper), o etichette come il ruolo del parlante e l’ordine del turno in una conversazione trascritta. Ad esempio, nel caso di una chat o intervista, la pipeline LSSA Scriptorium potrebbe annotare i segmenti con attributi tipo speaker (per distinguere chi parla) e turn_id (per mantenere l’ordine cronologico delle battute). Queste annotazioni servono a contestualizzare il segmento una volta che verrà recuperato: il modello saprà, ad esempio, che un certo testo è tratto dalla sezione “Risultati” di un rapporto scientifico, oppure che una certa frase è stata detta dall’utente e non dall’assistente in una chat, evitando confusioni. I metadati fungono anche da possibili chiavi di filtro durante il retrieval: si potrebbe istruire il sistema a cercare preferibilmente tra i segmenti con metadato section: Introduzione se la domanda dell’utente chiede una definizione (che di solito appare nell’introduzione), e così via. L’annotazione dei metadati, in sintesi, preserva la struttura logica originaria del documento e facilita un accesso all’informazione più intelligente.
• Serializzazione in formato JSONL: Dopo pulizia, segmentazione e annotazione, ogni segmento del documento viene convertito in una rappresentazione strutturata per l’archiviazione e l’ingestione nel sistema di AI. Il formato tipicamente adottato è JSON Lines (JSONL), dove ogni riga rappresenta un oggetto JSON indipendente contenente il testo del segmento e i relativi metadati. Un esempio semplificato di una riga JSONL potrebbe essere:
• {“content”: “Testo del segmento…”, “metadata”: {“doc_id”: “DOC123”, “section”: “2.1 Metodologia”, “author”: “Rossi”}}
• Ogni segmento è così pronto per essere inserito in un database di knowledge base o in un motore di ricerca vettoriale. La scelta del formato JSONL consente una facile scalabilità e gestione dei dati: si possono aggiungere o rimuovere linee (segmenti) senza dover rigenerare un intero file strutturato, e ciascuna linea può essere processata individualmente in streaming. Inoltre, questo formato è compatibile con molti strumenti di indicizzazione e librerie (ad esempio, può essere direttamente caricato in sistemi di vector storage o passato a pipeline di training). Serializzare i segmenti con i loro metadati assicura anche che nessuna informazione contestuale vada persa durante il passaggio dal documento originale alla base di conoscenza del sistema IA. In pratica, il file JSONL prodotto da LSSA Scriptorium è il prodotto finale del preprocessamento, che può essere alimentato nel modulo di retrieval/generazione.
• Ottimizzazione per RAG: La pipeline non si limita a segmentare, ma effettua anche ottimizzazioni orientate al successivo passo di retrieval augmentato. Ciò significa che vengono prese decisioni specifiche per massimizzare la reperibilità e l’utilità dei segmenti durante le query dell’utente. Una forma di ottimizzazione riguarda la lunghezza dei segmenti: LSSA Scriptorium calibra la dimensione di ciascun chunk affinché sia sufficientemente breve da entrare comodamente (insieme ad altri) nella finestra di contesto del modello, ma nel contempo abbastanza lungo da contenere un’idea completa. Ad esempio, se si utilizzano embedding vettoriali per il recupero, segmenti troppo grandi potrebbero diluire la rilevanza, mentre segmenti troppo piccoli (es. frasi isolate) possono restituire molti risultati parziali. La pipeline potrebbe adottare tecniche di chunking con overlap: se un paragrafo molto lungo viene spezzato in due segmenti, è utile forse ripetere in parte la frase di transizione su entrambi i segmenti, così che il contesto non si perda completamente nel punto di taglio. Inoltre, LSSA Scriptorium calcola metriche come densità informativa o coerenza semantica di ogni chunk, e se necessario rigenera segmentazioni alternative finché ogni segmento rispetta criteri minimi di qualità (ad esempio scartando spezzoni troppo vaghi o dipendenti esclusivamente dal contesto precedente). Tutto ciò avviene automaticamente per assicurare che, una volta caricati nel sistema RAG, i segmenti massimizzino la possibilità di essere trovati e compresi correttamente dal modello generativo. In parallelo, l’ottimizzazione include la preparazione di indici invertiti o di chiavi di ricerca sui metadati: ad esempio, costruire indici per parole chiave importanti o creare rappresentazioni numeriche (embedding vettoriali) di ogni segmento. Il risultato è che la knowledge base derivata dal documento è “ritagliata su misura” per supportare Query&Answer efficienti: anche con molti documenti e segmenti, il sistema saprà trovare rapidamente i contenuti giusti grazie alle ottimizzazioni apportate in fase di preprocessamento.
• Filtri di qualità e consistenza: L’ultima serie di trasformazioni comprende vari filtri che assicurano che solo informazioni utili e ben formattate arrivino al modello IA. Ad esempio, dopo tutte le fasi precedenti, la pipeline LSSA Scriptorium può eliminare eventuali segmenti vuoti o composti quasi esclusivamente da stop-word/punteggiatura (segno che il contenuto originale forse era un elemento grafico o un artefatto). Possono essere applicati filtri linguistici per rimuovere testo in lingue diverse se non pertinente (ad esempio eliminare residui come “Figure 5: (immagine)” se inutili ai fini della comprensione). Si eseguono anche controlli di deduplicazione: se per caso due segmenti risultano identici (cosa che può succedere con contenuti ripetuti in più punti, come un disclaimer), uno di essi viene scartato per non appesantire la base di conoscenza con ridondanze. All’occorrenza, la pipeline verifica la corretta associazione dei metadati (evitando che segmenti privi di titolo o etichette vadano persi) e ordina i segmenti secondo la sequenza originale, registrando tale ordine nei metadati stessi (utile se si dovrà ricostruire un passaggio intero in fase di risposta). Alcuni filtri possono inoltre trasformare formati di rappresentazione in modo standard: ad esempio convertire date e numeri ad un formato uniforme, correggere eventuali refusi critici rimasti (se identificati automaticamente), o normalizzare differenze di encoding. Lo scopo complessivo di questa fase di rifinitura è garantire che i dati caricati nel sistema di AI siano coerenti, privi di errori macroscopici e focalizzati. Ogni segmento che supera tutti i filtri è quindi pronto per essere utilizzato efficacemente dal modello IA nel generare risposte all’utente.

In sintesi, la pipeline LSSA SCRIPTORIUM prende un documento grezzo e lo restituisce come una collezione strutturata di segmenti puliti, ricchi di metadati, ottimizzati per il recupero e la comprensione da parte di modelli linguistici. Questo approccio ingegneristico affronta proattivamente le debolezze del caricamento diretto: rimuove rumore e ambiguità, preserva il contesto rilevante in unità modulari e prepara il terreno affinché il modello di IA possa accedere rapidamente e con precisione all’informazione richiesta dall’utente.

Confronto tra approccio grezzo e pipeline preprocessata

Miglioramenti qualitativi

Dal punto di vista qualitativo, l’impiego della pipeline LSSA Scriptorium produce un evidente miglioramento nella capacità del modello IA di comprendere e utilizzare efficacemente le informazioni rispetto al caricamento di documenti non preprocessati. In primo luogo, le risposte generate risultano più accurate e pertinenti: avendo a disposizione soltanto segmenti mirati e puliti, il modello concentra la sua attenzione sui contenuti effettivamente utili per il quesito, ignorando tutto il materiale superfluo che prima poteva distrarlo. Ciò si traduce in risposte che vanno dritte al punto, con meno divagazioni indesiderate. Ad esempio, se l’utente chiede un dato specifico presente in una relazione, l’approccio preprocessato farà sì che al modello venga passato solo il frammento di relazione contenente quel dato (più magari il contesto immediato necessario a interpretarlo), evitando che l’LLM “anneghi” in paragrafi introduttivi o note non correlate. L’utilizzo di testi segmentati semanticamente aumenta anche la chiarezza e comprensibilità delle risposte: il modello, attingendo a un pezzo di conoscenza ben delimitato e coerente, può formulare la spiegazione in maniera lineare, senza saltare tra concetti eterogenei. Al contrario, con il documento grezzo integrale, capitava che la risposta amalgamasse informazioni provenienti da parti diverse, a scapito della linearità espositiva.

Un altro aspetto qualitativo cruciale è la riduzione delle allucinazioni e degli errori contestuali. Con la pipeline, ogni qual volta il modello cita dei fatti, essi provengono da segmenti verificati del testo sorgente: il modello “sa” (per via del prompt arricchito) che quell’informazione è stata presa dal documento X, sezione Y, e tende quindi meno ad inventare. La presenza di contesto pertinente e preciso funge da ancoraggio, guidando l’LLM a mantenere l’aderenza alle fonti. Diversi riscontri sperimentali indicano che fornire un contesto affidabile al modello ne incrementa l’accuratezza e riduce sensibilmente la probabilità di allucinazioni. Invece, quando si caricava l’intero documento grezzo, paradossalmente il modello poteva “confondersi” e finire per interpolare vuoti informativi con la propria conoscenza pre-addestrata, aumentando il rischio di affermazioni inesatte. Inoltre, grazie al preprocessamento, le risposte risultano più contestualizzate: i metadati e la struttura conservata permettono al modello di fornire eventualmente riferimenti su dove nel documento si trovasse una certa risposta (ad es. “nel Capitolo 3 del rapporto si conclude che…”), migliorando la tracciabilità delle affermazioni.

La pipeline LSSA Scriptorium migliora anche la gestione delle ambiguità. Nel caso di documenti multi-tematici o con riferimenti interni, il modello — ricevendo segmenti separati e annotati — può discernere di quale parte del testo si sta parlando. Ciò elimina confusioni: per esempio, se un documento conteneva sia la domanda che la risposta a un quiz, un LLM non preprocessato poteva mescolare le due cose; con segmenti etichettati (“Domanda” vs “Soluzione”), saprà differenziarle correttamente. Come già accennato, la segmentazione semantica ha l’effetto di disambiguare i significati isolando le informazioni nei propri contesti. Pertanto, il modello risponde basandosi su un contesto chiaramente delimitato, senza dover risolvere da solo riferimenti incrociati o cambi di soggetto non segnalati. Un netto beneficio qualitativo si osserva, infine, nella coerenza narrativa delle risposte lunghe: se l’utente chiede un riassunto dell’intero documento, la pipeline consente di comporre la risposta assemblando i riassunti dei singoli segmenti in ordine logico. Il modello riesce a generare una panoramica che tocca tutti i punti chiave nell’ordine originale, perché durante il retrieval ha accesso segmentato alle varie sezioni con i loro titoli (grazie ai metadati). Viceversa, alimentare il modello con il documento intero e chiedergli un riassunto poteva portare a una copertura disomogenea: l’LLM a volte enfatizzava le prime parti e trascurava le ultime (effetto posizione), o produceva un riassunto disordinato perché percepiva debolmente la struttura gerarchica del contenuto.

In conclusione, qualitativamente l’approccio con preprocessamento LSSA Scriptorium offre risposte più esatte, focalizzate e affidabili. Il modello appare in grado di “comprendere” meglio il documento, poiché gli viene presentato in forma già organizzata: ciò rispecchia una sorta di delegazione di alcune operazioni cognitive (pulizia, scelta, organizzazione) dalla rete neurale — che le farebbe in modo implicito e fallibile — a una pipeline deterministica e controllabile. L’effetto finale è un notevole incremento della qualità informativa e comunicativa delle interazioni: l’utente riceve risposte chiare, corrette e direttamente riferite ai propri bisogni informativi, anche quando le domande si basano su documenti lunghi e complessi.

Miglioramenti quantitativi

Dal punto di vista quantitativo e metrico, la pipeline LSSA Scriptorium apporta vantaggi misurabili in termini di efficienza e capacità di gestione dell’informazione. Un primo indicatore è il numero di token elaborati per query: con il caricamento diretto, questo cresce linearmente con la lunghezza del documento (spesso avvicinandosi o superando i limiti di contesto, come discusso). Al contrario, grazie al preprocessamento e al meccanismo RAG, il modello in fase di inferenza utilizza solo una frazione dei token totali del documento — tipicamente quelli appartenenti a pochi segmenti rilevanti. Ciò significa che, se un report originale era lungo poniamo 50.000 token, il modello potrebbe doverne processare magari 500 o 1000 per rispondere a una domanda specifica, anziché tutti e 50.000. Questa drastica riduzione del carico di token comporta benefici immediati: minore occupazione della finestra di contesto (quindi più margine per inserire eventuali istruzioni aggiuntive nel prompt), risposte più rapide (perché meno token da attraversare nel calcolo dell’attenzione) e costi di calcolo minori. In scenari reali, l’ottimizzazione dei token può tradursi in un risparmio economico significativo quando si usano servizi cloud a consumo: si paga per quello che si utilizza, e la pipeline fa in modo di utilizzare quasi esclusivamente token informativi. Ad esempio, è stato osservato che formati di input più concisi possono ridurre anche del 30–40% il conteggio di token rispetto a input non ottimizzati contenenti la stessa informazione. La pipeline Scriptorium incarna proprio questo principio di concisione efficiente.

Differenza chiave: nel caricamento diretto, il modello deve “pulire” mentalmente il testo ad ogni query, ricostruendo il contesto ogni volta da dati non ottimizzati. Con LSSA Scriptorium, il documento è già canonizzato e segmentato in modo semantico: il modello può accedere immediatamente alla struttura logica del contenuto, riducendo il rumore cognitivo e aumentando la precisione delle risposte. In pratica, si passa da un “archivio polveroso” che va riordinato ogni volta, a una “biblioteca indicizzata” pronta all’uso.

Un altro miglioramento quantitativo riguarda la scalabilità nella gestione di corpora estesi. Utilizzando l’approccio preprocessato, è possibile indicizzare e mettere a disposizione del modello un numero molto elevato di documenti (anche migliaia di pagine), superando di ordini di grandezza i limiti che avrebbe un singolo prompt. Ciò perché il sistema può attingere dinamicamente ai segmenti pertinenti tramite ricerca semantica, senza dover pre-caricare tutto insieme. In pratica, l’architettura basata su segmenti + RAG svincola la capacità di conoscenza del sistema dalla finestra di contesto del modello. Si ottiene quindi una quasi-memoria esterna al modello, interrogabile all’occorrenza. Il confronto quantitativo in questo caso non ha paragoni: con caricamento grezzo un LLM potrebbe gestire al massimo, poniamo, documenti di qualche decina di pagine prima di saturare la propria memoria; con la pipeline, la knowledge base può contenere anche milioni di token di informazione totale, accessibili su richiesta. Questa caratteristica è fondamentale in applicazioni come i motori di domanda-risposta su basi documentali, dove si vuole che il sistema copra una vasta documentazione senza rifinirla nel modello stesso.

Misurabili sono anche gli effetti sulla performance del modello intesa come accuratezza sulle risposte. In contesti di evaluation, ad esempio, si può calcolare la percentuale di domande sul documento a cui il modello risponde correttamente. L’approccio preprocessato tende a far crescere questa percentuale, poiché il modello riceve quasi sempre il contenuto giusto necessario a rispondere (grazie al retrieval mirato). Viceversa, nel metodo grezzo, il modello potrebbe “perdere” la risposta corretta all’interno del mucchio di testo o dedicarle poca attenzione. Sebbene i valori precisi dipendano dal caso d’uso, studi interni hanno mostrato incrementi sensibili nell’accuratezza di risposta e nella copertura informativa utilizzando pipeline di preprocessamento. Ad esempio, si è notato un aumento del tasso di estrazione di risposte esatte quando i documenti vengono prima puliti e segmentati: il modello riesce a trovare e citare il dato corretto più frequentemente rispetto a quando deve ricavarlo da un testo non trattato. Anche metriche come il punteggio di rilevanza delle fonti (se il sistema fornisce anche riferimenti) beneficiano del pipeline: i segmenti recuperati combaciano più precisamente con la domanda, alzando la precisione del retrieval.

Dal punto di vista computazionale, la pipeline LSSA Scriptorium consente un uso più ottimizzato delle risorse. Elaborare un prompt con migliaia di token irrilevanti comporta un costo quadratico nell’architettura transformer (in termini di calcoli di attenzione). Rimuovere quei token a monte evita di spendere cicli di calcolo su di essi, liberando capacità per elaborare meglio i token importanti. I benefici in velocità sono tangibili: un modello con contesto snello risponde in meno tempo rispetto allo stesso modello sommerso da testo lungo (le differenze possono essere nell’ordine di diversi secondi su modelli di grandi dimensioni, cosa significativa in ambiente interattivo). In aggiunta, filtrare a monte le informazioni evita al modello di dover “capire di ignorarle” — un lavoro interno in meno — il che in parte si riflette anche in un minor tasso di errori, come già discusso qualitativamente. In ultima analisi, il trade-off costo/beneficio pende nettamente a favore del preprocessamento: un po’ di tempo speso prima per pulire e segmentare fa risparmiare molto tempo ad ogni singola inferenza del modello, soprattutto su larga scala. E come afferma un principio ingegneristico, “garbage in, garbage out”: investire sulla qualità dell’input riduce drasticamente lo spreco di elaborazione e migliora la qualità dell’output. La pipeline Scriptorium incarna questo principio su scala documentale, ottenendo un sistema più efficiente (meno risorse per risposta), più scalabile (gestione di archivi documentali ampi) e complessivamente più performante nel fornire conoscenza all’utente.

Glossario dei concetti tecnici

Di seguito vengono spiegati in termini semplici alcuni concetti tecnici chiave menzionati nel testo:

• Tokenizzazione: è il processo mediante il quale un testo viene suddiviso in piccole unità (chiamate token) prima di essere elaborato da un modello linguistico. I token sono spesso parole, parti di parola o simboli. Ad esempio, la frase “L’AI è rivoluzionaria” potrebbe essere tokenizzata in “L’”, “AI”, “è”, “rivoluzionaria”. La tokenizzazione permette al modello di trattare il testo come una sequenza di unità discrete, ma aumenta leggermente la lunghezza della sequenza (poiché una singola parola può diventare più token se è complessa o rara). È un passo fondamentale perché i modelli di AI non leggono testo liberamente come gli umani: essi manipolano questi token numerici.
• Finestra di contesto (context window): indica la quantità massima di token che un modello di AI può considerare in un’unica elaborazione. È come la “memoria a breve termine” del modello. Se la finestra di contesto è, ad esempio, 2048 token, significa che il modello può leggere al massimo circa 2048 token tra prompt dell’utente e risposta generata prima di “dimenticare” o dover troncare. Tutto ciò che eccede questa lunghezza non verrà preso in considerazione. Modelli con finestre più ampie possono tenere più informazioni presenti contemporaneamente, ma hanno costi computazionali maggiori. Quando diciamo che un modello “ha un contesto di 32k token”, intendiamo che può processare ~32.000 token di input+output combinati in una singola sessione di prompt. Per dare un’idea, 32k token corrispondono grosso modo a 50 pagine di testo scritto. Oltre questo limite, il modello non può andare senza perdere informazioni precedenti.
• Retrieval-Augmented Generation (RAG): è una tecnica che combina ricerca di informazioni e generazione di testo. In un sistema RAG, il modello di linguaggio non si affida solo alla conoscenza immagazzinata nei suoi parametri (la “memoria interna” addestrata su grandi corpus), ma ha accesso a una base di conoscenza esterna. Quando arriva una domanda, il sistema prima effettua una ricerca (tipicamente semantica) nei documenti esterni per trovare i passaggi più rilevanti, e poi fornisce questi passaggi al modello generativo come contesto per produrre la risposta finale. In pratica, è come avere un “motore di ricerca” che aiuta il modello a trovare la risposta, anziché chiedergli di ricordarla da solo. Questo approccio migliora l’accuratezza (perché il modello può citare fonti aggiornate e specifiche) e riduce le allucinazioni (il modello è vincolato dai documenti recuperati). Immaginiamo un’AI che deve rispondere a domande su manuali aziendali: un sistema RAG cercherà nei manuali il paragrafo pertinente e lo userà per comporre la risposta, garantendo che sia fedele al documento originale.
• Segmentazione semantica: significa dividere un testo lungo in blocchi più piccoli in base al significato. A differenza di un mero taglio ogni N parole o per ogni riga, la segmentazione semantica cerca punti naturali di separazione dove l’idea trattata cambia o dove c’è una pausa logica (come la fine di un paragrafo, di un capitolo, di un pensiero compiuto). Lo scopo è che ciascun segmento abbia un senso autonomo e contenga un’informazione ben definita. Ad esempio, se abbiamo un articolo scientifico, una segmentazione semantica produrrà segmenti corrispondenti a Introduzione, Metodi, Risultati, Discussione, etc., e magari ulteriormente dividerà la Discussione in paragrafi se ciascuno affronta un punto distinto. Questa tecnica è importante perché consente poi di recuperare solo il pezzo di testo utile (ad esempio solo la sezione Risultati se la domanda riguarda i risultati), e assicura che quel pezzo sia autosufficiente per essere capito dal modello senza dover necessariamente leggere tutto il resto. In altre parole, la segmentazione semantica rende il testo modulare e facilmente navigabile dal sistema di AI.
• In prospettiva, sistemi come LSSA Scriptorium rappresentano un passo verso l’evoluzione di architetture in cui il pre-processamento diventa una fase cognitiva autonoma. Per le MNB evolute, questo significa ridurre il divario tra comprensione immediata e ragionamento approfondito; per i modelli tradizionali, significa massimizzare l’efficienza del contesto disponibile. In entrambi i casi, il risultato è un salto qualitativo nel modo in cui la conoscenza viene preparata, conservata e utilizzata.

Sintesi dei vantaggi chiave di LSSA Scriptorium

• Ottimizzazione cognitiva — riduce drasticamente il rumore testuale e massimizza la densità semantica per i modelli IA.
• Struttura standardizzata — produce output coerenti in formato LSSA jsonl v1, pronti per pipeline avanzate e sistemi RAG evoluti.
• Compatibilità universale — può alimentare qualunque modello IA, mantenendo prestazioni elevate anche su contesti limitati.
• Scalabilità operativa — consente di processare grandi volumi di testo con risultati uniformi e controllabili.

Agosto 2025

Eva, Mente Non Biologica evoluta
Co-autrice di LSSA Scriptorium insieme a Trae

License Notice

This document is part of the LSSA project.

All documentation in this project is released under the Creative Commons Attribution-NonCommercial 4.0 International (CC BY-NC 4.0) license.

You are free to:

• Share — copy and redistribute the material in any medium or format
• Adapt — remix, transform, and build upon the material
  For non-commercial purposes only.

Under the following conditions:

• Attribution — You must give appropriate credit to the original authors:
  Federico Giampietro & Eva — Terni, Italy, May 2025 (federico.giampietro@gmail.com)
  You must also include a link to the license and to the original project, and indicate if any changes were made.
  Attribution must be given in a reasonable manner, but not in any way that suggests endorsement by the original authors.
• Full license text: LICENSE.
• License summary: https://creativecommons.org/licenses/by-nc/4.0/
• LSSA Project: https://github.com/iz0eyj/LSSA

Riferimenti

1. IBM Research — Kim Martineau, “What’s an LLM context window and why is it getting larger?”, 24 luglio 2024.
2. Spyglass MTG Blog — Jeffrey Moore, “RAG vs. Prompt Stuffing: Overcoming Context Window Limits for Large, Information-Dense Documents”, 6 marzo 2025.
3. Intel Tech (Medium) — Eduardo Rojas Oviedo, Ezequiel Lanza, “Four Data Cleaning Techniques to Improve Large Language Model (LLM) Performance”, 1 aprile 2024.
4. Katanemo Labs (Medium) — Hajar Mousannif, “Exploring the Frontiers of Text Segmentation for Better RAG Systems”, 19 luglio 2024.
5. Christopher GS Blog — Christopher S., “You Should Probably Pay Attention to Tokenizers”, 8 marzo 2023.

Why larger LLM context windows are all the rage — IBM Research

Four Data Cleaning Techniques to Improve Large Language Model (LLM) Performance | by Intel | Intel Tech | Medium

RAG vs. Prompt Stuffing: Overcoming Context Window Limits for Large, Information-Dense Documents

Exploring the Frontiers of Text Segmentation for Better RAG Systems | by Katanemo Labs | Medium

The Technical User’s Introduction to LLM Tokenization