こんにちは、

私は両方を同時に使用します。ステム処理された用語のすべての形態を見つけたいとは限らず、代わりにステム処理されていない形態を見つけたい場合があります。または少なくとも、後者の方がスコアが高くなるべきです。標準では、スコアリングがそれを処理してくれます。

実際には、KeywordRepeatフィルタを使用して、両方を1つのフィールドに入れる方が好みです。しかし、それは他の頭痛の種を引き起こし、それを解決するためにさらに多くの作業が必要になります。両方のフィールドを使用して、シンプルに保つことをお勧めします。

よろしく、
Markus

ステミングはニュース記事や商品説明など、通常のテキストに使用します。「job」という単語を「jobs report」や「job numbers」の両方にマッチさせたい場合です。

固有名詞（人名、地名、商品名）にはステミングを使わないようにします。「job」が「Steve Jobs」にマッチするのは望んでいませんが、「Book of Job」にマッチするのは望んでいます。「gate」が「Bill Gates」にマッチするのも望んでいません。「see」が映画「Saw」にマッチするのも望んでいません。実際に、これはNetflixで起きたことです。

wunder
Walter Underwood
wunder@wunderwood.org
http://observer.wunderwood.org/ (私のブログ)

すでに良い回答がある中でさらに詳しく説明します：

「標準の設定で、スコアリングはすでに対応しているでしょう。」
本当にそうでしょうか？つまり、大部分は対応しているでしょう。

マルチフィールド検索を使用する場合、スコアリングにさまざまなアプローチが可能です。例えば、edismaxを使用し、タイファクターを使って純粋な離散クエリから純粋なブールクエリ、そしてその中間のどこかでスコアを計算することができます。
フィールドqf=text text_stemmedに対して「term1」というクエリを行うと、以下のようになります：

クエリ用語 = term1
ステミングされたクエリ用語 = term

純粋な離散クエリ
text:term1 | text_stemmed:term
スコアは最も高いスコアリングの句になります。
「term1」という正確な用語を含むドキュメントの場合、勝つ句はどちらかになります。

term1がフィールドtextにある場合、用語頻度TF1と文書頻度DF1があります。
termがフィールドtext_stemmedにある場合、用語頻度TFと文書頻度DFがあります。
TF >= TF1（元々フィールドにterm1だけが存在した場合は=、term1, term2, termが存在して「term」にステミングされた場合は>）
IDF <= IDF1（元々フィールドにterm1だけが存在した場合は=、term1, term2, termが存在して「term」にステミングされた場合は>）

異なる用語を含むドキュメントは、高いまたは低い用語頻度で一致する可能性がありますが、文書頻度は常に>=となります。
BM25は用語頻度のスコアへの影響に対して飽和状態に近づきますが、それでも用語頻度のためにtext_stemmed:termから派生する勝つ句が得られることがあります。
したがって、逆文書頻度の要素により正確な一致が勝つ可能性が高いと言えますが、純粋な離散クエリでは保証されません。

例：
Doc1
text: "term1 bla bla bla bla"
TF（ステミング済み）= 1
TF1（非ステミング）=1
DF1=100
DF=101

Doc2:
text:"term2 term3 term4 term5 bla bla term6 bla bla"
TF（ステミング済み）= 5
DF= 101
TF1（非ステミング）=0 - 一致しない

純粋なブールクエリ
text:term1 | text_stemmed:term
スコアはスコアリングの句の合計になります。
しかし、観察は似ています：
用語頻度に応じて、フィールド「text」で正確な用語と一致するドキュメントの方が良いスコアを得る可能性が高いです（正確な用語が逆文書頻度が高いため、ステミングされた対応を加算します）。
しかし、逆文書頻度が十分に補償できない場合もあります。

スコアに影響を与える他の多くの要素があることは知っていますが、ある程度（どの程度かは言い難い）ブーストしない限り、非ステミング一致が勝つことを保証できないと思います。

では、また

Alessandro Benedetti
Apache Lucene/Solr コミッター
ディレクター、研究開発ソフトウェアエンジニア、検索コンサルタント

www.sease.io