ベクトルフィールドと KNN - Elasticsearch - Alibaba Cloud ドキュメントセンター

DiskBBQ は、ベクトルフィールド用のインデックスタイプです。標準インデックスと Collection は、同じ bbq_disk フィールド設定を共有します。Collection 内の Slice スコープでこのタイプのベクトルフィールドを検索する場合、Sliced DiskBBQ が使用され、追加のマッピングパラメータは不要です。以下のセクションでは、DiskBBQ フィールド設定と KNN クエリパラメータについて説明し、オンデマンドでベクトル値を読み取る方法を解説します。まず、標準インデックスの完全な例を実行してください。次の表は、リクエストエンドポイントのクイックリファレンスです。

操作	標準インデックス	Collection
ベクトルフィールドの追加	`PUT /{index}/_mapping`	`PUT /{collection}/_mapping`
最近傍のクエリ	`POST /{index}/_search`	`POST /{collection}/_search?_slice={slice}`

ドキュメントベクトルとクエリベクトルの次元数は、dims と一致する必要があります。以下のセクションの例は Collection を対象としています。標準インデックスを対象とする場合は、実際のインデックス名を使用してください。_slice パラメータは Collection クエリにのみ適用されます。_slice を使用して検索する Slice を指定するか、ベクトルクラスタ再現率モードに基づいてスコープを自動的に選択させることができます。このトピックの最後にある完全な例では、標準インデックスを使用しています。

2 層機能の利点、シナリオ、トレードオフについては、「DiskBBQ 2 層機能」をご参照ください。

フィールド設定とクエリパラメータ

マッピングの設定

はじめにでは、Collection の作成時に DiskBBQ を既に設定しています。ベクトルフィールドがまだない他の Collection については、マッピング API を使用して追加します。

PUT /{collection}/_mapping
{
  "properties": {
    "embedding": {
      "type": "dense_vector",
      "dims": 4,
      "index": true,
      "similarity": "cosine",
      "index_options": {
        "type": "bbq_disk"
      }
    }
  }
}

"type": "bbq_disk" を明示的に指定すると、サーバーは次のデフォルトの index_options 値を設定します。これらのデフォルト値は、ベクトルの次元数に依存しません。

{
  "index_options": {
    "type": "bbq_disk",
    "cluster_size": 384,
    "flat_index_threshold": -1,
    "default_visit_percentage": 0.0,
    "rescore_vector": { "oversample": 3.0 },
    "bits": 1
  }
}

default_visit_percentage は、マッピングレベルのデフォルト値です。クエリレベルの visit_percentage が設定されていない場合に使用されます。クエリレベルのパラメータが優先されます。rescore_vector.oversample は、クエリで上書きできます。cluster_size、flat_index_threshold、bits はサーバーによって管理されるため、調整する必要はありません。

ベクトルの次元数と類似度は、ベクトルを生成するために使用されるモデルと一致させてください。既存のベクトルフィールドのインデックスタイプを切り替えるには、移行先の Collection を作成し、新しいマッピングを設定してから、再インデックスを使用してデータを移行し、評価を再度実行してください。

KNN クエリの実行

クエリでは、knn.field を使用して、マッピングで設定したベクトルフィールドを参照します。次のリクエストでは、visit_percentage を使用して、指定された Slice 内の DiskBBQ のアクセススコープを調整します。

POST /knowledge-chunks/_search?_slice=tenant-a
{
  "knn": {
    "field": "embedding",
    "query_vector": [0.80, 0.12, 0.05, 0.03],
    "k": 10,
    "visit_percentage": 10.0
  },
  "_source": ["document_id", "title", "content"]
}

パラメータ	説明
`k`	検索対象から取得する最近傍の数。実際に返される結果の数は、リクエストのトップレベルの `size` パラメータ (デフォルト: `10`) によっても制限されます。
`visit_percentage`	各シャードでアクセスされるベクトルの割合。有効な値は 0 から 100 です。値を大きくすると、通常、再現率が向上しますが、計算と読み取りのオーバーヘッドも増加します。クエリで明示的に設定された値は、マッピングのデフォルト値を上書きします。最終的な有効値が `0` より大きい場合、`num_candidates` はアクセス割合の決定に使用されなくなります。
`num_candidates`	最終的な有効な `visit_percentage` が `0` の場合、このパラメータを使用して候補の検索範囲を決定します。クエリで明示的に設定された値は、`0` に明示的に設定された場合を含め、マッピングのデフォルト値よりも優先されます。
`filter`	構造化フィルタリングを追加して、無関係な候補を絞り込みます。
`rescore_vector`	元のベクトルを使用して、量子化検索によって返された候補をリスコアリングします。マッピングのデフォルトの `oversample` 値を上書きできます。

