文章目录
- 知识检索(RAG)
-
- [一、核心概念:为什么需要 RAG?](#一、核心概念:为什么需要 RAG?)
- [二、RAG 的六大核心概念](#二、RAG 的六大核心概念)
-
- [2.1 嵌入(Embeddings)](#2.1 嵌入(Embeddings))
- [2.2 文本相似度与语义相似度](#2.2 文本相似度与语义相似度)
- [2.3 文档分块(Chunking)](#2.3 文档分块(Chunking))
- [2.4 向量数据库](#2.4 向量数据库)
- [2.5 混合检索(Hybrid Search)](#2.5 混合检索(Hybrid Search))
- [2.6 RAG 的核心挑战](#2.6 RAG 的核心挑战)
- [三、GraphRAG:用知识图谱升级 RAG](#三、GraphRAG:用知识图谱升级 RAG)
-
- [3.1 GraphRAG 是什么?](#3.1 GraphRAG 是什么?)
- [3.2 传统 RAG vs GraphRAG](#3.2 传统 RAG vs GraphRAG)
- [3.3 GraphRAG 的典型应用场景](#3.3 GraphRAG 的典型应用场景)
- [3.4 GraphRAG 的局限性](#3.4 GraphRAG 的局限性)
- [四、智能体 RAG:RAG 的终极进化](#四、智能体 RAG:RAG 的终极进化)
-
- [4.1 智能体 RAG 是什么?](#4.1 智能体 RAG 是什么?)
- [4.2 智能体 RAG 的四大核心能力](#4.2 智能体 RAG 的四大核心能力)
- [4.3 三种 RAG 模式对比](#4.3 三种 RAG 模式对比)
- [4.4 智能体 RAG 的挑战](#4.4 智能体 RAG 的挑战)
- 五、源码解构
-
- [5.1 示例一:Google Search 实现 RAG(ADK)](#5.1 示例一:Google Search 实现 RAG(ADK))
- [5.2 示例二:Vertex AI RAG Corpus(ADK)](#5.2 示例二:Vertex AI RAG Corpus(ADK))
- [5.3 示例三:LangChain + LangGraph 完整 RAG 实现](#5.3 示例三:LangChain + LangGraph 完整 RAG 实现)
-
- 步骤一:加载文档并分块
- 步骤二:创建向量数据库
- [步骤三:定义 RAG 状态图](#步骤三:定义 RAG 状态图)
- 步骤四:定义检索节点
- 步骤五:定义生成节点
- 步骤六:组装工作流
- 步骤七:执行查询
- [六、RAG 实际应用场景](#六、RAG 实际应用场景)
- 七、与前几章的联系
- 八、关键要点总结
- 九、一图速览
- 十、参考文献
知识检索(RAG)
一、核心概念:为什么需要 RAG?
一句话:LLM 的知识是静态的,RAG 让它从"闭卷考试"变成"开卷考试",随时查阅外部最新资料。
打个比方:
- 没有 RAG 的 LLM:像一个被关在图书馆里的学者,只能凭记忆回答问题,不知道昨天发生的事
- 有 RAG 的 LLM:像一个带着搜索引擎的学者,遇到不确定的问题可以实时查阅资料再回答
RAG 解决的三大痛点:
| 痛点 | 说明 | RAG 的解法 |
|---|---|---|
| 知识过时 | 训练数据截止后的事件一无所知 | 实时检索外部最新信息 |
| 幻觉问题 | 不确定时编造看似合理的答案 | 基于检索到的真实数据回答 |
| 领域盲区 | 缺乏企业内部或专业领域知识 | 接入企业文档库、Wiki 等专有数据源 |
RAG 的核心流程:
用户提问
↓
① 检索:在知识库中搜索相关信息片段(语义搜索,非关键词匹配)
↓
② 增强:将检索到的信息片段附加到原始提示中
↓
③ 生成:LLM 基于增强后的提示生成响应
↓
输出:准确、有事实依据、可验证的答案(附带引用来源)
RAG 的四大优势:
- 实时性:突破训练数据的时间限制
- 准确性:以可验证数据为基础,降低幻觉
- 专业性:利用企业内部文档等专有知识
- 可追溯:提供引用来源,提升可信度
二、RAG 的六大核心概念
2.1 嵌入(Embeddings)
一句话:把文字变成数字向量,让计算机能"算"出两段话的意思有多近。
打个比方:
- 把每个词想象成地图上的一个坐标点
- 意思相近的词,坐标距离越近
- "cat"在(2, 3),"kitten"在(2.1, 3.1),"car"在(8, 1)
- 实际嵌入空间远不止二维,通常是数百到数千维
关键原理:
- 嵌入是文本的数值表示(向量/数字列表)
- 语义相近的文本,向量距离更近
- 高维空间能精细刻画语言的各种语义关系
- 嵌入模型(如 OpenAI Embeddings)负责将文本转为向量
2.2 文本相似度与语义相似度
| 类型 | 关注点 | 举例 | 局限 |
|---|---|---|---|
| 表层相似度 | 词汇重叠 | "首都"和"首府"字面相似 | 无法理解同义不同词 |
| 语义相似度 | 含义和上下文 | "furry feline companion"和"domestic cat" | 需要好的嵌入模型 |
核心区别:
- "What is the capital of France?" 和 "Which city is the capital of France?"
- 关键词匹配可能无法关联,但语义搜索能识别它们表达同一问题
- RAG 的语义搜索就是寻找与查询语义距离最小的文档
2.3 文档分块(Chunking)
一句话:把大文档切成小块,让检索更精准高效。
打个比方:
- 一本 500 页的百科全书太大了,不可能每次都翻完
- 分块就像把百科全书按条目拆成卡片,需要什么查什么
分块策略对比:
| 策略 | 说明 | 优点 | 缺点 |
|---|---|---|---|
| 固定大小分块 | 按字符数切分 | 简单、可控 | 可能切断语义完整性 |
| 按段落/章节分块 | 按文档结构切分 | 保持语义完整 | 需要文档有清晰结构 |
| 句子级分块 | 按句子切分 | 粒度最细 | 上下文可能不足 |
| 重叠分块 | 相邻块有重叠内容 | 防止边界信息丢失 | 存储冗余 |
关键代码(LangChain 示例):
python
text_splitter = CharacterTextSplitter(chunk_size=500, chunk_overlap=50)
chunks = text_splitter.split_documents(documents)
chunk_size=500:每块最多 500 字符chunk_overlap=50:相邻块重叠 50 字符,防止关键信息被切断
2.4 向量数据库
一句话:专门用来存储和快速检索嵌入向量的数据库,是 RAG 系统的"搜索引擎"。
打个比方:
- 传统数据库像电话簿------按名字精确查找
- 向量数据库像"意念搜索引擎"------你说"想找可爱的宠物",它能找到所有猫和狗,即使没出现"可爱"这个词
主流向量数据库对比:
| 数据库 | 特点 | 适用场景 |
|---|---|---|
| Pinecone | 全托管云服务,开箱即用 | 快速原型、中小规模 |
| Weaviate | 开源,支持混合检索 | 生产环境、需要灵活性 |
| Chroma DB | 轻量级,本地开发友好 | 开发测试、小型项目 |
| Milvus | 高性能,可扩展 | 大规模生产环境 |
| Qdrant | Rust 编写,高性能 | 对延迟敏感的场景 |
| pgvector | PostgreSQL 扩展 | 已有 PG 基础设施 |
底层检索算法:
- HNSW(Hierarchical Navigable Small World):基于图的近似最近邻算法,速度快
- FAISS(Facebook AI Similarity Search):Facebook 开源的高效向量检索库
- ScaNN(Scalable Nearest Neighbors):Google 开源的 ANN 检索库
2.5 混合检索(Hybrid Search)
一句话:把关键词匹配和语义搜索结合起来,既准又全。
用户查询
├─→ BM25(关键词检索)──→ 精确匹配结果
└─→ 语义搜索(向量检索)──→ 语义相关结果
↓
加权合并 + 去重
↓
最终检索结果
| 检索方式 | 原理 | 擅长 | 弱点 |
|---|---|---|---|
| BM25 | 关键词频率统计 | 精确术语、专有名词 | 不理解语义 |
| 语义搜索 | 嵌入向量距离 | 同义词、概念关联 | 可能漏掉精确术语 |
| 混合检索 | 两者结合 | 兼顾精确和语义 | 系统复杂度更高 |
2.6 RAG 的核心挑战
| 挑战 | 说明 | 影响 |
|---|---|---|
| 信息碎片化 | 答案分散在多个块中,难以获取完整上下文 | 答案不准确或不完整 |
| 检索噪声 | 检索到无关块会干扰 LLM | 引入错误信息 |
| 知识矛盾 | 多个来源信息不一致 | 需要额外的验证和调和机制 |
| 预处理工程量大 | 需将整个知识库分块、嵌入并存入向量数据库 | 运维成本高 |
| 数据同步 | 企业 Wiki 等动态内容需定期更新 | 保持最新需要持续投入 |
| 性能延迟 | 检索 + 生成增加响应时间 | 影响用户体验 |
三、GraphRAG:用知识图谱升级 RAG
3.1 GraphRAG 是什么?
一句话 :用知识图谱替代简单向量数据库,让 RAG 能理解信息之间的关系。
打个比方:
- 传统 RAG:像图书馆索引卡------能找到包含某个关键词的段落
- GraphRAG:像思维导图------不仅找到信息,还能看到信息之间的关联,比如"A 认识 B,B 在 C 公司工作"
GraphRAG 的核心机制:
- 实体(节点):人物、公司、事件等
- 关系(边):实体之间的连接
- 通过遍历图谱中的关系来回答复杂问题
3.2 传统 RAG vs GraphRAG
| 特性 | 传统 RAG | GraphRAG |
|---|---|---|
| 数据结构 | 向量空间 | 知识图谱 |
| 检索方式 | 语义相似度 | 图遍历 + 关系推理 |
| 擅长问题 | 单文档检索 | 跨文档关联分析 |
| 上下文完整性 | 可能碎片化 | 能整合分散信息 |
| 构建成本 | 中等 | 高(需要构建知识图谱) |
| 维护难度 | 中等 | 高(图谱需要持续更新) |
| 灵活性 | 高 | 低 |
| 延迟 | 较低 | 可能更高 |
3.3 GraphRAG 的典型应用场景
| 场景 | 说明 |
|---|---|
| 金融分析 | 分析企业与市场事件的复杂关联 |
| 科学研究 | 发现基因与疾病之间的关系 |
| 法律检索 | 关联判例、法规和当事人信息 |
| 供应链分析 | 追踪供应商、产品和事件的关联链 |
3.4 GraphRAG 的局限性
- 构建高质量知识图谱需要大量专业投入
- 系统灵活性较低,难以快速适应新领域
- 延迟可能高于简单向量检索
- 效果完全依赖底层图结构的质量和完整性
四、智能体 RAG:RAG 的终极进化
4.1 智能体 RAG 是什么?
一句话:在标准 RAG 基础上加入一个"智能质检员",主动审查、验证和精炼检索结果。
打个比方:
- 标准 RAG:像一个实习生------搜到什么就给什么,不管是否过时
- 智能体 RAG:像一个经验丰富的研究员------搜到资料后先验证可靠性、调和矛盾、补充缺失信息,再给出答案
4.2 智能体 RAG 的四大核心能力
能力一:反思与来源验证
场景:用户问"公司远程办公政策是什么?"
标准 RAG 的做法:
→ 检索到 2020 年博客 + 2025 年官方政策
→ 全部塞给 LLM
→ 可能给出过时答案
智能体 RAG 的做法:
→ 检索到同样的两份文档
→ 分析文档元数据,识别 2025 政策为最新权威来源
→ 丢弃过时博客,仅将正确内容送入 LLM
→ 答案准确可靠 ✅
能力二:调和知识冲突
场景:财务分析师问"Alpha 项目 Q1 预算是多少?"
检索结果:
→ 文件 A(初步方案):€50,000
→ 文件 B(最终报告):€65,000
智能体 RAG 的做法:
→ 识别两份数据存在矛盾
→ 分析文档类型,财务报告优先级高于初步方案
→ 采用 €65,000,确保答案基于最可靠数据 ✅
能力三:多步推理与复杂查询
场景:用户问"我们产品的功能和定价与竞争对手 X 有何区别?"
标准 RAG 的做法:
→ 检索到一些零散信息
→ LLM 凑合回答,可能遗漏关键对比
智能体 RAG 的做法:
→ 拆分为 4 个子查询:
① 我们产品的功能
② 我们产品的定价
③ 竞争对手 X 的功能
④ 竞争对手 X 的定价
→ 分别检索 → 综合成结构化对比
→ 输出完整、全面的分析 ✅
能力四:识别知识空缺与外部工具调用
场景:用户问"昨天新产品发布后市场的即时反应如何?"
智能体 RAG 的做法:
→ 检索内部知识库(每周更新)→ 未找到相关信息
→ 识别知识空缺
→ 调用实时 Web 搜索 API
→ 获取最新新闻和社交媒体舆情
→ 基于最新数据生成答案 ✅
→ 突破静态数据库限制!
4.3 三种 RAG 模式对比
| 特性 | 标准 RAG | GraphRAG | 智能体 RAG |
|---|---|---|---|
| 核心机制 | 向量语义检索 | 知识图谱遍历 | 智能体推理 + 验证 |
| 信息处理 | 被动检索 | 关系推理 | 主动审查和精炼 |
| 冲突处理 | 无 | 部分支持 | 智能调和 |
| 复杂查询 | 单步检索 | 跨文档关联 | 多步推理 + 子查询 |
| 知识空缺 | 无法处理 | 有限 | 调用外部工具 |
| 实现复杂度 | 低 | 高 | 最高 |
| 延迟 | 低 | 中 | 高 |
| 成本 | 低 | 中 | 高 |
| 答案可靠性 | 中 | 高 | 最高 |
4.4 智能体 RAG 的挑战
| 挑战 | 说明 |
|---|---|
| 工程复杂度高 | 设计和维护智能体的决策逻辑需要大量投入 |
| 计算开销大 | 反思、工具调用、多步推理比直接检索消耗更多算力 |
| 延迟增加 | 多轮推理导致响应时间变长 |
| 新的错误源 | 智能体本身可能推理失误,陷入无用循环或错误丢弃信息 |
五、源码解构
5.1 示例一:Google Search 实现 RAG(ADK)
python
from google.adk.tools import google_search
from google.adk.agents import Agent
search_agent = Agent(
name="research_assistant",
model="gemini-2.0-flash-exp",
instruction="You help users research topics. When asked, use the Google Search tool",
tools=[google_search] # 直接注入 Google Search 作为工具
)
逐行解读:
| 行号 | 代码 | 说明 |
|---|---|---|
| 1 | from google.adk.tools import google_search |
导入 Google Search 工具,这是 ADK 内置的检索工具 |
| 2 | from google.adk.agents import Agent |
导入 Agent 类 |
| 4-8 | Agent(...) |
创建智能体实例 |
| 5 | name="research_assistant" |
智能体名称 |
| 6 | model="gemini-2.0-flash-exp" |
使用 Gemini 模型 |
| 7 | instruction=... |
系统提示,指示智能体使用搜索工具 |
| 8 | tools=[google_search] |
核心:将 Google Search 注入为工具,智能体可自主决定何时调用 |
关键洞察:Google Search 本质上就是一种 RAG------用互联网作为知识库进行实时检索。这也是最简单的 RAG 实现:不需要自己建向量数据库,直接用搜索引擎。
5.2 示例二:Vertex AI RAG Corpus(ADK)
python
from google.adk.memory import VertexAiRagMemoryService
RAG_CORPUS_RESOURCE_NAME = "projects/your-gcp-project-id/locations/us-central1/ragCorpora/your-corpus-id"
SIMILARITY_TOP_K = 5
VECTOR_DISTANCE_THRESHOLD = 0.7
memory_service = VertexAiRagMemoryService(
rag_corpus=RAG_CORPUS_RESOURCE_NAME,
similarity_top_k=SIMILARITY_TOP_K,
vector_distance_threshold=VECTOR_DISTANCE_THRESHOLD
)
逐行解读:
| 行号 | 代码 | 说明 |
|---|---|---|
| 1 | from google.adk.memory import VertexAiRagMemoryService |
导入 Vertex AI RAG 记忆服务 |
| 3 | RAG_CORPUS_RESOURCE_NAME = ... |
指定 GCP 上的 RAG Corpus 资源路径 |
| 4 | SIMILARITY_TOP_K = 5 |
每次检索返回最相似的 5 个文档块 |
| 5 | VECTOR_DISTANCE_THRESHOLD = 0.7 |
语义距离阈值 0.7,低于此值的结果被过滤 |
| 7-10 | VertexAiRagMemoryService(...) |
创建 RAG 记忆服务实例 |
关键洞察:
TOP_K=5:检索的"召回数量",太多会引入噪声,太少可能遗漏关键信息DISTANCE_THRESHOLD=0.7:相关性"及格线",只返回语义距离足够近的结果- 这两个参数是 RAG 系统精调的关键旋钮
5.3 示例三:LangChain + LangGraph 完整 RAG 实现
步骤一:加载文档并分块
python
from langchain_community.document_loaders import TextLoader
from langchain.text_splitter import CharacterTextSplitter
# 下载文档
url = "https://github.com/langchain-ai/langchain/blob/master/docs/docs/how_to/state_of_the_union.txt"
res = requests.get(url)
with open("state_of_the_union.txt", "w") as f:
f.write(res.text)
# 加载文档
loader = TextLoader('./state_of_the_union.txt')
documents = loader.load()
# 分块:每块 500 字符,重叠 50 字符
text_splitter = CharacterTextSplitter(chunk_size=500, chunk_overlap=50)
chunks = text_splitter.split_documents(documents)
关键点 :chunk_overlap=50 确保相邻块之间有 50 字符的重叠,防止关键信息恰好被切断在两个块的边界。
步骤二:创建向量数据库
python
import weaviate
from weaviate.embedded import EmbeddedOptions
from langchain_community.embeddings import OpenAIEmbeddings
from langchain_community.vectorstores import Weaviate
# 初始化 Weaviate(嵌入式模式,无需额外服务)
client = weaviate.Client(embedded_options=EmbeddedOptions())
# 将文档块转为嵌入并存入 Weaviate
vectorstore = Weaviate.from_documents(
client=client,
documents=chunks, # 分块后的文档
embedding=OpenAIEmbeddings(), # 使用 OpenAI 的嵌入模型
by_text=False # 不用文本作为 ID,避免重复
)
# 创建检索器
retriever = vectorstore.as_retriever()
关键点:
EmbeddedOptions():嵌入式模式,开发测试用,无需部署独立的 Weaviate 服务OpenAIEmbeddings():调用 OpenAI API 将文本转为向量as_retriever():将向量数据库包装为检索器,方便后续调用
步骤三:定义 RAG 状态图
python
from typing import List, Dict, Any, TypedDict
from langchain_core.documents import Document
from langgraph.graph import StateGraph, END
# 定义状态结构
class RAGGraphState(TypedDict):
question: str # 用户问题
documents: List[Document] # 检索到的文档
generation: str # LLM 生成的回答
关键点:用 TypedDict 定义状态结构,LangGraph 的 StateGraph 会管理状态在节点之间的流转。
步骤四:定义检索节点
python
def retrieve_documents_node(state: RAGGraphState) -> RAGGraphState:
question = state["question"] # 取出用户问题
documents = retriever.invoke(question) # 用问题检索相关文档
return {
"documents": documents, # 检索到的文档
"question": question, # 原问题透传
"generation": "" # 清空生成结果
}
关键点:这是 RAG 流程的"检索"阶段------用语义搜索找到最相关的文档块。
步骤五:定义生成节点
python
def generate_response_node(state: RAGGraphState) -> RAGGraphState:
question = state["question"]
documents = state["documents"]
template = """You are an assistant for question-answering tasks.
Use the following pieces of retrieved context to answer the question.
If you don't know the answer, just say that you don't know.
Use three sentences maximum and keep the answer concise.
Question: {question}
Context: {context}
Answer:
"""
prompt = ChatPromptTemplate.from_template(template)
context = "\n\n".join([doc.page_content for doc in documents])
rag_chain = prompt | llm | StrOutputParser()
generation = rag_chain.invoke({"context": context, "question": question})
return {"question": question, "documents": documents, "generation": generation}
关键点:
- 模板明确指示 LLM:只用检索到的上下文回答,不知道就说不知道------这是减少幻觉的关键
context = "\n\n".join(...):将多个检索到的文档块拼接成上下文字符串prompt | llm | StrOutputParser():LCEL 链式调用------模板 → LLM → 解析输出
步骤六:组装工作流
python
workflow = StateGraph(RAGGraphState)
workflow.add_node("retrieve", retrieve_documents_node) # 添加检索节点
workflow.add_node("generate", generate_response_node) # 添加生成节点
workflow.set_entry_point("retrieve") # 入口:检索
workflow.add_edge("retrieve", "generate") # 检索 → 生成
workflow.add_edge("generate", END) # 生成 → 结束
app = workflow.compile() # 编译为可运行应用
完整流程图:
┌─────────────┐ ┌─────────────┐
│ retrieve │────→│ generate │────→ END
│ 检索文档块 │ │ LLM 生成答案 │
└─────────────┘ └─────────────┘
↑
用户问题
步骤七:执行查询
python
if __name__ == "__main__":
query = "What did the president say about Justice Breyer"
inputs = {"question": query}
for s in app.stream(inputs): # 流式执行
print(s)
关键点 :app.stream() 流式输出中间结果,可以看到检索和生成两个阶段的实时进展。
六、RAG 实际应用场景
| 场景 | 说明 | 核心价值 |
|---|---|---|
| 企业搜索与问答 | 内部聊天机器人检索 HR 政策、技术手册等 | 员工自助服务,减少重复咨询 |
| 客户支持与服务台 | 基于 FAQ、产品手册回答客户问题 | 精准一致答复,减少人工介入 |
| 个性化内容推荐 | 根据用户偏好语义检索相关内容 | 比关键词匹配更智能的推荐 |
| 新闻与时事摘要 | 集成实时新闻源,生成最新摘要 | 突破 LLM 知识截止限制 |
七、与前几章的联系
| 章节 | 与 RAG 的关系 |
|---|---|
| 第 5 章:工具使用 | RAG 的检索本质上是"工具调用"------调用搜索引擎或向量数据库作为工具 |
| 第 6 章:规划 | 智能体 RAG 的多步推理需要 Planning 能力来拆解复杂查询 |
| 第 7 章:多智能体协作 | 复杂 RAG 系统可以用多智能体分工:一个负责检索,一个负责验证,一个负责生成 |
| 第 8 章:记忆管理 | RAG 的向量数据库本质上就是智能体的"长期记忆",第 8 章介绍的语义搜索技术在这里被直接应用 |
| 第 4 章:反思 | 智能体 RAG 的来源验证和知识精炼,就是 Reflection 模式在检索场景的具体应用 |
整体脉络:前几章学的各种能力(工具调用、规划、反思、记忆)在 RAG 中汇聚------智能体 RAG 本质上是多种模式的组合应用。
八、关键要点总结
- RAG 的本质:让 LLM 从"闭卷推理"变为"开卷推理",通过检索外部知识增强生成质量
- 嵌入是基础:将文本转为向量,用数学距离衡量语义相似度
- 分块是关键:合理分块直接影响检索质量,chunk_size 和 chunk_overlap 是核心参数
- 向量数据库是引擎:支持高效语义检索的主流方案,Pinecone、Weaviate、Chroma DB 各有特色
- 混合检索是趋势:BM25 + 语义搜索,兼顾精确匹配和语义理解
- GraphRAG 解决关联问题:通过知识图谱理解实体关系,适合跨文档的复杂分析
- 智能体 RAG 是终极形态:引入推理层主动验证、调和冲突、拆解查询,但代价是复杂度和延迟
- RAG 不是银弹:信息碎片化、检索噪声、知识矛盾等挑战仍然存在
九、一图速览
┌──────────────────────────────────────────────────────────────┐
│ RAG 模式全景图 │
├──────────────────────────────────────────────────────────────┤
│ │
│ 用户提问 │
│ ↓ │
│ ┌──────────────────────────────────────────┐ │
│ │ 检索层 │ │
│ │ ┌─────────┐ ┌─────────┐ ┌─────────┐ │ │
│ │ │ 向量搜索 │ │ BM25 │ │ 知识图谱 │ │ │
│ │ │ (语义) │ │(关键词) │ │(关系) │ │ │
│ │ └────┬────┘ └────┬────┘ └────┬────┘ │ │
│ │ └──────────┬─┴──────────┘ │ │
│ │ 混合检索 │ │
│ └──────────────┬───────────────────────────┘ │
│ ↓ │
│ ┌──────────────────────────────────────────┐ │
│ │ 智能体推理层(可选) │ │
│ │ 验证来源 → 调和冲突 → 拆解查询 → 补全信息 │ │
│ └──────────────┬───────────────────────────┘ │
│ ↓ │
│ ┌──────────────────────────────────────────┐ │
│ │ 增强提示 + LLM 生成 │ │
│ │ 检索结果 + 用户问题 → 上下文增强 → 生成答案 │ │
│ └──────────────┬───────────────────────────┘ │
│ ↓ │
│ 准确、可验证、有引用的答案 │
│ │
└──────────────────────────────────────────────────────────────┘
十、参考文献
- Lewis, P., 等(2020)Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks - arxiv.org
- Google AI for Developers Documentation. Retrieval Augmented Generation Overview - cloud.google.com
- Retrieval-Augmented Generation with Graphs (GraphRAG) - arxiv.org
- LangChain 和 LangGraph:Leonie Monigatti, "Retrieval-Augmented Generation (RAG): From Theory to LangChain Implementation" - medium.com
- Google Cloud Vertex AI RAG Corpus - cloud.google.com