Una pipeline RAG minimale funziona bene in laboratorio: si fa il parsing del PDF, si estraggono le keyword dalla domanda, si recuperano alcune pagine e si interroga un modello. Il problema arriva con l’input reale. Angela Shi, su Towards Data Science, mostra dove si rompe una pipeline baseline e come aggiornarla brick per brick, usando sempre lo stesso paper (Attention Is All You Need, 15 pagine) e la stessa domanda con due typo: “What are the optoins for posiitional encoding?”.
La tesi è che i quattro blocchi della pipeline (document parsing, question parsing, retrieval, generation) vadano trattati come contratti tipizzati, ciascuno con input e output espliciti. È un approccio che interessa chiunque costruisca sistemi di document intelligence su corpus aziendali, dove i documenti sono contratti da 200 pagine senza outline, le domande arrivano con errori di battitura e il codice a valle vuole oggetti tipizzati, non stringhe.
I quattro blocchi, aggiornati
Il document parsing smette di restituire un flat line_df e produce un piccolo insieme relazionale: line_df (una riga per linea visibile, con page_num e line_num come unità di citazione), page_df (una riga per pagina), toc_df (una riga per sezione, con titolo, livello e pagina d’inizio) e un parsing_summary con tipo di documento, lingua e sintesi. Sul paper Attention il TOC nativo ha tre livelli e 22 voci.
Il question parsing trasforma la stringa rumorosa in un brief tipizzato. Una singola chiamata LLM corregge i typo ed estrae le keyword; poi un layer di vocabolario esperto (concept_keywords_df) espande “positional encoding” aggiungendo i due metodi concreti, sinusoidal e learned, così il retrieval li intercetta anche se la domanda non li ha nominati.
Il retrieval viene riformulato come filtro sulle tabelle strutturate, non come ricerca su un indice vettoriale. Il matching per keyword resta, ma il TOC apre un secondo segnale: invece di fare substring matching sui titoli, una piccola chiamata LLM legge l’intero TOC e sceglie la sezione che risponde alla domanda, con una frase di motivazione. L’articolo segnala anche un dettaglio pratico: le keyword multi-parola si perdono se il matching avviene linea per linea, perché una riga del PDF è un artefatto di rendering; la soluzione è cercare su passage di più righe unite.
La generation riempie uno schema tipizzato invece di restituire prosa. Per una domanda di tipo listing torna un ListAnswer con un item per opzione, ciascuno con il suo evidence span e una citazione verbatim, più quattro indicatori di qualità (confidence, complete_answer_found, context_completeness, context_structured) che un router a valle usa per decidere se spedire la risposta o rilanciare il retrieval.
In sintesi
- I quattro upgrade sono indipendenti: un team può adottarli uno alla volta come drop-in, senza riscrivere il codice circostante.
- Il segnale più utile del retrieval non è il punteggio coseno, ma il TOC scritto dall’autore del documento, letto e interpretato da un LLM.
- Uno schema di risposta tipizzato rende visibili i failure mode (contesto non strutturato, risposta incompleta) invece di nasconderli in una stringa.
Fonte: A Production RAG Pipeline for PDFs: Relational Parsing, TOC Retrieval, Typed Answers — https://towardsdatascience.com/a-production-rag-pipeline-for-pdfs-relational-parsing-toc-retrieval-typed-answers/
Hai qualcosa da aggiungere? Unisciti alla discussione.