osFoundry / Platform
Diversité MMR
La pertinence marginale maximale choisit des résultats qui couvrent différents angles, pas seulement le top match.
Présentation
La diversité MMR est une étape de récupération d'osFoundry qui applique Maximal Marginal Relevance lorsque votre base de connaissances est interrogée. Le classement par simple pertinence a un défaut bien connu : les premiers résultats sont souvent quasi identiques entre eux, parce qu'ils correspondent tous à la requête de la même façon. Si cinq chunks reprennent le même paragraphe, quatre gaspillent de l'espace dans la fenêtre de contexte et le modèle ne voit jamais le deuxième ni le troisième angle de la question. MMR corrige cela en notant chaque candidat à la fois sur sa pertinence vis-à-vis de la requête et sur sa dissemblance avec les chunks déjà retenus, puis en choisissant des résultats à la fois pertinents *et* mutuellement différents.
Dans osFoundry, MMR est l'une des étapes du pipeline RAG sur mesure que vous construisez par Path de chat dans osStudio. Une requête passe d'abord par une récupération hybride (recherche par embeddings et recherche par mots-clés BM25) ; vous pouvez ensuite ajouter des étapes de filtre et de reranking, et placer MMR après elles afin qu'il diversifie un ensemble de candidats déjà de haute qualité. L'étape expose les réglages MMR habituels : un paramètre lambda qui glisse entre pertinence pure et diversité pure, la taille du pool de candidats dans lequel il puise, et le nombre de chunks qu'il envoie dans le prompt. Comme chaque étape est une configuration versionnée et validée par JSON Schema, un Path de chat de code et un Path de customer success peuvent diversifier différemment, et vous pouvez annuler un changement sans toucher au code source.
Cela compte surtout pour les questions larges ou ambiguës et pour les corpus au vocabulaire qui se recoupe, où les premiers résultats d'embeddings se regroupent étroitement. MMR cède un peu de pertinence brute au top-1 en échange de couverture, ce qui produit en général des réponses mieux étayées, car le modèle voit l'étendue de ce que contient réellement la base de connaissances. Cela reste cohérent avec la posture BYOK et local-first d'osFoundry : la récupération et la diversification s'exécutent dans votre workspace, les embeddings passent par un proxy Voyage managé ou par votre propre clé, et aucun tarif par siège ne verrouille le pipeline.
Fonctionnalités clés
- Ajoute à votre pipeline de récupération une étape MMR (Maximal Marginal Relevance) qui équilibre pertinence et redondance, pour que les premiers résultats couvrent différents angles au lieu de reformuler le meilleur match
- Configurez MMR par Path dans osStudio : réglez le compromis lambda entre pertinence et diversité, la taille du pool de candidats et le nombre de chunks finaux qui atteignent le prompt
- S'enchaîne après les étapes de récupération, de filtre et de reranking, si bien que MMR diversifie un ensemble déjà classé plutôt que des résultats bruts d'embeddings
- S'exécute sur les résultats de la récupération hybride embeddings + BM25, avec les embeddings Voyage disponibles via un proxy managé ou vos propres clés en BYOK
- Chaque configuration MMR est une config osStudio versionnée et validée par JSON Schema, avec rollback, de sorte que différentes surfaces de chat diversifient différemment sans modification du code source
Cas d’usage
- Ingénieur support : une question de dépannage large renvoie cinq chunks quasi identiques ; MMR remplit les emplacements avec des causes distinctes pour que la réponse couvre plus d'un mode de défaillance
- Chercheur : lors de l'interrogation d'un vaste corpus de documents où les premiers résultats d'embeddings se regroupent sur une seule section ; MMR fait remonter des passages de différentes parties du corpus pour une synthèse plus complète
- Constructeur de pipeline osStudio : ajuste le lambda MMR sur un Path de chat de code pour une pertinence stricte tout en laissant un Path de découverte plus diversifié, le tout en configuration versionnée avec rollback
Questions fréquentes
Qu'est-ce que Maximal Marginal Relevance (MMR) et pourquoi l'ajouter au RAG ?
MMR est une méthode de sélection qui classe les passages candidats selon leur pertinence vis-à-vis de la requête tout en pénalisant la similarité avec les passages déjà choisis. Vous l'ajoutez lorsque vos premiers résultats de récupération tendent à être quasi identiques : sans MMR, une question large peut renvoyer cinq chunks qui disent tous la même chose, et le modèle ne voit qu'un seul angle. MMR garde le chunk le plus pertinent mais remplit les emplacements restants avec des passages distincts et complémentaires.
Comment activer la diversité MMR dans osFoundry ?
MMR est une étape du pipeline RAG sur mesure que vous configurez par Path de chat dans osStudio. Vous ajoutez l'étape MMR après vos étapes de récupération, de filtre et de reranking facultatif, puis vous réglez son lambda (le compromis pertinence-diversité), le pool de candidats dans lequel elle puise et le nombre de chunks finaux. La config est validée par JSON Schema et versionnée : vous pouvez donc l'ajuster, la tester sur un Path et l'annuler si besoin.
En quoi MMR diffère-t-il d'un reranker ?
Un reranker renote les candidats uniquement selon leur adéquation à la requête, améliorant la précision du top-k. MMR optimise un objectif différent : il maximise la pertinence tout en minimisant la redondance au sein de l'ensemble sélectionné. Ils sont complémentaires : dans osFoundry, vous rerankez généralement d'abord pour obtenir les candidats les mieux appariés, puis vous appliquez MMR afin que les chunks retenus couvrent différents aspects au lieu de répéter l'unique meilleur match.