RAG 全景入门：从"为什么需要"到"未来往哪走"

本文是 AI Agent 系统性学习系列 Phase 2 的第 1 篇。在动手构建 RAG 管道之前，我们先建立全局视角：RAG 解决什么问题？经历了怎样的演进？核心组件如何协作？生态里有哪些工具可选？如何评估效果？未来又在往哪走？

本文不写代码，专注于建立直觉和全景认知。动手实践请看下一篇：从零构建 RAG 管道。

前置要求：了解 LLM 基本概念。

配套代码：phase-2-rag/

1. 从一个真实场景说起

想象你是一家公司的技术支持。客户问：”你们产品 v3.2 的新 API 怎么用？”你把问题丢给 ChatGPT，它自信地给了一个回答——但你一看就知道不对，因为 v3.2 上周才发布，ChatGPT 的训练数据根本没有这个版本的信息。

更糟糕的是，它不会说”我不知道”，而是编了一个看起来合理但完全错误的答案。

这个场景暴露了 LLM 的三个根本限制：

知识有截止日期。模型只知道训练数据里的内容。你的产品文档、内部 wiki、最新的行业报告——它一概不知。

不了解私有数据。你公司的代码库、客户数据、业务流程——这些从来没有出现在它的训练集里。

不确定时会编造答案。这就是”幻觉”（Hallucination）。在医疗、法律、金融这些需要准确性的场景，幻觉是致命的。

RAG 的核心思想用一句话就能说清：

不要让 LLM 凭记忆回答，先帮它找到相关资料，再让它基于资料回答。

就像开卷考试和闭卷考试的区别。RAG 把 LLM 从”闭卷”变成了”开卷”——给它一个可以随时查阅的知识库。

2. RAG 核心流程：拆解每一步到底在干什么

把 RAG 想象成给 LLM 配了一个图书管理员。你问问题，图书管理员先去书架上找到相关的书翻到对应页码，然后 LLM 基于这些页码内容来回答。

整个过程分两个阶段：

2.1 离线阶段：建索引

这个阶段的目标是把你的知识库变成一个”可以按语义搜索的数据库”。只需要做一次（数据更新时重新跑）。

第一步：文本提取与清洗。把 PDF、网页、Word 等格式转成纯文本。这一步看似简单，实际上坑很多——PDF 的表格会乱序，网页有导航栏和广告噪声，扫描件需要 OCR。清洗质量直接决定后续所有环节的上限。

第二步：切块（Chunking）。一本 500 页的技术手册不能整本塞给 LLM（上下文窗口放不下，也会稀释关键信息），需要切成几百个小段落。这里有个核心矛盾：

块太大 → 检索不精确，一个块里混了多个主题
块太小 → 丢失上下文，一句话脱离了前后文就没意义了
经验值：200-500 字符一个块，相邻块重叠 10-20%（防止关键信息被截断在边界）

第三步：Embedding（向量化）。这是 RAG 的核心魔法。Embedding 模型把每个文本块变成一个固定长度的数字数组（向量），比如 384 个浮点数。关键性质：语义相近的文本，向量在空间中的距离也近。

"什么是人工智能？"  →  [0.12, -0.34, 0.56, ..., 0.23]  (384个数字)
"AI 的定义是什么？"  →  [0.11, -0.33, 0.55, ..., 0.22]  ← 非常接近！
"今天天气怎么样？"  →  [0.78, 0.12, -0.45, ..., -0.67]  ← 差很远

第四步：存入向量数据库。把所有文本块的向量存进去，同时建立索引结构以支持快速检索。

2.2 在线阶段：查索引 + 生成

用户每次提问都会走这个流程：

第一步：问题向量化。用同一个 Embedding 模型把用户的问题也变成向量。

第二步：相似度检索。拿问题向量去向量数据库里找”距离最近”的 K 个文档块向量，返回对应的文本内容。这就是”语义搜索”——不是匹配关键词，而是匹配意思。

第三步：拼接 Prompt。把检索到的文档块和用户问题组装成一个 Prompt：

请基于以下参考文档回答用户的问题。如果文档中没有相关信息，请说明。

【参考文档】
文档1: RAG 是检索增强生成技术，通过检索外部知识来增强 LLM 的回答...
文档2: 向量数据库使用高维向量表示文本语义...
文档3: ...

【用户问题】
什么是 RAG？它和普通的 LLM 对话有什么区别？

