ベクトルデータベース

この用語の意味

ベクトルデータベースは、文章や画像を数値化したベクトルを保存し、意味や特徴が近い情報を検索するためのデータベースです。質問をベクトルに変換して検索し、近い文書のIDや本文などを取り出します。数値へ変換するエンベディングモデルと、保存・検索するデータベースは別の役割です。

一般的なデータベースが商品番号や金額などの条件検索を行うのに対し、ベクトル検索は「この問い合わせに似た対応記録」といった近さを扱います。既存のデータベースにベクトル検索機能を追加する方式もあり、必ず専用製品を新設するわけではありません。

架空の機器販売会社なら、顧客の「電源は入るが画面が映らない」という相談から、表現の異なるFAQ候補を探せます。候補に製品区分や対応期限の条件を重ねれば、別製品や旧版の説明を減らせます。検索文書を生成AIへ渡すRAGでも、根拠となる候補を取り出す部分に使われます。

データベース自身が内容の真偽を判定したり、社内の承認を代行したりするわけではありません。似た文書をすばやく探せても、その文書が誤っていれば回答の根拠にはできません。文書数が少なく、一覧や全文検索で十分なら導入を急ぐ必要はありません。

文書を適切な長さに分ける仕組み、埋め込みモデル、検索基盤に加え、文書ID・版・分類・閲覧可能な利用者などの付帯情報が必要です。登録だけでなく、更新・削除時に検索先へ反映する処理と担当者も決めます。原本の保存先と、検索用の複製を区別して管理します。

費用は文書の数値化、ベクトルと本文の保存容量、検索回数、応答速度の要件、バックアップなどで変わります。高い検索速度と多くの候補の取りこぼしにくさを両立させる設定ほど、計算資源が増える場合があります。月額の表示価格だけでなく更新処理と監視の工数も見積もります。

統一された一つの製品ではありません。提供元の仕様で次元数・距離の計算方式・付帯情報の絞り込み・更新反映のタイミングを確認します。Pineconeのメタデータフィルターは実装例であり、同じ仕様がすべての製品にあるわけではありません。

実在顧客を含まない架空FAQを50件作り、製品区分と公開範囲を付けて登録します。質問30件について正しいFAQを先に決め、完全一致検索と比較します。よくある質問だけでなく、型番違い、該当文書なし、旧版を指定する質問も含めます。

記録するのは上位3件への正解の入り方、応答時間、閲覧不可文書の混入、改訂・削除の反映です。例として「正解包含率90％以上、権限外文書の返却0件、合意した更新時間内に旧版が消える」を試行基準にできます。数字は当該試行の目標で、製品性能の保証ではありません。

次にFAQを1件更新し、1件削除して再検索します。登録直後の品質だけでなく、毎月の更新を担当者が続けられるかを確認します。条件を満たせなければ原因を文書・数値化・検索設定・権限処理に分け、元のFAQ検索を継続します。

近似検索を使う場合、速度のために厳密な最近傍を必ず返すとは限りません。上位に出た結果だけを見るのではなく、必要な根拠が抜けていないかを正解付き質問で調べます。返す件数を増やすだけでは、無関係な文書や生成AIへ渡す量も増えます。

閲覧権限の絞り込みは、利用者が指定した文字列をそのまま信頼せず、認証済みの権限と結び付けます。検索用複製、キャッシュ、バックアップに残る文書の扱いも決めます。元文書を削除しただけで、関連するすべての保存先から即座に消えるとは限りません。