Policy for matching words

[gmourier]

Description

On a search with one or multiple words in the query. The user can choose what happens if a word on a query is not present on the document or the engine has not found enough documents. We could imagine a new setting to define a policy.

Some possibilities:

• none: All terms must be contained in a document to be considered as a search result. Introduced as all in v0.29version.
• last: If no document contains all the given terms, the engine removes the last query term and so on. Introduced as last in v0.29 version.
• first: If no document contains all the given terms, the engine removes the first query term and so on.
• optional: All words in a query are always optional;
• frequency: If no document contains all the given terms, the engine removes the most common term within the dataset and so on. Introduced as frequency in v1.9
• size: If no document contains all the given terms, the engine removes the shorter term and so on.

---

EDIT by @curquiza
Adding these issues here for the traceability:

• Meilisearch return results with a completely different word in it meilisearch#2198
• Meilisearch shows irrelevant results after updating to v0.27 meilisearch#2420
• how to narrow v0.24 results returned to mimic default v0.18 behavior ? meilisearch#2114
• Force all terms to be present meilisearch#1998

Needing optional or frequency

• The matching strategy is flawed meilisearch#4093

[tao]

I would like to add some input on how policies for matching words could be used and help solve some of our problems.

In our case, we are using MeiliSearch on a large text database and found that searching by "all words", "any word", and "exact phrase" provide the best results, as our users often search for quotes (or parts of a quote) that they remember the words for exactly (minus spelling mistakes and case sensitivity).

So perhaps policies like none and optional could provide us this functionality if they can be applied to the phrase search. Where none would only return results that match the exact phrase, and optional would allow us to do "any words" or "all word" searches.

We found after our testing that the normal search works like an "any word" search and returns and result that has some of those words sorted by relevancy. While phrase search words a lot more like "all word" search at the moment and returns results that contain those words throughout the document.

We are having trouble creating an "exact phrase" search, that only returns results with the exact phrase only, without gaps or other words in the middle. So for instance if you searched for known to your peoples we don't want to include a result with the one *known* as Daniel provided aid *to your peoples* The current rules for phrase search allow for that but perhaps a policy could help us achieve this result.

For example, we are trying to re-create these search results in MeiliSearch:

In this example of exact phrase search above, you can see only one result was returned out of around 65,000 paragraphs. This is a common way people use the search if they remember certain words from a quote and try find the full paragraph of what was said.

Perhaps a stricter policy on phrase search could probably achieve this same result...

This example above of "all words" search seems to be like the results we are currently getting from phrase search, as all the words exist in the document. So a useful feature that could probably be achieved with an none policy on the default search. So 21 results are returned now compared to the 1 in the previous example.

The last example of "any word" search works like the default Meilisearch and we're happy with that so far. This seems to match the optional policy but it seems like the default one for us.

We don't really see any case for last or first policies in our project but perhaps they'd be more useful for e-commerce websites... as a designer I wouldn't even include that option on the website because it gives the user too much choice and might create too much additional confusion... instead because MeiliSearch is a live-typing experience they can re-order the words themselves or omit words and see the result update in real-time. If they don't find the result, they could just remove the last word themselves or try another group of words. Personally, those seem a bit redundant to me and perhaps would work better if the search wasn't instant.

[gmourier]

Thank you @tao for this very complete feedback.

However, I have trouble understanding why this is not possible with the q parameter today strictly regarding your examples given here.

I have the impression that it would be possible today to fill all your criteria in this way with a transformation of the q parameter according to what the user chooses as search mode.

Let's say end-users type Law of One in the search bar.

Next to that, he chooses the search "mode" between any, all and phrase from your interface.

Let's break it down by mode.

any mode

In this case, you don't have to transform anything, the q parameter of the search query will be sent as Law of One. The engine will return matching documents containing those words with typo tolerance. The words ranking rule will return documents containing the Law of One term as more relevant than documents containing just Law and of and so on.

