Amazon OpenSearch Service のベクトルデータベース機能の説明

この記事は、Amazon OpenSearch Service’s vector database capabilities explained を翻訳したものです。

OpenSearch は、Apache 2.0 ライセンスのもとで提供される、検索、分析、セキュリティ監視、可観測性アプリケーションのためのスケーラブルで柔軟かつ拡張性のあるオープンソースソフトウェアスイートです。OpenSearch には、低レイテンシーの検索と集計を実現する検索エンジン OpenSearch、可視化とダッシュボードツールの OpenSearch Dashboards、アラート、きめ細かいアクセスコントロール、可観測性、セキュリティ監視、ベクトルの処理・格納などの高度な機能を提供するプラグイン群が含まれます。Amazon OpenSearch Service は、OpenSearch を AWS クラウドで簡単にデプロイ、スケール、運用できるようにする、フルマネージドサービスです。

エンドユーザーとして、OpenSearch の検索機能を利用する際、通常、達成したい目的が頭にあります。その目的を達成するために、OpenSearch を利用して情報を集めます (場合によっては、情報そのものが目的であることもあります)。私たちは「検索ボックス」というインターフェースにすっかり慣れており、単語を入力すると、単語と単語のマッチングに基づいて検索エンジンが結果を返してくれます。例えば、家族と暖炉の前でぬくぬく過ごすためにソファーを購入したいとします。Amazon.com にアクセスし、「暖炉のそばに座れる居心地の良い場所」と入力します。残念ながら、Amazon.com でその検索を実行すると、暖炉、ヒーター、インテリア雑貨などが表示されますが、それらは意図したものではありません。問題は、ソファー製造業者が「居心地の良い」「場所」「座る」「暖炉」という単語を製品タイトルや説明に使用していないことです。

近年、検索を強化するために機械学習 (ML) の技術がますます一般的になっています。その中には、埋め込みモデルの使用があります。これは、大量のデータを n 次元の空間にエンコードできるモデルで、各エンティティがベクトル (その空間内のデータポイント) にエンコードされ、類似したエンティティが近くにまとめられるように編成されます。例えば、埋め込みモデルはコーパスの意味をエンコードできます。エンコードされたドキュメントに最も近いベクトルを検索すること、つまり k 最近傍 (k-NN) 検索により、最も意味的に類似したドキュメントを見つけることができます。高度な埋め込みモデルは、複数のモダリティをサポートできます。たとえば、製品カタログの画像とテキストの両方をエンコードし、両方のモダリティで類似性マッチングを可能にします。

ベクトルデータベースは、k-NN インデックスのような専用インデックスを提供することで、効率的なベクトル類似性検索を実現します。また、ベクトルデータと他のデータ型の管理、ワークロード管理、アクセス制御など、その他のデータベース機能も提供します。OpenSearch の k-NN プラグインは、OpenSearch のコアとなるベクトルデータベース機能を提供します。したがって、お客様がカタログで「暖炉のそばに座れる居心地の良い場所」と検索したときに、そのクエリをエンコードして OpenSearch で近傍検索を実行し、暖炉の前にデザイナーが配置した写真のある 8 フィートの青いソファを表示させることができます。

OpenSearch Service をベクトルデータベースとして利用する

OpenSearch Service のベクトルデータベース機能を使用すると、セマンティック検索、LLM を用いた検索拡張生成 (RAG)、レコメンドエンジン、リッチメディアの検索などを実装できます。

セマンティック検索

