ハイフンを含む用語とぼかし検索
コピーリンク
(The bot translated the original post https://lists.apache.org/thread/bc7qqcnnmmqf562o3zwzwyo6o80grmkk into Japanese and reposted it under Apache License 2.0. The copyright of posted content is held by the original poster.)
こんにちは、
私はハイフンを含む用語でぼかし検索を行った際に、奇妙な結果を得ています。
私は次の2つの項目をインデックスしています：(1) "term-with-hyphens" と (2) "term with hyphens"。クエリ（"q"）で "term-with-hyphens" や "term with hyphens" を検索すると、どちらの項目も期待通りに返されます。エスケープされたハイフンでも同じです、例えば "term-with-hyphens" です。
問題点は、ぼかし検索パラメータを追加すると（つまり "term-with-hyphens~1" や "term-with-hyphens~1"）、結果が0件になってしまうことです。
私はこの結果を理解するのに苦労しており、どう問題を解決すればよいのかわかりません。直感的には、ぼかし検索パラメータを追加すれば結果のセットが増えるはずです。この問題についての助言を歓迎します。
私たちの現在の設定では、"Extended DisMax Query Parser" を使用していますが、同様の動作を "Standard Query Parser" を使用しても観察しています。また、"Standard Tokenizer" を使用しており、これはハイフンで分割します。これが問題と関連していますか？
助けていただければ幸いです。
Julian Hugo
もちろん、トークナイザーがどうかは確信が持てませんが、正しいのはおそらく "terms-with-hyphens"~1 ではありませんか？
ただの構文の問題で、メールでのやりとりでうまく伝わっていないかもしれませんが、興味があります。
（私の同僚であるJuliusが技術的な理由で返信できないため、彼の質問に代わって返信します）
こんにちは、Davidさん。
返信ありがとうございます！あなたの質問が指摘する点について、何か見落としている可能性があると思います。実際には、私たちはSolr 8.11を使用しており、ぼかし検索（https://solr.apache.org/guide/8_11/the-standard-query-parser.html#fuzzy-searches）を使用したいと考えています。つまり、クエリと異なる1文字または数文字の単語を見つけたいと思っています。私たちの理解では、以下のクエリを送信することで、クエリと最大2文字異なる一致を取得できるはずです（混乱を避けるために引用符を使用しないで別の行にします）：
term-with-hyphens~2
私たちの考えでは、ハイフンで区切られた用語は1つの単語なので、引用符は必要ないと考えています。あなたが提案したように、クエリでハイフンで区切られた用語を引用符で囲んで試してみましたが、マッチが返されるようです。標準のトークナイザーはハイフンで分割するため、引用符を使用しないクエリが何らかの形で次の 近接検索 クエリに変換されている可能性があります：
"term with hyphens"~2
それが失敗する理由を理解するのが大変ですが（それでもterm-with-hyphensに一致するはずです）、どうしているのかを理解できると良いですね。
よろしくお願いします。
Morten
わかりました、確認したところ、あなたは近接検索を行っていますので、用語はお互いの距離値以内にある必要があります。私の例では、距離値は2ですが、これは明らかに3つの用語では機能しません。ぼかし検索は単一の用語またはトークンに基づいていますので、各用語に対して~2を追加する必要があります。これに関する違いとなぜ期待通りに動作しないかについての非常に良いドキュメントがこちらにあります：
https://examples.javacodegeeks.com/apache-solr-fuzzy-search-example/
また、フレーズクエリフィールドを利用してブーストすることも試してみてください。
こんにちは、
わかりました、少しずつ理解が進んできました。私たちを混乱させていたのは、実際には「term-with-hyphens」のようなハイフンで区切られた用語を単一の用語と見なしており、それによりぼかし検索が通常通り適用されると考えていたことでした。しかし、あなたの説明を正しく理解したならば、正しい説明は実際にはぼかし検索が インデックス後に単一のトークンとなる用語に適用される ということです。標準のトークナイザーがハイフンで分割するため、ぼかし検索が適用されないということになりますね。私の理解は正しいでしょうか？
フレーズクエリフィールドについて、ちょっと理解が追いついていないのですが、qfクエリパラメータを使用することを意味しているのでしょうか、それとも何らかの種類の独立した「平行」フィールドの設定を指しているのでしょうか？
よろしくお願いします。
Morten
少し前のことですが、ぼかしクエリは解析されないと記憶しています。つまり、最大1つの編集距離で単一のトークンとしてterm-with-hyphensを探していることになります。しかし、ハイフンを分割するアナライザーを使用しているため、インデックスにはハイフン付きの用語が存在しません。
WhitespaceTokenizer（およびWordDelimiterFilterを使用しない）に移行して再インデックスすると、インデックスにはそのままterm-with-hyphensが含まれます。その後、FuzzyQueryを使用してそれを見つけることができます。
はい、今あなたは概念を理解していると思います。ダッシュは効果的に空白と同じで、句読点のように意味を持ちません。したがって、現在は3つの別々の単語になっています。そして引用します：
「fqおよびqfパラメータを使用して一致するドキュメントのリストが特定されたら、pfパラメータを使用して、qパラメータのすべての用語が近接して表示される場合に、ドキュメントのスコアを“ブースト”することができます」
pfパラメータには多くの力があり、あなたが探しているものにもっと適しているかもしれません。ちなみに、単語を組み合わせるシングルの概念もあり、これがさらに役立つかもしれません。例えば：
Dark storm rising
が
Dark_storm
Storm_rising
Dark
Storm
Rising
に変わることがあります。シングルを2に設定するとこうなります。これを行い、ストップワードを混ぜると、さらに面白いことができます。
そして、さらに楽しくしたいなら、自然言語処理/エンティティ抽出を使用して、これらの値だけをインデックスフィールドに混ぜ込み、ストップワードを取り除き、シングルを導入し、シングルの値を4まで上げて、pfでブーストします。退屈しないことを約束します。インデックスのサイズは増えますが、それを始めるときには既に十分なリソースを持っているべきです。
こんにちは、Davidさん、Markusさん
ご意見ありがとうございます！これで解決策を見つけるためのツールが揃ったと思います。
よろしくお願いします。
Morten
トピックへ返信するには、ログインが必要です。