欢迎期待已久的 Qdrant 1.7.0 版本。除了少数小修补和改进之外，本次版本还带来了一些令人兴奋的全新功能！您喜爱的向量搜索引擎的最新版本终于支持 稀疏向量。这是许多用户要求的功能，我们怎能忽视？我们还决定继续探索 超越搜索的向量相似度。全新的 Discovery API 涵盖了一些全新的用例。我们非常期待看到您将用它构建出什么！但这还不是全部！来看看 Qdrant 1.7.0 的新功能吧！
- 稀疏向量：您想使用基于关键词的搜索吗？对稀疏向量的支持终于来了！
- Discovery API：一种全新的方式，用于向量的限制性搜索和探索。
- 用户定义的分片：您现在可以决定哪些点应该存储在哪个分片上。
- 基于快照的分片传输：在节点之间移动分片的新选项。
您觉得还缺少什么吗？您的反馈推动着 Qdrant 的发展，所以请随时 加入我们的 Discord 社区，帮助我们构建最优秀的向量搜索引擎！
新功能
Qdrant 1.7.0 带来了许多新功能。让我们仔细看看吧！
稀疏向量
传统的基于关键词的搜索机制通常依赖于 TF-IDF、BM25 或类似算法。尽管这些技术在内部利用了向量，但它们通常涉及稀疏向量表示。在这些方法中， 向量主要由零填充，只包含相对少量的非零值。这些稀疏向量在理论上是高维度的，远高于语义搜索中使用的密集向量。然而，由于绝大多数维度通常为零，我们采用不同的存储方式，只保留非零维度。
直到现在，Qdrant 还不能原生处理稀疏向量。一些用户曾尝试将它们转换为密集向量，但这并非最佳解决方案，也不是推荐的方法。我们甚至写了一篇关于 构建混合搜索的思考 的文章，并鼓励您使用不同的工具进行关键词查找。
自那时以来，情况发生了变化，因为许多用户希望有一个可以同时处理稀疏向量和密集向量的工具。为了响应这一 普遍的 需求，我们现在引入了稀疏向量！
如果您是第一次接触稀疏向量这个主题，我们的 搜索简史 解释了稀疏向量和密集向量之间的区别。
请查阅 稀疏向量文章 和 稀疏向量索引文档，了解更多关于这个新索引对 Qdrant 用户意味着什么。
Discovery API
最近发布的 Discovery API 扩展了利用向量的场景范围。虽然其界面与 Recommendation API 相似，但它更侧重于优化搜索参数以提高精度。“上下文”（context）的概念是指一组正负向量对，它们定义了空间中的区域。每对向量有效地将空间划分为正向或负向的区域。这个概念指导搜索操作，根据点包含在正向区域内或避开负向区域来确定优先级。本质上，搜索算法偏爱落在多个正向区域内或避开负向区域的点。
Discovery API 可以通过两种方式使用——带或不带目标点。第一种情况称为 发现搜索，而第二种情况称为 上下文搜索。
发现搜索
发现搜索 是一种操作，它使用目标点在集合中查找最相关的点，同时仅在首选区域内执行搜索。这基本上是一个对搜索空间有更多控制的搜索操作。
请参阅 Discovery API 关于发现搜索的文档，了解更多详细信息以及该操作的内部机制。
上下文搜索
上下文搜索 模式与发现搜索类似，但不使用目标点。相反，使用 context 来导航 HNSW 图，朝着首选区域移动。在这种模式下，结果预计会多样化，而不是围绕一个点集中。上下文搜索 可以作为寻求更具探索性方法来导航向量空间的用户的解决方案。
用户定义的分片
Qdrant 的集合被划分为分片。一个单独的 分片 是一个独立的点存储单元，可以在节点之间移动。到目前为止，点通过一致性哈希算法分布在分片中，以便分片管理非交叉的点子集。后者仍然如此，但现在您可以定义自己的分片规则，并决定哪些点应该存储在哪个分片上。听起来不错，对吧？但您为什么需要这个呢？嗯，有很多场景下您可能希望使用自定义分片。例如，您可能希望将某些点存储在专用节点上，或者您可能希望将来自同一用户的点存储在同一分片上，以及
虽然现有行为仍然是默认行为，但您现在可以在创建集合时定义分片。然后，您可以通过在 upsert 操作中提供 shard_key 将每个点分配到一个分片。更重要的是，您还可以通过在搜索操作中提供 shard_key 参数，仅搜索选定的分片。
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 索引。然而，随着新的 snapshot 方法的引入，快照本身（包括所有数据和潜在的量化内容）被传输到目标节点。这个完整的快照包括整个索引，使目标节点能够无缝加载并迅速开始处理请求，而无需重新创建索引。
在许多场景下，您可能会偏好其中一种方法。请查阅 分片传输方法 的文档，了解更多详细信息和对比。目前，旧的 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)。