この投稿では、テキスト類似性検索と呼ばれる特定の手法に焦点を当てています。このタイプの検索では、ユーザーは短いフリーテキストクエリを入力し、ドキュメントはクエリとの類似性に基づいてランク付けされます。テキストの類似性は、さまざまな使用例で役立ちます。

• 質問回答:よくある質問のコレクションが与えられた場合、ユーザーが入力した質問に類似した質問を見つけます。

• 記事検索:研究記事のコレクションで、ユーザーのクエリに密接に関連するタイトルの記事を返します。

• 画像検索:キャプション付きの画像のデータセットで、ユーザーの説明に類似したキャプションを持つ画像を検索します。

類似性検索の直接的なアプローチは、クエリと共有する単語の数に基づいてドキュメントをランク付けすることです。しかし、共通する単語がほとんどない場合でも、ドキュメントがクエリと類似している可能性があります。より堅牢な類似性の概念では、構文と意味の内容も考慮されます。

自然言語処理 (NLP) コミュニティは、単語や文章を数値ベクトルとしてエンコードするテキスト埋め込みと呼ばれる手法を開発しました。これらのベクトル表現は、テキストの言語コンテンツをキャプチャするように設計されており、クエリとドキュメント間の類似性を評価するために使用できます。

この投稿では、テキスト埋め込みと Elasticsearch の dense_vector タイプを使用して類似性検索をサポートする方法について説明します。まず、埋め込み技術の概要を説明し、次に Elasticsearch を使用した類似性検索の簡単なプロトタイプを段階的に説明します。

テキスト埋め込みとは何ですか?

さまざまな種類のテキスト埋め込みと、従来の検索アプローチとの比較を詳しく見てみましょう。

単語埋め込み

単語埋め込みモデルは、単語を密な数値ベクトルとして表現します。これらのベクトルは、単語の意味特性を捉えることを目的としています。つまり、ベクトルが近い単語は、意味の点で類似しているはずです。適切な埋め込みでは、ベクトル空間の方向は単語の意味のさまざまな側面に結び付けられます。たとえば、「カナダ」のベクトルは、ある方向では「フランス」に近く、別の方向では「トロント」に近くなる可能性があります。

NLP および検索コミュニティは、かなり長い間、単語のベクトル表現に興味を抱いてきました。過去数年間、多くの従来のタスクがニューラル ネットワークを使用して再検討され、単語埋め込みへの関心が再び高まりました。word2vecやGloVeなど、いくつかの成功した単語埋め込みアルゴリズムが開発されました。これらのアプローチでは、大規模なテキスト コレクションを利用し、各単語が出現するコンテキストを調べてベクトル表現を決定します。

• word2vec Skip-gram モデルは、ニューラル ネットワークをトレーニングして、文中の単語の周囲のコンテキスト ワードを予測します。ネットワークの内部重みによって単語の埋め込みが与えられます。

• GloVe では、単語の類似性は、他の文脈上の単語と一緒に出現する頻度によって決まります。このアルゴリズムは、単語の共起カウントに基づいて単純な線形モデルをトレーニングします。

多くの研究グループが、Wikipedia や Common Crawl などの大規模なテキスト コーパスで事前トレーニングされたモデルを配布しており、ダウンロードして下流のタスクに組み込むのが便利になっています。事前トレーニング済みのバージョンが直接使用される場合もありますが、特定のターゲット データセットとタスクに合わせてモデルを調整すると役立つ場合があります。これは通常、事前トレーニング済みのモデルに対して「微調整」ステップを実行することによって実現されます。

単語埋め込みは非常に堅牢かつ効果的であることが証明されており、機械翻訳や感情分類などの NLP タスクでは、個々のトークンの代わりに埋め込みを使用するのが一般的になっています。

文の埋め込み

最近では、研究者たちは単語だけでなく、より長いテキストセクションを表す埋め込み技術に注目し始めています。現在のアプローチのほとんどは、複雑なニューラル ネットワーク アーキテクチャに基づいており、意味情報の取得を支援するためにトレーニング中にラベル付けされたデータを組み込むこともあります。

一度トレーニングされると、モデルは文を受け取り、文脈内の各単語のベクトルと文全体のベクトルを生成できるようになります。単語埋め込みと同様に、多くのモデルの事前トレーニング済みバージョンが利用可能であり、ユーザーはコストのかかるトレーニング プロセスを省略できます。トレーニング プロセスは大量のリソースを消費する可能性がありますが、モデルの呼び出しははるかに軽量です。文埋め込みモデルは通常、リアルタイム アプリケーションの一部として使用できるほど高速です。

