Agentic RAG: When Retrieval Gets Smart

Naive RAG always retrieves, even when the model already knows the answer — wasting tokens, latency, and money. Agentic RAG turns retrieval into a tool the model decides to call, evaluates, and retries. This is exactly how Claude's tool use, Perplexity's multi-source research, and ChatGPT's web-browse-when-needed work in 2026. Self-RAG, Corrective RAG, query routing, MCP-served retrievers — retrieval becomes a verb, not a pipeline stage.

Learning Objectives

After this lesson, you will be able to:

Understand how query routing looks at a user's question and automatically picks the best way to find the answer — vector search, web search, database query, or no search at all
Describe Self-RAG: the AI first decides whether it even needs to search, and after searching, checks if what it found is actually useful before answering
Compare fallback strategies (Corrective RAG) for what happens when the first search comes up empty or irrelevant
Design a multi-step retrieval pipeline for complex questions that have several parts requiring different sources

Prerequisites

Before You Start

Review

Why

Why This Matters

How Perplexity AI answers complex research questions — Perplexity uses agentic RAG to decompose multi-part questions, search multiple sources in parallel, evaluate the relevance of each result, and synthesize a comprehensive answer with citations from the best sources
How ChatGPT decides when to search the web — the model does not search for every query; it uses an internal routing decision to determine whether the question requires real-time information (web search), can be answered from training data, or needs a specialized tool (code execution, image generation)
How enterprise assistants handle diverse knowledge bases — a company's AI assistant must route "What's the PTO policy?" to the HR knowledge base, "How do I deploy to staging?" to the engineering docs, and "What were Q3 earnings?" to the financial database, each with different retrieval strategies
How AI coding assistants search large codebases — tools like Cursor and GitHub Copilot use agentic retrieval to decide whether to search code, documentation, or issue trackers, then iteratively refine their search until they find the relevant context for the developer's question

This is where RAG starts to feel genuinely intelligent. Instead of a dumb pipe that always does the same thing, you are building a system that thinks about how to search. It is one of the most exciting topics in this track — enjoy it.

#From Static to Agentic Retrieval

Try it: Watch an agent decide when to retrieveInteractive

Loading visualization...

#Query Analysis: Classify Before You Retrieve

Not all queries are created equal. The first step in agentic RAG is analyzing the query to determine the best retrieval strategy:

#Query Types

Query Type	Example	Best Strategy
Factual lookup	"What year was Python created?"	Vector search on knowledge base
Real-time	"What's the weather in Tokyo right now?"	Live API call (weather service)
Analytical	"Compare the GDP growth of India vs China over 10 years"	Multi-step retrieval + data tables
Conversational	"Thanks, that makes sense!"	No retrieval needed — respond directly
Code-related	"How do I use asyncio.gather?"	Code search + documentation
Personal context	"What did I ask you about yesterday?"	Conversation memory / user history

What Do You Think?

User asks: 'What's the weather in Tokyo right now?' Should agentic RAG search a vector database or call a weather API?

The answer is Weather API. A vector database contains static documents indexed at embedding time. "Right now" requires real-time data that changes by the minute. Agentic RAG's query router recognizes the temporal signal ("right now") and routes to the appropriate tool instead of wasting time on irrelevant vector search.

#Router-Based Retrieval

A query router is the decision-making component that directs queries to the right retrieval source. There are several implementation approaches:

#LLM-Based Router

The simplest approach: ask the LLM itself to classify the query.

System: You are a query router. Classify the user's question into one of:
- VECTOR_SEARCH: factual questions answerable from the knowledge base
- WEB_SEARCH: questions requiring recent/real-time information
- SQL_QUERY: questions about structured data (numbers, comparisons, dates)
- CODE_SEARCH: questions about code, APIs, or documentation
- NO_RETRIEVAL: greetings, clarifications, or questions answerable from context
- CALCULATOR: mathematical computations

Respond with only the category name.

Try it! Copy that system prompt into ChatGPT or Claude and send it a few different questions: "What is the refund policy?", "What is the weather in Tokyo right now?", "Thanks, that helps!", "SELECT * FROM users". See how the LLM classifies each one. You just built a query router in 30 seconds.

#Embedding-Based Router

For lower latency, compute the query embedding and use a classifier trained on labeled query-category pairs. This avoids the cost and latency of an LLM call for every routing decision.

#Multi-Source Retrieval

For complex queries, route to multiple sources simultaneously and merge results:

"What's the latest Python 3.13 feature?" -> Web search (recency) + docs search (depth)
"How does our API handle rate limiting?" -> Code search (implementation) + docs search (policy)

#Self-RAG: The Model Decides Everything

Self-RAG (Self-Reflective Retrieval-Augmented Generation) takes agentic RAG further by training the model to make three critical decisions through special tokens:

#Decision 1: Should I Retrieve?

Before retrieval, the model generates a [Retrieve] or [No Retrieve] token. For queries like "What is 2+2?" or "Tell me a joke," retrieval is unnecessary and would only add noise and latency.

#Decision 2: Is the Retrieved Content Relevant?

After retrieval, the model evaluates each retrieved passage and generates [Relevant] or [Irrelevant] tokens. Irrelevant passages are discarded before generation, preventing the model from being misled by off-topic content.

#Decision 3: Is My Response Supported?

After generating a response, the model evaluates whether its output is [Fully Supported], [Partially Supported], or [No Support] by the retrieved evidence. This self-critique catches hallucinations.

#Step 1: Query Arrives

The user asks: "What programming language is TensorFlow written in?" The model receives the query and must decide its first action.

#Step 2: Analyze Intent

The model classifies this as a factual question that requires specific knowledge. It generates a [Retrieve] token, deciding that retrieval is necessary rather than relying on parametric knowledge alone.

#Step 3: Route to Source

The query router sends this to the technical documentation vector database. The retriever returns 3 passages about TensorFlow's architecture, codebase, and history.

#Step 4: Retrieve and Filter

The model evaluates each retrieved passage:

Passage 1 (TensorFlow architecture overview): [Relevant] — mentions core language
Passage 2 (TensorFlow tutorial for beginners): [Irrelevant] — does not mention implementation language
Passage 3 (TensorFlow GitHub README): [Relevant] — states languages used

Passage 2 is discarded.

#Step 5: Generate with Relevant Context

Using only the relevant passages, the model generates: "TensorFlow is primarily written in C++ for its core runtime, with Python as the main user-facing API language."

#Step 6: Verify Support

The model checks its response against the retrieved evidence. Both relevant passages confirm C++ and Python. Verdict: [Fully Supported]. The response is returned to the user.

If the verdict were [No Support], the system would retry with a different retrieval strategy.

Try it: Watch Self-RAG make all three decisions — Retrieve? Relevant? Supported?Interactive

Self-RAG deciding whether to retrieve, and whether to trust what it retrieved.

Loading visualization...

#Corrective RAG (CRAG)

CRAG addresses the question: what do you do when retrieval fails? Instead of generating a potentially hallucinated answer from bad context, CRAG detects failure and takes corrective action.

#The CRAG Pipeline

Retrieve documents as usual
Evaluate retrieval quality with a lightweight classifier:
- Correct: At least one document is highly relevant -> proceed to generation
- Ambiguous: Documents are partially relevant -> refine the query and re-retrieve
- Incorrect: No relevant documents found -> trigger fallback strategies

#Fallback Strategies When Retrieval Fails

Strategy	When to Use	Example
Query rewriting	Original query was too vague or used different terminology	"JS async patterns" -> "JavaScript Promise async/await best practices"
Web search fallback	Knowledge base does not contain the answer	Internal docs search fails -> fall back to web search
Query decomposition	Complex question needs to be broken into parts	"Compare X and Y" -> "What is X?" + "What is Y?" + "Differences?"
Knowledge graph lookup	Question involves relationships or entities	"Who founded the company that made TensorFlow?" -> entity lookup
Honest abstention	No reliable source can answer the question	"I don't have enough information to answer this accurately."

Watch Out

Common Mistake

Always retrieving, even when unnecessary: Basic RAG retrieves for every query, including "hello" and "thanks." This adds latency, wastes compute, and can inject irrelevant context that confuses the model. Agentic RAG's first decision point, whether to retrieve at all, eliminates this waste.

Trusting all retrieved documents equally: Just because a document was returned by vector search does not mean it is relevant. Cosine similarity can be high for topically related but factually irrelevant documents. Self-RAG's relevance evaluation step is critical for filtering noise.

Single-attempt retrieval: If the first retrieval attempt fails, basic RAG generates from bad context. CRAG's retry mechanisms (query rewriting, source switching, decomposition) dramatically improve answer quality for hard queries. Think of it as the model saying "let me search differently" rather than "let me guess."

Ignoring the cost of agentic decisions: Each decision point (route, evaluate, verify) adds latency and token cost. For high-throughput, low-latency applications, a simpler RAG pipeline with good retrieval quality may outperform a complex agentic pipeline that spends more time deciding than answering.

