Dust 如何利用 Qdrant 扩展到 5,000 多个数据源

Dust 向量栈的彻底检修：利用 Qdrant 扩展到 5,000 多个数据源

挑战：为数千个数据源扩展 AI 基础设施

Dust 是一家为 AI 原生公司提供操作系统的公司，帮助用户构建由行动和公司知识驱动的 AI 代理。随着其业务规模的扩大，Dust 面临一系列日益增长的技术障碍。该公司的核心产品使用户能够为 AI 代理提供对内部和外部数据资源的安全访问，从而增强工作流程并加快信息访问速度。然而，当其基础设施开始在数千个数据源和日益增长的用户查询的重压下不堪重负时，这项任务遇到了瓶颈。

最初，Dust 采用为每个数据源创建单独向量集合的策略，但这很快变得不可持续。随着数据源数量激增至 5,000 多个，平台开始出现严重的性能下降。RAM 消耗飙升，向量搜索性能急剧下降，尤其是当内存映射向量溢出到磁盘存储时。一度，他们同时管理着近千个集合，并在单个周期内处理超过一百万次向量插入和删除操作。

评估和选择：Dust 为何选择 Qdrant

Dust 团队研究了几种流行的向量数据库。尽管每种数据库都有其优点，但没有一种能够满足 Dust 日益复杂的全部需求。一些提供商的开发人员体验与他们的工作流程不符，而另一些则缺乏所需的部署灵活性。Dust 需要一种能够处理大规模多租户、嵌入模型灵活性、高效内存使用和深度可配置性的解决方案。

Qdrant 凭借其开源 Rust 基础脱颖而出，赋予 Dust 对内存、性能和定制所需的控制。其直观的 API 和强大的开发人员社区也使集成体验更加无缝。至关重要的是，Qdrant 的设计允许 Dust 整合其分散的架构——用几个由强大的分片和有效负载过滤驱动的共享多租户集合取代了数千个单独的集合。

实施亮点：Qdrant 的高级架构

Dust 采用的最具影响力的功能之一是标量量化。这使向量存储大小减少了四倍，使团队能够将数据保存在内存中，而不是回退到较慢的磁盘存储。仅此一项转变就带来了显著的延迟改进。以前在大型集合中需要 5 到 10 秒的查询，现在可以在一秒内返回。即使在拥有超过一百万个向量和大量有效负载的集合中，搜索响应也始终远低于一秒。

Dust 还构建了一个自定义的 DustQdrantClient 来管理所有与向量相关的操作。该客户端抽象了集群版本、嵌入模型和分片逻辑之间的差异，从而简化了持续开发。他们的基础设施在 Google Cloud Platform 中运行，Qdrant 部署在独立的 VPC 中，这些 VPC 使用安全身份验证与 Dust 的核心 API 通信。该架构在美国和欧盟两个主要区域进行复制，确保高可用性和符合数据驻留法律。

成果：更快的性能、更低的成本、更好的用户体验

Qdrant 的影响立竿见影。搜索延迟从几秒的平均值缩短到亚秒级的响应速度。曾经消耗超过 30 GB RAM 的集合被优化为以其四分之一的大小高效运行。将量化向量移入内存，同时将原始向量保留在磁盘上以备回退，事实证明是平衡性能和资源使用的完美混合模型。

这些后端改进直接转化为面向用户的收益。Dust 的 AI 代理变得响应更快，更可靠。即使客户加载更大更复杂的数据集，系统也能持续提供一致的性能。该平台在不降低用户体验的情况下进行扩展的能力标志着一个转折点，使 Dust 能够自信地扩大其客户群。

转向多嵌入模型架构也带来了回报。通过按嵌入器对数据源进行分组，Dust 实现了更平滑的迁移和更高效的模型实验。Qdrant 的灵活性使他们能够发展其架构，而无需重新索引大量数据集或中断最终用户功能。

经验教训和路线图

随着规模的扩大，Dust 发现了一个关键的见解：用户在知道涉及数据库时倾向于提出更结构化、分析性的问题——这些查询更适合 SQL 而不是向量搜索。这促使团队将 Qdrant 与文本到 SQL 系统配对，将非结构化和结构化查询功能融合，以实现更通用的代理。

展望未来，Qdrant 仍然是 Dust 产品路线图的基石。他们正在构建多区域分片以实现更细粒度的数据驻留，垂直和水平扩展其集群，并支持来自 OpenAI 和 Mistral 等提供商的更新的嵌入模型。未来的集合将按嵌入器组织，并针对每个用例定制租户感知分片和索引优化。

性能、可扩展性和架构灵活性的新高度

通过采用 Qdrant，Dust 开启了性能、可扩展性和架构灵活性的新高度。他们的平台现在能够支持数百万个向量，在不同区域高效运行，并提供低延迟搜索，即使在企业规模下也是如此。对于构建复杂 AI 代理的团队来说，Qdrant 不仅仅提供了一个向量数据库，更是自信成长的基础设施支柱。