LangGraph Agentic RAG: When a Single Search Is No Longer Enough

Basic RAG retrieves and answers, even when questions are vague or results are incomplete. `agentic-rag-for-dummies` uses LangGraph to clarify queries, retry searches, and parallelize complex questions across agents. Supports Ollama locally or Claude, GPT-4, and Gemini in the cloud.

LangGraph Agentic RAG: When a Single Search Is No Longer Enough

Most RAG tutorials follow the same pattern: chunk documents, index them in a vector DB, retrieve similar chunks at query time, and pass them to an LLM. This works — until a question is ambiguous, the first retrieval comes up empty, or a single query needs to cover two different topics at once. agentic-rag-for-dummies addresses these three failure modes with an agent loop.

1. What Is agentic-rag-for-dummies?

agentic-rag-for-dummies is a LangGraph-based reference implementation of Agentic RAG.

"Most RAG tutorials show basic concepts but lack guidance on building modular, agent-driven systems — this project bridges that gap."

In one sentence: basic RAG is a two-step pipeline (retrieve → answer). Agentic RAG is a state machine that loops through understand → rewrite → parallel search → self-correct → compress → answer.

The project offers two learning paths: a notebook-based path for concept exploration and a modular project structure for real deployment. LLM backends are swappable — start with Ollama locally, then move to Anthropic Claude, OpenAI, or Google Gemini. The vector DB is Qdrant.


2. Why Basic RAG Falls Short

It Searches Without Understanding

Ask basic RAG "How do I update it?" and it retrieves chunks similar to "update" — with no awareness that the previous turn was about SQL installation. The result is either off-topic content or asking the user to re-explain context they already provided.

It Answers Even When Results Are Insufficient

If retrieved chunks are irrelevant or incomplete, basic RAG passes them to the LLM anyway. The LLM produces a plausible-sounding response regardless, effectively hallucinating from empty context.

It Cannot Split Complex Queries

"What is JavaScript, and how does it differ from Python?" is two questions. Basic RAG handles them as one query, diluting retrieval quality for both topics simultaneously.


3. How It Works: Internal Architecture

Core Components

Hierarchical Indexing

Documents are split twice. Markdown headers (H1, H2, H3) define large Parent Chunks that preserve context. A fixed-size pass over each parent produces smaller Child Chunks for precision retrieval. Searches run against child chunks; the LLM reads from parent chunks.

Document → H2-level split → Parent Chunk (context)
               └→ fixed-size split → Child Chunk (retrieval precision)

4-Stage Query Workflow

Question → history summary → query rewrite → clarification → parallel agents → aggregation → answer

Stage 1 — Conversation Understanding: Maintains recent turns and a rolling summary to resolve pronouns like "it" or "that" without growing the context window indefinitely.

Stage 2 — Query Clarification: Detects underspecified questions like "Tell me about that thing" and pauses for a Human-in-the-loop confirmation. Clear questions are rewritten into retrieval-optimized form.

Stage 3 — Parallel Agent Search (Multi-Agent Map-Reduce): When multiple sub-queries are generated, LangGraph's Send API spawns independent agent subgraphs in parallel. Each agent independently loops through: Child Chunk search → Parent Chunk lookup → self-correction if results are insufficient → context compression if token budget is exceeded.

Stage 4 — Answer Aggregation: All agent responses are collected and merged into a single reply.

LangGraph Graph Structure

Main graph and agent subgraphs are nested.

# Main graph
START → summarize_history → rewrite_query
  → [ambiguous] request_clarification → rewrite_query (re-entry)
  → [clear]     Send(agent_subgraph × N) → aggregate_answers → END

# Agent subgraph (runs independently per sub-query)
START → orchestrator
  → [tool needed] tools → should_compress_context
      → [above threshold] compress_context → orchestrator
      → [below threshold] orchestrator (loop)
  → [budget exhausted] fallback_response → collect_answer → END
  → [done]            collect_answer → END

4. Context Compression and Self-Correction

As an agent calls tools repeatedly, messages accumulate. When the token count exceeds BASE_TOKEN_THRESHOLD, the compress_context node summarizes the conversation so far and explicitly records which Parent Chunk IDs and queries have already been used — preventing redundant searches.

# Track executed searches to avoid repetition
updated_ids = state.get("retrieval_keys", set()) | new_ids

# Decide whether to compress
max_allowed = BASE_TOKEN_THRESHOLD + int(current_token_summary * TOKEN_GROWTH_FACTOR)
goto = "compress_context" if current_tokens > max_allowed else "orchestrator"

When results are insufficient, the agent automatically rewrites the query and retries. MAX_TOOL_CALLS and MAX_ITERATIONS cap the loop; if the budget runs out, fallback_response returns the best available answer.


5. Try It Yourself

1) Install Ollama

Download the installer for your OS from ollama.com/download.

ollama --version

2) Choose and Pull a Model

Model Size Tool Calling Best For
granite4.1:8b 5.3 GB Excellent (RAG-optimized) Default, English-heavy docs
qwen3:4b 2.3 GB Stable Memory-constrained, multilingual
qwen3:8b 4.9 GB Excellent 16 GB+ RAM, best quality
ollama pull granite4.1:8b
Tool calling is central to this system. Models smaller than 4B are not recommended — they may ignore instructions or run self-correction loops inefficiently.

3) Clone and Install

git clone https://github.com/GiovanniPasq/agentic-rag-for-dummies
cd agentic-rag-for-dummies

python -m venv .venv
source .venv/bin/activate   # macOS/Linux
# .venv\Scripts\activate    # Windows

pip install -r requirements.txt

4) Change the Model (Optional)

Edit two lines in project/config.py:

# Default
LLM_MODEL = "granite4.1:8b"
JUDGE_MODEL = "ministral-3:3b-instruct-2512-q8_0"

# Alternative
LLM_MODEL = "qwen3:4b"
JUDGE_MODEL = "qwen3:1.7b"

JUDGE_MODEL is only used by evaluation.ipynb for RAGAS quality scoring — a separate model avoids self-evaluation bias. It is not used when running python project/app.py.

5) Run

python project/app.py
# → http://127.0.0.1:7860

Upload a PDF in the Gradio UI and ask questions. To explore concepts first, open the Google Colab notebook and run cells in order.

6) Sample Conversation

# Conversation memory in action
User:  How do I install SQL?
Agent: [Installation steps]
User:  How do I update it?       ← "it" correctly resolved to SQL
Agent: [SQL update steps]

# Query clarification in action
User:  Tell me about that thing.
Agent: Could you clarify what topic you mean?
User:  The PostgreSQL installation process.
Agent: [PostgreSQL installation guide]

6. Basic RAG vs. LangGraph Agentic RAG

Basic RAG LangGraph Agentic RAG
Conversation memory None Rolling summary + recent turns
Ambiguous questions Retrieved as-is Human-in-the-loop clarification
Complex queries Single query Parallel agent Map-Reduce
Insufficient results Answers anyway Self-corrects and retries
Context management Hard token limit Compression + deduplication
Precision vs. context Trade-off Hierarchical Indexing handles both
Observability None Langfuse integration
Quality evaluation None RAGAS metrics

One line: Basic RAG retrieves and answers. Agentic RAG understands, clarifies, retries, processes in parallel, compresses, and then answers.


7. Google Is Solving the Same Problem: Gemini Enterprise Agentic RAG

The concepts in agentic-rag-for-dummies are not just an open-source experiment. Google Research and Google Cloud jointly developed and launched Cross-Corpus Retrieval powered by Agentic RAG on the Gemini Enterprise Agent Platform.

Structural Comparison

Both systems share the same core philosophy: if the context is insufficient, loop until it isn't.

