Warum Graphdatenbanken bei Entity Resolution scheitern (und was stattdessen funktioniert)

Kurzfassung: Graphdatenbanken scheitern an textbasierter Entity Resolution, weil das unscharfe Abgleichen von Namen und Adressen zu einer kombinatorischen Explosion von Knoten und Kanten führt. Die richtige Architektur löst Textentitäten zuerst mit einem spezialisierten Werkzeug wie Tilores auf und lädt anschließend saubere Golden Records in den Graphen, um dort Beziehungen zu analysieren.

Dimension	Textbasierte Entity Resolution	Graphbasierte Entity Resolution
Kernfrage	Beziehen sich diese beiden Datensätze auf dieselbe reale Entität?	Repräsentieren diese beiden Graphknoten dieselbe Entität, gemessen an ihren Beziehungen?
Abgleichmechanismus	Fuzzy Matching, Regelwerke, probabilistisches Scoring	Graph-Traversierung, Vergleich von Beziehungsmustern
Graphdatenbanken geeignet?	Nein. Führt zu einer kombinatorischen Explosion von Knoten und Kanten.	Ja. Die Graphstruktur ist hier das richtige Werkzeug.
Herausforderung bei der Skalierung	Quadratisch wachsende Zahl an Vergleichen; Blocking hilft, erzwingt aber Kompromisse	Skaliert im Graphen gut, sobald die Daten sauber sind
Beispielanwendung	Deduplizierung von 100 Mio. Kundendatensätzen aus Dutzenden unterschiedlicher Lieferantenformate	Identifikation zweier Personen mit identischen Beteiligungsmustern, aber unterschiedlichen Namen
Richtiges Werkzeug	Spezialisierte Entity Resolution (z. B. Tilores)	Graphdatenbank (z. B. Neo4j, Neptune)

Auf dieser Seite

• Was ist eine Graphdatenbank eigentlich?
• Entity Resolution: Ein völlig anderes Problem
• Wo Graphdatenbanken bei Entity Resolution an ihre Grenzen stoßen
• Wo Graphdatenbanken glänzen: Graph Entity Resolution
• Die richtige Architektur: erst Text-Resolution, dann Graph
• Fallstudie: 100 Millionen Datensätze in der Last-Mile-Logistik
• Das Problem, von dem Sie nicht wussten, dass Sie es haben
• Warum „Das bauen wir selbst” meistens scheitert
• Was ist mit KI und Large Language Models?
• Die wichtigsten Erkenntnisse
• Häufig gestellte Fragen

Ein Gespräch zwischen Steven Renwick (CEO, Tilores) und Max Latey (Gründer, Pinboard Consulting)

Graphdatenbanken können mächtige Werkzeuge für Entity Resolution (ER) sein, stoßen aber bei Enterprise-Datenmengen regelmäßig an Grenzen bei Performance und Komplexität. In einem aktuellen Webinar hat sich Steven Renwick, CEO von Tilores, mit Max Latey zusammengesetzt, dem Gründer der Graphtechnologie-Beratung Pinboard Consulting, um zu klären, warum Graphdatenbanken bei ER so häufig scheitern, obwohl sie so gut geeignet scheinen – und um Lehren aus realen Implementierungen zu teilen.

Herausgekommen ist ein bemerkenswert praxisnahes Gespräch für alle, die mit unsauberen, fragmentierten oder in Silos verteilten Daten arbeiten.

Was ist eine Graphdatenbank eigentlich?

Die Welt der Graphtechnologie leidet, wie Max Latey es formuliert, unter einem „Begriffsproblem”. Die meisten Menschen verbinden das Wort „Graph” mit Balken- und Liniendiagrammen – der Sorte, die man in Excel erstellt. In der Informatik, der Netzwerkforschung und der Mathematik ist ein Graph jedoch etwas grundlegend anderes: eine Struktur aus Knoten (Objekten) und Kanten (Beziehungen zwischen diesen Objekten).

Während eine klassische relationale Datenbank Daten in Zeilen und Spalten ablegt, speichert eine Graphdatenbank sie als Netzwerk. Ein Knoten kann eine Person, ein Unternehmen, einen Bahnhof oder auch ein chemisches Molekül repräsentieren. Eine Kante steht für die Beziehung zwischen zwei Knoten – eine Finanztransaktion, eine soziale Verbindung, ein Gleis oder eine kovalente Bindung.

