Entity-Resolution-Genauigkeit nach dem Go-Live überwachen: 7 Kennzahlen für 2026

Kurzfassung: Entity-Resolution-Genauigkeit ist kein einmaliger Test zum Go-Live. Sie verschlechtert sich still, während sich Upstream-Daten verschieben: ein neues Quellformat, eine geänderte Kodierung, ein neues Feld. Sieben Kennzahlen, laufend statt einmalig geprüft, erkennen diese Drift 2026, solange sie noch günstig zu beheben ist: Match-Rate gegen eine gleitende Baseline, gemessene Precision und Recall, Confidence-Score-Verteilung, Cluster-Größe, Volumen der Prüfwarteschlange, Time-to-Match und quellspezifische Drift.

Erkennen Sie Drift, bevor sich doppelte Datensätze anhäufen. Besprechen Sie Ihren Monitoring-Plan mit unserem Team oder beobachten Sie diese Kennzahlen an Ihren eigenen Daten. Demo buchen oder Tilores Studio kostenlos testen.

Auf dieser Seite

Warum lässt die Entity-Resolution-Genauigkeit nach dem Go-Live nach?
Kennzahl 1: Match-Rate gegen eine gleitende Baseline, nicht gegen eine feste Zahl
Kennzahl 2: Gemessene Precision und Recall gegen einen gelabelten Holdout
Kennzahl 3: Confidence-Score-Verteilung nahe am Schwellenwert
Kennzahl 4: Cluster-Größenverteilung über die Zeit
Kennzahl 5: Volumen und Ursachencodes der manuellen Prüfwarteschlange
Kennzahl 6: Time-to-Match für neue Datensätze
Kennzahl 7: Quellspezifische Drift, nicht nur aggregierte Drift
Was tun, wenn ein Alarm auslöst

Warum lässt die Entity-Resolution-Genauigkeit nach dem Go-Live nach?

IBMs Beschreibung des zugrunde liegenden Phänomens trifft direkt auf Matching-Systeme zu, auch wenn sie allgemein über Machine-Learning-Modelle geschrieben ist: Model Drift ist „the degradation of machine learning model performance due to changes in data or in the relationships between input and output variables”, und Modelle, „built with historical data can quickly become stagnant”, sobald neue Varianten, Muster und Trends nicht mehr zu dem passen, worauf das System ursprünglich abgestimmt wurde.

Ein Entity-Resolution-System ist davon nicht ausgenommen, nur weil ein Teil seiner Logik regelbasiert statt rein statistisch ist. Ein neues Upstream-System beginnt, ein Namensfeld in einem anderen Format zu senden. Ein Datenanbieter ändert eine Kodierung. Ein Adressformat aus einem neuen Land taucht zum ersten Mal in der Pipeline auf. Nichts davon erscheint als Fehlermeldung. Es zeigt sich allmählich als sinkende Match-Rate oder als wachsende Zahl von Beinahe-Duplikat-Clustern, die früher sauber aufgelöst wurden. Evidently AI bringt die allgemeine Version davon präzise auf den Punkt: „data drift is a change in the statistical properties and characteristics of the input data”, und diese Verschiebung „can lead to a decline in the model’s performance”, wenn niemand darauf achtet.

Ein einmaliger Genauigkeitstest beim Start beantwortet, ob das System am ersten Tag funktioniert hat. Er sagt nichts über Tag zweihundert. Sieben Kennzahlen, laufend statt einmalig geprüft, schließen diese Lücke.

Kennzahl 1: Match-Rate gegen eine gleitende Baseline, nicht gegen eine feste Zahl

Die Match-Rate, also der Anteil eingehender Datensätze, der sauber einer bestehenden oder neuen Entität zugeordnet wird, ist das sichtbarste Signal, allerdings nur, wenn sie gegen ihre eigene jüngere Historie verglichen wird, statt gegen eine beim Start einmalig festgelegte Zahl. Ein saisonales Geschäft, ein neues Kundensegment oder eine neue Quelle können die „normale” Match-Rate aus legitimen Gründen verschieben, die nichts mit einem Qualitätsproblem zu tun haben. Evidently AIs Anleitung zum statistischen Monitoring weist auf die richtige Form der Prüfung hin: den Vergleich, „if the current mean value of a numerical variable is within two standard deviations from the reference value”, also ein gleitender Vergleich, keine starre Bestehen-oder-Durchfallen-Linie.

Drift beginnt in einer Quelle, erzeugt unterschiedliche Matching-Symptome und wird handlungsrelevant, sobald die quellspezifische Ursache isoliert ist.

Kennzahl 2: Gemessene Precision und Recall gegen einen gelabelten Holdout

Die Match-Rate allein kann ein gesundes System nicht von einem unterscheiden, das still über- oder untermatched. Precision und Recall, gemessen an einer kleinen, regelmäßig aufgefrischten gelabelten Holdout-Stichprobe, decken auf, was eine aggregierte Rate verbirgt: Precision sinkt, wenn das System Datensätze verknüpft, die tatsächlich nicht dieselbe Entität sind, und Recall sinkt, wenn es Datensätze nicht verknüpft, die es sein sollten. William Winklers grundlegende Record-Linkage-Forschung für das US Census Bureau untermauert das mit Jahrzehnten Praxis: gut abgestimmte, computergestützte Verfahren senkten den Aufwand einer Duplikatauflösung beim Census, der sonst tausende Sachbearbeiter gebraucht hätte, auf einen Bruchteil davon, genau weil die zugrunde liegende Match-Logik gemessen und gegen bekannte Ergebnisse abgestimmt wurde, statt auf unbestimmte Zeit als korrekt vorausgesetzt zu werden.

Ein Holdout muss nicht groß sein, um nützlich zu sein. Er muss oft genug aufgefrischt werden, damit er die Daten widerspiegelt, die das System gerade tatsächlich sieht, nicht die Daten, die es sah, als der Holdout erstellt wurde.

Kennzahl 3: Confidence-Score-Verteilung nahe am Schwellenwert

Jede Match-Entscheidung der Tilores API trägt einen Entity Score und einen Hit Score, beide Fließkommazahlen zwischen null und eins, die Match-Qualität und die Nähe eines Ergebnisses zu den auslösenden Suchparametern widerspiegeln. Die aggregierte Verteilung dieser Werte über die Zeit zu verfolgen, deckt ein spezifisches Fehlerbild auf: ein wachsender Anteil an Matches häuft sich knapp über oder knapp unter dem Confidence-Schwellenwert an, statt eindeutig auf einer Seite davon zu liegen. Diese Verschiebung bedeutet meist, dass sich die zugrunde liegenden Daten verändert haben, noch bevor die Match-Rate selbst sichtbar fällt, und ist die früheste verfügbare Warnung, weil sie sich innerhalb einzelner Entscheidungen zeigt, nicht erst in einem aggregierten Ergebnis.

Kennzahl 4: Cluster-Größenverteilung über die Zeit

Ein gesunder Identity Graph hat eine stabile, erklärbare Verteilung der Cluster-Größen für einen gegebenen Entitätstyp: Die meisten Kunden lösen sich zu einem einzigen Datensatz auf, eine kleinere Zahl löst sich über Systeme hinweg zu zwei oder drei auf, und sehr große Cluster sind selten und meist erklärbar. Eine Verschiebung dieser Verteilung, ungewöhnlich groß werdende Cluster oder ein Sprung bei Einzeldatensatz-Clustern, die früher zusammengeführt wurden, ist ein strukturelles Signal dafür, dass sich etwas daran verändert hat, wie Datensätze eintreffen oder verglichen werden, und lohnt eine eigene Untersuchung, selbst wenn sich die Match-Rate noch nicht bewegt hat.

Kennzahl 5: Volumen und Ursachencodes der manuellen Prüfwarteschlange