Concept agentic-rag-for-dummies Google Agentic RAG
Multi-agent LangGraph Send API → parallel subgraphs Orchestrator → Planner → Search Fanout Agent
Query rewriting Stage 2: rewrite node Query Rewriter Agent
Retry on failure Self-correction loop (MAX_TOOL_CALLS) Phase 4: Iteration
Query decomposition Sub-query → Map-Reduce Planner Agent maps information pathways
Final synthesis aggregate_answers node Synthesis Agent

What Google Added: Sufficient Context Agent

The most distinctive difference is the Sufficient Context Agent — an explicit quality-control layer. Where agentic-rag-for-dummies relies on the LLM to implicitly decide whether to retry, Google separates this into a dedicated agent that produces structured feedback:

Finding: "Medication list and dietary restrictions retrieved."
Gap:     "No allergy or adverse event information found in source documents."
Action:  "Re-search specifically for 'rash' or 'adverse events'."

This makes every retrieval decision auditable and traceable. On the FramesQA benchmark, the system achieved up to 34% accuracy improvement over Vanilla RAG.

What Only dummies Has

Feature Notes
Human-in-the-loop clarification Pauses on ambiguous queries to ask the user
Conversation memory Rolling summary preserves prior context
Context compression Auto-summarizes when token budget is exceeded

Positioning

agentic-rag-for-dummies Google Agentic RAG
Nature Open-source reference implementation Enterprise managed service
Retrieval scope Single Qdrant vector DB Cross-corpus (multi-database routing)
Status Freely modifiable and deployable Google Cloud Public Preview

The three failure modes introduced in Section 2 are not problems that only this project identified. LangGraph, AWS Bedrock Knowledge Bases, Azure AI Foundry, and Google Gemini Enterprise all officially support Agentic RAG workflows, and companies like Morgan Stanley (financial research), PwC (tax and compliance), and ServiceNow (IT workflows) have deployed this pattern in production. According to Google Cloud's 2025 report, 52% of enterprises running GenAI now have agents in production — indicating this is no longer an experimental approach.

That said, the biggest barrier in practice is still response quality. More loops mean more opportunities to iterate in the wrong direction. Basic RAG is perfectly adequate for simple Q&A or single-document retrieval. Agentic RAG makes sense when queries require multi-hop reasoning or span multiple data sources — exactly the situations this repository is designed to handle.


8. Limitations

Heavily dependent on local model quality. The default backend is Ollama, and models of 8B parameters or larger are recommended. Smaller models may ignore tool-calling instructions or run self-correction loops inefficiently.

Many tuning parameters. MAX_TOOL_CALLS, MAX_ITERATIONS, BASE_TOKEN_THRESHOLD, TOKEN_GROWTH_FACTOR, and k are all sensitive knobs. Manual tuning is required depending on document domain and query type.

Vector DB is locked to Qdrant. Switching to a different vector store requires replacing the db/ module directly.

No public benchmark. The repository does not report quantitative gains over basic RAG. Domain-specific evaluation using the RAGAS notebook is necessary.


9. Closing Thoughts

The ways basic RAG fails are predictable: ambiguous questions, insufficient retrieval results, missing conversation context, and complex queries flattened into a single lookup.

LangGraph Agentic RAG closes each of these gaps with an agent loop. It clarifies the question first, retries when results fall short, splits complex queries for parallel processing, and maintains context through rolling summaries.

The implementation is not simple. The stack runs deep — LangGraph state machine, Qdrant, Hierarchical Indexing, Langfuse. But the two-track learning path (notebook → modular project) keeps the entry barrier manageable. Before putting RAG into production, understanding where basic RAG breaks is the essential first step. This repository shows exactly where those breaks happen — and how to fix them in code.


References

Subscribe to PAASUP IDEAS

Don’t miss out on the latest issues. Sign up now to get access to the library of members-only issues.
jamie@example.com
Subscribe