第四步：LLM 生成回答。LLM 基于 Prompt 中的文档内容生成回答，而不是凭自己的”记忆”编造。

2.3 一个关键洞察

RAG 的质量取决于两件事——找得准（检索质量）和答得好（生成质量）。

找得准意味着：检索回来的文档确实和问题相关（精确度高），同时没有遗漏关键信息（召回率高）。答得好意味着：LLM 忠实地基于文档回答，不编造，不跑题。

后面的所有技术演进，都是围绕这两个维度展开的。

3. RAG 的演进：从 Naive 到 Agentic

RAG 不是一个静态的技术，而是一个不断演进的范式。从 2020 年 Lewis 等人提出 RAG 概念至今，它经历了四个阶段。

3.1 Naive RAG：能跑，但粗糙

最简单的 RAG 就三步：检索 → 拼接 → 生成。

用户问一个问题，系统去向量数据库里找最相似的几个文档块，把它们和问题一起塞进 Prompt，让 LLM 回答。

这个方案能跑，但问题不少：

问题	表现
检索精度低	找回来的文档不全是相关的，噪声多
召回不足	该找到的关键信息没找到
幻觉依旧	LLM 可能忽略检索到的内容，继续编造
复杂问题无力	需要多步推理的问题，一次检索不够

配套代码：01-basic-rag/04_naive_rag.py 实现了完整的 Naive RAG 管道。

3.2 Advanced RAG：每个环节都能优化

Advanced RAG 的思路是：既然管道有多个环节，那就逐个优化。

检索前优化（Pre-Retrieval）：

更好的分块策略：递归字符分块、Markdown 结构分块、语义分块
查询改写：用户的问题可能模糊或口语化，改写成更适合检索的形式
HyDE：让 LLM 先生成一个假设性答案，用答案去检索（答案的表述更接近文档）
多查询扩展：把一个问题改写成多个角度的查询，合并结果
Step-back Prompting：先问一个更抽象的问题获取背景知识

检索中优化（Retrieval）：

混合检索：BM25（关键词匹配）+ 向量检索（语义匹配），两者互补
元数据过滤：按时间、来源、类别等条件预筛选

检索后优化（Post-Retrieval）：

重排序（Reranking）：用 Cross-Encoder 对候选文档精细打分，把最相关的排到前面
信息压缩：去除冗余，只保留最关键的内容

这些技术在配套文章从零构建 RAG 管道中有完整的代码实现。

3.3 Modular RAG：像乐高一样组装

Modular RAG 打破了 Naive RAG 的固定流水线，把每个环节抽象为可替换的模块。

如果说 Naive RAG 是固定套餐，那 Modular RAG 就是自助餐——你可以根据场景自由组合：

搜索模块

：不只是向量检索，还可以接入搜索引擎、SQL 查询、知识图谱查询
记忆模块

：利用对话历史和用户画像来优化检索
路由模块

：根据问题类型自动选择不同的检索策略
验证模块

：检查检索到的文档是否真的和问题相关，过滤掉噪声
额外生成模块

：当检索结果不够时，让 LLM 先生成补充上下文

模块之间的编排也不再是固定的线性流程。比如 Rewrite-Retrieve-Read 模式先改写查询再检索，ITER-RETGEN 模式在检索和生成之间迭代循环，Self-RAG 模式让模型自己判断是否需要检索。

3.4 Agentic RAG：RAG 遇上 Agent

这是 RAG 演进的最新方向。核心变化是：不再由固定流程决定何时检索、检索什么，而是由 Agent 自主判断。

一个 Agentic RAG 系统可以：

判断问题是否需要检索（简单问题直接回答）
评估检索结果的质量（不够好就换个策略重新检索）
多轮迭代检索（复杂问题分步骤，每步检索不同的信息）
跨知识库整合（同时查产品文档、技术博客、内部 wiki）

如果你完成了 Phase 1 的 Agent 学习，会发现 Agentic RAG 就是把 RAG 作为 Agent 的一个工具——Agent 决定何时用、怎么用。

配套代码 03-memory-rag/12_memory_enhanced_rag.py 实现了 Memory-Enhanced RAG，这是 Agentic RAG 的雏形。

3.5 演进总结

阶段	核心特征	类比
Naive RAG	检索-拼接-生成	去图书馆借书，拿到什么看什么
Advanced RAG	每个环节精细优化	有经验的研究员，知道怎么找、怎么筛
Modular RAG	模块化、可编排	自助餐，按需组合
Agentic RAG	Agent 自主编排	有自主判断力的研究助理