一般的な文埋め込み手法としては、 InferSent 、 Universal Sentence Encoder 、 ELMo 、 BERTなどがあります。単語や文の埋め込みの改善は活発に研究されている分野であり、今後さらに強力なモデルが導入される可能性があります。

従来の検索アプローチとの比較

従来の情報検索では、テキストを数値ベクトルとして表現する一般的な方法は、語彙内の単語ごとに 1 つの次元を割り当てることです。テキストのベクトルは、語彙内の各用語が出現する回数に基づいて決定されます。テキストを表現するこの方法は、文の構造を考慮せずに単語の出現回数を単純に数えるため、「bag of words」と呼ばれることがよくあります。

テキスト埋め込みは、いくつかの重要な点で従来のベクトル表現と異なります。

• エンコードされたベクトルは密度が高く、比較的低次元であり、多くの場合 100 次元から 1,000 次元の範囲になります。対照的に、Bag of Words ベクトルはスパースであり、50,000 以上の次元で構成できます。埋め込みアルゴリズムは、テキストの意味をモデル化する一環として、テキストを低次元空間にエンコードします。理想的には、同義語やフレーズは、新しいベクトル空間で同様の表現になります。

• 文の埋め込みでは、ベクトル表現を決定するときに単語の順序を考慮できます。たとえば、「tune in」というフレーズは、「in tune」とはまったく異なるベクトルとしてマッピングされる場合があります。

• 実際には、文の埋め込みはテキストの大きなセクションにはうまく一般化されないことがよくあります。これらは通常、短い段落よりも長いテキストを表すために使用されません。

類似性検索に埋め込みを使用する

質問と回答の大きなコレクションがあったとしましょう。ユーザーは質問をすることができ、私たちはユーザーが回答を見つけやすくするために、コレクション内で最も類似した質問を取得したいと考えています。

テキスト埋め込みを使用すると、類似の質問を取得できるようになります。

• インデックス作成中に、各質問は文埋め込みモデルに渡され、数値ベクトルが生成されます。

• ユーザーがクエリを入力すると、同じ文埋め込みモデルが実行され、ベクトルが生成されます。回答をランク付けするために、各質問とクエリ ベクトル間のベクトル類似度を計算します。埋め込みベクトルを比較する場合、コサイン類似度を使用するのが一般的です。

このリポジトリには、 Elasticsearch でこれをどのように実現できるかの簡単な例が示されています。メイン スクリプトは、 StackOverflow データセットから約 20,000 件の質問にインデックスを付け、ユーザーがデータセットに対してフリーテキスト クエリを入力できるようにします。

スクリプトの各部分については後ほど詳しく説明しますが、まずはいくつかの例の結果を見てみましょう。多くの場合、この方法は、クエリとインデックス付けされた質問の間に強い単語の重複がない場合でも類似性を捉えることができます。

• 「ファイルを圧縮」と入力すると、「フォルダとファイルの圧縮/解凍」が返されます。

• 「何かが IP であるかどうかを判断する」は、「文字列が IP であるかホスト名であるかを判断する方法」を返します。

• 「バイトを倍精度浮動小数点数に変換する」は「Pythonでバイトを浮動小数点数に変換する」を返します。

実装の詳細

スクリプトは、 TensorFlow に埋め込みモデルをダウンロードして作成することから始まります。Google の Universal Sentence Encoder を選択しましたが、他の多くの埋め込み方法を使用することもできます。スクリプトは追加のトレーニングや微調整を行わずに、埋め込みモデルをそのまま使用します。

次に、質問のタイトル、タグ、およびベクトルとしてエンコードされた質問のタイトルのマッピングを含む Elasticsearch インデックスを作成します。

dense_vector のマッピングでは、ベクトルに含まれる次元の数を指定する必要があります。title_vector フィールドにインデックスを作成するとき、Elasticsearch はマッピングで指定されたのと同じ数のディメンションがあるかどうかを確認します。

ドキュメントのインデックスを作成するには、質問のタイトルを埋め込みモデルに渡して数値配列を取得します。この配列は、title_vector フィールドのドキュメントに追加されます。

ユーザーがクエリを入力すると、テキストは最初に同じ埋め込みモデルに渡され、パラメータ query_vector に保存されます。7.3 以降、Elasticsearch はネイティブ スクリプト言語でcosineSimilarity 関数を提供します。したがって、ユーザーのクエリとの類似性に基づいて質問をランク付けするには、script_score クエリを使用します。

新しいクエリごとにスクリプト () が再コンパイルされるのを避けるために、クエリ ベクトルをスクリプト パラメータとして渡すようにします。Elasticsearch では負のスコアが許可されないため、コサイン類似度に 1 を追加する必要があります。

