Die Normalisierung von Firmennamen reicht für Fuzzy Matching nicht aus

Kurzfassung: Die Normalisierung von Firmennamen räumt nur Rechtsformen wie Ltd oder GmbH ab. Für gängige Geschäftsbegriffe wie Group, Holdings und Solutions leistet sie nichts – die tragen Bedeutung und lassen sich nicht wegnormalisieren. Standard-Fuzzy-Matcher behandeln jedes Token gleich und scheitern deshalb an Firmennamen. Gewichtetes Token-Matching mit Seltenheitsgewichten aus der Inverse Document Frequency, abgeleitet aus Ihren eigenen Daten, repariert Precision und Recall bei ein und demselben Schwellenwert.

Normalisierung vs. gewichtetes Token-Matching: der Überblick

Die Wahl steht zwischen dem Verlängern einer Normalisierungsliste und dem Gewichten von Token nach Seltenheit. Alle Kriterien unten stammen aus der ausführlichen Erklärung, die folgt; jede Formel und jedes Beispiel taucht im Fließtext wortgleich wieder auf.

Kriterium	Normalisierung von Rechtsformen	Gewichtetes Token-Matching (IDF)
Was damit abgedeckt wird	Rechtsformen: Ltd, Inc, Corp, Limited, Company, GmbH, SA, AG, Pty	Alle Token, gewichtet danach, wie selten sie im Korpus sind
Gängige Geschäftsbegriffe (Group, Holdings, Solutions)	Lassen sich nicht wegnormalisieren: Sie tragen fachliche Bedeutung	Werden automatisch heruntergewichtet, weil sie häufig sind
Wie über die Bedeutung eines Tokens entschieden wird	Von Hand gepflegte Referenz- und Ausnahmelisten	weight(token) = log(N / count(token)), aus den Daten abgeleitet
Anpassung je Domäne	Manuelle Regellisten pro Domäne und Sprachraum	Keine: Domänenwissen kommt automatisch aus den Daten
Paar A (Acme Group Ltd vs. Beta Group Ltd, sollte NICHT matchen)	False Positive bei Standard-Matchern (Jaro Winkler akzeptiert bei 85,7 %)	Wird bei rund 13 % abgelehnt
Paar B (Acme Group Ltd vs. Acme Holdings Ltd, sollte matchen)	Wird von Standard-Matchern häufig übersehen	Wird bei rund 84 % akzeptiert
Nettoeffekt bei einem Schwellenwert	Erzwungener Kompromiss: entweder Precision oder Recall, nicht beides	Repariert Precision und Recall beim selben Schwellenwert

Auf dieser Seite

• Normalisierung vs. gewichtetes Token-Matching: der Überblick
• Der Versuchsaufbau
• Warum gängige Geschäftsbegriffe Fuzzy Matching aushebeln
• Inverse Document Frequency: eine alte Idee an neuer Stelle
• So funktioniert gewichtetes Token-Matching
• Token-Häufigkeitsgewichte aus den eigenen Daten ableiten
• Was sich ändert, wenn das funktioniert
• Fazit
• Häufig gestellte Fragen

Jedes Entity-Resolution-Tool bringt eine Normalisierung von Rechtsformen mit. Keine davon beseitigt die False Positives, die entstehen, wenn über gängige Wörter wie Group, Holdings oder Solutions abgeglichen wird. Das sind bedeutungstragende Geschäftsbegriffe, die sich nicht wegnormalisieren lassen – die Lücke schließt erst eine Token-Gewichtung.

Standard-Fuzzy-Matching-Algorithmen scheitern an Datensätzen mit Firmennamen, und zwar aus einem strukturellen Grund: Sie behandeln jedes Token als gleichwertigen Beleg. Gewichtetes Token-Matching behebt das mit Seltenheitsgewichten aus der Inverse Document Frequency (IDF). Ohne Normalisierungslisten pro Token, ohne Feinjustierung pro Domäne.

