私は長年、ベクトルベースのソリューションの機能はいくつかの点で匹敵する可能性があるものの、すべてのベクトルベースのソリューションを総称してベクトルデータベースと呼ぶべきではないという見解を持っています。私の観点から見ると、pgvector や Elasticsearch はどちらも、特定のシナリオでユーザーのニーズを十分に満たすことができる優れた成熟した製品です。
データの量が少ない場合は、Elasticsearch とスカラー検索を組み合わせて使用するだけで、ビジネス シナリオに十分対応できます。あるいは、元のデータがリレーショナル データベースに完全に保存されている場合は、pgvector 操作に基づいて数十万、さらには 100 万のデータを検索することも完全に可能です。しかし、データ量が増加すると、多くのビジネス シナリオが従来のデータベース設計によって制限され、十分に拡張できないことがわかります。
実際、ベクトル データベースがどのような機能を提供するかを議論する場合、アルゴリズム、計算能力、スケジューリングなど、避けては通れない重要なポイントがいくつかあると思います。ベクトル データベースとして、これらの側面には特別な設計が必要です。
私が常に言及している 1 つの例は、最近傍検索を実行したいだけの場合は、ANN を作成でき、必要な最近傍検索機能を実現するのに必要なコードは 10 行未満である可能性があるということです。しかし、誰もがこれを行わないことを選択する理由は、主にパフォーマンスとコストの要因によるものです。この観点から、パフォーマンス、コスト、スケーラビリティが重要になると、従来のデータベースの多くはニーズを満たすことができない可能性があります。