セマンティック検索を使用すると、検索ドキュメントに言語ベースの埋め込みを適用することで、検索結果の関連性を向上させます。検索ユーザーは「暖炉のそばに座れる居心地の良い場所」といった自然言語クエリを使って、8 フィートの青いソファを見つけることができます。詳細は、Building a semantic search engine in OpenSearch を参照してください。ここでは、キーワード検索と比較して、nDCG (normalized Discounted Cumulative Gain) メトリクスで測定したときに、セマンティックサーチが 15% の関連性向上を実現できることを学ぶことができます。具体例として、
Semantic and Vector Search with Amazon OpenSearch Service ワークショップでは、BERT (Bidirectional Encoder Representations from Transformers) モデルに基づいて、キーワード検索とセマンティック検索の違いを探っています。このモデルは Amazon SageMaker でホストされ、ベクトルを生成し OpenSearch に保存します。このワークショップでは、製品の Q&A を例に使って、キーワード/フレーズのクエリを使用したキーワード検索がいくつかの不適切な結果につながることを示しています。一方、セマンティック検索は、クエリのコンテキストと意味をマッチングすることで、より適切なドキュメントを検索することができます。次の図は、ベクトルデータベースとして OpenSearch Service を使用したセマンティック検索アプリケーションのアーキテクチャ例を示しています。

LLM による検索拡張生成 (RAG)

RAGは、OpenAI、ChatGPT、Amazon Titan Text などの LLM を使用して生成 AI チャットボットを構築する手法です。生成 LLM の台頭に伴い、アプリケーション開発者はこの革新的なテクノロジーを活用する方法を探しています。一つの人気のあるユースケースは、知的エージェントを通じて会話体験を提供することです。あなたは、製品情報、カスタマーセルフサービス、税務報告ルールや疾患と治療に関する医療情報などの業界ドメイン知識のナレッジベースを持つソフトウェアプロバイダーかもしれません。会話型の検索体験は、ユーザーが対話や Q&A を通じて情報をふるい分けるための直感的なインターフェースを提供します。生成 LLM 自体は、モデルが事実とは異なるが真実味のある応答を生成するハルシネーションに陥りやすいです。RAG は、LLM を外部ナレッジベースで補完することにより、この問題を緩和します。このナレッジベースは、通常、ベクトルエンコードされた知識記事で埋め尽くされたベクトルデータベースを用いて構築されます。

以下の図に示されているように、クエリのワークフローは、エンコードされ、ベクトルデータベースから関連する知識記事を検索するために使用される質問から始まります。その結果は生成 LLM に送信されます。生成 LLM の役割は通常、会話型のレスポンスとして結果を要約することによって、それらの結果を拡張することです。生成モデルにナレッジベースを組み合わせることで、RAG はモデルを事実に基づくようにして、ハルシネーションを最小限に抑えます。セマンティックサーチワークショップの RAG モジュールでは、RAG ソリューションの構築方法の詳細をご覧いただけます。

レコメンドエンジン

レコメンドは、特に EC サイトでは検索体験において一般的なコンポーネントです。「こんな商品はいかが」や「この商品を買った人はこんな商品も買っています」といったユーザーエクスペリエンスを追加することで、ユーザーの欲しいものを提供して更なる収益を得ることができます。検索アーキテクトは、Two-tower ニューラルネットモデル、YoutubeDNN などのディープニューラルネットワーク (DNN) ベースの推薦アルゴリズムを含む様々な技術とテクノロジーを採用してレコメンドシステムを構築しています。例えば、学習済みの埋め込みモデルは、一緒に購入されることが多い商品を類似度が高いとしてエンコードすることで、埋め込み空間内でより近いデータポイントとして表現します。もう一つの可能性は、商品の埋め込みが購買活動ではなく、評価の類似性に基づいている場合です。この親和性データを利用するには、特定のユーザーの埋め込みとデータベース内のベクトル間のベクトル類似度を計算し、推奨アイテムを返します。次の図は、OpenSearch をベクトルストアとして使用してレコメンドエンジンを構築するアーキテクチャ例を示しています。

メディア検索

メディア検索を使用すると、ユーザーは画像、音声、動画などのリッチメディアを使用して検索エンジンにクエリできます。その実装はセマンティック検索と同様です。検索ドキュメントの埋め込みベクトルを作成し、ベクトルを使用して OpenSearch Service にクエリします。違いは、ResNet のようなコンピュータビジョン深層学習モデル (例えば畳み込みニューラルネットワーク (CNN)) を使用して、画像をベクトルに変換することです。次の図は、ベクトルストアとして OpenSearch を使用した画像検索のアーキテクチャ例を示しています。