Angenommen, Sie haben das Ltd/Limited-Problem im Griff und Ihre Rechtsformen normalisiert: Ihr Fuzzy-Matcher bewertet „Acme Group Ltd” und „Beta Group Ltd” (Paar A) trotzdem als ähnlicher als „Acme Group Ltd” und „Acme Holdings Ltd” (Paar B). Bei jedem gängigen Ähnlichkeitsalgorithmus (Jaccard, Cosine, Jaro, Jaro Winkler, Sorensen-Dice) schneidet Paar A besser ab als Paar B. Der Matcher tut genau das, wofür er entworfen wurde – und genau das ist das Problem.

Der Versuchsaufbau

Probieren Sie es mit Ihrem bevorzugten Fuzzy-Matching-Algorithmus aus. Nehmen Sie zwei Paare von Firmennamen:

• Paar A: Acme Group Ltd vs. Beta Group Ltd
• Paar B: Acme Group Ltd vs. Acme Holdings Ltd

Paar A sind zwei nicht verwandte Unternehmen. Paar B ist plausibel dieselbe Gruppe, womöglich dieselbe Firma. Paar B sollte höher bewertet werden. Was jeder gängige Fuzzy-Matcher tatsächlich sagt, steht hier – bei einer Match-Schwelle von 80 % Ähnlichkeit, Distanz ≤ 3, gleiche phonetische Codes. Zellen 🟢 über der Schwelle, 🔴 unter der Schwelle:

Algorithmus	Paar A: sollte NICHT matchen	Paar B: sollte matchen	Was schiefgeht
Cosine (Zeichen-n-Gramm)	🔴 69,2 %	🔴 48,5 %	🔴 Recall-Problem: übersieht den echten Match (Paar B)
Jaccard (Zeichen-n-Gramm)	🔴 52,9 %	🔴 31,8 %	↑
Sorensen-Dice	🔴 69,2 %	🔴 48,3 %	↑
Levenshtein-Distanz	🔴 4	🔴 8	↑
Kölner Phonetik	🔴 unterschiedliche Kodierung	🔴 unterschiedliche Kodierung	↑
Jaro	🟢 85,7 % ⚠	🔴 70,1 %	🔴 Beide Probleme: akzeptiert Paar A (False Positive) UND übersieht Paar B
Jaro Winkler	🟢 85,7 % ⚠	🟢 82,1 %	🔴 Precision-Problem: akzeptiert Paar A, obwohl es das nicht sollte
Gewichteter Token-Matcher	🔴 ~13 %	🟢 ~84 %	🟢 Beides richtig

⚠ = Der Matcher meldete einen Match, wo keiner sein dürfte (False Positive beim nicht verwandten Paar).

Prüfen Sie diese Zahlen selbst im kostenlosen Fuzzy-Matching-Vergleichstool von Tilores: Paar A und Paar B. Die Zeile zum gewichteten Token-Matcher verwendet plausible, illustrative Token-Häufigkeitsgewichte.

Es gibt keinen Schwellenwert, der beides löst. Senken Sie die Schwelle, um Paar B einzufangen, akzeptieren Sie auch Paar A als False Positive. Heben Sie sie an, um Paar A abzuweisen, verlieren Sie Paar B. Mit diesen Algorithmen entscheiden Sie sich zwischen schlechter Precision (falsche Übereinstimmungen) und schlechtem Recall (übersehene Übereinstimmungen) – und zwar genau bei der Art von Datensätzen, die Entity Matching eigentlich abdecken soll.

Nur der gewichtete Token-Matcher bekommt beides richtig. In Paar B leistet Acme die eigentliche Arbeit; Group und Ltd tragen in Paar A fast nichts bei. Die 80-%-Schwelle liegt sauber zwischen den beiden Werten: Paar A wird bei 13 % abgelehnt, Paar B bei 84 % akzeptiert. Beide Entscheidungen korrekt, mit Luft nach beiden Seiten.

Die Standard-Matcher sind nicht kaputt. Jaccard, Dice, Cosine und Jaro Winkler tun exakt das, wofür sie definiert sind: gemeinsame Zeichen und Token zählen oder messen – und dabei ignorieren, welche Zeichen und Token das eigentlich sind. Und bei Firmennamen, oder bei jedem kurzen natürlichsprachlichen Identifikator, ist genau das die falsche Zählweise.

