VectorはPostgreSQLの新しいJSONです
(jkatz05.com)- ベクトルはよく研究された数学的構造であり、JSONはデータ交換形式である
- しかし、データ保存と検索の世界では、この2つのデータ表現方式は共通言語となっており、最新のアプリケーション開発でまもなく不可欠な要素になるだろう
- 現在の傾向が続くなら、ベクトルもアプリケーション構築においてJSONと同じくらい重要になるだろう
- 生成AIの成果物を保存しクエリするために、PostgreSQLが自然な選択肢となった
- しかし、これは新しいデータパターンではない。数学的概念としてのベクトルは何百年も前から存在している
- ベクトルの基本データ構造である配列は、ほとんどの計算機科学入門課程で教えられる。PostgreSQLも20年以上にわたりベクトル演算をサポートしてきた
- では何が新しいのか？ それは、このようなAI/MLアルゴリズムの「アクセスしやすさ」と、一部の「現実世界」の構造（テキスト、画像、動画）をベクトルで表現し、それを後でアプリケーションで利用することがどれほど「容易に可能か」である
- また、こうしたシステムの出力である「埋め込み」をデータストアに保存すること自体も新しいとは言えないが、新しいパターンは、このデータをほぼリアルタイムですべてのアプリケーションからクエリして返せる「アクセス性」にある
- では、これがPostgreSQLとどう関係するのだろうか？
- データ型を効率的に保存・検索する共通パターンは、アプリ開発を大幅に単純化し、人々が同じ場所にデータを保存して既存ツールで作業できるようにした
- 私たちは10年前にJSONでこれを見ており、今はベクトルデータでこのパターンを目にしている
PostgreSQLにおけるJSONの簡単な歴史
（原文を参照してください）
ベクトルの台頭「新しい種類のJSON」
- 最近、人気が急上昇している
- 一般的なユースケースは、保存されたデータに対してモデルを構築し、ベクトル形式に変換したうえで「セマンティック検索」に利用すること
- この場合、検索時に入ってきた新しい入力をベクトル形式に変換し、データベース内で最も近いものを検索する
- 類似性はユークリッド距離やコサイン距離などの距離関数を用いて測定し、結果はしばしばk-NN（Nearest Neighbors）または最も類似したk個のオブジェクトに限定される
- ベクトルのトレーニングセットをエンコードするには多くの時間がかかることがあるため、DBのような場所にキャッシュし、そこでk-NNクエリを実行するのが望ましい
- セマンティック検索のためにクエリ可能な状態のベクトル群を持つことは、通常ユーザーにより良い体験を提供するため、「ベクトルデータベース」の必要性が浮上している
- ベクトル保存はPostgreSQLにとって新しいことではない
- 実際、PostgreSQLは多次元データ（例: matrix）を保存できるため、「ベクトル」という名称はやや不正確である
- 基本的に、PostgreSQLの配列には2つの配列間の「距離」計算など、ベクトル向けの機能が限定的ながら含まれている
- ストアドプロシージャを書くこともできるが、開発者には多少追加の作業が必要になる
- 幸い、cubeデータ型はこうした制限を克服する
- cubeは20年以上使われており、高次元ベクトルに対する操作を実行できるよう設計されている
- cubeにはユークリッド距離を含め、ベクトル類似検索で使われる一般的な距離関数の大半が含まれている
- GiSTインデックスを使って効率的なK-NNクエリも実行できる
- ただし、cubeは100次元までのベクトルしか保存できず、最新のAI/MLシステムはそれ以上の次元を要求する
pgvector: PostgreSQLでベクトルを保存・検索するためのオープンソース拡張
- pgvectorを使うと、ベクトルを保存し、さまざまな距離メトリクス（ユークリッド、コサイン、内積など）でk-NNクエリを実行できる
- 現在、pvectorはベクトルインデックスのIVR FLATメソッドを実装した1つのインデックス
ivfflatを備えている - インデックス化されたベクトルデータをクエリすることは、通常データをクエリすることとは異なる場合がある
- 高次元ベクトルで最近傍探索を行うコストのため、多くのベクトルインデックス手法は、正解に「十分近い」おおよその答えを見つける
- これが「ANN（Approximate Nearest Neighbor）」検索分野につながっている
- ANNクエリについて人々が注目する2つの軸は、性能と「recall」（関連する結果が返される割合）とのバランスである
ivfflatを例にすると、ivfflatインデックス作成時にいくつのリストを含めるかを決める- 各リストは「中心」を表し、この中心はk-meansアルゴリズムによって計算される
- すべてのセンターが決まると、ivfflatは各ベクトルが最も近いセンターを判定し、それをインデックスに追加する
- ベクトルデータをクエリする段階になると、
ivfflat.probes変数に応じて、いくつのセンターを調べるべきかが決まる - ここでANNの性能/リコールのトレードオフが見える。より多くのセンターを訪れるほど結果は正確になるが、性能は低下する
PostgreSQLでベクトルをより良くサポートするための次のステップ
- JSON型が正式サポートされたPostgreSQL 9.2の頃と同じように、ベクトルデータをPostgreSQLに保存する方法はまだ初期段階にある
- PostgreSQLとpgvectorはすでに優れているが、今後さらに良くなるだろう
- pgvectorはすでに一般的なAI/MLデータのユースケースに対応可能で、多くのユーザーがすでに導入して使っている
- 次のステップは改善と拡張を支援することであり、その大半はすでに進行中である
- さらなる並列化の追加
- 2,000次元を超えるベクトルのサポート
- 計算速度を高めるためのハードウェアアクセラレーション活用
- PostgreSQLをベクトル「データベース」として使うことには大きな期待が寄せられている
- JSONの歴史から分かるように、PostgreSQLコミュニティは拡張可能で安全な方法でこれをサポートする道を見つけるだろう
7件のコメント
汎用性は高いのでしょうが、結局は速度が鍵ではないかと思います。
純粋なベクターDBと比べると、見ていられないほど遅そうですが……
Pinecone のようなベクターデータベースがある状況で、なぜ PostgreSQL に期待が集まっているのか気になります。 @@
私の経験では、PostgreSQLが最も使いやすかったです。
PineconeやChromaDB、あるいはWeaviateのようなものを使うときは、各データベースを使えるように標準化されていませんでした。
つまり、データベースごとに異なるSDKを使う必要があり、その使い方も違うので、コードをデータベースごとに新しく作らなければなりませんでした。また、公式SDKが提供している言語も少なく、言語を変えなければならないこともありました。
もちろん、PostgreSQLでベクトルを使おうとしても似たような面はありますが、少なくとも既存のSQL文法に少し知識を足すだけでよいので、とっつきやすかったです。
現在、ベクトルデータベースの速度を比べてみるとPostgreSQLはかなり遅いほうですが、早くもう少しアップグレードされるといいですね。笑
「全部サポートされているDBを1つだけインストール・管理すれば楽だ」＋「他の機能との連携がしやすい」くらいではないでしょうか。
インスタンスが増えると、だんだん面倒になってくるんですよね..
ああ、理解しました。
Redisがあれこれ付け足しているのも、そういう理由なんですね。うんうん
起承転...テンソル...
筆者のJonathan Katzは、PostgreSQL Core Teamに所属しています。