技術を理解する

OpenSearch は、k-NN 検索を実現するために、NMSLIB、FAISS、Lucene ライブラリから近似最近傍探索 (ANN) アルゴリズムを使用しています。これらの検索手法は、大規模なデータセットの検索レイテンシを改善するために ANN を採用しています。k-NN プラグインが提供する 3 つの検索手法の中で、この手法は大規模なデータセットに対して最もスケーラブルな検索を実現します。エンジンの詳細は次のとおりです。

Non-Metric Space Library (NMSLIB) – NMSLIB は HNSW ANN アルゴリズムを実装しています
Facebook AI Similarity Search (FAISS) – FAISS は HNSW と IVF ANN アルゴリズムの両方を実装しています
Lucene – Lucene は HNSW アルゴリズムを実装しています

近似 k-NN 検索に使用される 3 つのエンジンは、それぞれがある状況下で他のエンジンよりも適している独自の属性を持っています。このセクションの一般情報に従うことで、要件を最も満たすエンジンを判断する助けとなるでしょう。

概して、大規模なユースケースには NMSLIB と FAISS を選択する必要があります。Lucene は小規模なデプロイメントに適していますが、状況に応じて最適なフィルタリング戦略 (事前フィルタリング、事後フィルタリング、Exact k-NN) が自動的に適用されるなどの利点があります。次の表は、各オプションの違いを要約しています。

.	NMSLIB-HNSW	FAISS-HNSW	FAISS-IVF	Lucene-HNSW
最大次元数	16,000	16,000	16,000	1,024
フィルタ	Post filter	Filter while search (OpenSearch 2.9 以降)	Filter while search (OpenSearch 2.10 以降)	Filter while search (OpenSearch 2.4 以降)
トレーニングの必要性	不要	不要	必要	不要
類似度指標	l2, innerproduct, cosinesimil, l1, linf	l2, innerproduct	l2, innerproduct	l2, cosinesimil
ベクトル容量	数十億	数十億	数十億	1,000万未満
インデクシングのレイテンシ	低	低	最低	低
クエリのレイテンシと品質	低レイテンシ、高品質	低レイテンシ、高品質	低レイテンシ、低品質	高レイテンシ、高品質
ベクトル圧縮	Flat	Flat, Product Quantization (PQ)	Flat, Product Quantization (PQ)	Flat
メモリ消費量	高	高, PQ使用時は低	中, PQ使用時は低	高

近似最近傍検索 (Approximate k-NN) と最近傍検索 (Exact k-NN)

OpenSearch Service の k-NN プラグインは、ベクトルのインデックスから k 最近傍を得るための 3 つの異なるメソッドをサポートしています。それは、近似 k-NN、スコアスクリプト (Exact k-NN)、Painless 拡張 (Exact k-NN) です。

近似 k-NN

最初の方法は、近似最近傍検索のアプローチです。これは、いくつかのアルゴリズムの 1 つを使用して、クエリベクトルに対して k 個のおおよその最近傍ベクトルを返します。通常、これらのアルゴリズムは、インデクシング速度や検索精度を犠牲にする代わりに、レイテンシの低減、メモリフットプリントの縮小、スケーラブルな検索などのパフォーマンス上のメリットを得ます。近似 k-NN は、低レイテンシを必要とする大規模なインデックス (つまり、数十万ベクトル以上) に対する検索に最適です。k-NN 検索の前にインデックスにフィルタを適用して検索対象のベクトル数を大幅に減らす場合は、近似 k-NN を使用しないでください。この場合は、スコアスクリプトまたは Painless 拡張を使用する必要があります。

スコアスクリプト

