@[TOC](检索增强生成 (RAG) 技术全栈指南 一)
0. 前言
RAG技术(检索增强生成)是大模型应用开发中必用技术之一，本文按照开源项目All in RAG 的目录进行学。
项目文档：https://datawhalechina.github.io/all-in-rag
GitHub: https://github.com/datawhalechina/all-in-rag
进度：
All-in-RAG 技术全栈指南 完整学习清单（带复选框）
第一部分：RAG基础入门
- 第一章 解锁RAG
- RAG简介 - RAG技术概述与应用场景
- 准备工作 - 环境配置与工具准备
- 四步构建RAG - 快速上手RAG开发
- 附：环境部署 - Python虚拟环境部署方案补充
- 第二章 数据准备
- 数据加载 - 多格式文档处理与加载
- 文本分块 - 文本切分策略与优化
第二部分：索引构建与优化
- 第三章 索引构建
- 向量嵌入 - 文本向量化技术详解
- 多模态嵌入 - 图文多模态向量化
- 向量数据库 - 向量存储与检索系统
- Milvus实践 - Milvus多模态检索实战
- 索引优化 - 索引性能调优技巧
第三部分：检索技术进阶
- 第四章 检索优化
- 混合检索 - 稠密+稀疏检索融合
- 查询构建 - 智能查询理解与构建
- Text2SQL - 自然语言转SQL查询
- 查询重构与分发 - 查询优化策略
- 检索进阶技术 - 高级检索算法
第四部分：生成与评估
- 第五章 生成集成
- 格式化生成 - 结构化输出与格式控制
- 第六章 RAG系统评估
- 评估介绍 - RAG系统评估方法论
- 评估工具 - 常用评估工具与指标
第五部分：高级应用与实战
- 第七章 高级RAG架构（拓展部分）
- 基于知识图谱的RAG
- 第八章 项目实战一
- 环境配置与项目架构
- 数据准备模块实现
- 索引构建与检索优化
- 生成集成与系统整合
- 第九章 项目实战一优化（选修篇）
- 图RAG架构设计
- 图数据建模与准备
- Milvus索引构建
- 智能查询路由与检索策略
- 第十章 项目实战二（选修篇）
- 规划中
第六部分：知识拓展
- 第十一章 Neo4J 简单应用
- 知识图谱与 Neo4j 安装
- Neo4j 基本使用
1. 文章目录
2. 第一章 解锁RAG
2.1 RAG简介 - RAG技术概述与应用场景
https://datawhalechina.github.io/all-in-rag/#/chapter1/01_RAG_intro
2.1.1 什么是RAG
RAG（Retrieval-Augmented Generation），即检索增强生成，其本质是一种 “内外结合” 的技术范式。它巧妙连接了两类知识：一类是 LLM 在训练过程中固化于模型权重的 “参数化知识”—— 就像我们大脑中长久记忆但可能模糊的知识；另一类是来自外部知识库、可随时更新的 “非参数化知识”—— 如同考试时可以查阅的精准参考资料。
简单来说，RAG 的核心逻辑是：在 LLM 生成回答前，先通过检索机制从外部知识库中找到与问题高度相关的信息，将这些 “参考资料” 与用户问题一同交给 LLM，引导其基于真实依据生成内容。这就像让 LLM 从 “闭卷考试” 变成 “开卷考试”，既发挥了模型的语言组织能力，又保证了输出的准确性。
2.1.2 技术原理
RAG 系统的运作的核心，是通过 “检索” 与 “生成” 两个关键阶段，实现内外知识的深度融合：
- 检索阶段：精准锁定 “参考资料”
- 第一步是 “知识向量化”：借助嵌入模型（Embedding Model），将外部知识库中的所有文档都编码成计算机能理解的向量形式，形成向量索引（Index）并存入向量数据库—— 这相当于给所有资料做了 “语义标签”，方便快速查找。
- 第二步是 “语义召回”：当用户发起查询时，同样用嵌入模型将问题转化为向量，通过相似度搜索技术，从向量数据库中精准筛选出与问题最相关的文档片段。这个过程就像一位细心的图书管理员，根据你的需求快速从海量书籍中找出核心参考资料。
- 生成阶段：融合知识产出答案
- 首先进行 “上下文整合”：生成模块会接收两部分信息 —— 用户的原始问题和检索到的相关文档片段；
- 随后进行 “指令引导生成”：按照预设的 Prompt 指令，LLM 会将问题与上下文信息有效结合，在可控范围内生成有理有据的回答，避免凭空捏造。
2.1.3 技术演进分类
2.1.4 为什么要使用 RAG？ 技术选型：RAG vs. 微调
在选择具体的技术路径时，一个重要的考量是成本与效益的平衡。通常，我们应优先选择对模型改动最小、成本最低的方案，所以技术选型路径往往遵循的顺序是提示词工程（Prompt Engineering） -> 检索增强生成 -> 微调（Fine-tuning）。
我们可以从两个维度来理解这些技术的区别。如下图所示，横轴代表“LLM 优化”，即对模型本身进行多大程度的修改。从左到右，优化的程度越来越深，其中提示工程和 RAG 完全不改变模型权重，而微调则直接修改模型参数。 纵轴代表“上下文优化”，是对输入给模型的信息进行多大程度的增强。从下到上，增强的程度越来越高，其中提示工程只是优化提问方式，而 RAG 则通过引入外部知识库，极大地丰富了上下文信息。
基于此，我们的选择路径就清晰了：
- 先尝试提示工程：通过精心设计提示词来引导模型，适用于任务简单、模型已有相关知识的场景。
- 再选择 RAG：如果模型缺乏特定或实时知识而无法回答，则使用 RAG，通过外挂知识库为其提供上下文信息。
- 最后考虑微调：当目标是改变模型“如何做”（行为/风格/格式）而不是“知道什么”（知识）时，微调是最终且最合适的选择。例如，让模型学会严格遵循某种独特的输出格式、模仿特定人物的对话风格，或者将极其复杂的指令“蒸馏”进模型权重中。
RAG 的出现填补了通用模型与专业领域之间的鸿沟，它在解决如表所示 LLM 局限时尤其有效：
