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这套方案目前实践下来仅适合个人知识库在企业知识库中运用还不完善。假如你从2026年开始学大模型按这个步骤走准能稳步进阶。接下来告诉你一条最快的邪修路线3个月即可成为模型大师薪资直接起飞。阶段1:大模型基础阶段2:RAG应用开发工程阶段3:大模型Agent应用架构阶段4:大模型微调与私有化部署配套文档资源全套AI 大模型 学习资料朋友们如果需要可以微信扫描下方二维码免费领取【保证100%免费】配套文档资源全套AI 大模型 学习资料朋友们如果需要可以微信扫描下方二维码免费领取【保证100%免费】