時間が経つにつれて、Sphinxは検索モードとランキングモードの大きな束に成長しました。 定期的にさまざまなことについての質問があります（「ドキュメントを1位に引き出す方法」から「一致の度合いに応じて1〜5個の星を描く方法」）。これらは実際にこれらのモードの内部構造に関する質問の本質です。 この投稿では、検索モードとランキングモードの配置、ランキングファクター、最終ウェイトなどのファクターの正確な計算方法など、覚えているすべてのことを説明します。 そして、もちろん、星について！

検索モードとランキングモードについて

まず、これらのモードが一般的に行うことを理解します。 APIを通じて、 SetMatchMode（）とSetRankingMode（）の 2つの異なるメソッドが利用可能になりました 。 それは違うように見えるでしょう。 しかし実際には、内部には同じものがあります。 以前は、バージョン0.9.8までは、検索モードのみが利用可能でした。 SetMatchMode（）。 それらはすべて、異なるコードブランチによって実装されました。 各コードブランチ自体が、ドキュメントの検索とランキングの両方を行いました。 さらに、もちろん、さまざまな方法で。 バージョン0.9.8では、新しい統合ドキュメント検索エンジンの開発が開始されました。 ただし、互換性を損なわないために、このエンジンはSPH_MATCH_EXTENDED2モードでのみ使用できました。 0.9.9からは、新しいエンジンが既に非常に安定しており、高速であることが明らかになりました（念のため、見落とした場合はバージョン0.9.8があります）。 これにより、多数の古いコードを削除でき、0.9.9以降、すべての検索モードは新しいエンジンによって処理されます。 互換性のために、古い検索モードを使用する場合、簡略化されたクエリ解析コードが使用され（フルテキストクエリ言語の演算子は無視されます）、正しい（検索モードに対応する）レンジャーが自動的に設定されますが、すべての違いはそこで終わります。 したがって、実際には、ドキュメントの重み （ weight ）はランキングモード（ranker）のみに依存します 。 したがって、次の2つのクエリは同じ重みを与えます。

// 1  $cl->SetMatchMode ( SPH_MATCH_ALL ); $cl->Query ( "hello world" ); // 2  $cl->SetMatchMode ( SPH_MATCH_EXTENDED2 ); $cl->SetRankingMode ( SPH_RANK_PROXIMITY ); $cl->Query ( "hello world" ); 

2番目のオプションでは、 @title helloを記述できます（クエリ言語を参照）。 最初は不可能です（互換性を参照）。

ランカーは、利用可能ないくつかの内部要因に基づいてドキュメントの重みを計算します（そして、それらにのみ）。 異なるランク付け者は、さまざまな方法で単純に要因を最終的な重みに収集すると言うことができます。 最も重要な2つの要因は、1）80年代以降のほとんど（すべてではないにしても）の検索エンジンで使用されている古典的な統計要因BM25、および2）Sphinx固有のフレーズ重み係数です。

BM25について

BM25は0から1の範囲の実数です。これは、一方では現在のドキュメントのキーワードの頻度に、他方では一般的なドキュメントのセット（コレクション）に、 頻度のみに 依存 します 。 SphinxでのBM25の現在の実装は、要求と実際に一致する頻度だけでなく、ドキュメント内の合計単語頻度に基づいて計算されます。 たとえば、 タイトル helloクエリ（ヘッダー内の単語helloの1つのコピーと一致）の場合、BM25係数は@（タイトル、コンテンツ）キーワードクエリと同じように計算されます。 単純化された実装は意図的に行われました。標準ランキングモードでは、BM25係数は二次的であり、テスト中のランキングの違いはわずかでしたが、速度はかなり大きく異なりました。 正確な計算アルゴリズムは次のようになります。

 BM25 = 0 foreach ( keyword in matching_keywords ) { n = total_matching_documents ( keyword ) N = total_documents_in_collection k1 = 1.2 TF = current_document_occurrence_count ( keyword ) IDF = log((N-n+1)/n) / log(1+N) BM25 = BM25 + TF*IDF/(TF+k1) } BM25 = 0.5 + BM25 / ( 2*num_keywords ( query ) ) 

