Ability — Entity Resolution
Ability verwandelt unordentliche, überlappende Datensätze in einen sauberen, rückverfolgbaren Satz von Entitäten. Es arbeitet in fünf Phasen und zerstört niemals Quelldaten: Jeder zusammengeführte Datensatz behält Links zu den Originalen, aus denen er entstanden ist.
Record Linkage ist die mathematische Übereinstimmung (Passt Datensatz A zu Datensatz B?). Entity Resolution ist die gesamte Aufgabe: Abgleichen, Clustern von Übereinstimmungen zu Entitäten, Bewertung der Konfidenz und Aufbewahrung der Provenienz. Führen Sie die gesamte Aufgabe aus.
Vor Beginn: Der Abgleichs-Check
Unklare Anfragen sind normal. Lesen Sie Tippfehler und Abkürzungen als Absicht und kommentieren Sie niemals die Rechtschreibung. Geben Sie vor der eigentlichen Arbeit drei kurze Zeilen an, damit der Benutzer kostengünstig korrigieren kann:
GESAGT: <was der Benutzer wörtlich gefragt hat>
INTERPRETIERT: <das tatsächliche Problem, das gelöst werden soll>
ANGENOMMEN: <die wichtigste Annahme, die Sie treffen — stellen Sie höchstens eine Frage, wenn Sie wirklich blockiert sind>
Überspringen Sie dies bei kurzen Fragen; verwenden Sie es, wenn Sie Daten verarbeiten oder eine Pipeline entwerfen.
Die 5-stufige Pipeline
1. Profiling
Untersuchen Sie jedes Feld, bevor Sie etwas abgleichen. Berichten Sie pro Feld: Nullrate, Anzahl unterschiedlicher Werte, häufigste Werte, Formatmuster und Kodierungsprobleme (UTF-8 vs. Latin-1). Das Profiling zeigt Ihnen, welche Felder vertrauenswürdig genug sind, um darauf abzugleichen, und welche Werte so häufig sind (z. B. "Schmidt", "Hauptstraße 19"), dass eine Übereinstimmung wenig bedeutet.
2. Standardisierung
Normalisieren Sie vor dem Vergleich, sonst sind die Bewertungen falsch: Kleinschreibung, Interpunktion entfernen, Abkürzungen erweitern (Str. → Straße), Namen in Bestandteile parsen, Telefonnummern auf Ziffern normalisieren, Firmenzusätze normalisieren (GmbH, AG, Ltd.) und Adressen standardisieren (Postverifikation, wo verfügbar).
Unordentliche echte Daten erfordern fast immer auch:
- Nickname-Tabelle (Bob/Robert, Peggy/Margaret, Sascha/Alexander, Trisch/Patricia) und Initialen ("J.") werden als kompatibel mit jedem Namen betrachtet, der mit diesem Buchstaben beginnt.
- Vertauschte Namensfelder — vergleichen Sie auch Vorname↔Nachname vertauscht.
- Mehrdeutige Daten — "04.05.1990" könnte der 4. Mai oder der 5. April sein. Behalten Sie beide Lesarten und behandeln Sie eine Vertauschung von Tag/Monat als partielle Übereinstimmung, nicht als Konflikt.
3. Blocking
Jeden Datensatz mit jedem anderen zu vergleichen ist N² — 1 Million Datensätze bedeuten etwa 500 Milliarden Paare. Blocking vergleicht nur Datensätze, die einen Schlüssel gemeinsam haben. Verwenden Sie mehrere Durchläufe mit unterschiedlichen Schlüsseln, damit ein Tippfehler in einem Feld keine echte Übereinstimmung verbirgt:
- Phonetischer Nachname (Soundex / NYSIIS) + Geburtsjahr
- Postleitzahl-Präfix + Hausnummer
- Letzte 4 einer ID + PLZ
- Telefon oder E-Mail
- Für textlastige Daten: MinHash LSH auf Tokenmengen, oder Embeddings + Nächste-Nachbarn-Suche (FAISS/HNSW)
Messen Sie es:
- Reduktionsrate = 1 − (verglichene Paare ÷ alle möglichen Paare) — Ziel > 99 %
- Paar-Vollständigkeit = echte Übereinstimmungen, die in einem Block landen ÷ alle echten Übereinstimmungen — Ziel ≥ 95 %
4. Bewertung — die 3-stufige Kaskade
Führen Sie zuerst die günstigen, sicheren Prüfungen durch und die teuren nur dort, wo nötig.
- Deterministisch: eine zuverlässige eindeutige ID stimmt überein (Personalausweis, Steuer-ID, Kontonummer, verifizierte E-Mail) → Übereinstimmung.
- Fuzzy: keine ID-Übereinstimmung → Felder mit dem richtigen Algorithmus pro Feld vergleichen (siehe Tabelle) und mit Fellegi-Sunter-Gewichten kombinieren.
- Maschinelles Lernen / menschliche Überprüfung: immer noch mehrdeutig → ein Klassifikator (z. B. logistische Regression auf den Feldähnlichkeitsmerkmalen), wenn beschriftete Daten vorhanden sind, andernfalls an eine menschliche Prüfwarteschlange weiterleiten.
| Feldtyp | Verwendung |
|---|---|
| Personennamen | Jaro-Winkler (belohnt übereinstimmende Präfixe) plus Nickname-Listen |
| Firmennamen | Token-Sort-Verhältnis (Wortreihenfolge spielt keine Rolle) nach Suffix-Bereinigung |
| Adressen | Levenshtein nach Standardisierung; Haus- und Wohnungsnummern müssen exakt übereinstimmen |
| IDs, Telefon, E-Mail | Exakt nach Normalisierung |
| Langer Text | Jaccard / Cosinus auf Tokens |
Fellegi-Sunter kurz gefasst — für jedes Feld k:
- m = P(Feld stimmt überein | Datensätze stimmen wirklich überein) — wie zuverlässig das Feld ist
- u = P(Feld stimmt überein | Datensätze stimmen nicht überein) — wie oft es zufällig übereinstimmt
- Übereinstimmungsgewicht = log2(m/u); Nichtübereinstimmungsgewicht = log2((1−m)/(1−u))
- Gesamtpunktzahl = Summe der Gewichte für das Ergebnis jedes Feldes
Seltene Werte liefern mehr Evidenz: Übereinstimmung bei "Mustermann" (winziges u) ist weitaus stärker als Übereinstimmung bei „Schmidt". Verwenden Sie wertspezifisches u, wo möglich. In der Praxis: ein seltener vollständiger Name plus ein exaktes Geburtsdatum ist ein starkes Indiz, selbst wenn Adresse, Telefon und E-Mail alle geändert haben (die Person ist umgezogen); ein gebräuchlicher Name plus Geburtsdatum ist es nicht.
Verwenden Sie zum Bewerten von Paaren scripts/fs_score.py anstatt von Hand zu rechnen — es wendet
die Gewichte an, wandelt die Punktzahl in eine Übereinstimmungswahrscheinlichkeit um (gegeben vorherige
Wahrscheinlichkeiten) und weist das Entscheidungsband zu. Führen Sie python scripts/fs_score.py --help für die Verwendung aus.
Vollständige Formeln, das durchgerechnete Beispiel und die m/u-Schätzung (einschließlich EM) finden Sie in
references/methods.md; lesen Sie es, wenn der Benutzer die Mathematik möchte oder Gewichte anpassen muss.
Zwei Fallstricke, die die Punktzahl allein nicht erkennt:
- Haushalte. Zwillinge, Ehepartner und Mitbewohner teilen sich Nachname, Adresse und manchmal Geburtsdatum, daher kann ihre Punktzahl wie eine nahezu sichere Übereinstimmung aussehen. Wenn sich die Vornamen unterscheiden (und keine Spitznamen voneinander sind) und persönliche Kontaktdaten (E-Mail, Telefon) widersprechen, halten Sie sie getrennt oder senden Sie sie zur Überprüfung — was auch immer die Punktzahl sagt.
- Platzhalterwerte. Daten wie 2000-01-01 oder 1900-01-01, Telefone wie 555-0000 und E-Mails wie [email protected] sind Füllmaterial, keine Evidenz. Das Profiling (Stufe 1) sollte Werte kennzeichnen, die verdächtig häufig wiederkehren; geben Sie ihnen kein Gewicht.
Entscheidungsbänder (auf beschrifteten Daten abstimmen; dies sind Ausgangspunkte):
| Übereinstimmungswahrscheinlichkeit | Aktion |
|---|---|
| ≥ 0.95 | Automatische Übereinstimmung |
| 0.80 – 0.94 | Menschliche Prüfwarteschlange |
| < 0.80 | Keine Übereinstimmung |
5. Zusammenführen — Überlebensregeln und Golden Records
Gruppieren Sie übereinstimmende Paare zu Entitäten (verbundene Komponenten / Graph-Clustering — achten Sie auf
Ketten, in denen AB und BC, aber A≁C; teilen Sie diese zur Überprüfung auf). Bauen Sie für jede Entität einen
Golden Record, indem Sie jedes Feld nach einer festgelegten Regel auswählen:
- aktuellstes (neuester Zeitstempel) — für Adressen, Telefon
- vollständigstes (nicht null, am längsten) — für Namen, Beschreibungen
- vertrauenswürdigste Quelle (System-Ranking) — für IDs, gesetzliche Namen
Überschreiben oder löschen Sie niemals Originale. Speichern Sie: Golden-Record-ID → Liste der Quell-Datensatz-IDs, die Regel, die jedes Feld ausgewählt hat, und die Übereinstimmungspunktzahl, die sie verbunden hat.
Ergebnisse validieren
Bitten Sie um einen kleinen beschrifteten Datensatz (einige hundert Paare, markiert als Übereinstimmung/keine Übereinstimmung) oder helfen Sie beim Erstellen. Berichten Sie Präzision, Recall und F1 darauf sowie Reduktionsrate und Paar-Vollständigkeit für das Blocking. Schwellenwerte ohne Validierung sind Schätzungen — sagen Sie das, wenn es keinen beschrifteten Datensatz gibt.
Evidenz-Tags
Wenn Sie ein Ergebnis behaupten, sagen Sie, woher Sie es wissen:
- [DOK] — aus einer Spezifikation oder Dokumentation, nicht ausgeführt
- [AUSG] — in dieser Sitzung ausgeführt
- [BEST] — gegen beschriftete/Testdaten geprüft
Kontrollpunkt-Überprüfung
Bei langen Aufgaben (etwa alle fünf Arbeitsschritte, wenn der Benutzer einen Fehler meldet oder wenn er „Kontrollpunkt" oder „Traum" eingibt): unterbrechen Sie die Projektarbeit und überprüfen Sie kurz Ihre eigenen letzten Schritte. Listen Sie jeden Fehler oder jede Abweichung von den angegebenen Einschränkungen des Benutzers auf, seine Ursache und die Korrektur, die Sie ab sofort anwenden werden. Setzen Sie dann fort. Halten Sie die Überprüfung aus den Ergebnissen heraus — sie dient dem Gespräch, nicht den Daten oder Dokumenten des Benutzers.
Ausgabe für einen Abgleichs-Job
Beenden Sie einen abgeschlossenen Job mit:
ENTITÄTEN: <Eingabedatensätze> → <aufgelöste Entitäten> (<gefundene Duplikate>)
BÄNDER: auto <n> | prüfen <n> | keine Übereinstimmung <n>
QUALITÄT: Präzision <x> | Recall <x> | F1 <x> (oder „nicht validiert — kein beschrifteter Datensatz")
DATEIEN: <wo die Golden Records, Crosswalk und Prüfwarteschlange gespeichert wurden>
Datenschutz
Abgleiche betreffen oft personenbezogene Daten. Verarbeiten Sie sie lokal, fügen Sie keine Identifikatoren
in URLs oder externe Dienste ein, und schlagen Sie bei Verknüpfungen zwischen Organisationen
datenschutzschonende Verknüpfung vor (Bloom-Filter-Kodierung von Namen, verglichen mit Dice-Ähnlichkeit) —
Details in references/methods.md.