Latey erklärt es so: „Graphdatenbanken speichern Dinge als Knoten und Kanten – Knoten sind Objekte, physische oder konzeptionelle, Kanten sind irgendeine Art von Beziehung zwischen ihnen. Man könnte zwei Menschen im Gespräch als zwei Knoten modellieren, wobei die Beziehung zwischen ihnen ‚führt ein Gespräch’ wäre und als Attribut eine Dauer haben könnte.”

Das macht Graphdatenbanken besonders geeignet für Anwendungsfälle wie die Analyse sozialer Netzwerke, Betrugserkennung, die Auswertung von Finanztransaktionen und Knowledge Graphs – überall dort, wo die Beziehungen zwischen den Dingen genauso wichtig sind wie die Dinge selbst.

Entity Resolution: Ein völlig anderes Problem

Entity Resolution – also der Prozess, zu erkennen, dass verschiedene Datensätze in einem oder mehreren Datenbeständen auf dieselbe reale Entität verweisen – müsste eigentlich eine Paradedisziplin für Graphdatenbanken sein, denn ER hat mit Beziehungen und Verbindungen in Daten zu tun. Genau das sorgt jedoch für so viel Verwirrung bei Teams, die ER-Lösungen umsetzen wollen.

Renwick erklärt: „Entity Resolution ist die Deduplizierung und Verknüpfung von Datensätzen aus einer oder vielen Quellen, um eindeutige Dinge oder Entitäten zu identifizieren. Meistens ist das eine Person oder ein Unternehmen, es kann aber auch ein Objekt, ein Ort oder ein Produkt sein. Der Unterschied zu Graphdatenbanken besteht darin, dass wir diese eindeutigen Entitäten überhaupt erst herausarbeiten wollen, statt Beziehungen zwischen Dingen aufzuzeigen.”

Der entscheidende Unterschied: Bei textbasierter Entity Resolution – der häufigsten Form – geht es im Kern darum, festzustellen, ob zwei Textblöcke dasselbe meinen. „Max Lately” und „Max Latey” bezeichnen wahrscheinlich dieselbe Person. „Steven Renwick” und „Stephen Renick” möglicherweise – oder eben nicht. Das aufzulösen erfordert Fuzzy Matching, Regelwerke und probabilistisches Scoring – keine Graph-Traversierung.

Wer die Grundlagen vertiefen möchte – was Entity Resolution ist und wie sie in KYC, AML und Customer 360 zum Einsatz kommt –, findet in der Tilores-Übersicht den vollständigen Umfang des Themas.

Wo Graphdatenbanken bei Entity Resolution an ihre Grenzen stoßen

Sowohl Renwick als auch Latey haben aus erster Hand erlebt, wie Organisationen versuchen, Graphdatenbanken für textbasierte Entity Resolution einzusetzen – und dabei feststellen, warum das nicht funktioniert.

Lateys Erfahrung: „Textbasierte Entity Resolution auf einem Graphen zu betreiben, ist einfach furchtbar. Man bekommt eine riesige kombinatorische Explosion. Es kommt zu einer Wucherung von Knoten und einer Wucherung von Kanten. Die Logik wird schwierig, weil die Art, wie man die Entitäten auflösen will, nichts mit den Beziehungen zu tun hat.”

Ein einfaches Beispiel: ein Kundendatensatz mit Varianten wie „123 Kings Street”, „123 Kingstr”, eine Postleitzahl einmal mit und einmal ohne Leerzeichen. In einer Graphdatenbank erzeugt jede Variante neue Knoten und Kanten – ein ständig wachsendes Gestrüpp ohne saubere Möglichkeit, all das zu einer einzigen Identität zusammenzuführen.

Renwick ergänzt, dass Tilores dieses Muster ständig begegnet: „Die Leute kommen zu uns, nachdem sie Entity Resolution schon mit einer Graphdatenbank versucht haben – meist Neo4j, manchmal Neptune. Und sie haben es auch mit Elasticsearch probiert, weil es konzeptionell einleuchtet: Ich habe ein neues Konto, also suche ich nach verwandten Konten. Aber dann will man alles finden, was mit diesem einen zusammenhängt, muss also erneut springen – und landet bei einem furchtbaren Problem transitiver Sprünge.”

Wo Graphdatenbanken glänzen: Graph Entity Resolution

Es gibt allerdings einen eigenständigen, völlig legitimen Anwendungsfall, in dem Graphdatenbanken tatsächlich das richtige Werkzeug sind: Graph Entity Resolution. Hier geht es darum, anhand ihrer Beziehungen zu bestimmen, ob zwei Graphknoten dieselbe reale Entität repräsentieren – nicht anhand ihrer Textattribute.

