ISMS Copilot
Engineering

Warum wir Compliance-Fakten nicht durch Ähnlichkeitsdeduplizierung zusammenführen

In unserer Memory-Deduplizierungsbewertung lagen Widersprüche im Durchschnitt bei einem Kosinuswert von 0,938 zu ihrem nächstgelegenen gespeicherten Fakt, während echte Duplikate bei 0,940 lagen. Kein einzelner Schwellenwert trennte die Paare, die nicht zusammengeführt werden dürfen, von denen, die es sollten. Daher trifft die Kosinus-Ähnlichkeit in unserer Pipeline niemals die Merge-Entscheidung.

von ISMS Copilot··9 min read
Warum wir Compliance-Fakten nicht durch Ähnlichkeitsdeduplizierung zusammenführen

Eine allgemeine Ähnlichkeitsmetrik beantwortet eine Frage gut: Handelt es sich bei diesen beiden Aussagen um dieselbe Sache? Bei dem Modell, das wir gemessen haben, beantwortete sie jedoch nicht die Frage, die eine Compliance-Fakten-Memory tatsächlich beantworten muss: Stimmen diese beiden Aussagen überein? Wir haben die Lücke in unseren eigenen Daten gemessen – und sie ist kein Wert, den man durch Feinabstimmung ausgleichen könnte.

In unserer Memory-Deduplizierungsbewertung lagen echte Duplikate im Durchschnitt bei einem Kosinuswert von 0,940 zu ihrem nächstgelegenen gespeicherten Fakt, während direkte Widersprüche bei 0,938 lagen. Kein einzelner globaler Schwellenwert in diesen Daten trennte die Umformulierungen, die wir unterdrücken wollten, von den Widersprüchen, die wir nicht zusammenführen durften. Wir nennen dies die „Aboutness-Falle“ – und genau deshalb trifft in unserer Pipeline die Kosinus-Ähnlichkeit niemals die Merge-Entscheidung.

Der Fehler ist leise und einseitig: Eine verpasste Deduplizierung hinterlässt eine redundante Zeile – ein kosmetisches Problem. Eine falsche Zusammenführung unterdrückt jedoch einen von zwei Fakten, die nicht übereinstimmen. Wenn der unterdrückte Fakt beispielsweise lautet „MFA ist für alle Nutzer nicht erzwungen“, hält ein assistierendes System für Compliance-Prüfungen nun das Gegenteil der Wahrheit fest. Wir behandeln diese beiden Fehlerkategorien als grundverschieden – und aus dieser Asymmetrie ergibt sich das gesamte Design.

Die Messung

Die Bewertung führt den echten Backend-Entscheidungspfad aus (denselben evaluateCandidate-Code, den auch die Pipeline verwendet) über einen adversarischen, synthetischen und PII-freien Datensatz mit GRC-Aussagenpaaren durch. Jedes Paar ist mit seiner Relation beschriftet:

  • eine umformulierte Duplikate, die unterdrückt werden soll,
  • oder eine von drei Kategorien, die nicht zusammengeführt werden dürfen:
    • ein unterschiedlicher Fakt mit einem einzigen abweichenden Token,
    • ein direkter Widerspruch,
    • oder eine Gültigkeitsbereichseinschränkung (Scope Refinement).

Protokollierter Durchlauf: 2026-06-25, mistral-embed (das Modell hinter dem v23.12-Alias) für die Vektoren und ein kleines Mistral-Judge-Modell (mistral-small-2603, Temperatur 0) für die Entscheidung. Insgesamt 261 Paare, 522 Modellaufrufe, Kosten: ca. 0,036 $.

Besonders interessant ist die Embedding-Studie. Hier die durchschnittlichen Kosinuswerte der Kandidaten zu ihrem nächstgelegenen gespeicherten Fakt, aufgeschlüsselt nach Relation (mistral-embed v23.12, Durchlauf 2026-06-25):

RelationDurchschnittlicher Kosinusn
Duplikat0,94010
Widerspruch0,9387
Nicht-Duplikat (ein Token)0,902239
Gültigkeitsbereichseinschränkung0,8475

