Qdrant

Qdrant 1.7.0 has just landed!

8.5内容质量

TL;DR · AI 摘要

Qdrant 1.7.0 新增稀疏向量支持和 Discovery API,提升向量搜索功能。

核心要点

  • Qdrant 1.7.0 支持稀疏向量,满足关键词搜索需求。
  • Discovery API 提供更精确的搜索参数控制。
  • 用户自定义分片和基于快照的分片迁移功能增强系统灵活性。

结构提纲

按章节快速跳转。

  1. Qdrant 1.7.0 发布,新增稀疏向量支持和 Discovery API 等功能。

  2. Qdrant 现在原生支持稀疏向量,满足关键词搜索需求。

  3. Discovery API 提供更精确的搜索参数控制,适用于受限搜索和探索场景。

  4. 用户可以决定哪些数据存储在哪个分片上,提升系统灵活性。

  5. 新增基于快照的分片迁移功能,便于在节点间移动分片。

思维导图

用一张图看清主题之间的关系。

查看大纲文本(无障碍 / 无 JS 友好)
  • Qdrant 1.7.0 新功能
    • 稀疏向量支持
      • 原生支持稀疏向量
      • 满足关键词搜索需求
    • Discovery API
      • 提供更精确的搜索参数控制
      • 适用于受限搜索和探索场景
    • 用户自定义分片
      • 用户可决定数据存储位置
    • 基于快照的分片迁移
      • 便于在节点间移动分片

金句 / Highlights

值得收藏与分享的关键句。

#Qdrant#向量搜索#AI#API
打开原文

Qdrant 1.7.0 已正式发布!

返回 Qdrant 文章

Kacper Łukawski

·

2023 年 12 月 10 日

欢迎期待已久的 Qdrant 1.7.0 版本发布!除了少量的微小修复和改进外,这个版本带来了一些令人兴奋的新功能!你最喜欢的向量搜索引擎的最新版本终于支持稀疏向量了。这是许多用户请求的功能,我们怎么能忽视呢?我们还决定继续探索向量相似性在搜索之外的应用。新的 Discovery API 覆盖了一些全新的使用场景。我们非常期待看到你们用它构建出什么!但这还不是全部!快来看看 Qdrant 1.7.0 中有哪些新功能!

  • 稀疏向量:你想要使用基于关键词的搜索吗?稀疏向量的支持终于来了!
  • Discovery API:一种全新的使用向量进行受限搜索和探索的方式。
  • 用户自定义分片:现在你可以决定哪些点应该存储在哪个分片上。
  • 基于快照的分片迁移:一种在节点之间迁移分片的新方法。

你觉得还有哪里不足吗?你的反馈推动着 Qdrant 的发展,所以请不要犹豫,加入我们的 Discord 社区,帮助我们打造最好的向量搜索引擎!

新功能

Qdrant 1.7.0 带来了许多新功能。让我们更详细地了解一下它们!

稀疏向量

传统的基于关键词的搜索机制通常依赖于 TF-IDF、BM25 或类似的方法。虽然这些技术在内部使用向量,但它们通常涉及稀疏向量表示。在这些方法中,向量主要由零组成,只有相对较少的非零值。这些稀疏向量理论上具有高维性,远远高于语义搜索中使用的密集向量。然而,由于大多数维度通常是零,我们以不同的方式存储它们,只保留非零维度。

到目前为止,Qdrant 无法原生处理稀疏向量。有些人尝试将它们转换为密集向量,但这并不是最佳解决方案或推荐的方法。我们甚至写过一篇关于构建混合搜索的文章,并鼓励你使用其他工具进行关键词查找。

从那时起,情况发生了变化,因为你们中有许多人希望有一个工具同时处理稀疏和密集向量。为了响应这一广泛的需求,我们现在推出了稀疏向量支持!

如果你是第一次接触稀疏向量,我们的《搜索简史》将解释稀疏向量和密集向量之间的区别。

查看稀疏向量文章和稀疏向量索引文档,以了解更多关于这个新索引对 Qdrant 用户意味着什么的信息。

