Starke Identifier
Kundennummer, Vertrags-ID, E-Mail-Adresse, HR-ID oder System-ID. Diese Signale sind oft belastbarer als Namen.
Praxis · Daten vorbereiten
Entity Resolution entscheidet, ob Namen, IDs, Aliasse oder Quellenhinweise dieselbe reale Entität meinen.
Wie erkennt man, dass zwei Namen, IDs oder Aliasse dasselbe meinen?
Ohne Identity-Logik fragmentiert Wissen: dieselbe Person, derselbe Kunde oder dasselbe System erscheinen mehrfach und Graphpfade werden falsch oder unvollständig.
Die wichtigsten Prinzipien dieses Themas auf einen Blick.
Identität braucht Regeln, Vertrauen, Review und belastbare Schreibweisen.
Aliasse, IDs, E-Mails, Systemnamen und Zeiträume können widersprüchliche Signale liefern.
Nicht jede Namensgleichheit bedeutet dieselbe Entität.
Manuelle Korrekturen müssen Vorrang vor automatischer Re-Extraktion haben.
Diese Fragen machen das Thema praktisch prüfbar. Hak sie ab – sie eignen sich als Einstieg für Workshops, Pilotvorhaben oder Architekturreviews.
Entity Resolution beantwortet eine scheinbar einfache Frage: Meinen diese zwei Hinweise dieselbe reale Sache? Im GraphRAG-Kontext ist das kritisch, weil der Graph sonst Wissen zerlegt oder falsch verbindet. Eine Person, Organisation, ein Vertrag oder System braucht eine stabile Identität, auch wenn Namen, Schreibweisen, IDs und Quellen voneinander abweichen.
Gute Identity-Logik kombiniert mehrere Signale. Ein einzelnes Signal reicht selten, außer es ist eine wirklich stabile ID aus einem führenden System.
Kundennummer, Vertrags-ID, E-Mail-Adresse, HR-ID oder System-ID. Diese Signale sind oft belastbarer als Namen.
Ähnliche Schreibweise, gleicher Ort, ähnliche Rolle oder gleicher Firmenname. Nützlich, aber selten allein beweisend.
Zeitraum, Quelle, Organisation, Projekt, Beziehung zu anderen Entitäten. Kontext entscheidet oft, ob ein Match plausibel ist.
Fachliche Korrektur, Review oder bestätigtes Matching. Diese Entscheidung sollte Vorrang vor automatischer Extraktion haben.
Entity Resolution verbindet Matching mit der Entscheidung, ob Entitäten zusammengeführt, getrennt oder bewusst getrennt gehalten werden.
Zwei Entitäten meinen dasselbe und werden zusammengeführt, etwa ACME Ltd. und ACME Limited mit derselben Kundennummer.
Eine Entität wurde fälschlich zusammengeführt und muss getrennt werden, etwa zwei verschiedene Personen mit gleichem Namen.
Zwei ähnliche Entitäten bleiben getrennt, weil der Nachweis fehlt oder das Risiko einer falschen Zusammenführung zu hoch ist.
Die Beispiele zeigen, warum Identity über String Matching hinausgeht.
Riskant
Michael Meier, M. Meier und michael.meier@example.com automatisch zusammenführen, nur weil der Name ähnlich ist.
Besser
E-Mail, Organisation, Rolle, Zeitraum und Quelle prüfen. Bei Unsicherheit als mögliche Übereinstimmung markieren.
Riskant
ACME, ACME GmbH und ACME Holding als dieselbe Firma behandeln.
Besser
Handelsregister-ID, Kundennummer, Land, Mutter-Tochter-Beziehung und Vertragspartei unterscheiden.
Riskant
CRM, Salesforce und Sales Cloud als drei getrennte Systeme speichern.
Besser
Synonyme und Produktnamen auf eine stabile Systemidentität mappen, aber Version oder Instanz als Eigenschaft behalten.
Starte mit Entitätstypen, bei denen falsche Zusammenführungen echten Schaden anrichten: Kunden, Personen, Verträge, Systeme oder regulatorische Begriffe. Definiere pro Typ, welche Identifier autoritativ sind, welche nur Hinweise sind und wann ein Mensch prüfen muss.
Viele Graphfehler sehen später wie Retrieval- oder LLM-Fehler aus. In Wahrheit ist oft die Identität im Graphen falsch.