all mode

If the user chooses this mode, the client code can transform Law of One to "Law" "of" "One" for the qparameter. This way, MeiliSearch will only return documents containing the 3 terms.

phrase mode

If the user chooses this mode, the client code can transform Law of One to "Law of One" for the q parameter. This way, MeiliSearch will only return documents this phrase with this exact order in the expression of the terms.

However, I don't understand the logic of being able to choose any and all within the interface for a search request. For me, these modes are not cumulative, but I'm probably (for sure) missing something. 🤓

[tao]

That's what I'm trying to figure out... because currently it's not working and not sure if it's something that needs to be solved with policies or if it's an issue with phrase search.

Regarding any or all we found this important if a user is searching for colours... for instance one example we have is looking for the phrase "red orange yellow green blue indigo violet" which will return very different results depending on whether you select all words or not. Perhaps in one instance you'd want any results that contain any of these colours, in another instance you want results that mention all the rainbow colours at once in the same context. I think the relevancy rules would push the articles that mention all colours to the top but it's a requirement the client has that I'm trying to work with.

[gmourier]

Thanks, @tao. We have indeed a bug on the Phrase Search which is also in v0.23.1 that we are investigating. It seems to me that this is the version you are using. We're sorry about that. I should have mentioned it earlier.

What you can do is to test with version v0.21.0 (the phrase search works as expected on this one) the different modes explained above and confirm that it corresponds well to your need.

[tao]

Okay. I've done some testing on v0.21.0 and the phrase search does seem to be working correctly now, which I'm really glad about so we will wait until the next release when it's fixed before we add search to our website.

Any word search

So one area that could be explored (as a policy?) is what happens when you run a default search, what we are referring to as an any word search... and if you query the search phrase red orange yellow green blue indigo violet it will return relevant results which include all or multiple colours first, but towards the end of the results it will only return results that include the colour red in them... where it could also continue and show results with any colour, like documents with only orange in them, or a document that only has the word blue. That would be a nice option to include.

So am I correct in assuming that is like the use-case for the first policy mentioned above? Where MeiliSearch would first return the most relevant results first, the start returning results with where some words are missing (optional?), then try the first policy and remove words from the front of the query to search for even more hits...

Phrase search

The next use-case where you could use a policy is a stricter phrase search. We don't have a problem with this but I thought it would be worth mentioning:

You can see in this exact phrase search, that the first result is an exact match but the second result has the same words occurring in order twice in the same paragraph with other words in-between. So I think that's perfectly fine if MeiliSearch believes it's a good enough match but another case where a policy could be used in the future?

[LowSociety]

I'll just add my two cents here, as we're currently unable to upgrade from v0.20.0 due to the fact that later versions return results regardless of how many terms match the document.

We have a search field with an autocomplete that can deliver three types of results: Categories, Articles and Businesses. These are facetted but we want to limit each type to three results. Since we can't set a limit on the number of results per facet we actually make three requests to the MeiliSearch engine, with a facet filter on each one.

Currently (v0.20.0), if a user enters a multi-word query where only one word matches a document, no results are returned. This is desired behaviour from our end, and if I understand correctly would be possible if the none option was added as described above. Note that "restaurants old town" does not match only "Restaurants" in v0.20.0:

Later versions do match only "Restaurants" though, meaning the default behaviour has changed to work like the optional option described above. This causes problems for us as we always get three (worse) results from the first request.

We'd love to have the option to choose the matching policy per request. Although I do realise that our issues could be resolved in other ways, like the possibility to limit results per facet or even multi-index search where we separate the types into different indexes altogether.

[gmourier]

Thank you very much for this feedback! 🙏

Regarding this sentence "This causes problems for us as we always get three (worse) results from the first request."

The ranking rule should give priority to the documents that contain all the search terms if some documents can be matched and therefore be more relevant than others that do not contain all the terms. @Kerollmops I think I'm not wrong, correct me if I am!

