osFoundry / Platform
MMR 多样性
最大边际相关性挑选覆盖不同角度的结果,而不仅仅是最佳匹配。
简介
MMR 多样化是 osFoundry 中的一个检索阶段，在查询知识库时应用最大边际相关性（Maximal Marginal Relevance）。单纯按相关性排序有一个众所周知的弊病：靠前的结果往往彼此近乎重复，因为它们都以相同的方式匹配查询。若五个 chunk 复述同一段话，其中四个便白白占用上下文窗口的空间，模型也永远看不到问题的第二、第三个角度。MMR 的做法是同时按两方面为每个候选打分，一是它与查询的相关性，二是它与已选 chunk 的相异度，再挑出既相关*又*彼此不同的结果，从而解决这一问题。
在 osFoundry 中，MMR 是你在 osStudio 里按每个聊天 Path 搭建的自定义 RAG 管线中的一个阶段。查询首先经过混合检索（向量检索加 BM25 关键词检索），随后你可以加入过滤与重排阶段，并把 MMR 置于其后，让它对一个已然高质量的候选集做多样化。该阶段提供标准的 MMR 控制项：一个在纯相关性与纯多样性之间滑动的 lambda 参数、它从中挑选的候选池大小，以及它送入 prompt 的 chunk 数量。由于每个阶段都是经 JSON Schema 校验、可版本化的配置，代码聊天 Path 与客户成功 Path 可以采用不同的多样化方式，而你无需改动源代码即可回滚某次更改。
这在宽泛或含糊的问题上，以及在词汇相互重叠的语料上最见成效，因为此时靠前的向量命中会紧紧聚成一团。MMR 以让出少许 top-1 原始相关性换取覆盖面，通常能带来更有据可依的回答，因为模型看到的是知识库实际内容的广度。它与 osFoundry 的 BYOK、本地优先立场保持一致：检索与多样化在你的 workspace 中运行，向量经由托管的 Voyage 代理或你自己的密钥生成，也没有按席位收费来卡住这条管线。
主要功能
- 为检索管线加入一个 MMR（最大边际相关性）阶段，在相关性与冗余之间取得平衡，使靠前的结果覆盖不同角度，而非反复复述最优命中
- 在 osStudio 中按 Path 配置 MMR：设定相关性与多样性之间的 lambda 权衡、候选池大小，以及最终有多少 chunk 送入 prompt
- 衔接在检索、过滤与重排阶段之后，因此 MMR 对已经排好序的候选集做多样化，而非对原始向量命中
- 作用于向量检索与 BM25 混合检索的结果之上，Voyage 向量可经托管代理或在 BYOK 下用你自己的密钥获取
- 每份 MMR 配置都是经 JSON Schema 校验、可版本化并支持回滚的 osStudio 配置，因此不同聊天界面可以采用不同的多样化方式，无需改动源代码
使用场景
- 支持工程师：一个宽泛的排障问题返回五个近乎雷同的 chunk；MMR 用彼此不同的成因填满各个位置，让回答覆盖不止一种故障模式
- 研究人员：在一个大型文档集上查询，靠前的向量命中聚集在同一节；MMR 从语料的不同部分带出段落，从而得到更完整的综合
- osStudio 管线搭建者：在代码聊天 Path 上把 MMR 的 lambda 调向严格相关，同时让探索型 Path 保持更高的多样性，这些都以可回滚的版本化配置完成
常见问题
什么是最大边际相关性（MMR），我为何要把它加进 RAG？
MMR 是一种选择方法，它按候选段落与查询的相关性排序，同时对与已选段落的相似度施加惩罚。当你靠前的检索结果往往近乎重复时，就该加入它：没有 MMR，一个宽泛的问题可能返回五个说着同一件事的 chunk，模型只看到一个角度。MMR 保留最相关的 chunk，但用彼此不同、相互补充的段落填满其余位置。
如何在 osFoundry 中启用 MMR 多样化？
MMR 是你在 osStudio 里按每个聊天 Path 配置的自定义 RAG 管线中的一个阶段。你把 MMR 阶段加在检索、过滤和可选的重排阶段之后，再设定它的 lambda（相关性与多样性的权衡）、它取用的候选池，以及最终 chunk 的数量。该配置经 JSON Schema 校验并版本化，因此你可以调优、在某个 Path 上测试，必要时回滚。
MMR 与重排器有何不同？
重排器纯粹按每个候选与查询的匹配程度重新打分，提升 top-k 精度。MMR 优化的是另一个目标：在所选集合内最大化相关性、同时最小化冗余。两者互补：在 osFoundry 中，你通常先重排以得到最匹配的候选，再应用 MMR，确保通过的 chunk 覆盖不同侧面，而非重复那唯一的最优命中。