Watch Out

Building keyword-based routers instead of embedding-based classifiers

Fix: The simplest agentic routers check for signal words: if the query contains 'latest' or 'today' route to web search, if it contains 'hello' skip retrieval, etc. This breaks immediately in production. Users type 'What is the current policy?' (no time signal) for real-time data, or 'What is the time complexity of quicksort?' (contains 'current' in a different sense). Rule-based routers have both false positives and false negatives that grow as query diversity grows. Instead, train a lightweight text classifier on labeled query examples, or use a small embedding model to compare the query against prototypical queries for each route. An embedding-based router with 50 labeled examples per category dramatically outperforms even 200 keyword rules.

#Multi-Step Retrieval: Decomposing Complex Questions

Some questions cannot be answered with a single retrieval step. Multi-step retrieval decomposes complex queries into a chain of simpler retrievals:

#Example: "How did the company that created React change its name, and when?"

Step 1: Retrieve "Who created React?" -> "React was created by Facebook"
Step 2: Retrieve "When did Facebook change its name?" -> "Facebook rebranded to Meta in October 2021"
Step 3: Synthesize: "Facebook, the company that created React, rebranded to Meta in October 2021."

Each step builds on the previous answer, and each retrieval is targeted and specific. The agent decides when it has enough information to synthesize a final answer.

#Adaptive Retrieval Depth

Not every query needs the same number of retrieval steps:

Simple factual: 1 step ("What is the capital of France?")
Multi-hop reasoning: 2-3 steps ("Who is the CEO of the company that acquired Instagram?")
Research synthesis: 5+ steps ("Summarize the key arguments for and against remote work, citing recent studies")

The agent monitors its confidence at each step and stops retrieving when it has sufficient evidence.

#Try It Yourself

pythonplayground.py · Pyodide

# Build a simple query router for an agentic RAG system

def route_query(query):
  q = query.lower()

# Define routing rules based on query analysis
  routes = {
      "VECTOR_SEARCH": {
          "signals": ["what is", "explain", "how does", "define", "describe"],
          "description": "Factual question -> search knowledge base",
      },
      "WEB_SEARCH": {
          "signals": ["latest", "today", "right now", "current", "2025", "2026", "news"],
          "description": "Real-time question -> search the web",
      },
      "SQL_QUERY": {
          "signals": ["how many", "total", "average", "count", "revenue", "sales"],
          "description": "Structured data question -> query database",
      },
      "CODE_SEARCH": {
          "signals": ["function", "import", "error", "bug", "code", "api", "syntax"],
          "description": "Code question -> search codebase",
      },
      "NO_RETRIEVAL": {
          "signals": ["hello", "thanks", "hi", "bye", "ok", "sure", "got it"],
          "description": "Conversational -> respond directly",
      },
      "CALCULATOR": {
          "signals": ["calculate", "compute", "what is 2", "multiply", "divide", "sum of"],
          "description": "Math question -> use calculator tool",
      },
  }

# Check each route's signals
  matches = []
  for route, config in routes.items():
      for signal in config["signals"]:
          if signal in q:
              matches.append({"route": route, "signal": signal, "description": config["description"]})
              break  # one match per route is enough

if not matches:
      return {"route": "VECTOR_SEARCH", "confidence": "low", "reason": "Default fallback"}

if len(matches) == 1:
      return {
          "route": matches[0]["route"],
          "confidence": "high",
          "reason": f"Matched signal: '{matches[0]['signal']}'",
      }

# Multiple matches: prefer more specific routes
  priority = ["CALCULATOR", "SQL_QUERY", "WEB_SEARCH", "CODE_SEARCH", "VECTOR_SEARCH", "NO_RETRIEVAL"]
  matches.sort(key=lambda m: priority.index(m["route"]) if m["route"] in priority else 99)
  best = matches[0]

return {
      "route": best["route"],
      "confidence": "medium",
      "reason": "Multiple matches, prioritized: " + ", ".join(m["route"] for m in matches),
  }

# Test the router
queries = [
  "What is the capital of France?",
  "What's the latest news about SpaceX?",
  "How many users signed up last month?",
  "How do I fix this Python import error?",
  "Hello, how are you?",
  "Calculate the sum of 15 and 27",
  "What is the current stock price of Apple?",
]

for query in queries:
  result = route_query(query)
  print(f"Q: {query}")
  print(f"   Route: {result['route']} ({result['confidence']})")
  print(f"   Reason: {result['reason']}")
  print()

