SaaSベンダーのHubSpot社は、同社のセマンティック検索基盤が概念実証（PoC）から発展し、現在では38以上のチームが利用する社内サービスへ成長した経緯を紹介した。この基盤は、200億件を超えるベクトルを管理している。HubSpot社によると、このシステムは現在、AIエージェントやRAG（検索拡張生成）、コンタクト情報の重複排除などを支えている。また、AIエージェントの利用拡大に伴い、検索精度とレイテンシの重要性はこれまで以上に高まっているという。
HubSpot社のブログによると、「VaaS（Vector as a Service）」と呼ばれるこの基盤は、Qdrantの前段に配置されている。アクセス制御、埋め込み（embedding）生成、データバージョニング、フィードバック収集といった機能を提供する。HubSpot社はQdrantを採用した理由として、オンプレミス環境で運用できることに加え、名前付きベクトル（named vectors）やハイブリッド検索、マルチステージクエリ、重み付きリランキングといった機能をサポートしている点を挙げている。また、量子化（quantization）やオンディスクストレージなど、コストを抑えるための機能を備えていることも評価したという。
HubSpot社は、Qdrantを自社運用することで、社内のトレーシング基盤やコスト追跡、レート制限、スケーリング、セキュリティツールとの統合を実現しているという。また、顧客データに対する管理権限を維持できる点も、自社運用を選択した理由として挙げている。HubSpot社によると、現在のプラットフォームは200以上のインデックス、140超のクラスター、5つのリージョン、2つの環境にまたがって運用されており、書き込みトラフィックはピーク時に毎秒10万リクエストへ達するという。
HubSpot社のOleg Tereshin氏とXin Liu氏によると、初期の構成はHelmを用いて構築され、利用するチームも少数だった。しかし、運用規模の拡大に伴い、手作業による管理は次第に困難になっていったという。両氏によると、チームはその後、社内のKubernetes Operatorフレームワークへ移行した。HelmではAPI呼び出しができず、外部メトリクスを利用したオートスケーリングや、状態を考慮したより複雑なライフサイクル管理にも対応できなかったためである。
「手作業による運用は、規模の拡大に耐えられない。」 ── Tereshin氏、Xin Liu氏
この移行により、クラスター管理はHubSpot社が「Translator」と呼ぶ仕組みに集約された。Translatorは60秒ごとにシステムの理想状態と実際の状態を照合し、その差分を解消する役割を担う。同ブログによると、このアプローチにより、クラスターの作成・廃止、シャードの移動、レプリケーション障害からの復旧といった運用作業を自動化できるようになったほか、運用チームの負担軽減にもつながっているという。
同様の課題は、ほかのベクトル検索システムでも見られる。Qdrant社が公開している大規模運用ガイダンスでは、本番環境でレイテンシと精度を維持しながら数億規模のベクトル検索を運用するためのチューニング手法に重点を置いている。これは、スケールの課題が検索品質だけでなく、運用面にも大きく関わるというHubSpot社の主張を裏付けるものだ。
同様の教訓は、ほかの実務者からも報告されている。Pinecone社がLinkedInに投稿した事例でも、同様の知見が共有されている。同社はベクトル数を4,000万件から6億件へ拡大した経験をもとに、検索の再現率（recall）を高水準で維持すること、ストレージとコンピュートを分離すること、そして信頼性を機能の一部として扱うことの重要性を強調している。また、ベクトル検索の本番運用に関する別の事例では、バージョン管理されたインデックスの採用、フィルター条件を考慮した設計、再現率とレイテンシの継続的な監視が推奨されている。これらは、HubSpot社が直面した課題と共通する内容である。
「再現率（recall）こそ最重要だ。」 ── Pinecone社 LinkedIn投稿より
これらのテーマは、シャード配置のバランス調整、メモリスキューの回避、そして自動化を活用して運用作業を管理下に置くことへのHubSpot社の重視点と一致している。HubSpot社によると、一部のコレクションには数十億件規模のデータポイントが格納されている。そのため、わずか1つのシャードに負荷の偏りが生じるだけでも、実際には必要な段階に達していないにもかかわらず、クラスターのスケールアウトを余儀なくされる場合があるという。
HubSpot社によると、この移行によりクラスターの立ち上げ時間は従来の数時間から数分へと短縮された。また、待機用のスタンバイクラスターを維持する必要もなくなったという。さらに、同じ差分同期（リコンシリエーション）モデルが現在では水平スケーリング、シャードの再配置、レプリケーション障害からの復旧も担っている。これにより、需要の増加に伴ってシステム規模が拡大しても、プラットフォームをより効率的に運用できるようになったとしている。
こうした傾向は、ベクトル検索市場全体にも見られる。多くのチームが、高い性能を維持しながら検索基盤をできるだけシンプルにする取り組みを進めている。InfoQも最近、OpenSearch、PlanetScale、AlloyDBにおけるベクトル検索機能の拡張を取り上げている。これらの取り組みはいずれも同じ課題意識を反映している。開発者は、データの近くでセマンティック検索を実行しながら、コストとレイテンシを十分に制御できる環境を求めているのである。
HubSpot社にとって重要なのは、ベクトルが新しい技術であるという点ではない。むしろ、その周辺インフラが成熟したプラットフォームサービスとして機能しなければならなくなったことにある。同ブログは、検索基盤が複数のAIプロダクトの中核機能となった時点で、課題はデータベースそのものだけではなくなったことを示している。真に難しかったのは、需要の拡大が続くなかでもシステムの安定性を維持できるよう、十分な運用自動化の仕組みを構築することだったとHubSpot社は説明している。