Indeed, the problem here is that the behavior is assigned for all requests which is not necessarily desired.

[LowSociety]

Yes, it would indeed prioritize documents containing more terms, but since we split the request into three we get worse results from the first facet since there are no documents containing all words. This is really just a side-effect of us splitting the query into three.

[curquiza]

I would add here, we should also define the default behavior we want :)
Currently (v0.21.0 and later) the default behavior is last. In v0.20.0 and before, the behavior is none. What is the most used or not.

Also, we should consider the impact on search speed. We are not sure this is related but in v0.19.0 we noticed better search performance than for v0.21.0 and later.
See this code sandbox created by @bidoubiwa using v0.19.0 -> https://codesandbox.io/s/meilisearch-boardgames-uj2tr
@bidoubiwa noticed a huge performance decrease between these both versions, for more detail regarding this, please ask her :)

[bidoubiwa]

My bad, code sand box has upgraded to the v0.24. I'm currently trying to create an instance on digital ocean with the board game dataset in v0.19 (but digital is down so I'm coming back soon).

The loss in performance comes when I start a second word.

With the same dataset and without any settings

multiple words

v0.19

v0.25

one letter

v0.19

v0.25

[Lupul]

Hello, is there a way to switch back to none matching policy when running v0.27.0?

[gmourier]

Hello @Lupul👋 This is not possible yet.

Could you tell me why the current behavior doesn't suit you? Thanks!

[Lupul]

I'm looking for a way to limit the results to only the documents that contain all words in the query but without losing other fuzzy features like prefix and typo matches.

Ex query: "ssd samsung pro" (without quotes ) will return all documents that contain the first word 'ssd' but sort them correctly

[goldmerc]

I'm using 0.25.2. If I make a multi word search (n words), I get the results with all the words first and then I get results with some or one of the words. I would like a situation where I only get the results with all the words, but if there are not results with all the words, I then get the results with n-1 words. If there are no n-1 results, I should get the n-2 words, and so on.

I tried using the parenthesis around each word suggestion but that stops fuzzy search, so it doesn't catch typos or even plurals.

Thanks for a great package!

[gmourier]

Hi @goldmerc

Just to be sure you would like something like a strict mode that would stop match results by removing words?

e.g.

• Search for results containing all words, if results are found then stop here and return a search response, else
  • Remove a word to find results, if results are found, stop here and return, else
    • Remove another word and so on...

[goldmerc]

Almost. If there were 3 words in the search but no full match, I would like to get all the matches with every combination of 2 words. And I would like fuzzy search to work especially for plurals.

[gmourier]

Thanks @goldmerc !

[trailerparkdev]

Hi all.

Definitely something that would be very useful on a per-usecase basis. Even more on a per-query basis if possible. It all boils down to the formal view that the more options developers have to specify a search behavior, the better they can solve customers problems, which are essentially infinite!

Thank you @gmourier for the proposal.

Keep up the good work.

[mvuidev]

Hi,

In addition to what others said, my suggestion would be a min/max number of results IF the query has been "transformed" (words removed).

For example, say i want minimum 100 results, and a maximum of 200 if the query was transformed.

If the query with all words matches 120 results, just return them.
If the query with all words matches 800 results, just return them.

If the query with all words matches only 50 results, the last word will be removed from the query.
But without the last word, i get 1500 results : that's too much irrelevant results.
In this case i'd like to get only 200 results.

I don't know if i explained well my needs but I really hope this could be possible ! 😄

[curquiza]

Thanks @mvuidev I think I understand better now. You would a kind of threshold: "if more than this threshold, return all of the documents you found. If less, fill with more documents by dropping query words"

The main issue I can see here, is when you say "I want to get the most relevant results, no matter the number of results" -> Meilisearch is not a search engine to work without a limit during the search, otherwise, you can have performance issues. Meilisearch is indeed designed to find the most relevant documents within a limit, that's why limit exists and is set to 20 by default.

