前回、ベクトル比較について書いた。
学習量が多ければ多いほど、RDBだと全部検索時間かかると思っていた。
そしたらベクトルDBなるものがあった。
のでまとめとく。
1. 役割の違い
- RDB（MySQL / PostgreSQL）
→ 条件検索・集計・リレーション管理が得意
→ SQL を使って「正確一致」や「範囲検索」を行う - ベクトルDB（Qdrant / Pinecone / Chroma）
→ 文書・画像・音声などを「似ている順」に検索するためのDB
→ コサイン類似度などで「類似検索」が高速にできる
2. 保存形式の違い
RDB
- テーブル
- 行（row）と列（column）
ベクトルDB
- コレクション
- ポイント（vector + payload）
3. データ構造の違い
| 種類 | 構造 |
|---|---|
| RDB | id / title / body / created_at / ... |
| ベクトルDB | id / vector[1536次元] / payload(json) |
ベクトルDBの例
{
"id": 1,
"vector": [0.12, -0.55, ...],
"payload": {
"text": "返品方法を教えて",
"category": "返品"
}
}
4. 検索方法の違い
RDB：
WHERE name = 'A'
WHERE price > 1000
ベクトルDB：
embedding と保存済みベクトルを比較し
「似ている上位5件」のように返す。
5. 速度の違い
RDB
embedding を保存すると
→ 類似度検索は 全件比較（遅い）
ベクトルDB
→ HNSW / IVF / PQ などのインデックスを使い
→ 数百万件でも 10〜30ms で返す
6. ベクトルDBが高速検索できる仕組み（概要）
それぞれがどの用な処理をしているかは省いた。
どんな役割があるかだけ書いた。
HNSW（階層的グラフ）
- ベクトル同士を「グラフの道」でつないでおく
- そのグラフを上から順に降りていくことで、
近い候補だけを見て検索できる - 結果 → 数百万件でもミリ秒で検索可能
[ベクトルA]───[ベクトルB]───[ベクトルC]
\ │ \
\ │ \
└────[ベクトルD]──────[ベクトルE]
- A と B は近い
- B と C は近い
- D と E も近い
IVF（クラスタリング）
- データを「似ているグループ」にあらかじめ分割
- 検索時は、関係あるクラスタだけ見る
- 結果 → 不要なデータをほとんど見ないで済む
PQ（圧縮）
- ベクトルを小さく圧縮して保存
- 大量データでもメモリに載せやすい
- 圧縮しても「距離（類似度）」はそこそこ正確に比較できる
■ まとめ
- HNSW → 近いところから探す
- IVF → 最初からグループ分けしておく
- PQ → 圧縮してメモリ効率を上げる
これらにより、ベクトルDBは
全レコードを brute-force しなくても類似検索ができる。
キャンプのしおりを学習させて、「消灯時間はいつ？」とか「ごみの捨てる時間は何時？」とかに答えられるボットも作成できそうだな。