# CHALLENGE: Add a MEMORY route for questions like
# "What did I ask you earlier?" or "Remember when I mentioned..."
# Hint: add signals like "earlier", "remember", "last time", "previously"

Tests · Verify 'What is the capital of France?' routes to VECTOR_SEARCH. Verify 'latest news' routes to WEB_SEARCH. Verify 'Hello' routes to NO_RETRIEVAL.

#Key Takeaways

Agentic RAG adds decision points to the retrieval pipeline — instead of always retrieving from the same source, the system classifies queries, routes to appropriate sources, evaluates results, and retries when retrieval fails
Self-RAG lets the model decide whether to retrieve, evaluate relevance, and verify support — three critical decision points that reduce unnecessary retrieval, filter noise, and catch hallucinations
Corrective RAG provides fallback strategies for failed retrieval — query rewriting, source switching, and decomposition ensure the system can recover rather than generating from bad context
Multi-step retrieval handles complex questions by decomposing them — each step builds on previous results, with the agent adaptively deciding when it has gathered enough evidence to synthesize a final answer

#Quick Check

Quick Check1 / 4

What is the primary advantage of query routing in agentic RAG?

Agentic RAG transforms retrieval from a fixed pipeline into an intelligent decision process. Next: Knowledge Graphs & Graph RAG — adding structured relationships to your retrieval toolkit for multi-hop reasoning that vector search alone cannot solve.

Agentic RAG: When Retrieval Gets Smart

Learning Objectives

After this lesson, you will be able to:

Understand how query routing looks at a user's question and automatically picks the best way to find the answer — vector search, web search, database query, or no search at all
Describe Self-RAG: the AI first decides whether it even needs to search, and after searching, checks if what it found is actually useful before answering
Compare fallback strategies (Corrective RAG) for what happens when the first search comes up empty or irrelevant
Design a multi-step retrieval pipeline for complex questions that have several parts requiring different sources

Prerequisites

Before You Start

Review

Why

Why This Matters

How Perplexity AI answers complex research questions — Perplexity uses agentic RAG to decompose multi-part questions, search multiple sources in parallel, evaluate the relevance of each result, and synthesize a comprehensive answer with citations from the best sources
How ChatGPT decides when to search the web — the model does not search for every query; it uses an internal routing decision to determine whether the question requires real-time information (web search), can be answered from training data, or needs a specialized tool (code execution, image generation)
How enterprise assistants handle diverse knowledge bases — a company's AI assistant must route "What's the PTO policy?" to the HR knowledge base, "How do I deploy to staging?" to the engineering docs, and "What were Q3 earnings?" to the financial database, each with different retrieval strategies
How AI coding assistants search large codebases — tools like Cursor and GitHub Copilot use agentic retrieval to decide whether to search code, documentation, or issue trackers, then iteratively refine their search until they find the relevant context for the developer's question

#From Static to Agentic Retrieval

Try it: Watch an agent decide when to retrieveInteractive

Loading visualization...

#Query Analysis: Classify Before You Retrieve

Not all queries are created equal. The first step in agentic RAG is analyzing the query to determine the best retrieval strategy:

#Query Types

Query Type	Example	Best Strategy
Factual lookup	"What year was Python created?"	Vector search on knowledge base
Real-time	"What's the weather in Tokyo right now?"	Live API call (weather service)
Analytical	"Compare the GDP growth of India vs China over 10 years"	Multi-step retrieval + data tables
Conversational	"Thanks, that makes sense!"	No retrieval needed — respond directly
Code-related	"How do I use asyncio.gather?"	Code search + documentation
Personal context	"What did I ask you about yesterday?"	Conversation memory / user history

What Do You Think?

User asks: 'What's the weather in Tokyo right now?' Should agentic RAG search a vector database or call a weather API?

#Router-Based Retrieval

A query router is the decision-making component that directs queries to the right retrieval source. There are several implementation approaches:

#LLM-Based Router

The simplest approach: ask the LLM itself to classify the query.

System: You are a query router. Classify the user's question into one of:
- VECTOR_SEARCH: factual questions answerable from the knowledge base
- WEB_SEARCH: questions requiring recent/real-time information
- SQL_QUERY: questions about structured data (numbers, comparisons, dates)
- CODE_SEARCH: questions about code, APIs, or documentation
- NO_RETRIEVAL: greetings, clarifications, or questions answerable from context
- CALCULATOR: mathematical computations

Respond with only the category name.

Try it! Copy that system prompt into ChatGPT or Claude and send it a few different questions: "What is the refund policy?", "What is the weather in Tokyo right now?", "Thanks, that helps!", "SELECT * FROM users". See how the LLM classifies each one. You just built a query router in 30 seconds.

#Embedding-Based Router

For lower latency, compute the query embedding and use a classifier trained on labeled query-category pairs. This avoids the cost and latency of an LLM call for every routing decision.

#Multi-Source Retrieval

For complex queries, route to multiple sources simultaneously and merge results:

"What's the latest Python 3.13 feature?" -> Web search (recency) + docs search (depth)
"How does our API handle rate limiting?" -> Code search (implementation) + docs search (policy)

#Self-RAG: The Model Decides Everything

Self-RAG (Self-Reflective Retrieval-Augmented Generation) takes agentic RAG further by training the model to make three critical decisions through special tokens:

#Decision 1: Should I Retrieve?

Before retrieval, the model generates a [Retrieve] or [No Retrieve] token. For queries like "What is 2+2?" or "Tell me a joke," retrieval is unnecessary and would only add noise and latency.

#Decision 2: Is the Retrieved Content Relevant?

#Decision 3: Is My Response Supported?

#Step 1: Query Arrives

The user asks: "What programming language is TensorFlow written in?" The model receives the query and must decide its first action.

#Step 2: Analyze Intent

#Step 3: Route to Source

The query router sends this to the technical documentation vector database. The retriever returns 3 passages about TensorFlow's architecture, codebase, and history.

#Step 4: Retrieve and Filter

The model evaluates each retrieved passage:

Passage 1 (TensorFlow architecture overview): [Relevant] — mentions core language
Passage 2 (TensorFlow tutorial for beginners): [Irrelevant] — does not mention implementation language
Passage 3 (TensorFlow GitHub README): [Relevant] — states languages used

Passage 2 is discarded.

#Step 5: Generate with Relevant Context

Using only the relevant passages, the model generates: "TensorFlow is primarily written in C++ for its core runtime, with Python as the main user-facing API language."

#Step 6: Verify Support

The model checks its response against the retrieved evidence. Both relevant passages confirm C++ and Python. Verdict: [Fully Supported]. The response is returned to the user.

If the verdict were [No Support], the system would retry with a different retrieval strategy.

Try it: Watch Self-RAG make all three decisions — Retrieve? Relevant? Supported?Interactive

Self-RAG deciding whether to retrieve, and whether to trust what it retrieved.

Loading visualization...

#Corrective RAG (CRAG)

CRAG addresses the question: what do you do when retrieval fails? Instead of generating a potentially hallucinated answer from bad context, CRAG detects failure and takes corrective action.

#The CRAG Pipeline

Retrieve documents as usual
Evaluate retrieval quality with a lightweight classifier:
- Correct: At least one document is highly relevant -> proceed to generation
- Ambiguous: Documents are partially relevant -> refine the query and re-retrieve
- Incorrect: No relevant documents found -> trigger fallback strategies

#Fallback Strategies When Retrieval Fails

Strategy	When to Use	Example
Query rewriting	Original query was too vague or used different terminology	"JS async patterns" -> "JavaScript Promise async/await best practices"
Web search fallback	Knowledge base does not contain the answer	Internal docs search fails -> fall back to web search
Query decomposition	Complex question needs to be broken into parts	"Compare X and Y" -> "What is X?" + "What is Y?" + "Differences?"
Knowledge graph lookup	Question involves relationships or entities	"Who founded the company that made TensorFlow?" -> entity lookup
Honest abstention	No reliable source can answer the question	"I don't have enough information to answer this accurately."

Watch Out

Common Mistake

Watch Out

Building keyword-based routers instead of embedding-based classifiers

#Multi-Step Retrieval: Decomposing Complex Questions

Some questions cannot be answered with a single retrieval step. Multi-step retrieval decomposes complex queries into a chain of simpler retrievals:

#Example: "How did the company that created React change its name, and when?"

Step 1: Retrieve "Who created React?" -> "React was created by Facebook"
Step 2: Retrieve "When did Facebook change its name?" -> "Facebook rebranded to Meta in October 2021"
Step 3: Synthesize: "Facebook, the company that created React, rebranded to Meta in October 2021."

Each step builds on the previous answer, and each retrieval is targeted and specific. The agent decides when it has enough information to synthesize a final answer.

#Adaptive Retrieval Depth

Not every query needs the same number of retrieval steps:

Simple factual: 1 step ("What is the capital of France?")
Multi-hop reasoning: 2-3 steps ("Who is the CEO of the company that acquired Instagram?")
Research synthesis: 5+ steps ("Summarize the key arguments for and against remote work, citing recent studies")

The agent monitors its confidence at each step and stops retrieving when it has sufficient evidence.

#Try It Yourself

pythonplayground.py · Pyodide

# Build a simple query router for an agentic RAG system

def route_query(query):
  q = query.lower()

if not matches:
      return {"route": "VECTOR_SEARCH", "confidence": "low", "reason": "Default fallback"}

if len(matches) == 1:
      return {
          "route": matches[0]["route"],
          "confidence": "high",
          "reason": f"Matched signal: '{matches[0]['signal']}'",
      }

return {
      "route": best["route"],
      "confidence": "medium",
      "reason": "Multiple matches, prioritized: " + ", ".join(m["route"] for m in matches),
  }

for query in queries:
  result = route_query(query)
  print(f"Q: {query}")
  print(f"   Route: {result['route']} ({result['confidence']})")
  print(f"   Reason: {result['reason']}")
  print()

# CHALLENGE: Add a MEMORY route for questions like
# "What did I ask you earlier?" or "Remember when I mentioned..."
# Hint: add signals like "earlier", "remember", "last time", "previously"

Tests · Verify 'What is the capital of France?' routes to VECTOR_SEARCH. Verify 'latest news' routes to WEB_SEARCH. Verify 'Hello' routes to NO_RETRIEVAL.

#Key Takeaways

Agentic RAG adds decision points to the retrieval pipeline — instead of always retrieving from the same source, the system classifies queries, routes to appropriate sources, evaluates results, and retries when retrieval fails
Self-RAG lets the model decide whether to retrieve, evaluate relevance, and verify support — three critical decision points that reduce unnecessary retrieval, filter noise, and catch hallucinations
Corrective RAG provides fallback strategies for failed retrieval — query rewriting, source switching, and decomposition ensure the system can recover rather than generating from bad context
Multi-step retrieval handles complex questions by decomposing them — each step builds on previous results, with the agent adaptively deciding when it has gathered enough evidence to synthesize a final answer

#Quick Check

Quick Check1 / 4

What is the primary advantage of query routing in agentic RAG?

Agentic RAG: When Retrieval Gets Smart

#From Static to Agentic Retrieval

#Query Analysis: Classify Before You Retrieve

#Query Types

#Router-Based Retrieval

#LLM-Based Router

#Embedding-Based Router

#Multi-Source Retrieval

#Self-RAG: The Model Decides Everything

#Decision 1: Should I Retrieve?

#Decision 2: Is the Retrieved Content Relevant?

#Decision 3: Is My Response Supported?

#Step 1: Query Arrives

#Step 2: Analyze Intent

#Step 3: Route to Source

#Step 4: Retrieve and Filter

#Step 5: Generate with Relevant Context

#Step 6: Verify Support

#Corrective RAG (CRAG)

#The CRAG Pipeline

#Fallback Strategies When Retrieval Fails

#Multi-Step Retrieval: Decomposing Complex Questions

#Example: "How did the company that created React change its name, and when?"

#Adaptive Retrieval Depth

#Try It Yourself

Deep Dive

#Key Takeaways

#Quick Check

Related Lessons

Your Reflection

Continue Learning

Discussion

Agentic RAG: When Retrieval Gets Smart

#From Static to Agentic Retrieval

#Query Analysis: Classify Before You Retrieve

#Query Types

#Router-Based Retrieval

#LLM-Based Router

#Embedding-Based Router

#Multi-Source Retrieval

#Self-RAG: The Model Decides Everything

#Decision 1: Should I Retrieve?

#Decision 2: Is the Retrieved Content Relevant?

#Decision 3: Is My Response Supported?

#Step 1: Query Arrives

#Step 2: Analyze Intent

#Step 3: Route to Source

#Step 4: Retrieve and Filter

#Step 5: Generate with Relevant Context

#Step 6: Verify Support

#Corrective RAG (CRAG)

#The CRAG Pipeline

#Fallback Strategies When Retrieval Fails

#Multi-Step Retrieval: Decomposing Complex Questions

#Example: "How did the company that created React change its name, and when?"

#Adaptive Retrieval Depth

#Try It Yourself

Deep Dive

#Key Takeaways

#Quick Check

Related Lessons

Your Reflection

Continue Learning

Discussion