RAG并非过时技术，小白程序员必备指南：收藏这份检索增强生成实战干货！

本文深入解析RAG（检索增强生成）在大模型应用中的重要性，阐述为何知识库成为AI时代的关键需求，以应对大模型在私域知识处理上的局限。详细介绍了RAG的定义、工作原理及其技术演进，包括全文检索、向量检索、混合检索、知识图谱等核心技术，并探讨了LLM Wiki等新兴知识库构建方案。强调RAG并非单一技术，而是一种持续进化的架构范式，只要大模型存在知识边界，RAG的价值就不会消失，对程序员而言，掌握RAG是提升大模型应用能力的关键。

RAG在网上已经死过很多遍了，谁用谁Low，但是实际上很多的企业知识库仍然在使用，并且依然是主流选择方案。

但是，这些论调会把很多人带偏，尤其是对知识库和RAG没有体系化认知的同学。

这里我们首先要理解一个问题：在AI时代，知识库为啥变得如此被需要？

大模型在回答问题时，它只知道公域知识，并不知道我们私域的知识，在这种情况下它就容易出现幻觉，胡乱编造一些看似正确的答案给我们。

为了缓解这个问题，我们可以给大模型外挂一个知识库，让大模型在回答问题时能够参考可信的知识来源。

但新的问题又出现了。

企业知识库中的内容往往很庞大，而大模型的上下文窗口是有限制的，就不可能把所有的知识一次性全部提供给模型。

因此，在回答问题之前，需要先从海量知识中找到与当前问题最相关的信息，再把这些信息作为上下文给到大模型参考回答。

这种解决方案，我们称之为RAG，即知识检索增强生成。

如果给它下一个定义的话：RAG 是一种通过动态检索外部知识，并将检索结果作为上下文提供给大模型，从而提升回答准确性、时效性和可解释性的系统架构范式。

在理解了这些知识后，我们在看前面的问题，RAG真的会死掉吗？

答案肯定是不会的，因为 RAG 并不是某一种具体的技术，而是一种检索 + 生成的架构范式。只要大模型无法穷尽所有私有知识、实时信息和动态变化的数据，检索的价值就不会消失：

只不过，这几年年RAG 内部采用的技术在不断的演进。

从最早的关键词检索，到向量检索；从单路召回，到混合检索；从传统 RAG，到 Graph RAG、Agentic RAG，本质上都是在不断提升信息获取和知识利用的效率。

接下来，我们就展开讨论下RAG体系下有哪些检索技术：

全文检索

全文检索在RAG检索策略中非常常用，可以说是元老级别的存在，其实现以Elasticsearch为代表，在企业内部文档搜索、电商商品搜索、法律案例检索、专利查重等场景的背后都有它们的身影：

它的大致原理是，对用户输入的问题进行分词，然后通过倒排索引找到包含这些关键词的文档，在根据BM25算法计算出每个文档的相关性得分，然后返回排序后的结果。

其中BM25算法公式如下，但对大多数同学来说略微复杂，但这并不重要。它核心逻辑是：一个词在文档中出现的次数越多、在整个文档集合中越稀有、并且文档长度相对更短，那么该词对这篇文档的重要性通常越高，相应的相关性得分也会更高。

全文检索的处理流程如下：

在用户搜索之前，系统会先对知识库中的文档进行预处理，构建倒排索引。

下面我们用一个简单的例子说明，方便大家理解。假设知识库中有下面三个文档：

文档A：员工因公出差产生的交通费、住宿费可按照规定进行报销。 文档B：员工请假需提交申请，并经过主管审批。 文档C：差旅费用报销标准包括交通费、住宿费以及餐补标准。

系统首先会对文档内容进行分词，分词过程中会去掉一些停用词，结果大致如下：

文档A：员工/出差/交通费/住宿费/报销 文档B：员工/请假/申请/审批 文档C：差旅/费用/报销/标准/交通费/住宿费

接下来会按如下方式构建倒排索引：

注意这里，并不是按照某个文档包含哪些词进行存储的，而是按照某个词存在于哪些文档中进行存储的，这就是倒排索引。

理解了索引结构，我们在看检索流程，当用户提问：

出差费用怎么报销？

系统同样会先进行分词：

出差/费用/报销

然后根据每个关键词在前面构建的倒排索引中查找包含该关键词的文档：

出差 → A 费用 → C 报销 → A、C

系统就能快速召回文档A和文档C，接下来，BM25算法会对召回的结果进行相关性评分，最终按照得分从高到低返回文档。

整个过程中，系统并没有真正理解“出差费用怎么报销”这句话的含义，而是通过关键词匹配找到候选文档，再利用BM25计算相关性并完成排序。

由此可见，全文检索其实就是类似关键词检索，这套逻辑在精准查找的场景下非常可靠，检索速度快并且很精准，但有个前提是关键词要明确。

比如查法规条款编号"ISO 27001第8.2条"、搜产品型号"NX-7200G"、或者查找特定术语、专有名词等这些场景就很适合。

但问题在于，现实中的用户并不总能使用与文档完全一致的表达方式。

比如，我们搜索的是员工离职流程，但是知识库文档里面写的是员工解除劳动合同办理规范。

虽然表达的意思相近，但因为关键词不同，全文检索就无法将相关的文档召回。

因此，全文检索解决的是“关键词是否匹配”的问题，而无法很好地解决“语义上是否相似”的问题。为了弥补这一缺陷，向量检索就开始被广泛应用于RAG系统中。

向量检索

向量检索，它解决的正是全文检索不擅长的问题：用户表达和文档表达不一致，但语义相近：

它的大致原理是，先通过 Embedding 模型把文本转换成一组数字向量，这个向量可以理解为文本在语义空间中的坐标，如果两段文本表达的意思越接近，那么它们在向量空间中的距离通常也越近。

比如下面两句话：

1. **员工离职流程是什么？** 2. **员工解除劳动合同办理程序是怎样的？**

从语义角度看，它们问的的都是员工离职相关流程，经过向量化处理之后，它们在语义空间中的距离就会比较接近。

这就是向量检索的核心价值。它的处理流程分为两个阶段：

1. 离线阶段：

在用户搜索之前，会先对文档进行切分，比如按标题、段落、固定长度或语义切成一个个知识片段，我们通常称之为 chunk。

然后使用 Embedding 模型，把每个 chunk 转换成向量，并存储到向量数据库中，比如 FAISS、Milvus、pgvector、Elasticsearch dense vector 等。

2. 检索阶段：

当用户提问时，同样会利用Embedding 模型把用户的问题转换成一个向量，然后在向量库中查找与这个查询向量最接近的文档片段。

判断两个向量是否接近，常见的方法包括余弦相似度、欧氏距离、点积等，其中余弦相似度比较常见，它关注的是两个向量方向是否接近，越一致表示语义越相似。

我们还是用一个简单例子来看。

假设知识库中有下面三个文档片段：

文档A：员工因公出差产生的交通费、住宿费可按照规定进行报销。 文档B：员工解除劳动合同前，应完成工作交接、资产归还和离职审批。 文档C：差旅费用报销标准包括交通费、住宿费以及餐补标准。

当用户提问：

离职前需要办哪些手续？

用户问题和文档B的内容在语义上是很接近的，因此会把文档B召回回来。如果用全文检索，因为关键词不匹配，就没有召回内容。

因此向量检索的优势：

它能理解同义词、近义表达、口语化问题，以及用户和文档之间表述不一致的情况。

但向量检索也不是万能的，它的优势是语义理解，但它在精确匹配上就很弱。

比如需要精确匹配某个编号、型号、条款或专有名词，这个时候全文检索比向量检索会更可靠。

另外，向量检索的效果还会受到很多因素影响，比如文档切分是否合理、Embedding 模型质量如何、知识片段是否包含足够上下文、召回数量设置是否合适等。

