Perché i PDF giuridici rompono i sistemi RAG

L’estrazione ingenua dei PDF legali produce dati formalmente corretti ma semanticamente inutilizzabili, e rende necessario un livello di parsing strutturale prima del chunking.

Il problema non nasce dal modello linguistico, né dal database vettoriale. Nasce prima, molto prima, nel punto in cui un testo giuridico viene trasformato in testo “leggibile dalla macchina”.

Nel caso dei manuali e dei codici giuridici in PDF, questa trasformazione è tutt’altro che neutra.

I documenti normativi sono progettati per la lettura umana. Usano colonne multiple, note marginali, rinvii incrociati, intestazioni ripetute, impaginazioni gerarchiche. Un PDF a due colonne, per un lettore umano, è ovvio: prima si legge la colonna sinistra, poi la destra. Per un parser tradizionale, invece, non esiste alcuna “colonna”: esiste solo una sequenza di coordinate e glifi.

Il risultato è un testo linearizzato riga per riga. Non per concetto, ma per posizione.
Articoli diversi finiscono mescolati. Commi lontani diventano adiacenti. Rinvi normativi vengono spezzati e promossi a contenuti autonomi. Dal punto di vista sintattico, il testo esiste. Dal punto di vista semantico, è corrotto.

Questo problema diventa critico nel momento in cui si applica il chunking.
Il chunking, per definizione, assume che il testo in ingresso abbia già una coerenza interna minima. Se il testo è “rotto”, il chunking non fa che cristallizzare l’errore. Un articolo spezzato a metà genera chunk incompleti. Una nota marginale può diventare un chunk autonomo. Un rinvio (“ai sensi dell’art. X”) può essere indicizzato come se fosse l’articolo X stesso.

Nel mio caso, questo si è manifestato in modo evidente: chunk che contenevano una singola riga troncata, riferimenti normativi isolati, frammenti che iniziavano correttamente con “Art. 23” ma non contenevano l’articolo 23. Formalmente validi, operativamente dannosi.

Il problema non era Qdrant. Qdrant indicizzava correttamente ciò che riceveva.
Il problema non era il modello. Il modello rispondeva in modo coerente al contesto fornito.
Il problema era il contesto.

Qui emerge un punto chiave: in un sistema RAG giuridico, la qualità del retrieval è limitata dalla qualità del parsing, non dal modello di generazione. Se il testo è semanticamente instabile a monte, nessuna architettura a valle può correggerlo.

La soluzione non è stata “migliorare il chunking”, ma spostare il punto di intervento prima del chunking.
È qui che entra LlamaIndex, o più precisamente LlamaParse.

Nel mio progetto, LlamaIndex non è usato come framework di orchestrazione del retrieval. Non gestisce query, ranking o prompt. Viene utilizzato in modo molto più mirato: come parser strutturale di PDF complessi nella fase di ingestione.

LlamaParse non legge il PDF come una sequenza di righe. Lo interpreta come un layout visivo. Riconosce colonne, titoli, separazioni logiche, gerarchie testuali. Invece di restituire testo grezzo, restituisce una rappresentazione ordinata (Markdown) che preserva l’ordine concettuale del documento.

Questo passaggio è cruciale: il testo non viene più “letto” riga per riga, ma ricostruito secondo l’intenzione editoriale del documento. Le colonne vengono srotolate correttamente. Gli articoli tornano ad essere unità coerenti. Le intestazioni smettono di interferire con il contenuto normativo.

Solo dopo questo parsing strutturale ha senso applicare il chunking.
A quel punto, dividere per articoli o per sezioni non è più un’operazione fragile, ma una semplice formalizzazione di una struttura già presente.

Inoltre emerge chiaramente un altro aspetto spesso sottovalutato: la fase di debug.
L’introduzione di una modalità “DEBUG” che salva su disco il testo pulito e i chunk generati non è un dettaglio operativo, ma una scelta epistemica. Significa trattare il testo come un dato ispezionabile, non come un flusso opaco. È l’unico modo per verificare che ciò che viene indicizzato corrisponda a ciò che un giurista si aspetterebbe di leggere.

Il risultato finale non è semplicemente “più precisione”. È un cambio di natura del sistema.
Il database smette di essere un deposito di stringhe e diventa una mappa semantica affidabile della norma. Le risposte migliorano non perché il modello è più intelligente, ma perché il contesto smette di mentire.

In questo senso, LlamaParse non è un optional tecnologico. È un livello di traduzione necessario tra due mondi incompatibili: la tipografia giuridica e l’indicizzazione vettoriale. Senza quel livello, il sistema resta formalmente funzionante ma concettualmente instabile.

La lezione è semplice ma non banale: nei sistemi giuridici basati su AI, il problema principale non è “capire la legge”, ma non romperla prima di farla leggere alla macchina.