Betrachten wir die ersten beiden Zeilen: Der durchschnittliche Widerspruch liegt nur 0,002 Punkte unter der durchschnittlichen Umformulierung desselben Faktums. Das einzelne Wort, das den Wahrheitswert umkehrt („nicht“), bewegt den Vektor kaum, weil beide Sätze in diesem Modell überwiegend von der MFA-Durchsetzung handeln – und die Nähe folgt hier eher dem gemeinsamen Thema als der Negation.

Noch näher beieinander liegen die „Nicht-Duplikate“ mit einem einzigen abweichenden Token. Der Satz „Wir haben einen SOC-2-Type-1-Bericht abgeschlossen“ versus „Type 2“ ist kein Haarspalterei: Ein Type-1-Bericht bescheinigt die Eignung des Kontroll-Designs zu einem bestimmten Stichtag, während ein Type-2-Bericht zusätzlich die Wirksamkeit der Kontrollen über einen bestimmten Zeitraum hinweg adressiert (AICPA, SOC-2-Berichtsleitfaden).

Wenn diese beiden Aussagen zusammengeführt werden, teilt ein assistierendes System einem potenziellen Kunden mit, dass Belege vorliegen, die es nicht gibt. In einem End-to-End-Test mit den echten Modulen wurden die Embeddings für „SOC 2 Type 1“ und „Type 2“ mit einem Kosinuswert von 0,961 gemessen – höher als der Durchschnitt echter Duplikate in der Tabelle. Dieses einzelne Beispiel ist entscheidend: ein Paar, das niemals zusammengeführt werden darf, erzielt einen höheren Wert als der Durchschnitt der Paare, die es sollten. Die Nicht-Duplikat-Klasse insgesamt lag im Schnitt bei 0,902.

Warum ein einzelner Schwellenwert sie nicht trennt

Der erste Instinkt, wenn man sieht, dass ein Duplikat einen hohen Ähnlichkeitswert hat, ist: „Setzen wir einen Merge-Schwellenwert knapp darunter.“ Unsere Daten sprechen aus zwei Gründen dagegen:

  1. Die Klassenmittelwerte überschneiden sich: 0,940 für Duplikate und 0,938 für Widersprüche sind für Schwellenwertzwecke dieselbe Zahl.
  2. Wir haben ein konkretes Gegenbeispiel über diesem Wert: das Type-1-vs-Type-2-Paar mit 0,961 – ein Paar, das nicht zusammengeführt werden darf und trotzdem höher liegt als der Durchschnitt echter Duplikate.

Ein globaler Schnitt, der niedrig genug ist, um alltägliche Umformulierungen zu unterdrücken, würde in diesen Daten auch Fakten unterdrücken, die wir gemessen haben und die getrennt bleiben müssen. Wir behaupten nicht, bewiesen zu haben, dass keine trennende Grenze für beliebige Datensätze oder Modelle existieren kann. Wir berichten lediglich, dass in diesem adversarischen GRC-Datensatz mit diesem Embedding-Modell kein einzelner globaler Kosinus-Schwellenwert die „sichere Zusammenführung“ von den „fatalen Zusammenführungen“ trennte.

Embeddings erfüllen in unserer Pipeline daher nur eine Aufgabe: Abruf. Der Kosinus-Floor liegt bewusst niedrig bei 0,55 und dient ausschließlich dazu, zu bestimmen, welcher gespeicherte Fakt mit dem Kandidaten verglichen werden soll. Er entscheidet nicht, ob zusammengeführt wird. Sobald der nächste Nachbar abgerufen ist, trifft eine andere Komponente die Entscheidung – eine, die sich die Token ansieht, die von der Kosinus-Metrik untergewichtet werden.

Die Architektur, die Widersprüche trennt

Zwei Ebenen, wobei die deterministische Ebene maßgeblich ist.

1. Deterministische Prüfung geschützter Token

Wir vergleichen den Kandidaten mit seinem abgerufenen Nachbarn auf Token, die compliance-relevante Bedeutung tragen:

  • Negationen („nicht“, „nicht mehr“),
  • Quantoren und Gültigkeitsbereiche („alle“, „nur“, „Administratoren“),
  • Jurisdiktionen und Regionen,
  • Framework-Versionen,
  • SOC-2-Typen,
  • Zahlen und Einheiten.