2 つ目の方法は、OpenSearch Service のスコアスクリプト機能を拡張して、knn_vector フィールドやバイナリオブジェクトを表すことができるフィールドに対して、Exact k-NN 検索を総当たりで実行することです。このアプローチでは、インデックス内のベクトルのサブセットに対して k-NN 検索を実行できます (時に pre-filter 検索と呼ばれます)。このアプローチは、ドキュメントの一部に対する検索や pre-filter が必要な場合に推奨されます。大規模なインデックスでこのアプローチを使用すると、高いレイテンシが発生する可能性があります。

Painless 拡張

3 つ目の方法は、より複雑な組み合わせで使用できる Painless 拡張として距離関数を追加するというものです。k-NN スコアスクリプトと同様に、この方法を使用すると、インデックス全体で Exact k-NN 検索を総当たりで実行できます。これは pre-filter もサポートしています。このアプローチは、k-NN スコアスクリプトと比較すると、クエリパフォーマンスがわずかに低下します。最終スコアについてより高度なカスタマイズが必要な場合は、スコアスクリプト k-NN よりもこのアプローチを使用する必要があります。

ベクトル検索アルゴリズム

類似ベクトルを見つける簡単な方法は、k-最近傍 (k-NN) アルゴリズムを使用することです。これは、クエリベクトルとベクトルデータベース内の他のベクトル間の距離を計算します。先ほど説明したとおり、スコアスクリプト k-NN と Painless 拡張の検索方法は、内部的に Exact k-NN アルゴリズムを使用しています。ただし、次元数が高く極めて大規模なデータセットの場合、これは検索効率を低下させるスケーリングの問題を生じます。近似最近傍 (ANN) 検索は、インデックスをより効率的に再構築し、検索可能なベクトルの次元数を削減するツールを採用することで、これを克服できます。ANN 検索アルゴリズムにはさまざまな種類があります。例えば、局所性鋭敏型ハッシュ、ツリーベース、クラスターベース、グラフベースなどがあります。OpenSearch は、HNSW (Hierarchical Navigable Small Worlds) と IVF (Inverted File System) の 2 つの ANN アルゴリズムを実装しています。OpenSearch で HNSW アルゴリズムと IVF アルゴリズムがどのように機能するかのより詳細な説明については、ブログ記事「OpenSearch における 10 億規模のユースケースに適した k-NN アルゴリズムの選定」をご覧ください。

HNSW

HNSW アルゴリズムは、ANN 検索のための最も一般的なアルゴリズムの 1 つです。このアルゴリズムの核となるアイデアは、互いに近いインデックスベクトルを結ぶエッジでグラフを構築することです。そして、検索時にこのグラフを部分的に探索して、クエリベクトルのおおよその最近傍を見つけます。クエリの最近傍に向けて探索を誘導するために、アルゴリズムは常にクエリベクトルに最も近い候補を次に探索します。

IVF

IVF アルゴリズムは、インデックスベクトルをバケットのセットに分割します。そして、検索時間を短縮するために、それらのバケットのサブセットだけを検索します。しかし、もしこのアルゴリズムがベクトルをランダムに異なるバケットに分割し、その一部だけを検索するのでは、劣った近似になってしまいます。IVF アルゴリズムは、よりエレガントなアプローチを用います。まず、インデクシングをする前に、各バケットに代表ベクトルを割り当てます。ベクトルがインデックス付けされると、最も近い代表ベクトルを持つバケットに追加されます。このようにすることで、互いに近いベクトルはおおよそ同じまたは近いバケットに配置されます。

ベクトルの類似度指標

すべての検索エンジンは、類似度指標を使用して結果をランク付けおよびソートし、最も関連性の高い結果を上位に表示します。プレーンテキストのクエリを使用する場合、類似度指標は TF-IDF と呼ばれ、クエリ内の用語の重要性を測定し、テキストの一致数に基づいてスコアを生成します。クエリにベクトルが含まれている場合、類似度指標は空間的な性質を持ち、ベクトル空間内の近接性を利用します。OpenSearch は、いくつかの類似度または距離尺度をサポートしています。