TFは、用語頻度（ランク付けされたドキュメントのキーワード頻度）の略です。 IDFはInverse Document Frequencyの略です。 コレクション内でよく見られるキーワードのIDFは小さく、まれな単語のIDFは大きくなります。 ピーク値は、1つのドキュメントに正確に現れる単語に対してIDF = 1になり、すべてのドキュメントにある単語に対してIDF〜= -1になります。 TFは、理論的には、k1に応じて0〜1の範囲です。 選択されたk1 = 1.2で、実際には0.4545 ...から1まで変化します。

BM25は、キーワードがまばらでドキュメントに何度も入力されると上昇し、キーワードが頻繁に発生するとクラッシュします。 BM25の最大の価値は、すべてのキーワードがドキュメントと一致し、単語が非常にまれ（コレクション全体からこの1つのドキュメントのみが見つかった）であり、それらも何度も含まれている場合に達成されます。 ドキュメントがすべてのドキュメントで発生する1つの超頻出語と一致する場合、それぞれ最小で、...もドキュメント内で何度も表示されます。

頻繁に使用される単語（文書の半分よりも頻繁に見つかる）がBM25を減らすことに注意してください。 実際、1つを除くすべてのドキュメントで単語が見つかった場合、頻繁に使用される単語のないこの1つのドキュメントは依然として特別であり、より重要になります。

フレーズの重みについて

フレーズの重み（クエリとの近接度であり、クエリの近接度でもあります）は完全に異なると見なされます。 この要素は頻度をまったく考慮しませんが、クエリとドキュメント内のキーワードの相対的な位置を考慮します。 それを計算するために、Sphinxはドキュメントの各フィールドのキーワードの位置を分析し、クエリとの最長の連続一致を見つけ、キーワードの一致、一致、長さを考慮します。 正式には、クエリと処理中のフィールド間のキーワードの最長共通サブシーケンス（LCS）を見つけ、このフィールドのフレーズの重みをLCSの長さと等しくなるように設定します。 言い換えると、フレーズの重み（下）は、リクエストとまったく同じ順序でフィールドに出現したキーワードの数です 。 以下に例を示します。

1) query = one two three, field = one and two three
field_phrase_weight = 2 ( "two three", 2 )

2) query = one two three, field = one and two and three
field_phrase_weight = 1 ( , )

3) query = one two three, field = nothing matches at all
field_phrase_weight = 0


ドキュメントの最終的なフレーズの重みを取得するには、各フィールドのフレーズの重みにユーザー指定のフィールドの重みを乗算し（SetFieldWeights（）メソッドを参照）、乗算の結果を加算します。 （ところで、デフォルトでは、フィールドの重みは1であり、1未満に設定することはできません。）擬似コードは次のようになります。

doc_phrase_weight = 0
foreach ( field in matching_fields )
{
field_phrase_weight = max_common_subsequence_length ( query, field )
doc_phrase_weight += user_weight ( field ) * field_phrase_weight
}


例：

doc_title = hello world
doc_body = the world is a wonderful place

query = hello world
query_title_weight = 5
query_body_weight = 3

title_phrase_weight = 2
body_phrase_weight = 1
doc_phrase_weight = 2*5+3*1 = 13


明るい未来について

今日説明した2つの要因は基本的なものですが、一般的には唯一の要因ではありません。 他のテキスト要素を考慮することは技術的に可能です。 たとえば、実際の一致に基づいて「正しい」BM25を検討します。 入ってくる単語の頻度を考慮して、サブフレーズの重みをよりmoreに考えます。 さらに、フィールドで一致する単語の数を考慮します。 などなど ランク付け者自身のレベルで、あらゆる種類の非テキスト要因を考慮することもできます。 つまり、 weight の計算プロセスで一部の属性を使用し、計算に追加するのではありません。

ランカーについて

最後に、簡潔さのランク付け者のためのランク付けモードについて。 彼らは、あらゆる種類のさまざまな要因から最終的な重みを収集します。 ランカーの出口での重みは整数です。

