ベクトルデータベースの選択

やでは、したを保存して素早く探す仕組みが必要です。 AIF-C01では、AWSのどのサービスがベクトルの保管先になるかを問われます。

概要

は、を保存し、指定したベクトルに近いものを高速に返します。専用の索引を使うため、大量のベクトルでも実用的な速度で検索できます。

AWSでは、既存のデータベースや検索サービスにの機能が用意されているほか、ベクトルを安く大量に保管するための専用のストレージ () もあります。

主要技術

①ベクトル検索に使えるAWSサービス ⚠️ 頻出

サービス	位置づけ	選ぶ理由
(Serverless含む)	検索との両方を扱えます。	全文検索とを併用したい場合。知識ベースの保管先としてもよく使われます。
PostgreSQL	拡張でベクトルを扱えます。	既存のリレーショナルデータと同じ場所で管理したい場合
for PostgreSQL	同じくpgvectorを使えます。	既存のPostgreSQL運用を活かしたい場合
Analytics	グラフとベクトルを組み合わせられます。	関係性とベクトルの両方を使いたい場合
	文書データベースでベクトルを扱えます。	文書指向のデータ構造を使っている場合
(Valkey)	ーでベクトル検索を行えます。	極めて低い遅延が必要な場合。似た質問への回答を再利用する仕組み (セマンティック) にも使えます。
	ベクトル専用のの (ベクトルバケット) に保管し、類似検索を行えます。インフラの準備は不要です。	大量のベクトルを低いコストで保管したい場合。問い合わせの頻度が低い用途に向きます。

⚠️ 頻出: 「キーワード検索とベクトル検索を組み合わせたい」ならAmazon OpenSearch Service、「既存のPostgreSQLへ寄せたい」ならAuroraまたはRDS for PostgreSQL、「大量のベクトルを最も安く保管したい」ならAmazon S3 Vectorsです。

Point

Amazon S3 Vectors は、S3と同じ耐久性と伸縮性を持つ、ベクトル専用の保管先です。
構成は ベクトルバケット → ベクトルインデックス → ベクトル の3段です。
問い合わせが頻繁で、より低い遅延や高度な検索 (ハイブリッド検索、集計) が必要なら、OpenSearch Serviceと組み合わせます。

②選定の観点

観点	見るポイント
既存の構成	すでに使っているデータベースに寄せられるか。
検索の種類	全文検索との併用が必要か。
遅延の要件	ミリ秒未満の応答が必要か。
運用の負担	で済ませたいか。
コスト	保管容量と稼働時間の費用。

③ハイブリッド検索

だけでは、型番や固有名詞の完全一致に弱いことがあります。キーワード検索とを併用するが有効です。

検索方式	得意なこと	苦手なこと
キーワード検索	型番、固有名詞、完全一致	言い換え、意味の近さ
ベクトル検索	言い換え、意味の近さ	完全一致の厳密さ
ハイブリッド	両方を補い合います。	設定が増えます。

④運用上の注意

注意点	内容
の統一	保存時と検索時で同じモデルを使います。
再作成	埋め込みモデルを変えたら全件を作り直します。
更新の反映	元文書の更新に合わせて再取り込みします。
削除	元文書を削除したらも削除します。
暗号化とアクセス制御	保管データをで暗号化し、で制御します。

⚠️ 頻出: 元文書を削除してもベクトルが残っていると、削除済みの内容が回答に混ざります。

試験対策

①選択基準

問題文のキーワード	選ぶサービス
全文検索とを併用したい
既存のPostgreSQLでを扱いたい	PostgreSQL、 for PostgreSQL
グラフの関係性も使いたい	Analytics
文書データベースで扱いたい
極めて低い遅延が必要	(Valkey) のベクトル検索
大量のベクトルを低コストで保管したい、問い合わせは多くない
保管先の選定と運用まで任せたい	のマネージド型の知識ベース

②よくある誤答

には専用のデータベースを新しく用意する必要があると考えること。既存のデータベースや検索サービスの機能で扱えます。
を、問い合わせが非常に多く極めて低い遅延が必要な用途に選ぶこと。低コストの大量保管に向く選択肢です。
の変更を軽く考えること。既存ベクトルとの互換性が失われます。
完全一致の検索要件をベクトル検索だけで満たそうとすること。を検討します。