Was ist Entity Resolution? Wie sie wirklich funktioniert und warum sie 2026 wichtig ist

Wir entwickeln beruflich KI-Agenten für Vertrieb und Marketing, und sie arbeiten immer über mehrere Systeme hinweg. Der Vertrieb läuft in Salesforce. Das Marketing läuft in HubSpot. Der Support ist wieder ganz woanders.

Einer unserer Agenten fiel auf die leiseste Art aus. Derselbe Kunde lag in beiden Systemen als zwei verschiedene Datensätze vor. Keine gemeinsame ID. Kein Match. Also riet der Agent.

Manchmal lag er falsch. Er protokollierte einen Anruf beim falschen Konto und teilte einem Vertriebsmitarbeiter mit, ein Geschäft sei erkaltet, obwohl es nur zwei Anrufe vor dem Abschluss stand.

Die Lücke, die diesen Fehler verursacht hat, hat einen Namen. Die meisten Menschen, die Software mit KI entwickeln, haben ihn noch nie gehört: Entity Resolution.

Entity Resolution entscheidet, ob zwei oder mehr Datensätze, unabhängig von ihrer Formatierung, dieselbe reale Person, dasselbe Unternehmen oder dieselbe Sache beschreiben. Funktioniert sie, stimmen alle Systeme eines Stacks bei der Identität überein. Funktioniert sie nicht, übernehmen alle KI-Agenten, Dashboards und Workflows auf diesen Daten die Verwechslung.

Was bedeuten Entity Resolution, Identity Resolution, Record Linkage und Deduplizierung genau?

Die vier Begriffe überschneiden sich, und Anbieter verwenden sie uneinheitlich. Deshalb lohnt sich eine klare Trennung.

Deduplizierung findet und vereinigt doppelte Datensätze innerhalb eines einzelnen Datenbestands, zum Beispiel zwei Zeilen für dieselbe Person in einer Tabelle.

Record Linkage ist der ältere statistische Begriff für den Abgleich von Datensätzen, die dieselbe Entität in zwei oder mehr getrennten Datenbeständen beschreiben. Die Idee ist älter, als viele annehmen. Sie stammt aus Volkszählung und Gesundheitsstatistik, wo William Winkler und Kollegen beim US Census Bureau sie über Jahrzehnte für nationale Datenbestände formalisierten (Winkler, 2014).

Identity Resolution ist meist die auf Menschen eingegrenzte Martech- und Adtech-Variante desselben Problems: Ein Browser-Cookie, eine mobile ID und eine E-Mail-Adresse werden zu einem Verbraucherprofil verbunden (Fivetran).

Entity Resolution ist der Oberbegriff. Er umfasst Menschen, Unternehmen, Produkte, Adressen, Transaktionen und alles andere, was ein System zuverlässig wiedererkennen muss, unabhängig davon, ob der Vergleich innerhalb eines Datenbestands oder über zehn Systeme hinweg stattfindet.

Wie funktioniert Entity Resolution wirklich?

Im Kern beantwortet eine Entity-Resolution-Engine immer wieder dieselbe Frage: Wie wahrscheinlich ist es bei zwei Datensätzen, dass sie dasselbe beschreiben? Zwei große Verfahrensfamilien beantworten diese Frage.

Was ist der Unterschied zwischen deterministischem und probabilistischem Matching?

Deterministisches Matching verknüpft Datensätze nur, wenn bestimmte Felder exakt übereinstimmen oder nach einer leichten Normalisierung gleich sind: dieselbe Steuer-ID, dieselbe verifizierte E-Mail-Adresse oder dieselbe amtliche Kennung. Es ist schnell, nachvollziehbar und präzise, wenn ein starker gemeinsamer Schlüssel existiert.

Probabilistisches Matching, auch Fuzzy Matching genannt, braucht keinen perfekten Schlüssel. Es bewertet die Ähnlichkeit mehrerer schwächerer Felder gleichzeitig, etwa die Schreibweise eines Namens, das Format einer Adresse und eine Telefonnummer, und kombiniert diese Werte zu einem einzigen Konfidenzwert.

Die meisten produktiven Systeme nutzen beides: Deterministische Regeln erfassen die einfachen Paare mit hoher Sicherheit, probabilistisches Scoring übernimmt den Rest.

Welche Verfahren zur Zeichenkettenähnlichkeit verwenden Matching-Engines tatsächlich?

Drei Verfahren erledigen einen Großteil der Arbeit, und jedes erfasst eine andere Art von realer Datenabweichung.

