向量数据库在 RAG 中的作用

The purpose of vector databases in RAG

接下来一个很有意思的问题是：LLM 究竟是如何利用向量数据库的？

大家通常最容易困惑的地方是：

既然 LLM 训练完成后，已经有了一套用于生成文本的模型权重，那向量数据库到底是在哪个环节起作用的？

我们来搞清楚这个问题。

首先要明确的是，LLM 部署上线时，学到的是训练时喂给它的语料的一个静态版本。

举例来说，如果一个模型是基于截止到 2024 年 1 月 31 日的数据训练并部署的，而我们在训练完成一周后才使用它，那么它对这一周里发生的事情将一无所知。

每天都用新数据重新训练一个新模型（或者更新最新版本），既不现实，成本也划不来。事实上，LLM 的训练往往需要数周时间。

另外，如果我们把这个 LLM 开源出去，而其他人想在自己私有的数据集上使用它——这份数据显然没有出现在训练过程中，那该怎么办？

不出所料，LLM 对此同样一无所知。

但仔细想想，训练一个 LLM 让它知晓世界上的每一件事，真的是我们的目标吗？

完全不是！

这从来都不是我们的目标。

相反，我们真正想做的，是帮助 LLM 学会语言的整体结构，以及如何理解和生成语言。

所以，只要我们在一个足够庞大的训练语料上训练出这个模型，就可以期待它具备相当不错的语言理解和生成能力。

因此，如果我们能想出一种办法，让 LLM 在不重新训练的前提下，查阅它没见过的新信息，并将其用于文本生成，那就再好不过了！

一种办法是直接把这些信息放进提示词里。

但由于 LLM 通常对上下文窗口（也就是它能接受的单词/token 数量）有限制，额外提供的信息很可能会超出这个上限。

向量数据库正好能解决这个问题。

正如前面提到的，向量数据库以向量的形式存储信息，每个向量都捕捉了被编码文本片段的语义信息。

因此，我们可以用嵌入模型把手头的信息编码成向量，存入向量数据库中维护起来。

当 LLM 需要用到这些信息时，它可以用提示词对应的向量对向量数据库做近似相似度搜索，找出与输入查询向量相似的内容。

一旦检索到近似最近邻，我们就会取出这些向量所对应的上下文——这些内容是在向量数据库对数据建立索引时就已经存好的（这份原始数据以 payload 的形式存储，我们会在实现部分讲到）。

上述搜索过程检索出的上下文，与查询向量相似，而查询向量所代表的正是 LLM 关心的上下文或主题。

我们可以把这部分检索到的内容和用户实际输入的提示词一起，作为 LLM 的输入。

这样一来，LLM 就能在生成文本时轻松地把这些信息用上，因为相关细节现在已经出现在提示词里了。

现在我们已经理解了这么做的目的，接下来就深入技术细节。