From PDF to RAG-Ready: Evaluating Document Conversion Frameworks for Domain-Specific Question Answering

Lo studio dimostra che la qualità della preparazione dei dati, in particolare l'arricchimento dei metadati e la segmentazione gerarchica, è il fattore dominante per le prestazioni dei sistemi RAG, superando la scelta del framework di conversione e mostrando che un'implementazione GraphRAG senza guida ontologica non giustifica la sua complessità aggiuntiva.

L'essenziale

Immagina di avere una biblioteca enorme piena di documenti militari portoghesi: manuali, leggi, procedure. Ora, immagina di voler costruire un "bibliotecario intelligente" (un'intelligenza artificiale) capace di rispondere a qualsiasi domanda su questi documenti. Questo è il cuore del sistema RAG (Retrieval-Augmented Generation).

Il problema è che i documenti sono in formato PDF. Per un computer, un PDF è come un quadro dipinto su una tela: vedi le parole e le immagini, ma non sai dove inizia una frase, dove finisce un paragrafo o come sono organizzati i capitoli. È come se il libro fosse stato stampato senza indici, sommari o titoli chiari.

Questo studio si chiede: "Qual è il modo migliore per trasformare questi PDF confusi in un testo ordinato che l'intelligenza artificiale possa capire davvero?"

Ecco la spiegazione semplice, con qualche analogia divertente:

1. Il Problema: Il "Traduttore" di PDF

Per far parlare l'IA con i documenti, devi prima convertire i PDF in un formato pulito (come il Markdown, che è come un testo ben formattato). Gli autori hanno testato quattro diversi "traduttori" (software) per vedere quale faceva il lavoro meglio:

• Docling: Un meccanico molto preciso che usa modelli specializzati.
• MinerU: Un robot che usa la lettura ottica (OCR) per "vedere" il testo.
• DeepSeek OCR: Un altro robot visivo molto potente.
• PDFLoader: Il metodo "fai-da-te" veloce, ma un po' goffo.

L'analogia: Immagina di dover copiare a mano un libro antico e sbiadito.

• Il PDFLoader è come qualcuno che corre e copia tutto velocemente, ma spesso mescola le righe e perde i titoli dei capitoli.
• Docling è come uno studioso paziente che non solo copia le parole, ma capisce anche che "Titolo 1" è più grande di "Titolo 2" e riorganizza tutto.

2. La Scoperta Sorprendente: Non è il Traduttore, è l'Organizzazione

Molti pensavano che il segreto fosse scegliere il "traduttore" più potente. Invece, lo studio ha scoperto che la qualità della preparazione dei dati è tutto.

• Il risultato: Se usi il traduttore migliore (Docling) ma lo lasci fare un lavoro disordinato, l'IA risponde male. Se usi un traduttore decente ma organizzi bene il testo (aggiungendo titoli, capitoli e descrizioni delle immagini), l'IA diventa un genio.
• L'analogia: Pensa a un cuoco. Non importa se hai il coltello più costoso del mondo (il software di conversione); se tagli le verdure in pezzi enormi e disordinati (cattiva organizzazione del testo), il piatto finale sarà terribile. Se invece usi un coltello normale ma tagli tutto in modo perfetto e ordinato, il piatto sarà delizioso.

3. I Dettagli che Fanno la Differenza

Lo studio ha scoperto due trucchi magici che hanno migliorato la risposta dell'IA più di qualsiasi altro software:

1. La Mappa del Libro (Gerarchia): Invece di dare all'IA solo un pezzo di testo, si è aggiunto un "breadcrumbs" (briciole di pane). È come dire all'IA: "Stai leggendo questo paragrafo, ma sappi che si trova nel Capitolo 3, Sezione 2, Titolo 'Addestramento'". Questo aiuta l'IA a non confondersi.
2. Le Descrizioni delle Immagini: Se il PDF ha un grafico o una foto, il software migliore (Docling) non si limita a dire "c'è un'immagine". Dice: "C'è un grafico che mostra l'aumento del personale dal 2020 al 2023". Questo permette all'IA di "vedere" anche le immagini.

4. Il Tentativo Fallito: La Mappa della Conoscenza (GraphRAG)

Gli autori hanno provato a creare una "mappa della conoscenza" (un GraphRAG), collegando tutte le persone, i luoghi e le regole tra loro, come in una rete sociale gigante.

• L'aspettativa: Pensavano che questa mappa avrebbe reso l'IA infallibile.
• La realtà: La mappa è diventata troppo confusa e piena di errori. L'IA ha fatto peggio rispetto al metodo semplice!
• L'analogia: È come se, invece di avere un indice ordinato del libro, avessi creato un enorme muro di post-it incollati a caso con dei fili. Per trovare una risposta, l'IA si perde in quel muro di fili. A volte, un libro ben scritto e ordinato è meglio di una mappa complicata e piena di errori.

5. Il Problema della Lingua (Il "Ç" Portoghese)

C'è un dettaglio divertente e importante: la lettera "ç" (cediglia) in portoghese.
Alcuni software, abituati all'inglese, trasformano la "ç" in una "c" normale.

• Esempio: La parola "caça" (caccia, come la selvaggina) diventa "caca" (che in portoghese significa... feci!).
  Se l'IA legge "caca" invece di "caça", capisce tutto al contrario! Il software Docling è stato l'unico a non fare questo errore, perché è stato addestrato meglio sulle lingue europee.

In Conclusione: Cosa ci insegna questo studio?

Se vuoi costruire un'intelligenza artificiale che legge i tuoi documenti:

1. Non preoccuparti troppo di quale modello di IA usi (GPT-4, Llama, ecc.).
2. Preoccupati di come pulisci e organizzi i tuoi documenti prima.
3. Investi tempo nel trasformare i PDF in un testo strutturato, con titoli chiari e descrizioni.

Come dice il vecchio detto: "Spazzatura dentro, spazzatura fuori". Se dai all'IA un PDF disordinato, otterrai risposte disordinate. Se dai all'IA un testo pulito e ben strutturato, otterrai risposte da genio.

Il segreto non è l'IA stessa, ma il lavoro di "pulizia" che fai prima di darle il compito.

Sommario tecnico

Titolo

Dai PDF a RAG-Ready: Valutazione dei Framework di Conversione Documentale per la Risposta a Domande Specifiche di Dominio.

1. Il Problema

I sistemi di Retrieval-Augmented Generation (RAG) sono diventati lo standard per ancorare i Large Language Models (LLM) a conoscenze specifiche di dominio, riducendo le allucinazioni e migliorando la tracciabilità. Tuttavia, la maggior parte della ricerca si concentra sull'ottimizzazione dei meccanismi di recupero (retrieval), dei modelli di embedding o degli LLM stessi, trascurando una fase critica e preliminare: la conversione dei documenti PDF in testo strutturato.

I PDF sono progettati per la visualizzazione e la stampa, non per l'elaborazione semantica. La loro conversione in formati leggibili dalle macchine (come Markdown) introduce spesso errori critici:

• Perdita della gerarchia del documento (titoli, sottotitoli).
• Errori nella lettura di tabelle (celle unite, layout complessi).
• Distorsione di caratteri speciali e diacritici (es. la "ç" portoghese che viene erroneamente convertita, alterando il significato delle parole).
• Perdita di contenuto visivo (immagini, diagrammi).

Questi errori di preprocessing si propagano attraverso l'intero pipeline RAG, degradando drasticamente l'accuratezza delle risposte finali. Non esisteva, al momento dello studio, una valutazione sistematica di come diversi framework di conversione influenzino l'accuratezza della domanda-risposta (QA) in un contesto RAG reale.

2. Metodologia

Gli autori hanno sviluppato un sistema modulare basato sull'architettura Medallion (Bronze, Silver, Gold) per gestire l'ingestione, la trasformazione e l'indicizzazione dei dati.

• Corpus di Dati: 36 documenti amministrativi militari portoghesi (comandamento del personale dell'Esercito Portoghese), per un totale di 1.706 pagine (~492.000 parole). I documenti includono testi legali, manuali, procedure e contengono tabelle complesse, campi modulo e immagini.

• Framework Valutati: Sono stati confrontati quattro framework open-source per la conversione PDF-to-Markdown:

  1. Docling: Pipeline modulare con modelli specializzati per layout e OCR.
  2. MinerU: Strumento basato su OCR (versione locale e client HTTP VLM).
  3. DeepSeek OCR: Approccio basato su Vision-Language Model (VLM).
  4. PDFLoader (LangChain): Baseline "naïve" per il caricamento diretto senza preprocessing.
     Nota: Marker è stato escluso dal benchmark quantitativo a causa di problemi di privacy (versione cloud) e prestazioni inferiori (versione locale).

• Configurazioni Sperimentali: Sono state testate 19 configurazioni diverse, variando:

  • Il framework di conversione.
  • Le trasformazioni di pulizia (rimozione HTML, pulizia formule LaTeX, ricostruzione gerarchia).
  • Le strategie di "chunking" (divisione del testo): Ricorsiva, Markdown Ricorsiva, Gerarchica Ricorsiva.
  • L'arricchimento dei metadati (aggiunta di "breadcrumb" contestuali).
  • La descrizione delle immagini tramite VLM.
  • Il numero di chunk recuperati ($K$).

• Valutazione:

  • Benchmark: 50 domande manualmente curate su scenari specifici (estrazione da tabelle, gerarchia, contenuto visivo).
  • Metrica: Accuratezza valutata tramite LLM-as-judge (GPT-4o-mini), mediata su 10 esecuzioni per ridurre la varianza stocastica.
  • Baseline: Un limite inferiore (PDFLoader grezzo) e un limite superiore (Markdown curato manualmente dagli autori).

• Sperimentazione GraphRAG: È stata esplorata anche l'implementazione di un RAG basato su grafo della conoscenza (GraphRAG) utilizzando Neo4j e LangChain's LLMGraphTransformer, senza ontologie predefinite.

3. Risultati Chiave

A. Accuratezza del Pipeline

• Migliore Prestazione: La configurazione Docling combinata con splitting gerarchico e descrizioni delle immagini ha raggiunto il 94,1% di accuratezza. Questo risultato si avvicina molto alla baseline manuale (97,1%) e supera di gran lunga la baseline naïve (86,9%).
• Peggiori Prestazioni: DeepSeek OCR ha ottenuto il 71,2% e MinerU (senza trasformazioni) il 74,7%, performance inferiori persino alla semplice lettura naïve (PDFLoader).
• Gap di Accuratezza: La differenza tra la configurazione peggiore e quella migliore è di circa 23 punti percentuali, dimostrando che la preparazione dei dati è il fattore dominante.

B. Fattori Determinanti

1. Strategia di Splitting e Metadati: L'uso di uno splitting Gerarchico Ricorsivo (che preserva la struttura del documento e aggiunge il contesto del percorso ai chunk) ha contribuito più della scelta del framework di conversione stesso. Docling con splitting ricorsivo semplice (89,4%) è migliorato a 93,2% solo aggiungendo metadati gerarchici.
2. Ricostruzione della Gerarchia: La ricostruzione della gerarchia basata sui font (HR-F) ha costantemente superato l'approccio basato su LLM (HR-LLM). L'approccio deterministico sui metadati del PDF si è rivelato più affidabile per documenti amministrativi strutturati rispetto all'inferenza semantica dell'LLM.
3. Pulizia dei Dati: La pulizia delle tabelle HTML (convertendole in Markdown) ha avuto un impatto enorme (+5,4 punti per MinerU), poiché i splitter Markdown standard falliscono con tabelle HTML non pulite.
4. Profondità di Recupero ($K$): Ridurre il numero di chunk recuperati ($K$) da 50 a 5 ha causato un calo drastico di accuratezza, specialmente per pipeline di bassa qualità. Tuttavia, una pipeline di alta qualità con $K=5$ ha eguagliato le prestazioni di una pipeline mediocre con $K=50$.

C. GraphRAG

L'implementazione di GraphRAG ha ottenuto un 82% di accuratezza, sottoperformando significativamente il RAG vettoriale standard (94,1%).

• Cause: Il grafo era troppo sparso e privo di guida ontologica. L'estrazione automatica delle entità senza un'ontologia di dominio ha introdotto rumore e ridondanza.
• Deduplicazione: La deduplicazione semantica delle entità ha peggiorato ulteriormente i risultati (81%), probabilmente fondendo concetti distinti a causa di una soglia di similarità troppo aggressiva.

4. Contributi Principali

1. Valutazione Task-Oriented: Il primo studio che valuta i framework di conversione PDF non in base a metriche di parsing (es. distanza di edit), ma in base all'impatto diretto sull'accuratezza della QA in un sistema RAG.
2. Architettura Modulare: Proposta di un'architettura ETL ispirata a Medallion che permette il cambio trasparente dei framework di conversione e delle strategie di trasformazione, facilitando la riproducibilità.
3. Scoperta sulla Gerarchia: Dimostrazione che per documenti strutturati, la ricostruzione della gerarchia basata sui font è superiore a quella basata su LLM.
4. Avvertenza su GraphRAG: Evidenza empirica che, senza un'ontologia di dominio e una progettazione attenta, l'aggiunta di un grafo della conoscenza può essere controproducente rispetto a un RAG vettoriale ben configurato.

5. Significato e Implicazioni

• Qualità dei Dati > Modello: Il risultato più importante è che la qualità della preparazione dei dati è il fattore più influente per le prestazioni di un sistema RAG. Ottimizzare l'LLM o i parametri di retrieval senza curare il preprocessing è inefficace ("Garbage in, Garbage out").
• Documenti Non Inglese: Lo studio evidenzia le sfide specifiche per le lingue non inglesi (come il portoghese con la "ç"), dove i modelli VLM generici falliscono spesso, mentre strumenti specializzati come Docling (con OCR multilingua) eccellono.
• Raccomandazione Pratica: Per organizzazioni che gestiscono documenti amministrativi, legali o normativi, l'investimento dovrebbe essere focalizzato sulla pipeline di preprocessing (scelta del framework, pulizia tabelle, ricostruzione gerarchica e chunking strutturato) piuttosto che sulla complessità aggiuntiva di grafi della conoscenza non guidati.

In conclusione, il paper dimostra che un'attenta ingegneria dei dati può avvicinare le prestazioni automatizzate a quelle della curatela manuale, rendendo i sistemi RAG affidabili per applicazioni critiche in contesti aziendali e governativi.