Jede einseitige Abweichung in einer geschützten Klasse blockiert die Zusammenführung – und überschreibt das Urteil des Modells, unabhängig von dessen Ergebnis. „MFA ist erzwungen“ versus „MFA ist nicht erzwungen“ wird durch die Negationsregel blockiert, egal wie ähnlich die beiden Sätze aussehen.

2. Konservatives Judge-Modell

Das Modell muss eine Konfidenz von mindestens 0,8 erreichen, um einen Kandidaten als Duplikat zu unterdrücken. Liegt die Konfidenz darunter, werden beide Zeilen beibehalten. Das System ist zurückhaltend, weil die beiden Fehlerrichtungen nicht symmetrisch sind:

  • Ein beibehaltenes Duplikat ist kosmetisch,
  • eine falsche Zusammenführung ist Korruption.

Die Hürde, die das System nehmen muss: Null falsche Zusammenführungen in den 251 Paaren, die nicht zusammengeführt werden dürfen. Das System hat diese Hürde genommen – null beobachtete falsche Zusammenführungen. Als Faustregel liegt die Fehlerquote bei etwa 3/251 (≈ 1,2%), aber bei einem festen, kuratierten Datensatz ist dies ein heuristischer Wert – keine echte Konfidenzgrenze und keine Produktionsgarantie.

Die Eigenschaft, auf die wir uns tatsächlich verlassen, ist enger und robuster: Die deterministische Prüfung allein – ohne Modell im Loop – blockierte alle 251 Paare. Die Schwelle wird also von Code gehalten, den man lesen kann, nicht von einem Modell, dem man vertrauen muss.

Was das Judge-Modell täuschte

Der ehrliche Teil: In einer begleitenden Bereinigungsbewertung zwei Tage später (2026-06-27) wurde eine falsche Zusammenführung entdeckt, die eine frühere Version der Prüfung übersehen hatte:

  • „SSO ist für Enterprise-Kunden verfügbar“ versus
  • „SSO ist für alle Kunden verfügbar.“

Das Modell urteilte, die allgemeinere Aussage sei eine harmlose Verfeinerung der spezifischeren – und führte sie zusammen. Es handelt sich um die „Aboutness-Falle“ auf einer höheren Ebene: Die beiden Sätze handeln fast ausschließlich von der SSO-Verfügbarkeit, und das Judge-Modell – wie das Embedding – untergewichtet das Quantifikationswort, das ändert, für wen die Aussage gilt.

Die Lösung bestand darin,

  1. einseitige Änderungen in einer Gültigkeitsbereichs-Klasse (Quantoren, Subjekte, Negation, Modalität) in die deterministische Prüfung zu verlagern – statt sie dem Judge zu überlassen,
  2. eine explizite „Applicability-Scope“-Regel im Judge-Prompt als zusätzliche Absicherung hinzuzufügen.

Nach der Korrektur zeigte die Bewertung null falsche Zusammenführungen, 18 von 18 unterschiedliche Paare blieben getrennt und 8 von 8 echte Duplikate wurden erkannt.

Das Muster wiederholt sich über die Ebenen hinweg:

  • Das Embedding untergewichtet strukturell Negation und Gültigkeitsbereich in diesem Modell.
  • Das Judge-Modell untergewichtet sie weich.
  • Die Ebene, die sie in unseren Durchläufen zuverlässig erfasste, ist diejenige, die die genauen Token benennt, die ein Compliance-Faktum umkehren – und diese Ebene ist deterministischer Code, kein weiteres Modell, das „vorsichtig sein soll“.

Grenzen

Dies ist ein Entscheidungsqualitäts-Gate über beschriftete Paare – ein Kandidat gegen seinen passenden Nachbarn – kein Lasttest für große Speicherabfragen. Die Klassen „Widerspruch“ und „Gültigkeitsbereichseinschränkung“ sind klein (7 bzw. 5 Paare), sodass ihre Mittelwerte indikativ, aber keine engen Schätzungen sind.

Die Kosinuswerte sind spezifisch für mistral-embed v23.12 auf diesen GRC-Sätzen. Ein anderes Embedding-Modell würde sie verschieben, und die von uns beobachtete Negations-Unempfindlichkeit ist spezifisch für das gemessene Modell – kein Gesetz der Ähnlichkeits-Embeddings. Kontrastiv trainierte Modelle können so eingestellt werden, dass sie Widersprüche stärker trennen, indem sie diese als harte Negativbeispiele nutzen (SimCSE, EMNLP 2021). Die richtige Schlussfolgerung lautet daher: „Miss dein eigenes Modell“, nicht „Embeddings können das nie leisten“.

