Docs Menu
Docs Home
/
MongoDB Atlas
/

ベクトル検索のパフォーマンス向上

項目一覧

  • ベクトル次元の縮小
  • クエリを実行するときにベクトルのインデックスを作成するのを避ける
  • 事前データのフィルタリング
  • 専用検索ノードの使用
  • 結果からベクトル フィールドを除外する
  • 十分なメモリを確保する
  • ファイルシステム キャッシュをウォームアップする
  • {0binData ベクトルを使用
  • ベクトル埋め込みの量子化

Atlas Vector Search を使用すると、選択した製品に類似する結果を検索したり、画像を検索したりする ANNクエリを実行できます。 インデックス速度とクエリパフォーマンスを向上させるには、次のベストプラクティスの採用を検討しましょう。

Atlas Vector Search は最大 4096までのベクトル次元をサポートします。 ただし、ベクトルが大きいほど、より多くの浮動小数点比較が必要になるため、ベクトル検索のインデックス作成とクエリは計算負荷が高くなります。 したがって、可能な場合は、埋め込みモデルの変更がベクトルクエリの精度に与える影響を測定できることを確認した後、次元数を減らすことをお勧めします。

ベクトル埋め込みは、インデックス作成中に計算リソースを消費します。 ベクトル検索中は、インデックス作成と再インデックス作成を避けることをお勧めします。 インデックスするベクトルを生成する埋め込みモデルを変更する場合は、現在使用しているインデックスをアップデートするのではなく、新しいベクトルを新しいインデックスに再インデックス化することをお勧めします。

より多くのベクトルまたはより高い次元を持つベクトルがある場合は、セマンティック検索の範囲を絞り込むことができ、すべてのベクトルが比較で考慮されないようにできます。filter $vectorSearchパイプライン内に オプションを含めることをお勧めします。これにより、ベクトル検索を実行するドキュメント数を減らすために事前フィルタリングが実行されます。また、大きな配列ではクエリのパフォーマンスが低下する可能性があるため、非常に高次元のベクトルのパフォーマンスへの影響も考慮してください。

mongodmongotプロセスと プロセスを 同じノードに配置すると、プロセス間でリソース競合が発生する可能性があります。 Atlas ベクトル検索クエリのパフォーマンスを最適化するには、専用の検索ノードmongot プロセスを配置することをお勧めします。これにより、mongot プロセスと プロセス間のリソース競合が回避されるだけでなく、検索ノード上のmongod $vectorSearchクエリに対してデフォルトで並列セグメント検索が有効になります。

$projectステージでは、結果内のドキュメントの既存のフィールドと、新しく計算されたフィールドを返すようにリクエストできます。 クエリのパフォーマンスを向上させるには、結果内にすべてのフィールドが必要な場合を除き、 $projectステージを使用して結果の中に返すフィールドを判断して結果の中に返すフィールドを判断します。 ベクトル埋め込みが大きく、結果を返す際にクエリのレイテンシに影響する可能性があるため、 $projectステージではベクトル フィールドを除外することをお勧めします。

Hierarchical Navigable Small Worlds は、ベクトルデータがメモリに保持されている場合に効率的に機能します。データ ノードには、ベクトルデータとインデックスを保持するのに十分なRAMがあることを確認する必要があります。データ分離のないワークロード分離のために、個別の検索ノードを配置することをお勧めします。これにより、ベクトル検索のユースケースでメモリをより効率的に使用できます。

ベクトル検索を実行すると、クエリは最初に Hierarchical Navigable Small Worlds を走査する際にディスクに対してランダムな検索を実行します。 グラフとベクトル値はメモリに読み込まれます。これにより、最初のクエリのレイテンシが非常に高くなります。 Hierarchical Navigable Small Worlds のレイテンシが改善されました 走査はインデックス付きベクトルをメモリに読み取り、後続のクエリでより迅速にアクセスできるようにします。

ただし、大規模な書き込みが行われた場合や、インデックスが再構築された場合に、このキャッシュ ウォーミング プロセスを繰り返す必要があります。

BinDataベクトルサブタイプは、 3mongodで浮動小数ベクトルを使用すると xストレージを節約し、int8 ベクトルやint1 ベクトルなどの代替型を持つベクトルのインデックス作成もサポートします。これにより、リソースプロファイルが大幅に削減され、 がmongod クエリごとにデータベースからドキュメントを取得するために使用する内部クエリ$vectorSearch パスが高速化されます。binData 浮動小数を使用している場合でも、binData ベクトルを使用すると、特にlimit (結果の数)が20 より大きい場合、クエリレイテンシが大幅に迅速化します。

スカラー量子化により、32 ビットの浮動小数点数を8 ビット整数に変換するなど、個々の単位の精度が低下します。ただし、ほとんどの埋め込みモデルで関連情報を適切に取得する能力は保持されています。一方、バイナリ量子化ではベクトルは1 または0 に削減され、QAT 埋め込みモデルのパフォーマンスが向上します。

スカラー量化は、ほとんどの埋め込みモデルからのベクトルの再現率を保持するのに適しています。QAT 埋め込みモデルからのベクトルがある場合、バイナリ量子化ではパフォーマンスが向上します。これは、訓練プロセスによってモデルが精度の極端な低下に適応するように訓練されるためです。

戻る

結果を評価する