All projects

RAG SystemsStatus: Case StudyYear: 2026

Research Saathi

Grounded research answers, with every claim checked against the sources.

A look inside

5 screens from the real build. Select any to see it full size.

The Live Run page after a finished run. The LangGraph workflow ran plan, ingest, index, retrieve, synthesize and verify in order, and the run, its plan and its sources are saved in SQLite so it can be opened again from History.
A run starts from a question, uploaded PDFs, URLs or both, and an output format: summary, literature review, comparison, company brief or interview prep. Here the sources are two Wikipedia articles.
The answer for that run. The synthesis prompt only allows the retrieved chunks as evidence and tells the model to say when evidence is missing, so the limitations it lists (the cost of confidence scoring, users preferring fast answers) come from the source text.
Each retrieved chunk gets a label (S1 to S5) with its source and chunk number, and the verifier cites these labels. In this run Gemini's embeddings endpoint rejected the request, so the app fell back to keyword search over the chunks stored in SQLite; the score is the number of query words matched.
A separate verifier call checks the draft against the same evidence and gives each claim a verdict (supported, weak_support or unsupported), a short reason and the labels it relied on. It flags problems; it does not rewrite the answer.

Overview

A research assistant that turns a question and a set of PDFs or web pages into a grounded answer, then checks every claim in it against the retrieved evidence.

The problem

Research workflows often fragment across PDFs, notes, web searches, and summaries, making citation tracking and factual grounding difficult.

What I built

Designed the workflow, the evidence-only synthesis and verification prompts, the retrieval fallback, and run storage.

What it does

  • PDF and URL ingestion
  • Five output formats, from summary to interview prep
  • Claim-by-claim verification
  • Saved run history

System and architecture

A LangGraph pipeline plans the research, ingests PDFs and URLs, indexes them, retrieves evidence, writes an answer using only that evidence, and runs a separate verifier over each claim.

A fixed LangGraph pipeline runs plan, ingest, index, retrieve, synthesize and verify in order. Sources are chunked and embedded into Chroma; when vector search is unavailable, retrieval falls back to keyword search over the chunks stored in SQLite. Every run, plan, source and verdict is saved, so a run can be reopened from History.

System map3 layers
  1. Interface
  2. Retrieval & data
  3. AI & models
  • Planner, synthesizer and verifier as separate model calls
  • Evidence labels (S1, S2, …) shared by the answer and the verifier
  • Keyword search over SQLite when vector search fails

Technology

  • Python
  • LangGraph
  • Gemini
  • Chroma
  • SQLite
  • Streamlit

Themes

  • Research assistant
  • RAG
  • Verification

Challenges and trade-offs

  • Keeping the model inside the retrieved evidence instead of its own knowledge.
  • Keeping retrieval working when the embeddings service fails.

Outcome

At a glance

LangGraph pipeline · Evidence-only answers · Claim verifier

  • Each claim gets a verdict (supported, weak support or unsupported) with the evidence labels it relied on.
  • Runs are stored, so any answer can be traced back to its sources later.

Learnings

  • A verifier is more useful when it flags problems than when it quietly rewrites the answer.
  • Stored runs are only useful when source provenance is preserved.

Next steps

  • Fix the embeddings call so vector search runs instead of the keyword fallback.
  • Reuse already-ingested URLs instead of returning an empty answer on a repeat run.