Splink vs. Tilores: Ein reproduzierbarer Benchmark mit 1 Million Datensätzen

Kurzfassung: Auf 1.000.000 synthetischen Datensätzen mit 100.000 bekannten Duplikatpaaren erreichte Tilores einen F1-Wert von 0,9949 gegenüber 0,8867 bei Splink – ein Abstand von +10,8 Prozentpunkten, der fast vollständig auf den Recall zurückgeht (+19,4 Prozentpunkte). Beim reinen Batch-Durchsatz gewinnt Splink klar, und es bleibt kostenlos. Der wesentliche Unterschied ist architektonisch: Splink erzeugt eine einmalige Paarliste, während Tilores einen dauerhaften, abfragbaren Entitätsindex aufbaut, den Sie in Echtzeit durchsuchen können. Jede Zahl lässt sich aus dem veröffentlichten Repository reproduzieren.

Sehen Sie es auf Ihren Daten: Demo buchen, um Entity Resolution in Echtzeit auf Ihren eigenen Datensätzen durchzugehen, oder Tilores Studio kostenlos testen, um es lokal auszuprobieren.

Warum überhaupt Splink gegen Tilores benchmarken?

Benchmarks zur Entity Resolution tappen meist in eine von zwei Fallen: Sie laufen auf Spielzeugdatenbeständen (10.000 Datensätze, Abgleich über ein einziges Feld) oder sie vergleichen Werkzeuge, die gar nicht wirklich konkurrieren. Die Frage Splink vs. Tilores stellen Praktiker dagegen tatsächlich: Ich nutze Splink zur Deduplizierung. Ab wann – wenn überhaupt – lohnt sich ein Wechsel?

Splink ist die glaubwürdigste heute verfügbare Open-Source-Bibliothek für Entity Resolution: entwickelt im britischen Justizministerium, probabilistisch, erklärbar und kostenlos. (Das weitere Feld behandeln wir in unserer Übersicht der Open-Source-Bibliotheken für Entity Resolution.) Tilores ist eine für den Produktivbetrieb gebaute Echtzeit-API für Entity Resolution. Unser Ziel war nicht, einen Sieger auszurufen, sondern herauszufinden, wo die Unterschiede tatsächlich liegen – und zwar sorgfältig genug, dass andere unsere Arbeit überprüfen können. Wir haben außerdem aufgeschrieben, wie wir einen Benchmark gebaut haben, dem wir selbst vertrauen.

Sämtlicher Benchmark-Code, alle Regelkonfigurationen und die vorberechneten Ergebnisse sind hier veröffentlicht: github.com/tilotech/tilores-splink-benchmark.

Wie war der Benchmark aufgebaut?

Wir haben mit der Faker-Bibliothek (Locale en_GB, Seed 42) einen synthetischen Datenbestand mit 1.000.000 Datensätzen erzeugt: 900.000 eindeutige Entitäten plus 100.000 absichtlich verfälschte Duplikate. Bei jedem Duplikat werden 1 bis 3 zufällige Felder auf Zeichenebene verfälscht (Vertauschen, Löschen, Einfügen oder Ersetzen), und bei 10 % der Datensätze wird ein Feld vollständig geleert. Ergebnis ist eine Ground-Truth-Datei mit 100.000 Paaren, und beide Werkzeuge werden gegen alle 100.000 Paare ausgewertet, ohne Stichprobenbildung.

Beide Werkzeuge gleichen dieselben Felder ab: first_name, last_name, date_of_birth, city, postcode und phone. Splink nutzt ein probabilistisches Modell mit einer Match-Schwelle bei einer Wahrscheinlichkeit ≥ 0,80; Tilores arbeitet regelbasiert und verknüpft ein Paar, sobald eine seiner sechs Verknüpfungsregeln greift. Die vollständigen Konfigurationen liegen im Repository.

Splink lief als eingebettete DuckDB-Bibliothek auf einem Entwickler-Laptop; Tilores lief auf einem LXC-Container mit 32 GB, derselben Speicherklasse. Keines der beiden Werkzeuge hat einen nennenswerten Hardwarevorteil.

Wie fielen die Ergebnisse aus?

Kennzahl	Splink (DuckDB)	Tilores	Δ
F1	0,8867	0,9949	+10,8 Prozentpunkte
Precision	0,9999	0,9998	~gleichauf
Recall	0,7965	0,9900	+19,4 Prozentpunkte
True Positives (von 100.000)	79.655	99.000	+19.345
False Positives	5	15	+10 (3× mehr – Splink gewinnt)
False Negatives	20.345	1.000	−19.345

Die Precision ist nahezu identisch. Beide Werkzeuge sind vorsichtig bei falschen Übereinstimmungen, und in absoluten Zahlen sind 15 False Positives bei 100.000 Paaren vernachlässigbar (hier liegt Splink mit 5 knapp vorn). Der entscheidende Abstand liegt beim Recall: Tilores findet 19.345 echte Duplikate mehr. Das ist die Zahl, die in der Praxis zählt, denn jedes übersehene Duplikat ist ein Datensatz, der im Silo bleibt.

