核心摘要
传统的 RAG 架构本质上是一条从检索到生成的单向流水线:用户提问 -> 向量检索 -> 拼接上下文 -> LLM 生成。这条流水线简单高效,但在面对真实业务中的复杂查询时,它缺乏"判断力"——无法决定该不该检索、从哪里检索、检索结果够不够好。
Agentic RAG 正是为解决这个问题而生。它将一个 AI Agent 嵌入 RAG 管道的核心位置,赋予系统自主决策、动态路由、质量评估和迭代修正的能力。本文将深入剖析其架构设计、四大核心模式,并提供基于 LangGraph 的实战代码。
📋 目录
✨ 核心要点
- 范式跃迁:Agentic RAG 将检索从"被动执行"升级为"主动思考",通过 Agent 闭环控制全链路。
- 四大模式:路由 (Routing)、多步骤 (Multi-step)、自纠错 (Corrective) 和自适应 (Adaptive) 是核心设计模式。
- 质量保障:引入"检索评估"环节,有效对抗模型幻觉,提高复杂问题的回答准确率。
- 落地建议:生产环境需重点关注延迟控制、防止无限循环及完善的可观测性体系。
💡 快速工具: Awesome Prompt 提示词库 — 发现和优化你的 Agent 提示词,显著提升 Agentic RAG 的路由与评估准确率。
从 Naive RAG 到 Agentic RAG:范式跃迁
在深入 Agentic RAG 之前,有必要厘清 RAG 技术的三个演进阶段。如果你对基础 RAG 架构还不熟悉,建议先阅读 RAG 检索增强生成基础教程。
三代 RAG 架构对比
| 维度 | Naive RAG | Advanced RAG | Agentic RAG |
|---|---|---|---|
| 检索策略 | 固定的 Top-K 向量检索 | 混合检索 + Rerank | Agent 动态选择检索策略 |
| 流程控制 | 线性单次 | 线性但有预处理/后处理 | 图状、可循环、可分支 |
| 质量保障 | 无 | 静态阈值过滤 | LLM 主动评估并自修正 |
| 数据源 | 单一向量库 | 单一向量库(优化索引) | 多数据源动态路由 |
| 典型延迟 | 1-2s | 2-4s | 3-15s(视复杂度而定) |
Naive RAG 的致命弱点在于它对所有查询一视同仁——无论用户问的是"你们公司的退款政策是什么"(简单事实查询)还是"对比你们最近三个季度的 ARR 增长趋势,并分析主要驱动因素"(复杂分析查询),系统都执行完全相同的检索-生成流程。
关于 Advanced RAG 中混合检索与 Rerank 的详细实现,可以参考 RAG 检索质量优化方案:从 Rerank 到 Hybrid Search。
Agentic RAG 的核心思想
Agentic RAG 的本质是将 RAG 管道中的"检索"环节从一个被动执行的函数调用,升级为一个由 AI Agent 主动规划和执行的智能工作流。这个 Agent 具备以下核心能力:
- 意图识别:判断用户查询是否需要外部知识,还是 LLM 自身就能回答。
- 数据源路由:根据查询类型选择最合适的知识库(向量库、SQL 数据库、搜索引擎、API)。
- 查询改写:当原始查询过于模糊或宽泛时,Agent 会主动改写或拆解查询。
- 结果评估:对检索到的文档进行相关性评判,决定是否需要重新检索。
- 迭代推理:在多轮检索-评估的循环中,逐步逼近高质量的最终答案。
这种架构与 ReAct 框架 的 Thought-Action-Observation 循环高度一致——Agent 在每一步都进行显式推理,然后决定下一步行动。
四大 Agentic RAG 设计模式
Agentic RAG 并非一种单一架构,而是一个设计模式族。根据业务场景的复杂度,可以选择不同的模式或将它们组合使用。
模式一:路由 RAG (Routing RAG)
路由 RAG 是最基础的 Agentic 模式。Agent 的核心职责是根据用户查询的语义意图,将请求分发到最合适的数据源。
典型场景:企业客服系统需要同时对接产品文档库、FAQ 知识库、工单系统和结构化的产品参数数据库。
from langgraph.graph import StateGraph, END
from typing import TypedDict, Literal
class AgentState(TypedDict):
query: str
route: str
documents: list
answer: str
def route_query(state: AgentState) -> AgentState:
"""Agent 根据查询意图决定路由"""
query = state["query"]
route_prompt = f"""分析以下用户查询,判断应该路由到哪个数据源:
- "vector_store": 产品功能、使用方法等非结构化文档
- "sql_database": 价格、库存、订单等结构化数据查询
- "web_search": 需要最新信息、竞品对比等实时数据
- "llm_direct": 通用常识问题,无需外部检索
查询: {query}
"""
result = llm.invoke(route_prompt)
state["route"] = result.content.strip()
return state
def retrieve_from_vector_store(state: AgentState) -> AgentState:
docs = vector_store.similarity_search(state["query"], k=5)
state["documents"] = docs
return state
def retrieve_from_sql(state: AgentState) -> AgentState:
sql_query = llm.invoke(f"将以下问题转换为SQL: {state['query']}")
results = db.execute(sql_query.content)
state["documents"] = [str(results)]
return state
# 构建路由图
graph = StateGraph(AgentState)
graph.add_node("router", route_query)
graph.add_node("vector_retrieval", retrieve_from_vector_store)
graph.add_node("sql_retrieval", retrieve_from_sql)
graph.add_node("web_search", search_web)
graph.add_node("generate", generate_answer)
graph.set_entry_point("router")
graph.add_conditional_edges("router", lambda s: s["route"], {
"vector_store": "vector_retrieval",
"sql_database": "sql_retrieval",
"web_search": "web_search",
"llm_direct": "generate",
})
路由 RAG 的关键挑战在于路由准确率。在生产环境中,建议先用少量标注数据对路由 Prompt 进行评估,路由准确率低于 90% 时应考虑使用微调后的小模型(如 fine-tuned BERT 分类器)替代 LLM 路由。
模式二:多步骤 RAG (Multi-Step RAG)
当用户查询涉及多个知识点的交叉推理时,单次检索往往不够。多步骤 RAG 让 Agent 将复杂问题拆解为多个子查询,逐步检索并汇总信息。
这与 AI Agent 中的任务分解 (Task Decomposition) 原理一脉相承。Agent 使用 链式思考 将问题拆解,然后对每个子问题独立检索。
def decompose_query(state: AgentState) -> AgentState:
"""将复杂查询拆解为子查询"""
decompose_prompt = f"""你是一个查询分析专家。请将以下复杂问题拆解为 2-4 个独立的子查询,
每个子查询应该可以通过单次文档检索来回答。
原始问题: {state["query"]}
以 JSON 数组格式输出子查询列表。"""
result = llm.invoke(decompose_prompt)
state["sub_queries"] = json.loads(result.content)
return state
def retrieve_for_sub_queries(state: AgentState) -> AgentState:
"""对每个子查询分别执行检索"""
all_docs = []
for sub_q in state["sub_queries"]:
docs = vector_store.similarity_search(sub_q, k=3)
all_docs.extend(docs)
# 去重并保留最相关的文档
state["documents"] = deduplicate_and_rank(all_docs)
return state
def synthesize_answer(state: AgentState) -> AgentState:
"""基于多步检索的结果进行综合推理"""
synthesis_prompt = f"""基于以下检索到的文档片段,综合回答用户的原始问题。
注意:你需要跨多个信息源进行推理和关联分析。
原始问题: {state["query"]}
子查询及检索结果:
{format_docs_with_sub_queries(state)}
"""
state["answer"] = llm.invoke(synthesis_prompt).content
return state
关于查询拆解的质量,直接决定了多步骤 RAG 的上限。好的拆解策略需要确保子查询之间既独立又互补。如果你的业务场景涉及实体间关系的推理,可以进一步参考 GraphRAG 工程化演进 中知识图谱的构建方法。
模式三:自纠错 RAG (Corrective RAG / CRAG)
自纠错 RAG 是 Agentic RAG 中最具实用价值的模式之一。它在生成答案之前,增加了一个 检索质量评估 (Retrieval Grading) 环节。如果评估结果不理想,Agent 会主动采取补救措施——改写查询重新检索,或者回退到 Web 搜索获取信息。
这种模式直接对抗了 RAG 系统中最常见的失败模式:检索到的文档看似相关,实际上并不包含回答问题所需的关键信息,最终导致 幻觉。
def grade_documents(state: AgentState) -> AgentState:
"""评估检索到的文档与查询的相关性"""
graded_docs = []
for doc in state["documents"]:
grade_prompt = f"""判断以下文档是否包含回答问题所需的关键信息。
问题: {state["query"]}
文档: {doc.page_content}
输出 "relevant" 或 "irrelevant",并简要说明理由。"""
result = llm.invoke(grade_prompt)
if "relevant" in result.content.lower():
graded_docs.append(doc)
state["documents"] = graded_docs
state["doc_quality"] = "sufficient" if len(graded_docs) >= 2 else "insufficient"
return state
def rewrite_query(state: AgentState) -> AgentState:
"""当检索质量不足时,改写查询"""
rewrite_prompt = f"""原始查询未能检索到足够相关的文档。请改写查询以提高召回质量。
原始查询: {state["query"]}
已检索但被判为不相关的文档主题: {state.get("irrelevant_topics", [])}
输出改写后的查询。"""
state["query"] = llm.invoke(rewrite_prompt).content
state["retry_count"] = state.get("retry_count", 0) + 1
return state
# 构建自纠错流程图
graph = StateGraph(AgentState)
graph.add_node("retrieve", retrieve_documents)
graph.add_node("grade", grade_documents)
graph.add_node("rewrite", rewrite_query)
graph.add_node("web_fallback", web_search_fallback)
graph.add_node("generate", generate_answer)
graph.set_entry_point("retrieve")
graph.add_edge("retrieve", "grade")
# 关键的条件路由逻辑
graph.add_conditional_edges("grade", decide_next_step, {
"sufficient": "generate", # 质量达标,直接生成
"rewrite": "rewrite", # 质量不足,改写查询
"fallback": "web_fallback", # 多次重试后仍不足,回退到 Web 搜索
})
graph.add_edge("rewrite", "retrieve") # 形成重试循环
graph.add_edge("web_fallback", "generate")
def decide_next_step(state: AgentState) -> str:
if state["doc_quality"] == "sufficient":
return "sufficient"
if state.get("retry_count", 0) >= 2:
return "fallback"
return "rewrite"
自纠错 RAG 中的 retry_count 上限设置至关重要。在生产环境中,必须设置明确的最大重试次数(通常为 2-3 次),防止 Agent 陷入无限重试循环。每次重试意味着额外的 LLM 调用和检索延迟,需要在回答质量与响应速度之间找到平衡。
模式四:自适应 RAG (Adaptive RAG)
自适应 RAG 是上述三种模式的有机融合,代表了 Agentic RAG 的最高形态。它的 Agent 不仅能路由、能拆解、能自纠错,还能在流程的每一个决策点上做出最优选择。
其核心架构可以用以下 TypeScript 伪代码描述:
interface AdaptiveRAGState {
query: string;
queryType: 'simple' | 'complex' | 'realtime' | 'no_retrieval';
documents: Document[];
subQueries?: string[];
gradeResult?: 'pass' | 'fail';
retryCount: number;
finalAnswer: string;
}
// 第一层决策:是否需要检索?
function classifyQuery(state: AdaptiveRAGState): AdaptiveRAGState {
// Agent 分析查询,判断是否需要外部知识
// "今天天气如何" -> realtime (需要搜索引擎)
// "什么是面向对象编程" -> no_retrieval (LLM 直接回答)
// "你们产品的退款政策" -> simple (单次检索)
// "对比 Q1-Q3 的运营数据并分析趋势" -> complex (多步骤检索)
return { ...state, queryType: classifiedType };
}
// 第二层决策:选择检索策略
function selectStrategy(state: AdaptiveRAGState): string {
switch (state.queryType) {
case 'no_retrieval': return 'direct_generate';
case 'realtime': return 'web_search';
case 'simple': return 'single_retrieval';
case 'complex': return 'multi_step_retrieval';
}
}
// 第三层决策:检索后的质量控制
function postRetrievalGate(state: AdaptiveRAGState): string {
if (state.gradeResult === 'pass') return 'generate';
if (state.retryCount >= MAX_RETRIES) return 'fallback_generate';
return 'rewrite_and_retry';
}
自适应 RAG 将路由、分解、评估三个维度的决策统一编排,其工作流可以用一张图概括:
用户查询 -> 意图分类 -> [直接回答 | Web搜索 | 单次检索 | 多步检索]
|
检索结果评估 -> 通过 -> 生成答案
|
不通过 -> 查询改写 -> 重新检索 (循环)
|
超过重试上限 -> 降级回答 + 标记低置信度
使用 LangGraph 构建完整的 Agentic RAG
下面我们用 LangGraph 实现一个融合了路由和自纠错的 Agentic RAG 系统。这是一个可以直接用于原型验证的完整示例。
from langgraph.graph import StateGraph, END
from langchain_openai import ChatOpenAI, OpenAIEmbeddings
from langchain_community.vectorstores import Chroma
from langchain_core.documents import Document
from typing import TypedDict, List, Optional
import json
# ========== 状态定义 ==========
class RAGState(TypedDict):
query: str
route: Optional[str]
documents: List[Document]
doc_grade: Optional[str]
retry_count: int
answer: Optional[str]
llm = ChatOpenAI(model="gpt-4o", temperature=0)
embeddings = OpenAIEmbeddings(model="text-embedding-3-small")
vectorstore = Chroma(embedding_function=embeddings, collection_name="knowledge_base")
# ========== 节点定义 ==========
def analyze_and_route(state: RAGState) -> RAGState:
"""入口节点:分析查询并决定路由"""
response = llm.invoke(
f"""分析查询意图,输出JSON格式:
{{"route": "vector_db" | "web_search" | "direct"}}
查询:{state['query']}"""
)
route_data = json.loads(response.content)
return {**state, "route": route_data["route"]}
def vector_retrieve(state: RAGState) -> RAGState:
"""从向量数据库检索"""
docs = vectorstore.similarity_search(state["query"], k=4)
return {**state, "documents": docs}
def grade_retrieval(state: RAGState) -> RAGState:
"""评估检索质量"""
if not state["documents"]:
return {**state, "doc_grade": "fail"}
doc_summaries = "\n".join([d.page_content[:200] for d in state["documents"]])
response = llm.invoke(
f"""评估这些文档是否能充分回答问题。输出 "pass" 或 "fail"。
问题:{state['query']}
文档摘要:{doc_summaries}"""
)
grade = "pass" if "pass" in response.content.lower() else "fail"
return {**state, "doc_grade": grade}
def rewrite_and_retry(state: RAGState) -> RAGState:
"""查询改写并重新检索"""
response = llm.invoke(
f"改写以下查询以提高检索效果,直接输出改写结果:{state['query']}"
)
new_query = response.content.strip()
docs = vectorstore.similarity_search(new_query, k=4)
return {
**state,
"query": new_query,
"documents": docs,
"retry_count": state["retry_count"] + 1,
}
def generate_answer(state: RAGState) -> RAGState:
"""生成最终回答"""
context = "\n\n".join([d.page_content for d in state["documents"]])
response = llm.invoke(
f"""基于以下上下文回答问题。如果上下文不足以完全回答,请如实说明。
问题:{state['query']}
上下文:{context}"""
)
return {**state, "answer": response.content}
def direct_answer(state: RAGState) -> RAGState:
"""LLM 直接回答(无需检索)"""
response = llm.invoke(state["query"])
return {**state, "answer": response.content}
# ========== 路由函数 ==========
def route_decision(state: RAGState) -> str:
return state["route"]
def grade_decision(state: RAGState) -> str:
if state["doc_grade"] == "pass":
return "pass"
if state["retry_count"] >= 2:
return "max_retries"
return "retry"
# ========== 构建图 ==========
workflow = StateGraph(RAGState)
workflow.add_node("analyze", analyze_and_route)
workflow.add_node("vector_retrieve", vector_retrieve)
workflow.add_node("grade", grade_retrieval)
workflow.add_node("rewrite", rewrite_and_retry)
workflow.add_node("generate", generate_answer)
workflow.add_node("direct", direct_answer)
workflow.set_entry_point("analyze")
workflow.add_conditional_edges("analyze", route_decision, {
"vector_db": "vector_retrieve",
"web_search": "vector_retrieve", # 简化:web_search 也走向量库
"direct": "direct",
})
workflow.add_edge("vector_retrieve", "grade")
workflow.add_conditional_edges("grade", grade_decision, {
"pass": "generate",
"retry": "rewrite",
"max_retries": "generate", # 超过重试上限,用现有文档尽力生成
})
workflow.add_edge("rewrite", "grade")
workflow.add_edge("generate", END)
workflow.add_edge("direct", END)
# 编译并运行
app = workflow.compile()
result = app.invoke({
"query": "对比上季度和本季度的客户流失率变化趋势",
"documents": [],
"retry_count": 0,
})
print(result["answer"])
这段代码的核心在于 grade 节点和 rewrite 节点之间形成的 条件循环。这正是 Agentic RAG 区别于传统 RAG 的本质特征——系统具备了自我反思和修正的能力。
生产环境最佳实践
将 Agentic RAG 从原型推向生产,需要重点关注以下几个工程维度。
延迟与成本控制
Agentic RAG 的每一次"思考"都意味着一次 LLM 调用。一个完整的自适应 RAG 流程可能涉及 3-6 次 LLM 调用(分类 1 次 + 检索 1 次 + 评估 1 次 + 可能的改写 1 次 + 生成 1 次 + 可能的生成质量评估 1 次)。
优化策略:
- 分级模型策略:路由和评估等"判断类"任务使用轻量模型(如 GPT-4o-mini 或 Claude 3.5 Haiku),仅在最终生成环节使用大模型。
- 并行执行:当多个子查询互相独立时,使用异步并行检索,而非串行。
- 缓存机制:对高频查询的路由结果和检索结果进行缓存,避免重复计算。
- 流式输出:在 Agent 思考的过程中,先流式输出"正在分析您的问题..."等中间状态,降低用户的感知延迟。
防止无限循环
Agent 陷入无限循环是 Agentic 系统的经典故障模式。当检索质量持续不达标时,Agent 可能无限地改写查询-重新检索-再次评估不通过。
# 必须设置硬性上限
MAX_RETRIES = 3
MAX_TOTAL_STEPS = 10
def should_continue(state: RAGState) -> str:
if state["retry_count"] >= MAX_RETRIES:
return "force_generate"
if state.get("total_steps", 0) >= MAX_TOTAL_STEPS:
return "force_generate"
return "continue"
同时建议在降级生成时,明确告知用户当前回答的置信度较低,并提供相关文档链接供用户自行查阅。
可观测性
Agentic RAG 的调试难度远高于传统 RAG,因为问题可能出现在任何一个决策节点。必须建设完善的可观测性体系:
- 全链路追踪:记录每个节点的输入、输出、耗时和 LLM 的原始响应。
- 决策日志:记录每次路由决策、质量评估结论和查询改写的具体内容。
- 指标监控:追踪平均重试次数、路由分布、评估通过率等关键指标。
LangSmith(LangChain 的追踪平台)可以直接对接 LangGraph,为每次运行生成完整的执行轨迹图。
评估体系
Agentic RAG 的评估不能只看最终答案质量,还需要评估中间决策的准确性:
| 评估维度 | 指标 | 目标 |
|---|---|---|
| 路由准确率 | 路由正确的查询占比 | > 90% |
| 检索召回率 | 评估节点标记为相关的文档中,实际相关的占比 | > 85% |
| 自纠错有效率 | 重试后答案质量提升的占比 | > 60% |
| 端到端准确率 | 最终回答的正确率(人工评估) | > 80% |
| 平均延迟 | 从查询到回答的总耗时 | < 10s (P95) |
与工具调用的结合
在更高级的场景中,Agentic RAG 的 Agent 不仅能检索文档,还能通过 Function Calling 和 Tool Use 调用外部 API。例如:
- 从 向量数据库 检索产品文档
- 调用内部 API 查询用户的订单状态
- 调用计算器工具进行数值推导
- 调用代码解释器执行数据分析
这使得 Agentic RAG 逐渐演化为一个通用的 Agentic Workflow,检索只是 Agent 工具箱中的一个工具而已。关于 AI Agent 的整体架构设计,可以参考 AI Agent 架构设计与代码实战指南。
Agentic RAG 与相关技术的关系
为了帮助你更好地定位 Agentic RAG 在技术版图中的位置,这里梳理它与几项相关技术的关系:
- GraphRAG:GraphRAG 专注于用知识图谱增强检索的深度,Agentic RAG 专注于用 Agent 增强检索的灵活度。两者可以结合——Agent 将 GraphRAG 作为一个高级检索工具来调用。详见 GraphRAG 工程化演进教程。
- 多 Agent 系统:当单个 Agent 难以同时处理路由、检索、评估、生成时,可以将这些职责拆分给多个专业 Agent 协作完成。
- 语义搜索 / Embedding:这些是 Agentic RAG 底层的检索基础设施。Agent 不替代它们,而是在它们之上进行智能编排。
- 提示工程:Agent 在每个决策节点的表现高度依赖 Prompt 的质量,特别是路由和评估环节的 Prompt 需要精心设计和持续调优。
- Guardrails:在 Agent 拥有多工具调用能力后,安全护栏变得更加重要——需要限制 Agent 能访问的数据范围和能执行的操作类型。
何时不需要 Agentic RAG
Agentic RAG 并非银弹。在以下场景中,更简单的方案可能是更好的选择:
- 查询模式单一:如果 95% 的查询都是同一类型的事实提取,Advanced RAG(混合检索 + Rerank)就足够了。
- 延迟要求极高:如果业务要求 P95 延迟在 2 秒以内,多次 LLM 调用的开销难以接受。
- 数据源单一:只有一个向量库,不需要路由决策。
- 成本敏感:每次查询 3-6 次 LLM 调用的成本在高 QPS 场景下可能不可接受。
在 RAG 分块策略 和 多模态 RAG 等基础优化做好的前提下,很多场景下 Advanced RAG 已经能满足需求。Agentic RAG 应该在这些基础优化都到位之后,针对确实需要动态决策的场景再引入。
总结
Agentic RAG 代表了 RAG 技术的下一个演进方向。它的核心贡献不是发明了新的检索算法,而是将 Agent 的自主决策能力引入了检索管道,让系统从"被动执行"升级为"主动思考"。
四大设计模式——路由、多步骤、自纠错、自适应——提供了从简单到复杂的渐进式落地路径。你不需要一步到位地实现最复杂的自适应 RAG,而是可以从路由 RAG 开始,逐步根据业务需求叠加自纠错和多步骤能力。
最关键的是,在追求 Agentic 能力的同时,不要忽视基础功的重要性。高质量的 Embedding 模型、精心设计的分块策略、稳健的 混合检索 管道——这些基础设施的质量,决定了 Agent 手中工具的上限,而工具的上限,也就是整个 Agentic RAG 系统的上限。
常见问题 (FAQ)
Q1: Agentic RAG 与传统 RAG 的核心区别是什么?
传统 RAG 是一条固定的流水线(检索 -> 生成),而 Agentic RAG 引入了 AI Agent 作为决策中枢,能够自主判断是否需要检索、选择哪个数据源、评估检索结果的质量,并在质量不达标时主动发起重新检索或改写查询,形成动态的闭环推理。
Q2: Agentic RAG 有哪些主要的设计模式?
业界公认的四大模式包括:路由 RAG(根据查询意图分发到不同数据源)、多步骤 RAG(将复杂问题拆解为子查询逐步检索)、自纠错 RAG(对检索结果进行质量评估并自动修正)、以及自适应 RAG(动态决定是否需要检索以及使用何种检索策略)。
Q3: 为什么 LangGraph 适合实现 Agentic RAG?
LangGraph 将 Agent 的工作流建模为有状态的图(Graph),每个节点代表一个操作(如检索、评估、生成),边则代表条件路由逻辑。这种图结构天然契合 Agentic RAG 中复杂的分支、循环和条件判断需求,且支持持久化状态和人机协作断点。
Q4: Agentic RAG 在生产环境中面临哪些挑战?
主要挑战包括:多次 LLM 调用导致的延迟累积与成本增加、Agent 陷入无限循环的风险、检索质量评估的准确性、以及多数据源路由的一致性。需要通过设置最大迭代次数、缓存中间结果、异步并行执行等策略来缓解。
Q5: Agentic RAG 适用于哪些业务场景?
它特别适用于需要跨多个知识库回答复杂问题的场景,例如企业级客服系统(需路由到产品文档、FAQ、工单系统)、法律合规审查(需要多步骤检索并交叉验证)、以及金融研报分析(需要从结构化数据和非结构化报告中联合推理)。
相关资源
- AI Agent 开发从入门到精通 — 深入了解 AI Agent 的底层架构与实战。
- RAG 检索增强生成基础教程 — 掌握 RAG 的核心原理与基础实现。
- RAG 检索质量优化方案:从 Rerank 到 Hybrid Search — 提升检索召回率与准确性的实战技巧。
- GraphRAG 工程化演进教程 — 探索知识图谱与 RAG 的结合。
- Awesome Prompt 提示词库 — 在线优化你的 Agent 指令。