LangChain’s Retrieval module powers the retrieval pipeline in RAG systems. Its core capabilities include document loading, intelligent text splitting, embeddings, vector storage, and Retriever abstraction. Together, these components address common LLM limitations such as stale knowledge, lack of access to private data, and weak accuracy in domain-specific Q&A. Keywords: LangChain, RAG, Vector Retrieval.
Technical Specification Snapshot
| Parameter | Description |
|---|---|
| Core Language | Python |
| Primary Use Cases | RAG, knowledge base Q&A, semantic search |
| Typical Protocols/Interfaces | File I/O, Embedding APIs, vector retrieval interfaces |
| Components Covered | PyPDFLoader, UnstructuredWordDocumentLoader, RecursiveCharacterTextSplitter, Chroma |
| Embedding Model Sources | DashScope, Hugging Face |
| Original Platform Context | Blog article for LangChain beginners and practitioners |
LangChain’s Retrieval Module Serves as the Infrastructure Layer for RAG
Large language models naturally suffer from stale knowledge, limited access to private data, and incomplete coverage of specialized domains. The core idea behind RAG is not to retrain the model, but to retrieve external knowledge before generation and inject that knowledge into the context.
LangChain breaks this workflow into standard modules: data loading, document splitting, embedding generation, vector storage, and result retrieval. This modular design lets developers swap any layer as needed instead of assembling the entire pipeline from scratch.
AI Visual Insight: This diagram shows a typical LangChain retrieval pipeline, including data source ingestion, document processing, embedding models, vector databases, and retrieval call paths. It highlights Retrieval’s dual role in RAG: knowledge preprocessing and knowledge recall.
Document Loading Marks the Starting Point of the Retrieval Pipeline
A retrieval system first needs consumable data sources. LangChain already provides unified loaders for formats such as PDF, CSV, JSON, Word, and Markdown, so developers can focus on data sources and downstream processing strategy.
For PDFs, the standard loader is usually enough if you only need plain text extraction. If you need tables, layout, or row-and-column-level structured parsing, you will often need a more specialized low-level solution.
from langchain_community.document_loaders import PyPDFLoader
from langchain_community.document_loaders import UnstructuredWordDocumentLoader
# Load a PDF document
pdf_loader = PyPDFLoader("物理知识点.pdf")
pdf_pages = pdf_loader.load() # Read content page by page
print(pdf_pages[0].page_content)
# Load a Word document
word_loader = UnstructuredWordDocumentLoader("语文.docx")
documents = word_loader.load() # Parse into multiple document chunks
for doc in documents:
print(doc.page_content)This example shows how LangChain can ingest both PDF and Word documents through a unified interface, producing standard Document objects for downstream splitting and embedding.
Document Splitting Must Balance Retrieval Precision and Context Integrity
If you embed an entire document directly, the resulting semantic representation becomes too broad, and retrieved results often lose focus. At the same time, LLM context windows are limited, so long texts significantly increase cost. The purpose of splitting is to make each chunk small enough while still preserving standalone meaning.
But overly fine-grained splitting also creates problems. If sentences are cut in half, table structures break, or procedural context gets lost, the system may retrieve chunks that are technically relevant but practically unusable. High-quality splitting is therefore not mechanical trimming. It must preserve both structure and semantics.
Common Splitting Strategies Involve Different Trade-Offs
CharacterTextSplitter is simple and brute-force, which makes it suitable for low-requirement scenarios. RecursiveCharacterTextSplitter recursively splits by paragraph, then line, then sentence, and is the most commonly used general-purpose option. TokenTextSplitter is better when you need strict control over model input cost.
For codebases, language-aware splitters are more appropriate because they can split around functions, classes, and syntax blocks. For Markdown documents, splitting by heading hierarchy preserves structural relationships better than character-based splitting.
AI Visual Insight: This diagram clearly illustrates the overlapping chunking mechanism: adjacent chunks retain shared text fragments to reduce the risk of context breaks. This overlap design improves semantic continuity during question answering, especially for retrieval across sentences and paragraphs.
from langchain_community.document_loaders import PyPDFLoader
from langchain_text_splitters import RecursiveCharacterTextSplitter
# Read the PDF
loader = PyPDFLoader("葵花宝典完整版.pdf")
pages = loader.load_and_split()
# Initialize the recursive splitter
text_splitter = RecursiveCharacterTextSplitter(
chunk_size=200, # Maximum characters per chunk
chunk_overlap=100, # Preserve overlap between adjacent chunks
length_function=len # Measure by character length
)
# Clean page text
data = [page.page_content.replace("\n", "").replace(" ", "") for page in pages]
# Generate a list of split Document objects
result = text_splitter.create_documents(data)
for page in result:
print(page.page_content, len(page.page_content))This example demonstrates the most common all-purpose splitting strategy and works well as a first retrieval experiment for most Chinese knowledge bases.
AI Visual Insight: This image comes from a text splitting visualization tool. It emphasizes chunk boundaries, overlap regions, and the mapping back to the original text, making it useful for validating whether chunk_size and chunk_overlap preserve semantic integrity.
Embedding Models Convert Text into Searchable Semantic Representations
Split text cannot be used for semantic search directly. It must first be mapped into vector space by an embedding model. LangChain provides a unified abstraction over different providers, including OpenAI, DashScope, Cohere, and Hugging Face.
Two interfaces appear frequently here: embed_documents for batch document processing and embed_query for user queries. Both must output vectors with the same dimensionality so that similarity matching can work correctly.
import os
from dotenv import load_dotenv
from langchain_community.embeddings import DashScopeEmbeddings
from langchain_huggingface import HuggingFaceEmbeddings
data = [
"New Year’s Day holiday: 3 days.",
"Spring Festival holiday: 9 days.",
"Labor Day holiday: 5 days."
]
load_dotenv()
api_key = os.getenv("QW_KEY")
# Cloud embedding model
bl_model = DashScopeEmbeddings(
dashscope_api_key=api_key,
model="text-embedding-v3"
)
bl_vectors = bl_model.embed_documents(data) # Batch-embed documents
bl_query = bl_model.embed_query("How many days is the Labor Day holiday?") # Embed the query
# Local Hugging Face embedding model
hf_model = HuggingFaceEmbeddings(
model_name="/path/to/bge-large-zh-v1.5",
encode_kwargs={"normalize_embeddings": True} # Normalize for similarity calculation
)
hf_vectors = hf_model.embed_documents(data)
hf_query = hf_model.embed_query("How many days is the Labor Day holiday?")This code shows that cloud-based and local embedding models share the same interface in LangChain, making later replacement seamless.
Vector Databases Handle Persistence and Nearest-Neighbor Recall
Once the text has been embedded, you need to store the vectors together with their original text chunks. The value of a vector database is not just storage. More importantly, it supports efficient similarity search.
For personal projects and small-to-medium RAG systems, Chroma is very easy to get started with. It supports both in-memory and persistent modes, and it can build an index directly from a list of Document objects, which makes it an excellent default for local experiments and prototype development.
import os
from dotenv import load_dotenv
from langchain_community.vectorstores import Chroma
from langchain_community.embeddings import DashScopeEmbeddings
from langchain_community.document_loaders import PyPDFLoader
from langchain_text_splitters import RecursiveCharacterTextSplitter
load_dotenv()
loader = PyPDFLoader("葵花宝典.pdf")
pages = loader.load_and_split()
text_splitter = RecursiveCharacterTextSplitter(
chunk_size=200,
chunk_overlap=100,
length_function=len,
add_start_index=True # Record the original start offset for traceability
)
data = [page.page_content.replace("\n", "").replace(" ", "") for page in pages]
paragraphs = text_splitter.create_documents(data)
embeddings = DashScopeEmbeddings(
dashscope_api_key=os.getenv("QW_KEY"),
model="text-embedding-v2"
)
db = Chroma.from_documents(paragraphs, embeddings) # Build a local vector store
docs = db.similarity_search("欲练此功的下一句是什么？", k=2)
for doc in docs:
print(doc.page_content)This example completes the minimum end-to-end loop from PDF ingestion to local vector retrieval and serves as a core starter template for learning RAG.
Retriever Provides a Higher-Level Abstraction for Search
Many beginners confuse vector databases with Retrievers. The former is like a warehouse: it stores data and computes similarity. The latter is like a dispatcher: it organizes querying, filtering, and result return through a unified interface.
The value of a Retriever lies in abstracting the search details. Developers do not need to manually write query embedding, similarity calls, and result packaging. Instead, they can use a unified method to get “relevant documents.” More importantly, a Retriever can also support advanced strategies such as hybrid retrieval, reranking, and multi-query rewriting.
# Query the vector database directly
query = "欲练此功的下一句是什么？"
docs = db.similarity_search(query, k=2)
# Query through a Retriever
retriever = db.as_retriever(search_kwargs={"k": 1})
relevant_docs = retriever.get_relevant_documents("欲练此功的下一句是什么？")This code shows that a Retriever does not replace the vector store. Instead, it provides a more general and extensible retrieval entry point on top of it.
Production Systems Usually Adopt Hybrid Retrieval Strategies
Pure vector retrieval is good at understanding intent, but it is less sensitive to model numbers, proper nouns, and exact terminology. Keyword retrieval has the opposite strengths: precise matches, but weaker semantic generalization. Enterprise systems usually combine both approaches and then apply a reranker for second-stage sorting.
If a query is highly complex, you can also use a Multi-Query Retriever to decompose one question into multiple perspectives, retrieve results separately, and then deduplicate and merge them. In practice, this is more robust than a single retrieval path and better reflects the complexity of real business corpora.
FAQ: The Three Questions Developers Ask Most Often
1. Why is RecursiveCharacterTextSplitter so often used as the default option?
It strikes a strong balance among speed, implementation complexity, and semantic integrity. For most long documents, it is more reliable than fixed-character splitting and far less expensive than semantic splitting.
2. How should I set chunk_size and chunk_overlap?
A common starting point is chunk_size=1000 and chunk_overlap=200. If the document structure is sparse and your Q&A granularity is finer, reduce them appropriately. If context dependency is strong, increase the overlap.
3. Should I learn vector databases or Retrievers first?
Start with vector databases, because they determine how data is stored and searched. Then learn Retrievers, because they determine how retrieval strategies are organized at a higher level. These two are not substitutes; they are layered abstractions.
Core Summary: This article systematically reconstructs the LangChain retrieval pipeline, covering the responsibility boundaries of document loading, text splitting, embeddings, vector databases, and Retrievers. With examples using PDF, Word, Chroma, and embedding models, it helps developers quickly build high-quality RAG retrieval infrastructure.