构建搜索引擎，而非向量数据库（Vector DB） [译]

阅读目录

向量数据库不等于存储器
好消息
附言（不太好的消息）

在过去 12 个月中，我们见证了向量数据库（Vector DB）创业公司的迅猛增长。我此刻并不打算深入探讨它们各自的设计取舍。相反，我更想探讨和解释一些关于向量数据库的常见理解——它是什么、它的功能用途，以及在解决问题时，我们应如何恰当地利用向量数据库。

向量数据库不等于存储器

很多向量数据库的主要作用被描述为解决大语言模型 (LLM) 缺乏长期记忆的问题，或者无法将一个问题的全部上下文放入提示语中。

https://trychroma.com/blog/seed

然而，向量搜索实质上只是搜索的一种特殊形式。虽然让大语言模型 (LLM) 能够写入和检索数据库非常有用，但最终这更像是提供给智能体一个搜索引擎的权限，而非真正“增加了存储空间”。

假设你是一家企业，想要建立一个由 LLM 驱动的文档查询体验。如果你将向量数据库仅看作是为语言模型提供更多存储空间，那么你可能会把公司的所有产品文档都嵌入其中，然后让用户向你的机器人提问。用户按下回车键时，系统会对他们的查询进行向量搜索，找到相关片段，加载到上下文中，然后让语言模型尝试回答问题。实际上，这正是我在 Stripe 工作时，开发他们的 AI 文档产品时最初尝试的方法。

但我最终发现，这种方法并不理想。关键在于，尽管向量搜索在某些方面优于传统搜索，但它并非万能。就像常规搜索一样，你可能会在搜索结果中遇到不相关或遗漏的文档。语言模型，就像人类一样，只能利用它们所拥有的信息，而这些不相关的文档很可能会导致误导。

如果你想打造一个优秀的基于文档的 RAG 工具，你首先应该构建一个足够优秀的搜索引擎，让人类也能轻松使用。这可能是你们组织之前已经考虑过的，如果尚未实现，那是因为打造一个高效的搜索引擎通常是一项颇具挑战的工作。

好消息

当你坐下来打算构建一个高效的搜索系统时，你该如何下手呢？在这个问题上，大语言模型 (LLM) 可以成为你的救星。

虽然嵌入技术 (Embeddings) 并非灵丹妙药，但它们的确令人惊叹。相比于关键词搜索，高质量的嵌入式搜索能显著降低假阴性的比率。而将嵌入式搜索与关键词搜索结合使用，其性能远胜于任何纯文本搜索。事实上，谷歌多年来一直在这方面利用 [BERT](https://blog.google/products/search/search-language-understanding

-bert/?ref=blog.elicit.com) 技术。此外，嵌入技术本身及其在大规模搜索中的应用工具已经得到了巨大的改进。市面上有许多经过实战检验的数据库能够结合关键词和向量搜索，我强烈建议使用这些数据库之一（例如在 Elicit 我们使用 Vespa，而像 Chroma 这样的向量数据库现在通常也支持这一功能）。

在将嵌入技术与传统方法结合以改善整体搜索之后，你将迎来一些真正有趣的挑战。一个精于搜索技巧的用户知道如何构造查询以确保找到相关信息（曾有一时期，Google-fu（高效使用谷歌的技巧）被视为一种强大的技艺），语言模型也能做到这一点。例如，如果你的模型想寻找“疟疾疫苗最新动态”，你可以让它构建一个包含日期过滤器的查询语句。这里充满了尚未开发的潜力，而且在此基础上，通过无穷无尽的微调，可以实现令人惊叹的高质量搜索。就像在其他许多情况下一样，虽然在大语言模型出现之前这些都是可能实现的，但它们需要大量的专业技能和努力。现在，你只需几小时的时间和一些计算资源，就能实现有竞争力的性能。

在传统搜索流程中，最后一个阶段通常是重新排序（re-ranking）。过去，要实现重新排序，我们需要基于用户在特定搜索结果页面的点击行为等信号训练一个相关性模型，然后用这个模型对首要结果进行排序。对于没有专门团队来构建搜索引擎的人来说，这是一个难以解决的问题。但现在，借助于语言模型（language models），你可以向模型提供查询与结果之

间的细节信息，从而获得一个相关性评分，这种评分甚至能超越大多数专业定制的系统。

归根结底，AI 的最新进展极大地简化了构建先进搜索引擎的过程，比起以往，所需的努力大幅减少。因此，投入时间和精力来认真打造高效的搜索引擎，所带来的回报是极其可观的。

如果你打算开发一个基于 RAG 的工具（RAG-based tool），那么首先需要着手构建搜索功能。