数億の論文の類似性ソートアルゴリズムと検索エンジンの原理 (翻訳)

Sergey Feldman はシアトルの AI2 の上級応用研究科学者であり、自然言語処理と機械学習に重点を置いています。

元のアドレス:意味学者のためのより良い検索エンジンの構築 | Sergey Feldman 著 | AI2 ブログ (allenai.org) https://blog.allenai.org/building-a-better-search-engine-for-semantic-scholar- ea23a0b661e7

2020 年は、アレン人工知能研究所が提供する AI を活用した無料の科学文献調査ツールであるSemantic Scholarを検索する年です。今年の私たちの最大の取り組みの 1 つは、検索エンジンの関連性の向上であり、年の初めから、私は約 3 年間の検索ログデータを使用してより良い検索ランキングを構築する方法を見つけるという任務を負っていました。

最終的には、より関連性の高い結果をユーザーに提供する検索エンジンが完成しましたが、最初は機械学習を検索で適切に機能させる複雑さを過小評価していました。「問題ない。次のことをやれば 3 週間以内に完全に成功できるだろう」と私は心の中で思いました。

すべての検索ログを取得します。
いくつかの特徴エンジニアリングを実行します。
優れた機械学習モデルをトレーニング、検証、テストします。
展開する。

これは検索エンジンの文献では確立された慣行であるように見えますが、実際に検索エンジンを機能させる実践的な作業から得られた経験や洞察の多くは、競争上の理由から公開されていないことがよくあります。AI2は AI の共通利益に焦点を当てているため、テクノロジーと研究の多くをオープンにして無料で使用できるようにしています。この記事では、上記のプロセスが期待するほど単純ではない理由を「全体的に」説明し、次の問題とその解決策について詳しく説明します。

データは間違いなく汚いので、注意深く理解してフィルタリングする必要があります。
多くの機能はモデル開発中のパフォーマンスを向上させますが、実際に使用すると、奇妙で望ましくない動作が発生します。
モデルをトレーニングするのは素晴らしいことですが、適切なハイパーパラメーターを選択することは、ホールドアウトテストセットでnDCG を最適化するほど簡単ではありません。
よく訓練されたモデルでも奇妙な間違いを犯す可能性があり、それを修正するには事後修正が必要になります。
Elasticsearch は複雑で、正しく理解するのが困難です。

このブログ投稿に加えて、オープンの精神で、現在 www.semanticscholar.org で実行されている完全な Semantic Scholar 検索再ランキングモデルと、再ランキングを自分で行うために必要なすべてのアーティファクトをリリースします。ここでチェックしてください: GitHub - allenai/s2search: The Semantic Scholar Search Reranker

検索ランカーの概要

まず、Semantic Scholar の高度な検索アーキテクチャについて簡単に紹介します。Semantic Scholar で検索する場合、次の手順が実行されます。

検索クエリは Elasticsearch に送信されます (約 1 億 9,000 万の論文にインデックスが付けられています)。
上位の結果 (現在 1000 を使用) は、機械学習ランカーによって再ランク付けされます。

最近 (1) と (2) の改善を行っていますが、このブログ記事では主に (2) の作業について説明します。私たちが使用するモデルは、 LambdaRank 目標を備えたLightGBM ランカーです。トレーニングと評価が非常に速く、大規模な導入も簡単です。確かに、ディープラーニングにはパフォーマンスを向上させる可能性がありますが、モデルのぐらつき、トレーニングの遅さ (LightGBM と比較して)、推論の遅さはすべて欠点です。

データは次のように構造化されている必要があります。クエリ q、順序付けされた結果セット R = [r_1, r_2, ..., r_M]、結果ごとのクリック数 C = [c_1, c_2, ..., c_M] が与えられた場合、次の入力/出力を行います。ペアはトレーニングデータとして LightGBM に供給されます。

f（q、r_1）、c_1

f（q、r_2）、c_2

...

f（q、r_m）、c_m

