AI/LLM/RAGを進める上で理解していることが重要なのでここにメモ。 過去にも下記の記事でまとめましたが、今回改めてまとめ直します。
RAGに関してはこちらでまとめています。
ベクターデータベースとは
ズバリ
質問の“意味”に近い情報を見つけるためのデータベース
です。
従来みたいにキーワード一致で探すのではなく、意味が似ているもの同士を数値で判断して検索できる仕組みです。
どんな仕組み
1. まずデータを「数値のかたまり」に変換
文章・画像などを、そのままでは検索できないので Embedding（埋め込みモデル） を使って
「数百〜数千次元のベクトル（数字のリスト）」 に変換します。
例：
「請求書の締日は？」
→ [0.12, -0.88, 0.37, …] みたいな長い数字の配列になる。
このベクトルは意味が似ていれば空間上で近くなるように設計されています。
2. ベクトルを専用データベースに保存
保存する時は、以下の2つを一緒に持ちます：
- ベクトル（数字の配列）
- メタデータ（元テキスト、タイトル、タグなど）
3. 検索のときも質問をベクトルに変換
ユーザーが質問する → それもEmbeddingしてベクトル化。
4.「意味の近さ」で探す（近傍探索）
使うのは 距離
- コサイン距離
- 内積（dot product）
- ユークリッド距離
で、「一番近い」ものを探します。
ただし、ベクトルは数百万〜数億ある
全部チェックすると遅いので、高速探索アルゴリズムを使っています。
代表例：
- HNSW（グラフ構造で探す）
- IVF（クラスタごとに検索）
- PQ（圧縮して高速探索）
これにより“意味が最も近いデータをミリ秒で返す”
という流れです。 （ここは長くなるので、また次回）
どうやって「文章 → 数字のリスト」にするの？
たとえば「請求書の締日は？」という文章を Embeddingモデル にそのまま入力した場合を見てみましょう。
まず、モデルの中で“意味の特徴”を数字化する
モデルは文章を読んで、
- これは「請求書」の話
-「日付」「締め日」に関係している - 文体は質問形式
- ビジネス文書っぽい
などの意味的な特徴を内部で分析します。
その後、特徴を「数字の並び」にして出す
分析した意味の特徴を、数学的に扱えるようにしたものがベクトルです。
例：
[0.12, -0.43, 0.88, 0.51, …（数百〜数千次元）]
これだけで、“この文章はどんな意味を持っているか” がわかるようになる。
つまりEmbeddingは文章を読んで、意味の特徴を数字（ベクトル）に置き換える技術です。
だから
似た意味の文章なら
数字も似た形になる → 意味検索ができる。
二次元以上は点として想像しづらいすですが、
意味の近いものは、場所も近ければ、形（パターン）も似ているイメージになります。そこがコサインの距離になります。
X次元の数字に変換する意味
意味を持たせて数値化するということでしたが、どれぐらいの意味を持たせるかで次元の数が変わってきます。
そして、次元を増やせば増やすほど、比較対象や保存するためのスペースも必要になるため、コストが高くなります。
でも、逆に次元数を減らすと意味を見逃してしまうケースも多く出てきてしまいます。なので、ここのバランスは重要なものになります。スピード重視なのか、意味合い重視なのかで持つべき次元数が変わります。
どんな区分や単位でベクトル化しているか
初期のNLPでは単語Embeddingが主流でしたが、現在のLLM時代では “文・段落全体のEmbedding” が標準になっています。単語をベクトル化するだけだと全体の意味を失いがちになるのがイメージできます。でも文章単位でベクトル化って想像するだけで大きなデータになりますね・・
距離の話
距離の話をしましたが、これもまた、２次元のようにシンプルではなく、複数の手法を使います。冒頭にて、コサイン距離、内積（dot product）、ユークリッド距離と説明しましたが、ここでそれぞれがどんなものなのかみてみます。
コサイン距離
2つのベクトルの“角度”が近いかどうかを測る。
- 向きが同じ → よく似ている
- 向きが違う → 似ていない
長さ（大きさ）は関係なく、“方向の近さ”だけを見るのがポイント。
文章Aと文章BのEmbeddingが似たパターン（似た方向）ならコサイン類似度が高いです。なので、文章の長さが違っても、意味の方向が近いなら高スコアになるため、文章検索に向いています。
内積（Dot Product）
向き × 大きさ を同時に測る。
- 同じ方向で、
- 数値（エネルギー）が強い
ほど値が大きくなる。
「どれくらい同じ方向へ 強く伸びているか」を測る。ということです。
Embeddingモデルが「重要特徴」を強く数値化している場合、その特徴が似ている文章同士は内積が大きくなる。
長さ（ベクトルの大きさ）の影響を受けるため、“方向だけ見たい”場合は向かないこともある。ということはある特定の特徴が強いとそれに影響される度合いが高くなってしまいます。
ユークリッド距離（Euclidean Distance）
2つの点の物理的な距離（直線距離）。
√((x1-x2)² + (y1-y2)² + …) で求められる数字になります。
数字同士がどれくらい違うか（差の総量）を測ることになります。
1536次元の数字の配列同士を全部引き算してその差を足し合わせるイメージ。
次元が高いと距離が均一化しやすいため、高次元Embeddingではユークリッド距離は意味の違いが表現されないため不向きになります。高次元空間では、どの点同士も“中間くらいの距離”に集中してしまう現象があるため、ユークリッド距離は差別性を失いやすくなります。
ベクターデータベースのスコープ（範囲）
そもそもこの記事がざっくりなので、まとめもざっくりですが、ベクターデーターベースとは、ベクター化されたデータから近しいものを探し返す、その元文章のメタデータを返す、というデータベースになります。
近いと判断されたベクターデータを受け取り、そこから文章を生成するのはAIの仕事となります。
まとめ
現在よく使われているベクターデータベースをいくつかリンク貼っておきますので、みてみてください。
ということで、RAGを理解する上でベクターデーターベース、ベクター化はとても重要な技術なので、再度まとめてみました。
毎度最後は
エンジニア募集中です。ASP.NET, AZURE系での開発が多い会社です。ぜひ腕を奮ってみたい方、なんとなくでも一緒に仕事してみたいと思った方はご応募お待ちしております。