在过去的几个月里，“知识库”“RAG”“AI智能体”这些词频繁刷屏。
许多朋友有问过我：
“啥是知识库啊？”
“到底什么是RAG？和普通搜索有啥区别？”
“企业要做知识库，怎么落地？”
今天这篇文章，我会尽量用最简单的语言，帮你一次搞懂。
知识库是什么？
知识库这个词听起来是不是有点高大上？别急，我们一步一步拆解：
其实，知识库就由两部分组成：知识 + 库。
知识：本质上，就是对我们有用的数据和信息。
它可以是：
一段文字
一张表格数据
一条操作流程
只要它能帮你解决问题、回答疑问，这就是“知识”。
库：简单来说，就是存储这些知识的地方。
比如：
你随手拿起的一张纸
桌子上的一个文件夹
相册里的一张照片
就是用来“把知识存起来、随时找得到”。
所以，现实的“知识库”= 有用的数据 + 一个能存放这些数据的地方，当然之前我们应该没人这么叫过。
我们现在聊的“知识库”，道理相通，只不过是通过计算机技术，将“知识”进行系统化、结构化和信息化的管理：
系统化：把零散内容整理归类
结构化：定义清晰的索引和关联
信息化：可以让计算机高效检索和使用
说人话就是：把知识用电脑存起来，像这样。。。
因为计算机和互联网技术的加持，使得这些知识可以被快速的查找和传播
举些例子：
个人知识库：你的Notion里一份「工作流程手册」
企业知识库：售后部门整理的FAQ，各种内部系统的数据
AI知识库：用于支持Chatbot智能回答的资料
所以，“万物皆可知识库”，只要它满足两个条件：
内容对问题有帮助
能被计算机检索和调用
RAG：检索增强生成
RAG，全称Retrieval-Augmented Generation，中文叫「检索增强生成」。
你可以读 R-A-G 三个字母，国外直接喊他 /ræɡ/
什么？这是啥？说人话！
一句话解释：
把「搜索引擎」和「语言模型」拼在一起，先找到最靠谱的资料，再让模型用自然语言回答。
所以本身这个技术还是基于大语言模型的，目的是为了让模型回复更准确
为什么一定要用 RAG？
目前很多大模型的回答容易按照自己已有的知识进行回答，尤其是在企业内部，垂直领域的问答中，可以让 AI 从内部的非公开数据获得知识，结合性的回复问题。RAG能比较显著的提升：
准确性：基于真实资料进行回答
可追溯性：可以指出引用和出处，方便纠错
可扩展性：不需要进行模型训练
比如三国演义里有这么一段话：
“吾有西凉进贡之良马，名曰‘ 赤兔 ’，日行千里，今特献与将军。”吕布大喜
对比传统搜索：
传统搜索： 关键词匹配
如果使用关键字「赤兔」「吕布」都能搜索到，但是用「吕布的坐骑」却搜不出来，仅文本匹配就是关键词搜索的一些局限性
RAG：「语义」理解
即便没出现「坐骑」二字，也能识别「赤兔」就是马，属于坐骑，赠与也能识别「吕布」和「赤兔」的关系
注意这里的语义带引号，因为从表象上的理解背后其实是算法手段的计算结果而已。
RAG的工作原理
RAG的核心流程分4步：
分片切割
把大文档拆分成很多小块（比如几百字），避免语义断裂。
向量化
用Embedding模型把每个分片转换成一个高维向量（在“语义空间”里的位置）。
语义检索
将用户问题也转成向量，在语义空间里寻找“最接近”的分片。
生成回答
把检索到的内容+原问题交给大语言模型，生成自然语言回答。
举个例子：
你问：“吕布的兵器是什么？”
系统检索出包含“方天画戟”的段落，再让模型回答：“吕布使用的兵器是方天画戟。”
RAG里的小细节
文本分片：把大块内容切小块
比如像这样：
为什么要分片？因为目前语言模型一次处理不了太长的文本，分片能让数据变小，检索时也会更精准。
滑窗分割是一种比较常见，更智能的分片方法：
按照格式进行文本分段
滑窗会让每个分片之间有部分重叠，保证上下文完整，降低内容断句
举例：
原文：ABCDE 分片1：AB 分片2：BC 分片3：CD
这种滑窗的分割也有点像我们小时候用手比划一个小相机，拍风景，是一样一样的，我们手比划的那个相机就像这里的窗
但是这个分片的粒度和重叠比例非常重要：
粒度太小：检索时上下文不够
比如下面，单个分片虽然够精准，但是内容太少
粒度太大：上下文会变大，容易命中过多内容
比如下面这样的分片，搜索“李善德 任务”会把小说的序也召回
重叠太多：重复度高，影响检索效率
下面滑窗重叠很小，导致分片从1000 → 2.3w，对检索效率有很大影响
重叠太少：语义断裂
比如下面这样，第一个片段从任务戛然而止了…
所以滑窗分片看似简单，实际是RAG效果的第一道“功夫”。
知识切片其实不关注存储的格式，文档，表格，图片，音视频，万物皆可切切切！
什么，长安的荔枝?
饿。。。可以切，给你切个玻璃荔枝，有 AI 什么不可能！
向量化：把文本变成数学坐标
向量化是什么？
把一段文本用Embedding模型编码成一个多维数字向量，让计算机理解语义。
通俗理解：
就像你租了一个仓库，把“苹果”和“香蕉”放在一个都是水果角落，“猫”放在另一个都是动物的角落里，那边有狗，狼还有鸡。
就类似如下图这样
当然，本身向量化可不是这样简简单单的三维空间坐标系就能解决的，实际的向量化维度一般在 256~1536 之间，想象一下真实情况是你的知识会被放到一个 1000+ 维度的空间里。。。如果你看过诺兰的星际穿越，那应该会对高维度有比较清楚的理解。
向量化技术主要依赖的是Embedding模型，这类的模型很多，有收费的比如OpenAI，免费的比如BGE等，模型不同，效果差距可能很大，所以决定时你需要好好斟酌和对比一下。
语义检索：在向量空间里找最相似的片段
那到底 RAG 是怎么检索的？
很容易理解，既然Embedding模型能把知识进行编码，一样也能把你的问题同样向量化，然后在知识库向量里按相似度排序返回。
通俗理解：
还是上面的那个仓库，把问题像盲盒一样也放进这个仓库，如果他被放到水果那个角落，那么就说它类似一个水果，接着就会把它附近的水果一起拿出去。
可以参考上面的三维图思考一下，像这一片：
感觉是不是还挺简单？
别高兴的太早，其实真实用过 RAG 的都是容易尽兴而去，铩羽而归（这T.M.D搜索的是什么）
没事，夸大疗效这个太常见了，如果你在互联网大厂待过，你懂得！
就像程序员挂在嘴边的金句：没有什么技术是银弹！
咳咳，说了大话总得找补一下。
扯远了，拉回来。其实 RAG 本身只是一项技术，并不对结果负责，因为有太多的因素影响最终的结果召回
那么提高检索效果，常用方法有哪些？
优化知识库内容质量
使用固定模版（如FAQ格式、产品文档模板，技术文档模版等），确保一致性，便于机器处理。
定期对知识库进行质量检查和更新，避免过时信息以及知识劣化。
调整滑窗分片策略
更精确的划分（例如按语义划分，而非单纯的字符数）可以避免误差，确保召回的相关性。
在滑窗方式中，重叠窗口大小的选择也很重要，避免过度冗余。
这边就不举例了，可以参考上面的篇幅
多路召回
引入领域特定模型，例如对于不同的领域（如金融、医疗、技术），使用不同领域的检索模型进行多路召回，这样可以提升领域相关性。
强调合并时的权重策略，比如根据模型的召回效果给不同召回源加权。
比如下面这个例子，医疗诊断需要疾病信息和药物信息进行整合，通过双路整合后增加了信息的召唤率。
对于冠心病
我们可以把这些数据向量化到一个二维和三维坐标系里，更能直观的看到，查询和检索结果的关系
嵌入模型多样化
不同的Embedding模型（例如，OpenAI、BGE、LLaMA）会在不同的文本和语境下表现不同，可以利用这些差异进行多角度对比，甚至融合一起召回，再由 AI 整理提取。
比如下面对比了2个模型的召回差异，可以看到智源的BGE在中文的识别能力更强大
知识图谱
构建知识图谱：根据知识构建实体关系图，帮助模型理解隐含关联，提升回答的精确度。
补充背景知识：将一些背景知识（如历史事件、人物关系，知识点来源等）通过图谱与现有文本内容关联，提升深度推理能力。
比如这个例子，下面是长安的荔枝的简单任务关系图：
如果此时有个问题：
李善德与何有光有什么矛盾？
##Embedding召回结果* 李善德和郑平安在荔枝运输途中成为盟友。* 十七娘原本是李善德的债主，后逐渐变成朋友。* 何有光是右相的重要代理人，控制长安城的货运。##识别到实体：{'右相', '郑平安', '李善德', '何有光'}##图谱扩展召回结果* 郑平安是左相派安插在岭南的卧底。* 左相与右相是政敌，长期争权。##图谱扩展实体：{'右相', '郑平安', '左相', '李善德', '何有光'}
上下文增强
在多轮对话中，有效地存储和利用历史对话数据，以增强对话的连贯性和相关性
举个简单的例子：
之前的问题1. 这款iphone15有几个颜色？2. 128G和256G的差价是多少？ 当前问题： 它支持双卡吗？# 如果没有召回之前的2个提问，那这个新问题将缺失主语# 大模型很容易会提问用户手机型号或者给出市面上双卡手机的介绍。
10. 总结
好了，现在我们知道了，知识库和RAG本身是两个东西，他们不是“高高在上”的技术，它的本质就是：数据治理、语义检索、再叠加智能生成。
RAG是应用在现在的AI大模型上的新技术，但是想要应用好其实还有上面非常多的知识点要一一优化才可以的，篇幅的关系，我们还没聊到之前的Coze dify FastGPT 甚至 RAGFlow 这些又是什么，下期吧，好饭不怕晚。
