前置き
こんにちは！データエンジニアの山口歩夢です。
最近、Amazon Bedrockを使ってChatbotを作成した際に、Amazon OpenSearch ServerlessをベクトルDBとして使用したのですが、Terraformを用いてデプロイする際に、いくつかの課題に直面しました。
OpenSearchの基礎知識や用語を理解していれば、スムーズにデプロイ進められたと思うので、それらに焦点を当ててまとめることにしました。
ちなみに、Amazon BedrockとAmazon OpenSearch ServelessをTerraformでデプロイする方法については、以下の記事を参考にしました。
本題
それでは本題に進んでいきます。
Amazon BedrockのベクトルDBとして、OpenSearch Serverlessを使用するのに役立つ基礎知識に絞ってまとめます！
以下がOpenSearchの公式ドキュメントで、こちらを読み解いて理解してきました。
OpenSearchとは
AWSが提供するフルマネージドな分散型検索・分析エンジンです。大量のデータをリアルタイムで検索することができます。
RDBと似ている気がしますが違いは簡単にまとめると以下のようなイメージです。
ログ分析や検索システムを構築するのであれば、OpenSearchを使うのが良さそうです。
| 項目 | OpenSearch | RDB |
|---|---|---|
| データ構造 | JSON形式 | テーブル形式 |
| 主な用途 | ログ分析、全文検索、リアルタイム分析 | データの永続化、トランザクション管理 |
| 柔軟性 | 高い柔軟性（非構造化・半構造化データに強い） | 構造化データに強い |
Documentとは
OpenSearchでは、「Document」という単位でデータが格納されます。
データベースで言うところの、「行」のようなものです。
この「Document」は、JSON形式で保存されます。
OpenSearchとRDBのデータ構造の違い
データ構造の違いは以下のようなイメージです。
Document(OpenSearch)
OpenSearchでは、JSON形式でドキュメントが格納されます。
{
"id": 1,
"name": "Taro Yamada",
"email": "taro@example.com"
}
行(RDB)
RDBでは、テーブル形式でレコードが格納されます。
| id | name | |
|---|---|---|
| 1 | Taro Yamada | taro@example.com |
Indexとは
「Index」は先述した「Document」の集まりのことです。
RDBで言うところの「テーブル」のようなものです。
複数のChatbotのRAGを作成する必要があり、それぞれユースケースが異なる場合(例: 社内ドキュメントBot、カスタマーサポートBotなど)などは、Index毎に格納するデータを分けると良さそうです。
Collectionとは
Amazon OpenSearch Serverlessでは、「Collection」という単位で複数のIndexを管理します。
Collectionは、特定のワークロードやユースケースに対応するIndex群をグループ化したもので、データ転送時には暗号化が施され、セキュリティも確保されています。
通常のOpenSearchとは異なり、Clusterのプロビジョニングやチューニングが不要で、ユーザーはインデックスやデータの管理に集中できます。
「Collection」はOpenSearch Serverlessならではの概念で、通常のOpenSearchでは、Clusterがデータ管理の基本単位となっています。
Clusterは、複数のNode（サーバー）の集まりで、これらのNodeが協力しながらデータを格納・検索します。
Collectionのタイプとは
OpenSearch Serverlessでは、以下の3つのタイプのCollectionをサポートしています。
Amazon BedrockのベクトルDBとして使用する場合は、「VECTOR SEARCH」を使います。
- VECTOR SEARCH
- ベクター検索に有用。自然言語処理などのデータを高次元のベクトル空間に変換し、そのベクトル間の距離を測ることで関連性を判定します。
- SEARCH
- 一般的な検索に有用。文書検索や、フィルタリング、キーワード検索など、通常の全文検索など。
- Time series
- 時系列データの取り扱いに有用。時間に沿って変化するデータ（例：金融データ、ログデータなど）を格納および分析など。
Policyとは
Amazon BedrockのベクトルデータベースとしてAmazon OpenSearch Serverlessを利用する場合、以下の3種類のPolicy設定が必要です。これらのPolicyを適切に設定することで、OpenSearch内のデータセキュリティを強化できます。
Security Policy
誰がOpenSearchにアクセスできるかを制御するポリシーです。
このポリシーを設定することで、特定のVPCからのアクセスに限定したり、指定したAWSリソースからのみアクセスを許可することができます。
Amazon BedrockのベクトルDBとしてOpenSearchを使う場合は、Amazon Bedrockからのみアクセスできるように制御すると良さそうです。
Data Access Policy
OpenSearchのインデックスに対して、どのユーザーがどのような操作（更新、読み取り、書き込みなど）を行えるかを制御します。必要最小限のアクセス権限を付与することで、不正な操作を防止できます。
Encryption Policy
OpenSearchに保存されるデータを暗号化し、データの機密性を保護します。このポリシーを適用することで、保存データの漏洩リスクを軽減し、セキュリティを強化できます。
MappingsとField
まず、「Field」とはDocumentの属性やプロパティのことです。
RDBの「列」に似た概念で、Index内に保存されるキーと値のペアです。
そして、「Mappings」は、OpenSearchにおいてFieldのデータ型を設定し、データの保存方法や検索方法を制御するものです。
Amazon BedrockのベクトルDBとしてOpenSearchを使用する場合、以下のような設定を行います。
{
"mappings": {
"properties": {
"chatbot_vector": {
"type": "knn_vector",
"dimension": 1024,
"method": {
"name": "hnsw",
"engine": "faiss",
"parameters": {
"m": 16,
"ef_construction": 512
},
"space_type": "l2"
}
},
"AMAZON_BEDROCK_METADATA": {
"type": "text",
"index": false
},
"AMAZON_BEDROCK_TEXT_CHUNK": {
"type": "text"
}
}
}
}
chatbot_vectorがベクトル検索に使われるField、AMAZON_BEDROCK_TEXT_CHUNKがテキスト検索に使用されるFieldになります。
ベクトル検索とテキスト検索を同時に行えるので、ハイブリッド検索に有用な構成となっています。
AMAZON_BEDROCK_METADATAはindexパラメータがfalseになっているので検索には使用されませんが、ナレッジベースに関連するメタデータを格納するFieldとして用意が必須です。
まとめ
Amazon BedrockのベクトルDBとしてOpenSearch Serverlessを使うにあたって知っておくと便利な用語をまとめさせていただきました！
皆様のお役に立てましたら幸いです。
宣伝
最後にお知らせをさせていただきます。
先日、Streamlitの書籍を出版致しました。
Streamlitを活用することで、Pythonだけでデータ可視化アプリケーションやChatbotを開発する方法を解説させていただいております。