万字深度：RAG 架构设计全景——从 Chunk 策略到生产级 Agentic RAG
作者：AI 技术架构师
标签：#RAG #检索增强生成 #AI架构 #向量数据库 #生产级AI
适合读者：中高级 AI 应用开发者、大模型架构师
引言：为什么 RAG 仍是 2026 年最重要的 AI 架构范式
2024 年初，RAG（Retrieval-Augmented Generation，检索增强生成）还被认为是"给 LLM 外挂一个向量库"的简单模式。到了 2026 年，RAG 已经演变为企业级 AI 应用的核心认知架构——它不再只是解决幻觉问题和知识过时问题的权宜之计，而是构建具有持久记忆、可解释推理、多源知识融合能力的 AI 系统的基础框架。
根据 UC Berkeley 最新研究（2025 年 6 月），生产环境中部署的 LLM 应用里有超过 70% 采用了某种形式的 RAG 架构。而在这 70% 中，仍然使用"Naive RAG"（直接向量检索 + 拼装上下文）的应用，用户满意度比采用 Advanced RAG 架构的应用低 34%。
本文将系统梳理 RAG 架构的完整技术栈——从最基础的文档分块策略，到最前沿的 Agentic RAG 范式，并给出可直接落地的代码示例和架构决策建议。
一、RAG 架构演进：五代技术范式
1.1 Naive RAG（2023 年前）
用户提问 → 向量检索 Top-K → 拼接上下文 → LLM 生成
问题：
- 检索精度低：向量检索对关键词匹配差，BM25 对语义理解差
- 缺乏上下文过滤：无关内容占据 Token 窗口
- 无自我校正：错误检索结果直接导致错误回答
1.2 Advanced RAG（2023-2024）
核心改进：
- 混合检索（Hybrid Search）：BM25 + 向量检索 + RRF 融合排序
- 重排序（Re-ranking）：用 Cross-Encoder 对初筛结果精排
- 上下文压缩（Context Compression）：用 LLM 或小型模型过滤无关内容
用户提问
↓
[Query 改写/扩展]
↓
[混合检索：BM25 ∪ 向量检索]
↓
[RRF 融合排序，取 Top-N]
↓
[Cross-Encoder 重排序，取 Top-K]
↓
[上下文压缩]
↓
LLM 生成
1.3 Modular RAG（2024）
将 RAG 流水线拆解为可组合的模块：
┌─────────────── Modular RAG 架构 ───────────────┐
│ │
│ Input → [Query Preprocessing] │
│ ↓ │
│ [Retriever Pool] ← 可并行多个检索器 │
│ ↓ │
│ [Post-Retrieval Filter] │
│ ↓ │
│ [Context Post-Processing] │
│ ↓ │
│ [Generator (LLM)] │
│ ↓ │
│ [Output Validation] │
│ ↓ │
│ Output │
└─────────────────────────────────────────────────┘
关键创新：检索器可插拔、可并行、可加权融合。
1.4 Graph RAG（2024-2025）
Microsoft Research 提出的 Graph RAG 范式，用知识图谱替代纯向量检索：
- 全局查询：利用图谱的社区结构做抽象摘要
- 局部查询：从实体出发做多跳推理
- 优势：解决传统 RAG 在"全局性问题"（如"这份报告的主要趋势是什么？"）上的根本性缺陷
1.5 Agentic RAG（2025-2026）
当前最前沿范式。RAG 系统本身作为一个 Agent，具备：
- 自适应检索：判断是否需要检索、检索几轮
- 工具调用：可调用搜索引擎、数据库、API
- 自我反思：验证检索结果质量，必要时重新检索
- 多步推理：将复杂问题拆解为多个子查询
用户提问
↓
[Router Agent：是否需要检索？]
├─ 不需要 → 直接回答
└─ 需要 ↓
[Query Planner：拆解子问题]
↓
[并行检索（向量/图谱/关键词）]
↓
[Self-Reflection：结果足够吗？]
├─ 不够 → 改写查询，重新检索
└─ 足够 ↓
[答案生成 + 引用标注]
二、Chunk 策略深度解析：决定 RAG 上限的基石
Chunking（分块）是 RAG 系统中最基础却最关键的决策。 chunk 质量直接决定检索召回率上限。
2.1 五种核心 Chunking 策略对比
| 策略 | 原理 | 优点 | 缺点 | 适用场景 |
|---|---|---|---|---|
| 固定大小分块 | 按 Token/字符数均匀切分 | 简单、速度快 | 破坏语义完整性 | 结构化文档（日志、代码） |
| 递归分块 | 按分隔符优先级递归切分 | 保持自然语义边界 | 需要调参 | 通用文档（推荐默认） |
| 语义分块 | 用 Embedding 相似度识别语义边界 | 语义连贯性最好 | 计算开销大 | 高质量问答系统 |
| 滑动窗口 | 固定大小 + Overlap | 保留跨块上下文 | 冗余度高 | 需要上下文连续性的场景 |
| 父子分块 | 小块检索 + 大块上下文 | 检索精度与上下文兼顾 | 存储开销翻倍 | 生产环境推荐 |
2.2 递归分块（Recursive Chunking）实现
递归分块是按分隔符优先级进行分层切分，分隔符优先级通常为：
[\n\n\n（三换）> \n\n（双换）> \n（单换）> 。（句号）> ，（逗号）> 空格 > 字符]
Python 实现示例：
from langchain_text_splitters import RecursiveCharacterTextSplitter
text_splitter = RecursiveCharacterTextSplitter(
separators=["\n\n\n", "\n\n", "\n", "。", "，", " ", ""],
chunk_size=512, # 每个 chunk 的目标大小（token）
chunk_overlap=50, # 重叠 token 数，保留跨 chunk 上下文
length_function=len, # 可替换为 token 计数器
)
docs = text_splitter.create_documents([raw_text])
关键参数调优建议：
chunk_size：通常 256-1024 token，取决于 Embedding 模型的最佳输入长度chunk_overlap：建议chunk_size * 0.1 ~ 0.2，过低会丢失跨块信息，过高浪费 Token- 对于中文文档，按字符数计算更接近实际 Token 消耗（中文约 1.5-2 字符 = 1 Token）
2.3 语义分块（Semantic Chunking）原理
语义分块的核心思路：先对每个句子做 Embedding，然后在语义发生显著变化的地方切分。
文档："RAG 是检索增强生成。它结合了检索和生成。
LSTM 是一种循环神经网络。它在序列建模中表现出色。
Transformer 架构革命了 NLP。BERT 和 GPT 都基于 Transformer。"
Step 1: 对每个句子做 Embedding
s1_emb = embed("RAG 是检索增强生成。")
s2_emb = embed("它结合了检索和生成。")
...
Step 2: 计算相邻句子的语义相似度
sim(s1, s2) = cosine_similarity(s1_emb, s2_emb) = 0.85 ← 高相似，同一主题
sim(s2, s3) = cosine_similarity(s2_emb, s3_emb) = 0.31 ← 低相似，主题切换！
Step 3: 在相似度低于阈值的位置切分
切分点：s2 和 s3 之间
LangChain 实现：
from langchain_experimental.text_splitter import SemanticChunker
from langchain_openai import OpenAIEmbeddings
embeddings = OpenAIEmbeddings()
semantic_chunker = SemanticChunker(
embeddings,
breakpoint_threshold_type="percentile", # 或 "standard_deviation"
breakpoint_threshold_amount=95, # 百分位数阈值
)
docs = semantic_chunker.create_documents([raw_text])
性能对比（基于 2026 年基准测试）：
| 方法 | 检索 NDCG@10 | 答案忠实度 | 处理速度 | Token 成本 |
|---|---|---|---|---|
| 固定大小 | 0.62 | 0.71 | ⭐⭐⭐⭐⭐ | $0.001/千文档 |
| 递归分块 | 0.68 | 0.75 | ⭐⭐⭐⭐ | $0.001/千文档 |
| 语义分块 | 0.79 | 0.84 | ⭐⭐ | $0.05/千文档 |
| 父子分块 | 0.77 | 0.82 | ⭐⭐⭐ | $0.003/千文档 |
2.4 父子分块（Parent-Child Chunking）生产实践
这是目前生产环境最推荐的策略：
┌─ 父块（Large Chunk，2048 token）─── 用于提供完整上下文 ──┐
│ "RAG 是检索增强生成框架。它结合了信息检索和文本生成两项 │
│ 核心技术。RAG 于 2020 年由 Meta AI 提出..." │
└────────────────────────────────────────────────────────────┘
↓ 检索时拆为子块
┌─ 子块 1（Small Chunk，512 token）── 用于精确检索 ──┐
│ "RAG 是检索增强生成框架。它结合了信息检索..." │
└──────────────────────────────────────────────────────┘
┌─ 子块 2 ──┐
│ "...和文本生成两项核心技术。RAG 于 2020 年..." │
└────────────┘
检索阶段：用子块做向量检索（精度高）
生成阶段：用子块对应的父块作为上下文（上下文完整）
LangChain 实现：
from langchain_text_splitters import RecursiveCharacterTextSplitter
from langchain_community.vectorstores import Chroma
# 父块分割器（大块，用于上下文）
parent_splitter = RecursiveCharacterTextSplitter(chunk_size=2000, chunk_overlap=200)
# 子块分割器（小块，用于检索）
child_splitter = RecursiveCharacterTextSplitter(chunk_size=400, chunk_overlap=50)
# 使用 ParentDocumentRetriever
from langchain.retrievers import ParentDocumentRetriever
from langchain_openai import OpenAIEmbeddings
retriever = ParentDocumentRetriever(
vectorstore=Chroma(embedding_function=OpenAIEmbeddings()),
docstore=InMemoryStore(), # 存储父块
parent_splitter=parent_splitter,
child_splitter=child_splitter,
)
三、混合检索架构：BM25 + 向量 + RRF
3.1 为什么需要混合检索？
向量检索（Dense Retrieval）擅长语义理解但：
- 对专有名词、产品型号、ID 等精确匹配差
- 在低频术语上表现不佳
BM25（Sparse Retrieval）擅长关键词匹配但：
- 无法理解语义相似（"AI" vs "人工智能"）
- 对 paraphrasing 完全失效
混合检索 = 语义理解能力 + 精确匹配能力，两者互补。
3.2 RRF（倒数排名融合）算法
RRF 是混合检索中最常用的融合算法：
对于查询 Q，有两个检索源：
- 向量检索返回排序： [doc_A, doc_B, doc_C, ...]
- BM25 返回排序： [doc_B, doc_A, doc_D, ...]
RRF 计算公式：
RRF(d) = Σ 1 / (k + rank_i(d))
其中：k 为常数（通常取 60），rank_i(d) 为文档 d 在第 i 个检索结果中的排名
示例（k=60）：
RRF(doc_A) = 1/(60+1) + 1/(60+2) = 0.01639 + 0.01613 = 0.03252
RRF(doc_B) = 1/(60+2) + 1/(60+1) = 0.01613 + 0.01639 = 0.03252
RRF(doc_C) = 1/(60+3) + 0 = 0.01613
RRF(doc_D) = 0 + 1/(60+3) = 0.01613
关键洞察：RRF 不需要调权重，自动平衡不同检索源的贡献。
3.3 LangChain 混合检索实现
from langchain.retrievers import EnsembleRetriever
from langchain_community.retrievers import BM25Retriever
from langchain_community.vectorstores import FAISS
from langchain_openai import OpenAIEmbeddings
# 向量检索器
vectorstore = FAISS.from_documents(docs, OpenAIEmbeddings())
vector_retriever = vectorstore.as_retriever(search_kwargs={"k": 5})
# BM25 检索器
bm25_retriever = BM25Retriever.from_documents(docs)
bm25_retriever.k = 5
# 融合检索器（默认使用 RRF）
ensemble_retriever = EnsembleRetriever(
retrievers=[bm25_retriever, vector_retriever],
weights=[0.4, 0.6] # 可手动调整权重，或用 RRF 自动融合
)
# 使用
results = ensemble_retriever.get_relevant_documents("RAG 混合检索原理")
四、重排序（Re-ranking）：检索精度的倍增器
4.1 为什么需要 Re-ranker？
第一阶段检索（Bi-Encoder）为了速度，用向量距离做相似度计算，精度有限。
第二阶段用 Cross-Encoder 对 Query-Document 对做深度交互计算，精度大幅提升。
第一阶段（检索）：Query → [Bi-Encoder] → 向量相似度排序 → Top-100
↓
第二阶段（重排）：[Cross-Encoder] 对 Query-Doc 对做注意力交互
↓
最终输出：Top-K（K=5~10）
精度对比：
- Bi-Encoder（无重排）：NDCG@10 ≈ 0.65
-
- Cross-Encoder 重排：NDCG@10 ≈ 0.78（+20% 提升）
4.2 Cohere / BGE Re-ranker 实践
from langchain_community.document_compressors import CrossEncoderReranker
from langchain_community.cross_encoders import HuggingFaceCrossEncoder
# 使用 BGE Re-ranker（开源，中文友好）
model = HuggingFaceCrossEncoder(model_name="BAAI/bge-reranker-v2-m3")
reranker = CrossEncoderReranker(model=model, top_n=5)
# 嵌入检索链
from langchain.retrievers.document_compressors import DocumentCompressorPipeline
from langchain_community.document_transformers import EmbeddingsRedundantFilter
# 完整检索管道
retriever = ensemble_retriever | reranker
生产建议：
- 第一阶段取 Top-50~100（保证召回率）
- 第二阶段重排取 Top-5~10（保证精确度）
- 中文场景优先用
bge-reranker-v2-m3（支持多语言）
五、高级 RAG 模式
5.1 Graph RAG：知识图谱增强
Microsoft Graph RAG 的核心创新：用图谱社区摘要应对全局查询。
传统 RAG 处理全局问题的缺陷：
问："这份 50 页报告的主要趋势是什么？"
→ 向量检索只能返回局部片段，无法获取全局视图
Graph RAG 的解决方案：
1. 从文档提取实体和关系 → 构建知识图谱
2. 对图谱做社区检测（Leiden 算法）
3. 对每个社区生成摘要
4. 全局查询：将所有社区摘要作为上下文
LangChain 实现图谱检索：
from langchain.graphs import Neo4jGraph
from langchain.chains import GraphCypherQAChain
from langchain_openai import ChatOpenAI
graph = Neo4jGraph(
url="bolt://localhost:7687",
username="neo4j",
password="password"
)
# 让 LLM 生成 Cypher 查询
chain = GraphCypherQAChain.from_llm(
ChatOpenAI(temperature=0),
graph=graph,
verbose=True
)
result = chain.invoke({"query": "受到影响最大的实体有哪些？"})
5.2 Self-RAG：自我反思式检索
Self-RAG 引入反思 Token（reflection tokens），让模型在生成过程中自主决定：
[Retrieve]：是否需要检索？
→ 是 → 检索相关文档
→ 否 → 直接生成
[IsRel]：检索结果是否相关？
→ 是 → 继续
→ 否 → 重新检索或标注"无相关信息"
[IsSup]：生成内容是否有检索结果支持？
→ 是 → 输出（带引用）
→ 否 → 标注为模型自有知识
核心价值：减少不必要的检索（降低延迟和成本），提高答案可溯源性和可靠性。
5.3 Agentic RAG：RAG 系统的自主决策
Agentic RAG 是 2026 年最热门的方向，核心特征是检索过程的自适应和自校正：
┌───────────── Agentic RAG 决策循环 ─────────────┐
│ │
│ User Query │
│ ↓ │
│ [Intent Classifier] │
│ ↓ │
│ 需要检索？──否──→ 直接生成 │
│ ↓ 是 │
│ [Query Planner] │
│ 单跳？ 多跳？ │
│ ↓ ↓ │
│ 单次检索 拆解子查询 → 并行检索 │
│ ↓ │
│ [Result Evaluator] │
│ 结果足够？──否──→ 改写查询 → 重新检索 │
│ ↓ 是 │
│ [Answer Generator + Citation] │
│ ↓ │
│ Output │
└────────────────────────────────────────────────┘
LangGraph 实现 Agentic RAG：
from langgraph.graph import StateGraph, END
class AgentState(TypedDict):
query: str
sub_queries: List[str]
retrieved_docs: List[Document]
answer: str
needs_retry: bool
workflow = StateGraph(AgentState)
# 定义节点
workflow.add_node("planner", query_planner_node)
workflow.add_node("retriever", retrieval_node)
workflow.add_node("evaluator", evaluate_retrieval_node)
workflow.add_node("generator", answer_generation_node)
# 定义边（条件跳转）
workflow.add_conditional_edges(
"evaluator",
lambda s: "retrieve" if s["needs_retry"] else "generate",
)
六、RAG 评估框架：从"感觉还行"到量化优化
6.1 RAGAS 五大核心指标
RAGAS 是当前最流行的 RAG 评估框架，五大指标覆盖完整流水线：
┌────────── RAGAS 指标体系 ──────────┐
│ │
│ 检索质量 │
│ ├─ Context Precision（上下文精度） │
│ └─ Context Recall（上下文召回率） │
│ │
│ 生成质量 │
│ ├─ Faithfulness（忠实度） │
│ ├─ Answer Relevance（答案相关性） │
│ └─ Answer Correctness（答案正确性）│
│ │
└────────────────────────────────────┘
指标详解：
| 指标 | 定义 | 计算方式 | 目标 |
|---|---|---|---|
| Faithfulness | 答案是否完全基于检索上下文 | NLI 模型判断答案中每个事实是否有上下文支持 | → 1.0 |
| Answer Relevance | 答案是否回答了问题 | 用 LLM 对"答案回复了问题的程度"打分 | → 1.0 |
| Context Precision | 相关文档是否排在前面 | PR 曲线下面积（近似） | → 1.0 |
| Context Recall | 答案所需信息是否都在上下文中 | 答案中的可验证声明是否都能在上下文中找到 | → 1.0 |
| Answer Correctness | 答案与标准答案的匹配度 | 语义相似度 + 关键词重叠 | → 1.0 |
6.2 RAGAS 评估代码示例
from ragas import evaluate
from ragas.metrics import (
faithfulness,
answer_relevancy,
context_precision,
context_recall,
)
# 准备评估数据集
eval_dataset = Dataset.from_dict({
"question": ["RAG 是什么？", "如何优化 RAG 检索？"],
"answer": ["RAG 是检索增强生成...", "优化 RAG 检索的方法包括..."],
"contexts": [
["RAG 全称 Retrieval-Augmented Generation...", "..."],
["混合检索可以提升 RAG 效果...", "..."]
],
"ground_truth": [
"RAG（检索增强生成）是一种结合检索和生成的技术...",
"优化 RAG 检索的主要方法包括：混合检索、重排序..."
]
})
# 执行评估
results = evaluate(
eval_dataset,
metrics=[faithfulness, answer_relevancy, context_precision, context_recall],
llm=ChatOpenAI(model="gpt-4o"),
embeddings=OpenAIEmbeddings()
)
print(results)
# 输出：
# {'faithfulness': 0.92, 'answer_relevancy': 0.88,
# 'context_precision': 0.85, 'context_recall': 0.90}
6.3 评估驱动的迭代优化闭环
┌───────── RAG 优化闭环 ─────────┐
│ │
│ 1. 用 RAGAS 评估当前系统 │
│ ↓ │
│ 2. 识别短板指标 │
│ ├─ Faithfulness 低 → 检索精度问题 → 优化 Chunk 策略/混合检索│
│ ├─ Answer Relevance 低 → 提示词问题 → 优化 System Prompt │
│ └─ Context Recall 低 → 召回率问题 → 增加检索数量/换 Embedding 模型│
│ ↓ │
│ 3. 针对性优化 │
│ ↓ │
│ 4. 重新评估（A/B Test） │
│ ↓ │
│ 5. 部署优化版本 │
│ │
└────────────────────────────────┘
七、生产级 RAG 系统最佳实践
7.1 架构 Checklist
✅ Chunking
- [ ] 选择了与文档类型匹配的分块策略
- [ ] chunk_size 经过实验调优（建议 256-1024）
- [ ] 实现了父子分块（生产推荐）
✅ 检索
- [ ] 使用了混合检索（BM25 + 向量）
- [ ] 实现了 RRF 或加权融合
- [ ] 使用了 Re-ranker（BGE / Cohere）
✅ 生成
- [ ] System Prompt 中包含答案格式要求和引用要求
- [ ] 实现了流式输出（提升用户体验）
- [ ] 有 Hallucination 防护（Faithfulness 检查）
✅ 评估
- [ ] 用 RAGAS 建立了基线指标
- [ ] 每次迭代都有量化对比
- [ ] 有在线评估（用户反馈收集）
✅ 工程化
- [ ] 实现了语义缓存（相同问题不重复检索）
- [ ] 有完整的调用链追踪（LangSmith / Phoenix）
- [ ] 有成本控制（Token 统计 + 预算告警）
7.2 语义缓存：降低 40% 成本的利器
from langchain_community.cache import InMemoryCache
from langchain.globals import set_llm_cache
from langchain_openai import ChatOpenAI
# 启用语义缓存（相同/相似问题直接返回缓存答案）
set_llm_cache(InMemoryCache())
# 或用 Redis 语义缓存（生产推荐）
from langchain_community.cache import RedisSemanticCache
set_llm_cache(
RedisSemanticCache(
redis_url="redis://localhost:6379",
embedding=OpenAIEmbeddings(),
score_threshold=0.85 # 语义相似度阈值
)
)
效果：语义缓存可以将重复问题的响应时间从 2-5 秒降低到 50ms 以内，成本降低 30-50%。
7.3 安全防护
生产级 RAG 必须防范以下风险：
┌────────── RAG 安全防护层 ──────────┐
│ │
│ Input 防护 │
│ ├─ 注入检测：防止 Prompt Injection│
│ ├─ 敏感信息过滤：防止 PII 泄露 │
│ └─ 查询改写白名单 │
│ │
│ Retrieval 防护 │
│ ├─ 访问控制：多租户数据隔离 │
│ ├─ 敏感文档过滤 │
│ └─ 检索结果合规性检查 │
│ │
│ Output 防护 │
│ ├─ PII 脱敏 │
│ ├─ 有害内容过滤 │
│ └─ 答案忠实度检查（Faithfulness） │
│ │
└────────────────────────────────────┘
八、总结与展望
RAG 架构在 2026 年已经形成了相对成熟的技术栈：
RAG 技术栈全景
│
├─ 数据层：文档解析 → Chunking → Embedding → 向量存储
├─ 检索层：混合检索（BM25+向量+RRF） → Re-ranking
├─ 增强层：上下文压缩 → 查询扩展 → 自我反思
├─ 生成层：LLM 生成 → 引用标注 → 格式校验
├─ 评估层：RAGAS 指标 → A/B 测试 → 持续优化
└─ 工程层：语义缓存 → 调用链追踪 → 成本监控
未来方向（2026-2027）：
- 端到端优化的 RAG：检索器和生成器联合训练（而非独立优化）
- 多模态 RAG：支持图像、表格、视频帧的联合检索
- 个性化 RAG：根据用户历史和行为做个性化检索排序
- 自我进化的 RAG：系统自动识别短板并触发优化流程
参考资料
- UC Berkeley RAG Survey（2025）：Retrieval-Augmented Generation: A Comprehensive Survey
- Microsoft Research - Graph RAG（2024）：From Local to Global
- Meta AI - Self-RAG（2023）：Learning to Retrieve, Generate, and Critique
- RAGAS Framework：github.com/explodinggr…
- LangChain RAG 文档：python.langchain.com/docs/tutori…
- BGE Reranker：github.com/FlagOpen/Fl…
本文约 3200 字，覆盖 RAG 架构设计的核心技术点。如有疑问或希望深入讨论某个子话题，欢迎评论区交流。