Die Duplikat-Erkennungsrate in der Deduplizierungsbewertung lag bei 0,5 – fünf von zehn echten Duplikaten wurden unterdrückt. Das ist der Preis, den wir gewählt haben: Das Judge-Modell behält beide Zeilen bei, solange es unsicher ist. Die Erkennungsrate ist der Hebel, den wir anpassen, während die beobachtete Anzahl falscher Zusammenführungen bei null bleibt. Wir ziehen es vor, ein paar redundante wahre Fakten mitzuführen, als jemals zwei widersprüchliche zusammenzuführen.

Die Aboutness-Falle – und eine Checkliste

Die zentrale Erkenntnis aus diesem Experiment: Bei dem von uns gemessenen Modell bedeutet ein hoher Ähnlichkeitswert, dass zwei Aussagen über dasselbe Thema handeln – nicht, dass sie übereinstimmen. Und Deduplizierung erfordert Übereinstimmung. Wenn eine solche Memory dokumentierte Informationen enthält, auf die sich ein ISMS stützt, verlangt ISO/IEC 27001:2022, Klausel 7.5.3 deren Schutz vor Integritätsverlust (ISO/IEC 27001:2022, Klausel 7.5.3, Ausgabe 2022-10). Wenn eine stille Zusammenführung einen erforderlichen Eintrag ungenau macht, ist das genau der Verlust an Integrität, den die Norm beschreibt.

Wenn du eine Memory oder Wissensschicht mit semantischer Deduplizierung aufbaust, führe folgende Schritte durch:

  • Miss die Verteilung – gehe nicht von Annahmen aus. Embede beschriftete Duplikat-, Widerspruchs- und „fast unterschiedliche“ Paare aus deinem eigenen Anwendungsbereich mit deinem eigenen Modell und betrachte den Kosinus nach Relation. Wenn die Widerspruchswerte mit den Duplikatwerten überlappen, wird kein Schwellenwert über diesem Score sie trennen.
  • Nutze Embeddings nur für den Abruf – nicht für die Merge-Entscheidung. Ein niedriger Kosinus-Floor, um einen Vergleichsnachbarn auszuwählen, ist in Ordnung. Dieselben Scores zur Entscheidung über eine Zusammenführung zu nutzen, ist der Weg, wie ein Widerspruch stillschweigend entfernt wird.
  • Platziere eine deterministische Prüfung vor der Zusammenführung. Liste die Token auf, die in deinem Bereich die Bedeutung umkehren (Negation, Quantoren, Gültigkeitsbereich, Versionen, Jurisdiktionen, Einheiten) und lasse eine einseitige Änderung in einer dieser Klassen die Modellentscheidung überschreiben.
  • Mache das Judge-Modell konservativ und asymmetrisch. Weise es an, beide Zeilen beizubehalten. Entscheide, welcher Fehler kosmetisch ist und welcher Korruption – und lasse das Modell niemals den zweiten Fehler riskieren, um den ersten zu vermeiden.
  • Halte die Anzahl der fatalen Fehler auf null und optimiere die Erkennungsrate separat. Halte falsche Zusammenführungen bei null als Gate; verbessere die Duplikat-Erkennungsrate unter Beibehaltung dieses Gates, ohne den Floor zu verschieben.
  • Füge die „Beinahe-Fehler“ in deinen Datensatz ein. Das Paar, das durch eine Gültigkeitsbereichserweiterung wie eine harmlose Verfeinerung wirkt, ist dasjenige, das zusammengeführt wird. Ausgeschriebene Zahlen, kleingeschriebene Akronyme und Quantorenwechsel sind die Stellen, an denen ein Judge-Modell leise versagt.

Alle oben genannten Werte stammen aus unseren eigenen Messungen an unseren eigenen synthetischen GRC-Fixtures mit mistral-embed v23.12 und mistral-small-2603 (Temperatur 0) vom 25.06.2026 und 27.06.2026. Der Datensatz enthält keine Kundendaten.

Verwandte Beiträge