详细内容或原文请订阅后点击阅览
何时（不）使用矢量数据库
当索引弊大于利时：我们如何认识到我们的 RAG 用例需要键值存储，而不是向量数据库何时（不）使用向量数据库一文首先出现在走向数据科学上。
来源:走向数据科学。它们解决了实际问题，并且在许多情况下，它们是 RAG 系统的正确选择。但事情是这样的：仅仅因为您使用嵌入并不意味着您需要矢量数据库。
我们看到了一种日益增长的趋势，即每个 RAG 实施都是从插入矢量 DB 开始的。这对于大规模、持久的知识库可能有意义，但它并不总是最有效的路径，特别是当您的用例更加动态或对时间敏感时。
在普朗克，我们利用嵌入来增强基于 LLM 的系统。然而，在我们的一个实际应用程序中，我们选择避免使用矢量数据库，而是使用简单的键值存储，结果证明这是更合适的。
在深入探讨之前，让我们先探索一个简单、通用的场景版本来解释原因。
Foo 示例
让我们想象一个简单的 RAG 风格的系统。用户上传一些文本文件，可能是一些报告或会议记录。我们将这些文件分成块，为每个块生成嵌入，并使用这些嵌入来回答问题。用户在接下来的几分钟内问了一些问题，然后离开。那时，文件及其嵌入都毫无用处，可以安全地丢弃。
换句话说，数据是短暂的，用户只会问几个问题，我们希望尽快回答它们。
现在暂停一下并问自己：
我应该在哪里存储这些嵌入？
大多数人的本能是：“我有嵌入，所以我需要一个向量数据库”，但请暂停一下，思考一下该抽象背后实际发生的情况。当您将嵌入发送到矢量数据库时，它不仅仅是“存储”它们。它构建了一个索引来加速相似性搜索。索引工作是很多魔力的来源，也是很多成本的来源。
所以真正的问题不是“我应该使用矢量数据库吗？”但是“索引工作值得吗？”为了回答这个问题，我们可以看一个简单的基准测试。