ここで、 f は 特性関数です。クエリあたり最大 m 行の場合、LightGBM は、c_i > c_j の場合、model(f(q, r_i)) > model( f (q, r_j)) となるようにモデルを最適化します。できるだけ多くのトレーニングデータが含まれます。

ここでの 1 つの技術的なポイントは、各トレーニングサンプルをその位置の逆傾向スコアで重み付けすることにより、位置の偏りを修正する必要があることです。検索エンジンの結果ページでランダムな位置交換実験を実行することで、傾向スコアを計算します。

特徴量エンジニアリングとハイパーパラメータの最適化は、これを可能にする重要なコンポーネントです。これらについては後ほど説明しますが、最初にトレーニングデータとその難しさについて説明します。

データが多ければ多いほど、疑問も多くなります

Machine Learning Wisdom 101 には「データは多ければ多いほど良い」と書かれていますが、これは単純化しすぎです。データは関連性がある必要があり、無関係なデータを削除すると役立ちます。最終的に、ヒューリスティックな「意味があるかどうか」フィルターを満たさないデータの約 3 分の 1 を削除する必要がありました。

それはどういう意味ですか？クエリが SARS-CoV-1 と比較した SARS-CoV-2 のエアロゾルと表面安定性であると仮定すると、検索エンジンの結果ページ (SERP) は次の論文を返します。

SARS-CoV-1と比較したSARS-CoV-2のエアロゾルおよび表面安定性
SARS-CoV-2 の起源に近い
感染患者の上気道検体中の SARS-CoV-2 ウイルス量
...

クリックが位置 (1) にあると予想していましたが、この仮説データでは実際には位置 (2) にあります。ユーザーがクエリと正確には一致しない論文をクリックしました。この動作には正当な理由があります (例: ユーザーが論文を読んだ、または関連する論文を見つけたいなど)。しかし、機械学習モデルにとって、これを正しく推測できる機能がない限り、この動作はノイズのように見えます。動作の原因（例：以前の検索でクリックされたコンテンツの特性に基づく）。現在のアーキテクチャでは、ユーザーの履歴に基づいて検索結果がパーソナライズされていないため、このトレーニングデータにより学習がより困難になります。もちろん、データサイズとノイズの間にはトレードオフがあります。よりノイズの多いデータを使用することも、あまりクリーンでないデータを使用することもでき、後者の方が問題の解決に適しています。

別の例: ユーザーが「ディープラーニング」を検索すると、検索エンジンの結果ページにこれらの年と引用された論文が返されたとします。

年 = 1990、引用数 = 15000
年 = 2000、引用数 = 10000
年 = 2015、引用数 = 5000

次に位置 (2) をクリックします。議論のために、3 つの論文はすべて同じように深層学習「について」であると仮定します。つまり、タイトル/要約/場所に深層学習というフレーズが同じ回数含まれているとします。話題性はさておき、学術論文の重要性は最新性と引用数の組み合わせによって決まると考えており、ここでユーザーは最新の論文も最も引用された論文もクリックしません。これはちょっとした例ですが、たとえば、番号 (3) の引用がゼロの場合、多くの読者は番号 (2) が最初に来ることを好むかもしれません。それにもかかわらず、上の 2 つの例をガイドとして使用すると、「意味のない」データを削除するために使用されるフィルターは、特定のトリプル (q、R、C) について次の条件をチェックします。

クリックされた論文はすべて、クリックされなかった論文よりも多く引用されていますか?
クリックされた論文はすべて、クリックされていない論文よりも新しいですか?
クリックされたすべての論文は、タイトルのクエリに対するテキストの一致がより優れていますか?
クリックされたすべての論文は、著者フィールドのクエリとテキスト的によりよく一致しますか?
クリックされたすべての論文は、「会場」フィールドのクエリとテキスト的によりよく一致していますか?

受け入れられるトレーニングサンプルは、これら 5 つの条件のうち少なくとも 1 つを満たしている必要があります。各条件は、クリックされたすべての論文の値（引用数、最新性、一致スコア）が、クリックされていない論文の最大値よりも高い場合に満たされます。要約が上記のリストにないことに気づくかもしれませんが、それを含めても除外しても、実質的な違いはありません。

前述したように、このフィルターはすべての (クエリ、結果) ペアの約 3 分の 1 を削除し、最終的な評価メトリクスに約 10% ～ 15% の改善をもたらします。これについては、後のセクションで詳しく説明します。このフィルタリングは、疑わしいボットトラフィックが削除された後に実行されることに注意してください。

特徴量エンジニアリングの課題

各 (クエリ、結果) ペアに対して、合計 22 個の特徴を持つ特徴ベクトルを生成しました。featureizer の最初のバージョンでは 90 個の機能が生成されましたが、そのほとんどが無用または有害であり、これらの機能のために何らかの作業を行うと、機械学習アルゴリズムの方が効果的に機能することが多いという、苦労して得た知恵が再確認されました。

最も重要な機能には、論文のタイトル、要約、場所、年のフィールド内のクエリテキストの最長のサブセットを検索することが含まれます。これを行うために、クエリから長さが 7 以下の考えられるすべての ngram を生成し、論文の各フィールドで正規表現検索を実行します。一致したら、さまざまな特徴を計算できます。以下は、論文分野ごとにグループ化された機能の最終リストです。

title_fraction_of_query_matched_in_text
title_mean_of_log_probs
title_sum_of_log_probs*match_lens
abstract_fraction_of_query_matched_in_text
log_probs の抽象平均値
abstract_sum_of_log_probs*match_lens
抽象的_利用可能
クエリの一致する会場の割合
会場ログ確率の平均値
会場ログプロブスの合計*一致レンズ
sum_matched_authors_len_divided_by_query_len
max_matched_authors_len_divided_by_query_len
author_match_ distance_from_ends
Paper_year_is_in_query
紙の古さ
論文と引用
Paper_n_key_quotes
Paper_n_quotes_divided_by_oldness
すべてのフィールドにわたって一致する非引用クエリの割合
sum_log_prob_of_unquoted_unmatched_unigrams
すべてのフィールドにわたる引用クエリの一部の一致
sum_log_prob_of_quoted_unmatched_unigrams

これらの機能の中には、さらに説明が必要なものもあります。詳細については、この記事の最後にある付録を参照してください。血みどろの詳細が必要な場合は、すべての特徴付けがここで行われます。

これらすべての機能の重要性を理解するために、現在運用環境で実行されているモデルの SHAP値のプロットを以下に示します。

これまでに SHAP 図を見たことがない場合は、読むのが少し難しいかもしれません。サンプル i と特徴 j の SHAP値は、「このサンプルiについて、この特徴j が 最終モデルスコアにどの程度寄与するか」を大まかに示す数値です。私たちのランキングモデルでは、スコアが高いほど、その論文は上位に近くランク付けされるべきであることを意味します。SHAP グラフ上の各ポイントは、特定の (クエリ、結果) クリックペアのサンプルです。色は、元の特徴空間の特徴の値に対応します。たとえば、title_fraction_of_query_matched_in_text 特徴が一番上にあることがわかります。これは、SHAP 値の最大 (絶対) 合計を持つ特徴であることを意味します。左側の青色 (0 に近い低い固有値) から右側の赤色 (1 に近い高い固有値) に変化します。これは、モデルがタイトルのクエリとクエリの精度との間のほぼ線形の関係を学習したことを意味します。紙のランキングと一致します。ご想像のとおり、多いほど良いです。

その他の観察事項:

多くの関係は単調であるように見えますが、その理由は次のとおりです。 LightGBM では、特徴ごとに一変量の単調性を指定できます。これは、他のすべての特徴が一定に保たれている場合、特徴が上昇または下降する場合、出力スコアは上昇でなければならないことを意味します。単調（立ち上がりと立ち下がりを指定可能）。
一致するクエリの量と一致するログの確率を理解することは重要であり、冗長ではありません。
この特徴には単調性制約がないにもかかわらず (そのような制約がない唯一の特徴です)、モデルは、より最近の論文が古い論文よりも優れていることを学習します。予想通り、学術検索ユーザーは最新の論文が好きです。
色が灰色の場合は、機能が欠落していることを意味します。LightGBM は欠落している機能をネイティブに処理できるため、これは大きな利点です。
会場の機能は非常に重要であるように見えますが、それは検索のほんの一部が会場指向であるためです。これらの機能は削除すべきではありません。

ご想像のとおり、これらの機能については、正しく使用するために重要な詳細が多数あります。ここで詳細を説明することはこのブログ投稿の範囲を超えていますが、特徴量エンジニアリングを行ったことがある人なら、次のようなドリルを知っているでしょう。

機能を設計/調整します。
モデルをトレーニングします。
エラー分析を実行します。
気に入らない奇妙な行動に注意してください。
(1)に戻って調整してください。
繰り返す。

現在では、(1) を「ニューラルネットワークアーキテクチャの設計/調整」に置き換え、(1) と (2) の間に追加のステップとして「モデルが訓練されているかどうかを確認する」を追加することを除いて、このループを実行することがより一般的です。

評価の質問

機械学習のもう 1 つの突破不可能な定説は、トレーニング、検証/開発、テストの分割です。これは非常に重要ですが、誤解しやすく、複雑なバリエーションもあります (私のお気に入りのトピックの 1 つです)。アイデアの基本的な説明は次のとおりです。

トレーニングにはトレーニングデータを使用します。
検証/開発データを使用してモデルバリアント (ハイパーパラメーターを含む) を選択します。
テストセットでの汎化パフォーマンスを推定します。
テストセットを他の用途に使用しないでください。

これは重要ですが、利用可能なテストデータが「実際の」運用テストデータをあまり反映していないため、学術出版物以外では現実的ではないことがよくあります。これは、検索モデルをトレーニングする場合に特に当てはまります。

その理由を理解するために、トレーニングデータと「実際の」テストデータを比較/対照してみましょう。トレーニングデータは次のように収集されます。

ユーザーがクエリを発行します。
一部の既存システム (Elasticsearch + 既存のリランカー) は、結果の最初のページを返します。
ユーザーは結果を (おそらく) 上から下に表示します。一部の結果をクリックする場合があります。このページのすべての結果が表示される場合もあれば、表示されない場合もあります。一部のユーザーは結果の 2 ページ目に移動しますが、ほとんどのユーザーは移動しません。

したがって、各クエリのトレーニングデータには 10、20、または 30 の結果が含まれます。一方、本番環境では、モデルは Elasticsearch によって取得された最初の 1000 件の結果を再ランク付けする必要があります。繰り返しますが、トレーニングデータは既存のリランカーによって選択された最初の数個のドキュメントにすぎませんが、テストデータは Elasticsearch によって選択された 1000 個のドキュメントです。ここでの素朴なアプローチは、検索ログデータを取得し、それをトレーニング、検証、テストに分割し、適切なエンジニアリングセット (機能、ハイパーパラメーター) のプロセスを経ることです。ただし、類似したトレーニングデータで最適化すると、「実際の」タスクで適切なパフォーマンスが得られると考えるのは十分な理由はありません。それらはまったく異なるものだからです。より具体的には、前の再ランカーからの上位 10 件の結果の再ランク付けに適したモデルを作成したとしても、このモデルが ElasticSearch からの 1000 件の結果の再ランク付けに適していることを意味するわけではありません。下位 900 人の候補者はトレーニングデータに含まれておらず、上位 100 人のようには見えない可能性があるため、1,000 人の候補者すべてを再ランク付けすることは、上位 10 人または 20 人を再ランク付けすることとまったく同じ作業ではありません。

