OpenSearch 3.0 では、セマンティックハイライトを導入しました。これは、キーワードの完全一致ではなく、意味に基づいて検索結果内の関連する文章をインテリジェントに特定する AI 搭載機能です。
OpenSearch 3.3 では、外部ホスト型のセマンティックハイライトモデル向けにバッチ処理を導入し、検索クエリあたりの機械学習 (ML) 推論呼び出しを N 回から 1 回に削減しました。ベンチマークでは、ドキュメントの長さと結果セットのサイズに応じて、100〜1,300% のパフォーマンス向上を実証しています。
今すぐデモをお試しください: OpenSearch ML Playground でセマンティックハイライトを体験できます。
新機能: リモートモデル向けバッチ処理
OpenSearch 3.0 では、セマンティックハイライトは各検索結果を個別に処理し、結果ごとに 1 回の ML 推論呼び出しを行っていました。多くの結果を返すクエリでは、この逐次的なアプローチにより、結果セットのサイズに比例してレイテンシが増加する可能性がありました。OpenSearch 3.3 では新しいアプローチを導入しました (下図参照)。すべての検索結果を収集し、単一のバッチ ML 推論呼び出しで送信することで、オーバーヘッドレイテンシを削減し、GPU 使用率を向上させます。
バッチ処理は現在、リモートセマンティックハイライトモデルのみ (Amazon SageMaker やその他の外部エンドポイントにデプロイされたモデル) に適用されます。
検索リクエストでのバッチセマンティックハイライトの使用
検索でバッチセマンティックハイライトを使い始めるには、以下の手順に従ってください。完全なセットアップについては、セマンティックハイライトチュートリアルを参照してください。
ステップ 1: リモートモデルの設定
バッチ処理を使用するには、外部エンドポイントにデプロイされたリモートバッチ推論をサポートするモデルが必要です。AWS 上でホストされている Amazon SageMaker エンドポイントと統合する方法は以下のとおりです。
- 必要な Amazon SageMaker モデルエンドポイントリソースを作成します。詳細については、README ガイドを参照してください。
- モデルエンドポイントを OpenSearch にデプロイします。詳細については、Amazon SageMaker ブループリントガイドを参照してください。
ステップ 2: システム生成パイプラインの有効化
以下のクラスター設定を追加して、OpenSearch が検索レスポンスを処理するためのシステムデフォルトのバッチセマンティックハイライトパイプラインを自動的に作成できるようにします。
PUT /_cluster/settings
{
"persistent": {
"search.pipeline.enabled_system_generated_factories": ["semantic-highlighter"]
}
}
ステップ 3: クエリにバッチフラグを追加
検索リクエストに batch_inference: true を含めて、バッチセマンティックハイライトを有効にします。以下の例では neural クエリを使用しています。
POST /neural-search-index/_search
{
"size": 10,
"query": {
"neural": {
"embedding": {
"query_text": "treatments for neurodegenerative diseases",
"model_id": "<your-text-embedding-model-id>",
"k": 10
}
}
},
"highlight": {
"fields": {
"text": {
"type": "semantic"
}
},
"options": {
"model_id": "<your-semantic-highlighting-model-id>",
"batch_inference": true
}
}
}
これでクエリは自動的にバッチ処理を使用するようになります。
パフォーマンスベンチマーク
MultiSpanQA データセットを使用して、セマンティックハイライトのバッチ処理によるパフォーマンスへの影響を評価しました。テスト環境は以下のように構成されました。
| 項目 | 構成 |
|---|---|
| OpenSearch クラスター | バージョン 3.3.0、AWS (us-east-2) にデプロイ |
| データノード | 3 × r6g.2xlarge (各 8 vCPU、64 GB メモリ) |
| マネージャーノード | 3 × c6g.xlarge (各 4 vCPU、8 GB メモリ) |
| セマンティックハイライトモデル |
opensearch-semantic-highlighter-v1、単一の GPU ベース ml.g5.xlarge を使用した Amazon SageMaker エンドポイントにリモートデプロイ |
| 埋め込みモデル |
sentence-transformers/all-MiniLM-L6-v2、OpenSearch クラスター内にデプロイ |
| ベンチマーククライアント | ARM64、16 コア、61 GB RAM |
| テスト構成 | 10 回のウォームアップ、50 回のテスト、3 シャード、0 レプリカ |
異なるドキュメント長を持つ 2 つのドキュメントセットでテストしました。
| データセット | ドキュメント長 | 平均トークン数 | P50 トークン数 | P90 トークン数 | 最大トークン数 |
|---|---|---|---|---|---|
| MultiSpanQA | 長いドキュメント | 約 303 | 約 278 | 約 513 | 約 1,672 |
| MultiSpanQA-Short | 短いドキュメント | 約 79 | 約 70 | 約 113 | 約 213 |
レイテンシ
セマンティックハイライトを有効にした場合と無効にした場合のセマンティック検索を比較することで、セマンティックハイライトのレイテンシオーバーヘッドを測定しました。ベースラインのセマンティック検索レイテンシは、すべての構成で約 20〜25 ms です。以下の表は、ハイライトのオーバーヘッドのみを示しています (値にはベースライン検索時間は含まれていません)。すべてのレイテンシ測定値は、OpenSearch レスポンスからのサービス側 took 時間です。
| k 値 | 検索クライアント | ドキュメント長 | バッチ処理なし P50 (ms) | バッチ処理あり P50 (ms) | P50 改善率 | バッチ処理なし P90 (ms) | バッチ処理あり P90 (ms) | P90 改善率 |
|---|---|---|---|---|---|---|---|---|
| 10 | 1 | 長い | 209 | 123 | 70% | 262 | 179 | 46% |
| 10 | 4 | 長い | 378 | 171 | 121% | 487 | 302 | 61% |
| 10 | 8 | 長い | 699 | 309 | 126% | 955 | 624 | 53% |
| 10 | 1 | 短い | 175 | 55 | 218% | 217 | 59 | 268% |
| 10 | 4 | 短い | 327 | 62 | 427% | 445 | 120 | 271% |
| 10 | 8 | 短い | 610 | 101 | 504% | 860 | 227 | 279% |
| 50 | 1 | 長い | 867 | 633 | 37% | 999 | 717 | 39% |
| 50 | 4 | 長い | 1,937 | 912 | 112% | 2,248 | 1,685 | 33% |
| 50 | 8 | 長い | 3,638 | 1,474 | 147% | 4,355 | 3,107 | 40% |
| 50 | 1 | 短い | 760 | 82 | 827% | 828 | 205 | 304% |
| 50 | 4 | 短い | 1,666 | 193 | 763% | 1,971 | 362 | 445% |
| 50 | 8 | 短い | 3,162 | 219 | 1,344% | 3,704 | 729 | 408% |
ベンチマークは、バッチ処理がセマンティックハイライトのオーバーヘッドを削減することを示しています。短いドキュメントで k=50、8 クライアントの場合、バッチ処理によりハイライトレイテンシが 3,162 ms からわずか 219 ms (P50) に削減されました。これは 1,344% の改善です。P90 レイテンシも改善 (408%) を示しており、一貫したパフォーマンス向上を実証しています。セマンティック検索のベースライン (約 25 ms) は一定のままなので、これらの改善はエンドツーエンドのレスポンス時間の短縮に直接つながります。
主な発見
- k=10。中程度から大幅な改善 (P50 で 46〜504%、P90 で 46〜279%)
- k=50。劇的な改善 (P50 で 37〜1,344%、P90 で 33〜445%)
-
短いドキュメントはより大きな恩恵を受ける。k=50 での長いドキュメントの 147% と比較して、最大 1,344% 高速化 (P50)
- なぜ違いがあるのか? 長いドキュメントはモデルの 512 トークン制限を超える可能性があり、バッチ処理でも複数のチャンク推論実行が必要になります。短いドキュメントは 1 回のパスで処理でき、バッチ処理の恩恵を最大化できます。
- P50 はより大きな改善を示す。中央値レイテンシはテールレイテンシよりも改善が大きいですが、両方とも大幅に恩恵を受けます。
スループット
バッチ処理が同時リクエストを処理するシステムの能力にどのように影響するかを理解するために、スループット (1 秒あたりの平均オペレーション数) も測定しました。結果 (以下の表に示す) は、すべての構成で一貫した改善を示しています。
| k 値 | 検索クライアント | ドキュメント長 | バッチ処理なし (ops/s) | バッチ処理あり (ops/s) | 改善率 |
|---|---|---|---|---|---|
| 10 | 1 | 長い | 4.23 | 6.29 | 49% |
| 10 | 4 | 長い | 9.18 | 17.9 | 95% |
| 10 | 8 | 長い | 10.02 | 21.27 | 112% |
| 10 | 1 | 短い | 4.83 | 11.59 | 140% |
| 10 | 4 | 短い | 10.47 | 37.79 | 261% |
| 10 | 8 | 短い | 12.03 | 48.33 | 302% |
| 50 | 1 | 長い | 1.11 | 1.49 | 34% |
| 50 | 4 | 長い | 1.99 | 3.74 | 88% |
| 50 | 8 | 長い | 2.12 | 4.28 | 102% |
| 50 | 1 | 短い | 1.27 | 4.3 | 239% |
| 50 | 4 | 短い | 2.27 | 11.55 | 409% |
| 50 | 8 | 短い | 2.43 | 14.33 | 490% |
スループットの改善は、バッチ処理が個々のクエリレイテンシを削減するだけでなく、全体的なシステム容量も増加させ、同じインフラストラクチャでより多くの同時ユーザーにサービスを提供できることを示しています。
まとめ
OpenSearch 3.3 のバッチ処理は、リモートモデルのセマンティックハイライトに大幅なパフォーマンス改善をもたらします。検索あたりの ML 推論呼び出し数を N から 1 に削減することで、以下を実現しました。
- 複数の検索結果をハイライトする際のレスポンス時間の短縮とクエリスループットの向上
- リモートモデルリソースのより効率的な使用
- 後方互換性のあるクエリ (既存のクエリはそのまま動作)
セマンティックハイライトのバッチ処理をお試しいただき、OpenSearch フォーラムでフィードバックをお寄せください。
OpenSearch Project(OSS) の Publicationです。 OpenSearch Tokyo User Group : meetup.com/opensearch-project-tokyo/
Discussion