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

深入了解 Dust 的向量堆栈改造：利用 Qdrant 扩展到 5,000+ 数据源

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

Dust 是一个面向 AI 原生公司的操作系统，使用户能够构建由操作和公司知识驱动的 AI Agent。随着业务的扩展，Dust 面临着一系列日益增长的技术难题。公司的核心产品使用户能够让 AI Agent 安全地访问内部和外部数据资源，从而增强工作流程并加快信息访问速度。然而，当其基础设施开始承受数千个数据源和日益增长的用户查询的压力时，这一使命遇到了瓶颈。

最初，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 的影响立竿见影。搜索延迟从数秒的平均值大幅缩短至亚秒级响应。曾经消耗超过 30GB RAM 的集合被优化到仅需四分之一的内存即可高效运行。转向内存中的量化向量，同时将原始向量保留在磁盘上作为备用，被证明是平衡性能和资源使用的完美混合模型。

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

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

经验教训和路线图

随着扩展，Dust 有了一个关键洞察：当用户知道涉及数据库时，他们倾向于提出更结构化的分析性问题——这些查询更适合 SQL 而不是向量搜索。这促使团队将 Qdrant 与文本到 SQL 系统配对，混合使用非结构化和结构化查询能力，以实现更通用的 Agent。

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

性能、可扩展性和架构灵活性的新层级

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