実際、これは実際には問題です。私が最初に構築したモデルパイプラインでは、モデルの選択に保持された nDCG を使用しましたが、そのプロセスで「最良の」モデルは奇妙なエラーを発生し、使用できませんでした。定性的には、「良い」 nDCG モデルと「悪い」 nDCG モデルの間には大きな違いはないようです。どちらも悪いです。実稼働環境に近い別の評価セットが必要でした。次に説明するアイデアの本質を思い付いてくれたAI2 CEO のOren Etzioniに多大な感謝を申し上げます。

直感に反しますが、最終的に使用した評価セットはユーザーのクリックにまったく基づいていませんでした。代わりに、実際のユーザーのクエリから 250 のクエリをランダムにサンプリングし、各クエリを構成要素に分解しました。たとえば、クエリが soderland etzioni emnlp open ie information extraction 2011の場合、そのコンポーネントは次のとおりです。

作宇： etzioni、soderland
場所: emnlp
年: 2011
テキスト: オープン、つまり情報抽出

この分解は手動で行われます。次に、このクエリを以前の Semantic Scholar Search (S2)、Google Scholar (GS)、Microsoft Academic Graph (MAG) などに送信し、検索のすべての要素 (著者、場所、年など) を満たす結果が上位にいくつあるかを確認します。、テキスト一致）。この例では、S2 には 2 つの結果があり、GS には 2 つの結果があり、MAG にはすべてのコンポーネントを満たす 3 つの結果があると仮定します。3 つ (そのうちの最大のもの) を選択し、このクエリの最初の 3 つの結果がそのコンポーネント条件 (上記の点) をすべて満たす必要があることを要求します。これは、この例のすべてのコンポーネントを満たすサンプルペーパーです。これは、Etzioni と Soderland によって 2011 年の EMNLP で公開されたもので、正確な ngram の「オープン IE」と「情報抽出」が含まれています。

上記の著者/場所/年/テキストのセクションに加えて、引用順序 (最高から最低) と最新順 (最新から最新) も調べました。特定のクエリに対して「合格」を取得するには、リランカーモデルの最上位の結果がすべてのコンポーネントと一致し (上記の例のように)、引用順序または最新順序に従っている必要があります。そうしないと、モデルは失敗します。ここでより詳細な評価を行うことも可能ですが、全か無かのアプローチが機能しました。

このプロセスはそれほど速くありません (2 人で 2 ～ 3 日の作業) が、最終的には 250 のクエリを構成要素、各クエリの目標結果数、および評価に使用される結果の数に分割します。 250 のクエリを満たす提案されたモデルコードのどの部分。

この指標に基づく山登りは、次の 2 つの理由から生産性が高いことが証明されています。

それはユーザーが認識する検索エンジンの品質に関係しています。
それぞれの「失敗」には、どのコンポーネントが不十分であったかの説明が付いています。たとえば、著者が一致せず、引用/最新の順序は考慮されません。

この評価指標を策定すると、ハイパーパラメータの最適化が合理的になり、特徴量エンジニアリングが大幅に高速化されました。私がモデル開発を開始したとき、この評価メトリクスは約 0.7 で、最終モデルのこの特定の 0 クエリセットのスコアは 93.250 でした。250 個のクエリを選択した場合、メトリクスに違いは感じませんが、新しい 250 個のクエリのセットでモデル開発を続行すると、モデルがさらに改善される可能性があるという予感があります。

事後修正

最良のモデルであっても、一見愚かなランキング選択を行うことがあります。これは機械学習モデルの性質によるものです。これらのエラーの多くは、単純なルールベースのイベント後の修正で修正できます。以下は、モデルスコアに対する事後修正のリストの一部です。

引用符で囲まれた一致は引用符のない一致よりも高く、引用符が多い一致は引用符が少ない一致よりも高くなります。
正確に一致する年が上部に移動されます。
著者のフルネーム ( Isabel Cacholaなど) を含むクエリの場合、その著者の結果が上部に移動されます。
クエリ内のすべてのアンタプルに一致する結果が先頭に移動されます。

ここのコードで事後修正を確認できます。

ベイジアン A/B テストの結果

