Personalization: clarify that reranking operates only on the `limit` documents returned by Meilisearch, and document the placeholder search interaction

[tpayet]

Context

The current personalization documentation (https://www.meilisearch.com/docs/capabilities/personalization/overview and https://www.meilisearch.com/docs/capabilities/personalization/getting_started/personalized_search) describes the feature as:

Meilisearch retrieves documents based on the query as usual. The re-ranking model reorders results based on the user profile.

This is accurate but leaves a few important behaviors undocumented, which has caused confusion in practice when personalization is combined with placeholder search (e.g. personalized homepage feeds or infinite scroll).

Gaps in the current documentation

1. The reranker only sees the limit documents returned by Meilisearch. It does not operate on a larger internal candidate pool. This means the value of limit directly bounds how much the reranker can change the result set: it can only reorder within the limit documents that were retrieved.

2. Interaction with placeholder search. When q is empty, Meilisearch returns a deterministic set of documents based on ranking rules and filters. The userContext cannot change which documents are retrieved, only their order within that fixed set. As a result, sending two very different user contexts to the same placeholder query can produce visually identical (or near-identical) results, which is counter-intuitive given the promise of personalization.

3. Interaction with hybrid.semanticRatio when q is empty. The current docs do not clarify that semanticRatio has limited or no effect when the query string is empty (there is no query text to embed), so users may assume hybrid search is contributing personalization signal when it is not.

Proposed clarifications

In the personalization overview or a new "Best practices" section under personalization:

• Explicitly state that the reranker operates on the documents returned by the search (i.e., bounded by limit), not on a larger internal candidate pool.
• Recommend a sensible limit range for personalized search (with a note on Cohere's 2048-token ceiling, already tracked in Personalization: mention token limits #3580).
• Add a section on personalizing placeholder feeds (homepage carousels, infinite scroll, "For you" feeds), explaining that placeholder search will not produce a genuinely personalized candidate set, and that users should instead:
  • Run a real semantic search (semanticRatio: 1) with a few keywords extracted from userContext as q, or
  • Use a larger limit if they want the reranker to choose from a wider pool (with the associated latency / token trade-off).

Observed behavior worth documenting

When using personalization with placeholder search (q: ""), two patterns surface that are not obvious from the current docs:

• Two very different userContext values can return the same items (just in a different order), because the candidate pool returned by Meilisearch is the same for both calls.
• Two slightly different wordings of the same userContext can produce different result orders, because the reranker is sensitive to phrasing while operating on an identical underlying pool.

Both behaviors are consistent with the implementation (post-retrieval Cohere rerank on a fixed candidate pool), but neither is currently explained in the docs.

Related

• Personalization: mention token limits #3580 (token limits)