如果 chunk 切得太短，可能语义信息不完整；如果 chunk 切得太长，又可能引入太多无关内容，导致向量表达不够聚焦。

这就引申出来了很多种分块的方法，比如固定长度+overlap，正则表达式、父子分段、大模型语义分段等，但都没有最优解。

这也是向量检索广受诟病，不招人待见的原因。但是又不得不用它！

总之，向量检索解决的是语义相似的问题，它跟全文检索这种方式不冲突。通常情况下，用户的问题既包含语义意图，也包含关键词、业务术语，使用单一检索方式召回效果有限。因此，会把全文检索和向量检索结合起来，形成混合检索，从而优劣互补。

那有了上面的混合检索方案，是不是就能完美解决所有问题了？ No，还差得远呢！ 在一些复杂知识库场景中，只是找到相关的文本内容还不够，有些问题并不只是单点的知识匹配，而是涉及到关系和多跳推理。

比如用户提问：

诺兰导演过哪些由莱昂纳多主演的电影？

这个问题包含几个关键信息，诺兰是谁？诺兰导演过哪些电影？莱昂纳多主演过哪些电影？这两者之间有没有交集？

通过前面的检索方式，可能会召回一些关于诺兰、莱昂纳多、电影的文本片段，但是并不能把这些关系给串联起来。

对于这种场景，就需要用到知识图谱了！

知识图谱

知识图谱可以理解为用“实体 + 关系”的方式把知识编织而成的结构化知识网络。

还是以电影的例子举例，其中实体可以是电影、导演、演员、角色、颁奖等，关系则表示这些实体之间的连接。

比如：

诺兰:导演:盗梦空间 莱昂纳多:主演:盗梦空间 莱昂纳多:饰演:柯布 盗梦空间:获得提名:奥斯卡最佳摄影

用图的方式表示如下：

这里的知识就不再是以一段段文本的形式存在了，而是被拆解为一个个实体，和实体之间的关系。

知识图谱的处理流程也分为两个阶段：

1. 离线阶段

先对电影百科、影人资料、影评文章、奖项记录等内容进行建模，识别里面的关键实体和关系。 比如从下面这段内容：

《盗梦空间》由克里斯托弗·诺兰执导，莱昂纳多·迪卡普里奥主演，并在片中饰演柯布。

系统要抽取出：

实体：盗梦空间、克里斯托弗·诺兰、莱昂纳多·迪卡普里奥、柯布 关系：诺兰导演盗梦空间、莱昂纳多主演盗梦空间、莱昂纳多饰演柯布

然后把这些实体和关系存储到图数据库中。

这里还有一个重要的概念，叫三元组，它啥意思呢？

就是用主体-关系-客体的方式描述一条知识，比如：

诺兰导:导演:盗梦空间 莱昂纳多:主演:盗梦空间 莱昂纳多:饰演:柯布

每一条三元组，本质上就是知识图谱中的一条边，大量的三元组连接在一起，就形成了知识图谱。

• 检索阶段

当用户提问时，系统会先识别问题中的实体和意图，将用户的自然语言问题转化为结构化的图查询（如Cypher语句），然后在图数据库中找到答案子图并返回结果。

比如还是前面那个问题：

诺兰导演过哪些由莱昂纳多主演的电影？

系统会先识别问题中的核心实体为诺兰、莱昂纳多，然后分别沿着关系进行查找：

克里斯托弗·诺兰 → 导演 → 电影 莱昂纳多·迪卡普里奥 → 主演 → 电影

对应的Cypher查询语句如下：

MATCH (n:Person {name: '克里斯托弗·诺兰'})-[:导演]->(m:Movie) MATCH (l:Person {name: '莱昂纳多·迪卡普里奥'})-[:主演]->(m:Movie) RETURN m.title AS 电影名称

最后取两条关系路径的交集，就能得到答案：《盗梦空间》。

