PDF Research Buddy
A demo-ready RAG chatbot for document intelligence
Ariadna Uxue Palomino Ylla • add your email
OCR
Metadata
FAISS
Open-source LLM
Gradio UI
Capstone build
PDF upload → OCR/text extraction → chunking → metadata → vector search → source-grounded answer.
Demo focus
Clean UI, traceable answers, confidence scores, and saved chat history.
Final Pipeline Presentation • 1/9
Problem Statement
Extracting trustworthy answers from messy PDF collections is slow, manual, and error-prone.
Challenge
Documents vary in format and quality. Some are digital, some scanned, and important facts may be buried in long PDFs or repeated across similar pages.
Solution
A RAG pipeline preprocesses PDFs, stores clean chunks with metadata, retrieves the best evidence, and asks an open-source LLM to answer with citations.
Pain point: poor scans
OCR fallback extracts text when normal PDF extraction returns too little content.
Pain point: long PDFs
Overlapping chunks make retrieval precise without sending the whole document to the model.
Pain point: trust
Every answer includes source file, page, score, confidence, and chunk count.
Pain point: mixed files
Document-type metadata lets the UI filter relevant chunks before generation.
Final Pipeline Presentation • 2/9
System Architecture
Data flows through a modular RAG pipeline from upload to final answer.
Input
Text +
OCR
Chunk +
Tags
Embedding
FAISS
Index
Retrieve
Top-K
LLM
Answer
Document processing
PyMuPDF for digital text; Tesseract OCR for scanned or low-text pages.
Indexing
Embeddings: all-MiniLM-L6-v2. Vector search: FAISS normalized inner product.
Answering
Open-source model: FLAN-T5 Base. Prompt: answer only from retrieved context and cite sources.
UI settings
Gradio Blocks; multiple PDF upload; top-k slider; document-type dropdown; save chat history.
Final Pipeline Presentation • 3/9
Pipeline Performance Metrics
Prototype metrics from a demo query and planned evaluation measurements.
Retrieval performance
Query: “Were there any packaging configuration changes?”
Top-K = 4; 3/4 retrieved chunks were directly relevant.
Precision@4 ≈ 0.75; first relevant chunk ranked #1, so MRR = 1.0 for this query.
Answer accuracy
The cleaned answer correctly identified PVC → PETG, +3 mm tray insert update, and drawing R2 → R3. Unsupported wording was removed after source review.
System performance
Retrieval is fast after indexing. OCR depends on scan quality and page count. Generation is usually the slowest stage and varies by CPU/GPU runtime.
Next evaluation step
Add a labelled test set to calculate Recall@K, Precision@K, MRR, answer correctness, citation accuracy, and latency per stage.
Final Pipeline Presentation • 4/9
Pipeline in Action: Query 1
Question: Were there any packaging configuration changes?
Retrieved evidence
Drawing Changes: DWG-29477427-PKG-R3 supersedes R2; updated tray cavity dimensions, sealing parameters, and label placement.
Configuration Change History: Rev B +3 mm tray insert; Rev C PVC → PETG.
Final answer
Yes. Revision B updated tray insert dimensions by +3 mm, and Revision C changed blister tray material from PVC to PETG. Drawing R3 also replaced R2 with updated cavity dimensions, sealing parameters, and label placement.
Final Pipeline Presentation • 5/9
Pipeline in Action: Query 2
Question: What is the document about?
What the user sees
A chat interface with an upload area, document-type filter, top-k slider, answer panel, sources, confidence score, and save history button.
What the system does
The retriever selects chunks with metadata and similarity scores, builds a grounded prompt, then asks the LLM to answer only from those chunks.
Demo value
Stakeholders can inspect both the generated answer and the evidence, which makes the app feel more trustworthy than a normal chatbot.
Final Pipeline Presentation • 6/9
Design Decision Analysis
The system prioritizes simplicity, transparency, and Colab compatibility.
MiniLM embeddings
Chosen for speed and low memory use on limited hardware.
FAISS vector store
Local, fast, and simple; no external database needed for demo.
FLAN-T5 Base
Open-source, no API key, easy Hugging Face integration.
Gradio Blocks
Allows a polished interactive UI quickly in Colab.
Tesseract OCR
Adds scanned-document support without cloud services.
Trade-off
Speed and simplicity came before maximum answer quality. A larger model could improve writing but would be slower and harder to run.
Honest decision
I optimized for a working, demo-worthy pipeline that is easy to understand and extend.
Final Pipeline Presentation • 7/9
Current Limitations & Next Steps
The prototype works, but these are the next improvements.
Low-quality scans
OCR can fail with skewed, blurry, handwritten, or table-heavy pages.
Vague questions
Generic queries can retrieve related but not exact chunks.
Tables
Plain text extraction may lose row/column structure.
Short term
Better document-type metadata, confidence thresholds, and clarification questions.
Medium term
Hybrid keyword + vector search, persistent vector DB, and labelled test queries.
Long term
Table-aware parsing, reranking, citation verification, and monitoring.
Final Pipeline Presentation • 8/9
Project Impact & Learning Outcomes
The project turned a document AI workflow into a demo-ready product.
Technical learning
OCR, chunking, embeddings, vector search, metadata filtering, prompt design, open-source LLMs, and Gradio UI development.
Business impact
The pipeline can reduce manual PDF search time, make evidence easier to audit, and help non-technical users find answers across document collections.
Skills developed
Python, PDF parsing, FAISS, Hugging Face, Gradio, debugging, evaluation thinking, source-grounded reasoning, and technical communication.
Final takeaway
Good RAG is not just about the LLM. Extraction, metadata, chunking, and retrieval quality determine whether the answer is trustworthy.
Final Pipeline Presentation • 9/9