ベクトルデータベース

エンベディング、つまり文章や画像を変換した数値の並びを貯めておく場所です。

AWSの解説は、RAGの説明の中でこう書いています。

データを数値表現に変換し、それをベクトルデータベースに格納する

— AWS「What is RAG?」より和訳

検索するときは、問いの側も同じ形に変換されます。

利用者の問いはベクトル表現に変換され、ベクトルデータベースと照合される

— AWS「What is RAG?」より和訳

どちらも数値の並びになっているので、計算で近さを測れます。 AWSは「関連性は、数学的なベクトルの計算と表現を使って算出され、確定された」と書いています。

Googleの用語集も同じ流れを「この比較はベクトル空間での類似度検索によって行われ、それによってシステムは意味の上で最も関連する情報を取り出せる」と説明しています。

IPAのガイドラインが、順番をはっきり書いています。

RAGを使用する場合は、問い合わせの前にベクトルDBへの検索が行われ、検索結果がプロンプトに追加されてからトークンへの変換と問い合わせが行われます。

— IPA『テキスト生成AIの導入・運用ガイドライン』

LLMに渡す前の工程です。 検索した結果をプロンプトにくっつけてから、トークンに変換して問い合わせる、という順になります。

ここは誤解されやすい点です。RAGにベクトルデータベースが必要、という決まりはありません。

Microsoftの公式ドキュメントは、RAGで使う「インデックス」をこう定義しています。

検索（キーワード検索・意味検索・ベクトル検索、またはそれらの組み合わせ）に最適化されたデータ構造

— Microsoft Learn より和訳

ベクトル検索は選択肢の1つとして並んでいるだけです。同じ資料は「インデックスは、効率よく取り出せるように内容を整理することで役に立つ」と、目的のほうを書いています。

実際のサービスも両方に対応しています。「Azure AI Search は、検索インデックスに格納されたベクトルのデータとテキストのデータの両方に対する検索に対応している」。

IPAの説明が「ベクトルDB」を名指ししているのは、よく使われる構成を書いたものと読むのが正確です。

ベクトル検索にはエンベディングを作る工程が付いてきます。

ベクトル検索は、インデックスを作る時点でエンベディングを必要とし、問い合わせの時点でも必要になることが多い

— Microsoft Learn より和訳

貯めるときに1回、検索するたびにもう1回かかる、ということです。 キーワード検索にはこの工程がないので、「とりあえずベクトルで」が常に安いわけではありません。

IPAのガイドラインは、ここをファインチューニングと並べて書いています。

RAGを使用するにあたって、ベクトルDBの検索を正確に行うためにはファインチューニングと同様に格納するデータの質を確保することが重要です。

— IPA『テキスト生成AIの導入・運用ガイドライン』

仕組みを入れれば精度が出る、という話ではありません。 入れる文書が古かったり重複していたりすれば、近いものとして取り出されてしまいます。

こう言うと伝わらない 「ベクトルDBを入れたいです」

こう言えば一度で済む 「社内マニュアル200本から、表記が違っても該当箇所を引けるようにしたいです。キーワード検索で足りるかどうかも含めて検討したいです」

後者なら、相手は検索方式の選択から相談できます。