Define field to search on at search-time

[gillian-meilisearch]

Related product team resources: roadmap card (internal only)

Related product discussions:

• Define field to search on at search-time product#107
• Define field to search on at search-time product#107 (comment)
• New ranking rule: `words in [attribute set]` product#595

Related spec: WIP

Motivation

Both Algolia and Typesense support this feature and it has been flagged several times as a blocker to adoption.

Usage

Enables running searches over a subset of searchableAttributes without modifying Meilisearch’s index settings.

⚠️ Refer to the final spec to know the details and the final decisions about the usage.

TODO

• Release a prototype
• If prototype validated, merge changes into main
• Update the spec

Technical prototype's TODO (@ManyTheFish addition)

• Milli side:
  • Ensure a database exists discriminating the fields that contain the searched words
  • Add a parameter to the Search struct
  • Modify resolve_universe
  • Modify bucket_sort
• API side:
  • Define a new Search parameter (restrictSearchableAttributes)
  • Make Milli work with the search parameter
• Test side (@ManyTheFish):
  • A query searching in an unsearchable field MAY return an error or MAY return an empty result (TBD)
  • A query with the terms matching strategy All must only return documents containing all the requested words in the searched field
  • Ensure the criteria take into account the filtered field:
    • Word: A document containing query-words in the searched field must be ranked before a document containing more query-words in all fields but fewer in the searched field.
    • Typo: A document containing query-words without typos in the searched field must be ranked before a document containing more query-words without typos in all fields but fewer in the searched field.
    • Proximity: A document containing query-words with a distance of x in the searched field must be ranked before a document containing query-words with a perfect distance in another field but a distance y worse than x in the searched field.
    • Attribute: A document containing query-words in the searched field must be ranked before a document containing more query-words in a higher-ranked field but fewer in the searched field.
    • Exactness: A document containing exact query-words in the searched field must be ranked before a document containing more exact query-words in all fields but fewer in the searched field

Remaining Uncertainties (@ManyTheFish addition) (poke @macraig)

After making a technical tour of the feature, some uncertainties remain:

• API: The dedicated search parameter is not defined, here is the comment link showing some competitor APIs
  • restrictSearchableAttributes
• Undefined behavior: when the end user search in a field that is not part of the searchable attribute the behavior of Meilisearch is undefined, we could return an error or return an empty response
  • Empty response
• Expectations of the feature: Does the order of the field given at search time reorder the searchable attribute order given in the settings
  • The order doesn't change
• Expectations of the feature, the feature could be implemented as an exclusive filter ("I only want the documents matching in this field") or as a ranking priority ("I want the documents matching in this field to be ranked before the others")
  • The feature is implemented as an exclusive filter

Impacted teams

@meilisearch/docs-team @meilisearch/integration-team

[dureuill]

Hello @ManyTheFish 👋

Seeing how the PR is already open for this feature, I hope I'm not arriving too late to the party 😃

I have feedback regarding this feature, in light of a discussion I had with @LukasKalbertodt

[...] the core problem is that Meili doesn't know how to compare attributes of different indexes regarding "importance". Just throwing ideas out there: one could, in a future version of Meili, allow users to not only specify the order of importance of attributes, but also assign a value the user picks. So instead of sending ["title", "author", "description"] to POST /indexes/../settings/searchable-attributes, one would send { "title": 1000, "author": 800, ..}. With that, the core problem is solved right? Because it can be now found out which of two attributes of different indexes is more important by comparing their number value.