Was verursacht den Unterschied beim Recall?

Ein Recall-Abstand von 19,4 Prozentpunkten auf einem sauberen, gut strukturierten synthetischen Datenbestand ist überraschend groß. Der Grund lohnt sich zu verstehen, denn der Abstand ist architektonisch bedingt und keine Frage der Feinjustierung.

Splink ist ein probabilistisches Record-Linkage-System. Es trainiert Expectation-Maximization-Parameter aus den Daten, wendet einen Blocking-Schritt an, um die Kandidatenpaare zu begrenzen, und vergibt Match-Wahrscheinlichkeiten. Der Blocking-Schritt ist tragend: Datensätze, die nie gemeinsam im selben Blocking-Bucket landen, können nicht abgeglichen werden – unabhängig davon, wie ähnlich ihre Felder sind. Jedes Duplikat, das außerhalb dieser Buckets fällt, etwa weil sowohl Postleitzahl als auch Nachname verfälscht sind, ist ein struktureller False Negative. Blocking ist schnell und notwendig, aber es ist auch der Ort, an dem der meiste Recall verloren geht.

Tilores verfolgt einen regelbasierten Graph-Ansatz. Es wertet explizite Verknüpfungsregeln über phonetische Vergleiche und String-Distanzen aus, und die Regeln überlappen sich: Ein Paar kann über eine Regel aus Name und Geburtsdatum, über eine Regel aus Name und Stadt oder über eine Postleitzahlenregel verknüpft werden, wobei die Ergebnisse transitiv im Entitätsgraphen zusammengeführt werden. Es gibt kein Blocking-Tor, das eine Übereinstimmung verhindern kann. Greift auch nur eine Regel, werden die Datensätze verknüpft. Der Preis dafür ist die Konfiguration: Sie führen die Regeln selbst auf. Der Vorteil ist, dass eine Verfälschung in einem Feld eine Übereinstimmung nicht blockiert, solange ein anderes Feld sauber bleibt.

Sie könnten den Recall von Splink erhöhen, indem Sie weitere Blocking-Schlüssel hinzufügen, aber jeder Schlüssel vergrößert den Kandidatenraum und verlangsamt den Lauf. Splink muss einen echten Kompromiss zwischen Recall und Komplexität verwalten; Tilores verwaltet ihn anders, nämlich über die Selektivität der Regeln.

Was vergleicht der Benchmark bewusst nicht?

Batch-Durchsatz. Splink ist bei der Batch-Deduplizierung auf eine Weise schnell, die schwer zu erreichen ist: 1 Mio. Datensätze in 9,24 Sekunden als eingebettete DuckDB-Bibliothek. Für reine Offline-Pipelines ohne Echtzeitanforderung ist das hervorragend – und es kostet keine Infrastruktur.

Erklärbarkeit. Splink erzeugt Match-Wahrscheinlichkeiten je Paar und kann zeigen, welche Felder wie stark beigetragen haben. Fragt ein Auditor, warum zwei Datensätze verknüpft wurden, hat Splink eine native probabilistische Antwort. Tilores liefert die Regelherkunft (welche Regel die Verknüpfung ausgelöst hat), aber keine Gewichtsaufschlüsselung. Für manche regulierten Prozesse entscheidet dieser Unterschied die Wahl.

Verfälschungen in echten Daten. Unser Datenbestand nutzt synthetische Verfälschungen im FEBRL-Stil. Echte Kundendaten haben andere Verteilungen: OCR-Fehler, Transliterationsrauschen, uneinheitliche Locales, fehlende Felder. Synthetische Benchmarks sind reproduzierbar, aber sie ersetzen keinen Test auf Ihren eigenen Daten.

Wann sollten Sie welches Werkzeug wählen?

Wählen Sie	Wenn
Splink	Kostenfreiheit ist Bedingung · reiner Batch-Betrieb · vollständige Kontrolle über die Matching-Pipeline auf Code-Ebene · erklärbare probabilistische Scores · akademische Arbeit oder F&E, bei der das Ergebnis eine deduplizierte Liste ist.
Tilores	Echtzeit-Abfragen nach der Datenaufnahme · inkrementelle Aufnahme (ein einzelner neuer Datensatz per API statt eines vollständigen Neulaufs) · ein dauerhafter, durchsuchbarer Entitätsindex · ein verwalteter, wartungsarmer Dienst mit Hochverfügbarkeits-SLAs und ohne eigenen Cluster · ein Matching, das sich vollständig im Code oder über eine grafische Oberfläche konfigurieren lässt · KYC, Betrugserkennung oder Customer 360 zur Abfragezeit.
Beides	Splink für Prototyping und Ground-Truth-Labeling, Tilores für den Produktivbetrieb.

