You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I was discussing with Curqui and Tamo how to improve the search performances on hybrid-search-configured indexes.
When performing a hybrid search, the engine has to compute the embedding corresponding to the query. It happens only if the keyword-only results are irrelevant enough, but it can cost a lot of time if it has to do so.
Meilisearch is a search-as-you-type search engine that seeks the best results at every keystroke. That's the main reason why we support prefix search. Computing embeddings are too slow to be used with this kind of use case, and that's why I want to propose an alternative. Instant-Meilisearch already proposes delaying requests to be sent after some time, but it removes the feeling of instantaneity.
I want to explain that users can keep performing requests on each keystroke and only send the hybrid-search one after the last keystroke. We can detect the last keystroke when no other key is struck after some time (100ms-500ms). The actual hybrid search is performed, awaited, and displayed at that point.
However, there is still something imperfect: The results will display keyword-only results, but when the hybrid results return, the results will change. It's a bad pattern, especially when the user finds its result and plans to click on it (and I hate that). We can still consider that if the user planned to click on keyword-only results, they are good enough and will not be replaced by hybrid ones.
Another proposal could be to perform keyword-only search requests with a small number of documents (max 5 documents), and the last hybrid request could perform a normal-length search request (20 documents). This ensures the user will not attempt to select a bad keyword-only result but only a top 5 one that has fewer chances to be replaced by hybrid ones.
The text was updated successfully, but these errors were encountered:
Kerollmops
changed the title
Some speed improvement advices
Some speed improvement & quality of search advices
Mar 19, 2025
I was discussing with Curqui and Tamo how to improve the search performances on hybrid-search-configured indexes.
When performing a hybrid search, the engine has to compute the embedding corresponding to the query. It happens only if the keyword-only results are irrelevant enough, but it can cost a lot of time if it has to do so.
Meilisearch is a search-as-you-type search engine that seeks the best results at every keystroke. That's the main reason why we support prefix search. Computing embeddings are too slow to be used with this kind of use case, and that's why I want to propose an alternative. Instant-Meilisearch already proposes delaying requests to be sent after some time, but it removes the feeling of instantaneity.
I want to explain that users can keep performing requests on each keystroke and only send the hybrid-search one after the last keystroke. We can detect the last keystroke when no other key is struck after some time (100ms-500ms). The actual hybrid search is performed, awaited, and displayed at that point.
However, there is still something imperfect: The results will display keyword-only results, but when the hybrid results return, the results will change. It's a bad pattern, especially when the user finds its result and plans to click on it (and I hate that). We can still consider that if the user planned to click on keyword-only results, they are good enough and will not be replaced by hybrid ones.
Another proposal could be to perform keyword-only search requests with a small number of documents (max 5 documents), and the last hybrid request could perform a normal-length search request (20 documents). This ensures the user will not attempt to select a bad keyword-only result but only a top 5 one that has fewer chances to be replaced by hybrid ones.
The text was updated successfully, but these errors were encountered: