In Haystack's SentenceTransformersDiversityRanker, how do its two strategies differ?

## What the component is `SentenceTransformersDiversityRanker` is Haystack's reordering component for the case where the top of a relevance-sorted list is dominated by documents that all say the same thing. It takes `query` and `documents`, returns `documents` reordered and truncated to `top_k`, and is configured with a sentence-transformers `model`, a `similarity` function, optional prefixes/suffixes, `meta_fields_to_embed`, a `strategy`, and `lambda_threshold`. ## `greedy_diversity_order` The greedy strategy embeds the query and all candidates, picks the candidate most similar to the query as the first output, and then iterates: at each step it selects the remaining candidate whose similarity to the *already selected* documents is lowest. Relevance to the query influences only the seed. The consequence to be honest about in an interview: this maximises spread, and spread is not the same as usefulness. On a candidate pool that is already tight and on-topic, greedy ordering is a cheap win. On a loose pool it will happily promote a barely-relevant outlier precisely because it is unlike everything else, and that outlier lands in the generator's context. Greedy diversity is safe when the upstream stage is precise and the pool is small. ## `maximum_margin_relevance` MMR keeps relevance in the loop at every step. Each remaining candidate is scored on two terms — how close it is to the query, and how close it is to the closest document already selected — and `lambda_threshold` (0 to 1, defaulting to a middle value) weights them. Push it toward 1 and the ranker behaves almost like a relevance sort; push it toward 0 and it approaches pure diversity. It is the strategy to reach for by default, because it has a knob and the greedy strategy does not, and because the failure mode of a bad `lambda_threshold` is a gradual shift rather than a cliff. Note that `lambda_threshold` only means anything under MMR. Setting it while running the greedy strategy is a no-op, and one of the more common configuration mistakes with this component. ## The cost that surprises people The ranker computes its own embeddings at run time using the model you configured. It does **not** reuse the `embedding` field that your indexing pipeline wrote onto each `Document`, and it does not reuse the query vector your query embedder already produced. So a query that goes through a dense retriever and then this ranker pays for embedding twice, over a candidate pool the size of whatever reached the ranker. That has three implications: 1. **Pool size is the lever.** Run this on a pool of tens, not hundreds. It belongs after a similarity ranker has already cut the list, not directly on a wide fused list. 2. **`warm_up()` applies.** Like any model-backed component, the constructor stores settings and `warm_up()` loads the model; a pipeline calls it for you, standalone use does not. That is another model resident in every worker process. 3. **Model choice is a real decision.** A small general-purpose sentence-transformers model is enough for measuring "are these two passages saying the same thing", and a bigger one mostly buys latency here. ## Placement in a pipeline The standard order is retrieve (possibly hybrid) → join → similarity rank → diversity rank → prompt build. Diversity ranking before a similarity ranker is close to pointless: the cross-encoder will re-sort by relevance and undo the arrangement. Diversity ranking as the very last step is also questionable if you then want a specific context ordering, since a later reordering component overrides whatever this one produced. ## When not to use it at all If near-duplicate passages come from the same source document being chunked with heavy overlap, the honest fix is upstream — deduplicate at indexing, or collapse chunks by source before ranking — not an extra model at query time. Reach for the diversity ranker when the redundancy is genuinely across distinct documents that happen to cover the same ground.