また新しい技術かと思ったら、「ベクトルDB」はすでに触っていた話

最近、技術記事で「ベクトルDB」という言葉をよく見る。

最初は「また新しい技術をキャッチアップしないといけないのか」と思ったが、中身を見てみると、以前RAGを作ったときにPostgreSQLでやっていたベクトル検索とかなり近い話だった。

もちろん、専用のベクトルDBとPostgreSQLの拡張機能では違いはある。
ただ、少なくとも概念としては、RAGでpgvectorなどを使ったことがある人なら、かなり理解しやすいと思う。

ベクトル検索とは何か

ベクトル検索は、文章や画像などのデータを数値の配列に変換し、その「近さ」を使って検索する仕組みだ。

普通のLIKE検索は、文字列が含まれているかどうかを見る。

たとえば「犬」で検索した場合、基本的には「犬」という文字が入っているデータが対象になる。

一方、ベクトル検索では、文字列そのものではなく意味の近さを見る。

「犬」と検索したときに、「ゴールデンレトリバー」や「ペット」、「散歩」のような、意味的に近い情報を拾える可能性がある。

つまり、完全一致や部分一致ではなく、文脈や意味の近さで検索する技術だ。

RAGで使っていた仕組み

自分がこの仕組みを使ったのは、LLMに独自データを参照させるRAGを作ったときだった。

流れはだいたいこうなる。

1. 社内ドキュメントや業務データを分割する
2. それぞれをEmbeddingでベクトル化する
3. ベクトルをPostgreSQLなどに保存する
4. ユーザーの質問もベクトル化する
5. 質問に近いデータをベクトル検索で取り出す
6. 取り出した情報をLLMに渡して回答を作らせる

この「質問に近い情報を探す」部分で使っていたのが、まさにベクトル検索だった。

当時は「ベクトルDBを使っている」という感覚ではなく、PostgreSQLにpgvectorを入れて検索している、くらいの認識だった。

ただ、やっていることの本質は、最近よく聞くベクトルDBとかなり近い。

PostgreSQL + pgvector と専用ベクトルDBの違い

PostgreSQLでベクトル検索をする場合、代表的なのがpgvectorだ。

これはPostgreSQLの拡張機能で、ベクトルを保存し、類似度検索を行える。PostgreSQLの中に通常の業務データとベクトルデータを一緒に持てるのが大きな利点だ。

たとえば、ユーザーID、カテゴリ、公開状態、更新日などの通常のカラムで絞り込んだうえで、ベクトル検索を行うような使い方がしやすい。

一方で、Pinecone、Milvus、Chromaのような専用のベクトルDBは、最初からベクトル検索やAIアプリケーション向けに設計されている。

大量のベクトルを扱う、検索性能を重視する、スケールさせる、AI向けの検索機能を使う、といった場面では専用DBのほうが向いていることがある。

ざっくり言うと、こういう整理になる。

「全く新しいもの」と思わなくていい

ベクトルDBという言葉だけを見ると、新しいカテゴリの技術に見える。

でも、PostgreSQLでRAGを作ったことがある人なら、基本的な考え方はすでに触っているはずだ。

新しく覚えるべきなのは、ベクトル検索そのものというより、

• どのくらいのデータ量を扱うのか
• 既存のRDBと一緒に管理したいのか
• 検索速度やスケールがどれくらい必要か
• 運用をPostgreSQLに寄せたいのか、専用サービスに切り出したいのか

という設計判断の部分だと思う。

もし「ベクトルDBを学ばないと」と感じているなら、まずPostgreSQL + pgvectorで小さなRAGを作ってみるのが近道だと思う。

そこで詰まったポイント（速度、スケール、運用）が、まさに専用ベクトルDBが解決している領域そのものだ。

先に名前を覚えるより、先に問題に出会う方が、技術の輪郭はくっきり見える。