誇張を抜きにしたベクトルデータベース:何をするもので、いつ必要なのか

「ベクトルデータベース」は、一年ほどで無名の専門用語から必須のチェック項目へと変わりました。これはたいてい、その言葉を理解している人より口にする人の方が多いことのサインです。この技術は本当に役立ちますが、誇張がシンプルな真実を覆い隠してしまいました。ベクトルデータベースは一つの特定の問題を解決するものであり、それに手を伸ばすプロジェクトの多くは、実はその問題を抱えていないのです。これは、こうしたシステムが何をするのか、なぜ存在するのか、そしてそもそも専用のものが必要かどうかをどう見極めるかについての、平易な説明です。

解決する問題:キーワードではなく、意味

従来のデータベースや検索エンジンは、正確なトークンで一致を取ります。「car」を検索すれば「car」を含む文書が得られますが、自動車や乗り物、セダンについての文書は得られません。多くの作業ではそれで問題ありませんが、別の作業では役に立ちません。文字どおりの言葉ではなく意味によって物事を見つけたいなら、完全一致は崩れ去ります。言語は同じアイデアを無数の表層形で表現するからです。

その解決策は、意味を数値で表現することです。モデルは各テキスト断片——文、段落、文書——を**埋め込み(エンベディング)**と呼ばれる数値のリストへと変換し、似た意味を持つものが高次元空間で互いに近くに位置するように配置します。「car」と「automobile」は、共通の文字が一つもなくても近くに配置されます。検索は幾何学の問題になります。クエリを表す点に最も近い、保存された点を見つけるのです。

埋め込みとは実際には何か

埋め込みとは、意味の類似性が空間的な近さになるように学習されたモデルの出力です。使うのに数式を理解する必要はありません。理解すべきはその帰結です。各項目は固定長の数値ベクトルになり、「この二つはどれくらい似ているか」は「この二つのベクトルはどれくらい近いか」になります。そのたった一手——意味を距離に変えること——が、ほかのすべてが乗る土台のすべてです。

決定的に重要なのは、埋め込みモデルとデータベースは別々の関心事だということです。モデルがベクトルを生み出し、データベースがそれを保存して近いものを高速に見つけます。一方を他方なしに変更できますが、モデルを切り替えたときに大規模なコレクションを再埋め込みするのは相応の作業です。この二つの役割を頭の中で区別しておくと、このトピックをめぐる混乱のほとんどを防げます。

埋め込みが何でないかを知っておくのも役立ちます。それは読める要約ではなく、テキストの圧縮コピーでもなく、調べることで元の言葉に逆変換できるものでもありません。それは座標——モデルが学習した空間内の位置——であり、その唯一の意味は、同じモデルが生み出したほかの座標との相対関係にあります。異なる二つのモデルから得たベクトルは比較できません。だからこそモデルを切り替えるとはすべてを再埋め込みすることなのです。これを押さえておけば、このトピックの残りは謎ではなくなります。

なぜ「最も近いベクトルを見つける」のが大規模では難しいのか

最も近い点を見つけるのは些細に聞こえますし、小さなコレクションなら実際そうです——クエリを保存済みのすべてのベクトルと比較し、最も近いものを残せばよいのです。問題は、この総当たり方式がデータ量に比例して増大することです。数件なら一瞬ですが、数百万件になると、クエリごとに一つひとつと比較するのは遅すぎます。

これこそが、専用のベクトルデータベースが存在する本当の理由です。それらは近似最近傍探索を実装しています。すべてを調べることなく、ほぼ確実に最も近いものの中に入っているベクトルを見つける巧みなインデックス手法です。「近似」の部分が取引です。桁違いに速い結果と引き換えに、真の最近傍を取りこぼすごくわずかな可能性を受け入れます。意味検索では、その取引はほぼ常に見合います。なぜなら意味がそもそも曖昧である以上、「とても近い」は「最も近い」と同じくらい役立つからです。

RAGとAIアプリケーションとのつながり