デフォルトでは、visit_percentage の有効値は 0 であるため、num_candidates が候補の検索範囲を決定します。検索範囲を割合で制御するには、マッピングで default_visit_percentage を設定するか、クエリで visit_percentage を設定してください。ベクトルクラスタ再現率を使用する場合は、候補 Slice のスコープも設定する必要があります。詳細については、「ベクトルクラスタ再現率リファレンス」をご参照ください。

オンデマンドでのベクトル値の読み取り

通常の検索では、ベクトルを返さないデフォルト設定のまま、_source のみを使用して、アプリケーションに必要なフィールドを選択してください。たとえば、前述の例のタイトルやコンテンツなどです。KNN 検索とリスコアリングはサーバー上で実行されるため、ベクトルをアプリケーションに返す必要はありません。

ベクトル値を検証またはエクスポートする必要がある場合にのみ、必要なフィールドを明示的に取得してください。たとえば、ドキュメントの embedding フィールドを読み取ります。

GET /knowledge-chunks/_doc/chunk-1001?_slice=tenant-a&_source_exclude_vectors=false

_source_exclude_vectors=false を使用して、ベクトルを明示的に取得します。このパラメータは、_source にビジネスフィールドとベクトルの両方を返します。ベクトルを返すと、データの読み取り、再構築、ネットワーク転送のオーバーヘッドが増加するため、ベクトルを検証またはエクスポートする必要がある場合にのみ、このパラメータを使用してください。

返される値は、ベクトルフィールドのストレージ精度に依存します。この例では、デフォルトで float (float32) を使用しています。浮動小数点の丸め誤差は、書き込まれた10進数値が float32 に変換される際や、cosine 類似度のために実行される正規化と復元の両方の過程で発生する可能性があります。フィールドが element_type: bfloat16 を使用している場合、ストレージ精度は float32 よりも低く、誤差がより顕著になります。DiskBBQ がベクトルを取得する場合、量子化エンコーディングから元の値を導出するのではなく、保持されたベクトル値を使用します。ビットレベルの検証や精度評価のために元のモデル出力が必要な場合は、元のベクトルを別途保存してください。

標準インデックスの完全な例

アカウントには、インデックスの作成、データの書き込みおよび読み取りに必要な権限が必要です。Agent Engine Edition インスタンスを作成して接続した後、Kibana Dev Tools で次のリクエストを順番に実行してください。この例では、標準インデックス vector-demo と、設定とクエリワークフローを検証するためにのみ手動で作成した 4 次元のベクトルを使用します。

ステップ 1：ベクトルインデックスの作成

PUT /vector-demo
{
  "settings": {
    "number_of_shards": 1,
    "number_of_replicas": 2
  },
  "mappings": {
    "properties": {
      "title": { "type": "text" },
      "embedding": {
        "type": "dense_vector",
        "dims": 4,
        "similarity": "cosine",
        "index": true,
        "index_options": { "type": "bbq_disk" }
      }
    }
  }
}

まだ存在しないインデックス名を使用してください。本番環境では、ベクトルの次元数と類似度をモデル出力と一致させてください。この例のシャードとレプリカの値は、デモンストレーションのみを目的としています。詳細については、「ノードとレプリカの設定」をご参照ください。

ステップ 2：データの書き込みとクエリ可視性の検証

POST /vector-demo/_bulk
{"index":{"_id":"1"}}
{"title":"Knowledge base search","embedding":[0.80,0.12,0.05,0.03]}
{"index":{"_id":"2"}}
{"title":"Product search","embedding":[0.10,0.75,0.10,0.05]}

標準インデックスへの通常の書き込みでは、アプリケーションコードで refresh を渡したり、_refresh を呼び出したりしないでください。 Bulk レスポンスで errors=false が返されたことを確認した後、自動バックグラウンドリフレッシュによってデータが検索可能になるまで約 5 秒間待機します。結果にまだ新しいドキュメントが含まれていない場合は、別の自動リフレッシュサイクルを待ってから再試行してください。 ID による書き込みの検証および同期的な待機の適用条件の詳細については、「リフレッシュとクエリの可視性」をご参照ください。

ステップ 3：類似ベクトルのクエリ

POST /vector-demo/_search
{
  "knn": {
    "field": "embedding",
    "query_vector": [0.80, 0.12, 0.05, 0.03],
    "k": 2,
    "visit_percentage": 10.0
  },
  "_source": ["title"]
}

timed_out=false と _shards.failed=0 であること、および hits.hits に「Knowledge base search」と「Product search」というタイトルの 2 つのドキュメントが含まれていることを確認します。この例では、リクエストワークフローのみを検証します。実際のベクトル、クエリセット、同時負荷を使用して、再現率とパフォーマンスを評価してください。