Document retrieval and question answering

Why I built it

I built this project to understand retrieval-augmented generation beyond connecting an LLM to a vector database. A language model cannot automatically access private documents, and even fluent answers may lack supporting evidence. I wanted to investigate how document representations, chunking, retrieval, and generation interact.

System architecture

The intended modular architecture separates ingestion, indexing, retrieval, and answer synthesis. The repository documents a semantic retrieval pipeline; an operational LLM synthesis stage should not be assumed without verifying the implementation.

1. Parse PDF or text documents into extracted text.
2. Split text into manageable chunks (the documented recursive splitter uses approximately 1,000 characters and 200 characters of overlap).
3. Embed chunks using sentence-transformers/all-MiniLM-L6-v2, producing 384-dimensional vectors.
4. Index vectors in FAISS and embed incoming questions with the same model.
5. Retrieve semantically similar passages for inspection or use as evidence in downstream generation.

The separation of retrieval and generation matters: an answer can fail because the relevant evidence was never retrieved, even if the language model could have answered with the right context.

Evaluation and evidence

I considered retrieval latency, relevance among the top five retrieved chunks (Precision@5), and the faithfulness of any generated answers to retrieved passages. The CV mentions sub-second retrieval, but the benchmark hardware, query count, and latency definition have not been recovered. No numerical Precision@5 or faithfulness score should be published without the original evaluation artifacts.

For each query, Precision@5 is the number of relevant passages among the five highest-ranked results divided by five. Faithfulness requires checking whether factual claims in an answer are supported by retrieved evidence; plausibility alone is not enough.

Challenges and lessons

Chunk boundaries can separate a claim from the context needed to interpret it. Embedding similarity is not the same as factual relevance. Latency includes query encoding and other pipeline stages, not only FAISS search. These distinctions made me think of RAG as a system of independently measurable components.

What I would explore next

I would benchmark fixed-size, recursive, and semantic chunking on the same document-question dataset; compare dense, keyword, and hybrid retrieval; test cross-encoder reranking; preserve page-level source metadata; and evaluate both retrieval quality and answer correctness. These are proposed extensions, not completed benchmark results.

Source code

GitHub — IITB-RAG. The public repository is the primary artifact; claims about a hosted demo or full generation interface require separate verification.

← All projects