osFoundry / Platform
Diversidad MMR
Maximal Marginal Relevance elige resultados que cubren distintos ángulos, no solo el mejor match.
Qué es
La diversidad MMR es una etapa de recuperación de osFoundry que aplica Maximal Marginal Relevance cuando se consulta tu base de conocimiento. La ordenación por relevancia pura tiene un fallo conocido: los primeros resultados suelen ser casi duplicados entre sí, porque todos coinciden con la consulta de la misma manera. Si cinco fragmentos repiten el mismo párrafo, cuatro malgastan espacio de la ventana de contexto y el modelo nunca llega a ver el segundo ni el tercer ángulo de la pregunta. MMR corrige esto puntuando cada candidato tanto por su relevancia frente a la consulta como por su disimilitud respecto a los fragmentos ya seleccionados, y eligiendo así resultados que son relevantes *y* distintos entre sí.
Dentro de osFoundry, MMR es una de las etapas del pipeline RAG personalizado que construyes por cada Path de chat en osStudio. Una consulta pasa primero por recuperación híbrida (búsqueda por embeddings más búsqueda de palabras clave BM25); a continuación puedes añadir etapas de filtro y reranking, y colocar MMR después de ellas para que diversifique un conjunto de candidatos ya de alta calidad. La etapa expone los controles habituales de MMR: un parámetro lambda que se desplaza entre la relevancia pura y la diversidad pura, el tamaño del pool de candidatos del que selecciona y cuántos fragmentos emite hacia el prompt. Como cada etapa es una configuración versionada y validada por JSON Schema, un Path de chat de código y un Path de éxito de cliente pueden diversificar de forma distinta, y puedes revertir un cambio sin tocar el código fuente.
Esto importa sobre todo en preguntas amplias o ambiguas y en corpus con vocabulario solapado, donde los primeros aciertos por embeddings se agrupan estrechamente. MMR cede algo de relevancia bruta en el top-1 a cambio de cobertura, lo que normalmente produce respuestas mejor fundamentadas, porque el modelo ve el rango de lo que la base de conocimiento contiene realmente. Se mantiene coherente con la postura BYOK y local-first de osFoundry: la recuperación y la diversificación se ejecutan en tu workspace, los embeddings pasan por un proxy gestionado de Voyage o por tu propia clave, y ninguna tarifa por asiento condiciona el pipeline.
Capacidades principales
- Añade una etapa MMR (Maximal Marginal Relevance) a tu pipeline de recuperación que equilibra relevancia y redundancia, de modo que los primeros resultados cubran ángulos distintos en lugar de reformular el mejor match
- Configura MMR por Path en osStudio: fija el equilibrio lambda entre relevancia y diversidad, el tamaño del pool de candidatos y cuántos fragmentos finales llegan al prompt
- Se encadena tras las etapas de recuperación, filtro y reranking, de modo que MMR diversifica un conjunto ya ordenado en vez de aciertos crudos de embeddings
- Opera sobre los resultados de la recuperación híbrida (embeddings más BM25), con embeddings de Voyage disponibles mediante un proxy gestionado o tus propias claves bajo BYOK
- Cada configuración de MMR es una config de osStudio versionada y validada por JSON Schema, con rollback, de modo que distintas superficies de chat diversifican de forma diferente sin cambios en el código fuente
Casos de uso
- Ingeniero de soporte: una pregunta amplia de resolución de problemas devuelve cinco fragmentos casi idénticos; MMR llena los huecos con causas distintas para que la respuesta cubra más de un modo de fallo
- Investigador: al consultar un gran conjunto de documentos donde los primeros aciertos por embeddings se agrupan en una sección; MMR saca a la luz pasajes de partes distintas del corpus para una síntesis más completa
- Constructor de pipelines en osStudio: ajusta el lambda de MMR en un Path de chat de código para una relevancia estricta y deja un Path de descubrimiento más diverso, todo como configuración versionada con rollback
Preguntas frecuentes
¿Qué es Maximal Marginal Relevance (MMR) y por qué lo añadiría a RAG?
MMR es un método de selección que ordena los pasajes candidatos por su relevancia frente a la consulta mientras penaliza la similitud con los ya elegidos. Lo añades cuando tus primeros resultados tienden a ser casi duplicados: sin MMR, una pregunta amplia puede devolver cinco fragmentos que dicen lo mismo, y el modelo solo ve un ángulo. MMR conserva el fragmento más relevante pero llena los huecos restantes con pasajes distintos y complementarios.
¿Cómo activo la diversidad MMR en osFoundry?
MMR es una etapa del pipeline RAG personalizado que configuras por cada Path de chat en osStudio. Añades la etapa MMR después de tus etapas de recuperación, filtro y el reranking opcional, y luego fijas su lambda (el equilibrio entre relevancia y diversidad), el pool de candidatos del que extrae y el número de fragmentos finales. La config está validada por JSON Schema y versionada, así que puedes ajustarla, probarla en un Path y revertirla si hace falta.
¿En qué se diferencia MMR de un reranker?
Un reranker vuelve a puntuar los candidatos únicamente por lo bien que cada uno coincide con la consulta, mejorando la precisión del top-k. MMR optimiza un objetivo distinto: maximiza la relevancia minimizando la redundancia dentro del conjunto seleccionado. Son complementarios: en osFoundry normalmente haces primero reranking para obtener los mejores candidatos y luego aplicas MMR para asegurar que los fragmentos que pasan cubran aspectos distintos en vez de repetir el único mejor match.