虽然我们说大模型的特点之一是知识丰富，但这里的知识仅限于通用的知识，也就是网上能够很容易找到的知识。对于一些特定的知识，比如你所在业务领域的知识，它就一无所知了。个中缘由，不言而喻，大模型训练时，根本不可能拿到你们公司的数据。如果我打算为自己的业务开发一个聊天机器人，也就是说，让聊天机器人知道我的业务，该怎么办呢？抛开训练一个属于自己的大模型这种成本高昂的办法，常见的解决方案有两种：模型微调：使用业务信息对已经训练好的模型进行微调。RAG：在上下文中带有业务信息，让大模型据此进行整合。相比于模型微调，RAG 的方案成本要低一些，而且更加灵活，实现起来也更简单一些，所以，它也成为了现在解决这个问题的首选。这一讲，我们就来了解一下 RAG。
RAG
RAG 是 Retrieval-Augmented Generation 的缩写，也就是检索增强生成。这是什么意思呢？就是通过检索的方式，对要处理的内容进行增强之后再去生成。
我们把大模型应用和检索增强结合起来理解一下。大模型有很多不知道的东西，比如，我们的业务。怎么让大模型了解我们的业务呢？最简单的方式就是每次请求时，把业务相关的内容放在提示词里告诉大模型。
问题是，业务相关的内容从何而来？这就是我们要在本地检索的内容。换言之，所谓检索增强生成，就是我们在本地检索到相关的内容，把它增强到提示词里，然后再去做内容生成。
下面是一个 RAG 系统处理用户请求的极简流程示意图：
图片
- 用户发起请求
- 根据用户的问题在相关资料中进行查询
- 获取到资料中的相关内容
- 组成完整的提示词发给大模型
- 将大模型的回复发给用户
对比普通的聊天机器人，差别就是在这个过程中，要去到相关资料中进行查询，再将查询得到的相关信息和用户问题拼装成完整的提示词发给大模型。
有了对 RAG 流程的初步认识，接下来的问题就是，怎样到相关资料中查询。既然要查询，必然是有个地方能够存储这些资料的。对于程序员来说，最熟悉的存储方案一定是数据库。
对于大模型应用开发而言，我们要根据文本去找相关内容。在业务系统开发中，我们经常做的文本匹配是用 SQL 语句的 like。但是，这种匹配对于大模型应用而言，就显得非常单薄了，因为它只能进行“字面”意义上的匹配，无法进行“语义”层面的匹配。如果想进行“语义”的匹配该怎么做呢？这就轮到向量登场了。
向量和向量数据库
向量，我们说过，许多 AI 算法处理的都不是文字，而是向量。采用向量的方案，“语义”的匹配程度就转换成了向量之间的相似程度。计算向量相似度的算法有很多，比如，余弦相似度、内积、欧氏距离等等。
有了向量，当用户提出问题时，处理过程就变成了将问题转换为向量，然后计算向量之间的距离，找到与问题向量最接近的文档向量，从而实现“语义”的匹配。
在开源社区里，已经有很多人提供了这样的模型，我们需要做的就是把模型部署起来，然后，调用这个模型。当然，也有人把已经训练好的模型部署成一个服务，这样，我们就可以直接调用现成的服务。
OpenAI 就提供了一个专门负责将文本转换成向量的 API——Embeddings。
我们可以根据需要，选择自己部署模型，或是选择别人提供的服务。不同的 Embedding 模型之间的差异主要取决于训练样本，比如有的模型会在中文处理上表现得比较好。到这里，我们知道了可以用向量进行文本内容的匹配。但是，我们要到哪里去匹配呢？
正如我们处理任何业务数据一样，在使用数据之前，第一步需要做的是，存储业务数据。在 RAG 系统中，我们要把数据存放到哪里呢？我们需要一个数据库，只不过，我们需要的既不是 Oracle、MySQL 这样的关系数据库，也不是 MongoDB、Redis 这样的 NoSQL 数据库。因为我们后续处理的都是向量，所以，我们需要的是向量数据库。
向量数据库并不是突然冒出来的。2000 年左右，加州大学伯克利分校的研究人员开始尝试开发向量数据库，用来存储和查询高维向量。2010 年，VectorWise 公司发布了第一个商业向量数据库。随着 AI 应用的兴起，人们对于向量数据库的兴趣日渐浓厚。在大模型兴起之后，随着 RAG 的蓬勃发展，向量数据库一下子站到舞台中央，开始成为许多大模型应用的重要组件。
向量数据库与传统数据库有很大的差别，在使用方式上，传统数据库搜索信息倾向于精确匹配，而向量数据库的匹配则是语义上的接近。
在实现上二者也存在不小的差别，比如，由于向量本身通常维度会很多，如果按照传统数据库的方式直接进行存储，将会带来很多问题。向量数据库需要把向量数据作为一个完整的单元处理，底层存储结构也需要根据这个特点进行规划。另外，向量数据格式也相对单一，每个维度的数据往往都是固定的数据格式（浮点数、二进制整数等）。
所以，向量数据库就可以有针对性地找到一些优化手段，比如，相关的数学运算可以更好地利用 CPU 缓存机制加速，甚至可以利用 CPU/GPU 的硬件特性；再比如，采用高效的数据压缩技术，这样就能够显著地减少存储空间。
索引
到这里，我们讲的都是怎样使用数据，也就是检索的过程。其实，还有一个关键的问题没有解决，这些数据从何而来，怎么跑到向量数据库里去的。这就是 RAG 另外一个重要的过程：索引（Indexing）。
下面是一个常见的索引过程：
图片
在这个过程里面，我们会先对信息源做一次信息提取。信息源可能是各种文档，比如 Word 文档、PDF 文件，Web 页面，甚至是一些图片。从这些信息源中，我们把内容提取出来，也就是其中的文本。
接下来，我们会把这些文本进行拆分，将其拆分成更小的文本块。之所以要拆分，主要是原始的文本可能会比较大，这并不利于检索，还有一点重要原因是，我们前面说过，要把检索到的信息拼装到提示词里，过大的文本可能会造成提示词超过模型有限的上下文窗口。
再来，就是把文本块转换成向量，也就是得到 Embedding 的过程。前面我们说过，这个过程往往是通过训练好的模型来完成的。到这里，我们就把信息转换成了向量。最后一步，就是把得到的向量存储到向量数据库中，供后续的检索使用。
至此，我们对常见的 RAG 流程已经有了基本了解。但实际上，RAG 领域正处于一个快速发展的过程中，有很多相关技术也在不断地涌现：
虽然采用向量搜索对于语义理解很有帮助，但一些人名、缩写、特定 ID 之类的信息，却是传统搜索的强项，有人提出混合搜索的概念，将二者结合起来；
通过各种搜索方式，我们会得到很多的候选内容，但到底哪个与我们的问题更相关，有人引入了重排序（Rerank）模型，以此决定候选内容与查询问题的相关程度；
除了在已有方向的努力，甚至还有人提出了 RAG 的新方向。我们前面讨论的流程前提条件是把原始信息转换成了向量，但这本质上还是基于文本的，更适合回答一些事实性问题。它无法理解更复杂的关系，比如，我的朋友里谁在 AI 领域里工作。所以，有人提出了基于知识图谱的 RAG，知识图谱是一种结构化的语义知识库，特别适合找出信息之间的关联。
由此你可以看到，想要打造一个好的 RAG 应用并不是很容易的一件事，但在一些技术框架支持下，上手编写一个 RAG 应用却不是什么难事。
总结
RAG 是 Retrieval-Augmented Generation 的缩写，也就是检索增强生成的意思。它主要是为了解决大模型本身知识匮乏的问题。RAG 应用的主要流程包括索引、检索和生成。
目前常见的 RAG 技术是依赖于将文本转换成向量，以实现语义上的匹配。将文本转成向量，我们通常会使用专门的 Embedding 模型，而对向量进行检索，则使用向量数据库。索引就是把信息放到向量数据库中，而检索就是把信息提取出来，提取出来的信息与用户提示词合并起来，再到大模型去完成生成的过程。
如果今天的内容你只能记住一件事，那请记住，RAG 是为了让大模型知道更多的东西。