|注:このブログ投稿では、元々、Elasticsearch 7.3 で使用可能だったベクトル関数の別の構文を使用していましたが、7.6 では非推奨になりました。|

重要な制限事項

script_score クエリは、制限的なクエリをラップし、返されるドキュメントのスコアを変更するように設計されています。ただし、match_all クエリを提供しているため、スクリプトはインデックス内のすべてのドキュメントに対して実行されます。これは、Elasticsearch におけるベクトル類似性の現在の制限です。ベクトルはドキュメントのスコアリングには使用できますが、最初の検索手順では使用できません。ベクトル類似性に基づく検索のサポートは、現在進行中の作業の重要な領域です。

すべてのドキュメントをスキャンすることを回避し、高速なパフォーマンスを維持するために、match_all クエリをより選択的なクエリに置き換えることができます。検索に使用する適切なクエリは、特定のユースケースによって異なる可能性があります。

上記ではいくつか有望な例を見てきましたが、結果にはノイズが多く直感的でない場合もあることに注意することが重要です。例えば、「ファイルを圧縮する」では、「部分的な.csproj」にも高いスコアが割り当てられます。ファイル」と「.pyc を回避する方法」ファイルですか？また、メソッドが予期しない結果を返す場合、その問題をデバッグする方法が必ずしも明確であるとは限りません。各ベクトル要素の意味は不透明であることが多く、解釈可能な概念に対応していません。単語の重複に基づく従来のスコアリング手法を使用すると、「なぜこのドキュメントのランクが高いのか」という質問に答えるのが簡単になることがよくあります。

前述のように、このプロトタイプは埋め込みモデルをベクトル フィールドで使用する方法の例として提供されており、本番環境で使用できるソリューションとして提供されているわけではありません。新しい検索戦略を開発するときは、一致クエリなどの強力なベースラインと比較しながら、独自のデータでそのアプローチがどのように機能するかをテストすることが重要です。確実な結果を得るには、ターゲット データセットの埋め込みモデルを微調整したり、単語レベルのクエリ拡張などの埋め込みを組み込むさまざまな方法を試したりするなど、戦略に大きな変更を加える必要がある場合があります。

結論

埋め込み技術は、テキストの言語コンテンツを取得する強力な方法を提供します。埋め込みをインデックス化し、ベクトル距離に基づいてスコアリングすることで、単語レベルの重複を超えた類似性の概念を使用してドキュメントを比較できます。

ベクター フィールド タイプに基づいた機能をさらに導入することを楽しみにしています。検索にベクトルを使用するのは、微妙で発展途上の領域です。いつものように、 Githubやディスカッション フォーラムで、皆さんの使用事例や体験談をお聞かせください。

背景

Elasticsearch を開発しているときに、解決するための単純なアプローチや確立されたアプローチがない重要な問題に遭遇することがあります。「うーん、これについて言及している学術論文はあるのだろうか？」と疑問に思うのは当然です。時には、学術的な仕事がインスピレーションの源となることもあります。新しいアルゴリズムやデータ構造を提案する論文に出会うと、「これはとても便利だろう！」と思うでしょう。Elasticsearch と Apache Lucene が学術研究にどのように組み込まれているか、いくつかの例を次に示します。

• カーディナリティ集計 のための HyperLogLog++

• 適応型レプリカ選択 のための C3アルゴリズム

• Lucene における最近傍ベクトル検索のための階層的ナビゲート可能スモールワールドグラフ (HNSW)

• 機械学習の分類を改善する ための MIC統計

• Lucene でトップヒット検索を高速化 する ブロック最大 WAND

• ... その他 多数

学術論文は、データ集約型システムを開発するエンジニアにとって貴重なリソースです。しかし、それらを実装するのは困難で、エラーが発生しやすくなります。アルゴリズムの説明は複雑であることが多く、重要な実用的な詳細が省略されています。そして、テストは本当に難しいです。たとえば、出力がデータセットに大きく依存する機械学習アルゴリズムを徹底的にテストするにはどうすればよいでしょうか。

ソフトウェアの依存関係と同じように論文を評価する

新しいソフトウェア依存関係を追加するには、慎重な評価が必要です。他のパッケージが正しくなかったり、速度が遅かったり、安全でなかったりする場合は、プロジェクトも同様になる可能性があります。依存関係を導入する前に、開発者は必ずその品質を評価します。