新しいリランカーのパフォーマンスを評価するために、数週間にわたって A/B テストを実施しました。発行されたクエリごとの (平均) 合計クリック数を調べた結果は次のとおりです。

これは、人々が検索結果ページをクリックする頻度が約 8% 高いことを示しています。しかし、彼らは上位の結果をクリックするでしょうか? これは、各クエリのクリックの最大相互ランクを調べることで確認できます。クリックがない場合、割り当てられる最大値は 0 です。

答えは「はい」です。クリック数の下位ランキングの最大値が約 9% 増加しました。クリック位置の変化をより詳細に理解するために、制御とテストに使用された最高/最大クリック位置のヒストグラムを次に示します。

このヒストグラムはクリック以外を除外しており、ほとんどの改善が位置 2 で発生し、次に位置 3、位置 1 が続いていることを示しています。

これらすべてを Elasticsearch で実行してみてはいかがでしょうか?

次の 2 つの部分は、 Semantic Scholar の検索エンジニアリングディレクターである Tyler Murrayによって書かれています。

Elasticsearch は、最も上級のユーザーでもさまざまなマッチング、スコアリング、および再ランキング句を作成できる強力なツールと統合のセットを提供します。これらの関数は強力ではありますが、多くのフィールド、句、フィルターを組み合わせた場合、混乱を招き、最悪の場合ばかばかしいものになる傾向があります。より複雑な検索の使用例では、ブースト、フィルター、スコアリングのデバッグと調整に伴う労力はすぐに耐えられなくなる可能性があります。

LTR は、手動で調整された重み付けと再スコアリングから、現実世界のユーザーの行動に基づいてトレーニングされた検索システムへの移行を検討している検索チームにとって推奨されるアプローチであることがよくあります。LTR を実装すると、他の方法と比較して次のような利点と欠点が生じます。

アドバンテージ：

再スコアリングは、Elasticsearch のクエリライフサイクル中に発生します。
再ランク付けされた候補者を「合格」させることに関連するネットワークコストを回避または最小限に抑えます。
テクノロジーをメインのストレージエンジンとより緊密に連携させます。
検索テクノロジーの稼働時間は、サービス全体に分散されるのではなく、クラスターから分離されます。

欠点:

プラグインアーキテクチャでは、Elasticsearch JVM で実行する Java バイナリが必要です。
変更、デプロイ、テストを行う場合、クラスターを完全にローリング再起動する必要があるため、反復が非常に遅くなる可能性があります。これは特に大規模なクラスターに当てはまります。(>5TB)
Java はアクティブで成熟したエコシステムを維持していますが、最先端の機械学習および AI テクノロジのほとんどは現在 Python の世界に存在しています。
判断を集めることが難しい、または大規模に不可能な領域では、LTR 手法を効果的にトレーニングすることが困難になります。
同じクラスター内で複数のランキングプラグインを実行せずに、A/B テストでランキングアルゴリズムを並べてテストする場合の柔軟性は限られています。

ランキングの変更がどのようにテストおよびデプロイされるかについて将来に目を向けると、Elasticsearch プラグインのアプローチの欠点は、2 つの主軸、つまり反復とテストの速度 (これは私たちが開始するために重要であるため) の利点を大幅に上回ります。ユーザー中心の改善アプローチ。オフライン測定は、反復的にさまざまなモデルの健全性をテストするために重要ですが、最終的な測定は常にモデルが実際にどのように機能するかになります。Elasticsearch が提供するプラグインアーキテクチャを使用すると、反復とテストが非常に面倒で時間がかかります。第 2 に、Python エコシステムを通じて実現される堅牢なツールチェーンは、短期的な遅延リグレッションを上回ります。さまざまな言語モデルと既存の機械学習技術を統合する柔軟性は、幅広い関連性の問題の解決に有益であることが証明されています。これらのソリューションを Java エコシステムに戻すのは大変な作業になります。全体として、Elasticsearch は強力な検索エクスペリエンスを構築するための強固な基盤を提供しますが、より複雑な相関問題に対処し、より高速に反復する必要があるため、Elasticsearch エコシステムの外側に目を向ける必要がますます高まっています。

Elasticsearch での候補クエリの調整

フィルタリング、スコアリング、および再スコアリング句を適切に組み合わせることは、予想よりもはるかに難しいことが判明しました。これは、プラグインベースのランキングモデルをサポートするために使用される既存のベースラインに基づいて作業していることも原因の 1 つですが、インデックスマッピングに関するいくつかの問題も原因です。他の人が旅を進める上で役立ついくつかのメモ:

しないでください:

検索対象のドキュメントが、検索ランキングに必要なフィールドとアナライザー以外のもので肥大化することを許可します。同じインデックスを使用してレコードを検索し、表示するためにハイドレートしている場合は、複数のインデックス/クラスターが必要かどうかを検討することをお勧めします。ドキュメントが小さいほど検索が速くなり、データフットプリントが増大するにつれてその重要性はますます高まります。
multi_matchクエリは遅く、推論が難しいドキュメントのスコアを生成することが判明しているため、多くの multi_matchクエリを使用してください。
かなり積極的なフィルターを使用せず、またはこの関数を rescore 句で実行できるかどうかを考慮せずに、非常に大きな結果セットに対してfunction_scoreタイプのクエリを実行します。
script_score句を使用すると、速度が遅く、JVM でメモリリークが簡単に発生する可能性があります。ただ、それはやめてください。
インデックス/フィールド内のストップワードの処理を無視します。これらは、スコアリングに大きな違いをもたらします。特に、多数の用語やストップワードが一般的に使用される自然言語クエリの場合には顕著です。マッピングでは、以下で説明する一般的な用語 (v7.3 以下) クエリタイプまたはストップワードフィルターを常に考慮してください。
フィルタまたは一致句で field_name.* 構文を使用します。これにより、少なからぬオーバーヘッドが発生し、ほとんどの場合、希望どおりにはなりません。どのフィールド/アナライザーと照合するのかを明確にしてください。

する：

検索フィールドからストップワードをフィルターしたくない場合は、カットオフ周波数を指定した一般的な用語クエリの使用を検討してください。これが、起動するのに十分なパフォーマンスを発揮する候補選択クエリを取得する際に、私たちを限界を超えて押し上げた原因でした。
複数のフィールドの複数の用語に一致するドキュメントをブーストしたい場所に単一の連結フィールドを構築するには、インデックス作成中にcopy_to を使用することを検討してください。multi_match クエリを検討している場合はどこでも、このアプローチをお勧めします。
ユースケースで許可されている場合は、query_stringタイプのクエリを使用してください。IMO では、これらは ES ツールボックスの中で最も強力なクエリであり、大幅な柔軟性と調整が可能です。
rescore句の使用を検討してください。これにより、コストがかかる可能性のある操作のパフォーマンスが向上し、一定のスコアによる重み付け一致の使用が可能になります。これは、推論できるスコアを生成するのに役立つことがわかりました。
プライマリ検索句または rescore 句のいずれかでの Field_value_factor スコアリングは、非常に役立つことがわかります。私たちは、引用頻度の高い文書の関連性が高いと考えているため、このツールを使用してそれらの文書をそれに応じて強化します。
minimum_ should_match に関するドキュメントを注意深く読んでから、さらに数回読んでください。この動作は状況に応じたものであり、使用状況に応じて動作が異なります。

結論と謝辞

新しい検索が semanticscholar.orgで公開されており、これは大きな改善だと考えています。試してみて、フィードバックをフィードバック@semanticscholar.orgに電子メールでお送りください。

コードを精査して使用することもできます。フィードバックは歓迎です。

プロセス全体には約 5 か月かかりましたが、Semantic Scholar チームの大部分の協力がなければ不可能でした。特に、アイデアをブレインストーミングし、数え切れないほどのプロトタイプモデルの結果を調べ、それらが新しく興味深い方法でどのように機能するかを私に教えてくれるため、精力的に協力してくれたDoug DowneyとDaniel Kingに感謝したいと思います。また、このプロジェクトに関する素晴らしい注釈作業をしてくれた Madeleine van Zuylenと、有益な議論をしてくれた Hamed Zamaniにも感謝したいと思います。私のコードを採用し、魔法のように本番環境で動作させてくれたエンジニアにも感謝します。

