Entity Resolution im Enterprise-Maßstab: Einblick in einen Unternehmensgraphen mit 110 Millionen Datensätzen

Die meisten Entity-Resolution-Demos sehen mit ein paar Tausend sauberen Datensätzen hervorragend aus. Entity Resolution im Enterprise-Umfeld ist ein völlig anderes Problem. Im Enterprise-Maßstab lösen Sie Hunderte Millionen Datensätze auf, aus Quellen, die nie dafür gedacht waren, miteinander übereinzustimmen — während das System live, schnell und prüfbar bleibt und der Rest Ihrer Datenplattform ringsherum weiterläuft.

Dieser Artikel betrachtet, was Entity Resolution im Enterprise-Maßstab tatsächlich erfordert, und nimmt dafür ein reales Enterprise-Deployment als Referenz: wie Exiger einen Unternehmens-Entitätsgraphen mit 60 Millionen Clustern aufgebaut hat — aus 110 Millionen Quelldatensätzen, als Grundlage für seine KI-gestützte Supply-Chain-Intelligence. Die vollständige Kundengeschichte steht auf der Fallstudienseite; hier geht es um die Lehren für jedes Unternehmen, das Entity-Resolution-Software bewertet.

Was „Enterprise-Maßstab” tatsächlich bedeutet

Wenn Teams sagen, sie brauchen Entity Resolution, meinen sie meist Matching. Im Enterprise-Maßstab ist Matching nur eine von sechs Anforderungen — und selten die, die zuerst bricht:

Volumen — Hunderte Millionen Datensätze, mit Clustergrößen, die in die Tausende gehen können. Naives O(n²)-Vergleichen ist hier unbrauchbar; ein Enterprise-System braucht Blocking- und Graphstrategien, die mit wachsenden Datenmengen standhalten.
Aufnahme in Echtzeit — neue Datensätze müssen sich fortlaufend in den Graphen auflösen, sobald sie eintreffen, nicht in einem nächtlichen Batch. Ein statisches, rein batchbasiertes System kommt für die meisten Enterprise-Workflows nicht infrage.
Genauigkeit auf beiden Achsen — hohe Precision ist leicht, wenn Sie Recall opfern. Enterprise-Datenqualität hängt davon ab, beides richtig zu machen, denn Under-Clustering füllt die Datenbank stillschweigend mit Duplikaten.
Erklärbarkeit — jede Auflösungsentscheidung muss nachvollziehbar sein: welche Datensätze übereinstimmten, über welche Attribute, nach welcher Regel. Enterprise-Software, die ihren Rechenweg nicht zeigen kann, ist ein Risiko für Compliance und Fehlersuche.
Anpassbare Regeln — Enterprise-Daten sind spezifisch. Ein änderbares, transparentes Regelsystem schlägt eine Blackbox, die Sie nicht anpassen können.
Passung zur Architektur — das System muss sich in die vorhandene Enterprise-Infrastruktur einfügen (Cloud, Data Warehouse, Streaming), ohne dass alles andere drumherum neu gebaut werden muss.

Fehlt auch nur einer dieser Punkte, scheitert ein Entity-Resolution-Werkzeug im Produktivbetrieb — selbst wenn es im Benchmark glänzt.

Der Beleg: 110 Mio. Datensätze, aufgelöst

Exiger ist ein Enterprise-Marktführer für Lieferkettenrisiken und Due Diligence, dem mehr als 150 Fortune-500-Unternehmen und über 60 US-Bundesbehörden vertrauen. Um Lieferketten verlässlich abzubilden, musste das Unternehmen zunächst eine trügerisch schwierige Frage im Enterprise-Maßstab beantworten: Welche Unternehmen sind tatsächlich in der Kette?

Gemeinsam mit Tilores löst Exiger heute auf:

110 Mio.+ Quelldatensätze aus mehr als 16 verschiedenen Datenquellen
zu 60 Mio. kanonischen Unternehmensclustern
mit einer vollständigen Erstladung in unter 24 Stunden
und Suchanfragen, die in unter 100 Millisekunden antworten, selbst unter paralleler Last
bei einer Steigerung des paarweisen F1-Scores um rund 30 Punkte gegenüber der bisherigen internen Baseline

Diese Kombination — Enterprise-Volumen, Auflösung in Echtzeit und ein messbarer Genauigkeitsgewinn — ist die Hürde, die Entity Resolution im Enterprise-Umfeld nehmen muss.

Warum Enterprise-Daten naives Matching brechen

Enterprise-Quellen decken ein weites Spektrum ab. An einem Ende stehen saubere, gut strukturierte Register für Rechtsträger, ideal für Matching mit hoher Konfidenz. Am anderen Ende stehen weltweite Fracht- und Zolldaten — ein Datenbestand von außerordentlichem Wert, um reale Handelsströme nachzuvollziehen, dessen Beschaffenheit aber widerspiegelt, wie er am Ursprungsort erfasst wird: Firmennamen können eingebettete Adressfragmente, zusätzliche Tokens, Transliterationsvarianten und fehlende Attribute enthalten.