I don't know if it's a specific usecase yet, but in any case, thanks for sharing it 😄 If anyone has a similar usecase please share it with us!

[mvuidev]

@curquiza

Yes, a threshold like Typesense does, but with a "maximum of results if tokens have been dropped", to avoid getting too much irrelevant results.

About the number of results and performance, i usally make multiple requests for the same search untill there is no more results (with limit + offset).

Anyway, thank you for considering my request 😄

[curquiza]

Thank you for taking the time to describe your need! 😄

We are currently working on improving the relevancy customization. Since there are a LOT of different use cases and possibilities regarding this, we want to improve the relevancy customization step by step. Indeed, one of Meilisearch's purposes is to stay easy to use and complex settings can lead to a bad user experience.

I hope the several updates we will do in the future will help you handle Meilisearch as you expect!

[xushenkun]

By default, right word will be dropped. But maybe "everyone" is much more important than "hello", So how can I decide which word should be dropped first?

[gmourier]

Hi @xushenkun

That's a good question and made me think of that; How do you know which word is more important to an end-user? Defining a strategy that works for you, may not work for other users. Maybe it's the first, the last, the middle one?

Defining a list of words with a dedicated weight that would be given by the developer seems inelegant and ineffective at first sight. It would be even worse if the end-user had to do it.

Guessing a user's intention involves other more complex mechanisms (to go very far, I'm thinking of a layer that does this automatically based on previous queries that have given satisfactory results measured with a click rate on search results)

[curquiza]

Hello everyone here! 👋

We are working on introducing the relevancy customization during the search with Meilisearch, and we just released a first prototype that allows you, for example, only to return documents containing ALL the query words! 🔥

It would be super helpful if you could let us know if this helps with your issue.
To know more about the prototype and how to use it, take a look at the dedicated discussion.

[gmourier]

Hello 👋

We have just released v0.29.0rc1, which is a release candidate of v0.29.0 🔥

It introduces a new search parameter named matchingStrategy;

For now, it accepts 2 strategies:

• last: the default strategy. If no document contains all the given terms, the engine removes the last query term and so on.
• all: All the query terms must be present in a document to make it a search result.

Binaries are attached to the release, or you can use the docker image:

docker run -it --rm \
    -p 7700:7700 \
    getmeili/meilisearch:v0.29.0rc1

Let us know about any bugs or feedback! 😄 It would be really helpful.

FYI, the official v0.29.0 release will be available on 3rd October.

[gmourier]

Hello folks 👋

v0.29 release is finally out. 🔥

It brings the matchingStrategy search parameter; Accepting 2 strategies.

• last: the default strategy. If no document contains all the given terms, the engine removes the last query term and so on.
• all: All the query terms must be present in a document to make it a search result.

If you were stuck in a version earlier than v0.21.0 because it was critical for you to have the all strategy, you can now enjoy all the new features and improvements we have added since then!

This discussion remains open to discuss other strategies that we could implement in the future.

Thank you ✨

[chrissshh]

I would really appreciate something along the lines of "optional" for query terms. It's especially useful in fashion since users don't usually put the most important terms first and they may even search for multiple colors using the search box. Is there an ETA on when this feature could be released?

[macraig]

Hi @chrissshh , we don't have an ETA for this feature for now, but we appreciate your feedback to consider when we add it to the roadmap in the future.

[antonhedling]

I would love to have "optional" as a matching strategy!

Our use case is that our search bar will automatically suggest filters based on the query term. If a user selects the suggestion, it will be added as a facet filter. But the search term must remain in the search input for technical reasons.

The result is that a user then would get

Search query: "whit shrt"
Facet filters: "Color: white", "Type: Shirt"

The search will filter by color and type, but then also try to match the search term, which can restrict the results depending on what the user entered as a query.

