MmrReranker
Maximal Marginal Relevance: prefers a candidate that is close to the query and unlike the candidates already chosen.
What it is for, stated so it can be argued with
A nearest-neighbour search over a cache that has been running for a while returns near-duplicates of each other. Ask "how do I exit vim" and the five nearest entries may be five phrasings of the same question — which is fine when the answer is servable, and expensive when it is not. The cache tries candidates in order, and a Verifier costs a model call each time. Five paid calls that all inspect what is effectively one entry is four calls wasted, and the genuinely different candidate that would have been served is tried last.
MMR reorders so that each candidate the cache tries adds something the previous ones did not. The effect is fewer verifier calls before a servable candidate is reached. It does not change which entries are considered — the store already chose those — and with no verifier configured and every candidate iterated, it changes only which of several servable entries is served.
What it costs
One pass per selected candidate over the remaining ones, so quadratic in the candidate count. That count is single digits by default, and the arithmetic is a dot product over vectors already in memory.
Parameters
how much relevance is worth against diversity, in [0.0, 1.0]. At 1.0 this is the identity ordering; at 0.0 relevance is ignored entirely and only novelty counts. The default leans towards relevance, because the candidates are already the nearest ones and the goal is to break up duplicates rather than to go looking for variety.
Functions
Returns candidates in the order the cache should try them.