Einen Identity Graph entwerfen, der genau bleibt: 6 Architekturentscheidungen für 2026

Kurzfassung: Ein Identity Graph veraltet, wenn seine Keys, Kanten und Cluster keine neuen Datensätze aufnehmen können, ohne komplett neu gebaut zu werden. Sechs Entscheidungen halten ihn 2026 genau, während sich Daten verändern: stabile Entitäts-Keys, gewichtete Kanten, Provenance auf jeder Kante, versionierte Merges und Splits, inkrementelles Re-Matching und Drift-Monitoring. Ein Produktionsgraph mit 110 Millionen Datensätzen zeigt, was passiert, wenn alle sechs eingehalten werden.

Entwerfen Sie den Graphen, bevor die Daten die Entscheidung erzwingen. Besprechen Sie die Architektur mit unserem Team oder testen Sie das Matching-Verhalten zunächst an Ihren eigenen Datensätzen. Demo buchen oder Tilores Studio kostenlos testen.

Auf dieser Seite

Warum veraltet ein Identity Graph überhaupt?
Entscheidung 1: Entitäts-Keys wählen, die jedes einzelne Quellsystem überdauern
Entscheidung 2: Jeder Kante einen Confidence Score geben, nicht nur einen booleschen Link
Entscheidung 3: Provenance auf jeder Kante festhalten
Entscheidung 4: Merges und Splits versionieren, damit sie wiederholt werden können
Entscheidung 5: Inkrementell nachmatchen, statt den Graphen neu aufzubauen
Entscheidung 6: Drift erkennen, bevor sie sich aufsummiert

Warum veraltet ein Identity Graph überhaupt?

Ein Identity Graph veraltet nicht, weil sich Daten verändern. Daten verändern sich immer: Namen werden unterschiedlich transliteriert, Firmen fusionieren, Telefonformate variieren von System zu System. Er veraltet, wenn die Struktur des Graphen diese Veränderung nicht ohne einen kompletten Neuaufbau aufnehmen kann, sodass die Genauigkeit zwischen den Neuaufbauten still nachlässt, statt stabil zu bleiben.

Record Linkage als Disziplin ist älter als jede Graphdatenbank. William Winklers Forschungsbericht des US Census Bureau von 2006 bringt die Kernaufgabe klar auf den Punkt: Name- und Adressinformationen über Paare von Dateien hinweg zu vergleichen, „to determine those pairs of records that are associated with the same entity”, wobei die anspruchsvollsten Ansätze „graph theoretic ideas for representing linkage relationships as conditional random fields that be partitioned into clusters representing individual entities” nutzen. Das ist der Identity Graph, beschrieben sechzig Jahre in die Geschichte des Feldes hinein: Knoten sind Datensätze, Kanten sind Match-Entscheidungen, Cluster sind aufgelöste Entitäten.

Neo4js eigene Anleitung zur Graphmodellierung ergänzt den Teil, der für dauerhafte Genauigkeit entscheidend ist: „creating a model is an iterative process”, verfeinert durch Tests, während sich Datenanforderungen und Abfragemuster klarer zeigen. Ein Graph, der einmal entworfen und dann sich selbst überlassen wird, ist ein Graph, der für die Daten des ersten Tages entworfen wurde, nicht für die Daten, die im zweiten Jahr eintreffen. Sechs Entscheidungen bestimmen, ob er mithalten kann, und ein Produktionsgraph, der Firmenidentität über mehr als 16 Quellsysteme hinweg auflöst, zeigt, wie jede davon aussieht, sobald echte, unsaubere Daten hindurchlaufen.

Entscheidung 1: Entitäts-Keys wählen, die jedes einzelne Quellsystem überdauern

Neo4js Anleitung zur Knotenmodellierung ist auch außerhalb einer Graphdatenbank eine nützliche Grunddisziplin: „the dominant nouns in your application use case are represented as nodes”, jeweils mit einer „unique identifier” versehen, sodass sichergestellt ist, dass „every node is a separate and distinguished entity”. Die Falle bei Entity Resolution besteht darin, den Primärschlüssel eines Quellsystems als diesen Identifikator zu verwenden. Eine CRM-ID, eine ERP-Kundennummer oder eine Support-Ticket-Kontonummer beschreiben alle dieselbe reale Person oder Firma unterschiedlich, und keine davon übersteht eine Systemmigration.

