欢迎了解备受期待的 Qdrant 1.7.0 版本。除了少量问题修复和改进外，该版本还带来了我们非常乐于分享的几项炫酷新功能！你最喜爱的向量搜索引擎终于支持稀疏向量（sparse vectors）了。这是许多用户请求的功能，我们当然不会忽略！同时，我们决定继续深耕 向量相似度搜索之外的领域。全新的 Discovery API 涵盖了一些全新的应用场景，我们非常期待看到你用它构建出什么样的应用！不仅如此，快来看看 Qdrant 1.7.0 还有哪些新亮点！
- 稀疏向量：想使用基于关键词的搜索？对稀疏向量的支持终于到来了！
- Discovery API：一种全新的使用向量进行受限搜索和探索的方法。
- 用户定义分片（User-defined sharding）：现在你可以决定哪些数据点存储在哪个分片上。
- 基于快照的分片迁移：在节点间移动分片的一种新方式。
觉得还少了点什么？你的反馈推动着 Qdrant 的发展，所以请务必 加入我们的 Discord 社区，帮助我们将它打造为市面上最优秀的向量搜索引擎！
新功能
Qdrant 1.7.0 带来了许多新功能。让我们仔细看看！
稀疏向量
传统的关键词搜索机制通常依赖于 TF-IDF、BM25 或类似算法。虽然这些技术在内部使用了向量，但它们通常涉及稀疏向量表示。在这种方法中，向量大部分位置是零，只有极少数非零值。这些稀疏向量在理论上是高维的，肯定远高于语义搜索中使用的稠密向量。然而，由于大部分维度通常为零，我们采用不同的存储方式，仅保留非零维度的值。
在此之前，Qdrant 无法原生处理稀疏向量。有些人尝试将其转换为稠密向量，但这并不是最佳方案或推荐做法。我们甚至写过一篇关于 构建混合搜索的想法 的文章，鼓励大家使用其他工具进行关键词检索。
现在情况不同了，因为许多用户希望使用单一工具来处理稀疏向量和稠密向量。为了响应这一 热门 需求，我们现已引入稀疏向量支持！
如果你是第一次接触稀疏向量，我们的 搜索简史 文章解释了稀疏向量与稠密向量的区别。
请查阅 稀疏向量文章 和 稀疏向量索引文档，了解此新索引对 Qdrant 用户意味着什么。
Discovery API
近期推出的 Discovery API 扩展了向量利用的场景范围。虽然其接口类似于 推荐 API，但它专注于细化搜索参数以获得更高的精度。“上下文（context）”概念指一组正负对，它们定义了空间内的区域。每一对有效地将空间划分为正向或负向段。这一概念引导搜索操作根据点是否落在正向区域内或避开负向区域来确定优先级。本质上，搜索算法倾向于选择落在多个正向区域内或避开负向区域的点。
Discovery API 有两种使用方式——带目标点或不带目标点。前者称为 发现搜索（discovery search），后者称为 上下文搜索（context search）。
发现搜索
发现搜索 是一种使用目标点在集合中查找最相关点，同时仅在首选区域内进行搜索的操作。本质上，这是一种对搜索空间拥有更多控制权的搜索操作。
有关详细信息及操作的内部机制，请参阅 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)。