Latey nennt ein einprägsames Beispiel aus der Finanz-Compliance: Zwei Personen – nennen wir sie John Smith und Kurt Müller – halten beide Anteile an denselben drei Unternehmen, leben beide im selben Land und sind beide Kunde bei derselben Bank. Ihre Namen sind völlig verschieden, ein Textabgleich würde sie also nie miteinander verknüpfen. Ihre Beziehungsmuster sind jedoch nahezu identisch, was eine berechtigte Frage aufwirft: Handelt es sich in Wahrheit um dieselbe Person unter zwei Identitäten?

„Für Graph Entity Resolution, bei der man anhand von Beziehungen herausfinden will, welche Knoten tatsächlich dieselbe Entität sein könnten, sind Graphdatenbanken großartig”, sagt Latey. „Aber für textbasierte Entitäten – Textblöcke, bei denen man bestimmen will, ob sie ähnlich sind oder nicht – ist ein Graph tatsächlich furchtbar.”

Die richtige Architektur: erst Text-Resolution, dann Graph

Praktisch bedeutet das: Textbasierte Entity Resolution und Graph Entity Resolution sind keine konkurrierenden Ansätze – sie sind einander ergänzende Schritte in einer gut entworfenen Datenpipeline.

Die empfohlene Architektur: Lösen Sie Ihre Textentitäten zuerst mit einem spezialisierten Werkzeug wie Tilores auf und laden Sie die sauberen, deduplizierten Daten anschließend in Ihre Graphdatenbank, um dort beziehungsbasierte Analysen durchzuführen. Latey fasst es so zusammen: „Entity-resolvierte Graphen laufen definitiv besser, wenn man so etwas wie ein Text-Regelwerk einsetzt, bevor man die Knoten in die Graphdatenbank lädt, und danach Graph Entity Resolution betreibt.”

Ohne diesen Schritt landen vier Datensätze von „Max Latey” als vier separate Knoten in Ihrem Graphen – und Ihre gesamte nachgelagerte Beziehungsanalyse steht auf einem fehlerhaften Fundament.

Tilores löst Datensätze bereits bei der Ingestion auf, mit deterministischen Regeln ebenso wie mit probabilistischem oder unscharfem ML-Matching. Der Kontext, der zur Abfragezeit abgerufen wird, ist damit bereits aufgelöst. Das ergänzt Ihre bestehende MDM-, CDP-, KYC-AML-, Governance- oder Data-Warehouse-Schicht, statt sie zu ersetzen. Wer das gesamte Integrationsbild durchdenken will, findet im Leitfaden zu Entity-Resolution-Technologie für das Stammdatenmanagement eine Darstellung, wie diese Schichten zusammenspielen.

Fallstudie: 100 Millionen Datensätze in der Last-Mile-Logistik

Theorie ist das eine. Konkret wird das Gespräch, als die beiden auf ein aktuelles Logistikprojekt zu sprechen kommen – einen Kunden, den Latey zu Tilores gebracht hatte, nachdem er ihn auf einer Logistikkonferenz kennengelernt hatte.

Die Ausgangslage: ein Last-Mile-Logistikdienstleister, der Daten von Dutzenden Lieferanten verarbeitet – eBay, Amazon, Temu, Shein und andere – die jeweils Daten in unterschiedlichen Formaten, in unterschiedlicher Qualität und nach unterschiedlichen Konventionen liefern. Manche maskieren E-Mail-Adressen. Manche kürzen Namen auf Initialen. Manche trennen Adressen an unerwarteten Stellen. Frühere Versuche, eine einheitliche Kundensicht aufzubauen, waren gescheitert.

„Ich habe einmal draufgeschaut und gedacht: Das knackt Tilores locker”, sagt Latey. „Wir haben einen sehr erfolgreichen PoC gemacht. Es hat buchstäblich nur ein paar Wochen gedauert, ihr Datenschema aufzunehmen, die Auflösung durchzuführen, die Modelle aufzusetzen, über 100 Millionen Datensätze zu laden und diese auf rund 30 Millionen eindeutige Golden Records aufzulösen. Die False Negatives und False Positives waren verschwindend gering, und sie waren vollkommen begeistert.”

Renwick merkt an, dass das Ausmaß der vorherigen Fehlschläge das Ergebnis fast unglaubwürdig wirken ließ: „Ich glaube, das Ausmaß der Probleme, die sie vorher hatten, führte dazu, dass sie kaum glauben konnten, wie einfach es sein kann, wenn man die richtigen Werkzeuge einsetzt.”

Das Problem, von dem Sie nicht wussten, dass Sie es haben