4. 核心组件详解

4.1 文档处理：垃圾进，垃圾出

RAG 的质量上限由数据质量决定。文档处理包括两步：加载和分块。

加载：支持多种格式——PDF（pypdf、pdfplumber）、网页（BeautifulSoup）、Markdown、Word 等。关键是文本清洗：去除页眉页脚、多余空行、控制字符等噪声。

分块：把长文档切成适合检索的小段。四种主流策略：

策略	原理	适用场景
固定大小	按字符数硬切	快速原型
递归字符	先按段落切，再按句子切	通用文档（推荐）
结构感知	按标题层级切，保留文档结构	技术文档、Markdown
语义分块	用 Embedding 判断语义断裂点	高质量 RAG

经验值：chunk_size 200-500 字符，overlap 10-20%。

4.2 Embedding：把文本变成可以计算的数字

Embedding 是 RAG 的核心魔法，值得多花点篇幅理解。

本质：Embedding 模型是一个经过大量文本训练的神经网络，它学会了把文本映射到一个高维向量空间。在这个空间里，语义相近的文本距离近，语义不同的文本距离远。

你可以把它理解为给文字算”GPS 坐标”。现实世界中，北京和天津的 GPS 坐标很接近（因为地理位置近），北京和纽约的坐标差很远。Embedding 做的是同样的事，只不过是在”语义空间”里——”机器学习”和”深度学习”的坐标接近，”机器学习”和”烹饪技巧”的坐标差很远。

维度：一个 384 维的 Embedding 意味着每段文本被表示为 384 个浮点数。维度越高，能表达的语义细节越丰富，但计算和存储成本也越高。常见维度：384（轻量）、512、768、1024、1536（OpenAI）。

距离度量：两个向量有多”像”，用数学距离来衡量：

度量方式	原理	特点
余弦相似度	衡量两个向量方向的夹角	最常用，不受向量长度影响
欧氏距离	衡量两个向量端点的直线距离	直观，但受向量长度影响
点积	两个向量对应元素相乘再求和	计算快，归一化后等价于余弦相似度

余弦相似度范围是 [-1, 1]，1 表示完全相同，0 表示无关，-1 表示完全相反。RAG 中最常用余弦相似度。

Embedding 模型怎么选：

类别	模型	维度	特点
开源轻量	all-MiniLM-L6-v2	384	英文为主，速度快，适合学习入门
中文推荐	BAAI/bge-small-zh-v1.5	512	中文效果好，国内团队维护
商业 API	OpenAI text-embedding-3-small	1536	多语言，效果强，按调用付费
开源强力	BAAI/bge-m3	1024	多语言、多粒度，支持稀疏+稠密混合

选型建议：学习阶段用开源模型（免费、本地运行、不依赖网络），生产环境根据语言和精度需求选择。中文场景优先考虑 BGE 系列。

4.3 向量数据库：语义搜索是怎么做到快的

向量数据库的核心任务：存储百万甚至十亿级别的向量，当给定一个查询向量时，快速找到最相似的 K 个向量。

暴力搜索的问题：最直接的方法是拿查询向量和数据库里每一个向量都算一次距离，取最近的 K 个。100 万个 384 维向量，每次查询要做 100 万次距离计算——太慢了。

近似最近邻（ANN）算法：向量数据库的核心技术。牺牲一点点精度，换取几个数量级的速度提升。主流算法：

HNSW（Hierarchical Navigable Small World）：目前最主流的 ANN 算法。原理类似”六度分隔理论”——构建一个多层图结构，每个向量是一个节点，和它相近的向量之间有边相连。搜索时从顶层开始，逐层向下”跳跃”，快速逼近目标区域。

搜索过程（类比）：
  你要在北京找一家特定的咖啡店
  第1层（全国）：先定位到北京市
  第2层（城市）：再定位到朝阳区
  第3层（区域）：再定位到三里屯
  第4层（街道）：找到那家店

  不需要遍历全国所有咖啡店，几步就到了。

IVF（Inverted File Index）：先把向量空间划分成若干个区域（聚类），查询时只在最近的几个区域内搜索。类似于”先确定在哪个书架，再在书架上找书”。

PQ（Product Quantization）：把高维向量压缩成更短的编码，减少存储和计算开销。适合超大规模数据集。

向量数据库选型：

