VectorDB の 2024 年 12 月現在における各社のプロダクト展開についてまとめる。
筆頭に挙げられるのは Pinecone (pinecone.io) だ。2022/3 に Series A で $28M、さらにその約一年後の 2023/4 に Series B で $100M の資金調達をしている。ソースコードは公開されていないが、マネージドで使える VectorDB の代名詞ではないだろうか。内部ではk8s でマルチクラウド運用されており、インデックスは別の Pods に Replication されている。
主観だが、API が直感的で使いやすい。namespace を使うとレコードを Partitioning できるので、例えばリージョン別や言語別にインデックスを管理したりといったこともできる。各レコードには metadata を割り当てることができるので、例えばデータの属性やマシンタイプ別など柔軟なクエリが表現できる。metadata には配列も利用できるので、本のジャンルを複数検索といった要件も実現できる。
VectorDB の性能改善のために、特色のある機能や実装を積極的に公開している印象だ。例えば Single-Stage Filteringでは、単純な Pre-Filtering や Post-Filtering で問題になる計算量の増加もしくはクエリ結果の欠落性を克服している（と紹介されている）。Sparse-dense Vectors を利用することで、従来のキーワード検索の利点と Semantic Search の利点を組み合わせた検索を Pinecone のみで実現することができる。例えば E-Commerce において商品の検索をする際に、ユーザーの検索クエリとカテゴリーの画像を組み合わせることで、より的確な検索結果を返すことができる。
本番運用を想定した機能を実装しているのも開発者としては嬉しい。Prometheus から scrape できる機能を実装していたり、Datadog との Integration を公開している。ただし、現在はまだベクター数やクライアントからのリクエスト数、エラー数やレイテンシなど基本のメトリクスに過ぎない。インデックス側の内部の状況についてはあくまでブラックボックスだ。
Cloudflare Vectorize は 2023/09 にPublic Beta で公開 されたばかりのまだ若いプロダクトだ。ベータ版が外れるまでは試験運用に近いだろう。
API としては Pinecone を意識していそうだ。Partitioning のための namespace はもちろん、レコード単位での metadata による切り分けができる。Vector Similarity のアルゴリズムとしても、定番の三つ、Cosine / Euclidean / Dot-product が当たり前のように提供されている。
現時点ではまだベータ版なので、制約条件を確認してもそこまで意味ないだろうが、現時点で 100 インデックスまで生成することができ、1536 dimensions までサポートしており、ベクター数もインデックスあたり 200K まで追加できるので、検証をしたり、おもちゃを作ったりする程度には十分だろう。ちょうどこの記事を書いているタイミングで Metadata Filtering が使えるようになった。
個人的には、Cloudflare Workers AI と合わせて、中規模の LLM アプリケーションを実装する際の選択肢にはなってくるだろう。正直 Cloudflare Workers から Pinecone など他の VectorDB を使うのもたいして難しくないので、どう差別化していくかは気になるところである。エッジで動かすがゆえにネットワークのラウンドトリップは他の競合プロダクトより差別化できる要素であろうが、VectorDB においてはベクトル計算やデータの UPSERT 時のパフォーマンスの方がボトルネックになりうるので、エッジで走らせただけでは物足りない気もする。
Pinecone の対抗馬として OSS で名乗りを挙げているのが Chroma (trychroma.com) だ。現在 Seed round で 2023/04 に $18M を資金調達している。VectorDB ではなく "Embedding database" というマーケティングをしているが、実質似たようなユースケースをサポートしていると理解している。
現在はマネージドサービスを提供していないが、Waiting list を執筆時点で募っており、マネージドサービスの公開もそう遠くはないはずだ。Distributed Systems や Cloud Infrastructure の job role を募集しており、内部でも最優先で実装していることは想像に難くない（"Hosted Chroma" と呼ぶようだ）。Chrome 0.4 では Google PaLM や ChatGPT Retrieval Plugin のサポートを実装するなど、開発速度も注目に値する。ロードマップを見る限り CLI の拡張や可視化ツールなど、日常の開発業務を円滑にする周辺ツールをまだまだ拡充していく必要はありそうだ。
collections という概念でベクター値を扱う。Pinecone や Cloudflare Vectorize 同様、Vector Similarity は Cosine / Euclidean / Dot-product をサポート（といっても実際には numpy の wrapper に近い）。collections には embedding_functions を渡し、collections に doocuments が追加される度に embedding_functions を使ってトークナイズする。metadata も利用できるので、他社プロダクトと同様にクエリの際に任意の値でフィルタリングすることができる。Pinecone のように metadata のフィルタリングに配列は使える上に、AND / OR が使えるので、柔軟な検索クエリも表現できる。Multi-modal 対応の collections を用意することも可能だ。
プロダクトの完成度としては Pinecone に後塵を拝している感は否めない。クライアントも Python と JavaScript 以外の選択肢が増え、マネージドサービスも公開し、パフォーマンスも安定してくれば、OSS というブランディングも相まって、Pinecone の良い競争相手として進化してほしい。
Qdrant (qdrant.tech) も、Chroma 同様 OSS の VectorDB だが、Qdrant は Rust 実装である。Chroma 同様 2023/04 に Seed round で $7.5M を調達している。資金調達やプロダクトアウトについては Pinecone が先を進んでいる分、Rust 実装による単一ノードでのパフォーマンスへの期待感であったり Integration の選択肢であったりと、差別化を図っていく必要があるのだろう。すでに Qdrant Cloud を提供し、Free tier も存在する。
とはいえ、Pinecone のリーダーシップや、Cloudflare Vectorize の期待感、Chroma におけるコミュニティの強さのような差別化要因は今のところ見えていない。私のリサーチ不足か理解不足による可能性は大いにあるが、Rust で書いたからといって全てのワークロードで速くなるわけではない。公開されているベンチマーク結果も、ベンチマーク結果によってどうにでもなるし、そもそも Pinecone は比較対象に入っていない。
他にも例えば、トップページで Hierarchical Navigable Small World (HNSW) を実装したと謳っている。NSW とは、Small-world network におけるグラフ探索の最適化の手法であり、それを階層構造（= Hierarchical）に拡張したものが HNSW なのだが、C++ 実装は nmslib/hnswlib で Python binding とともに公開されている。実は先述の Chroma もフォークした実装 を利用しているので、HNSW 実装をしているというだけでは差別化にならない。
どちらかというと、単一ノードのパフォーマンスよりは、エンドユーザーのビジネス要件は多様だという前提を置いた上で、アプリケーションを実装するユーザーが柔軟にパフォーマンスチューニングできるための Observability の充足や開発環境の拡充、もしくはマネージドサービスで提供される高度な Scalability や安定した Availability の方が重要だと考えている。したがって、厳しい意見になるが「Rust 実装」という以外のウリを作っていく必要はあるだろう。
Weaviate (weaviate.io) も OSS の VectorDB なのだが、Chroma や Qdrant より先んじて Series A で $16M の調達を 2022/2 に、Series B で $50M の調達を 2023/4 に行っている。Series B での調達額は Pinecone の半分ではある。Go で実装されており、マネージドサービスの展開もすでに市場に投下済みである。SOC 2 の取得や OpenID Connect (OIDC) の対応など、エンタープライズに向けたセキュリティ周りの地盤固めも着実に行っている。
Pinecone でも実装されていた機能だが、従来のキーワード検索とベクター検索を掛け合わせた Hybrid search を Weaviate もすでに展開済みである。Multi-tenancy を API として実装している点も興味深い。同様のことは他の VectorDB でも Metadata や Namespaces といった機能を用いれば実現可能だが、ネイティブに実装してきているのは主張を感じる。Cross-references を利用して Collections 間を紐づけて扱うこともできる。Cross-references は、one-way / bi-directional / one-to-many すべての参照方法が設定可能だ。
本番運用を想定した機能も抜け目がない印象だ。ダウンタイム無し（と謳っている）の Backup 機能を使って Blob storage に保存できる。一番好きなドキュメントページは Horizontal Scaling だ。Sharding および Replication 戦略について詳解されている。これなら、明日から Weaviate のクラスターの本番運用を任されても、愚痴をこぼさずに取り組めそうだ。クラスター間の協調には Hashicorp が実装している Gossip-based の memberlist を利用している。
Vector Index の実装は Qdrant 同様に HNSW だ。キーワード検索のための転置インデックスには、定番の LSM-Tree を採用している。きっとデータベースを開発したことのある誰かが初期の開発チームにいるのだろう。ドキュメントを読んでいると、それをひしひしと感じる。特に興味深いのは、AWS DynamoDB のような Leaderless を選択している点だ。Single-leader でも Multi-leader でも無い。Leaderless の場合、一般に結果整合性で書き込み性能を向上させることができる。
以上 VectorDB を紹介してきたが、既存の RDBMS や GraphDB たちもこぞって Vector Search を実現できるプラグインや機能を実装してきている。VectorDB に黙って顧客を取られたらたまらない、というわけだ。Postgres は pgvector の OSS 実装がある。Neo4j も vector search index を実装した。MongoDB も Atlas Vector Search を実装してきている。
正直これがどの程度のものかは疑問に残る。各データベースの実装は、それぞれ得意なことに注力できるように、ディスクのフォーマットからメモリのレイアウト、各レイヤーのプロトコルを最適化してきている。どれだけ VectorDB の需要が高まってきたからといって、別のことが得意であった RDBMS や Key-Value / GraphDB が Vector Search を実装したところで、どこまで性能を出せるのか。また、どこまで保守性を維持できるのか。
マーケットからの圧力は大きいだろうし、すでに使っているデータベースで Vector Search が実装されれば、ちょっとした検索性能であれば問題ないビジネス要件もあるかもしれない。しかし、パフォーマンスが極端に求められるケースや、そもそものトラフィックのボリューム量から、Vector Search に特化したエンジンを搭載しているプロダクトを使わざるを得ないケースもあるとみている。こればかりは、各プロダクトの品質次第だが。
あくまで個人のリサーチ結果による主観なので、べき論を書きたくないのだが、どうしても困っている人がいる場合は、以下の観点を参考にしてみてほしい（あくまで主語は筆者）。なお、VectorDB を巡るプロダクト環境は毎週のようにアップデートされているので、賞味期限の短い観点である点には注意されたい。
git clone したが本番環境で使うことは現状はなし他にも VectorDB の選択肢はあるけれど、ここのリストを真面目に追っておけば開発は困らないだろう。Vald と milvus あたりも要望があれば調査してみる。
以上、2023 年 12 月現在における VectorDB の各社のプロダクト展開についてまとめてみた。
VectorDB は"流行り"なのか？個人の意見としては、GraphDB や NoSQL が出現した時の歴史とたいして変わらないと感じている。周囲のアプリケーション開発の様相やビジネス要件が変化したがゆえに、既存のデータベースエンジンの実装では求められるパフォーマンスが出なくなった（例：LLM アプリケーションを本番展開するにあたって、RDBMS や KVS では 10ms/p99 でクエリ結果が返らない）。そこで、自然と新しい需要に最適化したデータベースエンジンを作らざるを得なくなった、という流れだろう。データベースに特別情熱が無い場合は、手持ちのカードを増やす、武器の一つとして使えるくらいの距離感で付き合う程度で良いのではないだろうか。