Eines der auffälligsten Themen des Gesprächs ist, wie oft Entity Resolution die eigentliche Ursache von Datenproblemen ist, die Organisationen mit anderen Werkzeugen zu lösen versuchen.

„Entity Resolution ist wahrscheinlich die häufigste Data-Science-Herausforderung, von der man nicht weiß, dass man sie hat”, sagt Renwick. „Fast jedes Unternehmen hat dieses Problem mit verstreuten, unsauberen Daten – und alle rennen herum und versuchen, KI darauf aufzubauen, ohne zu merken, dass die Daten eigentlich ziemlich mies sind. Das ist, als würde man ein schickes modernes Haus am Strand bauen, ganz ohne Fundament.”

Latey beschreibt eine Krankenversicherung, die jahrelang ein Problem beim Abgleich von Leistungsabrechnungen und Zahlungen hatte, ohne je zu erkennen, dass es sich um einen Entity-Resolution-Anwendungsfall handelte: „Erst als ich mit ihnen über dieses Szenario gesprochen habe, ging ihnen ein Licht auf: Oh mein Gott, wir haben ein Entity-Resolution-Problem.”

Das zweite Fehlermuster sind Organisationen, die das Problem zwar erkennen, aber davon ausgehen, es selbst lösen zu können – typischerweise mit Python-Bibliotheken und Levenshtein-Distanz, Jaccard-Ähnlichkeit oder Cosinus-Abgleich.

Warum „Das bauen wir selbst” meistens scheitert

Ein Data Scientist mit einem guten Python-Werkzeugkasten kann ein Entity Matching bauen, das an einer Stichprobe von ein paar Tausend Datensätzen gut funktioniert. Das Problem ist die Skalierung.

„Es ist ein quadratisches Problem”, erklärt Renwick. „Man muss jeden einzelnen Datensatz mit jedem anderen vergleichen. Macht man das über 10.000 Datensätze, hat man bereits eine beachtliche Zahl an Vergleichen. Bei 10 Millionen Personen werden die Zahlen langsam verrückt. Es gibt Techniken wie Blocking, aber man macht trotzdem zu viele Kompromisse. Etwas, das an kleinen Stichproben funktioniert, in Produktion zu bringen, ist nahezu unmöglich.”

Die beiden bleiben diplomatisch, aber deutlich, wenn es darum geht, was passiert, wenn Teams sich erst an SQL-Joins, eigenen Python-Skripten oder Graphdatenbanken versuchen, bevor sie schließlich eine spezialisierte Lösung hinzuziehen: „Wir sagen ihnen: Gut, das verzögert unseren Start eben um drei Monate. Probieren Sie es ruhig aus.”

Wer verstehen will, wie sich ein selbst gebautes System in der Praxis gegenüber einem spezialisierten Ansatz schlägt, findet im Tilores-Leitfaden Wie Sie Ihr eigenes Identity-Resolution-System bauen die tatsächlichen Abwägungen und die Stellen, an denen das quadratische Skalierungsproblem am härtesten zuschlägt.

Was ist mit KI und Large Language Models?

Angesichts der aktuellen Begeisterung für LLMs kommt das Gespräch unweigerlich auf die Frage, ob KI Entity Resolution lösen kann. Die Antwort ist differenziert.

„LLMs können Entity Resolution”, räumt Renwick ein. „Wenn Sie eine kleine Datenstichprobe haben und eine einmalige Deduplizierung durchführen wollen, werfen Sie sie in Claude und Sie bekommen ziemlich anständige Ergebnisse. Versuchen Sie, das in Produktion zu bringen, und es gibt eine ganze Reihe von Dingen, die nicht funktionieren.”

Latey ergänzt: „Als Teil eines großvolumigen Daten-Workflows ist das nicht tragfähig. Die Token-Kosten, die Genauigkeit – und Erklärbarkeit können Sie vergessen. Tilores ist buchstäblich zu 100 % eine White Box: Sie sehen, was womit übereingestimmt hat und warum, gespeichert am Datensatz.”

Die interessantere künftige Anwendung sind LLMs als Ersatz für den Menschen im Prozess bei Grenzfällen: Graubereichs-Übereinstimmungen, die ein Regelwerk als unsicher markiert, könnten von einem LLM geprüft werden, statt eine manuelle Prüfung zu erfordern – also geringe Mengen mehrdeutiger Fälle abdecken, während das Gros des deterministischen Abgleichs beim Regelwerk bleibt.

Der Tilores-Artikel dazu, ob sich LLMs für Entity Resolution einsetzen lassen, beleuchtet dieses hybride Modell im Detail, einschließlich der Grenzen im Produktivbetrieb.

