Was wir beim Aufbau eines öffentlichen Splink-Benchmarks gelernt haben

Kurzfassung: Wir haben einen reproduzierbaren Benchmark veröffentlicht, der unsere eigene Entity-Resolution-API mit dem Open-Source-Werkzeug Splink vergleicht – inklusive der proprietären Regelkonfiguration, die die meisten Anbieter für sich behalten. Die Schlagzeilenzahl (F1 0,9949 gegenüber 0,8867) zählt weniger als die Methode: derselbe Datensatz, dieselbe Ground Truth, veröffentlichter Code und eine ehrliche Darstellung dessen, wo Splink gewinnt. Die interessanteste Erkenntnis war architektonischer Natur: Die Recall-Lücke von 19,4 Prozentpunkten geht auf den Blocking-Schritt von Splink zurück, nicht auf das Tuning. Dieser Beitrag handelt davon, wie wir einen Benchmark gebaut haben, dem wir auch dann trauen würden, wenn ihn ein Wettbewerber durchgeführt hätte.

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

Warum sollte man das eigene Produkt öffentlich benchmarken?

Anbieter-Benchmarks haben ein Glaubwürdigkeitsproblem, und das wissen wir. Die übliche Annahme – meist zu Recht – lautet: Ein vom Anbieter veröffentlichter Benchmark wurde vom Ergebnis her rückwärts konstruiert. Datensatz aussuchen, Metrik aussuchen, so lange justieren, bis man gewinnt, veröffentlichen. Warum also überhaupt einen machen?

Weil die Alternative schlechter ist. Wer Entity Resolution evaluiert, stellt eine konkrete Frage: Ich nutze Splink zur Deduplizierung – wann, wenn überhaupt, lohnt sich ein Wechsel? Die Antwort lautet „kommt darauf an, hier sind die Daten”, und die geben wir lieber als reproduzierbares Artefakt heraus als in Form einer Präsentation. Splink ist die stärkste verfügbare Open-Source-Referenz: entwickelt im britischen Justizministerium, probabilistisch, erklärbar und kostenlos. Wenn wir für einen fairen Vergleich damit nicht geradestehen könnten, sollten wir überhaupt keine Aussagen zur Genauigkeit machen.

Die Regel, die wir uns auferlegt haben: den Benchmark so zu bauen, dass jemand, der ihn widerlegen will, es versuchen kann – mit allem in der Hand, was er dafür braucht. Diese Vorgabe hat jede weitere Entscheidung geprägt.

Was macht einen Benchmark vertrauenswürdig statt bloß werblich?

Ein Benchmark verdient Vertrauen dadurch, dass er überprüfbar ist, nicht dadurch, dass er schmeichelt. Wir haben uns auf fünf Prinzipien festgelegt – und würden einen Wettbewerber an denselben messen.

Prinzip	Was das in der Praxis bedeutet
Gleiche Eingangsdaten	Beide Werkzeuge sehen denselben Datensatz und dieselben Ground-Truth-Paare. Kein Datensatz pro Werkzeug, keine Stichproben.
Veröffentlichte Konfiguration	Jede Regel, jeder Schwellenwert und jeder Parameter liegt im Repository — auch unsere, die proprietär ist.
Von Grund auf reproduzierbar	Ein deterministischer Generator (seed 42) sorgt dafür, dass jeder exakt dieselben 1 Mio. Datensätze erzeugt und beide Werkzeuge erneut laufen lässt.
Wo das andere Werkzeug gewinnt	Wir sagen klar, dass Splink beim Batch-Durchsatz, bei den Kosten und bei der Erklärbarkeit einzelner Paare gewinnt.
Ein Weg, uns zu widerlegen	Öffnen Sie ein Issue, wenn die Methode fehlerhaft ist; öffnen Sie einen Pull Request, wenn Sie einen Wert auf denselben Daten schlagen können.

Die letzten beiden Punkte trennen einen Benchmark von einer Broschüre. Ein Vergleich, bei dem der Wettbewerber nie etwas gewinnt, behauptet ein Ergebnis, statt es zu messen. Splink gewinnt auf mehreren Achsen deutlich, und das auszusprechen ist genau das, was die Recall-Zahl glaubwürdig macht, wenn wir sie berichten.

Warum die proprietäre Regelkonfiguration veröffentlichen?

Das war die Entscheidung mit der meisten internen Diskussion. Die Verknüpfungsregeln von Tilores – welche Felder kombiniert werden, welche Vergleichsverfahren und Distanzschwellen eine Übereinstimmung auslösen – sind normalerweise genau das, was ein Produktunternehmen für sich behält. Wir haben sie trotzdem veröffentlicht.