另外需要注意的是，图数据库的核心能力是存储关系和查询关系，它并不会自动完成推理。如果要实现推理，我们还要做领域规则建模才能根据查询出来关系完成推理逻辑。

上面就是知识图谱的简化流程，它非常适合处理那些关系明确、结构稳定、需要多跳推理的场景。

但我们实际在构建知识图谱的时候要难很多，初期的构建成本和后期的维护成本都比较高，需要处理实体识别、关系抽取、本体设计以及规则建模、实体消歧等问题，后续如果业务发生变化，图谱和规则都需要持续更新。

LLM Wiki

在今年4月，karpathy在Github上面公开了LLM wiki 的构想文件，介绍了一种新的知识库构建方案的架构和理念。

他的核心观点是，传统的RAG系统，都是先上传资料，查询时召回相关知识片段，然后临时综合性回答，知识并没有被持续沉淀下来。

而LLM wiki 做法是：人负责收集原始资料，大模型来理解这些知识，然后自动维护一个结构化的Wiki，后续检索时就直接从wiki里面找答案。

它的整体结构大致如下：

这里我们需要聚焦一下，看看它是如何做知识检索的。

首先，在把知识写入wiki的时候，会同时在Index.md文件中维护内容索引，这里可以把这个理解为wiki的目录结构。

在做知识查询的时候，会读取这个索引文件，判断哪些wiki文件跟当前问题相关，然后在进一步读取。这和我们从目录结构找到对应的章节知识是类似的做法，可以提高检索的效率。

这里Wiki 页面的渐进式展开和 Skills 的渐进式披露的机制是非常一致的。

但是问题也来了，如果知识库内容持续扩大，Index.md这个单文件的内容也会越来越大，甚至超过大模型上下文限制，导致检索效率降低、单次token消耗变大。

那这里处理的方法又得回答前面介绍的检索方式了，得通过关键词检索或者向量检索来解决。

并且LLM wiki这套方案目前实践下来仅适合个人知识库，在企业知识库中运用还不完善。

总结

现在回过头来看，RAG的发展并不是一种技术淘汰另一种技术，而是在不断弥补前一种方案解决不了的问题。

全文检索解决的是关键词匹配的问题，向量检索解决的是语义理解的问题，混合检索兼顾了精准匹配和语义召回，知识图谱进一步解决了实体关系和多跳推理的问题，而近一年出现的 PageIndex、LLM Wiki 等新范式，则开始重新思考知识应该如何组织。

但始终没有出现银弹！

无论未来检索方式如何变化、知识组织形式怎么升级，它们解决的始终都是同一个问题：

把最准确、最可信、最相关的知识给到大模型

所以，只要大模型仍然需要外部知识来弥补自身能力的边界，RAG这种”检索增强生成”的思想，就会长期存在。

最后

如果说程序员已经是高薪职业，那么干AI的程序员，就是高薪中的高薪。

现在的市场，已经用数据给程序员指明了方向：学AI大模型，就是冲刺高薪的最优解！

看着身边越来越多的同行转型大模型、拿到高薪offer，很多人心里都动了心，但真正的难题来了：零基础小白不知道从哪入门？有基础的程序员找不到系统学习路径？实战项目练手无门？面试不知道考什么？

别慌！今天就给大家整理了一份【2026年最新版】AI大模型免费学习资源包，覆盖从入门到实战、从理论到面试、从基础到进阶的全流程，所有资料均已整理归档，无冗余、无套路，免费分享给每一位想抓住AI风口的程序员和小白！

👇👇扫码免费领取全部内容👇👇

1、大模型系统化学习路线

2、大模型学习书籍&文档

3、AI大模型最新行业报告

4、大模型项目实战&配套源码

5、大模型大厂面试真题

四阶段精细化学习规划（附时间节点，可直接照做）

