SaaS 软件供应商 HubSpot 详细介绍了其语义搜索平台如何从概念验证发展成为一项内部服务。目前，该服务管理着超过 38 个团队的 200 多亿个向量。该公司表示，该系统目前支持代理、RAG 以及联系人去重功能，而且随着代理使用量的增加，检索质量和延迟问题变得比以往更加重要。
HubSpot 网站上的这篇博文解释说，该平台名为 VaaS（向量即服务），位于 Qdrant 之前，提供访问控制、嵌入向量生成、数据版本控制和反馈收集等功能。HubSpot 表示，选择 Qdrant 是因为它支持本地部署，具备命名向量、混合搜索、多阶段查询和加权重新排序等功能，并提供包括量化处理和磁盘存储在内的成本控制措施。
HubSpot 还表示，该公司选择在内部运行 Qdrant，是因为这样既能与内部的追踪、成本监控、速率限制、扩展和安全工具集成，又能对客户数据保持控制权。该公司称，当前的平台涵盖 200 多个索引、140 多个集群、5 个区域和 2 个环境，峰值写入流量可达每秒 10 万次请求。
在该博文中，Oleg Tereshin 和 Xin Liu 写道，早期的架构是基于 Helm 构建的，而且消费者数量比较少，但随着集群规模的扩大，手动管理变得越来越困难。他们表示，团队转而采用内部的 Kubernetes Operator 框架，因为 Helm 无法进行 API 调用以及根据外部指标自动扩展，也无法处理更复杂的、具有状态感知能力的生命周期任务。
手动运维无法适应业务增长。
—— Oleg Tereshin 和 Xin Liu
这一举措将集群管理转移到了 HubSpot 所称的 Translators 上。该组件每 60 秒会将系统目标状态与实际状态进行一次同步。该文指出，如今这种方法已经实现了集群创建与退役、分片迁移以及复制恢复的自动化，减轻了团队的运维负担。
其他向量搜索系统也面临着同样的压力。Qdrant 自身的大规模指南侧重于对数亿个向量进行调优，同时将延迟和准确率保持在生产环境可接受的范围内，这印证了 HubSpot 的观点：规模化既关乎运营，也关乎检索质量。
其他从业者也得出了类似的经验教训。在 LinkedIn 上的一篇博文中，Pinecone 描述了向量规模从 4000 万跃升至 6 亿的过程，建议必须保持高召回率，将存储与计算分离，并将可靠性视为一项功能。而另一篇关于向量搜索的生产实践总结则建议采用版本化索引及过滤感知设计，并仔细监控召回率和延迟。
召回率至上。
——Pinecone 发表在 LinkedIn 的博文
这些主题与 HubSpot 所强调的平衡分片放置、避免内存偏斜以及利用自动化控制运维工具相契合。该公司表示，某些数据集包含数十亿个数据点，即使只有一个分片失衡，也可能迫使集群在真正需要之前就进行扩展。
HubSpot 还表示，这一转变将集群启动时间从数小时缩短至数分钟，并消除了对备用集群的需求。该公司补充道，如今，同一套对账模型可以同时处理水平扩展、分片再平衡和复制恢复，这使得平台在需求增长时更易于运维。
在向量搜索市场中，这种趋势广泛存在：各团队正越来越多地设法在不牺牲性能的前提下简化检索系统。InfoQ 最近报道了 OpenSearch、 PlanetScale 和 AlloyDB 在向量搜索方面的更新。这些更新都指向同一个需求：开发者希望在数据附近实现语义检索，并且能够拥有足够的控制权来调整成本和延迟。
对于 HubSpot 而言，关键不在于向量技术本身是个新事物，而在于其周边基础设施现在必须像一个成熟的平台服务那样运行。该文明确指出，一旦检索成为多种 AI 产品的核心，数据库本身就只是问题的一部分。更艰巨的任务是围绕它构建足够的自动化机制，确保在需求持续增长的情况下保持系统稳定。
原文链接：https://www.infoq.com/news/2026/07/hubspot-semantic-vector-search/