Die Begründung: Ein Benchmark, bei dem die Konfiguration einer Seite verborgen bleibt, ist konstruktionsbedingt nicht überprüfbar. Hätten wir unsere Ergebnisse mit geschwärzter Regelkonfiguration veröffentlicht, würde jede Zahl auf „vertrauen Sie uns” beruhen. Durch die Veröffentlichung kann ein skeptischer Leser genau sehen, warum ein Paar verknüpft wurde, es reproduzieren und infrage stellen. Die Konfiguration ist nicht der Burggraben. Die Echtzeit-API, der persistente Entitätsgraph und das operative Verhalten drumherum sind es. Eine Regelliste auf einem synthetischen Datensatz verrät weit weniger, als die meisten annehmen – und sie verschafft das Einzige, was ein Anbieter-Benchmark sonst nicht haben kann: die Möglichkeit, überprüft zu werden.

Sie hat uns auch zur Ehrlichkeit gezwungen. Man schreibt Regeln deutlich anders, wenn man weiß, dass sie Zeile für Zeile von Leuten gelesen werden, die Freude daran hätten, einen Daumen auf der Waage zu entdecken.

Was war die interessanteste technische Erkenntnis?

Die auffälligste Lücke lag beim Recall: Tilores fand 19.345 zusätzliche echte Duplikate unter 100.000 Paaren (+19,4 Prozentpunkte), was den F1-Score auf 0,9949 gegenüber 0,8867 bei Splink trieb. Bei der Precision lagen beide praktisch gleichauf, denn beide Werkzeuge sind bei falschen Übereinstimmungen vorsichtig. Interessant war nicht, dass es die Lücke gab, sondern woher sie kam – denn sie ist kein Artefakt des Tunings.

Splink ist ein probabilistisches Record-Linkage-System und stützt sich wie jedes System dieser Familie auf einen Blocking-Schritt, um die Zahl der Kandidatenpaare beherrschbar zu halten. Blocking ist dabei tragend: Zwei Datensätze, die nie im selben Blocking-Bucket landen, können nicht verglichen werden – egal, wie ähnlich ihre Felder sind. Auf unseren verrauschten Daten wird ein Duplikat, dessen Blocking-Felder (etwa Postleitzahl und Nachname) beide verfälscht sind, zu einem strukturellen Falsch-Negativ, das gar nicht erst in die Kandidatenmenge gelangt. Blocking ist schnell und notwendig – und zugleich der Ort, an dem der meiste Recall verloren geht.

Tilores geht einen anderen Weg. Das System wertet überlappende Verknüpfungsregeln über phonetische Vergleiche und String-Distanzen aus und führt Übereinstimmungen transitiv in einem persistenten Entitätsgraphen zusammen. Es gibt kein Blocking-Gatter, das ein Paar vorab ausschließen könnte: Sobald eine einzige Regel greift (Name + Geburtsdatum, oder Name + Stadt, oder Postleitzahl), werden die Datensätze verknüpft. Verfälschungen in einem Feld verhindern keine Übereinstimmung, solange ein anderes Feld sauber bleibt. Der Preis: Sie zählen die Regeln selbst auf. Der Nutzen: genau der Recall, den Sie in den Ergebnissen sehen.

Das ist die Erkenntnis, die ein Leser mitnehmen sollte, selbst wenn er unser Produkt nie anfasst. In dieser Problemklasse wird die Recall-Obergrenze oft von der Architektur gesetzt – Blocking gegenüber überlappenden Regeln auf einem persistenten Graphen –, und zwar lange bevor Parameter-Tuning ins Spiel kommt. Man kann den Recall von Splink mit mehr Blocking-Schlüsseln steigern, aber jeder Schlüssel vergrößert den Kandidatenraum und verlangsamt den Lauf. Das ist eine echte Abwägung, und ein fairer Benchmark sollte sie benennen statt verbergen.

Was hat uns der ehrliche Weg gekostet?

