Question About Multi Match Queries

[gusdemayo]

Looking at the queries that get generated & eventually sent to elasticsearch, I've noticed that some of the fields retrieved & added to the multi_match section of the query in Smile\ElasticsuiteCore\Search\Adapter\Elasticsuite\Request\Query\Builder\MultiMatch in buildQuery vary depending on search term - sometimes they will appear in the multi_match query fields with their weights, sometimes not - even if is_searchable is set to true & search_weight has a value in the catalog_eav_attribute table

I've also noticed that there is sometimes variance in which analyzers are used on particular fields for particular search terms

how is it determined which fields are applied to particular search terms, & which analyzers are applied?

[gusdemayo]

For example, for one search term it'll use the default analyzer "standard" as well as "whitespace", but for another search term it'll use "standard" and "shingle" - or for one term a field that is marked as searchable with a search_weight of 1 will appear in the multimatch query, while for another it won't

[rbayet]

Hello @gusdemayo,

That's a pretty huge subject there.

There are several parameters that will affect how the queries are built

• the number of search terms (words) in the user request
• the type of request to built according to the determined "spelling type", basically
  • is/are the word/words present in the index in an exact/unaltered way - ie is the word "horses" present exactly in this form
  • or present if you take into account the stemming - ie "horse" and "horses" are considered the same word, so searching for "horses" will match "horse" and vice versa, same thing for "rider" and "riding"
  • or present only if you allow typographic fuzziness, so searching for "hurse" or "herse" will match "horse"
  • or not likely present at all or beyond the typographic fuzziness capabilities, like searching "djaquettes" for "jacket" where maybe the phonetic fuzziness will be able to match
• whether the following features are enabled or disabled or how they are configured
  • fuzziness
  • phonetic search
  • the phrase match boost value
  • the different settings, some of which are currently flagged as experimental
    • the ones affecting the output of the term vector request which determines the spelling type
    • the ones affecting the behavioral of the "filter" component of an exact match query
• and above of all that both the default analyzer of fields and their search weight

So, to make it simple, without going in too deep about the extra settings

• the "spelling type" will determine the type of request: "exact match", "most exact", "stop words", "most fuzzy", "fuzzy"
• depending on the type of request we will always target one "meta-field" which contains the data of searchable fields
  • "search" for all searchable fields: it's used for "sort of" exact match request
  • "spelling" for all searchable fields with spellcheck allowed: it's used when fuzziness is required
• on top of that, we will target fields related to fields that are searchable AND with a weight greater than 1
  • simply because we already have and target the data for searchable fields with a weight of 1 in the "meta-field"
• but, depending on the type of request, we will target specific versions of searchable and indexed fields
  • field.whitespace for exact match request: "horses" will only match "horses" and not "horse"
  • field.standard for both
    • exact match request: "horses" will match "horses" and "horse" (so if you search for "horses" and we do an exact match request the book "my friend the horse" is present amongst the results, maybe at a lower place than the book "all about horses")
    • fuzzy-like requests: to allow typographic fuzziness ("hurse" vs "horse")
  • field.phonetic for fuzzy requests
  • field.shingle for (exact match only ?) requests with several terms like "horse riding"
    • the request will have independent clauses for "horse" and "riding"
    • but also a clause for boosting documents that contain both terms close one to another (that's the phrase matching)

Beyond those "short" explanations lie all the hooks and crannies related to search relevance settings I've quickly talked about.
We will probably update at some point the wiki to include / refresh part of those explanations.

Regards,