构建搜索引擎，而不是向量数据库

英文原文地址：Build a search engine, not a vector DB

构建搜索引擎，而不是矢量数据库

2023 年 12 月 19 日

在过去12个月里，向量数据库初创公司数量激增。我并不是来讨论其中任何一个的具体设计权衡。相反，我想回顾一下向量数据库是什么、它的用途以及如何使用它来解决问题的几种常见方法。

向量数据库不是内存

许多向量数据库将其基本用途定义为解决语言模型缺乏长期记忆的问题，或者解决您无法将问题的所有上下文放入提示中的问题。

然而，向量搜索最终只是一种特殊的搜索*。*为您的 LLM 提供对其可写入和搜索的数据库的访问权限非常有用，但最终最好的概念是为代理提供对搜索引擎的访问权限，而不是实际上"拥有更多内存"。

想象一下，您是一家想要构建由LLMs支持的文档体验的公司。如果您认为向量数据库只是为您的语言模型提供扩展的内存，那么您可能只需嵌入公司的所有产品文档，然后让用户向您的机器人提问。当用户按下回车键时，您会对他们的查询进行向量搜索，找到所有块，将它们加载到上下文中，然后让您的语言模型尝试回答问题。事实上，这就是我在 Stripe 开发他们的AI 文档产品时最初采用的方法。

但最终，我发现这种方法是死胡同。关键在于，虽然向量搜索在某些方面比传统搜索更好，但这并不神奇。就像常规搜索一样，您最终会在结果中得到不相关或丢失的文档。语言模型就像人类一样，只能使用他们拥有的东西，那些不相关的文档很可能会误导他们。

如果您想制作一个使用您的文档的优秀 RAG 工具，您应该首先为这些文档创建一个足以供人们自行使用的搜索引擎。这可能是您的组织之前考虑过的事情，如果它不存在，那是因为构建一个好的搜索引擎传统上是一项重大任务。

好消息

您已经坐下来决定建立良好的搜索，那么您实际上是如何做到的呢？事实证明，在这种情况下，LLMs实际上可以扭转局面。

尽管嵌入不是魔法棒，但仍然非常令人惊奇。高质量的嵌入搜索将比关键字搜索具有更低的误报率，并且将这两个结果结合起来比任何纯全文搜索的性能都要好得多（谷歌多年来一直在使用BERT来做到这一点）。然而，嵌入本身以及在大规模搜索中使用它们所需的工具都得到了突飞猛进的改进。有很多经过实战考验的数据库可以让您将关键字和向量搜索结合起来，我强烈建议使用其中之一（在 Elicit 中我们使用Vespa，但像 Chroma 这样的矢量数据库现在也通常支持这种方式）。

一旦您通过将嵌入与更传统的方法相结合来改进了整体搜索，您就会得到有趣的东西。一个精明的人试图通过搜索引擎查找信息，知道如何构建他们的查询，以确保他们找到相关信息（Google-fu 曾经是一种强大的艺术形式），语言模型也可以做到这一点。如果您的模型想要查找"有关疟疾疫苗的最新消息是什么"，您可以让语言模型构建一个包含日期过滤器的查询。这里有大量唾手可得的成果，之后可以进行几乎无穷无尽的调整，以产生令人难以置信的高质量搜索。与许多其他情况一样，在LLMs之前，类似的事情在世界上是可能的，但它们需要大量的专业技能和努力。现在，您只需花费几个小时的时间和一些计算即可获得具有竞争力的性能。

传统搜索流程的最后阶段是重新排名。过去的情况是，要进行重新排名，您需要根据信号训练相关性模型，例如用户在给定的搜索结果页面上单击哪些项目，然后使用该模型对热门结果进行排序。如果您不是一个围绕构建搜索引擎构建的整个团队，那么这不是一个可行的解决问题。现在，借助语言模型，您可以向模型提供有关查询：结果对的一些详细信息，并获得相关性分数，该分数将击败除最佳专用系统之外的所有系统。

最终，人工智能的最新进展使得构建尖端搜索变得更加容易，所需的工作量比以前少了几个数量级。正因为如此，坐下来认真建立良好的搜索的回报是非常高的。

如果您想构建基于 RAG 的工具，请首先构建搜索。

后记（坏消息）

您已经使用上述技术构建了一个不错的搜索引擎，现在是时候部署它了。不幸的是，语言模型无法让您避免构建搜索引擎的另一半：评估它。

具体来说，这意味着能够回答以下问题：

"什么时候进行搜索合适？"
"当您进行搜索时，您实际上想要查找什么内容？"
"该内容在您的结果中排名有多高？"

回答任何这些问题都需要构建评估和监控基础设施，您可以使用它来迭代搜索管道并了解您所做的更改是否有所改进。对于评估搜索引擎的后续内容，我推荐这一系列优秀的帖子。