Am schärfsten stellt sich das bei Firmennamen, wo verlässliche Adressen häufig von vornherein fehlen. Dasselbe Problem gibt es bei Personennamen. Smith und Garcia verdecken das Matching-Signal seltener Namen, die jemanden tatsächlich identifizieren. Bei Adressen trägt eine Hausnummer plus ein seltener Straßenname das Signal, während Street, Avenue oder Road nichts Eindeutiges beisteuern.

Wie also bekommt der gewichtete Token-Matcher beide Paare richtig? Er fängt damit an zu wissen, welche Wörter überhaupt zählen.

Warum gängige Geschäftsbegriffe Fuzzy Matching aushebeln

Ziehen Sie sich eine Million Firmennamen aus einem beliebigen Register und tokenisieren Sie. Die Spitze der Häufigkeitsverteilung zerfällt in zwei Schichten – und die sind unterschiedlich schwer zu handhaben.

Die einfachere Hälfte (bei westlichen Unternehmen): Rechtsformen. Ltd, Inc, Corp, Limited, Company, GmbH, SA, AG, Pty. Die bekommen Sie mit einer Referenzliste bekannter Rechtsformvarianten und einem Normalisierungsschritt in den Griff. Die meisten Entity-Resolution-Tools haben das eingebaut; OpenSanctions veröffentlicht offene Referenzdaten zur Nachnutzung; kommerzielle Werkzeuge bringen fertige Listen mit. Für westliche Rechtsformen ist das weitgehend gelöst.

Bei chinesischen, russischen, transliterierten oder nicht lateinisch geschriebenen Firmennamen wird es schnell kompliziert. Der Ansatz über Referenzlisten stößt an seine Grenzen, sobald sich Transliterationsvarianten, gemischte Schriftsysteme und regionsspezifische Namenszusätze häufen. Das ist ein eigener Artikel. Für den Rest hier nehmen wir an, die einfachen Fälle sind erledigt, und schauen auf das, was übrig bleibt.

Die schwierigere Hälfte: Token aus der Geschäftssprache, die keine Rechtsformen sind. Group, Holdings, International, Global, Services, Solutions, Systems, Technologies, Industries, Consulting, Management, Capital, Digital, Cloud und so weiter. Jedes davon taucht in 5–25 % der Datensätze auf (das heißt, in nahezu 90 % der Datensätze eines beliebigen Bestands steht eines dieser Wörter). Es sind echte, bedeutungstragende Wörter. Manchmal unterscheiden sie ein Unternehmen (eine „Solutions”-Tochter ist etwas anderes als eine „Industries”-Tochter), manchmal nicht („Acme Group” wurde zu „Acme Holdings” umbenannt). Wegnormalisieren können Sie sie nicht. Sie tragen fachliche Bedeutung. Aber die Wahrscheinlichkeit, dass zwei Datensätze eines davon teilen, liegt kaum über dem Zufall.

Genau hier zerbricht naive Token-Mengen-Ähnlichkeit beim Abgleich von Firmennamen. Ein Matcher, der Solutions (in 18 % der Datensätze) nicht von Petrochemical (in 0,01 %) unterscheidet, hält „Acme Solutions Ltd” und „Beta Solutions Ltd” für einen starken Match-Kandidaten (beide teilen Solutions und Ltd) – obwohl der Unterschied Acme/Beta das Einzige ist, was diese beiden überhaupt als verschiedene Unternehmen ausweist.

Dasselbe zeigt sich bei Personennamen. Smith, Garcia, Wang und Lee decken zusammen etwa 15 % der Datensätze in ihren jeweiligen Populationen ab. Dass zwei Datensätze in einem US-Bestand beide Smith enthalten, sagt fast nichts. Dass zwei Datensätze im selben Bestand beide Petrov enthalten, sagt sehr viel. Und bei Adressen: Main Street und High Street gibt es in Tausenden von Städten; eine Hausnummer plus Magnolia Lane gehört nur Ihnen.

Die Lösung ist kein besserer String-Ähnlichkeitsalgorithmus. Edit-Distanz, Levenshtein, Jaro-Winkler – sie alle haben dasselbe Problem, sobald man sie auf kurze Identifikatoren anwendet. Und es ist auch keine längere Normalisierungsliste. Solutions, Holdings und Industries sind keine Kandidaten für Normalisierung. Es sind bedeutungstragende Token, die zufällig häufig sind. Die Lösung besteht darin, dem Matcher eine Information zu geben, die er bislang nicht hat: ein Gespür dafür, welche Token Information tragen.

Inverse Document Frequency: eine alte Idee an neuer Stelle

Suchmaschinen wissen das seit fünfzig Jahren. Sie nutzen TF-IDF (Term Frequency × Inverse Document Frequency): Die erste Hälfte zählt, wie oft ein Wort in einem bestimmten Dokument vorkommt; die zweite Hälfte rechnet ab, wie häufig das Wort im gesamten Korpus ist. Zusammen messen sie, wie unterscheidungskräftig ein Wort für dieses Dokument ist. Der Belegwert eines Tokens ist umgekehrt proportional dazu, wie oft es auftaucht.

Die IDF-Hälfte:

weight(token) = log(N / count(token))

N ist die Gesamtzahl der Datensätze, count(token) die Zahl derjenigen, die das Token enthalten. Häufige Token bekommen Gewichte nahe null. Seltene Token bekommen hohe Gewichte.

Nichts Exotisches. Dieselbe Intuition, die jede Suchmaschine verwendet.

Ungewöhnlich ist, IDF für Entity Matching einzusetzen. Die Suche nutzt sie, um Dokumente gegen eine Anfrage zu ranken: Welches Dokument passt am besten zu diesen Wörtern? Entity Matching nutzt sie für eine verwandte, aber andere Frage: Beziehen sich diese beiden kurzen Datensätze auf dieselbe Sache? Gleiche Idee, andere Anwendung.

Sie nehmen die Token beider Datensätze, gewichten jedes mit seinem IDF-Wert – und schon hat Ihr Matcher die Information, die ihm vorher fehlte. Acme sollte um Größenordnungen mehr zählen als Solutions, Holdings oder Group, wenn man misst, wie stark sich zwei Datensätze überschneiden.

Und entscheidend: Sie brauchen dafür keine Normalisierungsliste pro Token. Die Gewichte kommen aus den Daten selbst. Dieselbe Technik funktioniert über Domänen hinweg (Firmennamen, Personennamen, Produktbezeichnungen, Adressen), weil die IDF-Ableitung die Unterscheidung selten/häufig aus genau dem Korpus zieht, auf den Sie sie ansetzen. Domänenwissen kommt automatisch aus den Daten. Keine Feinjustierung pro Domäne, keine manuellen Regellisten, keine von Fachleuten gepflegten Ausnahmedateien.

Wenn Sie den Ratio-Matcher kennen (übereinstimmende Token / eindeutige Token, oder irgendeine gleichwertige Mengenähnlichkeit mit einheitlichen Gewichten), ist das der natürliche nächste Schritt. Gleiche Idee, nur mit Seltenheit als Gewichtungsprinzip statt Gleichbehandlung aller Token.

Wie sich Precision- und Recall-Messungen anwenden lassen, sobald Ihr Matcher läuft, vertieft Precision und Recall in der Entity (Identity) Resolution im Tilores-Blog.

So funktioniert gewichtetes Token-Matching

Die Bewertungsformel:

matching_score = matching_token_weights / all_token_weights

Dabei gilt:

• matching_token_weights = die kombinierten IDF-Gewichte der Token, die zwischen den beiden Datensätzen übereinstimmen. Unscharfe Treffer (Tippfehler wie Aleksandr vs. Aleksander) steuern ihr Gewicht skaliert mit dem String-Ähnlichkeitswert bei, halbe Treffer zählen also halb.
• all_token_weights = die kombinierten IDF-Gewichte aller Token über beide Datensätze hinweg.

Was Sie damit berechnen: den Anteil des informationstragenden Gehalts, den die beiden Datensätze teilen, statt des Anteils der Token. Hängen Sie einen Schwellenwert an diesen Wert (sagen wir 80 %), und Sie haben einen Matcher, der nicht mehr auf die Group/Holdings/Solutions-Falle hereinfällt.

Selbst ausgereifte probabilistische Linkage-Werkzeuge wie Splink sagen ausdrücklich, dass sie nicht für den einspaltigen „Bag of Words”-Fall gedacht sind – eine Tabelle mit nur einer Spalte Firmenname, sonst nichts. Genau diesen Fall deckt diese Technik ab, und er macht einen beachtlichen Teil der realen Entity-Matching-Arbeit aus, der oft unterversorgt bleibt.

