[AWS]BedrockとOpenSearchで始める、全く新しいベクトルDB入門

Amazon BedrockでOpenSearchをベクトルDBとして使う際、インデックス、マッピング、k-NNアルゴリズムの設定が重要です。運用にはベクトルデータとメタデータ（元のテキストやスキーマ情報）が必要。テーブル名やカラム情報をメタデータとして格納することで、セマンティック検索やRAGのプロンプト精度を高め、LLMの応答品質を向上させることができます。

BedrockのOpenSearch Vector DBが定義するもの

Amazon BedrockでOpenSearchをベクトルデータベースとして利用する場合、主に以下の要素を定義します。

1. インデックス:

OpenSearchにおけるインデックスは、データの集合体です。ベクトルデータを保存する際には、インデックスを作成し、そこにドキュメントとしてベクトルを投入します。

2. マッピング:

マッピングは、インデックス内のドキュメントのフィールドとそのデータ型を定義するスキーマです。ベクトルデータを扱う上で、特に重要なのは以下のフィールドです。

• ベクトルフィールド: ベクトルデータを格納するフィールドです。knn_vectorデータ型を使用し、次元数を指定する必要があります。
• メタデータフィールド: ベクトルに対応する元のテキストや、カテゴリ、タイムスタンプなど、検索やフィルタリングに利用したい情報を格納します。テキスト、キーワード、数値、日付など、様々なデータ型を利用できます。

3. k-NNアルゴリズム設定:

類似度検索（k-NN検索）を実行するためのアルゴリズムを設定します。主な設定項目は以下の通りです。

• engine: 類似度検索に使用するエンジン（例: faiss, nmslib, hnswなど）を指定します。
• space_type: ベクトル間の距離を計算する方法（類似度指標）を指定します。
  • l2 (ユークリッド距離): 2つのベクトルの距離を測定します。
  • cosine (コサイン類似度): 2つのベクトルの方向の類似度を測定します。
  • ip (内積): 2つのベクトルの内積を計算します。
• parameters: 選択したエンジンに応じたパラメータ（例: ef_construction, mなど）を設定します。これらのパラメータは、インデックスの構築速度や検索精度に影響します。

運用で入れる必要があるデータ

運用でOpenSearch Vector DBに入れる必要があるデータは、以下の2種類です。

1. ベクトルデータ (埋め込み):

これは、テキストや画像などのデータをAIモデル（Amazon Titan Embeddingsなど）を使って数値のベクトルに変換したものです。このベクトルこそが、類似度検索の対象となります。

2. メタデータ:

ベクトルに対応する元の情報や、検索を絞り込むための情報です。具体的には、以下のようなデータが考えられます。

• 元のテキスト: ベクトル化する前のテキストです。検索結果として表示したり、ユーザーに元の情報を提示するために必要です。
• ID: 各ドキュメントを一意に識別するためのIDです。
• カテゴリ/タグ: 検索を特定のカテゴリに絞り込みたい場合に利用します。
• タイムスタンプ: 最新の情報のみを検索したい場合などに利用します。
• URL/パス: 関連するファイルやウェブサイトへのリンクです。
• 作成者/著者: 検索結果を特定の人物に絞り込みたい場合に利用します。

テーブル名とカラムのスキーマデータを効果的に入れる方法

テーブル名とカラムのスキーマデータをOpenSearch Vector DBに入れることは、単にデータを格納するだけでなく、検索の質を向上させる上で非常に効果的です。

効果的な使い方

1. メタデータとして格納:テーブル名、カラム名、データ型、説明などの情報を、元のテキストと共にメタデータとして格納します。これにより、以下のことが可能になります。
   • セマンティック検索の実現: ユーザーが「注文IDについて教えて」と自然言語で尋ねたときに、order_idというカラム名や、それが含まれるテーブルのスキーマ情報がベクトル化されていれば、関連するドキュメントをより正確に検索できます。
   • フィルタリング: 特定のテーブルやカラムに関する情報のみを検索対象にしたい場合に、メタデータを使ってフィルタリングできます。
   • 検索結果のコンテキスト提供: ユーザーに検索結果を提示する際に、「これはcustomersテーブルのcustomer_idカラムに関する情報です」といった形で、より詳細なコンテキストを提供できます。
2. プロンプトエンジニアリングへの活用:RAG（Retrieval-Augmented Generation）のような仕組みを構築する場合、検索で得られたスキーマ情報やカラムの定義を、プロンプトの一部としてLLMに渡すことができます。
   • 具体的なプロンプト例:「以下のスキーマ情報に基づいて、ユーザーの質問に答えてください。テーブル名: customersカラム:
     • customer_id (数値): 顧客を一意に識別するID
     • first_name (文字列): 顧客の名
     • last_name (文字列): 顧客の姓ユーザーの質問: 顧客12345の名前は何ですか？」
   これにより、LLMはより正確な情報を生成し、ユーザーの質問に適切に答えることが可能になります。

まとめ

テーブル名とカラムのスキーマデータを、単にデータベースのスキーマとしてではなく、ベクトル化するテキストの一部、あるいは検索後のフィルタリングやプロンプトのコンテキストとして利用するメタデータとしてOpenSearch Vector DBに入れることで、検索精度とLLMの応答品質を大幅に向上させることができます。これにより、単なるキーワード検索ではなく、よりセマンティックでコンテキストを理解した検索システムを構築できます。