ユークリッド距離 – 点間の直線距離です。
L1 (マンハッタン) 距離 – すべてのベクトル成分の差分の和です。L1 距離は、例えて言うと点 A から点 B へ移動するのに必要な直交する市街地のブロック数を測定します。
L-∞ (チェス盤・チェビシェフ) 距離 – 例えると、n 次元のチェス盤上をキングが移動する手数です。対角線上ではユークリッド距離とは異なります。つまり、2 次元のチェス盤での対角ステップは、ユークリッド距離で 1.41 単位離れていますが、L-∞ 距離では 2 単位離れています。
内積 – 2 つのベクトルの大きさとその間の角度のコサインの積です。通常、自然言語処理 (NLP) のベクトル類似度に使用されます。
コサイン類似度 – ベクトル空間内の 2 つのベクトル間の角度のコサインです。
ハミング距離 – 2 進符号化されたベクトルについて、2 つのベクトル間で異なるビットの数です。

OpenSearch をベクトルデータベースとして利用するメリット

OpenSearch Service をベクトルデータベースとして使用する場合、使いやすさ、スケーラビリティ、可用性、相互運用性、セキュリティなどのサービス機能を活用できます。より重要なことに、OpenSearch の検索機能を利用して検索エクスペリエンスを向上させることができます。たとえば、OpenSearch の Learning to Rank 機能を使用して、ユーザーのクリックスルー動作のデータを検索アプリケーションに統合し、関連性を向上させることができます。また、OpenSearch のテキスト検索とベクトル検索の機能を組み合わせて、キーワードとセマンティックな類似性に基づいてドキュメントを検索することもできます。インデックスの他のフィールドを使用してドキュメントをフィルタリングし、関連性を向上させることもできます。上級者向けには、ハイブリッドスコアリングモデルを使用して、Okapi BM25 関数によって計算される OpenSearch のテキストベースの関連度スコアとベクトル検索スコアを組み合わせ、検索結果のランキングを改善することができます。

スケールと制限

OpenSearch はベクトルデータベースとして、数十億のベクトルレコードをサポートします。クラスタのサイズを決定する際には、ベクトルの数と次元に関する以下の計算を念頭に置いてください。

ベクトルの数

OpenSearch VectorDB は OpenSearch のシャーディング機能を活用し、ベクトルをシャード化し水平方向にノードを追加することで、1 桁ミリ秒のレイテンシで数十億個のベクトルまでスケールできます。1 台のマシンに収まるベクトル数は、そのマシンのオフヒープメモリの可用量の関数で決まります。必要なノード数は、ノードごとにアルゴリズムで使用できるメモリ量と、アルゴリズムが必要とするメモリの総量に依存します。ノードが多いほど、メモリが増え、パフォーマンスが向上します。ノードごとに利用可能なメモリ量は、 memory_available = (node_memory – jvm_size) * circuit_breaker_limit として計算されます。パラメータの説明は以下の通りです。

node_memory – インスタンスの全メモリ容量。
jvm_size – OpenSearch の JVM ヒープサイズ。これはインスタンス RAM の半分に設定され、約 32 GB で上限が設定されます。
circuit_breaker_limit – サーキットブレーカーのネイティブメモリ使用量のしきい値。これは 0.5 に設定されます。

クラスター全体のメモリ見積もりは、ベクトルレコード数とアルゴリズムに依存します。HNSW と IVF には異なるメモリ要件があります。詳細については、Memory Estimation を参照してください。

次元数

OpenSearch のベクトルフィールド knn_vector に対する現在の次元制限は 16,000 次元です。各次元は 32 ビットの浮動小数点数で表されます。次元数が多いほど、インデクシングと検索に必要なメモリが多くなります。次元数は通常、エンティティをベクトルに変換する埋め込みモデルによって決定されます。knn_vector フィールドを構築する際に選択できるオプションはたくさんあります。正しいメソッドとパラメータを選択するには、Choosing the right method を参照してください。

お客様のストーリー

Amazon Music