Ein paar Details, die man kennen sollte:

• Unscharfe Treffer skalieren proportional. Zwei Datensätze mit Aleksandr und Aleksander (Tippfehler in einem seltenen Token) sollten nicht genauso bewertet werden wie ein exakter Treffer. Null sollten sie aber auch nicht bekommen. Den Beitrag der Schnittmenge mit dem String-Ähnlichkeitswert zu gewichten, löst das ganz natürlich.
• Die Position kann ein schwaches Indiz liefern. Steht dasselbe Wort in den beiden Datensätzen an sehr unterschiedlichen Positionen, ist das ein kleines Signal dafür, dass die Datensätze Unterschiedliches meinen. Ein moderater Positionsabstands-Abschlag deckt das ab; wie scharf er ausfällt, hängt von der Domäne ab.

Ich beschreibe hier die allgemeine Struktur. Mehrere konkrete Bewertungsfunktionen passen hinein. Worauf es ankommt, ist die strukturelle Änderung: weg von „alle Token gleich”, hin zu „Token nach Seltenheit gewichtet”.

Wenn Sie verstehen wollen, wie sich das in eine vollständige Matching-Pipeline einfügt: Wie Sie Ihr eigenes Identity-Resolution-System bauen geht den kompletten Komponenten-Stack durch.

Token-Häufigkeitsgewichte aus den eigenen Daten ableiten

Eine wichtige Frage haben wir übergangen: Woher kommt eigentlich count(token)?

Sie haben zwei Möglichkeiten. Eine generische Gewichtsliste verwenden (also eine englische IDF von der Stange) – oder Ihre eigene aus Ihren Daten ableiten.

Generisch ist einfacher. Und auf subtile Weise falsch. Industries ist im allgemeinen Englisch selten und bekäme ein hohes Gewicht. In einem B2B-Lieferantenbestand steht Industries überall. Petrochemical ist im allgemeinen Englisch selten, könnte in Ihrem Bestand aber häufig sein. Generische Gewichte gewichten genau die Token falsch, die für Ihre Domäne charakteristisch sind. Also genau die, auf die es am meisten ankommt.

Die Gewichte aus dem eigenen Datenbestand abzuleiten, ist der richtige Weg. Schicken Sie Ihr Korpus durch dieselbe Transformationskette, die auch das Matching zur Laufzeit verwendet, zählen Sie die Token-Häufigkeiten und berechnen Sie die IDF.

Der Teil „dieselbe Transformationskette” ist nicht trivial. Wenn Ihr Tokenizer bei der Gewichtserzeugung diakritische Zeichen entfernt und der Tokenizer zur Laufzeit nicht, dann zieht der Matcher für Token X ein Gewicht, das gegen einen anderen Splitter berechnet wurde – und übersieht das Token entweder (weil die Form nicht in der Gewichtsliste steht) oder bewertet es falsch. Diese Diskrepanz bleibt still; nichts stürzt ab; das Matching arbeitet einfach schlechter, als es könnte.

Die Abhilfe ist organisatorischer Natur. Legen Sie die Transformationskette fest. Verwenden Sie dieselbe Kette für beide Zwecke. Erzeugen Sie die Gewichte neu, wenn sich der Datenbestand nennenswert verschiebt.

Was sich ändert, wenn das funktioniert

Die False Positives gehen zurück, und der Recall bleibt beim selben Schwellenwert stabil. Die Fachbereiche hören auf, jene Ausnahmelisten zu pflegen, die sie gegen die offensichtlich falschen Treffer der Token-Mengen-Verfahren aufgebaut haben.

Wo das am meisten zählt: beim Abgleich von Fracht- oder Zolldatensätzen (oft per OCR aus handschriftlichen Formularen gelesen) gegen saubere Firmenregister, wo das einzige gemeinsame Signal ein Firmenname ist, der von überflüssigen Token, Transliterationsvarianten oder in das Namensfeld gerutschten Adressfragmenten durchsetzt ist. Adressbasiertes Matching hat dort nichts, womit es arbeiten könnte. Token-Mengen-Verfahren ersaufen im Rauschen. Gewichtetes Matching ist das, was die beiden Seiten am Ende zusammenbringt.