Die Levenshtein-Distanz, auch Editierdistanz genannt, zählt die kleinste Zahl einzelner Einfügungen, Löschungen oder Ersetzungen von Zeichen, die nötig sind, um eine Zeichenkette in eine andere umzuwandeln. Vladimir Levenshtein führte sie 1965 ein, die englische Veröffentlichung folgte 1966 (Levenshtein, 1966). Sie erkennt Tippfehler gut: Zwischen "Jonathon" und "Jonathan" liegt genau eine Änderung.

Die Jaro-Winkler-Ähnlichkeit wurde für kurze Zeichenketten wie Namen entwickelt. Sie bewertet übereinstimmende Zeichen innerhalb eines begrenzten Abstands und vergibt anschließend einen Bonus für ein gemeinsames Präfix, weil Menschen den Anfang eines Namens selten falsch schreiben. Matthew Jaro schlug die Basismetrik 1989 vor. William Winkler, damals beim US Census Bureau, ergänzte die nach ihm benannte Präfixgewichtung (Winkler, US Census Bureau; Oracle FCCM Matching Guide).

Soundex gleicht nach Klang statt nach Schreibweise ab. Margaret Odell und Robert Russell patentierten das Verfahren 1918, um Namen aus dem US Census phonetisch zu indexieren. Dadurch erhalten "Smith" und "Smyth" denselben Code (Soundex-Geschichte, West Penwith). Das Verfahren erkennt bis heute Transliterationen und phonetische Abweichungen, die eine Editierdistanz übersieht.

Was ist das Fellegi-Sunter-Modell, und warum steckt es noch immer in den meisten Matching-Engines?

1969 veröffentlichten die Statistiker Ivan Fellegi und Alan Sunter den Aufsatz "A Theory for Record Linkage" im Journal of the American Statistical Association. Das Modell ist bis heute das theoretische Rückgrat, das die meisten modernen Matching-Engines annähern, unabhängig davon, ob sie regelbasiert oder maschinell gelernt sind (Fellegi & Sunter, 1969).

Das Modell vergleicht jedes Feld zweier Datensätze und stellt zwei Fragen. Erstens die m-Wahrscheinlichkeit: Wenn dieses Paar wirklich dieselbe Entität ist, wie wahrscheinlich stimmt dieses Feld dann überein? Zweitens die u-Wahrscheinlichkeit: Wenn dieses Paar nicht dieselbe Entität ist, wie wahrscheinlich stimmt das Feld rein zufällig überein? Dass ein Geburtsmonat zufällig gleich ist, geschieht ungefähr in einem von zwölf Fällen. Bei einem seltenen Nachnamen ist die Zufallswahrscheinlichkeit deutlich kleiner (Übersicht zu Record Linkage, Wikipedia).

Das Verhältnis dieser beiden Wahrscheinlichkeiten wird logarithmiert und über alle verglichenen Felder summiert. So entsteht ein Gesamtgewicht für das Paar. Fellegi und Sunter zeigten, dass die Sortierung nach diesem Gewicht und die Einteilung in drei Gruppen, Link, möglicher Link und Nicht-Link, für vorgegebene Fehlergrenzen die statistisch optimale Entscheidungsregel ist. Diese Dreiteilung mit einer manuellen Prüfwarteschlange in der Mitte prägt noch heute die meisten Systeme für Sanktionsscreening und KYC.

Wie funktionieren Konfidenzwerte und Match-Schwellenwerte?

Eine Matching-Engine überführt das Fellegi-Sunter-Gewicht oder ein maschinell gelerntes Gegenstück in einen einzigen Konfidenzwert je Kandidatenpaar. Zwei Schwellenwerte bestimmen dann, was damit geschieht.

Oberhalb des oberen Schwellenwerts wird das Paar automatisch verknüpft. Unterhalb des unteren Schwellenwerts gilt es als zwei getrennte Entitäten. Alles dazwischen wird zu einem möglichen Match und meist an einen Menschen oder eine zweite Regel zur Prüfung weitergegeben.

Die Wahl dieser Schwellenwerte ist eine geschäftliche Entscheidung, nicht nur ein statistisches Problem. Ein KYC-Team bei der Prüfung auf sanktionierte Personen akzeptiert mehr manuelle Arbeit, um keinen echten Treffer zu verpassen. Ein Marketingteam bei der Deduplizierung einer Newsletter-Liste nimmt mehr Risiko in Kauf, um weniger manuell prüfen zu müssen.

Was ist Blocking, und warum ist es bei großen Datenmengen wichtig?

Jeden Datensatz mit jedem anderen zu vergleichen, skaliert nicht. Eine Datei mit einer Million Datensätzen enthält fast 500 Milliarden mögliche Paare. Jedes davon zu bewerten, ist nicht praktikabel (Binette & Steorts, arXiv).