类别	工具	索引算法	特点
轻量级	ChromaDB	HNSW	零配置，内置 Embedding，适合学习
轻量级	FAISS	IVF/PQ/HNSW	Meta 开源，纯向量检索，速度极快
生产级	Milvus	IVF/HNSW/DiskANN	开源，支持十亿级向量，分布式
生产级	Qdrant	HNSW	Rust 实现，性能好，支持过滤
托管服务	Pinecone	专有	全托管，零运维，按用量付费
传统扩展	pgvector	IVFFlat/HNSW	PostgreSQL 插件，适合已有 PG 的团队

学习阶段用 ChromaDB 就够了——它内置 Embedding 功能，几行代码就能跑起来，不需要单独部署。

4.4 检索策略：精确率和召回率的平衡

检索是 RAG 中最关键的环节。理解检索，需要先理解两个核心指标：

精确率（Precision）：检索回来的文档中，有多少是真正相关的？精确率低意味着噪声多——找回来 10 个文档，只有 3 个有用，其余 7 个是干扰。

召回率（Recall）：所有相关的文档中，有多少被检索到了？召回率低意味着遗漏——知识库里有 5 个相关文档，你只找到了 2 个，漏掉了关键信息。

知识库中有 5 个相关文档（A B C D E），检索返回了 8 个文档

返回结果：[A, B, X, Y, C, Z, W, V]
                ↑  ↑        ↑
              相关 相关     相关

精确率 = 3/8 = 37.5%  （8个里只有3个相关）
召回率 = 3/5 = 60%    （5个相关的只找到了3个）

理想情况是两者都高，但实际中往往需要权衡：返回更多结果可以提高召回率，但会降低精确率。

三种检索方式：

稀疏检索（BM25）：基于关键词匹配的经典算法。核心思想：一个词在文档中出现越多（词频 TF），在所有文档中出现越少（逆文档频率 IDF），这个词对该文档的重要性就越高。

擅长：精确匹配专有名词、代码、型号等（搜”Python 3.12″就是要包含这个关键词的文档）
弱点：无法理解语义（搜”如何让搜索更准”，找不到写着”检索精度优化”的文档）

稠密检索（向量检索）：用 Embedding 模型把查询和文档都变成向量，按余弦相似度排序。

擅长：语义匹配（搜”如何让搜索更准”能找到”检索精度优化”）
弱点：可能忽略关键词精确匹配（搜”BM25 算法”，可能返回讲”TF-IDF”的文档而不是直接提到 BM25 的）

混合检索（Hybrid Search）：两者结合，用 RRF（Reciprocal Rank Fusion）融合排名。RRF 的巧妙之处在于只用排名，不用分数——不需要对 BM25 和向量检索的分数做归一化。

RRF 融合示例：
  BM25 排名：  [文档A(第1), 文档C(第2), 文档B(第3)]
  向量排名：  [文档B(第1), 文档A(第2), 文档D(第3)]

  RRF 分数 = Σ 1/(k + rank)，k=60

  文档A: 1/(60+1) + 1/(60+2) = 0.0164 + 0.0161 = 0.0325  ← 最高
  文档B: 1/(60+3) + 1/(60+1) = 0.0159 + 0.0164 = 0.0323
  文档C: 1/(60+2) + 0         = 0.0161
  文档D: 0         + 1/(60+3) = 0.0159

  最终排序：A > B > C > D

两阶段检索架构：生产环境的标准做法。

粗检索（Bi-Encoder）

：查询和文档分别编码为向量，文档向量可以预计算并缓存，速度极快
精排（Cross-Encoder）

：把查询和文档拼接后一起输入模型，直接输出相关性分数。能捕获查询-文档间的细粒度交互，精度远高于 Bi-Encoder，但每个查询-文档对都要重新计算，所以只能对少量候选使用

4.5 生成策略：答得好同样重要

检索到了好的文档，还需要 LLM 正确使用它们。这一步的核心挑战是：LLM 可能忽略你给它的文档，继续用自己的”记忆”编造答案。

Prompt 设计要点：

明确角色和约束

：告诉 LLM “你是一个基于文档回答问题的助手，只能使用提供的参考文档来回答”
要求引用来源

：让 LLM 标注答案来自哪个文档，方便用户验证
处理信息不足

：明确指示”如果文档中没有相关信息，请直接说明，不要猜测”
控制输出格式

：根据场景要求结构化输出（列表、表格、分步骤等）