Der Ansatz verallgemeinert sich. Personennamen: Aleksandr Petrov durch einen Kundenbestand voller Smiths und Garcias zu matchen, wird handhabbar statt zur Tuning-Übung. Adressen: „12 Old Mill Lane, Petersfield” findet „12 Old Mill Ln, Petersfield”, ohne in jedem Datensatz zu ertrinken, der Lane oder Street oder irgendeine Postkürzel-Variante enthält. Verknüpfung von Antragstellern bei Betrugsfällen, Kundendeduplizierung über Systeme hinweg, sprachübergreifender Identifikator-Abgleich. Überall dort, wo kurze Token das Signal tragen und die meisten davon Rauschen sind, stellt sich dasselbe Problem – und wird auf dieselbe Weise gelöst. Das Domänenwissen steckt in den Daten.

Das hat seinen Preis. Sie pflegen die Gewichte, justieren den Schwellenwert und halten die Transformationskette über beide Stufen hinweg deckungsgleich. Die meisten Teams, die Entity Resolution im großen Maßstab betreiben, bringen diese Disziplin ohnehin mit. Gewichtetes Matching gibt ihnen nur ein Werkzeug, das sie auch nutzt.

Wenn Sie Schwellenwerte gegen Firmennamen-Bestände von Hand justieren, Rechtsformen normalisieren und Ausnahmeregeln für Treffer auf Solutions, Holdings und Group schreiben: Es geht besser.

Fazit

• Standard-Fuzzy-Matching (Jaccard, Cosine, Jaro, Jaro Winkler, Levenshtein) scheitert an Datensätzen mit Firmennamen, weil alle Token als gleichwertiger Beleg zählen.
• Gängige Geschäftsbegriffe wie Group, Holdings oder Solutions sind keine Kandidaten für Normalisierung. Sie tragen fachliche Bedeutung, auch wenn sie fürs Matching Rauschen sind.
• Token-Gewichtung nach IDF-Art trennt seltene und aussagekräftige Token von häufigen und rauschhaften. Das repariert Precision (False Positives) und Recall (übersehene Treffer) beim selben Schwellenwert.
• Im großen Maßstab muss auch die Indizierung Token nach Gewicht in Klassen einteilen: seltene Token einzeln indiziert, mittelgewichtige paarweise, häufige aus dem Index entfernt.
• Die Gewichte leiten sich automatisch aus Ihrem Datenbestand ab, durchlaufen dieselbe Transformationskette wie das Matching zur Laufzeit. Dieselbe Technik funktioniert bei Firmennamen, Personennamen, Adressen, Produktbezeichnungen – bei allem. Domänenwissen kommt aus den Daten; manuelle Regellisten oder Feinjustierung pro Domäne sind nicht nötig.

So geht der Matcher von Tilores in seiner Entity-Resolution-Pipeline vor (technische Dokumentation). Die oben beschriebene Ausrichtung der Transformationskette ist als eigener Gewichtserzeugungsschritt umgesetzt, der Ihren Datenbestand durch die Laufzeit-Transformationskette schickt, damit die Gewichte konsistent berechnet werden. Gewichte, Kategoriegrenzen und Transformationskette sind explizite Konfiguration – keine vorjustierten Einstellungen, die Sie weder sehen noch anpassen können.

Sehen Sie, was aufgelöste Entitätsdaten für Ihr Geschäft und für Ihre KI leisten.

An Ihren eigenen Daten ausprobieren: Demo buchen für einen Durchgang mit Ihren Datensätzen, oder Evaluation Build holen, um aufgelöste Entitätsdaten lokal zu testen. Die technischen Details stehen in der Dokumentation zum gewichteten Token-Matcher.

Weiterlesen

• Precision und Recall in der Entity (Identity) Resolution behandelt, wie man Matching-Qualität misst und einen Konfidenz-Schwellenwert für automatisches Zusammenführen vs. manuelle Prüfung setzt.
• Was ist Entity Resolution erklärt die Grundlagen des Verknüpfens und Deduplizierens von Datensätzen über Systeme hinweg – für KYC, Customer 360 und KI-Anwendungsfälle.
• Wie Sie Ihr eigenes Identity-Resolution-System bauen geht die Komponenten einer vollständigen Matching-Pipeline durch.
• Tilores-Funktionen: wie Echtzeit-Matching, Konfidenzbewertung und Transformationskette im Produktivbetrieb zusammenspielen.