実装を検討している学術論文にも同じことが当てはまります。アルゴリズムが論文で発表されているので、そのアルゴリズムは正しく、パフォーマンスも優れているに違いないと思われるかもしれません。しかし、査読プロセスに合格したとしても、学術論文には問題がある可能性があります。おそらく、正しさの証明は現実的ではない仮定に依存しているのでしょう。あるいは、「実験」セクションではベースラインよりもはるかに優れたパフォーマンスが示されていますが、これは特定のデータセットにのみ当てはまります。たとえ論文の質が優れていたとしても、そのアプローチがプロジェクトに適していない可能性があります。

学術論文に「依存」するかどうかを考えるときは、ソフトウェア パッケージの場合と同じ質問をすると役立ちます。

• ライブラリは広く使用され、「実戦テスト済み」ですか?→ 他のパッケージでもこの論文は実装されていますか? また、うまく機能しましたか?

• パフォーマンスベンチマークは利用可能ですか?これらは正確かつ公平と思われますか?→論文には現実的な実験が含まれていますか？それらはうまく設計されていますか?

• パフォーマンスの改善は複雑さを正当化するほど大きいですか?→ この論文は強力なベースラインアプローチに匹敵しますか?このベースラインをどれだけ上回るのでしょうか?

• このアプローチは当社のシステムとうまく統合されるでしょうか?→ アルゴリズムの前提とトレードオフは、私たちのユースケースに適合していますか?

どういうわけか、ソフトウェア パッケージが競合製品とのパフォーマンス比較を公開すると、そのパッケージが常に最速であると出てきます。第三者がベンチマークを設計した場合、よりバランスが取れる可能性があります。同じ現象が学術論文にも当てはまります。アルゴリズムが元の論文だけでなく、他の論文でも強力なベースラインとして優れたパフォーマンスを示している場合、そのアルゴリズムは信頼できる可能性が非常に高くなります。

テストを創造的に行う

学術論文のアルゴリズムは、私たちが日常的に目にするタイプのアルゴリズムよりも動作が洗練されていることがよくあります。おそらく、これは精度と引き換えに速度を向上させる近似アルゴリズムです。あるいは、大規模なデータセットを取り込み、（場合によっては予期しない）出力を生成する機械学習の手法である可能性もあります。アルゴリズムの動作を単純な方法で特徴付けることができない場合、これらのアルゴリズムのテストをどのように記述できるでしょうか?

不変量に焦点を当てる

ユニット テストを設計するときは、例に基づいて考えるのがよくあります。つまり、アルゴリズムにこの例の入力を与えると、その出力が得られるはずです。残念ながら、ほとんどの数学アルゴリズムでは、例に基づくテストではその動作を十分にカバーできません。

Elasticsearch が検索リクエストをどのノードが処理すべきかを判断するために使用する C3 アルゴリズムを考えてみましょう。ノードの以前のサービスと応答時間、およびキュー サイズを組み込んだ微妙な計算式を使用して各ノードをランク付けします。いくつかの例をテストしても、式を正しく理解できたかどうかは実際には確認できません。一歩下がって不変条件のテストについて考えてみると役に立ちます。サービス時間が長くなると、ノードのランクは下がりますか?キューのサイズが 0 の場合、論文で主張されているように、ランクは応答時間によって決定されますか?

不変条件に焦点を当てると、次のような多くの一般的なケースで役立ちます。

• このメソッドは順序に依存しないものになるのでしょうか?もしそうなら、入力データを異なる順序で渡すと同じ出力が得られるはずです。

• アルゴリズムの何らかのステップでクラス確率が生成されますか?もしそうなら、これらの確率の合計は 1 になるはずです。

• 関数は原点を中心に対称ですか?もしそうなら、入力の符号を反転すると、出力の符号も単に反転するはずです。

C3 を初めて実装したとき、式にバグがあり、応答時間の代わりに応答時間の逆数を誤って使用していました。つまり、より遅いノードの方が上位にランク付けされる可能性があるということです。問題を修正する際には、将来のミスを防ぐために不変チェックを追加するようにしました。

リファレンス実装と比較する

論文とともに、著者らはアルゴリズムの実装も公開したようです。(論文に実験が含まれている場合は特にこの可能性が高くなります。多くのジャーナルでは、著者が結果を再現するためのコードを投稿することを求めているためです。)このリファレンス実装に対してアプローチをテストし、アルゴリズムの重要な詳細を見逃していないことを確認できます。

最近傍検索用の Lucene HNSW 実装を開発する際に、論文の著者による参照ライブラリに対してテストを行いました。同じデータセットに対して Lucene とライブラリの両方を実行し、結果の精度と実行された計算の数を比較しました。これらの数値がほぼ一致する場合、Lucene がアルゴリズムを忠実に実装していることがわかります。

