Dopo aver aggiornato ciascun blocco di una pipeline RAG separatamente, la prova del nove è farli girare insieme sullo stesso codice, senza cambiare una riga, su documenti che non si assomigliano affatto. È esattamente ciò che fa questo articolo della serie Enterprise Document Intelligence: punta un’unica pipeline su quattro PDF molto diversi (un paper di ricerca, uno standard NIST, un altro paper e un report con la table of contents rotta) e osserva come regge su ciascuno.
Una sola chiamata, quattro bricks
La parte precedente aveva potenziato ogni brick in isolamento: il parsing ora restituisce un set relazionale con un TOC e un parsing_summary tipizzato; il question parsing trasforma l’input rumoroso dell’utente in un brief strutturato; il retrieval legge il TOC del documento tramite un piccolo LLM e fonde quelle pagine con gli hit da keyword; la generation ritorna una risposta tipizzata con una citazione per elemento più quattro indicatori di qualità del contesto. Questo articolo li collega in un’unica funzione, pdf_qa: una chiamata prende un PDF e una domanda e restituisce la risposta tipizzata più l’intero audit trail, dalla domanda alla citazione. Compaiono due canali laterali che esistono solo quando i bricks girano insieme: il parsing_summary che alimenta entrambi i bricks LLM e un segnale di feedback dalla generation al retrieval.
Contratti tipizzati, bricks indipendenti
I quattro bricks mantengono gli stessi nomi della versione minimale e restano indipendenti: nessuno importa un altro. Ognuno consuma l’oggetto tipizzato emesso dal precedente (line_df dal parsing, ParsedQuestion dal question parsing, anchor e context dal retrieval) e il contratto è lo schema Pydantic, non un dizionario generico. Sono circa venti righe di Python con quattro chiamate LLM (question parsing e generation, più i bricks che l’LLM non lo chiamano), e il dizionario di provenance rende ogni step ripercorribile: un auditor può tracciare dalla domanda alla citazione senza rieseguire la pipeline.
Lo stress test: il TOC rotto
Il caso più istruttivo è un report del World Bank con un TOC integrato ma i cui titoli di sezione risultano tutti Blank Page: i bookmark erano stati generati senza titoli. Il router LLM del TOC riceve voci prive di contenuto semantico, non seleziona nulla e la pipeline ripiega sul solo keyword retrieval. È un buon test di cosa succede quando uno dei quattro bricks (il parsing) restituisce un output degenerato, gestito senza rompere il resto. I tre run funzionano senza una singola riga di codice cambiata proprio perché ogni brick ha un solo compito e un solo output tipizzato: cambiare documento cambia ciò che scorre nei bricks, mai i bricks stessi.
- La stessa pipeline gira invariata su documenti diversissimi perché i contratti tra bricks sono tipizzati (DataFrame e schemi Pydantic).
- I quattro bricks sono context engineering, non retrieval tuning: ciascuno modella ciò che il modello vede alla fine, togliendo spazio alle risposte sbagliate ma sicure.
- La provenance per-brick rende l’intero percorso, dalla domanda alla citazione, ripercorribile senza rieseguire la pipeline.
Fonte: One RAG Pipeline, Four Very Different PDFs: Same Four Bricks, Every Answer Typed and Cited — https://towardsdatascience.com/one-rag-pipeline-four-very-different-pdfs-same-four-bricks-every-answer-typed-and-cited/
Hai qualcosa da aggiungere? Unisciti alla discussione.