Jedes System, das unsichere Matches an einen menschlichen Prüfer weiterleitet, erzeugt eine Warteschlange, und diese Warteschlange ist ein direktes Messinstrument, sofern der Grund, warum jeder einzelne Fall dort landete, mit erfasst wird. Eine wachsende Warteschlange ohne Veränderung bei den Ursachencodes bedeutet meist, dass echte Mehrdeutigkeit weiter oben zugenommen hat. Eine wachsende Warteschlange, die sich auf einen Ursachencode konzentriert, etwa ein bestimmtes Feld, das nicht normalisiert werden kann, deutet auf eine behebbare, lokal begrenzte Ursache statt auf ein allgemeines Genauigkeitsproblem hin, und lohnt eine Triage, bevor sie so groß wird, dass sie ein Prüfteam überfordert.

Kennzahl 6: Time-to-Match für neue Datensätze

Latenz ist ein Genauigkeitssignal, nicht nur ein Performance-Signal. Tilores löst neue Datensätze gegen bestehende Cluster auf dem verwalteten AWS-Pfad in unter 150 Millisekunden auf, selbst gehostet neben der Workload in rund 1 Millisekunde. Ein anhaltender Anstieg dieser Zahl, selbst ohne Änderung an der Match-Logik, bedeutet meist, dass sich die eingehenden Daten selbst in ihrer Form verändert haben, größere Datensätze, mehr Quellfelder oder ein ungewöhnlich großer Batch, was sich zu verstehen lohnt, bevor es auch die Match-Qualität beeinträchtigt.

Kennzahl 7: Quellspezifische Drift, nicht nur aggregierte Drift

Eine aggregierte Kennzahl kann stabil bleiben, während sich eine bestimmte Quelle deutlich verschlechtert, wenn diese Quelle nur einen kleinen Anteil am Gesamtvolumen hat. IBMs Aufschlüsselung der Drift-Arten ist hier hilfreich: Concept Drift, bei der „there is a divergence between the input variables and the target variable”, kann saisonal, plötzlich oder allmählich auftreten, und eine Sicht auf einzelne Quellen ist oft der einzige Weg, eine allmähliche Verschiebung bei einer Quelle zu erkennen, bevor sie groß genug wird, um die aggregierte Zahl zu bewegen. Jede der sechs oben genannten Kennzahlen nach Quellsystem aufzuschlüsseln, nicht nur nach Gesamtvolumen, ist das, was aus einer unternehmensweiten Untersuchung eine Untersuchung von fünfzehn Minuten macht.

Kennzahl	Was sie erkennt	Typische Prüffrequenz
1. Match-Rate vs. gleitende Baseline	Eine allgemeine Verschiebung darin, wie gut eingehende Datensätze aufgelöst werden	Laufend oder täglich
2. Gemessene Precision und Recall	Stilles Über- oder Untermatching, das die Match-Rate allein verbirgt	Wöchentlich bis monatlich
3. Confidence-Score-Verteilung	Datendrift, oft bevor sich die Match-Rate selbst bewegt	Laufend oder täglich
4. Cluster-Größenverteilung	Strukturelle Veränderungen darin, wie Datensätze eintreffen oder verglichen werden	Täglich bis wöchentlich
5. Volumen und Ursachencodes der Prüfwarteschlange	Lokal begrenzte, behebbare Ursachen gegenüber echter Mehrdeutigkeit	Laufend
6. Time-to-Match	Veränderungen in Form oder Volumen der eingehenden Daten	Laufend
7. Quellspezifische Drift	Eine einzelne, sich verschlechternde Quelle, versteckt in einer stabilen aggregierten Zahl	Täglich bis wöchentlich, pro Quelle

Was tun, wenn ein Alarm auslöst

Ein Alarm bei einer der sieben oben genannten Kennzahlen ist der Ausgangspunkt einer Untersuchung, kein Urteil. Der erste Schritt ist immer derselbe: prüfen, ob die Verschiebung quellspezifisch oder systemweit ist, anhand der Aufschlüsselung aus Kennzahl 7. Eine quellspezifische Verschiebung lässt sich meist auf eine Schema- oder Formatänderung bei dieser Quelle zurückführen, behebbar auf der Normalisierungsebene, ohne die Matching-Logik überhaupt anzufassen. Eine systemweite Verschiebung ist seltener und verdient schnellere Eskalation, da sie bedeuten kann, dass sich die zugrunde liegende Datenverteilung für jede Quelle gleichzeitig tatsächlich verschoben hat, was das schwierigere Problem zur Diagnose ist und dasjenige, dessen frühe Erkennung sich am meisten lohnt.

