Der RAG-Prototyp eines Entwicklers verweigerte die Antwort auf jede Abfrage mit einer Cosinus-Ähnlichkeit unter 0,50. Er funktionierte tadellos – bis das Embedding-Modell ausgetauscht wurde. Die Schutzmaßnahme ließ dann lautlos falsche Antworten durchrutschen. Der Vorfall beweist, dass ein fest codierter Ähnlichkeitsschwellenwert über verschiedene Modelle hinweg kollabieren kann – ein Risiko, das jedes System bedroht, das sich bei Sicherheitsprüfungen auf Embedding-Ähnlichkeiten verlässt.

Warum der Schwellenwert entscheidend war

RAG-Pipelines (Retrieval-augmented generation) verwenden oft eine Ähnlichkeitsprüfung (Similarity Guard): Wenn die Cosinus-Ähnlichkeit zwischen einer Abfrage und dem am nächsten liegenden Dokument unter einen vordefinierten Wert fällt, bricht das System die Antwort ab. Die Prüfung verhindert, dass das Modell halluziniert, wenn der abgerufene Kontext schwach ist. Im ursprünglichen Setup hielt ein Schwellenwert von 0,50 das System ehrlich – nicht beantwortbare Abfragen lagen unter der Linie, beantwortbare darüber.

Als das Embedding-Backend geändert wurde, trennte derselbe Cut-off von 0,50 die beiden Gruppen nicht mehr. Die Pipeline begann, selbstbewusste, aber falsche Antworten zurückzugeben, ohne dass es zu einem Absturz oder einer expliziten Fehlermeldung kam. Das Versagen entging den Standard-Ranking-Metriken und wurde erst bemerkt, als ein Mensch die Abweichung feststellte.

Geometrie ist nicht universell

Jedes Embedding-Modell bildet Sprache in einen hochdimensionalen Raum mit einer eigenen Geometrie ab. Cosinus-Ähnlichkeitswerte bedeuten daher von einem Modell zum nächsten etwas anderes. Ein Wert von 0,50 kann bei einem Modell an der Grenze einer klaren Lücke liegen und bei einem anderen tief innerhalb der Überschneidung.

  • Voyage-3 – die 0,50-Linie liegt zwischen niedrig bewerteten, nicht beantwortbaren Abfragen und hoch bewerteten, beantwortbaren Abfragen. Die Prüfung funktioniert wie beabsichtigt.
  • BGE-Small – viele nicht beantwortbare Abfragen erzielen Werte über 0,50, sodass die Prüfung nie ausgelöst wird. Eine Erhöhung des Cut-offs auf 0,70 stellt die Sicherheitsmarge wieder her.
  • Hashing-64 – die Werte für beantwortbare und nicht beantwortbare Abfragen vermischen sich so stark, dass kein einzelner Schwellenwert sie trennen kann; das Modell ist zu schwach, um überhaupt eine Ähnlichkeitsprüfung zu unterstützen.

Diese Fälle illustrieren eine grundlegende Wahrheit: Ein Schwellenwert gehört zu einem spezifischen Modell-Daten-Paar und ist keine universelle Regel.

Die versteckten Kosten einer Konstante

Ähnlichkeitsschwellenwerte erscheinen in vielen nachgelagerten Aufgaben:

  • semantisches Caching (semantic caching)
  • Duplikaterkennung (duplicate detection)
  • Prüfung der Dokumentenrelevanz (document relevance checks)
  • Entity Matching

Die Verwendung eines konstanten Wertes setzt voraus, dass alle Embedding-Modelle dieselbe Score-Verteilung teilen – eine gefährliche Annahme. Wenn diese Annahme scheitert, erzeugen Systeme lautlos selbstbewusst falsche Ausgaben, was das Vertrauen der Nutzer untergräbt und nachgelagerte Entscheidungen mit fehlerhaften Daten füttert.

Kalibrierung modellspezifischer Schutzmaßnahmen

Die Lösung ist einfach: Veröffentlichen Sie niemals eine fest codierte Konstante. Behandeln Sie den Schwellenwert als Hyperparameter, der für jedes neue Embedding-Modell abgestimmt werden muss.

  1. Erstellen Sie einen bescheidenen, annotierten Validierungssatz, der sowohl beantwortbare als auch nicht beantwortbare Abfragen abdeckt.
  2. Berechnen Sie die Cosinus-Ähnlichkeiten für jedes Abfrage-Dokument-Paar mit dem Zielmodell.
  3. Erstellen Sie ein Diagramm der beiden Verteilungen oder berechnen Sie die False-Confident-Rate – den Anteil der nicht beantwortbaren Abfragen, die den potenziellen Schwellenwert überschreiten.
  4. Wählen Sie den kleinsten Ähnlichkeitswert, der die False-Confident-Rate unter einem akzeptablen Risikoniveau hält.

Da das Ziel darin besteht, übermäßiges Selbstvertrauen zu verhindern, sind traditionelle Ranking-Metriken wie der Mean Reciprocal Rank (MRR) unzureichend. Die False-Confident-Rate misst direkt den Fehlermodus der Schutzmaßnahme.

Gegenargument: „Einige Modelle funktionieren sofort“

Es stimmt, dass bestimmte gut funktionierende Modelle, wie Voyage-3 im Beispiel, zufällig mit dem 0,50-Schwellenwert übereinstimmen. Das garantiert keine zukünftige Stabilität. Modell-Updates, Fine-Tuning oder sogar Verschiebungen im zugrunde liegenden Korpus können die Ähnlichkeitsverteilung verändern und die Schutzmaßnahme erneut aushebeln. Sich auf eine einzige glückliche Übereinstimmung zu verlassen, lädt zu Nachlässigkeit ein.

Worauf man als Nächstes achten sollte

-

-

-

Fazit

Ein Ähnlichkeitsschwellenwert ist kein universeller Sicherheitsschalter; er ist eine modellspezifische Schutzmaßnahme, die jedes Mal kalibriert werden muss, wenn Sie das Embedding-Backend oder die Daten, die es verarbeitet, ändern. Wer dies ignoriert, lässt RAG-Systeme in eine stille Halluzination abgleiten, was den eigentlichen Zweck der Schutzmaßnahme untergräbt. Der einzige zuverlässige Weg nach vorne ist eine systematische Kalibrierung pro Modell und eine kontinuierliche Überwachung der False-Confident-Rate.