Amazon Music は、ユーザーにユニークでパーソナライズされた体験を提供するために、常にイノベーションを行っています。Amazon Music の音楽レコメンドのアプローチの 1 つは、クラシックな Amazon のイノベーションであるアイテム間の協調フィルタリングとベクトルデータベースのリミックスです。ユーザーのリスニング行動に基づいて集計されたデータを使用し、Amazon Music は、類似したトラックを類似したベクトルとして表現するベクトル空間に、音楽トラックと顧客表現をエンコードする埋め込みモデルを作成しました。10 億曲の楽曲がベクトルにエンコードされ、OpenSearch にインデックスされ、複数の地域に配信されて、リアルタイムのレコメンドを実現しています。OpenSearch は現在、10 億 5,000 万のベクトルを管理しており、Amazon Music のレコメンドを支えるために、ピーク時には 1 秒あたり 7,100 ベクトルクエリを処理しています

アイテム間の協調フィルターは、大規模な顧客基盤と製品カタログへのスケーリングに効果的であることから、オンライン製品レコメンドに最も人気のある方法の 1 つです。OpenSearch はスケールアウトするインフラストラクチャ、トラック数に応じて線形に成長する k-NN インデックス、対数時間での類似性検索を提供することで、レコメンダーの運用とスケーラビリティの向上を容易にしています。次の図は、ベクトル埋め込みによって作成された高次元空間を可視化したものです。

Amazon におけるブランド保護

Amazon は、お客様に本物の商品を最大限幅広く選択していただけるよう努め、世界で最も信頼できるショッピング体験を提供することを目指しています。お客様からの信頼を獲得し維持するために、偽造品の販売を厳しく禁止するとともに、本物の商品のみがお客様のもとに届くことを保証するイノベーションに対して引き続き投資しています。Amazon のブランド保護プログラムは、ブランドを正確に表現し、完全に保護することでブランドとの信頼関係を築いています。私たちが提供する信頼できる体験が世間の認識と一致するよう努めています。当社のブランド保護戦略は、次の 4 つの柱に焦点を当てています。(1)予防管理、(2)ブランドを保護するための強力なツール、(3)不正行為者の責任追及、(4)お客様の保護と教育です。Amazon OpenSearch Service は、Amazon の予防管理の重要な一部を担っています。

2022 年、Amazon の自動化テクノロジーは、商品の詳細ページで潜在的な悪用の兆候を探すために、毎日 80 億件以上の変更の試みをスキャンしました。当社のプロアクティブコントロールは、ブランドがそれを見つけて報告する前に、ブロックまたは削除されたリスティングの 99 %以上を発見しました。これらのリスティングは、詐欺、侵害、偽造、またはその他の形態の悪用のリスクがあると疑われました。これらのスキャンを実行するために、Amazon は、世界中の Amazon の店舗におけるリスティングの知的財産権侵害の検出を自動化するための高度な機械学習モデルの使用など、高度で革新的なテクニックを使用するツールを作成しました。このような自動システムを実装する上での主な技術的課題は、膨大な数十億ベクトルコーパス内で保護された知的財産を、高速かつスケーラブルでコスト効率の良い方法で検索できる能力です。ブランドと自動システムが、高可用かつ高速 (秒以下) の検索 API を介してリアルタイムでの侵害検出を実行できるように、Amazon OpenSearch Service のスケーラブルベクトルデータベース機能と分散アーキテクチャを活用して、合計 680 億の 128 次元および 1024 次元ベクトルを OpenSearch Service にインデックスする取り込みパイプラインを開発しました。

結論

生成 AI ソリューションを構築したり、リッチメディアやオーディオを検索したり、既存の検索ベースのアプリケーションによりセマンティックな検索を加えたりするには、OpenSearch は有能なベクトルデータベースです。OpenSearch は様々なエンジン、アルゴリズム、距離尺度をサポートしており、適切なソリューションを構築することができます。OpenSearch は、低レイテンシで数十億のベクトルに対応できる、スケーラブルなエンジンを提供します。OpenSearch とそのベクトル DB 機能により、ユーザーは簡単に 8 フィートの青いソファを見つけ、暖かい火のそばでリラックスできます。

Amazon Web Services ブログ