常见问题和对策：

问题	表现	对策
幻觉	LLM 编造文档中不存在的信息	在 Prompt 中强调”只基于文档回答”
信息丢失	检索到了但 LLM 没用上	减少检索文档数量，突出关键内容
冗余重复	多个文档说了类似的话，回答啰嗦	检索后去重或压缩
上下文过长	塞了太多文档，LLM 反而找不到重点	控制 Top-K 数量，用重排序筛选

一个实用的经验：检索 3-5 个高质量文档块比检索 20 个效果更好。LLM 处理长上下文时存在”中间迷失”现象——开头和结尾的信息被关注，中间的容易被忽略。

5. 技术生态一览

5.1 端到端框架

框架	特点	适用场景
LangChain	生态最大，组件丰富	快速原型，通用场景
LlamaIndex	专注数据索引和检索	数据密集型应用
Haystack	模块化设计，企业级	生产部署
RAGFlow	开源 RAG 引擎，中文友好	中文场景，可视化编排

5.2 关键组件工具

文档解析

：Unstructured、LlamaParse、pdfplumber
Embedding

：sentence-transformers、FlagEmbedding（BGE 系列）
向量数据库

：ChromaDB、Milvus、Qdrant、Pinecone、pgvector
评估

：RAGAS、TruLens、Phoenix

5.3 选型建议

学习阶段：Python + ChromaDB + sentence-transformers。这也是本系列配套代码的方案——零成本、本地运行、足够理解原理。

快速原型：LangChain 或 LlamaIndex，几十行代码搭出完整管道。

生产部署：根据数据规模、延迟要求、团队技术栈选择。Milvus 适合大规模，Qdrant 适合中等规模，pgvector 适合已有 PostgreSQL 的团队。

核心原则：先理解原理，再用框架。框架会变，原理不变。

6. 如何评估 RAG 系统

6.1 为什么评估很重要

“看起来回答得不错”不是评估标准。你需要量化指标来：

对比不同配置的效果（分块大小、检索策略、模型选择）
发现系统的薄弱环节（是检索不准还是生成有问题？）
持续监控线上质量

6.2 核心评估维度

RAG 的评估围绕三个核心指标展开（RAGAS 框架和 OpenAI 的报告都强调了这三个）：

指标	衡量什么	低分意味着
Faithfulness（忠实度）	回答是否基于检索到的文档	存在幻觉，LLM 在编造
Answer Relevancy（答案相关性）	回答是否切题	回答跑题了
Context Relevancy（上下文相关性）	检索到的文档是否和问题相关	检索噪声大，找的不准

补充指标：Context Recall（上下文召回率）衡量是否检索到了所有需要的信息，Context Precision（上下文精确度）衡量检索结果中相关文档的比例。

6.3 评估驱动优化

评估不是目的，优化才是。每个指标低分都指向不同的优化方向：

指标低	优化方向
Faithfulness	改进 Prompt，强调”只基于文档回答”
Answer Relevancy	改进 Prompt 模板，优化回答格式
Context Precision	加入重排序，改进分块策略
Context Recall	改进检索策略（混合检索、查询改写）

配套代码 02-advanced-rag/08_ragas_evaluation.py 实现了完整的 RAGAS 评估流程。

7. 趋势与未来方向

7.1 多模态 RAG

RAG 不再局限于文本。最新的研究和产品已经支持检索图片、表格、音频甚至视频。比如你可以上传一份包含图表的 PDF，RAG 系统不仅理解文字，还能理解图表中的数据。

7.2 Graph RAG

传统 RAG 检索的是独立的文档块，但很多知识是有关联的。Graph RAG 用知识图谱来组织信息，支持多跳推理。比如”A 公司的 CEO 毕业于哪所大学”需要先找到 CEO 是谁，再找到他的教育背景——这需要图结构的关联检索。

7.3 长上下文 vs RAG

随着 LLM 上下文窗口越来越大（Gemini 已经支持百万 token），有人问：还需要 RAG 吗？

答案是：两者互补，不是替代。长上下文有”大海捞针”问题——把太多信息塞进去，模型反而找不到关键内容。RAG 更经济（只检索需要的部分），更可控（知道答案来自哪个文档），也更容易更新（换文档就行，不用重新训练）。

实践中，最好的方案往往是结合使用：RAG 负责从海量数据中筛选，长上下文负责处理筛选后的内容。