Ein Entitäts-Key muss von der Resolution-Schicht selbst vergeben werden, in dem Moment, in dem sich ein Cluster zum ersten Mal bildet, und er muss stabil bleiben, selbst wenn sich jeder Quelldatensatz dahinter später ändert. Tilores vergibt diesen Key auf Entitätsebene, unabhängig von der Nummerierung eines Quellsystems, genau damit eine Migration oder eine neue Integration keine nachgelagerten Systeme zwingt, ihre Datensätze neu zu verschlüsseln. Genau diese Unabhängigkeit erlaubt es einem Graphen, sich über so unterschiedliche Quellen wie ein sauberes Register juristischer Personen und ein eingescanntes Zollformular zu erstrecken, die Spanne, die eine Due-Diligence-Plattform heute zu einem einzigen Firmengraphen auflöst.

Ein Graph bleibt genau, wenn jede Verbindung die Belege trägt, die für Aktualisierung, Erklärung, Umkehr und Monitoring nötig sind.

Entscheidung 2: Jeder Kante einen Confidence Score geben, nicht nur einen booleschen Link

Ein Graph, der nur festhält, ob zwei Datensätze übereinstimmen oder nicht, verschenkt genau die Information, die ein Steward oder ein Entwickler später braucht, um zu entscheiden, ob ein grenzwertiger Match noch einmal geprüft werden sollte. Die Tilores API liefert bei jedem Match zwei getrennte Werte: einen Entity Score, „the overall quality of matches within the entity”, und einen Hit Score, „how closely the match aligns with the provided search parameter”, beide als Fließkommazahl zwischen null und eins.

Diesen Wert direkt an der Kante zu speichern, nicht nur als Nebenprodukt des Matching-Laufs, bedeutet, dass eine spätere Abfrage gezielt nach jedem Cluster fragen kann, dessen schwächste Kante unter einen Schwellenwert fällt, also genau die Menge an Clustern, die eine manuelle Prüfung verdient, bevor sie sich zu einem größeren Fehler aufsummieren. Bewertete Kanten halten Abfragen auch bei großem Umfang schnell: Ein Graph mit 60 Millionen aufgelösten Firmenclustern kann eine Abfrage weiterhin in rund 100 Millisekunden beantworten, weil der Score mit der Kante mitreist, statt bei jedem Lesevorgang neu berechnet zu werden.

Entscheidung 3: Provenance auf jeder Kante festhalten

Neo4js Modellierungsanleitung merkt an, dass „properties for a relationship are used to enrich how two nodes are related”, genutzt, wenn man wissen muss, wie zwei Knoten verbunden sind, nicht nur dass sie es sind. Provenance ist die Kanteneigenschaft, die für einen Identity Graph am meisten zählt: welcher Quelldatensatz, welche Matching-Regel oder Modellversion und welcher Lauf diese Kante erzeugt haben.

Ohne sie bedeutet das Erklären eines Merges Monate später, den Match von Grund auf neu laufen zu lassen und zu hoffen, dass das Ergebnis reproduzierbar ist. Mit ihr kann ein Data Steward oder ein Prüfer genau diese Kante öffnen, die ausgelöste Regel und das verglichene Datensatzpaar sehen und sofort eine Antwort erhalten. Ein Graph, der auf 23 gemeinsam gegen einen Ground-Truth-Datensatz abgestimmten Clustering-Regeln aufbaut, bleibt nur erklärbar, wenn jede Kante festhält, welche dieser 23 Regeln ausgelöst hat. Die Record-Insights-Schicht von Tilores legt genau das offen: Filterung, Statistik und Aggregation über die Datensätze innerhalb einer aufgelösten Entität, sodass das Warum hinter einem Cluster abfragbar ist, statt im Nachhinein rekonstruiert werden zu müssen.

Entscheidung 4: Merges und Splits versionieren, damit sie wiederholt werden können

Jeder Identity Graph liegt irgendwann bei einem Merge falsch, meist weil zwei Quelldatensätze zum damaligen Zeitpunkt tatsächlich wie dieselbe Entität aussahen und spätere Belege zeigten, dass sie es nicht waren. Ein Graph ohne Versionierung behandelt diese Korrektur als destruktive Änderung: Der alte Zustand ist verschwunden, und es gibt keine Möglichkeit zu zeigen, was der Graph vor der Korrektur angenommen hatte.

