RAG技术完全指南——从小白到进阶

RAG技术完全指南——从小白到进阶
君逝生0. 阅读导引 (๑•̀ㅂ•́)و✧
嗨~欢迎来到 RAG 的奇妙世界!这篇文章是写给所有对 AI 应用开发感兴趣的朋友的。无论你是:
- 刚听说”大模型”想了解怎么用它做知识库的 纯小白 🐣
- 写过几个 RAG Demo 但总觉得”还不够好用”的 进阶选手 💪
- 想知道 2025-2026 年 RAG 领域最新进展的 前沿追踪者 🔭
这篇文章都会给你满满的干货!(保证不水字数,每一节你都能用上)
读完你会获得什么?
- 理解 RAG 为什么诞生,解决了什么问题
- 掌握从数据清洗到检索生成的全链路技术细节
- 了解 GraphRAG、Agentic RAG、Self-RAG 等 2025 年前沿方案
- 能用代码实现一个生产级的 RAG 系统
本文约 2 万字,建议收藏后慢慢啃 (。・ω・。)
1. 故事从 GPT 说起——RAG 为什么要存在? 🤔
1.1 大模型的”知识诅咒”
2022 年 11 月 ChatGPT 横空出世,全世界都被它的能力震惊了。但很快,人们发现了几个让人头疼的问题:
问题一:它在胡说八道 (Hallucination / 幻觉)
1 | 用户:请介绍一下 OpenPipe 这个公司。 |
因为训练数据里没有 OpenPipe 的信息,模型就”脑补”了一个答案——还不是低调地脑补,而是带着 100% 的自信说出来 (╯°□°)╯︵ ┻━┻
问题二:它的知识有时效性
1 | 用户:最新的 iPhone 是哪款? |
模型的”知识”冻结在训练结束的那一天。之后发生的一切——新论文、新产品、新政策——它一概不知。
问题三:它不了解你的私有数据
1 | 用户:我们公司内部的项目 X 目前进度如何? |
公司内部的文档、数据库、Wiki——这些才是日常工作中最需要 AI 辅助的地方,但大模型天然看不到这些数据。
1.2 三种”土办法”的尝试与失败
人们一开始想了几招来让模型”知道更多”:
| 方法 | 核心思路 | 致命问题 |
|---|---|---|
| 🗣️ 全量 Prompt 注入 | 每次提问时把所有相关文档塞进 Prompt | Token 上限+成本爆炸(一次查询可能烧掉 $0.5) |
| 🧠 微调 (Fine-tuning) | 用新数据重新训练模型 | 训练成本高、无法增量更新、容易”灾难性遗忘” |
| 📚 全量数据训练 | 从零训练专属大模型 | 百万美元起步、需要海量 GPU、非大厂不可为 |
1.3 RAG 的核心理念:检索 + 生成 = 最佳拍档
2020 年,Meta(当时还叫 Facebook AI)的论文 Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks 提出了一个后来改变了整个 AI 应用范式的架构——RAG。
核心思想其实特别简单:
%%{init: {'theme': 'base'}}%%
flowchart LR
A["📚 知识库<br/>(文档/DB)"] --> B["🔍 向量检索<br/>(找到相关内容)"]
B --> C["📋 相关知识块"]
C --> D["📝 增强 Prompt<br/>(问题+上下文)"]
D --> E["🤖 LLM<br/>生成回答"]
F["🙋 用户提问"] --> B
用人话解释就是:
别让模型背答案,给它一个”开卷考试”的环境 📖
每次用户提问时,系统先去知识库里”翻书”找到相关内容,然后把问题和参考资料一起交给 LLM,让它”参考这些材料来回答”。
这样做的三大好处:
- 解决幻觉:模型有据可依,不再凭空捏造(至少大幅减少)
- 解决时效性:知识库随时更新,不需要重新训练模型
- 解决私域数据:你的文档、数据库、API 都可以作为知识源
2025 年 RAG 已经成了几乎所有 AI 应用的标配架构。 从 GitHub Copilot 的代码检索、到 Notion AI 的文档问答、到 Perplexity 的联网搜索增强——底层都是 RAG 的变体。
2. RAG 的核心四大件 🔧
如果把 RAG 比作一辆车,它有四个核心部件:
%%{init: {'theme': 'base'}}%%
flowchart TD
A["① 数据预处理<br/>(Ingestion)<br/>文档切块 & 清洗"] --> B["② 向量化与存储<br/>(Embedding)<br/>文本 → 高维向量"]
B --> C["③ 检索<br/>(Retrieval)<br/>混合检索 + 精排"]
C --> D["④ 生成<br/>(Generation)<br/>LLM 基于上下文回答"]
咱们一个一个解剖 (๑•̀ω•́)ノ🔪
2.1 数据预处理——“把书拆成卡片” 📇
在 RAG 中,”知识”存储在知识库里。但你不能把一本 500 页的书直接丢给检索系统——那样什么都搜不出来。你需要切块(Chunking)。
2.1.1 为什么需要切块?
- 向量模型(Embedding Model)有输入长度限制(通常是 512 或 1024 tokens)
- 太长的文本会被截断,丢失语义
- 太短的文本缺乏上下文,检索精度下降
- 检索时你希望返回的块”恰好”包含答案,不多不少
2.1.2 切块策略全家福
%%{init: {'theme': 'base'}}%%
flowchart LR
A["① 固定分块<br/>Fixed-size<br/><br/>⚡ 最简单"] --> B["② 句子分块<br/>Sentence-based<br/><br/>按句号/换行切"]
B --> C["③ 递归分块<br/>Recursive<br/><br/>层层缩小切分粒度"]
C --> D["④ 语义分块<br/>Semantic<br/><br/>✨ 按相似度切"]
D --> E["⑤ Agentic<br/>Chunking<br/><br/>🤖 LLM 自主判断"]
① 固定大小分块(Fixed-size Chunking)
最简单粗暴的方式。设定一个 chunk_size(如 500 tokens),从头到尾均匀切割。
1 | # 最基础的固定分块(使用 LangChain) |
优点:简单、快、不需要模型
缺点:经常在句子中间切断,有些块完全没有语义价值
⚠️ overlap 的重要性:假设你的文档里有一段:
1 | ...根据量子力学原理,薛定谔方程描述了量子态的演化... |
如果不设 overlap,可能变成:
- Chunk 42:
...根据量子力学原理,薛定谔方程← 不完整! - Chunk 43:
描述了量子态的演化...← 缺主语!
设了 overlap(比如 50 tokens)后:
- Chunk 42:
...根据量子力学原理,薛定谔方程 - Chunk 43:
...薛定谔方程描述了量子态的演化...← cover 了整个句子 (ง •̀_•́)ง
② 递归分块(Recursive Chunking)
先在”大边界”上切(如段落 \n\n),如果块太长再在”小边界”上切(如句子 。),层层递归。
1 | from langchain.text_splitter import RecursiveCharacterTextSplitter |
这是目前最常用的切块方式,在成本和效果之间取得了很好的平衡。
③ 句子分块(Sentence-based Chunking)
按句子边界切分,每个 chunk 包含 N 个完整句子。保证每块都是完整的语义单元。
1 | import spacy |
④ 语义分块(Semantic Chunking)✨ 2025 前沿!
这也是2024-2025 年最热门的 chunking 趋势——让模型自己判断”哪里该切”。
工作原理:
- 遍历文档中的每个句子
- 计算相邻句子的 Embedding 相似度
- 当相似度降到阈值以下 → 此处切开(话题转换点)
- 每个 chunk 内部保持语义连贯
1 | # langchain 的 SemanticChunker |
2025 年新进展:
- Agentic Chunking:用一个轻量 LLM 遍历文档,每读一段就决定”这里该不该切”,比固定阈值更灵活
- Chunk Linking:切块后不只存单独的块,还存块与块之间的”前一页/后一页”关系,让 LLM 可以在回答时”翻页”
⑤ 小文档策略(Small-to-Big)✨ 更高级
不是把所有文档都切成小块。而是:
- 检索时用小 chunk(精准匹配)
- 喂给 LLM 时用大 chunk 或完整段落(提供充足上下文)
实现方式有:
- 父文档检索器(Parent Document Retriever):检索小 chunk,返回它所属的整个文档
- 句子窗口检索(Sentence Window Retrieval):检索命中句子,返回前后各 K 句
1 | # LlamaIndex 的 SentenceWindowNodeParser |
2.1.3 处理特殊格式 ⚡
现实世界的数据远比纯文本复杂:
| 格式 | 关键挑战 | 解决方案 |
|---|---|---|
| 表格、图片、两栏排版 | LlamaParse / Marker / Docling 做结构化解析 | |
| 🌐 网页 | 导航栏、广告、评论噪音 | readability 算法提取正文 + CSS selector |
| 💻 代码 | 函数调用关系跨越多个文件 | AST(抽象语法树)分块 + 依赖图 |
| 📋 表格 | 每个单元格单独看都没意义 | 转 Markdown 表格 + 表头重复策略 |
| 🏢 企业文档 | PPT、Excel、Confluence、飞书 | Unstructured.io (支持 20+ 格式) |
2.1.4 Document Cleaning 也别忽略! 🧹
脏数据 = 坏检索。你应该至少做:
1 | import re |
2.2 向量化——“让机器能’看懂’文字” 🔢
把文本切成块后,下一步是把它变成计算机可以”比较相似度”的形式——向量(Vector / Embedding)。
2.2.1 向量和 Embedding 到底是什么?
想象一个三维空间:
- 🍎 “苹果”在 (0.8, 0.1, 0.3)
- 🍌 “香蕉”在 (0.7, 0.2, 0.4) ← 离苹果很近
- 🚗 “汽车”在 (-0.5, 0.8, 0.6) ← 离苹果很远
一个好的 Embedding 模型做的事情就是:把语义相似的文字,映射到相近的向量位置上。
真实世界使用的向量不是 3 维,而是 768、1024 甚至 4096 维——维度越高,能编码的语义信息越丰富。
2.2.2 如何选 Embedding 模型?
截至 2025 年中,主流选择(按场景):
| 模型 | 维度 | 最大 Tokens | 适用场景 | 语言 |
|---|---|---|---|---|
| BGE-M3 (BAAI) | 1024 | 8192 | 通用中文/多语言 | 中英+100+语言 |
| GTE-Qwen2-7B | 3584 | 32768 | 长文档+中文旗舰 | 中英文 |
| Jina Embeddings v3 | 1024 | 8192 | 多语言+任务特定 LoRA | 89种语言 |
| Cohere Embed v3 | 1024 | 512 | 英文商业应用 | 英文 |
| text-embedding-3-large (OpenAI) | 3072/256/1024 | 8191 | 灵活维度+高精度 | 50+语言 |
| NV-Embed-v2 (NVIDIA) | 4096 | 4096 | MTEB 榜首 2025 | 英文 |
🏆 2025 年 MTEB 榜单(海量文本 Embedding 基准测试)前三名:
- NV-Embed-v2(NVIDIA)— 2025.02 发布
- GTE-Qwen2-7B-instruct — 阿里出品,中文最强
- SFR-Embedding-2-R(Salesforce)
2.2.3 动手实践:给文档生成向量
1 | # 使用 BGE-M3 给中文文档生成 Embedding |
2.2.4 Dense vs Sparse Embedding——两种”找相似”的哲学 🧘
1 | Dense Embedding(稠密向量) Sparse Embedding(稀疏向量) |
2025 年的趋势:混合使用!Dense 捕获语义+ Sparse 精确匹配 = 天作之合(见 2.3 节)
2.3 检索——“大海捞针的艺术” 🎣
向量化之后,你把所有文档块的向量存到了向量数据库里。现在用户来了一个问题,你怎么找到最相关的内容?
2.3.1 基础向量检索:KNN 与 ANN
暴力最近邻(KNN):拿问题的向量跟库里的 N 个向量逐一算距离 → 太慢了,百万级数据要几分钟。
近似最近邻(ANN):牺牲一点点精度,换回百倍速度。主流算法:
| 算法 | 原理 | 代表实现 | 适用场景 |
|---|---|---|---|
| HNSW | 多层跳表图 | Qdrant, Weaviate, pgvector | 高召回率要求 |
| IVF (倒排索引) | 先聚类再搜索 | Faiss, Milvus | 千万级以上数据 |
| DiskANN | 磁盘上的图索引 | Microsoft DiskANN, LanceDB | 内存有限的大数据量 |
| PQ (乘积量化) | 向量压缩 | 配合 IVF/HNSW 使用 | 内存压缩 10-30x |
2.3.2 混合检索(Hybrid Search)—— 2025 年的标配 ⊹⋛
纯向量检索的问题:
1 | 用户问题:"CPU 怎么超频?" |
混合检索 = 向量检索 + 关键词检索 → 合并排序
1 | # 混合检索示例(使用 RRF: Reciprocal Rank Fusion) |
2.3.3 Reranker(重排序)——检索的最后一道关口 🎯
即使混合检索的结果,通常第一条也不一定是”最有用”的。你需要一个 Reranker 做”精排”。
原理:检索阶段粗筛 50-100 条 → Reranker 用更强的模型逐条打分 → 只保留 Top 5-10
1 | # 使用 BGE-Reranker-v2 进行精排 |
2025 年 Reranker 选型指南:
| Reranker | 规模 | 特点 |
|---|---|---|
| BGE-Reranker-v2-m3 | 0.5B | 多语言,性价比之王 |
| Cohere Rerank v3 | API | 商业最稳,多语言 |
| Jina Reranker v2 | 0.3B | 超快,多语言 |
| gte-Qwen2-7B-instruct | 7B | 精度第一,中文特化 |
2.3.4 查询重写(Query Rewriting)——让你的问题更”聪明” 💡
用户提出的问题往往很随意。直接检索效果时好时坏。
1 | # 示例:多轮对话中的查询重写 |
常见的查询优化技术:
| 技术 | 做法 | 效果 |
|---|---|---|
| HyDE | 先用 LLM 生成一个”假设答案”,用假设答案做向量检索 | 大幅提升长问题的召回率 |
| Multi-Query | 从一个问题生成 3-5 个变体,并行检索取并集 | 提高召回覆盖度 |
| Query Decomposition | 复杂问题拆成子问题,逐步检索 | 适合多跳推理 |
| Step-back Prompting | 先生成高层次的”背景问题”,再结合原始问题 | 提升抽象问题检索质量 |
| Self-Query | 让 LLM 从问题中抽取元数据过滤条件 | “2024年的AI论文”→ year=2024 |
2.3.5 Multi-hop Retrieval(多跳检索)🔗
有些问题需要”先搜 A,再从 A 的结果里搜 B”:
1 | 问题:"马斯克创办的第一家AI公司的现任CEO是谁?" |
1 | # 多跳检索的简化实现 |
2.4 生成——“最后一步:写出漂亮答案” ✍️
检索到相关知识后,最后一步是把”问题 + 检索到的上下文”拼成一个 Prompt,交给 LLM 生成答案。
2.4.1 Prompt 模板设计
一个标准的 RAG Prompt 模板:
1 | 基于以下参考资料,回答用户的问题。 |
2.4.2 上下文预算管理 ⚖️
2025 年的模型上下文窗口虽然很大(Gemini 2.5 Pro 支持 1M tokens!),但你不可能无限制塞文档——
- 💰 成本:每 1000 tokens 都要钱
- ⏱️ 速度:Prompt 越长、生成越慢
- 🧠 注意力稀释:”大海捞针”测试显示,Prompt 太长时模型容易”忽略”中间内容
1 | def allocate_context_budget( |
2.4.3 引用(Citation)机制
没有引用的 RAG = 新版胡说八道 (눈_눈)
1 | def format_with_citation(docs: list, answer: str) -> str: |
3. 进阶 RAG:2024-2025 前沿方案 🚀
基础 RAG(Naive RAG)虽然能用,但在实际生产中有很多短板。业界在近几年发展出了成熟的进阶 RAG方案。
3.1 Advanced RAG——给基础 RAG 加”配件” 🧩
%%{init: {'theme': 'base'}}%%
flowchart LR
subgraph 基础RAG
A1["🙋 User Query"] --> A2["🔍 检索"]
A2 --> A3["📋 返回 Top-K"]
A3 --> A4["📝 拼到 Prompt"]
A4 --> A5["🤖 LLM 生成"]
end
subgraph 进阶RAG
B1["🙋 User Query"] --> B2["✏️ 查询重写/拆分"]
B2 --> B3["🔀 混合检索<br/>(BM25 + 向量)"]
B3 --> B4["🎯 Reranker 精排"]
B4 --> B5["⚖️ 上下文压缩/预算"]
B5 --> B6["🤖 LLM 生成 + 引用"]
end
style B2 fill:#e1f5fe,stroke:#0288d1
style B3 fill:#e8f5e9,stroke:#388e3c
style B4 fill:#e1f5fe,stroke:#0288d1
style B5 fill:#e1f5fe,stroke:#0288d1
style B6 fill:#e8f5e9,stroke:#388e3c
3.2 GraphRAG——让 LLM 理解”大局” 🌐
这是 2024 年微软研究院提出的最有影响力的 RAG 改进之一。
核心洞察:传统 RAG 只能检索”块级”信息,无法理解数据集的全局结构。比如:
1 | 传统 RAG: |
GraphRAG 工作流:
%%{init: {'theme': 'base'}}%%
graph TD
A[原始文档] --> B[文本分块]
B --> C[LLM 提取实体与关系]
C --> D[构建知识图谱]
D --> E[Leiden 社区检测]
E --> F1[社区总结1]
E --> F2[社区总结2]
E --> F3[社区摘要N]
G[用户问题] --> H{检索阶段}
H --> I1[向量检索具体事实]
H --> I2[匹配社区摘要]
I1 --> J[合并上下文]
I2 --> J
J --> K[LLM 生成最终答案]
GraphRAG 最佳适用场景:
- ✅ 数据集级别的问答(”总结这些文档的主题”)
- ✅ 发现意外的关联(”A 和 B 之间有什么联系?”)
- ✅ 大规模语料的宏观分析
- ❌ 精确事实查询(传统 RAG 更高效)
- ❌ 实时性要求高的场景(图谱构建慢)
1 | # 简化版 GraphRAG 实现思路 |
微软 GraphRAG 的官方实现:github.com/microsoft/graphrag
GraphRAG 的致命伤:贵 💸
上面的流程看起来很美好,但实际跑一下就知道了——贵得离谱。原因:
- 图谱构建阶段:每个文档块都要调 LLM 提取实体和关系,一个中型数据集(10万文档块)就需要 10万+ 次 LLM 调用
- 社区摘要生成:Leiden 检测出几百个社区后,每个社区都要调 LLM 做总结
- 查询时双路检索:既要向量搜具体事实,又要匹配社区摘要,每次查询的 Token 消耗翻倍
实际测试数据:
1 | 数据集:1,000 篇中等长度技术文档(~2M tokens) |
100-200 倍的构建成本差异,让很多团队在 GraphRAG 门口直接劝退。
2024-2026:GraphRAG 的”降本增效”演进之路 🚀
好在学术界和工业界的反应极快,两年内涌现了大量改进方案。
1. LazyGraphRAG(2024.11,微软)
微软自己也知道 GraphRAG 太贵了,同年 11 月推出了 LazyGraphRAG:
1 | GraphRAG: 先建全量图谱 → 社区检测 → 生成摘要 → 查询 |
核心区别:不预先构建全球图谱,而是等用户提问后,才针对问题动态构建一个”局部子图”。就像你不需要背整本百科全书,只需要在考试时翻到相关的几页。
1 | 成本对比(同上数据集): |
参考:LazyGraphRAG: Setting a new standard for quality and cost — Microsoft, 2024.11
2. LightRAG(2024.10,香港大学)
港大提出的轻量级方案,核心创新是双向检索:
1 | 传统 GraphRAG:实体 → 社区摘要 → 答案 |
LightRAG 把实体和关系存成 (entity, relation, entity) 三元组,然后用向量检索来匹配,不需要预生成社区摘要,构建成本下降了 90%+。
1 | # LightRAG 的简化核心概念 |
参考:LightRAG: Simple and Fast Retrieval-Augmented Generation — HKU, 2024.10
3. nano-graphrag(2025,社区)
更激进的社区方案,目标是 <100 行核心代码 + 兼容本地小模型:
1 | nano-graphrag 的设计取舍: |
4. GraphRAG-SGLang 加速(2025)
用 SGLang 框架把 GraphRAG 的批量 LLM 调用做流水线并行,实体提取阶段提速 5-10x。
GraphRAG 生态全景图(截至 2026)
| 方案 | 发布时间 | 构建成本 | 查询质量 | 适合规模 | 一句话 |
|---|---|---|---|---|---|
| GraphRAG | 2024.07 | 💸💸💸💸💸 | ⭐⭐⭐⭐⭐ | 1K-10K 文档 | 最全最贵,企业级首选 |
| LazyGraphRAG | 2024.11 | 💸 | ⭐⭐⭐⭐ | 10K-1M 文档 | 按需构建,成本友好 |
| LightRAG | 2024.10 | 💸💸 | ⭐⭐⭐⭐ | 1K-100K 文档 | 双向检索,性价比之王 |
| nano-graphrag | 2025 | 💸 | ⭐⭐⭐ | 100-10K 文档 | 本地/小模型友好 |
| GraphRAG + Agent | 2025-2026 | 💸💸💸 | ⭐⭐⭐⭐⭐ | 灵活规模 | Agent 自主决策,最灵活 |
我该用哪个?——决策指南
%%{init: {'theme': 'base'}}%%
flowchart TD
S["我有多少预算?"] --> Q1{"数据规模?"}
Q1 --> |"不足1K 文档"| A["传统 RAG 就够了<br/>别过度设计"]
Q1 --> |"1K-10K 文档"| Q2{"主要查询类型?"}
Q1 --> |"超过10K 文档"| Q3{"有 GPU 集群吗?"}
Q2 --> |"全局总结/宏观分析"| B["GraphRAG 或 LightRAG"]
Q2 --> |"精确事实查找"| A
Q3 --> |"有"| C["GraphRAG 完整版<br/>+ SGLang 加速"]
Q3 --> |"没有"| D["LazyGraphRAG<br/>按需构建,省钱省资源"]
B --> Q4{"Token 预算充裕?"}
Q4 --> |"充裕"| C
Q4 --> |"紧张"| E["LightRAG<br/>性价比最优"]
2026 年的共识:GraphRAG 不是”用不用”的问题,而是”用哪个版本”的问题。就像数据库——小项目用 SQLite,大项目用 PostgreSQL,不存在一个万能方案。
3.3 Self-RAG——学会”自我反思”的 RAG 🪞
2023 年底提出的 Self-RAG(Self-RAG: Learning to Retrieve, Generate, and Critique through Self-Reflection)引入了”批判性反思”机制。
核心思路:在生成过程中,模型会不断问自己:
- 🤔 我需要去检索吗?(有些问题不需要,比如”你好”)
- 📋 检索到的内容真的相关吗?
- ✅ 我生成的答案是否得到了资料的支持?
- 🎯 答案是否完整、有用?
1 | # Self-RAG 的简化决策流程 |
3.4 Agentic RAG——RAG 的下一个范式 🤖
如果说传统 RAG 是”检索+生成”的固定流水线,那 Agentic RAG 就是让 AI 自己决定每一步该做什么。
%%{init: {'theme': 'base'}}%%
graph TD
Q[用户提问] --> Agent{Agent 决策中心}
Agent --> |需要更多信息| W[网页搜索]
Agent --> |查询内部文档| V[向量检索]
Agent --> |需要结构化数据| S[SQL 查询]
Agent --> |需要计算| C[代码执行]
W --> Agent
V --> Agent
S --> Agent
C --> Agent
Agent --> |信息充足| A[生成最终答案]
A --> |自我审查不通过| Agent
A --> |审查通过| R[返回答案+引用]
Agentic RAG 的核心是工具调用(Tool Use / Function Calling):
1 | # Agentic RAG 的简化实现(使用 LangGraph) |
2025 年 Agentic RAG 的标志性项目:
- LangGraph:LangChain 的状态图 Agent 框架,支持复杂循环和分支
- CrewAI:多 Agent 协作框架,每个 Agent 有不同角色
- LlamaIndex Agent:内置丰富的 RAG 专用工具
3.5 更多前沿方向一览 (✧∀✧)
| 方向 | 核心思路 | 代表工作 | 成熟度 |
|---|---|---|---|
| HyDE | 用 LLM 生成假设答案,用答案做向量检索 | Precise Zero-Shot Dense Retrieval (2023) | ⭐⭐⭐ 成熟 |
| RAPTOR | 递归摘要+树状索引,支持多粒度检索 | RAPTOR (2024) | ⭐⭐ 较新 |
| CRAG | 检索后自动纠错+补充检索 | Corrective RAG (2024) | ⭐⭐ 较新 |
| Adaptive RAG | 根据问题复杂度自动选择检索策略 | Adaptive RAG (2024) | ⭐⭐ 较新 |
| ColBERT | Token 级别的延迟交互检索 | ColBERT v2 / PLAID (2023) | ⭐⭐⭐ 成熟 |
| Late Chunking | 先 Embed 整篇文档、再在向量空间切块 | Jina AI (2024) | ⭐⭐ 较新 |
| Contextual Retrieval | Anthropic 的上下文 chunk + BM25 | Anthropic (2024) | ⭐⭐⭐ 成熟 |
4. RAG 评估——你的系统到底好不好? 📏
把系统搭起来了,然后呢?你需要一个客观的衡量标准。
4.1 RAGAS——最主流的 RAG 评估框架
RAGAS 定义了几个核心指标:
| 指标 | 测量什么 | 怎么算 |
|---|---|---|
| Faithfulness(忠实度) | 答案是否完全基于上下文?(反幻觉) | 从答案拆分声明 → 检查每个声明在上下文中能否找到支持 |
| Answer Relevancy(答案相关性) | 答案是否切题? | 从答案反向生成问题 → 与原始问题算相似度 |
| Context Precision(上下文精准度) | 检索到的文档在 Top-K 中位置是否靠前? | 高相关文档 rank 越靠前分越高 |
| Context Recall(上下文召回率) | 有没有漏掉关键的参考文档? | 答案中引用的信息是否覆盖了参考文档中的关键点 |
| Context Relevancy(上下文相关性) | 检索到的文档是否多余? | 相关文档数 / 总检索文档数 |
1 | from ragas import evaluate |
4.2 人工评估 Checklist
自动化评估虽好,但在实际生产上线前,你至少应该人工过一遍:
1 | □ 简单事实查询:"数据库连接端口是多少?"(应该精准命中) |
5. 从零搭建一个 RAG 系统 🔨
理论讲完了,来写一个完整的 Mini RAG 系统吧!(๑•̀ㅂ•́)و✧
5.1 系统架构
%%{init: {'theme': 'base'}}%%
flowchart LR
subgraph 数据摄入
A1["📁 docs/"] --> A2["📄 PyPDFLoader"]
A2 --> A3["✂️ RecursiveSplitter"]
A3 --> A4["🧮 BGE-M3 Embedding"]
A4 --> A5[("🗄️ Qdrant<br/>VectorDB")]
end
subgraph 查询管道
B1["🙋 query"] --> B2["✏️ Query Rewriter"]
B2 --> B3["🔀 Hybrid Retriever<br/>(Vector + BM25)"]
B3 --> B4["🎯 Reranker<br/>(Cross-Encoder)"]
B4 --> B5["📋 Context Builder"]
B5 --> B6["🤖 LLM<br/>(Qwen/DeepSeek)"]
B6 --> B7["✅ Answer + Citations"]
end
A5 -.-> B3
5.2 完整代码
1 | """ |
5.3 部署 Checklist
在上生产之前,逐项确认:
1 | ☐ 向量数据库持久化配置(重启不丢数据) |
6. 常见问题与最佳实践 ⭐
6.1 幻觉为什么还是存在?
即使加了 RAG,幻觉依然可能出现。原因:
- 检索没找到正确答案 → LLM 只好自己”编”
- 检索到的内容互相矛盾 → LLM 选择性相信某一方
- Prompt 没有强调”不准编造” → 给 LLM 明确的角色约束
- LLM 的训练惯性 → 它在训练时学到的知识可能覆盖检索到的信息
降低幻觉的实践清单:
1 | ✅ 设 Reranker 提高检索精度 |
6.2 Chunk Size 设为多少合适?
1 | 场景经验值: |
6.3 多语言支持
中文文档需要特别注意:
- 分词:中文不像英文有空格分隔,Tokenizer 的行为差异大
- Embedding 模型选型:选 BGE-M3 / GTE-Qwen2 这类明确支持中文的
- 混合检索:中文的 BM25 分词要用 jieba 而不是默认的空白分割
7. 展望 2026-2027 🎯
站在 2026 年年中回看,RAG 在过去两年经历了从”玩具”到”基础设施”的蜕变。以下几个趋势正在加速:
7.1 从 RAG 到 Agentic RAG——已成定局
2024 年还在讨论”要不要加 Agent”,2025 年 “Agentic RAG” 已经是默认选项。2026 年的新项目,很少有人会从零手写一个固定流水线的 RAG 了——直接用 LangGraph、CrewAI、OpenAI Agents SDK 搭一个带决策循环的 Agent 系统才是主流做法。
1 | 2024:Naive RAG(查 → 拼 → 答) |
7.2 Long Context + RAG = 互补而非替代
Gemini 2.5 Pro 的 1M tokens 窗口、Claude 4 的 200K 窗口都很震撼,但并没有杀死 RAG。三个硬道理:
- 成本:把 50 万字的文档全塞进 context window,一次查询 $2+;RAG 检索到 5K tokens,一次查询 $0.02
- 延迟:1M tokens 的 prefill 需要数十秒;RAG 的检索只有几百毫秒
- 注意力稀释:即便模型能读完一整本书,它对第 3 页和第 300 页的”注意力”是不一样的——检索是在帮模型关注真正重要的部分
2026 年的共识:长上下文解决了”能塞多少”的问题,RAG 解决了”该关注什么”的问题。
7.3 多模态 RAG——文本已经不够了
- ColPali / ColQwen2(2024-2025):直接用视觉 Embedding 检索 PDF 页面截图,不需要先做 OCR 或文本提取。传统方法”PDF → OCR → 文本 → Embedding”的质量损失链被直接绕过了
- VideoRAG(2025):对视频做时间轴分片,每段提取关键帧+字幕,混合检索
- AudioRAG(2025-2026):会议录音、播客内容的语音 RAG,Whisper 转写 + 说话人分离 + 时间戳索引
7.4 本地 RAG 的爆发
2025-2026 年 llama.cpp、Ollama、llamafile 的成熟让”完全本地化的 RAG”从概念验证变成了实际可行的方案:
1 | 一台 M3 Max MacBook(128GB 统一内存): |
企业对数据隐私的要求越来越高,本地 RAG 在企业内部知识库、医疗病历检索、法律文书分析等场景正在快速普及。
7.5 知识图谱的回归
GraphRAG 在 2024-2026 的演进(上文已详述)证明了结构化知识在复杂推理场景的不可替代性。结合 LightRAG、LazyGraphRAG 等降本方案,图 + 向量的混合检索正在成为企业级 RAG 的标准配置。
7.6 RAG 即基础设施
2026 年最明显的变化:RAG 不再是一个”功能”,而是像数据库、缓存、消息队列一样的基础设施层。MCP (Model Context Protocol) 的流行加速了这一趋势——RAG 作为标准化的”知识检索工具”被接入各种 AI 应用中。
%%{init: {'theme': 'base'}}%%
flowchart LR
App["🖥️ AI 应用"] --> MCP["🔌 MCP 协议"]
MCP --> RAG["📚 RAG 服务<br/>(标准化知识检索)"]
MCP --> DB["🗄️ 数据库工具"]
MCP --> API["🌐 外部 API"]
RAG --> KB["知识库"]
7.7 最后一个预测 🔮
到 2027 年,”RAG” 这个词可能会消失——不是因为技术死了,而是因为它已经融入了所有 AI 系统的默认架构。
就像今天我们不会说 “我的 Web 应用使用了 Ajax”,因为 Ajax 已经是所有 Web 应用的标配。同样,未来的 AI 应用不会说”我用了 RAG”,因为”检索增强”已经内置在所有 LLM 应用的基因里。
参考资料 📚
- Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks — RAG 原始论文 (Lewis et al., 2020)
- GraphRAG: Unlocking LLM discovery on narrative private data — Microsoft, 2024
- LazyGraphRAG: Setting a new standard for quality and cost — Microsoft, 2024
- LightRAG: Simple and Fast Retrieval-Augmented Generation — HKU, 2024
- Self-RAG: Learning to Retrieve, Generate, and Critique through Self-Reflection — Asai et al., 2023
- BGE-M3 技术报告 — BAAI, 2024
- RAGAS: Automated Evaluation of Retrieval Augmented Generation — 2023
- RAPTOR: Recursive Abstractive Processing for Tree-Organized Retrieval — 2024
- LangGraph 官方文档
- Anthropic - Contextual Retrieval — 2024
- ColPali: Efficient Document Retrieval with Vision Language Models — 2024
写在最后 💌
如果只能记住三件事:
- RAG 的核心不是”检索”,而是”检索到了对的东西”——Reranker、混合检索、查询重写比花里胡哨的架构重要 10 倍
- 没有银弹——Naive RAG / GraphRAG / Agentic RAG / Self-RAG 各有适用场景,不是越新越好,而是越匹配越好
- 先跑通再优化——一个能工作的朴素 RAG,比一个永远搭不完的”完美架构”有价值一万倍
这篇文章从基础概念一路讲到 MiniRAG 的完整实现,横跨了 RAG 生态的方方面面。希望它能帮你少走弯路,快速搭建起自己的 RAG 系统 (◍•ᴗ•◍)❤
如果你在实践过程中遇到问题、有更好的方案,或者发现了本文的疏漏——欢迎在评论区交流讨论,我们一起把 RAG 这件事做得更好。
下一篇:向量数据库深度解析——从原理到选型 —— RAG 的”引擎”怎么选?万字长文,现已发布。
Happy RAGging! 🚀







