osFoundry / Platform
MMR-Diversität
Maximal Marginal Relevance wählt Ergebnisse, die unterschiedliche Blickwinkel abdecken, nicht nur den Top-Treffer.
Was es ist
MMR-Diversität ist eine Retrieval-Stufe in osFoundry, die Maximal Marginal Relevance anwendet, sobald Ihre Wissensbasis abgefragt wird. Reines Relevanz-Ranking hat eine bekannte Schwäche: Die obersten Ergebnisse sind oft Beinahe-Duplikate voneinander, weil sie alle auf dieselbe Weise zur Anfrage passen. Wenn fünf Chunks denselben Absatz wiederholen, vergeuden vier davon Platz im Kontextfenster, und das Modell bekommt den zweiten oder dritten Blickwinkel auf die Frage nie zu sehen. MMR behebt das, indem es jeden Kandidaten sowohl nach seiner Relevanz zur Anfrage als auch nach seiner Unähnlichkeit zu den bereits ausgewählten Chunks bewertet und dann Ergebnisse wählt, die relevant *und* untereinander verschieden sind.
Innerhalb von osFoundry ist MMR eine Stufe der individuellen RAG-Pipeline, die Sie pro Chat-Path in osStudio aufbauen. Eine Anfrage durchläuft zunächst das hybride Retrieval (Embedding-Suche plus BM25-Keyword-Suche); danach können Sie Filter- und Rerank-Stufen ergänzen und MMR dahinter setzen, damit es einen bereits hochwertigen Kandidatensatz diversifiziert. Die Stufe bietet die üblichen MMR-Regler: einen Lambda-Parameter, der zwischen reiner Relevanz und reiner Diversität gleitet, die Größe des Kandidatenpools, aus dem sie auswählt, und wie viele Chunks sie in den Prompt gibt. Da jede Stufe eine versionierte, per JSON Schema validierte Konfiguration ist, können ein Code-Chat-Path und ein Customer-Success-Path unterschiedlich diversifizieren, und Sie können eine Änderung zurückrollen, ohne den Quellcode anzufassen.
Am meisten zählt das bei breiten oder mehrdeutigen Fragen sowie bei Korpora mit überlappendem Vokabular, wo sich die obersten Embedding-Treffer eng zusammendrängen. MMR gibt ein wenig rohe Top-1-Relevanz für Abdeckung her, was in der Regel besser fundierte Antworten liefert, weil das Modell die Bandbreite dessen sieht, was die Wissensbasis tatsächlich enthält. Es bleibt der BYOK- und Local-first-Haltung von osFoundry treu: Retrieval und Diversifizierung laufen in Ihrem Workspace, Embeddings gehen über einen verwalteten Voyage-Proxy oder Ihren eigenen Schlüssel, und keine Pro-Sitz-Gebühr riegelt die Pipeline ab.
Wichtige Funktionen
- Fügt Ihrer Retrieval-Pipeline eine MMR-Stufe (Maximal Marginal Relevance) hinzu, die Relevanz gegen Redundanz abwägt, sodass die obersten Ergebnisse verschiedene Blickwinkel abdecken, statt den Top-Treffer neu zu formulieren
- Konfigurieren Sie MMR pro Path in osStudio: legen Sie den Lambda-Abgleich zwischen Relevanz und Diversität, die Größe des Kandidatenpools und die Zahl der finalen Chunks fest, die in den Prompt gelangen
- Wird nach den Retrieve-, Filter- und Rerank-Stufen verkettet, sodass MMR einen bereits gerankten Kandidatensatz diversifiziert statt roher Embedding-Treffer
- Arbeitet auf den Ergebnissen des hybriden Retrievals aus Embeddings und BM25, wobei Voyage-Embeddings über einen verwalteten Proxy oder Ihre eigenen Schlüssel unter BYOK verfügbar sind
- Jede MMR-Konfiguration ist eine per JSON Schema validierte, versionierte osStudio-Konfiguration mit Rollback, sodass verschiedene Chat-Oberflächen ohne Quellcode-Änderungen unterschiedlich diversifizieren
Anwendungsfälle
- Support-Engineer: Eine breite Fehlerbehebungsfrage liefert fünf nahezu identische Chunks; MMR füllt die Plätze mit unterschiedlichen Ursachen, sodass die Antwort mehr als einen Fehlermodus abdeckt
- Forscher: Bei der Abfrage eines großen Dokumentensatzes ballen sich die obersten Embedding-Treffer in einem Abschnitt; MMR holt Passagen aus verschiedenen Teilen des Korpus für eine vollständigere Synthese hervor
- osStudio-Pipeline-Bauer: Stimmt das MMR-Lambda auf einem Code-Chat-Path für enge Relevanz ab und lässt einen Discovery-Path diverser, alles als versionierte Konfiguration mit Rollback
Häufig gestellte Fragen
Was ist Maximal Marginal Relevance (MMR), und warum sollte ich es RAG hinzufügen?
MMR ist ein Auswahlverfahren, das Kandidatenpassagen nach ihrer Relevanz zur Anfrage rankt und dabei die Ähnlichkeit zu bereits gewählten Passagen bestraft. Sie fügen es hinzu, wenn Ihre obersten Retrieval-Ergebnisse dazu neigen, Beinahe-Duplikate zu sein: Ohne MMR kann eine breite Frage fünf Chunks zurückgeben, die alle dasselbe sagen, und das Modell sieht nur einen Blickwinkel. MMR behält den relevantesten Chunk, füllt die übrigen Plätze aber mit eigenständigen, ergänzenden Passagen.
Wie aktiviere ich MMR-Diversität in osFoundry?
MMR ist eine Stufe der individuellen RAG-Pipeline, die Sie pro Chat-Path in osStudio konfigurieren. Sie fügen die MMR-Stufe nach Ihren Retrieve-, Filter- und optionalen Rerank-Stufen ein und legen dann ihr Lambda (den Abgleich zwischen Relevanz und Diversität), den Kandidatenpool, aus dem sie schöpft, und die Zahl der finalen Chunks fest. Die Konfiguration ist per JSON Schema validiert und versioniert, sodass Sie sie feinabstimmen, auf einem Path testen und bei Bedarf zurückrollen können.
Worin unterscheidet sich MMR von einem Reranker?
Ein Reranker bewertet Kandidaten allein danach neu, wie gut jeder zur Anfrage passt, und verbessert so die Top-k-Präzision. MMR optimiert ein anderes Ziel: Es maximiert die Relevanz und minimiert zugleich die Redundanz innerhalb des ausgewählten Satzes. Beide ergänzen sich: In osFoundry reranken Sie üblicherweise zuerst, um die passendsten Kandidaten zu erhalten, und wenden dann MMR an, damit die durchgereichten Chunks verschiedene Aspekte abdecken, statt den einen besten Treffer zu wiederholen.