A Retriever is a component in LangChain that fetches relevant documents from a data source in response to a user’s query. Think of it as a specialized search engine that sits between the user and your data
1. How a Retriever Works (Working Diagram) #
The retriever functions as a bridge between a raw query and your stored knowledge
2. Types of Retrievers #
Retrievers are generally categorized in two ways: by the data source they use or by the search strategy they employ.
A. Based on Data Source
These retrievers are defined by where they look for information:
- Wikipedia Retriever: Hits the Wikipedia API to find articles related to your keywords.
- Vector Store Retriever: The most common type; it searches through vector embeddings in a database (like Chroma or FAISS) using semantic similarity.
- Arxiv Retriever: Searches through scientific research papers.
B. Based on Search Strategy
These retrievers use advanced logic to improve the quality of the results:
- MMR (Maximum Marginal Relevance): Balances finding relevant info with avoiding redundant (duplicate) info.
- Multi-Query Retriever: Uses an LLM to generate multiple versions of a user’s query to overcome ambiguity.
- Contextual Compression: Trims documents to remove irrelevant “fluff,” keeping only the exact sentences that answer the query.
1. Wikipedia Retriever (External API Search) #
The WikipediaRetriever queries the Wikipedia API directly without requiring pre-computed embeddings or local indexing.
from langchain_community.retrievers import WikipediaRetriever
# Initialize retriever (fetch top 2 English articles)
wiki_retriever = WikipediaRetriever(top_k_results=2, lang="en")
# Execute query
query = "History of Artificial Intelligence"
docs = wiki_retriever.invoke(query)
# Display results
for i, doc in enumerate(docs):
print(f"\n--- Result {i+1}: {doc.metadata.get('title', 'Wikipedia')} ---")
print(f"Content:\n{doc.page_content[:300]}...\n")
2. Vector Store Retriever (Semantic Vector Search) #
Vector store retrievers index custom documents into vector embeddings (using databases like Chroma or FAISS) and retrieve matches based on cosine or distance similarity.
Why use a Retriever instead of vectorstore.similarity_search? #
- LCEL / Runnable Interface: Retrievers implement the
Runnableprotocol, allowing clean pipeline chaining (retriever | prompt | model). - Strategy Plug-and-Play: You can swap search algorithms (e.g., standard similarity, MMR, similarity with score threshold) without changing application logic.
from langchain_community.vectorstores import Chroma
from langchain_google_genai import GoogleGenerativeAIEmbeddings
from langchain_core.documents import Document
# 1. Prepare sample documents
documents = [
Document(page_content="LangChain helps developers build LLM applications easily."),
Document(page_content="Chroma is a vector database optimized for LLM-based search."),
Document(page_content="Embeddings convert text into high-dimensional numerical vectors."),
Document(page_content="Google Gemini provides fast and powerful multimodal models."),
]
# 2. Initialize embedding model
embeddings = GoogleGenerativeAIEmbeddings(model="models/text-embedding-004")
# 3. Create in-memory Chroma vector store
vectorstore = Chroma.from_documents(
documents=documents,
embedding=embeddings,
collection_name="knowledge_base"
)
# 4. Expose as a retriever
retriever = vectorstore.as_retriever(search_kwargs={"k": 2})
# 5. Query the retriever
query = "What is Chroma used for?"
results = retriever.invoke(query)
for i, doc in enumerate(results):
print(f"Result {i+1}: {doc.page_content}")
Advanced Search Strategies #
Standard similarity search often runs into three common issues:
- Redundancy: Returning 5 chunks that say almost the exact same thing.
- Query Ambiguity: User questions that miss keywords or present incomplete perspective.
- Information Noise: Chunks that contain 90% irrelevant text and only 1 relevant sentence.
LangChain provides advanced retrievers to address each challenge.
1. MMR (Maximum Marginal Relevance) — Eliminating Redundancy #
If your search results are too similar (e.g., two chunks saying the exact same thing), MMR fixes this by picking documents that are both relevant and diverse. It uses a “Lambda” parameter where 0 gives maximum diversity and 1 acts like a normal search.
from langchain_community.vectorstores import FAISS
from langchain_google_genai import GoogleGenerativeAIEmbeddings
from langchain_core.documents import Document
# Sample documents with overlapping information
docs = [
Document(page_content="LangChain makes it easy to work with LLMs."),
Document(page_content="LangChain is used to build LLM based applications."),
Document(page_content="Chroma is used to store and search document embeddings."),
Document(page_content="Embeddings are vector representations of text."),
Document(page_content="MMR helps you get diverse results when doing similarity search."),
Document(page_content="LangChain supports Chroma, FAISS, and other vector stores.")
]
embeddings = GoogleGenerativeAIEmbeddings(model="models/text-embedding-004")
vectorstore = FAISS.from_documents(documents=docs, embedding=embeddings)
# Configure retriever with MMR
mmr_retriever = vectorstore.as_retriever(
search_type="mmr",
search_kwargs={
"k": 3, # Number of documents to return
"fetch_k": 5, # Number of candidate documents to pass to MMR algorithm
"lambda_mult": 0.5 # 0 = Max Diversity, 1 = Max Relevance
}
)
results = mmr_retriever.invoke("What is LangChain?")
for i, doc in enumerate(results):
print(f"MMR Result {i+1}: {doc.page_content}")
2. Multi-Query Retriever — Overcoming Query Ambiguity #
Problem: #
Users rarely formulate optimal search queries. A vague query like “How to stay healthy and balance energy?” might miss documents focused specifically on sleep cycles, nutrition, or cardiovascular workouts.
Solution: #
MultiQueryRetriever uses an LLM to generate multiple alternative perspectives and sub-queries for the user’s prompt, retrieves results for all of them, and takes the union (deduplicated set) of all retrieved documents.
from langchain_community.vectorstores import FAISS
from langchain_google_genai import GoogleGenerativeAIEmbeddings, ChatGoogleGenerativeAI
from langchain_core.documents import Document
from langchain.retrievers.multi_query import MultiQueryRetriever
all_docs = [
Document(page_content="Regular walking boosts heart health and reduces fatigue.", metadata={"source": "H1"}),
Document(page_content="Consuming leafy greens and fruits improves metabolic energy.", metadata={"source": "H2"}),
Document(page_content="Deep sleep is crucial for cellular repair and emotional regulation.", metadata={"source": "H3"}),
Document(page_content="Mindfulness and controlled breathing help stabilize stress hormones.", metadata={"source": "H4"}),
Document(page_content="Financial budgeting ensures long-term wealth growth.", metadata={"source": "F1"}),
]
embeddings = GoogleGenerativeAIEmbeddings(model="models/text-embedding-004")
vectorstore = FAISS.from_documents(documents=all_docs, embedding=embeddings)
llm = ChatGoogleGenerativeAI(model="gemini-1.5-flash", temperature=0)
# Build Multi-Query Retriever
multiquery_retriever = MultiQueryRetriever.from_llm(
retriever=vectorstore.as_retriever(search_kwargs={"k": 2}),
llm=llm
)
query = "How to improve energy levels and maintain balance?"
results = multiquery_retriever.invoke(query)
print(f"Retrieved {len(results)} distinct documents across query variants:\n")
for i, doc in enumerate(results):
print(f"[{doc.metadata.get('source')}] {doc.page_content}")
Contextual Compression Retriever — Cutting Out the Fluff #
Problem: #
Documents retrieved from vector stores are often chunks of 500–1000 tokens. The specific answer may only be a single sentence inside that chunk. Passing entire bloated chunks to the final LLM wastes context window, increases latency, and increases hallucination risk.
Solution: #
ContextualCompressionRetriever passes retrieved candidate documents through a document compressor (such as LLMChainExtractor). The compressor inspects each document against the query and extracts only the relevant sentences, discarding the rest.
from langchain_community.vectorstores import FAISS
from langchain_google_genai import GoogleGenerativeAIEmbeddings, ChatGoogleGenerativeAI
from langchain_core.documents import Document
from langchain.retrievers import ContextualCompressionRetriever
from langchain.retrievers.document_compressors import LLMChainExtractor
docs = [
Document(
page_content="""
The Grand Canyon is one of the most visited natural wonders in the world.
Photosynthesis is the process by which green plants convert sunlight into chemical energy.
Millions of tourists travel to see the canyon every year. The rock strata date back billions of years.
""",
metadata={"source": "General Science & Nature"}
),
Document(
page_content="""
In medieval Europe, castles were built primarily for military defense and royal residence.
Chlorophyll absorbs blue and red light while reflecting green wavelengths during photosynthesis.
Feudal lords maintained armies to defend castle fortifications against sieges.
""",
metadata={"source": "History & Biology"}
)
]
embeddings = GoogleGenerativeAIEmbeddings(model="models/text-embedding-004")
vectorstore = FAISS.from_documents(docs, embeddings)
# Initialize LLM compressor
llm = ChatGoogleGenerativeAI(model="gemini-1.5-flash", temperature=0)
compressor = LLMChainExtractor.from_llm(llm)
# Wrap base retriever with the compression layer
base_retriever = vectorstore.as_retriever(search_kwargs={"k": 2})
compression_retriever = ContextualCompressionRetriever(
base_compressor=compressor,
base_retriever=base_retriever
)
# Run Query
query = "What is photosynthesis and how does chlorophyll work?"
compressed_docs = compression_retriever.invoke(query)
print("--- Compressed Extracted Context ---")
for i, doc in enumerate(compressed_docs):
print(f"\nResult {i+1}:")
print(doc.page_content.strip())
Result 1:
Photosynthesis is the process by which green plants convert sunlight into chemical energy.
Result 2:
Chlorophyll absorbs blue and red light while reflecting green wavelengths during photosynthesis.
Why Use Advanced Retrievers? # #
When you build a basic RAG system, the performance isn’t always perfect. To improve your AI, you “plug in” these advanced retrievers to make the search more intelligent. Mastering these is the key to moving from a simple chatbot to an Advanced RAG system.
Summary & Comparison Matrix #
| Retriever Type | Primary Use Case | Advantage | Trade-off / Cost |
|---|---|---|---|
| Vector Store (Similarity) | Standard semantic search | Fast, low latency, standard $k$-NN lookup | Can return redundant/repetitive chunks |
| MMR Retriever | Broad topical queries | Maximizes information coverage & diversity | Slight embedding computation overhead |
| Multi-Query Retriever | Ambiguous or complex user queries | Bridges keyword mismatch & perspective gaps | Extra LLM call upfront before search |
| Contextual Compression | Long chunks with dense/mixed topics | Extracts precise snippets; saves LLM prompt tokens | Extra LLM extraction latency per candidate doc |
| Wikipedia / API Retriever | Public web/live knowledge retrieval | No local index or embedding storage needed | Dependent on external API latency/rate limits |
Retrievers Quiz #
Q.1 In the context of LangChain, what is the primary function of a Retriever component?
To generate natural language responses using a Large Language Model.
To convert raw text files into vector embeddings for storage.
To fetch relevant documents from a data source in response to a user query.
To split large documents into smaller, manageable chunks.
Explanation
A Retriever searches a data source, such as a vector database or an external API, and returns the most relevant documents for a given user query.
Q.2 What characteristic of LangChain retrievers allows them to be easily integrated into complex chains?
They automatically encrypt data sources.
They are strictly limited to vector database sources.
They do not require an input query to function.
They are categorized as Runnables.
Explanation
LangChain retrievers implement the Runnable interface, allowing them to be seamlessly combined with prompts, LLMs, parsers, and other components using LCEL.
Q.3 How does a Wikipedia Retriever differ from a standard Vector Store Retriever in its search mechanism?
It requires the entire Wikipedia database to be stored locally.
It only retrieves documents in a single, hard-coded language.
It utilizes dense vector embeddings for all searches.
It uses keyword-based matching via an API instead of semantic similarity.
Explanation
A Wikipedia Retriever typically queries the Wikipedia API using keyword-based search, whereas a Vector Store Retriever searches using semantic similarity between embeddings.
Q.4 Which problem is the Maximum Marginal Relevance (MMR) strategy specifically designed to solve?
Low accuracy in keyword matching.
Inability to process multi-lingual queries.
Slow retrieval speeds in large databases.
Redundancy in retrieved results.
Explanation
MMR balances relevance and diversity so that retrieved documents are both highly relevant and different from one another, reducing redundant results.
Q.5 In the MMR algorithm, what does the parameter λ (lambda) represent?
The speed at which the embedding model generates vectors.
The threshold for discarding irrelevant documents.
The balance between query relevance and diversity among results.
The number of documents to be retrieved (K).
Explanation
The lambda (λ) parameter controls the trade-off between selecting documents that are highly relevant to the query and selecting documents that add diversity to the retrieved results.
Q.6 Which retriever would be most effective for a user who asks a broad or ambiguous question like 'How can I stay healthy?
Basic Similarity Search
Wikipedia Retriever
Multi-Query Retriever
Vector Store Retriever
Explanation
A Multi-Query Retriever generates several alternative versions of the user’s question using an LLM, increasing the likelihood of retrieving relevant information for broad or ambiguous queries.
Q.7 What is the primary benefit of using a Contextual Compression Retriever?
It reduces the amount of irrelevant text passed to the LLM by trimming documents.
It allows for searching across multiple vector stores simultaneously.
It automatically translates documents into the user's native language.
It speeds up the initial vector search process.
Explanation
A Contextual Compression Retriever removes irrelevant portions of retrieved documents, ensuring that only the most useful context is sent to the LLM, improving response quality and reducing token usage.
Q.8 The Multi-Query Retriever performs a 'merge and deduplicate' step. Why is this necessary?
To ensure that the total character count stays below the API limit.
Because multiple generated queries might return the same documents.
To convert document objects back into a single string for the prompt.
To verify the factual accuracy of the retrieved information.
Explanation
Different generated queries often retrieve overlapping documents. Merging and deduplicating removes duplicates so the final context contains unique, useful information.
Q.9 Which component is required to build a Contextual Compression Retriever in addition to the 'Base Retriever'?
A Compressor (usually an LLM).
A Text Splitter.
An Embedding Model.
A Vector Database.
Explanation
A Contextual Compression Retriever combines a Base Retriever with a Document Compressor, typically powered by an LLM, which filters or compresses retrieved documents before they reach the final prompt.
Q.10 Why is the use of advanced retrievers considered a key part of 'Advanced RAG'?
They improve the accuracy and relevance of the context provided to the LLM.
They replace the need for Large Language Models entirely.
They allow for the use of cheaper, lower-quality embedding models.
They automatically update the source data in real-time.
Explanation
Advanced retrievers retrieve higher-quality, more relevant, and more diverse context, enabling the LLM to generate more accurate, complete, and reliable responses in RAG applications.
