Amazon Web Services ブログ
検索関連性の向上: Amazon OpenSearch Serverless での自動セマンティック強化
本記事は 2025 年 8 月 6 日 に公開された「Boosting search relevance: Automatic semantic enrichment in Amazon OpenSearch Serverless」を翻訳したものです。
従来の検索エンジンは、クエリの結果を見つけるために単語対単語のマッチング(語彙検索と呼ばれる)に依存しています。これはテレビのモデル番号などの特定のクエリには適していますが、より抽象的な検索では苦労します。例えば、「shoes for the beach」を検索する場合、語彙検索は単に個々の単語「shoes」、「beach」、「for」、「the」をカタログアイテムでマッチングするだけで、正確な検索用語を含まない「water-resistant sandals」や「surf footwear」などの関連商品を見逃す可能性があります。
大規模言語モデル (LLM) は、テキストの密なベクトル埋め込みを作成し、個々の単語境界を超えて、単語が使用される文脈を含む検索を拡張します。密なベクトル埋め込みは、靴とビーチがどのくらい頻繁に一緒に出現するかを学習することで、靴とビーチの関係を捉え、セマンティック検索と呼ばれる手法を通じて、より抽象的なクエリに対するより良い検索を可能にします。
スパースベクトルは、語彙検索とセマンティック検索の利点を組み合わせます。プロセスは、テキストから限定されたトークンセットを作成する WordPiece トークナイザーから始まります。次に、トランスフォーマーモデルがこれらのトークンに重みを割り当てます。検索中、システムは、クエリからの(削減されたセットからの)トークンの重みと、ターゲットドキュメントからのトークンとのドット積を計算します。クエリとターゲットの両方で重みが高いトークン(用語)から、ブレンドされたスコアを取得します。スパースベクトルは、密なベクトルのようにセマンティック情報をエンコードし、ドット積を通じて単語対単語のマッチングを提供し、ハイブリッドな語彙セマンティックマッチを実現します。スパースおよび密なベクトル埋め込みの詳細な理解については、OpenSearch ブログの Improving document retrieval with sparse semantic encoders をご覧ください。
Amazon OpenSearch Serverless の自動セマンティック強化により、スパースベクトルを使用したセマンティック検索の実装が簡単になります。数回のクリックだけで検索関連性の改善を実験し、本番環境にデプロイできるようになり、長期的なコミットメントや初期投資は必要ありません。この投稿では、自動セマンティック強化がどのように摩擦を取り除き、テキストデータのセマンティック検索の実装をシームレスにするかを、検索機能を強化するためのステップバイステップの手順とともに示します。
自動セマンティック強化
OpenSearch のデフォルトの語彙スコアリングである Okapi BM25 アルゴリズムを超えて検索関連性スコアリングを強化し、OpenSearch のコネクターフレームワークを使用してセマンティック検索のための密なベクトルとスパースベクトルモデルを統合することは既に可能でした。しかし、OpenSearch Serverless でのセマンティック検索の実装は複雑でコストがかかり、モデルの選択、ホスティング、OpenSearch Serverless コレクションとの統合が必要でした。
自動セマンティック強化により、フィールドタイプを設定するだけで、OpenSearch Serverless コレクション内のテキストフィールドをスパースベクトルとして自動的にエンコードできます。取り込み中、OpenSearch Serverless は、サービス管理された機械学習 (ML) モデルを通じてデータを自動的に処理し、テキストをネイティブ Lucene 形式のスパースベクトルに変換します。
自動セマンティック強化は、英語のみと多言語の両方のオプションをサポートしています。多言語バリアントは、アラビア語、ベンガル語、中国語、英語、フィンランド語、フランス語、ヒンディー語、インドネシア語、日本語、韓国語、ペルシア語、ロシア語、スペイン語、スワヒリ語、テルグ語をサポートしています。
モデルの詳細とパフォーマンス
自動セマンティック強化は、カスタムファインチューニングを必要とせずに効果的に動作する、サービス管理された事前トレーニング済みスパースモデルを使用します。モデルは指定したフィールドを分析し、多様なトレーニングデータから学習した関連性に基づいてスパースベクトルに展開します。展開された用語とその重要度の重みは、効率的な検索のためにネイティブ Lucene インデックス形式で保存されます。エンコーディングがデータ取り込み時にのみ発生するドキュメントのみモードを使用してこのプロセスを最適化しました。検索クエリは、スパースモデルを通じて処理されるのではなく、単にトークン化されるだけで、ソリューションをコスト効率的かつ高性能にします。
機能開発中のパフォーマンス検証では、平均 334 文字のパッセージを特徴とする MS MARCO パッセージ検索データセットを使用しました。関連性スコアリングについては、英語コンテンツの BEIR ベンチマークで最初の 10 件の検索結果 (ndcg@10) の平均正規化割引累積利得 (NDCG) を測定し、多言語コンテンツの MIRACL で平均 ndcg@10 を測定しました。レイテンシーは、クライアント側の 90 パーセンタイル (p90) 測定と検索レスポンス p90 took 値を通じて評価しました。これらのベンチマークは、検索関連性とレスポンス時間の両方のベースラインパフォーマンス指標を提供します。
以下の表は、自動セマンティック強化のベンチマークを示しています。
| 言語 | 関連性の改善 | P90 検索レイテンシー |
| 英語 | 語彙検索より 20.0% 向上 | 語彙検索より 7.7% 低いレイテンシー (bm25 は 26 ms、自動セマンティック強化は 24 ms) |
| 多言語 | 語彙検索より 105.1% 向上 | 語彙検索より 38.4% 高いレイテンシー (bm25 は 26 ms、自動セマンティック強化は 36 ms) |
各ワークロードの独特な性質を考慮して、実装の決定を行う前に、独自のベンチマーク基準を使用して開発環境でこの機能を評価することをお勧めします。
料金
OpenSearch Serverless は、インデックス時のスパースベクトル生成中に消費される OpenSearch Compute Units (OCU) に基づいて自動セマンティック強化を請求します。インデックス中の実際の使用量に対してのみ課金されます。この消費量は、Amazon CloudWatch メトリクス SemanticSearchOCU を使用して監視できます。モデルトークン制限と OCU あたりのボリュームスループットの具体的な詳細については、Amazon OpenSearch Service 料金をご覧ください。
前提条件
自動セマンティック強化インデックスを作成する前に、タスクに必要な権限が付与されていることを確認してください。必要に応じて、アカウント管理者にサポートを求めてください。OpenSearch Serverless で自動セマンティック強化を使用するには、以下のポリシーに示すアカウントレベルの AWS Identity and Access Management (IAM) 権限が必要です。権限は以下の目的で使用されます:
aoss:*IndexIAM 権限は、インデックスの作成と管理に使用されます。aoss:APIAccessAllIAM 権限は、OpenSearch API 操作の実行に使用されます。
また、コレクション内のインデックスと関連リソースを作成および管理するための OpenSearch Serverless データアクセスポリシーも必要です。詳細については、OpenSearch Serverless Developer Guide の Data access control for Amazon OpenSearch Serverless をご覧ください。以下のポリシーを使用してください:
プライベートコレクションにアクセスするには、以下のネットワークポリシーを設定してください:
自動セマンティック強化インデックスの設定
自動セマンティック強化インデックスを設定するには、以下の手順に従ってください:
- AWS Command Line Interface (AWS CLI) を使用して自動セマンティック強化インデックスを作成するには、create-index コマンドを使用します:
- 作成されたインデックスを記述するには、以下のコマンドを使用します:
AWS CloudFormation テンプレート (Type: AWS::OpenSearchServerless::CollectionIndex) または AWS Management Console を使用して、コレクションのプロビジョニング中およびコレクション作成後にセマンティック検索を作成することもできます。
例:商品カタログ検索のインデックス設定
このセクションでは、商品カタログ検索インデックスの設定方法を示します。title_semantic フィールド(英語モデルを使用)でセマンティック検索を実装します。product_id フィールドについては、デフォルトの語彙検索機能を維持します。
以下の index-schema では、title_semantic フィールドのフィールドタイプが text に設定され、パラメータ semantic_enrichment がステータス ENABLED に設定されています。semantic_enrichment パラメータを設定すると、title_semantic フィールドで自動セマンティック強化が有効になります。language_options フィールドを使用して、english または multi-lingual のいずれかを指定できます。この投稿では、title_non_semantic という名前の非セマンティックタイトルフィールドを生成します。以下のコードを使用してください:
データ取り込み
インデックスが作成された後、クライアントライブラリ、REST API、または OpenSearch Dashboards を通じて直接など、標準的な OpenSearch メカニズムを通じてデータを取り込むことができます。OpenSearch Dashboards Dev Tools でバルク API を使用して複数のドキュメントを追加する方法の例を以下に示します:
自動セマンティック強化インデックスに対する検索
データが取り込まれた後、インデックスをクエリできます:
以下がレスポンスです:
検索は、クエリで crimson footwear を使用したにもかかわらず、Red shoes を含むドキュメントと正常にマッチし、セマンティック検索の力を実証しています。システムは、正確なキーワードではなく意味に基づいてこれらのインテリジェントなマッチを可能にするドキュメントのセマンティック埋め込み(簡潔にするためここでは切り詰められています)を自動的に生成しました。
検索結果の比較
非セマンティックインデックス title_non_semantic に対して同様のクエリを実行することで、非セマンティックフィールドが文脈に基づいて検索できないことを確認できます:
以下が検索レスポンスです:
クエリ書き換え
自動セマンティック強化は、クエリの変更を必要とせずに、既存の「match」クエリをセマンティック検索クエリに自動的に変換します。match クエリが複合クエリの一部である場合、システムはクエリ構造を走査し、match クエリを見つけて、ニューラルスパースクエリに置き換えます。現在、この機能は「match」クエリの置き換えのみをサポートしており、スタンドアロンクエリまたは複合クエリの一部のいずれでも対応します。「multi_match」はサポートされていません。さらに、この機能は、ネストされた match クエリを置き換えるすべての複合クエリをサポートします。複合クエリには、bool、boosting、constant_score、dis_max、function_score、hybrid が含まれます。
自動セマンティック強化の制限事項
自動セマンティック検索は、映画のタイトル、商品説明、レビュー、要約など、自然言語コンテンツを含む小〜中規模のフィールドに適用する場合に最も効果的です。セマンティック検索はほとんどのユースケースで関連性を向上させますが、特定のシナリオでは最適ではない場合があります:
- 非常に長いドキュメント – 現在のスパースモデルは、英語の各ドキュメントの最初の 8,192 トークンのみを処理します。多言語ドキュメントの場合は 512 トークンです。長い記事の場合、完全なコンテンツ処理を確保するためにドキュメントチャンキングの実装を検討してください。
- ログ分析ワークロード – セマンティック強化はインデックスサイズを大幅に増加させ、通常は正確なマッチングで十分なログ分析には不要な場合があります。追加のセマンティックコンテキストは、増加したストレージ要件を正当化するほどログ検索の効果を向上させることはほとんどありません。
特定のユースケースに自動セマンティック強化を実装するかどうかを決定する際は、これらの制限事項を考慮してください。
まとめ
自動セマンティック強化は、すべての OpenSearch Serverless ユーザーが高度な検索機能にアクセスできるようにする重要な進歩を示しています。セマンティック検索実装の従来の複雑さを排除することで、検索開発者は最小限の労力とコストで検索機能を強化できるようになりました。この機能は複数の言語とコレクションタイプをサポートし、さまざまなユースケースに経済的に実行可能な従量課金制の料金モデルを提供します。ベンチマーク結果は、特に英語検索において有望で、関連性の向上とレイテンシーの削減の両方を示しています。ただし、セマンティック検索はほとんどのシナリオを強化しますが、非常に長い記事の処理やログ分析などの特定のユースケースでは、代替アプローチの方が有益な場合があります。
この機能を実験し、ML インフラストラクチャの管理オーバーヘッドなしに、より良い検索体験を提供できるよう検索実装を最適化する方法を発見することをお勧めします。追加の詳細については、動画と技術ドキュメントをご確認ください。
著者について
Jon Handler Amazon Web Services の検索サービス担当 Solutions Architecture ディレクターで、カリフォルニア州パロアルトを拠点としています。Jon は OpenSearch と Amazon OpenSearch Service に密接に関わり、生成 AI、検索、ログ分析ワークロードを持つ幅広い顧客にヘルプとガイダンスを提供しています。AWS 入社前は、ソフトウェア開発者として大規模な eCommerce 検索エンジンのコーディングに 4 年間従事していました。ペンシルベニア大学で学士号、ノースウェスタン大学でコンピュータサイエンスと人工知能の修士号と博士号を取得しています。
Arjun Kumar Giri OpenSearch プロジェクトに取り組む AWS の Principal Engineer です。主に OpenSearch の人工知能・機械学習 (AI/ML) とセマンティック検索機能に従事しています。AI、ML、スケーラブルシステムの構築に情熱を注いでいます。
この記事は Kiro が翻訳を担当し、Solutions Architect の 榎本 貴之 がレビューしました。