ベクトルデータベース: 技術入門書 [PDF]
(tge-data-web.nyc3.digitaloceanspaces.com)- AIアプリケーションが非構造・高次元データを扱うようになる中、ベクトルデータベースはデータを数値配列の形で保存・検索する専用システムとして重要性を増している
- 中核となるのは、行・列や明示的な関係よりも、データ属性間の類似性を基準にレコードを結び付け、暗黙的な意味を活用する点にある
- 意味関係を多次元ベクトルとしてエンコードすると、類似性検索、クラスタリング、分類のような分析作業をより高速に実行できる
- 生成AIでは、大量の高次元データを管理し、類似ベクトル検索を通じて学習と推論の速度およびパーソナライズされた結果を改善するために使われる
- 高度なインデキシングは検索対象を関連性の高い部分集合に絞り込み、検索時間を短縮し、類似性と他の条件を組み合わせた複雑なクエリを可能にする
ベクトルデータベースが扱うデータの形態
- ベクトルデータベースは、高次元データ表現であるベクトルを保存、管理、処理するための特殊なデータベースである
- 従来のデータベースがデータを行と列に保存するのに対し、ベクトルデータベースはデータを多次元空間のベクトルとして保存する
- 各ベクトルは、データポイントの特徴や属性を表す数値配列である
意味と類似性に基づく接続
- 従来のデータベースは、明示的なリンクや階層に基づいて要素間の関係を設定する
- ベクトルデータベースは、データ属性の類似性を基準にレコードをアルゴリズム的に接続する
- この方式により、データベース要素内の暗黙的な意味に基づく、より直感的な接続を作ることができる
分析クエリに合わせた構造
- データが意味関係を反映した多次元ベクトル、つまり数値配列としてエンコードされると、高度な分析作業を高速に実行できる
- サポートされる作業には、類似性検索、クラスタリング、分類が含まれる
- 計算モデルは、パターン検出、予測分析、高い分析要件を持つアプリケーションに適している
AIと生成AIでの活用
- AIと機械学習の普及は、ベクトルデータベース需要が拡大した主要な背景である
- 生成AIの領域でベクトルデータベースは、大量の高次元データを効率的に保存・管理できるよう設計されている
- 類似ベクトルを高速に検索して結果を取得できるため、生成AIモデルの学習と推論の過程を大幅に高速化できる
- 生成AIシステムが、ユーザーによりパーソナライズされ関連性の高いコンテンツを提供するのにも活用される
インデキシングと複雑な検索条件
- ベクトルデータベースは、高度なインデキシング手法によって類似ベクトルを高速に照会・検索する
- インデックスは検索対象を、より小さく関連性の高いベクトル部分集合へと絞り込み、検索時間を大幅に短縮する
- 類似性条件と他の検索基準を組み合わせる複雑なクエリも処理できる
- この柔軟性は、洗練された検索機能が必要な高度なAIアプリケーションで重要である
1件のコメント
Hacker Newsのコメント
A Comprehensive Survey on Vector Database: Storage and Retrieval Technique, Challenge: https://arxiv.org/abs/2310.11703
Survey of Vector Database Management Systems: https://arxiv.org/abs/2310.14021
What are Embeddings: https://raw.githubusercontent.com/veekaybee/what_are_embeddi...
出典表記: https://twitter.com/eatonphil/status/1745524630624862314 および https://twitter.com/ChristophMolnar/status/17457316026829826...
注釈付きスライドと、選べる 38分の動画 も用意されている
Wikipedia記事: https://en.wikipedia.org/wiki/Vector_database
Vector Database 101: https://zilliz.com/learn/introduction-to-unstructured-data
近似最近傍探索と類似度検索: https://vinija.ai/concepts/ann-similarity-search/
分散データベース: https://15445.courses.cs.cmu.edu/fall2021/notes/21-distribut...
自分も気になっていた点なので、基準や経験則があれば知りたい
最近、Simon Willisonのすばらしい
llmツールで埋め込みを扱ってみたが、アプローチはきわめてシンプルで、距離計算用のUDFをいくつか用意して SQLiteに埋め込みを保存 するというものだったこのシンプルさは魅力的だが、トラフィックやデータ量がある水準を超えたら、もっと特化したデータベースが必要になるはずで、その境界がどのあたりなのか感覚を知りたい
検索はもっとも単純に全件走査してハミング距離（
xorとpopcount）で比較していたが、2011年製MBPの単一コアで 20万個のハッシュ を10ms未満でスキャンして最も近い項目を見つけられただいたい1000行のコードだったので、結局は外部のベクターデータベースは不要だった
ただ、それを超えるとPineconeのような一応使える選択肢は複雑で遅く、法外に高価になる
自分の知る限り最良の選択肢はturbopuffer.comで、Pineconeより100倍くらい安く、実際にスケールするように見える
スライドのおすすめベクターDB一覧に入っていなかったので、よさそうな推薦として置いておく
https://news.ycombinator.com/item?id=38703943
この講義は、ベクター、ベクターデータベース、インデックス、類似度検索の基本概念を扱う理論とデモを組み合わせたもので、最後はPineconeとWeaviateデータベースのデモで締めくくられる
この段階では人間の判断が非常に微妙に、ときにはほとんど無視できるほどの形で入り込んでいるのに、見た目は非常に自動化された「ただの数学」のシステムのように見えてしまう
オーディオを例にすると、N次元ベクターを作るためにどんな特徴を取り出すのか。簡単な答えは「できるだけ多く」かもしれない
しかし第一に、名前を付けやすい特徴でさえ、特徴化データにアクセスできないことがある
第二に、ドメイン知識が深くなければ、使うべき潜在的な特徴の存在自体に気づけないことがある
第三に、ドメイン知識が深くあっても、なお使うべき潜在的な特徴が分からないことがある
たとえば、Reich式の位相移動ミニマル音楽のファンだとしよう。このジャンルの代表曲、たとえばPiano Phaseに似た音楽を探すために、ベクターデータベースに間接的にクエリする
データベースは、支配周波数、音の立ち上がり間隔、音量、周波数分布ベースの音色特徴、見かけ上の基音や音階など、さまざまなオーディオ・音楽特徴を使う
しかし、データベースの特徴集合に「時間に伴って音と音の間隔が一定である」という性質がなければ、クエリによって音色・和声・旋律・リズムが似たものは見つけられても、中核的な特徴である 2つの旋律線の相対位相が継続的に変化すること を共有する曲を見つけるかどうかは、完全に運任せになってしまう
視覚、テキスト、数値など、どんなデータでも似た例を作るのは難しくない
もちろん、これはベクトルデータベースと特徴分類が役に立たないという意味ではない
特定のデータセットで一致パターンを見つけられるか見つけられないかに関して、最初に問うべきことの1つは 特徴集合が完全であると強く保証できるかどうか、そうでないならどう拡張すべきかということだ
ベクトルデータベースは 検索と検索結果の取得 に合わせて作られている
通常、ベクトルを作る方法は、大規模な事前学習モデルをファインチューニングし、その内部表現を抽出するというものだ
データセットには成功したクエリと取得結果が含まれているので、生の入力を使って、ベクトルデータベースがサポートする類似性目的に合わせて損失関数を最適化すればよい
表、テキスト、画像、音声のような一般的なモダリティでは、特徴選択に人間の判断はほとんど入らず、単にアテンションを適用すればよい
ちなみに、E5-Mistral のような最新のテキストベクトルモデルは、データセットに人手のキュレーションすら必要としない
「知らないことを知らない」という点をうまく突いている
Steve Reich 愛好家をまた見かけてうれしいし、私の好きな Music for 18 Musicians に似た曲のおすすめが気になる
すばらしい概要だが、最後のセクションでは Postgres+pgvector のような ベクトルストア と、Pinecone のような ベクトルデータベース のどちらを使うかという定番の問いを扱っていない
クエリ速度、挿入・インデックス構築速度、使いやすさなど、さまざまなトレードオフを論じて、各アプリケーションに合った選択を助ける発表をもっと見たい
PR はいつでも歓迎
データベースとは、ストアにいろいろな機能が付いたものだ
digitaloceanspaces.com は S3 スタイルのホスティングプロバイダーなので、Hacker News がこれを特別扱いして、ドメインを単に digitaloceanspaces.com と表示するのではなく、tge-data-web.nyc3.digitaloceanspaces.com のように表示してくれるとよいのだが
ただし S3 にも同じ問題があるようだ: https://news.ycombinator.com/item?id=38876761
他にも前例はある。x.github.io のサブドメインサイトはここで特別扱いされている: https://news.ycombinator.com/from?site=lfranke.github.io
この資料は、エンジニアが出発点にするには かなり危険 に見える
意味に基づいてクラスタリングされるとか、分析に最適化されているといった表現は疑わしい
クラスタリングは計算された埋め込みに依存する。埋め込みがデータの意味をうまく近似していると信じるなら、そのように考えても構わないかもしれない
しかし、それを破る埋め込みはいくらでも想像できる。たとえば、意味が同じ音声ファイルとテキストファイルを同じ埋め込みプロセスに入れても、マルチモーダルでなければ、埋め込みベクトル空間では大きく離れる可能性が高い
今後は、意味的な類似性よりも 利用のされ方 に応じて、ベクトル空間内で近くに配置する埋め込みも確実に出てくると思う
レコメンデーションシステムを作るなら、単発購入のさまざまなバリエーションを近くにまとめたくはない
たとえば、意味的に最も近いフライトは同じ目的地の別の時間帯の便や近隣空港行きの便だろうが、実際には、そのフライトを買った人がよく一緒に買うホテルを近くに置きたいかもしれない
ベクトルデータベースは、時間認識のような追加次元もデータに入れられる。意味をエンコードしたベクトルを必ず使う必要はない
したがって、ベクトルデータベースは入力ベクトルベースの参照や検索に最適化されており、OLAP クエリ に似ているわけではない
Snowflake より Elasticsearch に近い。ベクトル空間に対するレポーティングや大規模分析を期待してベクトルデータベースを使うなら、私の知る限り、今すぐ使える製品はない
リンゴの写真から「リンゴらしさ」を表すベクトルへ行き、そのベクトルを普通の数学で他のベクトルと比較する、というのは理解できる
理解できないのは、誰が／何が画像を入力として受け取り、ベクトルを出力するのかという点だ
文書でも同じだ。配列に数値を1つ追加する形で次元を増やしたいなら、ベクトルデータベースのどの部分を修正すれば、その次元がベクトル計算に含まれるのか？
それとも、文書・画像・何であれベクトル表現に変換するプロセスは、データベースの外で別の方法によって行われるのか？
修正: 埋め込み計算は機械学習アルゴリズムの仕事のように見えるが、そうなるとそのアルゴリズムもまず学習しなければならない。結局、果てしなく学習が連なることになる
なぜ PQ が「インデックス戦略」として挙げられているのかわからない
PQ はベクトル圧縮・量子化技法であって、検索空間を分割する手段ではない
全探索／フラットインデックス、IVF インデックス、HNSW で PQ によってベクトルをエンコードでき、Faiss ではそれぞれ IndexPQ、IndexIVFPQ、IndexHNSWPQ として実装されている
望むなら k-D ツリーや ANNOY と組み合わせることもできる
「クエリ速度が精度より重要なときは、非常に大きなデータセットに HNSW や Annoy を使え」という話にも問題がある
グラフベース手法はメモリオーバーヘッドと構築コストが大きく、10億規模データセット には実用的ではない
通常は IVF 手法より高精度かつ高速だが、それは IVF が同程度の精度を得るために多くのセルを訪問しなければならないからだ
一方で IVF は、他の手法と違って大きなオーバーヘッドなしに 1兆規模データベース まで拡張でき、それでいて妥当な速度と精度のトレードオフを提供する
私なら、「クエリ速度が重要で、しかも高い精度も欲しく、フラット／全探索インデックスが非現実的な中規模データセットに使え」と言うだろう
まず PQ を行い、その新しい離散ベクトルに対して KNN を実行すればよい
こうすれば語彙空間を固定サイズに圧縮できる
15枚目のスライドの表では、Traditional Databases と Vector Databases の Indexing & Search Efficiency の欄が互いに入れ替わっているように見える
SQLite のような 組み込み型埋め込みデータベース のおすすめはあるだろうか？
小規模な用途向けだが、LMDB + FAISS より手軽だとうれしい
Python プロセス内で実行でき、コンテンツは SQLite に保存し、埋め込みベクトルはローカルのベクトルインデックス形式（Faiss、HNSW、Annoy）に保存する機能をサポートしている
ちなみに自分は txtai の主な作者だ
https://github.com/patricktrainer/hackernews-comment-search
llmツールは SQLite といくつかの UDF だけを使っているそのシンプルさは魅力的だが、いつ、なぜそれで十分でなくなるのかはいまひとつ分からない
Go 向けには、最近 Chroma のインターフェースに着想を得て chromem-go を作り始めた: https://github.com/philippgille/chromem-go
まだ高度な機能や大規模用途向けではないが、RAG デモは動作する
[1] https://github.com/chroma-core/chroma