Edismaxの謎？
コピーリンク
(The bot translated the original post https://lists.apache.org/thread/rhvpztwrb367x9oz8hh4w2q4hdpxsz3y into Japanese and reposted it under Apache License 2.0. The copyright of posted content is held by the original poster.)
皆さん、こんにちは。
勇気を持っており、edismaxパーサーの動作について少し知識がある方に、クエリ解析に関する簡単な質問があります！
これはおそらく例を挙げるのが最善だと思います：
以下に、2つのフィールドタイプで3つのフィールドがあります（以下に定義されています）
ST_Field1 - search_textフィールドタイプ
ST_Field2 - search_textフィールドタイプ
LC_Field1 - lowercaseフィールドタイプ
<!--英語のテキスト検索-->
<fieldType name="search_text" class="solr.TextField" positionIncrementGap="100" uninvertible="false">
<analyzer type="index">
<tokenizer class="solr.WhitespaceTokenizerFactory"/>
<filter class="solr.WordDelimiterGraphFilterFactory" generateWordParts="1" generateNumberParts="1" catenateWords="1" catenateNumbers="1" catenateAll="0" splitOnCaseChange="1" preserveOriginal="1"/>
<filter class="solr.FlattenGraphFilterFactory"/>
<filter class="solr.LowerCaseFilterFactory"/>
</analyzer>
<analyzer type="query">
<tokenizer class="solr.WhitespaceTokenizerFactory"/>
<filter class="solr.WordDelimiterGraphFilterFactory" generateWordParts="1" generateNumberParts="1" catenateWords="0" catenateNumbers="0" catenateAll="0" splitOnCaseChange="1"/>
<filter class="solr.LowerCaseFilterFactory"/>
</analyzer>
</fieldType>
<!--コード値検索 例：フライト番号QF123-->
<fieldType name="lowercase" class="solr.TextField" positionIncrementGap="100" uninvertible="false">
<analyzer>
<tokenizer class="solr.KeywordTokenizerFactory"/>
<filter class="solr.TrimFilterFactory"/>
<filter class="solr.LowerCaseFilterFactory" />
</analyzer>
</fieldType>
これらのフィールドを2用語クエリ「34567 something」でクエリした場合（フレーズクエリではなく、q.op=AND）、qfフィールドのみを変更すると、クエリパーサーの動作が大きく変わります。
クエリ1：qf=ST_Field1 ST_Field2を使用した場合
qfに「lowercase」フィールドタイプを使用しない場合 - 生成されるクエリは、各用語（合計2つ）ごとにMUST DisjunctionMaxQueryが存在し、各qfフィールドがSHOULD句となる - これが期待される動作です
"querystring":"34567 something",
"parsedquery":"+(+DisjunctionMaxQuery((ST_Field1:34567 | ST_Field1:34567)) +DisjunctionMaxQuery((ST_Field2:something | ST_Field2:something )))"
クエリ2：qf=ST_Field1 LC_Field1を使用した場合
「search_text」フィールドタイプのqfに「lowercase」フィールドタイプを使用すると - 生成されるクエリは、各qfフィールドが「search_text」フィールドタイプのMUST句となり、タイプ「lowercase」フィールドがSHOULD句となる -
"querystring":"34567 something",
"parsedquery":"+(+DisjunctionMaxQuery(((+ST_Field1:34567 +ST_Field1:something) | LC_Field1:34567 something )))"
これらのクエリの動作変更を規定するルールを高レベルで知っている方はいますか？ もし知っている場合、そのような挙動変化を制限するために回避すべき特定の解析チェーンはありますか（つまり、クエリ1の動作を強制する、上記のクエリ2の動作ではない）。
Open Source Connectionsの方々（John Berryman）がedismaxに関する素晴らしい記事を持っています（https://opensourceconnections.com/blog/2013/03/07/the-anatomy-of-a-dismax-query/）、そしてそれが彼らかこのフォーラムのどこかで、クエリが「複雑すぎる」と挙動が変わると読んだことがありますが、その挙動変化を予測できるように、何がその挙動変化を引き起こすかのいくつかの具体的な点を理解することは有用です！
よろしくお願いします、
Dwane
Solr 8.8.2
最初のクエリでは、両方のフィールドが同じ fieldType を持つため、クエリパーサーは各節の用語を簡潔に結合できます。おそらくパフォーマンスのためにもそうします。しかし、2番目のクエリでは、2番目のフィールドが異なるタイプであるため、別々である必要があります。そのフィールドにキーワードトークナイザーを使用したため、クエリ文字列は個々の用語に分割されません。バージョン7.0で "sow" パラメーター（ホワイトスペースで分割）がデフォルトで false に変更されたと思います。現在、クエリパーサーは入力をホワイトスペースで分割しなくなりました。必要な場合は、解析でそれを行う必要があります。"sow=true" を設定してみて、どのような結果が得られるか確認してみてください... ただし、データの性質に応じて、そうすると実際には望んでいる結果が得られない場合もあります。
説明の唯一の不正確な部分は、lowercase フィールドが SHOULD 節であることです。q.op=AND は SHOULD 節を生成すべきではありません。クエリに "echoParams=all" を追加して、レスポンスヘッダーに "mm" と "q.op" パラメーターがあるかどうかを確認してください。dismax と edismax では、q.op と mm の相互作用を正しく設定するのが非常に難しく、非常に驚くべき結果を生み出すことがあります。どちらか一方だけを設定することをお勧めします。
Shawn
Shawn、理解できました！ sow パラメーターを true に設定すると、意図した動作が得られましたが、他のすべてが期待どおりに動作しているかどうかを確認するためにさらなるテストを実行する必要があります。さらに、mm と q.op に関する警告に感謝します。それについて注意を払います！ sow についての言及が、edismax および sow を使用する際に発生する可能性のあるいくつかの特異性について良い洞察を提供する2つの優れた記事につながりましたので、他の興味を持つ読者にはこれらの記事が役立ちます。
Doug Turnbull（Open Source Connections）
https://opensourceconnections.com/blog/2018/02/20/edismax-and-multiterm-synonyms-oddities/
Alessandro Benedetti（Sease）
https://sease.io/2021/05/apache-solr-sow-parameter-split-on-whitespace-and-multi-field-full-text-search.html
再度、貴重な情報をありがとうございました。
Dwane
トピックへ返信するには、ログインが必要です。