ベクトル検索が爆発的な人気を得たのは大規模言語モデルと時を同じくしており、そのつながりは検索拡張生成(RAG)です。自分自身の文書を使ってモデルに答えさせたいとき、すべてをプロンプトに収めることはできません。そこで文書を埋め込んでベクトルを保存し、ユーザーの質問を埋め込んで、意味的に最も関連する少数のかたまりを取り出し、文脈としてモデルに渡します。モデルはそれらの一節に根ざして答えます。

だからこそすべてのRAGチュートリアルにベクトルストアが登場します。しかしベクトルデータベースが何をして何をしていないかに注目してください。それは検索層、すなわち関連するテキストを高速に見つける部分です。あなたの質問を理解したり答えを書いたりはしません——それをするのは言語モデルです。この境界をはっきりさせておくと、本当は検索品質やプロンプトの問題であるものをデータベースのせいにすること、あるいはその逆を防げます。

専用のものが必要ない場合

ここが誇張の見落とす部分です。独立した専用のベクトルデータベースが正当化されるのは、大規模なコレクションを抱え、大規模で高速な意味検索が必要なときです。その閾値を下回るなら、よりシンプルな選択肢の方が役立つことがよくあります。ささやかなコレクションなら、素のコードでの総当たり比較で十分に速く、運用もはるかに単純です。データが小さいときに類似度を直接計算することに、何ら問題はありません。

さらに重要なのは、多くの汎用データベースが今やベクトル検索を機能として備えていることです。すでにリレーショナルデータベースを運用しているなら、それにベクトル機能を追加する方が、二つ目の専用システムを立ち上げて維持するよりも、運用上の負担がはるかに少ないかもしれません。正直なデフォルトは、すでに持っているデータベースにベクトル検索を追加し、スケールや専用機能が実際に要求したときにだけ専用システムへ昇格することです。新しいインフラの採用は、反射的な反応ではなく、本物の制約への対応であるべきです。

ひそかに品質を左右する部分

実際に意味検索を構築するなら、品質が決まるのはまずデータベースではありません。より重要なのは二つの上流の選択です。一つ目は埋め込みモデルです。モデルが違えば意味の捉え方も違い、あなたの扱うテキストや言語に合わせて調整されたものは、ベクトルをどう保存しようと汎用のものを上回ります。二つ目はチャンク分割——埋め込み前に文書をどう分割するかです。大きすぎるチャンクは意味を薄め、小さすぎるチャンクは文脈を失います。これを間違えると、どんなデータベースも救えません。

三つ目の、忘れられがちな要因は、意味検索が常にキーワード検索より優れているわけではないということです。正確な識別子やコード、名前についてのクエリでは、文字どおりの一致が勝ちます。多くの強力なシステムは、ベクトルを代替物として扱うのではなく、キーワードと意味の両方を組み合わせています。ベクトルに手を伸ばすことは、すでに機能している検索技術を捨てることを意味しません。最良の結果は、両者を一緒に使うことから得られることがよくあります。

各ベクトルとともに何を保存するかという問題もあります。実際のシステムがベクトルを単独で検索することはまれです——メタデータでもフィルタリングし、特定のユーザー、日付範囲、文書種別からの結果だけを返します。効率的にフィルタリングできないベクトル層は、ぎこちない回避策を強いるので、ユースケースが意味ベースの一致と構造化フィルタリングの両方を必要とするなら、その能力を生の検索速度と同じくらい重く評価してください。最もきれいな意味的一致も、ユーザーが見ることを許されていない文書に属していれば無価値です。

まとめ

ベクトルデータベースは一つのことをうまくこなします。クエリに意味が最も近い項目を、大規模なコレクションをまたいでも高速に見つけることです。その能力は本当に強力で、意味検索とRAGを支えています。しかしそれは一つの構成要素であって、魔法の材料ではありません——品質を決めるのは埋め込みモデルとチャンク分割の戦略であり、多くのプロジェクトは、専用システムを採用するよりも、既存のデータベースにベクトル検索を追加するか、単純な総当たり比較を使う方がよく機能します。まず問題を理解しましょう。専用ツールに手を伸ばすのは、スケールがそうさせるときだけにしましょう。