Ein versionierter Graph behandelt einen Merge oder Split als Ereignis mit einem Vorher-Zustand und einem Nachher-Zustand, beide abfragbar. Das macht einen falschen Merge reversibel, ohne kaskadierenden Schaden an allem, was sich auf den alten Cluster bezogen hat, und es gibt einem Prüfer eine echte Antwort auf die Frage, wie ein Datensatz an einem bestimmten Datum aussah, statt nur, wie er heute aussieht.

Entscheidung 5: Inkrementell nachmatchen, statt den Graphen neu aufzubauen

AWS’ eigener Entity-Resolution-Dienst unterscheidet zwei Verarbeitungsmodi: „manual bulk processing”, das auf Abruf den gesamten Datensatz neu verarbeitet, und „automatic incremental processing”, das nur neue Datensätze mit dem bestehenden Bestand vergleicht, sobald Daten eintreffen. Der Unterschied summiert sich mit wachsendem Umfang. Ein Graph, der nur durch komplette Neuverarbeitung nachgematcht werden kann, läuft entweder selten, sodass er hinter eingehenden Daten hinterherhinkt, oder läuft ständig, zu Kosten, die mit der Gesamtgröße des Graphen wachsen, nicht mit der Größe dessen, was sich tatsächlich verändert hat.

Von Anfang an auf inkrementelles Matching zu setzen, sodass ein neuer Datensatz gegen bestehende Cluster verglichen wird, statt eine vollständige Neuberechnung auszulösen, ist das, was Echtzeit-Resolution möglich macht, ohne ein ständig wachsendes Batch-Fenster im Hintergrund. Es ist auch das, was einen großen Erstimport überhaupt praktikabel macht: Ein vollständiger erster Durchlauf über mehr als 100 Millionen Quelldatensätze kann in unter einem Tag abgeschlossen werden, genau weil jeder Datensatz nach diesem ersten Import nur einmal mit dem Graphen verglichen werden muss, statt zusammen mit allem bereits Aufgelösten neu verarbeitet zu werden.

Entscheidung 6: Drift erkennen, bevor sie sich aufsummiert

Ein Graph, der beim Start genau war, verschlechtert sich still, während sich die Quelldaten darunter verschieben: Ein neues Upstream-System beginnt, ein Namensfeld anders formatiert zu senden, oder ein Datenanbieter ändert eine Kodierung, und die Match-Rate fällt, bevor es jemand bemerkt. Die Lösung ist kein einmaliger Genauigkeitstest zum Go-Live. Es ist eine ständige Prüfung der Cluster-Größenverteilung, der Match-Rate gegen eine gleitende Baseline und des Anteils an Matches, die nahe am Schwellenwert liegen, statt eindeutig darüber oder darunter.

So gemessen ist der Nutzen konkret, nicht theoretisch: Der Wechsel von einem adressabhängigen Matching-Ansatz zu einem, der um die sechs Entscheidungen oben herum aufgebaut ist, verwandelte eine dokumentierte Schwäche, geringe Recall-Werte bei unsauberen Quelldaten, in eine Verbesserung des F1-Werts um 30 Punkte gegenüber dem vorherigen Ansatz auf demselben Ground-Truth-Datensatz. Das ist ein Thema groß genug für eine eigene Antwort, behandelt in einem begleitenden Beitrag zu erklärbarer Entity Resolution und der Prüfung von Confidence-Schwellenwerten. Ein Graph, der mit Kanten-Scores, Provenance und Versionierung entworfen wurde, trägt die Daten, die eine Monitoring-Prüfung braucht, bereits in sich; ein Graph ohne all das muss diese Belege jedes Mal neu von Grund auf rekonstruieren, wenn etwas verdächtig aussieht.

Entscheidung	Was ohne sie schiefgeht	Was sie ermöglicht
1. Stabile Entitäts-Keys	Jede Quellmigration erzwingt eine Neuverschlüsselung in allen nachgelagerten Systemen	Eine Entitäts-ID, die eine CRM- oder MDM-Migration übersteht
2. Confidence Scores an Kanten	Keine Möglichkeit, schwache Matches zu finden, bevor sie sich aufsummieren	Abfragbare Prüfung jedes Clusters unterhalb eines Schwellenwerts
3. Provenance an Kanten	Ein Merge lässt sich nur erklären, indem der Match von Grund auf neu läuft	Sofortige, reproduzierbare Antworten für einen Steward oder Prüfer
4. Versionierte Merges und Splits	Eine Korrektur löscht die Aufzeichnung dessen, was der Graph vorher annahm	Reversible Korrekturen und eine echte Antwort zu einem bestimmten Zeitpunkt
5. Inkrementelles Re-Matching	Kosten und Verzögerung wachsen mit der Gesamtgröße des Graphen, nicht mit dem, was sich änderte	Echtzeit-Resolution ohne ein ständig wachsendes Batch-Fenster
6. Drift-Monitoring	Genauigkeit verschlechtert sich still zwischen Neuaufbauten, ohne sichtbares Signal	Eine Frühwarnung, bevor eine Verschiebung in den Upstream-Daten zu einem großen Fehler wird

