RAG全栈开发入门：从原理到五大核心环节详解

想做一个靠谱的知识客服，或者搭建一个能回答问题的企业知识库，有一项技术绕不开——RAG。B站UP主阿水在这期视频中，用通俗的方式拆解了RAG的完整实现链路。本文基于其讲解内容，系统梳理RAG的运行原理与五大核心环节。

什么是RAG，它解决了什么问题

RAG全称 Retrieval Augmented Generation，翻译过来就是"检索增强生成"。听起来高大上，但本质只做两件事：先从资料库中检索相关内容，再基于这些内容生成答案——先检索，再生成。

它是目前最常用的AI问答方案之一，大量企业的智能客服、内部知识库都基于这项技术。把员工手册、产品手册等内容存入知识库，通过RAG查询，可以大幅节省查询时间，实现降本增效。

那么为什么不直接把所有文档一股脑扔给大模型？阿水指出了三个关键问题：模型无法读取所有内容（受上下文窗口大小限制，内容过多会"读了后面忘了前面"，准确率下降）；推理成本高（输入越多，token越多，本地部署则耗电和硬件需求越大）；推理速度慢（内容越多，模型消化越慢，上百页手册会严重拖慢响应）。

文档读取速度受限

解决思路很简单：不要把整个文档都发给模型，只把文档中与问题相关的片段发给它。比如上百页产品手册里，可能只有三个片段跟用户问题有关，那就把这三个片段挑出来，连同问题一起发给大模型。原本的三个难题也就迎刃而解。

RAG的两大阶段与五个环节

阿水把整个RAG流程拆成两个阶段：提问前（数据准备）和提问后（回答）。

提问前包括：分片、索引两个环节，需要提前准备。
提问后包括：召回、重排、生成三个环节，在用户提问后触发。

下面逐个拆解这五个环节。

分片（Chunking）

分片顾名思义就是把文档拆分成许多片段。切分方法有多种：按字数切分（固定500字、800字、1000字一段）、按段落切分、按章节切分等。不管用哪种方法，最终目的都是把整篇文档切成多块。

分片策略的选择对最终检索质量影响很大，是 RAG 调优中最容易被忽视的环节。固定字数切分实现简单，但可能在句子中间硬截断，破坏语义完整性；为此常引入"重叠"机制——相邻片段之间保留一定字数的重叠区域（如每段500字，相邻段重叠100字），确保跨片段的信息不会完全丢失。按段落或章节切分语义更完整，但片段长度差异大，超长段落仍需二次截断。此外还有递归分割、基于语义相似度的动态分割等更高级方法。片段太长会稀释相关信息、增加噪声；片段太短则可能缺少足够上下文，导致大模型生成时语境不足。实践中通常需要针对具体文档类型和模型的上下文窗口大小反复测试，找到最优的分片粒度。

索引（Indexing）

索引是通过 Embedding 把每个片段文本转成一个向量，再将片段文本和对应向量一起存入向量数据库。这里涉及三个关键概念：向量、Embedding、向量数据库。

核心概念：向量、Embedding与向量数据库

向量

向量是数学概念，代表一个有大小、有方向的量，通常用一个数组表示。数组中数字的个数就是向量的维度——四个数字就是四维向量。低维向量可以画在坐标轴上，一维在直线上，二维在平面坐标轴上，三维在立体坐标轴上。超过三维就无法可视化了，但不代表它不存在。

向量可以在坐标轴上表示

实际RAG中的向量维度非常大，几百甚至几千维。维度越大，每个向量包含的信息越丰富，能力越强、可靠性越高。

Embedding

Embedding 是把文本转化成向量的过程。阿水用二维向量举例："今天天气是晴天"对应(-1.5, 2.5)，"阿水喜欢吃菠萝"对应(2, 3)，"阿水喜欢吃苹果"对应(3, 3)。可以看到后两个句子的向量非常接近，而"晴天"距离较远——这正是Embedding的目的：语义相近的文本，转成向量后也相近。

这样当用户问"阿水喜欢吃什么"时，把问题也向量化，再根据向量相似度就能找到最相近的文本片段。Embedding由专门的Embedding模型完成，而非ChatGPT、DeepSeek^广告这类通用对话模型。阿水推荐查看 HuggingFace 的 Embedding 模型排行榜来挑选合适的模型（排行榜会随新模型推出而更新）。

向量数据库