Essentially, I would like to have the option of making the entire search into: {search_query} OR {filters}. It sounds like matching strategy: optional may achieve this.

Perhaps an edge case and some other way to do this, but I haven't figured it out!

[macraig]

Hi @antonhedling , thanks for describing your use case!

Essentially, I would like to have the option of making the entire search into: {search_query} OR {filters}

Have you considered using the multi-search endpoint?

[maiorfi]

"Optional" matching strategy would be really useful. Sadly, default "last" strategy has the effect of giving to first word within search query kind of exclusive-priority, since it becomes mandatory for a document to be returned. What if, searching for "one two three", I would like to get documents containing "two three four" or "three four five"?

[xamir82]

@irevoire @curquiza Hello, sorry to tag you guys; but it's been nearly 6 months since we got the last update in meilisearch/meilisearch#4093. Any movement on this one yet? Again, this is pretty important stuff!

[dtrckd]

I have to admit that the lack of effort in this area is a real enigma, given the quality of the rest of the work. But unfortunately, without it, the product can't claim to compete with elasticsearch (although that's what it seems to claim when you read the doc/blog resources).

Hope it will change someday ;)

[nhatimme]

We also got issues. We are searching with q = 850. In the database we have 100 results, containing 850 like: 100850. The problem is: Meilisearch only provides results, based on the begin value. Like it returns: 850, 85001. It does NOT return the 100850 or 1850. How to manage/fix this? We would like to get all the results which includes 850 in it ofcourse.

PS. Those numbers, are ID's from our objects (results). id: 850 as example.

"hits": [ { "id": 850, }, { "id": 10850, } ]

[macraig]

Hi @nhatimme , this seems to be similar to this other discussion. Feel free to upvote and comment there as well.

[macraig]

Hi @maiorfi @xamir82 @dtrckd , thank you for submitting your feedback and comments. As I said in one of the messages above, we don't have an ETA on this for now. We are going to include it in our next planning discussions, and I'll make sure to share any updates in this discussion. We understand the importance of this feature and appreciate your understanding as we navigate through our priorities.

[nhatimme]

We really need it. Its sort of a basic in my opinion if you want to battle those other programs. We want to stick on Meilisearch, would awesome if this is being implemented within a month.

Keep us informed, good luck!

[xamir82]

Second what @nhatimme said. Meilisearch is pretty pleasant to work with and I really don't want to have to switch to something else, but this is a very fundamental hole that should be filled ASAP, in my opinion. Thank you in advance.

[maiorfi]

Concerning the so desired "optional" strategy still missing, I was wondering if, taking advantage of some workaround (for example running two searches with "first" and "last" strategies and then somehow merging results both in terms of hits and facets), would it be possible to face the temporary (I hope) lack of that strategy. Any thoughts about that?

[macraig]

A user shared a similar workaround here. They split all the search term combinations in multiple search requests using multi-search and then merge the results.

[bedus-creation]

Hi,

Thanks for the a great tool

we are trying to implement OR search (Optional in above), which should allow us to search by either of the terms, is there any way to implement it?

We were trying to implement multi-search, but we have pagination too, so we couldn't figure out how to calculate pagination. So is there any way we can implement it ?

• forking the repo and implementing optional as above?
• Or how can we implement optional search with multisearch ?

[macraig]

Hi @bedus-creation , we've been working on implementing the frequency matching strategy (see comment below) which could be considered an "advanced" version of the optional strategy. Do you think that would help your use case?

[macraig]

Hi everyone, we're happy to announce that we will be shipping a new frequency matching strategy in v1.9 (which will be officially out on July 1st). If no document contains all the given terms, the engine will remove the most common term within the dataset and so on.

The upcoming API details can be found here.

[macraig]

Update: frequency matching strategy is available in pre-release and will be officially out on July 1st

[macraig]

Hey folks 👋

v1.9 has been released🦎 and the frequency matching strategy is now officially supported.