Blocking, auch Candidate Generation genannt, löst das Problem, indem Datensätze zuerst über einen günstigen gemeinsamen Schlüssel gruppiert werden, etwa Postleitzahl, Geburtsjahr oder die ersten drei Buchstaben eines Nachnamens. Der aufwendige Vergleich läuft nur innerhalb dieser Gruppen (Zingg, Entity Resolution at Scale).

Blocking tauscht Recall gegen Geschwindigkeit. Ein zu aggressiver Block kann zwei echte Matches auf verschiedene Gruppen verteilen, bevor sie überhaupt verglichen werden. Üblich sind deshalb mehrere überlappende Blocking-Durchläufe mit unterschiedlichen Schlüsseln. Ein Paar muss dann nur eines von mehreren Signalen teilen, um die Scoring-Stufe zu erreichen.

Was ist ein Resolution Graph, und wie unterscheidet er sich von einem "Golden Record"?

Älteres Master Data Management verdichtete alles zu einem einzigen "Golden Record", also einer zusammengeführten Zeile, die ihre Quelldaten überschrieb. Dadurch gehen die ursprünglichen Belege verloren, und ein fehlerhafter Match lässt sich später nur schwer rückgängig machen.

Die Alternative, die viele moderne Plattformen verwenden, ist ein Resolution Graph: Quelldatensätze bleiben als Knoten unverändert, und deterministische sowie probabilistische Matches werden zu Kanten zwischen ihnen. Die "Entität" ist der verbundene Cluster, den man in beide Richtungen bis zu jedem Ursprungsdatensatz verfolgen kann (Aerospike, Entity Resolution und Golden Records; Binette & Steorts beschreiben Entity Resolution formal als Graph-Clustering-Problem). Neue Datensätze lassen sich hinzufügen, und der Graph wird schrittweise aktualisiert, statt eine vollständige neue Zusammenführung zu erzwingen.

Entity Resolution, Explained

Echtzeit oder Batch Entity Resolution: Was ist der Unterschied, und warum ist er wichtig?

Entity Resolution arbeitet nach zwei verschiedenen Zeitmodellen. Welches passt, hängt davon ab, ob eine Entscheidung auf die Antwort wartet, nicht von einer Stilfrage.

Batch ist richtig, wenn nichts auf die Antwort wartet, etwa bei der nächtlichen Deduplizierung einer Marketingliste oder dem vierteljährlichen Abgleich einer Warehouse-Tabelle. Echtzeit wird wichtig, sobald eine laufende Entscheidung von der Identität abhängt: ein neues Konto freigeben, eine Transaktion prüfen oder einem KI-Agenten ermöglichen, beim ersten Versuch zum richtigen Kunden zu antworten. Streaming- und API-native Matcher lösen Entitäten auf und aktualisieren den Graphen beim Eintreffen neuer Datensätze, statt auf das nächste Batch-Fenster zu warten. AWS Entity Resolution und API-native Plattformen wie Tilores (tilores.io) arbeiten auf diese Weise. Sie ergänzen ältere, Batch-orientierte Master-Data-Management-Werkzeuge, statt jeden Anwendungsfall zu ersetzen.

Warum ist Entity Resolution gerade jetzt wichtig?

Datenqualität und Customer 360. Jedes Unternehmen mit mehr als einem führenden System hat dasselbe Problem wie am Anfang: Derselbe Kunde liegt als leicht unterschiedliche Zeilen in mehreren Werkzeugen vor. Niemand besitzt den Abgleich, also findet er nicht statt. Entity Resolution ist der Mechanismus hinter einer echten "einheitlichen Kundensicht", nicht nur das gewünschte Ziel.

KYC, AML und Sanktionsscreening. Der Abgleich des Namens eines neuen Kunden mit einer Sanktionsliste oder einer Liste politisch exponierter Personen ist ein Record-Linkage-Problem im Compliance-Kontext: Ist diese antragstellende Person angesichts von Transliteration, Spitznamen und Tippfehlern dieselbe Person wie der gelistete Name? Regulierer erwarten ein risikobasiertes Compliance-Programm mit genau dieser Art von Screening-Kontrolle (OFAC, A Framework for OFAC Compliance Commitments). Ist der Matching-Schwellenwert zu locker, ertrinken Ermittler in Fehlalarmen. Ist er zu streng, rutscht ein echter Treffer durch.

