Skip to content
AI360Xpert
Gen AI

Corrective RAG (CRAG)

When the vector database fails to find a good answer, CRAG detects the failure and automatically pivots to a web search to find the missing information.

CRAG acts as a safety net: if the internal database retrieves irrelevant documents, the system triggers a web search to correct the knowledge gap.
CRAG acts as a safety net: if the internal database retrieves irrelevant documents, the system triggers a web search to correct the knowledge gap.

Why Does This Exist?

In traditional RAG pipelines, the system is entirely constrained by the data you put into it. If a user asks a question about a news event that happened yesterday, and your vector database was last updated three days ago, the vector search will fail. It will return the least irrelevant documents it can find. The LLM, trying to be helpful, will stitch those irrelevant documents together into a highly convincing, totally hallucinated answer.

Self-RAG fixes part of this problem by having the LLM look at the retrieved documents and say, "These are irrelevant, I can't answer this." While that prevents hallucination, it results in a terrible user experience: "I'm sorry, I don't know."

Corrective RAG (CRAG) takes this a step further. When the system detects that the retrieved documents are irrelevant, it doesn't just give up. It takes corrective action by pivoting to a fallback mechanism—usually a live web search—to fetch the missing information on the fly.

Think of It Like This

The honest but resourceful librarian

Imagine asking a librarian, "Who won the baseball game last night?"

Standard RAG: The librarian checks their printed encyclopedia (the vector DB). The encyclopedia only goes up to 2023. The librarian reads you the results of the 2023 World Series. (Hallucination / Stale Data).

Self-RAG: The librarian checks the encyclopedia, realizes it's from 2023, and says, "I'm sorry, I don't have that information." (Safe, but unhelpful).

Corrective RAG: The librarian checks the encyclopedia, realizes it's outdated, puts the book away, pulls out their smartphone, Googles the score, and tells you who won last night. (Resourceful and correct).

How It Actually Works

CRAG introduces a "Retrieval Evaluator" module into the pipeline.

1. Initial Retrieval

The user submits a query, and the system searches the internal vector database just like normal.

2. The Retrieval Evaluator

A lightweight LLM (or a fine-tuned classifier) looks at the query and the retrieved documents. It grades the documents into three categories:

  • Correct: The documents clearly contain the answer.
  • Incorrect: The documents are completely irrelevant.
  • Ambiguous: The documents are tangentially related, but might not contain the full answer.

3. The Routing Logic (The Correction)

Based on the evaluator's grade, the pipeline routes the data differently:

  • If Correct: The documents are passed through a "Knowledge Refinement" step. The LLM extracts only the vital sentences and discards the fluff, creating a dense context block.
  • If Incorrect: The internal documents are thrown in the trash. The system takes the user's query, rewrites it for Google/Bing, executes a live web search (via an API like Tavily or Serper), and uses the web results as the context.
  • If Ambiguous: The system combines both approaches. It keeps the internal documents, runs a web search to augment them, and passes the combined knowledge to the final generation step.

4. Final Generation

The final LLM receives the highly refined, corrected context (whether it came from the DB, the web, or both) and generates the answer.

Show Me the Code

This is a conceptual implementation of the CRAG routing logic using LangChain-style conditionals.

import openai
def evaluate_retrieval(query, document):    """    Acts as the Retrieval Evaluator.     Returns 'Correct', 'Incorrect', or 'Ambiguous'.    """    prompt = f"""    Does the following document contain the information needed to answer the query?    Answer ONLY with 'Correct', 'Incorrect', or 'Ambiguous'.    Query: {query}    Document: {document}    """    response = openai.chat.completions.create(        model="gpt-4o-mini",        messages=[{"role": "user", "content": prompt}],        temperature=0.0    )    return response.choices[0].message.content.strip()
def web_search(query):    # Simulates calling the Tavily or Bing API    print(f"  [Action] Executing Web Search for: '{query}'")    return "Web Search Result: The stock price closed at $150 today."
def corrective_rag_pipeline(query, vector_db_result):    print(f"User Query: {query}")        # Step 1 & 2: Evaluate the internal retrieval    evaluation = evaluate_retrieval(query, vector_db_result)    print(f"Evaluator Grade: {evaluation}")        final_context = ""        # Step 3: Route based on evaluation    if "Correct" in evaluation:        print("  [Action] Proceeding with internal data.")        final_context = vector_db_result            elif "Incorrect" in evaluation:        print("  [Action] Internal data irrelevant. Discarding and pivoting to Web Search.")        final_context = web_search(query)            elif "Ambiguous" in evaluation:        print("  [Action] Internal data is ambiguous. Augmenting with Web Search.")        web_data = web_search(query)        final_context = f"{vector_db_result}\n{web_data}"            # Step 4: Final Generation (omitted for brevity)    print(f"\nFinal Context provided to LLM: {final_context}")    return "Generated Answer..."
# --- Execution Scenarios ---
# Scenario 1: Database has the answerquery_1 = "What is our company's PTO policy?"doc_1 = "Employees receive 20 days of Paid Time Off (PTO) per year."corrective_rag_pipeline(query_1, doc_1)# -> Evaluator Grade: Correct# ->   [Action] Proceeding with internal data.
print("\n" + "="*40 + "\n")
# Scenario 2: Database is stale/irrelevantquery_2 = "What is the current stock price of Apple?"doc_2 = "Apple Inc. was founded by Steve Jobs and Steve Wozniak."corrective_rag_pipeline(query_2, doc_2)# -> Evaluator Grade: Incorrect# ->   [Action] Internal data irrelevant. Discarding and pivoting to Web Search.# ->   [Action] Executing Web Search for: 'What is the current stock price of Apple?'

Watch Out For

Security and Data Leakage

Pivoting to a web search requires sending the user's query out to a third-party search engine API (like Google or Bing). If you are building an internal enterprise RAG system that handles sensitive HR data, PII, or trade secrets, sending a failed query to the public internet is a massive data leakage risk. You must implement strict PII scrubbing before the web search fallback is triggered, or disable the fallback entirely for sensitive environments.

The Quick Version

  • Standard RAG fails if the answer simply isn't in the database (e.g., recent news, general knowledge outside the domain).
  • Corrective RAG (CRAG) evaluates the quality of the retrieved documents before generation.
  • If the documents are deemed irrelevant ("Incorrect"), the system discards them and automatically executes a Web Search to find the answer.
  • If the documents are partially helpful ("Ambiguous"), the system combines the internal data with live web data.
  • This creates an incredibly resilient chatbot that rarely says "I don't know."
  • Read Self-RAG to understand how models are trained to evaluate their own retrievals.
  • Read Agentic RAG to see how web search and vector search become just two "tools" in a much larger autonomous system.
  • Read RAG Architecture for the baseline pipeline that CRAG improves upon.

Related concepts