付録: 機能の詳細

*_fraction_of_query_matched_in_text — この特定のフィールドでクエリのどの部分が一致しましたか?
log_prob は、言語モデルによる実際の一致の確率を指します。たとえば、クエリがセンチメント分析用のディープラーニングであり、フレーズセンチメント分析が一致する場合、高速でオーバーヘッドの低い言語モデルでその対数確率を計算して、驚きのレベルを理解できます。直感的には、特定のフィールドで一致したクエリの数だけでなく、一致したテキストが興味深いかどうかも知りたいと考えます。一致の確率が低いほど、興味深いものになるはずです。たとえば、「ウイルス負荷の利点」は「店に行く」よりも 4 グラム驚くべきことです。*_mean_of_log_probs は、フィールド内の一致の平均対数確率です。私たちは、 BERT のようなものの代わりにKenLM を言語モデルとして使用します。これは超高速です。つまり、機能ごとに何十回も呼び出すことができ、それでも特徴付けを迅速に行うことができます。本番の Python コードで実行するのに十分です。( この関数タイプを推奨してくれたDoug Downeyと KenLM に感謝します。
*_sum_of_log_probs*match_lens — 平均ログ確率を取得しても、一致が複数回発生したかどうかに関する情報は得られません。合計では、クエリテキストが複数回一致する論文が優先されます。これは主に要約に関連しています。
sum_matched_authors_len_divided_by_query_len — これは、タイトル、要約、場所のマッチングに似ていますが、各論文著者のマッチングは一度に 1 人ずつ行われます。この機能には追加のトリックがいくつかあります。私たちは名とミドルネームの一致よりも姓の一致に重点を置いていますが、絶対ではありません。検索結果によっては、ミドルネームが一致する論文が姓が一致する論文よりも上位にランク付けされる場合があります。これは機能改善の TODO です。
max_matched_authors_len_divided_by_query_len — 合計は、著者フィールドが全体的に一致した一致の数を示し、max は、個々の著者の一致の最大数を示します。直感的には、Sergey Feldman を検索すると、1 つの論文 (Sergey Patel、Roberta Feldman) と別の論文 ( Sergey Feldman Deman 、Maya Gupta)が表示されますが、2 番目の論文の方がはるかに優れています。max 機能を使用すると、モデルはこれを学習できます。
author_match_ distance_from_ends — 論文によっては 300 人の著者がいる場合もあり、著者が一致するのはまったくの偶然である可能性が高くなります。ここで、どこに一致するかをモデル作成者に伝えます。最初または最後の著者と一致した場合、この特徴は 0 になります (そして、モデルは小さい数字が重要であると学習します)。一致する著者のスコアが 300 点中 150 点の場合、特徴は 150 になります (値が大きいと不良とみなされます)。この機能の初期のバージョンは len(paper_authors) だけでしたが、このモデルは、多数の著者による論文に厳しすぎるペナルティを与えることを学習しました。
fraction_of_*quoted_query_matched_across_all_fields — 紙のフィールドごとに部分一致がある場合でも、モデルが加算方法を学習する必要がないように、すべてのフィールドを結合したときに一致したクエリの数を知ると役立ちます。
sum_log_prob_of_unquoted_unmatched_unigrams — この記事内の一致しないユニグラムの確率をログに記録します。ここで、モデルは不完全な一致にペナルティを与える方法を理解できます。たとえば、ミミズを識別するためのディープラーニングを検索した場合、モデルは、Depth という単語またはEarthworm という単語を含まない論文のみを検索する可能性があります。引用と最新性が同等であると仮定して、「ミミズ」などの非常に驚くべき用語を除外することにより、一致の品質が低下する可能性があります。