AIxivコラムは、本サイト上で学術的・技術的な内容を掲載するコラムです。過去数年間で、このサイトの AIxiv コラムには 2,000 件を超えるレポートが寄せられ、世界中の主要な大学や企業のトップ研究室がカバーされ、学術交流と普及を効果的に促進しています。共有したい優れた作品がある場合は、お気軽に寄稿するか、報告のために当社までご連絡ください。提出メール: liyazhou@jiqizhixin.com; zhaoyunfeng@jiqizhixin.com
この記事の著者は、機械学習リーダーである Yang Yang 博士と、OpenSearch China R&D チームの機械学習エンジニア Geng Zhichao および Guan Cong です。 OpenSearch は、Amazon Cloud Technology によって開始された純粋なオープンソースの検索およびリアルタイム分析エンジン プロジェクトです。このソフトウェアは現在 5 億回以上ダウンロードされており、コミュニティには世界中で 70 社を超える企業パートナーがいます。
大規模モデルの爆発的な増加以来、セマンティック検索は徐々に一般的なテクノロジーになってきました。特に RAG (検索拡張生成) アプリケーションでは、検索結果の関連性が AI 生成の最終的な効果を直接決定します。 現在市場にあるセマンティック検索実装ソリューションのほとんどは、言語モデルを使用してテキスト文字列を高次元ベクトルにエンコードし、近似 k 近傍検索 (k-NN) を使用します。多くの人は、VectorDB と言語モデルの導入 (GPU が必要) のコストが高いために躊躇しています。 最近、Amazon OpenSearch は、Amazon Shanghai Artificial Intelligence Research Institute と協力して、OpenSearch NeuralSearch プラグインの Neural Sparse 関数 を開始しました。これは、セマンティック検索が現在直面している次の 3 つの課題を解決します:
- さまざまなクエリでの相関パフォーマンスの安定性: ゼロショットセマンティック検索では、セマンティックコーディングモデルがさまざまな背景を持つデータセットに対して良好な相関パフォーマンスを持つ必要があります。つまり、言語モデルが言語モデルの外で使用される必要があります。ユーザーがデータセットを微調整する必要はありません。スパース コーディングと用語ベクトルの相同特性を利用して、Neural Sparse は、馴染みのないテキスト表現 (業界固有の単語、略語など) に遭遇した場合にテキスト マッチングにダウングレードし、それによって法外な検索結果を回避できます。
- オンライン検索の時間効率: リアルタイム検索アプリケーションにとって低遅延の重要性は明らかです。現在普及しているセマンティック検索方法には、通常、セマンティック エンコーディングとインデックス作成という 2 つのプロセスが含まれており、これら 2 つの速度によって、検索アプリケーションのエンドツーエンドの検索効率が決まります。 Neural Sparse の独自の doc-only モードは、オンライン コーディングを行わずに、テキスト マッチングと同様の遅延で、ファーストクラスの言語モデルに匹敵する意味検索の精度を達成できます。
- インデックス ストレージ リソースの消費: 商用検索アプリケーションは、ストレージ リソースの消費に非常に敏感です。大量のデータのインデックスを作成する場合、検索エンジンのランニングコストはストレージ リソースの消費に大きく関係します。関連する実験では、Neural Sparse は、同じサイズのデータにインデックスを付けるのに、k-NN インデックス作成の 1/10 のみを必要としました。同時に、メモリ消費量も k-NN インデックスよりも大幅に小さくなります。
関連性デモ
- ドキュメントのホームページ: https://opensearch.org/docs/latest/search-plugins/neural-sparse-search/
- プロジェクトの Github アドレス: https://github.com/opensearch-project/neural-検索
ネイティブ Lucene インデックスと組み合わせたスパース エンコーディング 現在のセマンティック検索の主な方法は、デンス エンコーディング (Dense Encoding) から来ています。への文書そして、クエリテキストは、言語エンコーディングモデルによって高次元空間のベクトルに変換されます。たとえば、Sentence-BERT の TASB モデルは 768 次元のベクトルを生成し、All-MiniLM-L6 はテキストを 384 次元のベクトルに変換します。このタイプの高次元ベクトルのインデックス付けには、初期のツリー構造ベースの FLANN、ハッシュ ベースの LSH、および隣接グラフやスキップ テーブルに基づく後期の HNSW などの特別な k-NN 検索エンジンの使用が必要です。最新の量子化ベースの FAISS エンジンとして。 スパース エンコーディングは、テキストをトークンと重みのセットに変換します。ここでのトークンは、言語コーディング モデルがセグメンターを使用してテキストを切り取った後に生成されるテキスト単位です。たとえば、WordPiece スプリッターを使用すると、トークンはある程度「単語」として理解できますが、単語が長すぎて 2 つのトークンに分割される場合もあります。 ️スパースエンコーディングとデンスエンコーディングの比較 
スパースエンコーディングによって生成されたトークン重みの組み合わせは、従来のテキストマッチング手法で使用される用語ベクトルと非常に似ているため、ネイティブ Lucene インデックスを使用できます。オープンサーチでまばらにエンコードされたドキュメントを保存するため。 k-NN 検索エンジンと比較して、ネイティブ Luence エンジンは軽量で、使用するリソースも少なくなります。
次の表は、テキスト マッチングに Lucene を使用した場合、k-NN エンジンを使用して密なエンコーディングを保存した場合、および Lucene を使用してスパース エンコーディングを保存した場合のディスク消費量とランタイム メモリ (ランタイム RAM) 消費量の比較を示しています。 へ-- BEIR の記事によると、現在の高密度コーディング モデルのほとんどは MSMAARCO データ セットの微調整に基づいているため、このモデルはこのデータ セットで非常に優れたパフォーマンスを発揮します。ただし、他の BEIR データ セットに対してゼロショット テストを実行する場合、データ セットの約 60% ～ 70% では、密コーディング モデルの相関が BM25 を超えることはできません。これは、私たち自身の反復比較実験からもわかります (以下の表を参照)。 ️いくつかのデータセットに対する複数の手法の相関パフォーマンスの比較 
実験では、なじみのないデータセットでは、スパースコーディングがデンスコーディングよりも優れたパフォーマンスを発揮することがわかりました。現在のところ、それを裏付ける詳細な定量的データはありませんが、いくつかのサンプルの分析によると、その利点は主に 2 つの点にあります: 1) 同義語の関連付けでスパースコーディングがより顕著になる、2) まったく馴染みのないテキスト表現に遭遇した場合たとえば、一部の専門用語の場合、スパース コーディングはこれらの用語トークンの重みを高め、関連するトークンの重みを弱める傾向があるため、検索プロセスがキーワード マッチングに退化し、安定した相関パフォーマンスを追求することになります。
BEIR ベンチマークの実験では、Neural Sparse の 2 つの手法が、密コーディング モデルや BM25 と比較して相関スコアが高いことがわかります。 Neural Search は、究極のオンライン検索速度を提供するモードも提供します。このモードでは、取得するドキュメントのみがスパースにエンコードされます。対照的に、オンライン検索中は、クエリ テキストはエンコード用の言語エンコード モデルを呼び出しません。代わりに、クエリ テキストを分割する場合にのみトークナイザーを使用してください。深層学習モデルの呼び出し処理が省略されるため、オンライン検索の遅延が大幅に短縮されるだけでなく、GPUの計算能力などモデル推論に必要な計算リソースを大幅に節約できます。 次の表は、テキスト マッチング取得方法 BM25、密エンコード取得 BERT-TASB モデル、クエリ エンコード バイ エンコーダ メソッドを使用したスパース エンコード取得、および MSMAARCO v2 100 万でのスパース エンコード取得のみのドキュメント エンコード doc のみを比較しています。ボリュームレベルのデータセットの速度比較。ドキュメントのみのエンコード モードの速度パフォーマンスが BM25 と同等であることがはっきりとわかります。また、前のセクションの表から、ドキュメントのみのエンコード モードの相関パフォーマンスはクエリ スパース エンコードと変わらないことがわかります。方法が多すぎます。ドキュメントのみのエンコード モードは、非常にコスト効率の高い選択であると言えます。 
さらに高速: 2 段階検索を使用して高速化します
前の記事で述べたように、スパース エンコーディング プロセス中に、テキストはトークンと重みのセットに変換されます。この変換により、重みの低いトークンが多数生成されますが、これらのトークンは検索プロセスのほとんどの時間を占めますが、最終的な検索結果への影響は大きくありません。
したがって、最初の検索でこれらの低重みのトークンをまず除外し、高重みのトークンのみに依存して上位のドキュメントを見つける新しい検索戦略を提案します。次に、これらの選択されたドキュメントに対して、以前にフィルタリングされた低重みのトークンが再導入されて 2 回目の詳細なスコアリングが行われ、最終スコアが取得されます。
この方法により、2 つの部分で遅延が大幅に削減されます。まず、検索の最初の段階で、転置インデックスで重みの高いトークンのみが一致するため、不必要な計算時間が大幅に削減されます。第 2 に、結果ドキュメントの正確な狭い範囲内で再度スコアリングする場合、関連する可能性のあるドキュメントの低重みトークンのスコアのみを計算し、処理時間をさらに最適化します。 最終的に、この改良された方法は、ドキュメント エンコード モード (ドキュメントのみ) で BM25 検索に近いレイテンシー パフォーマンスを達成し、クエリ エンコード モード (バイ エンコーダー) では 5 倍高速になりました。 Neural Search のレイテンシ パフォーマンスとスループットが 8 倍に大幅に向上しました。以下は、4 つの典型的な Beir データセットにおける標準ニューラル スパース、2 段階ニューラル スパー、BM25 の遅延比較です: 2 段階検索速度の比較 
OpenSearch でニューラル スパーを構築する 5 つのステップOpenSearch セマンティック検索アプリケーションで1. Neural Search を設定して有効にします
まず、モデルがローカル クラスターで実行できるようにクラスター構成を設定します。 PUT /_cluster/settings{"transient" : {"plugins.ml_commons.allow_registering_model_via_url" : true,"plugins.ml_commons.only_run_on_ml_node" : false,"plugins.ml_commons.native_memory_threshold" : 99}}ログイン後にコピー
Opensearch には現在 3 つのオープンソース モデルがあります。関連する登録情報は公式文書で入手できます。例として amazon/neural-sparse/opensearch-neural-sparse-encoding-v1 を考えてみましょう。 まず、登録 API を使用して登録します。
POST /_plugins/_ml/models/_register?deploy=true{ "name": "amazon/neural-sparse/opensearch-neural-sparse-encoding-v1", "version": "1.0.1", "model_format": "TORCH_SCRIPT"}ログイン後にコピー
{"task_id": "<task_id>","status": "CREATED"}ログイン後にコピー
GET /_plugins/_ml/tasks/
ログイン後にコピー
{"model_id": "<model_id>","task_type": "REGISTER_MODEL","function_name": "SPARSE_TOKENIZE","state": "COMPLETED","worker_node": ["wubXZX7xTIC7RW2z8nzhzw"], "create_time":1701390988405,"last_update_time": 1701390993724,"is_async": true}ログイン後にコピー
PUT /_ingest/pipeline/neural-sparse-pipeline{ "description": "An example neural sparse encoding pipeline", "processors" : [ { "sparse_encoding": { "model_id": "<model_id>", "field_map": { "passage_text": "passage_embedding" } } } ]}ログイン後にコピー
4. インデックスを設定します
神经稀疏搜索利用 rank_features 字段类型来存储编码得到的词元和相对应的权重。索引将使用上述预处理器来编码文本。我们可以按以下方式创建索一个包含两阶段搜索加速管线的索引（如果不想开启此功能，可把 `two_phase_search_pipeline` 替换为 `_none` 或删除 `settings.search` 这一配置单元）。
PUT /my-neural-sparse-index{ "settings": { "ingest":{ "default_pipeline":"neural-sparse-pipeline" }, "search":{ "default_pipeline":"two_phase_search_pipeline" } }, "mappings": { "properties": { "passage_embedding": { "type": "rank_features" }, "passage_text": { "type": "text" } } }}ログイン後にコピー
PUT /my-neural-sparse-index/_doc/{ "passage_text": "Hello world"}ログイン後にコピー
在索引中进行稀疏语义搜索的接口如下，将 替换为第二步中注册的 model_id：
GET my-neural-sparse-index/_search{ "query":{ "neural_sparse":{ "passage_embedding":{ "query_text": "Hi world", "model_id": <model_id> } } }}ログイン後にコピー
以上がAmazon Cloud Innovation「Neural Sparse Retrieval」: セマンティック検索を実現するにはテキスト一致のみが必要ですの詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。
![[Web フロントエンド] Node.js クイック スタート](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