发现 API 可以通过两种方式使用:一种是使用目标点,另一种是不使用目标点。第一种情况称为发现搜索,而第二种情况称为上下文搜索。

#### 发现搜索

发现搜索是一种使用目标点来查找集合中最相关点的操作,同时仅在首选区域中进行搜索。基本上,这是一种对搜索空间具有更多控制的搜索操作。

如需了解更多关于发现搜索的详细信息以及该操作的内部机制,请参考发现 API 文档。

#### 上下文搜索

上下文搜索的模式与发现搜索类似,但不使用目标点。相反,它使用上下文来引导 HNSW 图向首选区域导航。可以预期,在这种模式下,结果会更加多样化,而不是围绕一个点。上下文搜索可以作为那些希望采用更具探索性方法来导航向量空间的用户的解决方案。

用户自定义分片

Qdrant 的集合被划分为分片。一个分片是一个自包含的点存储,可以在节点之间移动。迄今为止,点是通过使用一致性哈希算法在分片之间进行分配的,这样分片管理的是互不重叠的点子集。后者仍然成立,但现在你可以定义自己的分片,并决定哪些点应该存储在哪个分片上。听起来很酷,对吧?但你为什么需要这样做呢?实际上,有多种场景可能需要使用自定义分片。例如,你可能希望将某些点存储在专用节点上,或者你可能希望将同一用户的数据存储在同一个分片上。

虽然现有的行为仍然是默认行为,但现在你可以在创建集合时定义分片。然后,你可以通过在插入操作中提供 shard_key 来将每个点分配到特定的分片上。此外,你还可以通过在搜索操作中提供 shard_key 参数,仅在选定的分片上进行搜索。

code
POST /collections/my_collection/points/search
{
"vector": [0.29, 0.81, 0.75, 0.11],
"shard_key": ["cats", "dogs"],
"limit": 10,
"with_payload": true,
}

如果你想了解更多关于用户自定义分片的信息,请参考分片文档。

基于快照的分片迁移

这是为分布式模式用户实现的一项更深入的技术改进,我们为分片迁移机制引入了新的选项。新方法基于分片的快照,该快照被传输到目标节点。

迁移分片对于集群的动态扩展是必要的。你的数据可以在节点之间迁移,而迁移的方式对于整个系统的性能至关重要。传统的 stream_records 方法(仍然是默认方法)在机器之间传输所有记录,并在目标节点上进行索引。在迁移分片的情况下,每次都需要重新创建 HNSW 索引。然而,随着新快照方法的引入,快照本身(包括所有数据和潜在的量化内容)被传输到目标节点。这个全面的快照包括整个索引,使目标节点能够无缝加载它,并立即开始处理请求,而无需重新创建索引。

在某些情况下,你可能更倾向于使用其中一种方法。请查看分片传输方法的文档,以获取更多详细信息和直接对比。目前,旧的 stream_records 方法仍然是默认方法,但未来我们可能会更改这一默认设置。

小幅改进

除了引入新功能外,Qdrant 1.7.0 还提升了性能并解决了各种小问题。以下是主要改进的概述:

  • 在高 CPU 系统上改进 HNSW 索引构建(PR#2869)。
  • 改进搜索尾部延迟:针对高 CPU 系统上进行大量并行搜索的优化,通过减少延迟直接提升用户体验。
  • 为地理地图负载添加索引:为地理地图负载添加索引可以显著提高搜索性能,尤其适用于涉及地理数据的应用。
  • 大型高负载集群上的共识稳定性:在大型高负载环境中增强共识的稳定性,对于确保系统的可靠性和可扩展性至关重要(PR#3013,PR#3026,PR#2942,PR#3103,PR#3054)。
  • 搜索的可配置超时:允许用户配置搜索的超时时间,提供更大的灵活性,并有助于在不同操作条件下优化系统性能(PR#2748,PR#2771)。

发布说明

如果你对更多细节感兴趣,可以查看我们的发布说明。请记住,Qdrant 是一个开源项目,欢迎你随时贡献!