7.4 RAG + Fine-tuning

RAG 和微调不是二选一，而是互补关系：

Fine-tuning

教模型”怎么回答”——回答的风格、格式、领域术语
RAG

提供”回答什么”——最新的、准确的事实信息

结合使用时，微调后的模型能更好地理解和利用 RAG 检索到的文档。

7.5 Agentic RAG 的深化

Agentic RAG 是当前最活跃的研究方向。核心趋势包括：

自适应检索

：模型自己判断何时需要检索，避免不必要的检索开销
多轮迭代

：复杂问题通过多轮检索-推理逐步逼近答案
工具集成

：RAG 不再是唯一的信息来源，Agent 可以同时调用搜索引擎、数据库、API 等多种工具

8. 入门必备：你需要掌握什么

读完前面的内容，你可能觉得 RAG 涉及的东西很多。别慌，入门其实只需要掌握以下核心知识点。按优先级排列：

第一层：必须理解的概念

Embedding 是什么

：文本 → 向量，语义相近 → 向量距离近
余弦相似度

：两个向量方向越接近，相似度越高（范围 -1 到 1）
向量数据库的作用

：存储向量 + 快速找到最相似的 K 个
RAG 两阶段流程

：离线建索引（切块→向量化→存储）+ 在线查索引（问题向量化→检索→生成）
精确率 vs 召回率

：找得准 vs 找得全，两者需要平衡

第二层：必须会用的工具

一个 Embedding 模型

：推荐 sentence-transformers 的 all-MiniLM-L6-v2（英文）或 bge-small-zh-v1.5（中文）
一个向量数据库

：推荐 ChromaDB，零配置，pip install chromadb 即可
一个 LLM API

：OpenAI、DeepSeek、Anthropic 任选一个
文本分块工具

：推荐 LangChain 的 RecursiveCharacterTextSplitter

第三层：必须动手做的实验

实现一个 Naive RAG

：加载文档 → 分块 → 存入 ChromaDB → 检索 → 拼 Prompt → LLM 回答
对比不同 chunk_size 的效果

：200 vs 500 vs 1000，观察检索质量变化
对比 BM25 和向量检索

：同一个问题，两种方式各找到了什么？有什么互补？
观察幻觉现象

：故意问一个文档里没有的问题，看 LLM 是否会编造

第四层：进阶提升

实现混合检索（BM25 + 向量 + RRF 融合）
加入 Cross-Encoder 重排序
尝试查询改写（HyDE、多查询扩展）
用 RAGAS 评估你的 RAG 系统

以上所有实验在配套代码 phase-2-rag/ 中都有完整实现，可以直接运行。

9. 学习路径与资源推荐

9.1 推荐学习路径

9.2 推荐资源

论文：

Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks（Lewis et al., 2020）—— RAG 的开山之作
Retrieval-Augmented Generation for Large Language Models: A Survey（Gao et al., 2024）—— 最全面的 RAG 综述

教程与文档：

LangChain RAG Tutorial —— 官方中文教程
LlamaIndex 官方文档 —— 数据索引框架
RAGAS 文档 —— RAG 评估框架
Pinecone Learning Center —— 向量数据库和 RAG 最佳实践

中文资源：

本系列配套代码：phase-2-rag/ —— 13 个 Python 实现，从基础到高级
A Practical Guide to RAG in 2026 —— RAG 技术对比实践指南
RAG 全类型概览 —— 14 种 RAG 类型详解

10. 总结

RAG 的本质是一个简单的想法：让 LLM 在回答之前先查资料。但围绕这个想法，已经发展出一个庞大的技术体系。

RAG 全景
├── 为什么需要：知识截止、私有数据、幻觉问题
├── 核心流程：离线建索引 + 在线查索引
├── 演进路径：Naive → Advanced → Modular → Agentic
├── 核心组件
│   ├── 文档处理（加载、清洗、分块）
│   ├── Embedding（文本 → 向量）
│   ├── 向量数据库（语义检索）
│   ├── 检索策略（稀疏 + 稠密 + 重排序）
│   └── 生成策略（Prompt 工程）
├── 评估体系：Faithfulness / Relevancy / Context Quality
└── 未来方向：多模态、Graph RAG、Agentic RAG

理解了全景，接下来就是动手。下一篇从零构建 RAG 管道会带你用 Python 实现上面提到的每一个组件。

RAG 全景入门：从”为什么需要”到”未来往哪走”