结合上述资源，给大家整理了一份可直接落地的四阶段学习规划，总时长约2个月，小白可循序渐进，程序员可根据自身基础调整节奏，高效掌握大模型核心能力，快速实现从“入门”到“能落地、能面试”的跨越。

第一阶段（10天）：初阶应用

该阶段让大家对大模型 AI有一个最前沿的认识，对大模型 AI 的理解超过 95% 的人，可以在相关讨论时发表高级、不跟风、又接地气的见解，别人只会和 AI 聊天，而你能调教 AI，并能用代码将大模型和业务衔接。

• 大模型 AI 能干什么？
• 大模型是怎样获得「智能」的？
• 用好 AI 的核心心法
• 大模型应用业务架构
• 大模型应用技术架构
• 代码示例：向 GPT-3.5 灌入新知识
• 提示工程的意义和核心思想
• Prompt 典型构成
• 指令调优方法论
• 思维链和思维树
• Prompt 攻击和防范
• …

第二阶段（30天）：高阶应用

该阶段我们正式进入大模型 AI 进阶实战学习，学会构造私有知识库，扩展 AI 的能力。快速开发一个完整的基于 agent 对话机器人。掌握功能最强的大模型开发框架，抓住最新的技术进展，适合 Python 和 JavaScript 程序员。

• 为什么要做 RAG
• 搭建一个简单的 ChatPDF
• 检索的基础概念
• 什么是向量表示（Embeddings）
• 向量数据库与向量检索
• 基于向量检索的 RAG
• 搭建 RAG 系统的扩展知识
• 混合检索与 RAG-Fusion 简介
• 向量模型本地部署
• …

第三阶段（30天）：模型训练

恭喜你，如果学到这里，你基本可以找到一份大模型 AI相关的工作，自己也能训练 GPT 了！通过微调，训练自己的垂直大模型，能独立训练开源多模态大模型，掌握更多技术方案。

到此为止，大概2个月的时间。你已经成为了一名“AI小子”。那么你还想往下探索吗？

• 为什么要做 RAG
• 什么是模型
• 什么是模型训练
• 求解器 & 损失函数简介
• 小实验2：手写一个简单的神经网络并训练它
• 什么是训练/预训练/微调/轻量化微调
• Transformer结构简介
• 轻量化微调
• 实验数据集的构建
• …

第四阶段（20天）：商业闭环

对全球大模型从性能、吞吐量、成本等方面有一定的认知，可以在云端和本地等多种环境下部署大模型，找到适合自己的项目/创业方向，做一名被 AI 武装的产品经理。

• 硬件选型
• 带你了解全球大模型
• 使用国产大模型服务
• 搭建 OpenAI 代理
• 热身：基于阿里云 PAI 部署 Stable Diffusion
• 在本地计算机运行大模型
• 大模型的私有化部署
• 基于 vLLM 部署大模型
• 案例：如何优雅地在阿里云私有部署开源大模型
• 部署一套开源 LLM 项目
• 内容安全
• 互联网信息服务算法备案
• …

👇👇扫码免费领取全部内容👇👇

6、这些资料真的有用吗？

这份资料由我和鲁为民博士(北京清华大学学士和美国加州理工学院博士)共同整理，现任上海殷泊信息科技CEO，其创立的MoPaaS云平台获Forrester全球’强劲表现者’认证，服务航天科工、国家电网等1000+企业，以第一作者在IEEE Transactions发表论文50+篇，获NASA JPL火星探测系统强化学习专利等35项中美专利。本套AI大模型课程由清华大学-加州理工双料博士、吴文俊人工智能奖得主鲁为民教授领衔研发。

资料内容涵盖了从入门到进阶的各类视频教程和实战项目，无论你是小白还是有些技术基础的技术人员，这份资料都绝对能帮助你提升薪资待遇，转行大模型岗位。

这份完整版的大模型 AI 学习资料已经上传CSDN，朋友们如果需要可以微信扫描下方CSDN官方认证二维码免费领取【保证100%免费】