Der Migrationsfall ist das Szenario, das wir eigentlich verstehen wollten: Wo stößt ein Team, das Splink für die Batch-Deduplizierung nutzt, an die Wand? Diese Wand ist selten die Genauigkeit. Es ist der Moment, in dem jemand fragt: „Können wir jetzt sofort prüfen, ob dieser neue Datensatz ein Duplikat ist, ohne auf den nächsten Batch zu warten?” Diese Frage lässt sich mit einer Paarliste architektonisch nicht beantworten. Tilores baut stattdessen einen dauerhaften Index auf: Die Suchlatenz auf dem Index mit 1 Mio. Datensätzen liegt in diesem Benchmark bei 8,6 ms p95 im LAN – und Tilores steht neben Ihrem bestehenden MDM-, CDP-, Warehouse- oder KYC-Stack, statt ihn zu ersetzen.

Welche Einschränkungen gibt es?

Beide Konfigurationen sind vollständig veröffentlicht. Die von Splink liegt näher am Tutorial-Stil, und ein Splink-Experte könnte mit eigenem Blocking und einer Feinjustierung der m/u-Werte vermutlich noch 1 bis 2 Prozentpunkte F1 herausholen. Der Vergleich ist also nicht das letzte Wort zur Obergrenze beider Werkzeuge. Wir halten das in der Methodik fest und akzeptieren es als Einschränkung. Wenn jemand per Pull Request eine verbesserte Splink-Konfiguration einreicht, lassen wir den Benchmark erneut laufen und aktualisieren die Ergebnisse.

Der Datenbestand ist synthetisch. Er ist reproduzierbar und legt seine Konstruktion offen, aber er ersetzt Ihre eigenen Daten nicht.

Wie reproduzieren Sie das?

# 1. Den Datenbestand mit 1 Mio. Datensätzen erzeugen (deterministisch, Seed 42)
python benchmark/generate_febrl_data.py

# 2. Splink ausführen — kein Konto erforderlich
python benchmark/benchmark_splink_febrl.py

# 3. Tilores ausführen — erfordert eine laufende Tilores-Instanz
export TILORES_API_URL=https://YOUR_INSTANCE.svc.tilores.io/YOUR_ID/graphql
export TILORES_TOKEN=your-token-here
python benchmark/benchmark_tilores_febrl.py

Die genaue Tilores-Regelkonfiguration ist im Repository veröffentlicht, zusammen mit den vorberechneten Ergebnissen beider Werkzeuge sowie der vollständigen Methodik, dem Auswertungsprotokoll und den Vorbehalten. Wenn Sie einen Fehler in der Methodik finden, eröffnen Sie ein Issue. Wenn Sie einen der beiden Werte auf denselben Daten mit einer reproduzierbaren Konfiguration schlagen können, eröffnen Sie einen Pull Request – wir veröffentlichen ihn.

FAQ

Was ist Entity Resolution?

Entity Resolution entscheidet, ob sich zwei Datensätze trotz Abweichungen in Name, Adresse oder Identifikator auf dieselbe reale Entität beziehen. Sie kombiniert deterministische Regeln mit Fuzzy Matching, um jeder realen Entität eine stabile ID zuzuweisen, sodass Analysen, Betrugsprüfungen und KI alle mit einer einzigen korrekten Sicht arbeiten.

Ist Splink oder Tilores genauer?

In diesem Benchmark erreichte Tilores den höheren F1-Wert (0,9949 gegenüber 0,8867), getrieben vom Recall: Es fand 19.345 echte Duplikate mehr von 100.000 Paaren. Bei der Precision lagen beide praktisch gleichauf. Genauigkeit hängt von Konfiguration und Daten ab – genau deshalb ist der Benchmark vollständig reproduzierbar.

Warum ist der Recall von Splink in diesem Test niedriger?

Splink setzt aus Performancegründen auf einen Blocking-Schritt, um die Kandidatenpaare zu begrenzen. Duplikate, bei denen beide Blocking-Felder verfälscht sind, werden nie zu Kandidaten und können nicht abgeglichen werden. Tilores hat kein Blocking-Tor – überlappende Regeln können ein Paar auch dann verknüpfen, wenn nur ein Feld sauber bleibt.

Kann Splink Echtzeit-Abfragen wie Tilores?

Nein. Splink erzeugt während der Batch-Verarbeitung eine einmalige Paarliste; danach gibt es keine dauerhafte Abfrage-API. Tilores baut einen dauerhaften Entitätsindex auf, den Sie zur Abfragezeit durchsuchen können (hier 8,6 ms p95 auf einem Index mit 1 Mio. Datensätzen) – genau das, was Echtzeit-KYC- und Customer-360-Prozesse brauchen.

Wo kann ich den Benchmark-Code einsehen?

Alles – die Skripte, die Tilores-Regelkonfiguration und die vorberechneten Ergebnisse – liegt im öffentlichen Repository unter github.com/tilotech/tilores-splink-benchmark.