Genau diese Spannbreite ist der Grund, warum sich klassisches Fuzzy Matching im Enterprise-Umfeld schwertut. Adressbasiertes Matching ist stark, wenn Adressen verlässlich sind — doch in Enterprise-Handelsdaten fehlt sehr oft eine verwertbare Adresse. Ausschlaggebend war für Exiger das tokengewichtete Matching, das seltene, aussagekräftige Tokens stärker gewichtet als häufige, dazu Konsistenzregeln, die einen Datensatz aus einem Cluster ausschließen, wenn ein festgelegtes Feld (etwa eine USt-IdNr.) widerspricht — auch dann, wenn andere Regeln ihn zugeordnet hätten.

„Die anderen Optionen hatten ihre Stärken — viele davon waren stark in adressbasierter Entity Resolution. Das Problem ist: Bei vielen unserer Entitäten haben wir schlicht keine Adresse. Das löst unser eigentliches Problem nicht, nämlich Datensätze verschiedener Unternehmen unabhängig von ihren Adressen zu gruppieren.” — Simon Baker, SVP of AI Products & Supply Chain Intelligence, Exiger

Selbst bauen oder kaufen im Enterprise-Maßstab

Der Reflex in vielen Unternehmen ist, Entity Resolution selbst zu bauen. Über die Kosten sollte man ehrlich sprechen. Eine produktionsreife Engine — Aufnahme, Transformation, Blocking, Matching, Entitätsgraph, Abfrage-API und Aktualisierungen in Echtzeit — bedeutet Jahre spezialisierter Arbeit. Und das Schwierigste ist nicht, Übereinstimmungen zu finden; es ist, Over-Clustering zu kontrollieren und dabei den Recall zu halten, während das Volumen wächst.

Selbst mit einem leistungsfähigen Anbieter brauchte Exiger fast neun Monate iterativer Entwicklungsarbeit bis zur Enterprise-Produktion, einschließlich einer Lösung für Cluster, die über 6.000 Datensätze hinauswuchsen — ein Problem, aus dem die cliquenbasierte Graphkompression hervorging, die heute jedem Tilores-Kunden zur Verfügung steht. Die Lehre für die meisten Unternehmen: Solange Entity Resolution nicht Ihr Produkt ist, verschafft der Kauf eines Systems, das Blocking, Echtzeit-Aktualisierungen und Erklärbarkeit bereits löst, Ihrem Team die Freiheit, auf einer sauberen Entitätsschicht aufzubauen, statt eine zu pflegen.

Eine Bewertungs-Checkliste für Entity Resolution im Enterprise-Umfeld

Wenn Sie Entity-Resolution-Software für das Enterprise-Umfeld vergleichen, testen Sie sie an Ihren schwierigsten Daten, nicht an einer sauberen Stichprobe:

Führen Sie einen echten Benchmark durch. Messen Sie Precision, Recall, F1 und Clusterreinheit an annotierter Ground Truth aus Ihren eigenen Quellen — die Schlagzeilenwerte von Anbietern lassen sich leicht schönen.
Testen Sie den unsauberen Rand, nicht die saubere Mitte. Das System, das bei adressreichen Daten gewinnt, kann bei genau den Datensätzen einbrechen, auf die es Ihnen ankommt.
Verlangen Sie Erklärbarkeit. Jede Übereinstimmung sollte die Attribute, Quelldatensätze und Regeln zurückgeben, die dahinterstehen.
Prüfen Sie das Echtzeitverhalten. Bestätigen Sie die Latenz für die Auflösung einzelner Datensätze unter Last — nicht nur den Batch-Durchsatz.
Bestätigen Sie die Passung zur Architektur. Das System sollte sich ohne Umbau in Ihren Cloud-, Warehouse- und Streaming-Stack einfügen.
Sehen Sie sich die Regeln an. Sie wollen ein transparentes, änderbares Regelsystem, keine Blackbox.

Entity Resolution im Enterprise-Umfeld ist kein Feature, das Sie einschalten — sie ist grundlegende Dateninfrastruktur, auf der alles Nachgelagerte aufbaut. Simon Baker formuliert es so: „Wenn Sie mit schlechten Eingangsdaten starten, kann am Ende Garbage in, Garbage out stehen. Viele Modelle profitieren von einem guten Entitätssystem früh in der Pipeline.”

Die ganze Geschichte: Lesen Sie die Fallstudie Exiger × Tilores oder sehen Sie, wie Tilores Supply Chain Intelligence im Enterprise-Maßstab ermöglicht.