Wir haben drei Einschränkungen offen protokolliert. Unsere veröffentlichte Splink-Konfiguration ist eher tutorial-nah, und ein Splink-Experte könnte mit eigenem Blocking und angepassten m/u-Werten vermutlich noch 1–2 Prozentpunkte F1 herausholen. Das schreiben wir in die Methodik, und wenn jemand per Pull Request eine stärkere Konfiguration einreicht, lassen wir den Lauf neu durchlaufen und aktualisieren. Der Datensatz ist synthetisch: reproduzierbar und ehrlich in Bezug auf seine Konstruktion, aber kein Ersatz für Ihre unordentlichen Produktivdaten mit OCR-Fehlern, Transliterationsrauschen und länderspezifischen Eigenheiten. Und wir stellen Tilores bewusst nicht als Ersatz für Splink dar. Beide lösen überlappende, aber unterschiedliche Probleme. Splink erzeugt im Batch eine einmalige Paarliste; Tilores ist eine Echtzeit-API für Entity Resolution, die Datensätze bei der Aufnahme auflöst und die aufgelöste Entität zum Abfragezeitpunkt zurückgibt (8,6 ms p95 auf dem hier verwendeten Index mit 1 Mio. Datensätzen) – und die neben Ihrem MDM, Ihrer CDP, Ihrem Warehouse oder Ihrem KYC-Stack steht, statt sie zu ersetzen.

Keine dieser Einschränkungen hilft dem Marketing. Alle helfen der Glaubwürdigkeit – und die ist bei einem Benchmark die Währung, auf die es ankommt.

Was würden wir jemandem raten, der einen eigenen Benchmark baut?

Veröffentlichen Sie genug, damit man Sie widerlegen kann: Code, Datengenerator, Ground Truth und die Konfigurationen beider Seiten, ohne Ausnahme. Berichten Sie, wo Sie verlieren, denn ein Benchmark ohne Verlustspalte ist keine Messung. Und trennen Sie die Zahl von der Architektur. Die nützlichste Erkenntnis in unserem Fall war nicht der F1-Score. Es war das Verständnis, dass Blocking gegenüber überlappenden Regeln auf einem Graphen den Recall bewegt hat. Wenn Ihr Benchmark nur eine Rangliste erzeugt und keine Erklärung, haben Sie Marketing gebaut, kein Engineering.

Alles liegt im öffentlichen Repository unter github.com/tilotech/tilores-splink-benchmark: die Skripte, der deterministische Datengenerator, die Ground Truth, unsere Regelkonfiguration und vorberechnete Ergebnisse für beide Werkzeuge. Die vollständige Auswertung finden Sie in unserem Benchmark-Beitrag Splink vs. Tilores.

FAQ

Warum sollte ein Anbieter einen Benchmark gegen das eigene Produkt veröffentlichen?

Um eine Frage zu beantworten, die Praktiker tatsächlich stellen – wann man von Splink zu einer Echtzeit-API wechseln sollte – und zwar mit einem überprüfbaren Artefakt statt mit einer Verkaufsaussage. Der Benchmark ist so gebaut, dass ein Skeptiker jede Zahl reproduzieren und infrage stellen kann. Nur so verdient ein Anbietervergleich Vertrauen.

Warum hat Tilores seine proprietäre Regelkonfiguration veröffentlicht?

Weil ein Benchmark, bei dem die Konfiguration einer Seite verborgen bleibt, konstruktionsbedingt nicht überprüfbar ist. Die Veröffentlichung der Regeln erlaubt es einem Leser, genau zu sehen, warum jedes Paar verknüpft wurde, und es zu reproduzieren. Der verteidigbare Wert liegt in der Echtzeit-API und im persistenten Entitätsgraphen, nicht in einer Regelliste auf einem synthetischen Datensatz.

Was war die zentrale technische Erkenntnis?

Die Recall-Lücke von 19,4 Prozentpunkten ist architektonisch bedingt und kein Artefakt des Tunings. Der Blocking-Schritt von Splink schließt Paare aus, deren Blocking-Felder beide verfälscht sind, und macht sie zu strukturellen Falsch-Negativen. Tilores nutzt überlappende Regeln auf einem persistenten Graphen ohne Blocking-Gatter, sodass ein einziges sauberes Feld ein Paar trotzdem verknüpfen kann.

Räumt der Benchmark ein, wo Splink gewinnt?

Ja – ausdrücklich. Splink gewinnt beim reinen Batch-Durchsatz (1 Mio. Datensätze in 9,24 Sekunden als eingebettete DuckDB-Bibliothek), bei den Kosten (es ist kostenlos) und bei der nativen probabilistischen Erklärbarkeit einzelner Paare. Ein Benchmark ohne Verlustspalte für den Autor ist eine Broschüre, keine Messung.

Wo kann ich den Benchmark einsehen und selbst überprüfen?

Der Code, der deterministische Datengenerator, die Ground Truth, die Tilores-Regelkonfiguration und die vorberechneten Ergebnisse liegen alle im öffentlichen Repository unter github.com/tilotech/tilores-splink-benchmark. Die vollständigen Ergebnisse finden Sie im Benchmark-Beitrag Splink vs. Tilores.