変更要約: 初版: ドメイン1（FM統合・データ管理・コンプラ）の5節を作成
1.3ベクトルストアソリューションの設計
FM 拡張のためのベクトルデータベース設計を学びます。Amazon Bedrock Knowledge Bases、OpenSearch Service（ベクトル検索/Neural plugin）、Aurora pgvector、DynamoDB、メタデータフレームワーク、増分更新による鮮度維持を扱います。
RAG の心臓部はベクトルストアです。文書を埋め込み（embedding）に変換して格納し、意味的に近いチャンクを検索します。要件（規模・運用・既存資産）に応じてストアを選びます。
1.3.1ベクトルストアの選択
- Amazon Bedrock Knowledge Bases：取り込み・チャンキング・埋め込み・検索をマネージドで一括提供。最小運用で RAG を始める既定の選択。
- OpenSearch Service（ベクトル検索）：大規模・ハイブリッド検索（キーワード＋ベクトル）・シャーディング/階層インデックスで高性能に制御したい場合。
- Aurora（pgvector）：既存のリレーショナルデータと同居してベクトルを持ちたい場合（PostgreSQL 拡張）。
- メタデータフレームワーク：タイムスタンプ・著者・ドメイン分類などのメタデータを付与し、検索の精度とフィルタリングを上げる。
「マネージドで最速に RAG＝Bedrock Knowledge Bases」「大規模＋ハイブリッド検索＝OpenSearch ベクトル検索」「既存 RDB と同居＝Aurora pgvector」「鮮度維持＝増分更新/自動同期」「精度向上＝メタデータ＋フィルタ」 は頻出です。Knowledge Bases は OpenSearch Serverless 等をマネージドのベクトルストアとして利用できます。
ストア選定の軸は「運用負荷」と「制御の細かさ」です。最小運用なら Bedrock Knowledge Bases（データソース＝S3 等を指定すれば取り込み〜検索まで自動）、細かい制御や大規模・ハイブリッド検索なら OpenSearch Service（Neural plugin で Bedrock 埋め込みと統合、シャーディングや複数インデックスで分割）。既存 PostgreSQL/Aurora 資産があれば pgvector で同居。DynamoDB はメタデータ/埋め込みの保管に併用できます。鮮度維持は増分更新（変更検知→該当チャンクのみ再埋め込み）、スケジュール再取り込み、リアルタイム同期で実現。検索精度はチャンク設計・メタデータ・フィルタに大きく依存します。Knowledge Bases は社内 wiki・ドキュメント管理など複数ソースの統合取り込みにも対応します。
| 要件 | 選ぶもの | 特徴 |
|---|---|---|
| 最小運用で RAG | Bedrock Knowledge Bases | 取り込み〜検索を自動 |
| 大規模/ハイブリッド検索 | OpenSearch ベクトル検索 | キーワード＋ベクトル/シャーディング |
| 既存 RDB と同居 | Aurora pgvector | PostgreSQL 拡張 |
| 鮮度維持 | 増分更新/自動同期 | 変更分のみ再埋め込み |
ひっかけ： 「文書が更新されるたびに全件を再埋め込みする」は非効率で誤りです。増分更新（変更検知で該当チャンクのみ再埋め込み）が正解。また「Knowledge Bases は使えないので必ず自前で OpenSearch を構築すべき」も誤り（最小運用が要件なら Knowledge Bases が既定）。
1.3.2この節のまとめ
- 最小運用＝Knowledge Bases／大規模・ハイブリッド＝OpenSearch／RDB同居＝Aurora pgvector
- 精度＝メタデータ＋フィルタ／鮮度＝増分更新
進捗の記録にはログインが必要です。
理解度チェック
（軽い確認用）Q1. 最小の運用負荷で、S3 上の社内文書を使った RAG をすぐ始めたい。取り込み・チャンキング・埋め込み・検索をマネージドで賄える選択は？
Q2. 大規模なナレッジで、キーワード一致と意味的類似度を組み合わせたハイブリッド検索を細かく制御したい。最適なベクトルストアは？
Q3. 既存の Aurora PostgreSQL に業務データがあり、追加インフラを増やさずに埋め込みも同じ DB に保存して検索したい。最適なのは？