我们最近在一个项目中使用了知识库技术，并通过与他人交流了解到大家对知识库的看法。我们发现大多数人都意识到通用大模型在特定领域知识和实时信息方面存在局限性。一些人知道可以用知识库解决专业领域的知识问题，用联网搜索解决实时信息问题。不过，在了解知识库的人群中，往往会过于乐观地高估知识库的实际能力。很多同学认为知识库能彻底解决很多问题，然而实际情况是，大多数相关项目要么因效果不尽如人意，要么因知识库建设和维护成本过高而夭折。为了让大家对知识库有更深入的理解，今天我们就来探讨下知识库背后的技术——RAG，它是什么又它为什么会诞生？它的能力和局限是什么？以及如何正确地评估和使用RAG技术！
背景
众所周知，大语言模型是通过海量文本数据训练出来的，训练结束后模型所掌握的知识就固化了，无法继续学习新知识。然而在实际应用中，我们常常需要模型能够获取最新数据，以及一些私有或特定领域的专业知识。这些信息有个共同特点：它们都不在模型的预训练数据中——简单来说，模型并不知道这些信息，所以也就无法回答相关的问题。怎么解决？答案是将这些私有信息作为参考资料（知识库）提供给大模型，让模型能够借助这些资料来回答问题，这就是RAG技术诞生的背景。
让我们用一个形象的例子来说明下这个问题。回想下正在上大学的你，老师给了你一堆资料，你之后要参加一场相关的考试。在这里你就是大模型，老师给的资料就是知识库，考试其实就是运用知识库去回答用户的问题。实际上，很多人在这里对知识库的使用产生了误解。你可能以为大模型会像学霸一样，彻夜苦读、消化这些资料，然后在回答问题时从容作答。但真实的RAG过程更像是一个不学无术的学渣，完全没有预习这些资料，只是带着它们去参加一场开卷考试。
让我们回想一下开卷考试的过程：当看到题目时，你会翻开课本，迅速查找相关章节。找到对应内容后，你会仔细阅读和理解这些材料，然后结合自己的理解写出答案。这个过程恰如大语言模型的工作方式——课本就是知识库，模型先从知识库中检索相关信息，再基于这些信息生成答案。
这个过程正是RAG的工作方式，RAG全程是Retrieval Augmented Generation（检索增强生成）。
- Retrieval (检索)： 检索是RAG中的第一个关键环节。它的主要任务是从知识库中找出与用户问题最相关的信息。这个过程类似于我们使用搜索引擎，输入关键词后获取相关结果。在技术实现上，通常会将文档转换为向量形式，然后使用向量相似度计算来找出最相关的内容。
- Augmented (增强)： 增强是RAG的核心理念，指的是用外部知识来增强模型的回答能力。这种增强不是对模型本身进行修改，而是在回答问题时为模型提供额外的上下文信息。这就像是为模型提供了一本随时可以翻阅的参考书，让它能够基于最新、最准确的信息来回答问题。
- Generation (生成)： 生成是RAG的最后一步，由大语言模型完成。模型会将用户的问题和检索到的相关信息结合起来，生成一个连贯、准确的回答。这个过程不是简单的信息复制粘贴，而是需要模型理解问题和上下文，并用自然的语言表达出来。
让我们再回到考试这个例子上，这里你最终能考出什么样的成绩，就取决于好几个因素了：
- 首先是题目的质量，即问题是否清晰明确，能帮助你在课本中快速定位到相关知识点。这就像在RAG中提问的质量直接影响检索效果。
- 其次是参考资料的质量，它需要包含完整准确的知识点，并且内容组织合理，方便快速查找。这就像RAG系统中的知识库质量，直接决定了最终的表现。
- 最后是你的理解和表达能力——即使找到了相关内容，能否准确理解并用自己的语言表达出来，这就像大语言模型的生成能力。
相信通过这个示例，你已经能大概了解到 RAG 的工作原理，以及它的一些优点和局限，接下来让我们从技术实现的角度看看RAG是如何实现的。
RAG的技术实现
在前面内容中，我们通过考试的类比深入理解了RAG的工作原理和各个环节。在实际构建RAG系统时，我们需要一些前置准备工作。就像开卷考试前老师会提供参考资料一样，我们需要将资料整理成大模型易于检索和理解的形式。具体来说，我们主要需要准备知识库并完成知识库的向量化。从知识库构建开始分析，RAG实现过程中最关键的环节就是对现有文档进行科学合理的处理。
知识库内容整理
知识库的内容整理是RAG系统实现的关键一步。在实际场景中，模型的上下文窗口是有限的，它无法一次性处理太长的文本。此外，将长文本整体作为检索单位，会导致检索效率低下且结果不够精准。因此，在开始构建RAG系统时，我们需要将收集到的Word或PDF等格式的文档资料进行合理的切分处理。通过切分，我们可以让大模型更高效地检索和理解这些知识。
文档切分（Chunking） 是将大型文档分割成较小文本片段的过程。切分的大小和方式直接影响系统性能：切分过大会降低检索精度并增加处理成本，切分过小则可能丢失上下文信息。经验表明，将文档切分为几百到几千字符的片段较为合适，这样的大小能够满足大多数问答场景的需求。文档切分的方式有很多中，这里简单介绍几个常见的切分方式
简单切分
最基础的切分策略是按固定字数（如500字）进行切分，这种方法优缺点很明显，有点就是简单粗暴，但缺点就是容易造成语义割裂。例如，一个重要的知识点正好被切分到两个片段中，这样在检索时就无法完整地获取该知识点的信息。 也有一些工程优化来减缓语义割裂的问题，这里简单介绍下：
段落优化： 即在切分过程中保持每个段落的完整性和语义连贯性，这意味着即使某个段落的长度超过了预设的字数限制，系统也会将整个段落作为一个完整的单位进行保留，而不是强行将其分割开来；
重叠切分： 在相邻片段之间保留一定重叠区域，通常是前后各保留一定数量的文字（如每个片段的开头包含上一个片段的末尾100字，结尾包含下一个片段的开头100字）。这种重叠切分策略能够有效减少信息损失，确保上下文的连贯性，并且在检索时能够捕获到跨片段的相关信息。当用户的查询涉及到片段边界的内容时，这种方法特别有效。
父子片段： 父子片段的思路是在进行基础切分的同时，为每个片段保留更大范围的上下文。例如，我们可以为每个500字的子片段创建一个包含前后1000字的父片段。这样在检索时，我们可以先通过子片段快速定位相关内容，然后使用父片段提供更完整的上下文信息。
语义切分
语义切分是一种更高级的切分方式，是指根据文本的语义完整性进行智能分割，从而更好地保持上下文的连贯性。在大模型诞生之前，这种切分方式实现成本很高，有了大模型后，我们可以借助大模型通过提示引导，让模型自动识别文档的语义结构并进行合理的切分。例如，模型可以根据标题层级、段落主题和语义完整性来确定切分点，确保每个切分后的文本片段都具有独立且完整的语义。这种方式的缺点就是实现成本高，但实打实能带来更好的效果。
QA对
实际上，效果最理想的内容形式是预先整理好的问答对（QA对）。这很容易理解：用户查询知识库的目的就是寻找特定问题的答案。如果我们能事先整理好用户最常见的问题及其答案，自然能提供最优质的服务。在知识库构建过程中，高质量的问答对能显著提升RAG系统的整体表现。不过，这种方式也有明显的缺点：需要投入大量人力来进行知识整理和持续维护。
检索及其优化
在文档整理完成后，我们还需要把它变成大模型可以快速检索的形式。就如同你在开卷考试中，你需要使用目录来检索你要的内容， 同样大模型也需要一些“目录”来检索数据。这里有传统技术比如倒排索引，像目前很多 AI 搜索引擎主力检索就是这种方式，简单讲就是通过关键词建立索引，将每个文档中的关键词映射到对应的文档位置。当用户查询时，系统会找出包含查询关键词的文档。虽然这种方式实现简单且计算高效，但它无法理解文本的语义，只能进行字面匹配。相比之下，现在向量检索则能更好地理解文本的语义关系，所以我们在知识库中向量检索的方式会用的更多一些。
向量数据库
让我们先来了解向量化（技术上称为embedding）。虽然其原理比较复杂，但可以简单理解为：向量化就是将文本的语义转换成高维的一个向量描述。当我们想比较两段文本是否表达相同的意思时，只需计算它们对应向量之间的数学相似度即可。上图示例中从视觉上可以看出king 和 man两个词比较接近，而 queen 和 woman 两个词比较接近。而更复杂的文本知识用了更高维度的向量而已，其原理是类似的。
向量数据库则负责存储这些文本块的向量。除了存储功能，它还提供强大的查询能力——可以快速计算查询文本的向量与库中所有向量的相似度，并返回最相似的几个结果。简单来说，当你输入一段查询文本时，向量数据库就能返回与之最相似的若干个文本块。这种方式能高效地找到与用户问题最相关的知识，从而帮助大模型生成更准确的答案。
重排序
实践表明，向量数据库虽然能通过语义相似度找出匹配的文本片段，但其排序结果有时并不够准确。因此，许多 RAG 的工程实现都引入了重排序（Reranking）机制。重排序在向量检索的基础上，利用更复杂的重排序模型对初步检索结果进行二次排序，获得更精确的排序结果。重排序过程通常会考虑多个因素，包括文本的相关性、关键词匹配度、文档的时效性等。通过这种方式，我们可以更好地确保检索结果的质量，为后续的生成环节提供更可靠的知识支持。一些实现中还会结合传统的检索方法（如关键词匹配）和向量检索的结果，以获得更全面的匹配效果。
增强生成
向量数据库检索出结果，并且重排序后，接下来我们需要将检索到的知识与用户的问题进行整合，让大模型基于这些上下文信息生成答案。实现这一步没啥大的技术门槛，只需要需要设计合适的提示词（Prompt），指导大模型如何处理和利用检索到的知识回答用户的问题即可。 在 prompt 设计过程中，可以注意以下这几个关键点：首先要明确说明问题的背景和上下文，帮助模型准确理解用户需求；其次，要设计合适的提示词引导模型充分利用检索到的知识，减少大模型使用内置知识从而产生过度自由发挥的现象；最后，提示词中可以包含明确的输出格式和质量要求，以确保生成的答案既准确又易懂。
小结
以上我们将整个 RAG 的实现步骤挨个介绍了下，整个流程也可以参考上图（修改自网图），从上图中可以看到，RAG的核心步骤可以分为以下几个主要环节，每个环节都扮演着重要的角色：
- 知识库内容整理： 通过简单切分（固定字数、段落优化、重叠切分、父子片段）或语义切分的方式，将文档合理分割成适合检索的片段。切分质量直接影响系统整体效果。
- 检索及优化： 采用向量数据库存储文本语义向量，实现高效的语义检索。通过重排序机制对检索结果进行优化，综合考虑相关性、匹配度等多个因素，提高检索精度。
- 增强生成： 设计合适的提示词，指导大模型利用检索到的知识生成准确的答案。这一步骤需要精心设计提示词模板，确保生成内容的质量和相关性。
这三个环节的有机结合，使RAG系统能够有效地将外部知识与大模型的能力相结合，为用户提供更准确、可靠的答案。每个环节都需要仔细调优，以达到最佳效果。
GraphRAG 简述
最后让我们简单介绍一个更为高级的知识图谱类 RAG——GraphRAG。当你深入理解了 RAG 的实现原理后，你可能会意识到一个关键问题：RAG 本质上是基于文本片段的，无论如何切分这些片段，它们始终只能代表局部信息，无法完整检索出全文的信息。举个简单的例子，如果你把一本小说作为知识库加载到智能体中，这个智能体可能对小说中的每个场景、每个细节都了如指掌，但对一些全局性问题却无法回答，比如"这本小说的主要故事线是什么？" 、“概述下主角的生平！” ……
为了解决这个问题，微软团队推出了GraphRAG技术，其提出了一种基于知识图谱的增强方案。它不仅存储文本片段，还会构建文档的知识图谱，捕捉文档中实体之间的关系和层次结构。这样，当用户提问时，系统就能通过图谱获取更完整的上下文信息，从而生成更全面和连贯的答案。
GraphRAG的核心优势在于它能够建立文档内容之间的语义关联，突破了单个文本片段检索的局限。通过构建知识图谱，系统可以追踪实体之间的复杂关系，理解文档的整体结构和层次关系，从而提供更智能和全面的问答能力。比如，当用户询问某个角色的发展轨迹时，GraphRAG可以通过图谱连接多个相关片段，构建出完整的故事线索。
虽然听起来似乎听牛x，但为什么大家没怎么见过实际应用场景？原因很简单，这项技术存在一些显著缺点，因此目前仍主要停留在理论研究阶段，具体的缺点如下：
- 构建成本高： 相比传统RAG，构建知识图谱需要更多的计算资源和时间。特别是在处理大规模文档时，图谱的构建和维护成本会显著增加。此外，普通RAG就已经面临着大量分散数据难以收集利用的问题，这个问题对GraphRAG的影响更大——构建一个不完整的知识图谱的价值十分有限。
- 实现复杂度高： 知识图谱的构建涉及实体识别、关系抽取等复杂的自然语言处理任务。这些任务在不同场景中往往需要根据具体的上下文进行定制化开发，这就需要专业的技术团队支持，而很多公司并不具备这样的能力。
- 使用成本高： 除了构建成本，GraphRAG在运行时也需要更多的计算资源。知识图谱的查询和遍历操作比简单的向量检索更耗时，这可能影响系统的响应速度，尤其是在高并发场景下。
- 适用场景受限： 对于许多常见的业务场景，GraphRAG的复杂性可能有点"杀鸡用牛刀"。尤其是在文档结构相对简单、实体关系不那么复杂的场景下，传统RAG就足以满足需求。
需要说明的是，本文提到的 GraphRAG 只是一种前沿技术探索，并非在推荐大家使用这种高级技术。我们应该根据实际业务场景和需求来选择合适的技术方案。在绝大多数情况下，合理使用传统 RAG 就能满足大部分业务需求，没必要为了追求技术的先进性而牺牲实用性和可维护性。
总结
最后总结一下，本文介绍了知识库背后的核心技术RAG及其基本实现流程。这包括三个关键步骤：知识库内容整理、语义检索和增强生成。通过本文的介绍，相信大家对RAG技术有了更深入的理解，也能从其技术原理中认识到它的能力与局限。 最后我们也简单介绍了GraphRAG这种高级方案，它通过知识图谱的方式解决了传统RAG在局部信息检索上的局限性，但也带来了更高的构建和使用成本。对于大多数实际应用场景，合理使用传统RAG就能满足需求，无需过度追求技术的前沿性。
最后我们来探讨一个问题，大语言模型的一个重要应用是信息检索。早期由于上下文窗口的限制，模型无法处理超长文本。RAG 技术的出现很好地解决了这个问题，通过基于用户意图的检索方式显著缩小了需要处理的文本范围。不过，随着技术的不断发展，各种大语言模型的上下文窗口在持续扩大。例如 GPT-4 和 DeepSeek 的 128K 上下文窗口在当前已显得落后，而 Google 的 Gemini 模型已经支持 1M（百万中文字符）的上下文长度。其技术团队也公开表示，1M的限制是其保持技术领先且考虑成本效益下的平衡点，实际上 gemini 在亿级的上下文在也有不错的效果。
所以问题就是：随着大语言模型的上下文窗口不断扩大，RAG及其相关技术是否仍有存在的必要？如果依然必要，这些技术未来又将如何发展？
