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. 员工解除劳动合同办理程序是怎样的？从语义角度看，它们问的的都是员工离职相关流程，经过向量化处理之后，它们在语义空间中的距离就会比较接近。
这就是向量检索的核心价值。它的处理流程分为两个阶段：
- 离线阶段：
在用户搜索之前，会先对文档进行切分，比如按标题、段落、固定长度或语义切成一个个知识片段，我们通常称之为 chunk。
然后使用 Embedding 模型，把每个 chunk 转换成向量，并存储到向量数据库中，比如 FAISS、Milvus、pgvector、Elasticsearch dense vector 等。
- 检索阶段：
当用户提问时，同样会利用Embedding 模型把用户的问题转换成一个向量，然后在向量库中查找与这个查询向量最接近的文档片段。
判断两个向量是否接近，常见的方法包括余弦相似度、欧氏距离、点积等，其中余弦相似度比较常见，它关注的是两个向量方向是否接近，越一致表示语义越相似。
我们还是用一个简单例子来看。
假设知识库中有下面三个文档片段：
文档A：员工因公出差产生的交通费、住宿费可按照规定进行报销。文档B：员工解除劳动合同前，应完成工作交接、资产归还和离职审批。文档C：差旅费用报销标准包括交通费、住宿费以及餐补标准。当用户提问：
离职前需要办哪些手续？
用户问题和文档B的内容在语义上是很接近的，因此会把文档B召回回来。如果用全文检索，因为关键词不匹配，就没有召回内容。
因此向量检索的优势：
它能理解同义词、近义表达、口语化问题，以及用户和文档之间表述不一致的情况。
但向量检索也不是万能的，它的优势是语义理解，但它在精确匹配上就很弱。
比如需要精确匹配某个编号、型号、条款或专有名词，这个时候全文检索比向量检索会更可靠。
另外，向量检索的效果还会受到很多因素影响，比如文档切分是否合理、Embedding 模型质量如何、知识片段是否包含足够上下文、召回数量设置是否合适等。
如果 chunk 切得太短，可能语义信息不完整；如果 chunk 切得太长，又可能引入太多无关内容，导致向量表达不够聚焦。
这就引申出来了很多种分块的方法，比如固定长度+overlap，正则表达式、父子分段、大模型语义分段等，但都没有最优解。
这也是向量检索广受诟病，不招人待见的原因。但是又不得不用它！
总之，向量检索解决的是语义相似的问题，它跟全文检索这种方式不冲突。通常情况下，用户的问题既包含语义意图，也包含关键词、业务术语，使用单一检索方式召回效果有限。因此，会把全文检索和向量检索结合起来，形成混合检索，从而优劣互补。
那有了上面的混合检索方案，是不是就能完美解决所有问题了？ No，还差得远呢！ 在一些复杂知识库场景中，只是找到相关的文本内容还不够，有些问题并不只是单点的知识匹配，而是涉及到关系和多跳推理。
比如用户提问：
诺兰导演过哪些由莱昂纳多主演的电影？
这个问题包含几个关键信息，诺兰是谁？诺兰导演过哪些电影？莱昂纳多主演过哪些电影？这两者之间有没有交集？
通过前面的检索方式，可能会召回一些关于诺兰、莱昂纳多、电影的文本片段，但是并不能把这些关系给串联起来。
对于这种场景，就需要用到知识图谱了！
知识图谱
知识图谱可以理解为用“实体 + 关系”的方式把知识编织而成的结构化知识网络。
还是以电影的例子举例，其中实体可以是电影、导演、演员、角色、颁奖等，关系则表示这些实体之间的连接。
比如：
诺兰:导演:盗梦空间莱昂纳多:主演:盗梦空间莱昂纳多:饰演:柯布盗梦空间:获得提名:奥斯卡最佳摄影用图的方式表示如下：
这里的知识就不再是以一段段文本的形式存在了，而是被拆解为一个个实体，和实体之间的关系。
知识图谱的处理流程也分为两个阶段：
- 离线阶段
先对电影百科、影人资料、影评文章、奖项记录等内容进行建模，识别里面的关键实体和关系。 比如从下面这段内容：
《盗梦空间》由克里斯托弗·诺兰执导，莱昂纳多·迪卡普里奥主演，并在片中饰演柯布。系统要抽取出：
实体：盗梦空间、克里斯托弗·诺兰、莱昂纳多·迪卡普里奥、柯布关系：诺兰导演盗梦空间、莱昂纳多主演盗梦空间、莱昂纳多饰演柯布然后把这些实体和关系存储到图数据库中。
这里还有一个重要的概念，叫三元组，它啥意思呢？
就是用主体-关系-客体的方式描述一条知识，比如：
诺兰导:导演:盗梦空间莱昂纳多:主演:盗梦空间莱昂纳多:饰演:柯布每一条三元组，本质上就是知识图谱中的一条边，大量的三元组连接在一起，就形成了知识图谱。
- 检索阶段
当用户提问时，系统会先识别问题中的实体和意图，将用户的自然语言问题转化为结构化的图查询（如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大模型的正确顺序，千万不要搞错了
🤔2026年AI风口已来！各行各业的AI渗透肉眼可见，超多公司要么转型做AI相关产品，要么高薪挖AI技术人才，机遇直接摆在眼前！
有往AI方向发展，或者本身有后端编程基础的朋友，直接冲AI大模型应用开发转岗超合适！
就算暂时不打算转岗，了解大模型、RAG、Prompt、Agent这些热门概念，能上手做简单项目，也绝对是求职加分王🔋
📝给大家整理了超全最新的AI大模型应用开发学习清单和资料，手把手帮你快速入门！👇👇
学习路线:
✅大模型基础认知—大模型核心原理、发展历程、主流模型（GPT、文心一言等）特点解析
✅核心技术模块—RAG检索增强生成、Prompt工程实战、Agent智能体开发逻辑
✅开发基础能力—Python进阶、API接口调用、大模型开发框架（LangChain等）实操
✅应用场景开发—智能问答系统、企业知识库、AIGC内容生成工具、行业定制化大模型应用
✅项目落地流程—需求拆解、技术选型、模型调优、测试上线、运维迭代
✅面试求职冲刺—岗位JD解析、简历AI项目包装、高频面试题汇总、模拟面经
以上6大模块，看似清晰好上手，实则每个部分都有扎实的核心内容需要吃透！
我把大模型的学习全流程已经整理📚好了！抓住AI时代风口，轻松解锁职业新可能，希望大家都能把握机遇，实现薪资/职业跃迁～
)