osFoundry / Platform
MMR diversity
Maximal Marginal Relevance picks results that cover different angles, not just the top match.
What it is
MMR diversity is a retrieval stage in osFoundry that applies Maximal Marginal Relevance when your knowledge base is queried. Plain relevance ranking has a well-known failure mode: the top results are often near-duplicates of each other because they all match the query the same way. If five chunks all restate the same paragraph, four of them waste context-window space and the model never sees the second or third angle on the question. MMR fixes this by scoring each candidate on both its relevance to the query and its dissimilarity from chunks already selected, then picking results that are relevant *and* mutually different.
Inside osFoundry, MMR is one stage in the custom RAG pipeline you build per chat Path in osStudio. A query first runs through hybrid retrieval (embedding search plus BM25 keyword search); you can then add filter and rerank stages, and place MMR after them so it diversifies an already high-quality candidate set. The stage exposes the standard MMR controls — a lambda parameter that slides between pure relevance and pure diversity, the size of the candidate pool it selects from, and how many chunks it emits into the prompt. Because every stage is a versioned, JSON-Schema-validated config, a code-chat Path and a customer-success Path can diversify differently, and you can roll back a change without touching source code.
This matters most on broad or ambiguous questions and on corpora with overlapping vocabulary, where the top embedding hits cluster tightly. MMR trades a small amount of raw top-1 relevance for coverage, which usually produces better grounded answers because the model sees the range of what the knowledge base actually contains. It stays consistent with osFoundry's BYOK, local-first stance: retrieval and diversification run in your workspace, embeddings go through a managed Voyage proxy or your own key, and no per-seat fee gates the pipeline.
Key capabilities
- Adds an MMR (Maximal Marginal Relevance) stage to your retrieval pipeline that balances relevance against redundancy, so top results cover different angles instead of restating the top match
- Configure MMR per Path in osStudio: set the lambda relevance/diversity tradeoff, the candidate pool size, and how many final chunks pass through to the prompt
- Chains after retrieve, filter, and rerank stages, so MMR diversifies an already-ranked candidate set rather than raw embedding hits
- Runs on the results of hybrid embedding + BM25 retrieval, with Voyage embeddings available through a managed proxy or your own keys under BYOK
- Every MMR config is a JSON-Schema-validated, versioned osStudio config with rollback, so different chat surfaces can diversify differently with no source-code changes
Use cases
- Support engineer: a broad troubleshooting question returns five near-identical chunks; MMR fills the slots with distinct causes so the answer covers more than one failure mode
- Researcher: querying a large document set where top embedding hits cluster on one section; MMR surfaces passages from different parts of the corpus for a fuller synthesis
- osStudio pipeline builder: tunes the MMR lambda on a code-chat Path for tight relevance while leaving a discovery Path more diverse, all as versioned config with rollback
Frequently asked questions
What is Maximal Marginal Relevance (MMR) and why would I add it to RAG?
MMR is a selection method that ranks candidate passages by relevance to the query while penalizing similarity to passages already chosen. You add it when your top retrieval results tend to be near-duplicates: without MMR, a broad question can return five chunks that all say the same thing, and the model only ever sees one angle. MMR keeps the most relevant chunk but fills the remaining slots with distinct, complementary passages.
How do I turn on MMR diversity in osFoundry?
MMR is a stage in the custom RAG pipeline you configure per chat Path in osStudio. You add the MMR stage after your retrieve, filter, and optional rerank stages, then set its lambda (the relevance-versus-diversity tradeoff), the candidate pool it draws from, and the number of final chunks. The config is JSON-Schema-validated and versioned, so you can tune it, test it on one Path, and roll it back if needed.
How is MMR different from a reranker?
A reranker re-scores candidates purely on how well each one matches the query, improving top-k precision. MMR optimizes a different objective: it maximizes relevance while minimizing redundancy across the selected set. They are complementary — in osFoundry you typically rerank first to get the best-matching candidates, then apply MMR to make sure the chunks that pass through cover different aspects rather than repeating the single best match.