デフォルトのランカ（拡張/拡張2モード）はSPH_RANK_PROXIMITY_BM25と呼ばれ、フレーズの重みをBM25と組み合わせます。 ファクターBM25は小数点以下3桁にあり、フレーズの重みは4番目以降から始まります。 関連する2つのランカー、 SPH_RANK_PROXIMITYとSPH_RANK_BM25があります。 1つ目は、フレーズ自体の重み係数を重みとして単に返します。 2番目は正直にBM25のみを考慮しており、長い計算の代わりに、各一致フィールドのフレーズの重みはすぐに1に等しくなります。

// SPH_RANK_PROXIMITY_BM25 ( )
rank_proximity_bm25 = doc_phrase_weight*1000 + doc_bm25*999

// SPH_RANK_PROXIMITY ( SPH_MATCH_ALL)
rank_proximity = doc_phrase_weight

// SPH_RANK_BM25 (, . )
rank_bm25 = sum ( matching_field_weight )*1000 + doc_bm25*999


おそらくデフォルトでSPH_RANK_PROXIMITY_BM25が選択されています。 利用可能なもののうち、最も関連性の高い結果が得られるという意見があります。 将来のデフォルトは変更される可能性があります。 より賢く一般的に優れたランク付け者を作成するための計画はかなりあります。 ランカーSPH_RANK_PROXIMITYは、SPH_MATCH_ALLモードをエミュレートします（ちなみに、2001年にすべてが始まった最初のモードです）。 何らかの理由でフレーズの重みが重要でない場合は、SPH_RANK_BM25を使用する必要があります。 または、クエリを高速化したい場合のみ。 ところで、 ランカーの選択はクエリの速度に大きく影響します ！ 通常、計算の最も高価な部分は、文書内の単語の位置の分析です。 そのため、SPH_RANK_PROXIMITY_BM25は常にSPH_RANK_BM25よりも遅くなり、SPH_RANK_NONE（まったくカウントされない）よりも常に遅くなります。

履歴検索モードの処理に使用される別のランカーはSPH_RANK_MATCHANYです。 彼は、他の2つの近接ランク付け役と同様に、サブフレーズの重みも考慮します。 しかし、これはさらに、各フィールドで一致するキーワードの数をカウントし、サブフレーズの重みと組み合わせて、a） 任意のフィールドの長いサブフレーズが上記のドキュメント全体を配置するようにします。 b）同じサブフレーズの長さで、一致する単語の数が多いドキュメントほどランクが高くなりました。 指では、ドキュメントAにドキュメントBよりもクエリのより正確な（長い）サブフレーズがある場合、ドキュメントAをより高くランク付けする必要があります。そうでない場合（サブフレーズが同じ長さである場合）、単に単語の数を調べます。 アルゴリズムは次のとおりです。

k = 0
foreach ( field in all_fields )
k += user_weight ( field ) * num_keywords ( query )

rank = 0
foreach ( field in matching_fields )
{
field_phrase_weight = max_common_subsequence_length ( query, field )
field_rank = ( field_phrase_weight * k + num_matching_keywords ( field ) )
rank += user_weight ( field ) * field_rank
}


Ranker SPH_RANK_WORDCOUNTは、各フィールドで一致したキーワードの出現数にフィールドの重みを掛けたものを愚かに合計します。 SPH_RANK_NONEよりも簡単です。SPH_RANK_NONEはまったくカウントされません。

rank = 0
foreach ( field in matching_fields )
rank += user_weight ( field ) * num_matching_occurrences ( field )


最後に、 SPH_RANK_FIELDMASKは、リクエストに一致するフィールドのビットマスクを返します。 （また複雑ではない、はい...）

rank = 0
foreach ( field in matching_fields )
rank |= ( 1<< index_of ( field ) )


星について

可能な最大重量が等しい理由と、それらをアスタリスク（通常は5ポイントですが、可能な場合）、パーセンテージ、または1から17までの直感的なスケールのポイントに正しく変換する方法についての質問が定期的に発生します。 ランカーから、そしてリクエストから 。 たとえば、SPH_RANK_PROXIMITY_BM25の出力での絶対最大重みは、キーワードの数とフィールドの重みに依存します。

max_proximity_bm25 = num_keywords * sum ( field_weights ) * 1000 + 999


