您已决定在应用程序、产品或业务中使用 。您已研究过嵌入和向量搜索如何以及为何能够解决问题或启用新功能。您已涉足近似最近邻算法和向量数据库这一热门新兴领域。 向量搜索 在将矢量搜索应用程序投入生产后，您几乎会立即遇到非常困难且可能意想不到的困难。本博客试图为您提供一些关于您的未来的知识、您将面临的问题以及您可能还不知道但需要问的问题。  1. 向量搜索≠向量数据库 向量搜索和所有相关的智能算法是任何试图利用向量的系统的核心智能。然而，要使其发挥最大作用并投入生产，所有相关的基础设施都是巨大的，而且很容易被低估。 。矢量搜索本身绝不是一个“简单”的问题（我们将在下面介绍许多困难的子问题），但矢量数据库需要解决的大量传统数据库问题肯定仍然是“困难的部分”。 我尽可能强调的是： 一个可用于生产的矢量数据库将解决比“矢量”问题多得多的“数据库”问题 数据库解决了一系列非常现实且经过深入研究的问题，包括原子性和事务、一致性、性能和查询优化、耐久性、备份、访问控制、多租户、扩展和分片等等。对于任何产品、业务或企业，矢量数据库都需要在所有这些维度上提供答案。 要非常小心自制的“向量搜索基础设施”。下载一个最先进的向量搜索库并开始使用近似最近邻算法来获得一个有趣的原型并不 。然而，继续沿着这条路走下去，就有可能意外地重新发明你自己的数据库。这可能是你想要有意识地做出的选择。 难  2. 向量的增量索引 由于大多数现代 ANN 向量搜索算法的性质，逐步更新向量索引是一项巨大的挑战。这是一个众所周知的“难题”。这里的问题是，这些索引是为快速查找而精心组织的，任何试图用新向量逐步更新它们的尝试都会迅速降低快速查找属性。因此，为了在添加向量时保持快速查找，需要定期从头开始重建这些索引。 任何希望持续传输新向量的应用程序，如果要求向量能够快速显示在索引中，并且查询保持快速，则需要对“增量索引”问题提供强有力的支持。这是您了解数据库的一个非常重要的领域，也是提出许多难题的好地方。 数据库可以采用多种潜在方法来帮助您解决此问题。对这些方法进行适当的调查将填满许多篇幅的博客文章。了解数据库方法的一些技术细节非常重要，因为它可能会给您的应用程序带来意想不到的权衡或后果。例如，如果数据库选择以某种频率进行完全重新索引，则可能会导致高 CPU 负载，从而定期影响查询延迟。 您应该了解您的应用程序对增量索引的需求，以及您所依赖的系统为您服务的功能。  3. 向量和元数据的数据延迟 每个应用程序都应该了解其对数据延迟的需求和容忍度。基于向量的索引至少按照其他数据库标准具有相对较高的索引成本。成本和数据延迟之间存在重大权衡。 在您“创建”向量后多久您需要它在索引中可搜索？如果很快，向量延迟是这些系统中的一个主要设计点。 这同样适用于系统的元数据。一般来说，元数据的改变相当常见（例如，更改用户是否在线），因此元数据过滤查询快速响应元数据的更新通常非常重要。以上面的例子为例，如果您的向量搜索返回最近离线的人的查询，那么它就毫无用处了！ 如果您需要将向量连续地传输到系统中，或者连续地更新这些向量的元数据，那么您将需要一个不同的底层数据库架构，而不是在您的用例中可以接受的，例如每天晚上重建完整索引以供第二天使用。  4. 元数据过滤 我要强烈强调这一点： 。 我认为在几乎所有情况下，如果底层向量搜索基础设施可以通过元数据过滤（或混合搜索）得到增强，产品体验将会更好 显示我可能喜欢的所有餐馆（矢量搜索），这些餐馆位于 10 英里以内，价格从低价到中等（元数据过滤器）。 此查询的第二部分是传统的类似 SQL 的 子句，与第一部分中的向量搜索结果相交。由于这些大型、相对静态、相对单一的向量索引的性质，很难有效地进行联合向量 + 元数据搜索。这是向量数据库需要为您解决的另一个众所周知的“难题”。 WHERE 数据库可以采用多种技术方法来为您解决这个问题。您可以“预过滤”，即先应用过滤器，然后进行向量查找。这种方法的缺点是无法有效利用预先构建的向量索引。您可以在完成完整的向量搜索后对结果进行“后过滤”。这种方法非常有效，除非您的过滤器非常有选择性，在这种情况下，您会花费大量时间寻找向量，然后由于它们不符合指定的条件而将其丢弃。有时，就像在 Rockset 中一样，您可以进行“单阶段”过滤，即尝试将元数据过滤阶段与向量查找阶段合并，以保留两全其美的方式。 如果您认为元数据过滤对您的应用程序至关重要（我上面假设它几乎总是如此），那么元数据过滤的权衡和功能将成为您想要仔细检查的东西。  5. 元数据查询语言 如果我是对的，并且元数据过滤对于你正在构建的应用程序至关重要，那么恭喜你，你又遇到了一个问题。你需要一种方法来指定针对此元数据的过滤器。这是一种查询语言。 从数据库的角度来看，由于这是 Rockset 博客，您可能已经猜到我要说什么了。SQL 是表达此类语句的行业标准方式。矢量语言中的“元数据过滤器”只是传统数据库的“  子句”。它的优点是在不同系统之间移植也相对容易。 WHERE 此外，这些过滤器是查询，而查询可以进行优化。查询优化器的复杂程度会对查询的性能产生巨大影响。例如，复杂的优化器将尝试首先应用最具选择性的元数据过滤器，因为这将最大限度地减少过滤后期阶段所需的工作，从而带来巨大的性能提升。 如果您计划使用向量搜索和元数据过滤器编写非平凡应用程序，那么理解并熟悉您要使用、编写和维护的查询语言（包括人体工程学和实现）非常重要。  6. 媒介生命周期管理 好吧，您已经做到了这一步。您拥有一个矢量数据库，它具有您所需的所有正确的数据库基础知识、适合您用例的正确增量索引策略、关于元数据过滤需求的良好描述，并且将以您可以容忍的延迟保持其索引最新。太棒了。 您的 ML 团队（或许是 OpenAI）推出了其嵌入模型的新版本。您有一个巨大的数据库，里面充满了现在需要更新的旧向量。现在该怎么办？您要在哪里运行这个大型批量 ML 作业？您要如何存储中间结果？您要如何切换到新版本？您打算如何以不影响生产工作量的方式做到这一点？ 提出尖锐问题 是一个快速发展的领域，我们看到很多用户开始将应用程序投入生产。我写这篇文章的目的是让你了解一些你可能还不知道要问的关键难题。如果你能早日得到这些问题的答案，你将受益匪浅。 矢量搜索 在这篇文章中，我没有介绍 Rockset 如何解决所有这些问题，以及为什么我们的一些解决方案具有开创性，并且比其他大多数最先进的解决方案更好。介绍这些内容需要很多篇幅的博客文章，我认为这正是我们要做的。请继续关注。

Walkthroughs, tutorials, guides, and tips. This story will teach you how to do something new or how to do something better.

Build data apps here

該音頻是用故事的原始語言製作的！

向量搜索产品化的 6 个关键挑战

About Author

註釋

標籤

这篇文章刊登在

Related Stories

架构师指南：构建 AI/ML 数据湖参考架构

创建以用户为中心的加密产品：客户反馈的重要性

加密货币增长：创建有效的用户角色

看不见的层面：为什么用户访谈是不可替代的资产

架构师指南：构建 AI/ML 数据湖参考架构

创建以用户为中心的加密产品：客户反馈的重要性

加密货币增长：创建有效的用户角色

看不见的层面：为什么用户访谈是不可替代的资产

Light-Mode

Classic

Newspaper

Minty

Dark-Mode

Neon Noir

Minty

HN StartUps