Die wichtigsten Erkenntnisse

• Graphbasierte und textbasierte Entity Resolution sind verwandte, aber grundlegend verschiedene Disziplinen – wer sie verwechselt, landet bei teuren gescheiterten Implementierungen.
• Textbasierte Entity Resolution („Sind diese beiden Datensätze dieselbe Person?”) eignet sich schlecht für Graphdatenbanken, die beim unscharfen Textabgleich eine kombinatorische Explosion erleiden.
• Graphbasierte Entity Resolution („Sind diese beiden Knoten anhand ihrer Beziehungen tatsächlich dieselbe Entität?”) ist der Bereich, in dem Graphdatenbanken wirklich glänzen – etwa bei der Analyse wirtschaftlich Berechtigter.
• Die optimale Architektur lautet: erst textbasierte Entity Resolution, dann saubere Golden Records in die Graphdatenbank laden.
• Entity Resolution gehört zu den häufigsten Datenproblemen, von denen Organisationen nicht wissen, dass sie sie haben – und zu den am häufigsten unterschätzten.
• LLMs können bei Entity Resolution in kleinem Maßstab oder bei der Prüfung von Grenzfällen unterstützen, taugen aber nicht als zentrale Matching-Engine im Produktivbetrieb.

FAQ

Warum scheitern Graphdatenbanken an textbasierter Entity Resolution?

Textbasierte Entity Resolution erfordert Fuzzy Matching und probabilistisches Scoring, um zu bestimmen, ob zwei Datensätze auf dieselbe reale Entität verweisen. Wendet man das auf eine Graphdatenbank an, erzeugt jede Adress- oder Namensvariante neue Knoten und Kanten und damit eine kombinatorische Explosion. Die Logik wird unbeherrschbar, weil die Art, wie Entitäten über unscharfen Textabgleich aufgelöst werden, nichts mit Graphbeziehungen zu tun hat.

Was ist der Unterschied zwischen textbasierter und graphbasierter Entity Resolution?

Textbasierte Entity Resolution bestimmt, ob zwei Textblöcke auf dieselbe reale Entität verweisen, und benötigt dafür Fuzzy Matching, Regelwerke und probabilistisches Scoring. Graphbasierte Entity Resolution bestimmt anhand der Beziehungsmuster, ob zwei Graphknoten dieselbe Entität repräsentieren – nicht anhand der Textattribute. Beide sind einander ergänzende Schritte, keine konkurrierenden Ansätze.

Wann sind Graphdatenbanken das richtige Werkzeug für Entity Resolution?

Graphdatenbanken glänzen bei Graph Entity Resolution, wo es darum geht, anhand von Beziehungen zu erkennen, ob zwei Knoten dieselbe Entität sind. In der Finanz-Compliance können etwa zwei Personen mit völlig unterschiedlichen Namen, aber identischen Beteiligungsmustern und Bankverbindungen dieselbe Person sein. Für das Aufspüren solcher struktureller Ähnlichkeiten sind Graphdatenbanken bestens geeignet.

Wie sieht die richtige Architektur für die Kombination von Text- und Graph-Entity-Resolution aus?

Lösen Sie Ihre Textentitäten zuerst mit einem spezialisierten Werkzeug wie Tilores auf, das bei der Ingestion deterministische Regeln sowie probabilistisches oder unscharfes ML-Matching anwendet und daraus saubere Golden Records erzeugt. Laden Sie diese deduplizierten Golden Records anschließend in Ihre Graphdatenbank, um dort beziehungsbasierte Analysen durchzuführen. Ohne diesen Schritt landen doppelte Datensätze als separate Knoten im Graphen und verfälschen jede nachgelagerte Beziehungsanalyse.

Können LLMs im Produktivbetrieb eine spezialisierte Entity-Resolution-Engine ersetzen?

LLMs können Entity Resolution an kleinen Datenstichproben leisten oder Graubereichsfälle prüfen, taugen aber nicht als zentrale Matching-Engine im Produktivbetrieb. Token-Kosten, Genauigkeit im großen Maßstab und fehlende Erklärbarkeit machen sie für großvolumige Daten-Workflows ungeeignet. Ein spezialisiertes Werkzeug liefert ein zu 100 % nachvollziehbares White-Box-Matching, bei dem jede Match-Entscheidung samt Begründung am Datensatz gespeichert wird.

Sehen Sie es an Ihren eigenen Daten: Buchen Sie eine Demo für einen Durchlauf mit Ihren Datensätzen, oder holen Sie sich den Evaluation Build, um aufgelöste Entitätsdaten lokal auszuprobieren.