Keine dieser sieben Kennzahlen erfordert, ein Monitoring-System von Grund auf neu zu bauen. Ein Identity Graph, der mit Confidence Scores und Provenance auf Kantenebene entworfen wurde, trägt bereits die meisten der für dieses Monitoring nötigen Daten in sich, genauso wie erklärbares, auditfähiges Matching davon abhängt, dass genau diese Felder von Anfang an vorhanden sind. Was bleibt, ist die Festlegung der Schwellenwerte und die Prüfung der Alarme, nicht die nachträgliche Instrumentierung des Systems.

FAQ

Wie oft sollte Entity-Resolution-Genauigkeit nach dem Deployment überwacht werden?

Match-Rate, Confidence-Score-Verteilung und Volumen der Prüfwarteschlange sind günstig genug, um laufend oder täglich geprüft zu werden. Gemessene Precision und Recall gegen einen gelabelten Holdout können wöchentlich oder monatlich laufen, oft genug aufgefrischt, damit der Holdout weiterhin aktuelle Daten widerspiegelt.

Was ist der Unterschied zwischen Model Drift und Data Drift?

Data Drift ist eine Verschiebung der statistischen Eigenschaften der Eingabedaten selbst. Model Drift, einschließlich Concept Drift, ist eine Divergenz zwischen Eingabevariablen und Zielergebnis, was bedeutet, dass dieselben Eingaben jetzt einer anderen korrekten Antwort entsprechen als früher.

Was bedeutet es, wenn sich Matches nahe am Confidence-Schwellenwert häufen?

Das bedeutet meist, dass sich die zugrunde liegenden Daten bereits verschoben haben, noch bevor die Match-Rate selbst sichtbar fällt, da ein wachsender Anteil der Entscheidungen tatsächlich schwerer zu treffen wird, statt eindeutig richtig oder falsch zu sein. Es ist typischerweise die früheste verfügbare Warnung vor Drift.

Sollte jeder unsichere Match zur manuellen Prüfung gehen?

Unsichere Matches zur Prüfung weiterzuleiten ist gängige Praxis, aber die Prüfwarteschlange ist nur dann ein nützliches Monitoring-Signal, wenn der Grund für jeden einzelnen Fall erfasst wird. Ohne Ursachencodes sagt eine wachsende Warteschlange nur, dass sich etwas verändert hat, nicht was.

Kann sich eine einzelne, sich verschlechternde Datenquelle in einer gesunden aggregierten Match-Rate verstecken?

Ja, wenn diese Quelle nur einen kleinen Anteil am Gesamtvolumen hat. Match-Rate, Precision, Recall und Confidence-Score-Verteilung nach Quelle aufzuschlüsseln, statt nur einen unternehmensweiten Durchschnitt zu verfolgen, ist das, was eine allmähliche Verschiebung bei einer einzelnen Quelle erkennt, bevor sie groß genug wird, um die aggregierte Zahl zu bewegen.

Quellen

What Is Model Drift?, IBM, geprüft am 2026-08-26.
Data Drift in Machine Learning, Evidently AI, geprüft am 2026-08-26.
Overview of Record Linkage and Current Research Directions, William E. Winkler, US Census Bureau, geprüft am 2026-08-26.
API Reference, Tilores Documentation, geprüft am 2026-08-26.
How to Design an Identity Graph That Stays Accurate: 6 Architecture Decisions for 2026, Tilores, geprüft am 2026-08-26.
Explainable Entity Resolution: Confidence Thresholds and Audit, Tilores, geprüft am 2026-08-26.
Deployment Options: Run Tilores Where Your Data Is, Tilores, geprüft am 2026-08-26.
Contact, Tilores, geprüft am 2026-08-26.