FAQ

Warum scheitert die Normalisierung von Firmennamen beim Fuzzy Matching?

Die Normalisierung räumt nur Rechtsformen wie Ltd, Inc und GmbH ab. Für gängige Token der Geschäftssprache wie Group, Holdings, International, Services und Solutions leistet sie nichts – die kommen jeweils in 5 bis 25 Prozent der Datensätze vor und tragen echte Bedeutung, lassen sich also nicht wegnormalisieren. Standard-Fuzzy-Matcher behandeln jedes Token als gleichwertigen Beleg, weshalb zwei nicht verwandte Unternehmen, die Group und Ltd teilen, höher bewertet werden können als zwei Datensätze, die plausibel dasselbe Unternehmen sind. Die Lösung ist, jedes Token nach seiner Seltenheit zu gewichten, statt die Normalisierungsliste zu verlängern.

Was ist gewichtetes Token-Matching und wie funktioniert es?

Gewichtetes Token-Matching bewertet ein Datensatzpaar als matching_token_weights / all_token_weights, wobei jedes Token mit seiner Inverse Document Frequency gewichtet wird: weight(token) = log(N / count(token)). Häufige Token bekommen Gewichte nahe null, seltene Token hohe Gewichte. Ein seltenes Token wie Acme zählt damit um Größenordnungen mehr als Group, Holdings oder Solutions, wenn gemessen wird, wie stark sich zwei Datensätze überschneiden. Unscharfe Treffer steuern ihr Gewicht skaliert mit dem String-Ähnlichkeitswert bei, halbe Treffer zählen also halb.

Was ist IDF, und warum sollte man sie für Entity Matching einsetzen?

IDF steht für Inverse Document Frequency, die Seltenheitshälfte des TF-IDF-Maßes, das Suchmaschinen seit fünfzig Jahren verwenden. Der Belegwert eines Tokens ist umgekehrt proportional dazu, wie oft es im Korpus vorkommt. Die Suche nutzt IDF, um Dokumente gegen eine Anfrage zu ranken; Entity Matching nutzt sie für die verwandte Frage, ob sich zwei kurze Datensätze auf dieselbe Sache beziehen. Die Token eines Datensatzes nach IDF zu gewichten, gibt dem Matcher eine Information, die ihm sonst fehlt: ein Gespür dafür, welche Token tatsächlich identifizierendes Signal tragen.

Brauche ich eine Normalisierungsliste pro Token, um gewichtetes Token-Matching einzusetzen?

Nein. Die Gewichte kommen aus den Daten selbst. Die IDF-Ableitung zieht die Unterscheidung selten/häufig aus genau dem Korpus, auf den Sie sie ansetzen. Domänenwissen kommt also automatisch aus den Daten – ohne Feinjustierung pro Domäne, ohne manuelle Regellisten und ohne von Fachleuten gepflegte Ausnahmedateien. Dieselbe Technik funktioniert bei Firmennamen, Personennamen, Produktbezeichnungen und Adressen.

Sollte ich IDF-Gewichte aus meinen eigenen Daten ableiten oder eine generische Liste verwenden?

Leiten Sie sie aus Ihrem eigenen Datenbestand ab. Eine generische englische IDF-Liste gewichtet genau die Token falsch, die für Ihre Domäne charakteristisch sind: Industries ist im allgemeinen Englisch selten, in einem B2B-Lieferantenbestand aber allgegenwärtig, und Petrochemical kann in Ihren Daten häufig sein. Schicken Sie Ihr Korpus durch dieselbe Transformationskette, die auch das Matching zur Laufzeit verwendet, zählen Sie die Token-Häufigkeiten und berechnen Sie die IDF. Legen Sie diese Transformationskette fest, damit Gewichtserzeugung und Laufzeit-Matching übereinstimmen, und erzeugen Sie die Gewichte neu, wenn sich der Datenbestand nennenswert verschiebt.