アルゴリズムをシステムに組み込む場合、複数のコアに拡張したり、パフォーマンスを向上させるためにヒューリスティックを追加したりするなど、変更や拡張を行う必要があることがよくあります。最初に「バニラ」バージョンを実装し、リファレンスに対してテストしてから、段階的な変更を加えるのが最適です。そうすれば、カスタマイズを行う前に、すべての重要な部分を確実にキャプチャできます。

既存のアルゴリズムとの決闘

最後のセクションでは、テスト不変条件の別のアイデアとして、アルゴリズムの出力を、より単純で理解しやすいアルゴリズムの出力と比較する方法について説明します。例として、上位の結果に表示されないドキュメントをスキップすることでドキュメントの検索を高速化する、Lucene の block-max WAND アルゴリズムを考えてみましょう。block-max WAND があらゆるケースでどのように動作するかを正確に説明することは困難ですが、これを適用しても上位の結果は変わらないはずです。したがって、テストではランダムな検索クエリをいくつか生成し、それらを WAND 最適化ありとなしの両方で実行して、結果が常に一致することを確認できます。

これらのテストの重要な側面は、比較を実行するためのランダムな入力を生成することです。これにより、思いもよらなかったケースを練習したり、予期しない問題を明らかにしたりすることができます。たとえば、Lucene の BM25F スコアリングのランダム化比較テストは、微妙なエッジ ケースのバグを検出するのに役立ちました。アルゴリズムにランダムな入力を与えるという考え方には、コンピューター セキュリティの一般的なテスト手法であるファジングの概念との密接な関係があります。

Elasticsearch と Lucene では、このテスト手法が頻繁に使用されます。2 つのアルゴリズム (TestDuelingAnalyzers、testDuelTermsQuery...) 間の「決闘」について言及しているテストを見ると、この戦略が実行中であることがわかります。

論文の用語を使用する

他の開発者があなたのコードで作業する場合、詳細を理解するために論文を参照する必要があります。Elasticsearch の HyperLogLog++ 実装に関するコメントは、次のようにうまく表現しています。「論文を読まずにこのクラスが何をするかを理解しようとするのは冒険的だと見なされます。」このメソッドのコメントも良い例を示しています。学術論文へのリンクが含まれており、元々説明されていたアルゴリズムにどのような変更が加えられたかが強調されています。

開発者は紙に基づいてコードを理解するので、まったく同じ用語を使用すると便利です。数学表記は簡潔なので、通常は「適切なスタイル」とは見なされない名前になることもありますが、論文の文脈では非常に明確になります。学術論文の数式は、Elasticsearch でrS や muBarSInverseのような難解な変数名に遭遇する数少ない例の 1 つです。

著者が推奨する論文の読み方は、大きなコーヒーを飲みながら読むことです。

著者にメールを送ることができます

難しい論文に取り組むとき、誤解しているのか、それとも単なるタイプミスなのかわからず、数式について頭を悩ませるのに何時間も費やすことがあります。これがオープンソース プロジェクトであれば、GitHub または StackOverflow で質問することができます。しかし、学術論文はどこで入手できるのでしょうか?著者は忙しそうなので、あなたのメールにイライラするかもしれません。

それどころか、多くの学者は自分のアイデアが実践されていると聞くことを喜び、メールで質問に喜んで答えてくれます。彼らが精通している製品に取り組んでいる場合は、そのアプリケーションが彼らの Web サイトに掲載される可能性もあります。

また、ソフトウェア開発で使用したのと同じツールの多くを使用して、研究者が論文を公開して議論する傾向も高まっています。論文にソフトウェア パッケージが付属している場合は、 Github でよくある質問への回答が見つかることがあります。「理論計算機科学」や「Cross Validated」などの Stack Exchange コミュニティにも、人気のある論文に関する詳細な議論が含まれています。一部の会議では、すべての論文レビューをオンラインで公開し始めています。これらのレビューには著者との双方向の議論が含まれており、アプローチに関する役立つ洞察が得られる可能性があります。

つづく

この投稿では、学術論文の選び方の基本に焦点を当て、

正しく実装しますが、アルゴリズムを実際に展開するすべての側面をカバーしているわけではありません。たとえば、アルゴリズムが複雑なシステムの 1 つのコンポーネントにすぎない場合、そのコンポーネントへの変更がエンドツーエンドの改善につながることをどのように保証すればよいでしょうか。また、アルゴリズムを統合するために、元の論文でカバーされていない大幅な変更や拡張が必要な場合はどうなるでしょうか?これらは重要なトピックであり、今後の投稿でさらに詳しく共有したいと考えています。