(I'm quoting them)

So, I think it would be great if the "Define field to search on at search-time" could take this need into account, either in this first cycle if attainable at all, or at least planned as a future extension.

Concretely, the changes it would entail IMO:

• drop the restrict from restrictSearchableAttributes as it could be used to communicate distinct weights rather than a subset of the searchable attributes (must be done in first cycle)
• Allow to pass either a list (like today) or a JSON object where the key is the attribute name, and the value is its weight. The unclear part for me, though is what the weights should be. (can be done later)
  • The score on a scale of 1000 makes sense with today's relevancy prototype, but a future prototype could well change that scale to a unit float scale (from 0.0 to 1.0).
  • Implementation-wise, what we need is both the cost associated with each field, as well as the maximum cost that is considered. Ideally both of these could be derived from the weighted list and be index independent such that different lists still yield to comparable scores. Maybe this could be achieved by asking the user for both the weights (higher is better) and the scale (what is the max weight that gives a perfect score)?
• The cost computation in the attribute_fid ranking rule should take into account the list of "restricted" searchable attributes and their weights. Once we know how to convert the weights to costs and a max cost, this can be done easily by enriching the attribute_fid ranking rule with a map of the fid to the cost, and using that map instead of directly the fid as the cost in the conditions (implementation wise it may entail modifying the RankingRuleGraphTrait to accept &self parameters so we can have state in the graph based ranking rules, but it is not a very large change) (not sure if can be done later or must be done in first cycle)

Thanks for reading,
I'm available to discuss this anytime 😃

Side note:

• Undefined behavior: when the end user search in a field that is not part of the searchable attribute the behavior of Meilisearch is undefined, we could return an error or return an empty response
  - Empty response

What is the rationale for returning an "empty response" in that case? I would expect either:

1. (strongly preferred) a synchronous error, so that you can catch my typos when putting genre instead of genres or colour instead of color
2. (less preferred) since this field is not indexed, no document will match it (but other searchable attributes might return some hits). This will certainly be unexpected for users, though, if the field appears in some of their documents, is not searchable in the index settings. In this situation they won't get an error but these documents won't match either, not ideal.

[ManyTheFish]

Hello @dureuill,
I'll start with the easiest:

What is the rationale for returning an "empty response" in that case

Well, it's not really the case, Meilisearch behaves as you explained in (2) other searchable attributes might return some hits, we only filter on the restricted attributes that Meilisearch knows, the other attributes are ignored.
About the error, I don't have a strong opinion on that, I personally prefer returning an error, but, after discussing with @irevoire, it's possible that the documents containing the restricted field are not yet indexed and we would return an error until the task is processed, which could be disturbing.

Drop the restrict from restrictSearchableAttributes as it could be used to communicate distinct weights rather than a subset of the searchable attributes (must be done in first cycle)

We can do this 😄 we only chose restrictSearchableAttributes because it's consistent with competitors' API, but searchableAttributes is fine. (poke @macraig on this change)

Allow to pass either a list (like today) or a JSON object where the key is the attribute name, and the value is its weight. The unclear part for me, though is what the weights should be.

I personally don't like the weight approach, it's too tricky to set a good weight for a field from the end-user perspective. Moreover, it would be inconsistent with the setting API that defines an order.
However, in the current PR, we chose to take an ordered list in parameters that could be used to reorder the fields at search time in the future. 🤔

The cost computation in the attribute_fid ranking rule should take into account the list of "restricted" searchable attributes and their weights. Once we know how to convert the weights to costs and a max cost, this can be done easily by enriching the attribute_fid ranking rule with a map of the fid to the cost, and using that map instead of directly the fid as the cost in the conditions

It's completely doable, but I feel that is something different that the planned feature for v1.3.

[dureuill]

Thank you ManyTheFish for the detailed answer ☺️

About the error, I don't have a strong opinion on that, I personally prefer returning an error, but, after discussing with @irevoire, it's possible that the documents containing the restricted field are not yet indexed and we would return an error until the task is processed, which could be disturbing.

Ah OK, this happens in the case where restrictSearchableAttributes is used with an inferred searchableAttributes, that then gets modified by indexing new documents.

If I have to choose between this particular edge case and fixing the typos I prefer we fix the typos. Maybe this is inconsistent with some other attributes related APIs usable at search time, though? We would need to check that. I'm noting that our competitors only allow restrictSearchableAttributes at search time when the searchableAttributes setting is non empty and non null. I wonder if that makes sense for us to do the same? It would remove the edge case that @irevoire is thinking of. It would also be good to check what our competitor is doing in the case where an attribute that is not part of searchableAttributes is passed to restrictSearchableAttributes, as another data point.

About the naming change and scope change, I think it would be best if we discussed this synchronously. To be clear I'm not suggesting we completely remove the possibility to specify a list of attributes, just advocating that we add the additional capability of specifying the weights. In an ideal world we would also upgrade the setting to accept the weights additionally to the list.

[gillian-meilisearch]

Hello everyone 👋

We have just released the first RC (release candidate) of Meilisearch containing this change!
You can test it by using

• the release assets
• the Meilisearch Docker image

docker run -it --rm -p 7700:7700 -v $(pwd)/meili_data:/meili_data getmeili/meilisearch:v1.3.0-rc.0

If you encounter any bugs, please report them here.
Thanks in advance for your help and your involvement in Meilisearch ❤️

🎉 The official and stable release containing this change will be available on July 31st, 2023

⚠️ RC (release candidates) are not recommended for production