KI-Agenten und RAG. Hier wird die Bedeutung unterschätzt. Wenn ein Agent oder eine Retrieval-Pipeline "den Kundendatensatz" abruft, vertraut das System darauf, dass eine vorgelagerte Schicht bereits entschieden hat, welche Datensätze zu diesem Kunden gehören. Fehlt Entity Resolution, ist sie falsch oder uneinheitlich, weiß der Agent nichts von seinem Fehler. Er antwortet selbstbewusst aus dem Fragment, das er abgerufen hat, weil ein Sprachmodell eine zersplitterte Identität nicht von einer vollständigen unterscheiden kann. Beobachter von RAG-Fehlern in Unternehmen führen Halluzinationen zunehmend auf genau solche vorgelagerten Datenprobleme statt auf das Modell selbst zurück (CX Today, KI-Halluzinationen und fehlerhafte Daten). Bekommt ein Agent eine aufgelöste, deduplizierte Identitätsschicht, hört er auf zu raten. Bekommt er zwei Fragmente derselben Person, wählt er eines davon selbstbewusst aus und liegt manchmal falsch. Genau das ist uns passiert.

Können zwei Datensätze ohne gemeinsamen Schlüssel wirklich derselben Person zugeordnet werden?

Ja. Ein Beispiel hilft, weil genau dieser Teil vielen am schwersten glaubhaft erscheint.

Angenommen, ein CRM enthält den Kontakt "Maria Alonso-Diaz", Unternehmen "Fernwood Supply", Stadt "Austin", ohne hinterlegte Telefonnummer. Ein separates Marketingtool enthält einen Lead aus einem Webinarformular: "M. Diaz", eine private Gmail-Adresse, Telefonnummer "(512) 555-0199", Unternehmen "Fernwood Supply", Stadt "Austin".

Kein einzelnes Feld stimmt exakt überein. Die E-Mail-Adressen sind verschieden. Die Namen sind unterschiedlich formatiert. Es gibt keine gemeinsame Kunden-ID. Eine deterministische Exact-Match-Regel würde daraus zwei verschiedene Personen machen und fortfahren.

Ein probabilistischer Matcher braucht keinen perfekten Schlüssel. Er erkennt, dass der Unternehmensname exakt übereinstimmt. Das ist ein starkes Signal, weil "Fernwood Supply" keine häufige Zeichenkette ist und daher eine geringe u-Wahrscheinlichkeit für eine zufällige Übereinstimmung hat. Er erkennt dieselbe Stadt. Er erkennt den Nachnamen "Diaz" und bewertet "Maria Alonso-Diaz" gegen "M. Diaz" mit einem Ähnlichkeitsverfahren, das den gemeinsamen Nachnamen und Anfangsbuchstaben belohnt, statt den fehlenden Vornamen zu bestrafen. Keines dieser Signale würde allein eine Verknüpfung rechtfertigen. Zusammen überschreiten sie in einer gewichteten Summe nach Fellegi-Sunter den Schwellenwert. Das Paar wird zu einer Entität aufgelöst, wobei beide Ursprungsdatensätze als Belege darunter erhalten bleiben.

Genau dieser Mechanismus fehlte unserem Agenten. Keine magische KI-Funktion. Es ist eine gewichtete Kombination gewöhnlicher, einzeln schwacher Signale, die vor mehr als fünfzig Jahren formalisiert wurde und noch immer unter einem großen Teil der Identitätsschicht arbeitet, die wir täglich nutzen.

Quellen

1. Fellegi, I.P. und Sunter, A.B. (1969). "A Theory for Record Linkage." Journal of the American Statistical Association, 64(328), 1183-1210.
2. Winkler, W.E. (2014). "Matching and Record Linkage." WIREs Computational Statistics.
3. Winkler, W.E. "Matching and Record Linkage" (Arbeitspapier rr93-8), US Census Bureau.
4. Wikipedia. "Record linkage" (Fellegi-Sunter-Modell, m/u-Wahrscheinlichkeiten, Entscheidungsbereiche).
5. Wikipedia. "Levenshtein distance."
6. Oracle Financial Crime and Compliance Management. "Jaro-Winkler matching guide."
7. West Penwith Local History Group. "Soundex - the True Story" (Patent von Odell und Russell, 1918).
8. Binette, O. und Steorts, R.C. "(Almost) All of Entity Resolution." arXiv:2008.04443.
9. Zingg. "Entity Resolution at Scale, Part 3: Blocking."
10. Aerospike. "Achieving the Perfect Golden Record with Graph Data."
11. US Department of the Treasury, Office of Foreign Assets Control. "A Framework for OFAC Compliance Commitments" (2019).
12. Fivetran. "Identity vs Entity Resolution in B2B Tech and Retail."
13. CX Today. "AI Hallucinations Start With Dirty Data: Governing Knowledge for RAG Agents."
14. Tilores. "What Is Entity Resolution? A Practical Guide for AI, KYC and Customer 360 (2026)."
15. Schmitdy Gadget. "Entity Resolution, Explained." YouTube.