Nichts davon ist ungewöhnlich für das zugrunde liegende Problem, nur dafür, wie selten ein Graph dafür entworfen wird, es zu erwarten. Ein Name, der überflüssige Tokens mitträgt, oder eine Adresse, die darin eingebettet ist, schlägt eine gewöhnliche unscharfe oder exakte Suche komplett fehl, und genau deshalb sind die sechs Entscheidungen oben strukturell, nicht optional, sobald weitere, unordentlichere Quellen dem Graphen beitreten. Konsequent angewendet, sind sie das, was einen Graphen seine hundertste neue Quelle genauso aufnehmen lässt wie seine erste: ohne Neuaufbau und ohne einen stillen Rückgang dessen, worauf man sich verlassen kann.

FAQ

Was ist ein Identity Graph bei Entity Resolution?

Ein Identity Graph stellt Datensätze als Knoten und Match-Entscheidungen als Kanten dar, wobei Cluster verbundener Knoten jeweils eine einzelne aufgelöste reale Entität repräsentieren. Das ist die strukturelle Form, die die Record-Linkage-Forschung seit Jahrzehnten nutzt, angewendet auf einen lebendigen, laufend aktualisierten Datensatz.

Warum braucht ein Identity Graph Versionierung?

Ohne Versionierung ist die Korrektur eines falschen Merges eine destruktive Änderung, die löscht, was der Graph vor der Korrektur angenommen hatte. Mit Versionierung ist ein Merge oder Split ein Ereignis mit Vorher- und Nachher-Zustand, sodass ein Fehler rückgängig gemacht werden kann und ein Prüfer sehen kann, wie ein Datensatz an einem bestimmten Datum aussah.

Was ist der Unterschied zwischen Bulk- und inkrementellem Matching?

Bulk Processing verarbeitet auf Abruf den gesamten Datensatz neu, was funktioniert, aber mit wachsendem Datensatz teurer wird. Incremental Processing vergleicht nur neue oder geänderte Datensätze mit dem bestehenden Bestand, sobald Daten eintreffen, was Echtzeit-Resolution im großen Maßstab überhaupt praktikabel macht.

Wie viele Quellsysteme kann ein Identity Graph auflösen?

Es gibt keine feste Grenze, aber die Schwierigkeit skaliert mit der Uneinheitlichkeit der Quellen, nicht nur mit ihrer Anzahl. Exiger löst mehr als 16 verschiedene Quellen auf, von sauberen Registern juristischer Personen bis zu globalen Zoll- und Versanddaten, in einem einzigen Entitätsgraphen.

Was sollte ein Team überwachen, um Drift im Identity Graph früh zu erkennen?

Die Match-Rate gegen eine gleitende Baseline, die Verteilung der Cluster-Größen und den Anteil an Matches, die nahe am Confidence-Schwellenwert liegen, statt eindeutig darüber oder darunter. Ein Graph, der mit Confidence Scores und Provenance auf Kantenebene entworfen wurde, trägt die für dieses Monitoring nötigen Daten bereits in sich.

Quellen

Overview of Record Linkage and Current Research Directions, William E. Winkler, US Census Bureau, geprüft am 2026-08-26.
Graph Data Modeling Guidelines, Neo4j Developer Guides, geprüft am 2026-08-26.
What Is AWS Entity Resolution?, AWS Entity Resolution Documentation, geprüft am 2026-08-26.
API Reference, Tilores Documentation, geprüft am 2026-08-26.
Exiger Case Study: Resolving the World’s Companies at Scale, Tilores, geprüft am 2026-08-26.
Deployment Options: Run Tilores Where Your Data Is, Tilores, geprüft am 2026-08-26.
Explainable Entity Resolution: Confidence Thresholds and Audit, Tilores, geprüft am 2026-08-26.
Contact, Tilores, geprüft am 2026-08-26.