ただし、この絶対最大値は、 すべてのフィールドに1xのクエリの正確なコピーと、2xのすべてのフィールドのクエリ検索が含まれる場合にのみ実現されます。 また、特定のフィールド（たとえば、 タイトル hello world）に制限を設定してリクエストが行われた場合はどうなりますか？ この特定のタイプのリクエストでは、絶対的な最大値は原則として達成できません。実際に可能な最大の重みは次の値に等しくなります。

max_title_query_weight = num_keywords * title_field_weight * 1000 + 999


そのため、「正しい」最大重量を分析的に正確に計算することはかなり困難です。 星のない生命が存在しない場合、「絶対」最大値（ほとんど達成されない）を比較的簡単に検討するか、特定のサンプルごとに最大重量を取得し、それに関連するすべてを正規化します。 複数クエリのメカニズムにより、これはほぼ無料で行われますが、これはすでに別の記事のトピックです。

完全一致（更新）について

コメントには、質問とフィールドの完全一致が上位にランクされない理由と、それを達成する方法についての良い質問がありました。

重要なのは、ランク付け者の仕事の論理にあります。 要求がフィールドで完全に満たされた場合のデフォルトのプロキシミティおよびproximity_bm25ランカは、そのようなフィールドに最大フレーズウェイトを割り当てます（これが主要なランキング要素です）。 同時に、フィールド自体の長さは考慮されません。 フィールドがリクエストと完全に一致するという事実も考慮されません。 これが歴史的に確立された動作です。 どうやら、何らかの理由で、リクエストが1つまたは別のフィールドと完全に一致する状況は、以前はあまり一般的ではありませんでした。

現在のトランク（バージョン0.9.10）では、作業が既に進行中です。実験用レンジャーSPH_RANK_SPH04が追加され、上記のフィールドの完全一致をランク付けするだけです。 技術的な機会は、おそらく0.9.9に現れました。 0.9.8では、インデックス形式は必要なデータを提供しません（奇妙なことに、保存された位置には「これはフィールドの終わりでした」というフラグがありません）。

新しいランカーがいなくても、何かをすることができます。

たとえば、完全に一致する場合は、手動で重みを増やすことができます。 これを行うには、ペンを使用して、フィールド自体（インデックス作成時）および要求からすべての句読点と大文字を削除し、フィールドからcrc32を考慮して、そのインデックス属性を保存します。 次に、検索時に、式の重み + if（fieldcrc == querycrc、1000,0）を計算し、この式で結果を並べ替えます。 かなり曲がっていますが、場合によっては役立ちます。

それでもタスクをわずかに変更し、完全な一致の事実ではなく、ドキュメント（または別のフィールド）の長さを考慮することができます。 これを行うには、インデックス作成時に属性にLENGTH（myfield）を保存し、検索時にフォームの式でランク付けします（これは単なる例です！） Weight + ln（max（len、1））* 1000

場合によっては（コメントから曲名のインデックスを作成する例など）、フィールドを個別にではなく、一緒にインデックス付けすると意味があり、「group-song」というフレーズの一致が「glued」フィールドのフレーズにより多くの重みを与えることがあります。 それ以外の場合、すべてのフィールドは個別と見なされ、「フィールド境界を越えて」一致は上に配置されません。

ファイルスペースについて

とにかくこのキッチン全体をさらにドリブルする方法はありますか？ そのように。 既存のランカーがどのように配置されているか、どのような要因が考慮され、どのように組み合わされているかを理解したら、すぐに意識的に即座に重みを修正できます（より正確には、 重みを含む新しい算術式を設定し、それによって出力をソートできます） さらに興味深いことに、新しい専門のランカーを追加することは技術的に可能です（最初の1分間の広告：ランカーSPH_RANK_WORDCOUNTとSPH_RANK_FIELDMASKは私によって発明されたものではありません、 商用ユーザーが要求しました）。 ランク付け者のC ++コードから、クエリ、キーワード、ランキングドキュメント、および（最も重要な）クエリに一致するすべてのキーワードのリストとドキュメント内の位置への即時アクセスがあります。 最も重要なことは、見事にファイルマジックを適用することです。