向量数据库专门用于存储和查询向量，它为向量存储做了大量优化，并提供计算向量相似度的函数。需要注意：存储时不仅要存向量，还要把原始文本一起存进去，这样找到相似向量后才能定位对应文本。因此向量数据库至少包含两列——一列向量，一列文本。

索引流程的整体概念

理解了这三个概念，再回看索引流程就清晰了：把每个片段逐一通过Embedding转成向量，连同文本一起存入向量数据库，处理完所有片段，索引阶段就结束了。分片和索引都发生在用户提问之前。

常见的向量数据库包括开源的 Chroma、Qdrant、Weaviate，以及商业化的 Pinecone 等。与传统关系型数据库（如 MySQL）不同，向量数据库针对高维向量的近似最近邻（ANN，Approximate Nearest Neighbor）搜索做了专项优化——传统数据库做精确匹配，向量数据库做"相似度查找"。在实际部署中，小型项目常用轻量级的 Chroma（可直接在本地内存或磁盘运行），大规模生产环境则更多选用支持分布式部署、过滤检索的 Qdrant 或 Weaviate。值得注意的是，许多 RAG 框架（如 LangChain、LlamaIndex）已经封装了对主流向量数据库的连接器，开发者无需从头编写增删查改逻辑，直接调用接口即可。

提问后的三个环节：召回、重排、生成

召回（Retrieval）

召回就是搜索与用户问题相关片段的过程。用户提问后，先用Embedding模型把问题转成向量，发给向量数据库查询最相关的N个片段（N不固定，可以是5个、10个，只要数量不多即可）。

数据库判断相关性靠的是向量相似度计算。阿水介绍了三种最常用的方法：

余弦相似度：计算两个向量夹角的cos值，夹角越小相似度越高；
欧氏距离：计算两向量之间的距离，距离越小相似度越高；
点积：既包含向量方向又包含向量大小，目前用得较多。

实际使用Embedding模型或RAG框架时，相似度计算通常已经封装好，不需要自己实现。

重排（Rerank）

重排就是重新排序。它和召回做的事类似，但是从召回出来的N个片段中，再精选出几个最相关的。为什么要分两步？阿水用招聘打了个精彩的比方：

企业招聘时面对成千上万份简历，不可能每份都仔细面试，于是先快速初筛（可能筛错，但权衡成本后最优），从一万份筛出二十份，再对这二十份逐个精细面试。

召回相当于初筛：用向量相似度，成本低、耗时短，但准确率相对低；重排相当于精细面试：使用Cross-Encoder（文中称classical/rerank模型），耗时长、成本高，但准确率高。两者相似度计算逻辑不同，组合使用的效果比单纯召回更好。

召回阶段使用的是 Bi-Encoder 架构：问题和文档片段分别独立编码成向量，再计算相似度，速度快但丢失了两者之间的交叉语义信息。重排阶段使用的 Cross-Encoder 则将问题与每个候选片段拼接后一起输入模型，让模型直接对这一对文本打出相关性分数，能捕捉更细粒度的语义匹配，但计算量与候选片段数量成正比，不适合直接对全库使用。正因如此，两阶段组合成为工业界标准做法：先用 Bi-Encoder 从百万文档中快速捞出几十个候选，再用 Cross-Encoder 对这几十个候选精排，兼顾效率与准确率。常用的开源重排模型包括 BGE-Reranker 系列和 Cohere Rerank API。

生成（Generation）

生成就是产出最终答案。把经过召回与重排筛选出的参考片段，连同用户问题一起发给大模型，大模型据此生成回答，返回给用户。至此整个流程结束。

完整流程串联

把两个阶段串起来回顾：

提问前（准备）：用户资料 → 分片 → Embedding模型转成向量 → 存入向量数据库。

提问后（回答）：用户问题 → Embedding模型转成向量 → 向量数据库检索出N个最相近片段（召回）→ Rerank模型重排筛选出几个最相关片段 → 连同问题交给大模型 → 生成答案返回用户。

其中召回数量N和重排后保留数量都可以自行设定。理解了这条链路，就能动手用领导给的资料做一些RAG小demo了。阿水也鼓励初学者先从简单的Demo入手，边做边学。

小结

这期内容把RAG从"为什么需要"到"怎么运行"讲得相当通透：核心是通过检索把海量文档中与问题相关的片段挑出来，再交给大模型生成答案，从而突破上下文窗口限制、降低成本、提升速度。五个环节——分片、索引、召回、重排、生成——构成了一套可落地的企业知识库技术方案。对于想入门RAG的开发者来说，这是一份清晰的概念地图。