Il dilemma del parsing dei PDF per un sistema RAG è noto: il parser buono è lento e costoso, quello veloce si perde la tabella dove vive la risposta. Eseguire il parser pesante su ogni pagina di un report da 200 pagine significa pagarne 200 per recuperarne tre; eseguire quello economico ovunque significa affondare la singola tabella importante. Il punto, spiega Angela Shi su Towards Data Science, è che il documento non è uniforme: la maggior parte delle pagine è testo semplice, poche portano le tabelle che servono. È la pagina stessa a dover decidere quanto viene parsata.
Due fasi: baseline e cascata
Il parsing adattivo gira in due fasi. La prima è l’inizializzazione: si sceglie un parser baseline per documento in base a cosa è (PDF nativo, scansione, export da Word). In una piattaforma questo scatta all’ingestion, così ogni documento ha subito un primo layer testuale. La seconda fase è la cascata: si eseguono controlli deterministici ed economici sull’output della baseline e si escalano a un parser più profondo solo le pagine che falliscono un controllo. Il divario di costo giustifica l’approccio: PyMuPDF parsa una pagina in circa 5 millisecondi gratis, mentre un vision LLM sulla stessa pagina può costare ordini di grandezza in più e richiedere una decina di secondi. E in un corpus enterprise tipico (30-100 pagine per documento, 1-3 rilevanti per domanda, meno di 10 domande nel ciclo di vita) circa il 90% delle pagine parsate all’ingestion non viene mai consumato da alcuna risposta.
La cascata di controlli
La valutazione non è un singolo check ma una cascata, con controlli via via più costosi e distribuiti sui quattro “mattoni” della pipeline (parsing, question parsing, retrieval, generation). I metadati pre-parsing instradano gran parte del corpus prima di ogni estrazione: densità di caratteri per pagina, numero di immagini e la producer string del PDF. Sul paper Attention, per esempio, la Figura 1 a pagina 3 si segnala da sola con 1827 caratteri contro una media di 2633 e un’immagine incorporata; la producer string pdfTeX-1.40.25 indica un PDF nativo e da sola instrada l’80% di un corpus enterprise verso il tier giusto.
Al parsing-time entrano i fingerprint sull’output di PyMuPDF: il flat-table fingerprint riconosce le tabelle appiattite (celle corte e strette raggruppate subito dopo la caption “Table N”), mentre il controllo delle figure opache segnala le immagini con zero caratteri estratti nel loro bounding box. Così la Tabella 3 a pagina 9, che il check di densità non cattura, viene comunque flaggata. Più a valle intervengono l’intent routing sulla domanda e lo score gap del retrieval.
Un modello dati che rende tutto auditabile
Il meccanismo poggia su una sola colonna, parsing_method, aggiunta alle tabelle relazionali. L’escalation aggiunge righe, non le sostituisce: la riga PyMuPDF resta accanto a quella di Azure o del vision LLM, con audit trail e caching che escono gratis dallo schema.
- Partire dal parser più economico ed escalare solo le pagine che falliscono un controllo evita di pagare per pagine che nessuno leggerà.
- I check pre-parsing e parsing-time sono deterministici, gratuiti e girano in millisecondi, senza chiamate a un LLM.
- La colonna
parsing_methodmantiene lo schema invariato a valle e rende ogni escalation tracciabile.
Fonte: Loop Engineering with Adaptive PDF Parsing — https://towardsdatascience.com/loop-engineering-with-adaptive-pdf-parsing-start-cheap-pay-for-a-heavier-parser-only-when-the-page-needs-it/
Hai qualcosa da aggiungere? Unisciti alla discussione.