Von Splink zu Tilores: Ein Migrationsleitfaden in 5 Schritten

Kurzfassung: Splink bringt Sie zu einem belastbaren Proof of Concept; Tilores bringt Sie in den Produktivbetrieb. Wenn Ihr Splink-Batch-Job bereits funktioniert, nachgelagerte Teams jetzt aber Antworten in Echtzeit brauchen, müssen Sie nicht von vorn beginnen. Dieser Leitfaden in fünf Schritten (Splink-Logik verstehen, auf Tilores-Regeln übertragen, eine Stichprobe einlesen, gegen die Referenzdaten trocken testen und dann live gehen) nimmt Ihr Matching-Design mit, ohne dass Sie die schwierigen Überlegungen wiederholen müssen. Wir verwenden durchgängig den öffentlichen FEBRL-Benchmark-Datensatz, damit jeder Schritt konkret und reproduzierbar ist.

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 von Splink migrieren?

Splink ist die glaubwürdigste Open-Source-Bibliothek für Entity Resolution, die es derzeit gibt: probabilistisch, erklärbar, kostenlos und im britischen Justizministerium praxiserprobt. Wenn Ihre Aufgabe Batch-Deduplizierung oder eine wissenschaftliche Verknüpfungsstudie ist, ist sie eine ausgezeichnete Wahl (hier steht, was wir an Splink schätzen), und unser eigener reproduzierbarer Benchmark zeigt, wie schnell sie ist: 1.000.000 Datensätze in 9,24 Sekunden dedupliziert, als eingebettete DuckDB-Bibliothek, ohne Infrastrukturkosten.

Der Grund für eine Migration ist selten die Genauigkeit. Es ist eine Änderung der Anforderungen. Ein Team weist mit Splink nach, dass Entity Resolution funktioniert, dann fragt jemand: „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 einmalig erzeugten Paarliste architektonisch nicht beantworten. Es ist der Moment, in dem ein Batch-Werkzeug an seine Grenze stößt – und der Moment, in dem sich eine Echtzeit-API auszahlt.

Tilores ist eine Echtzeit-API für Entity Resolution. Sie löst und verknüpft Datensätze bei der Ingestion und liefert zur Abfragezeit den aufgelösten Entitätskontext über eine GraphQL-API. Sie steht neben Ihrem bestehenden MDM, Ihrer CDP, Ihrem Warehouse oder Ihrem KYC/AML-Stack und ersetzt keines davon. Die Matching-Logik, die Sie in Splink bereits entworfen haben, lässt sich sauber darauf abbilden. Dieser Leitfaden zeigt, wie.

Wann lohnt sich diese Migration wirklich?

Kennen Sie den Auslöser, bevor Sie beginnen. Die Frage ist nicht, ob Tilores besser ist als Splink. Splink ist das richtige Werkzeug für Forschung, Entwicklung und Batch; Tilores ist das richtige Werkzeug für Produktion und Echtzeit.

Migrieren sollten Sie, wenn …	Bei Splink bleiben sollten Sie, wenn …
Nachgelagerte Systeme in dem Moment eine Antwort brauchen, in dem ein Datensatz eintrifft (KYC beim Onboarding, Betrugsprüfung bei der Registrierung, Abfrage am Behandlungsort).	Ihr Anwendungsfall reiner Batch ist und es auch bleiben wird.
Sie inkrementelle Ingestion wollen – einen einzelnen neuen Datensatz per API statt eines kompletten Neulaufs.	Sie Fellegi-Sunter-Modellparameter in einer wissenschaftlichen Arbeit veröffentlichen müssen.
Sie einen dauerhaften, durchsuchbaren Entitätsindex statt einer statischen Paarliste brauchen.	Ein striktes Nullbudget jedes kommerzielle Werkzeug ausschließt.
Der Betrieb der Batch-Infrastruktur (Spark-/DuckDB-Jobs, Scheduling, Monitoring) zur Last geworden ist.	Sie die Pipeline gern selbst betreiben und die interne Expertise dafür haben.

Viele Teams betreiben beides: Splink für Prototyping und die Erzeugung von Referenzdaten, Tilores für den Produktivbetrieb. Der folgende Leitfaden setzt voraus, dass Sie den Produktionsauslöser für sich bejaht haben.

Schritt 1: Verstehen Sie Ihre Splink-Matching-Logik

Sie können keine Logik migrieren, die Sie nicht benennen können. Bevor Sie Tilores anfassen, halten Sie drei Dinge aus Ihren Splink-Einstellungen fest, denn jedes davon hat auf der anderen Seite eine direkte Entsprechung.

Vergleiche. Auf welchen Feldern gleichen Sie ab, und mit welchen Vergleichsfunktionen? Im FEBRL-Benchmark gleichen beide Werkzeuge auf sechs Feldern ab (first_name, last_name, date_of_birth, city, postcode und phone) und nutzen für die Namens- und Adressfelder unscharfe Vergleiche wie Jaro-Winkler und Levenshtein.
Blocking-Regeln. Welche SQL-Blocking-Regeln begrenzen den Raum der Kandidatenpaare? Das ist der tragende Teil jeder Splink-Konfiguration. Notieren Sie ihn sorgfältig: Blocking ist der Grund, warum Splink schnell ist – und zugleich die Quelle der meisten übersehenen Übereinstimmungen. Datensätze, die nie im selben Blocking-Eimer landen, können nie miteinander verglichen werden.
Schwellenwert. Ab welcher Match-Wahrscheinlichkeit wird aus einem Kandidatenpaar eine bestätigte Verknüpfung? Im Benchmark haben wir eine Wahrscheinlichkeit ≥ 0,80 verwendet.

Halten Sie das in einer schlichten Tabelle fest: Feld, Vergleichstyp, Rolle im Blocking, Schwellenwert. Diese Tabelle ist Ihre Migrationsspezifikation.

Schritt 2: Bilden Sie Felder und Vergleiche auf eine Tilores-Regelkonfiguration ab

Hier liegt der entscheidende Denkwechsel. Splink ist probabilistisch: Es lernt m- und u-Parameter und summiert Match-Gewichte zu einer einzigen Wahrscheinlichkeit. Tilores ist regelbasiert: Sie zählen explizite Verknüpfungsregeln über Vergleichsfunktionen auf, und ein Paar wird verknüpft, sobald irgendeine Regel greift; die Verknüpfungen werden im Entitätsgraphen transitiv zusammengeführt. Es gibt kein Blocking-Gatter, das eine Übereinstimmung vorab verhindern könnte. Genau deshalb hat Tilores im Benchmark 19.345 zusätzliche echte Duplikate gefunden (Recall 0,9900 gegenüber 0,7965).

Die Abbildung ist direkter, als sie aussieht:

Splink-Konzept	Entsprechung in Tilores
Felder unter `comparisons`	Felder in Ihrem Tilores-Schema
Eine Vergleichsfunktion (Jaro-Winkler, Levenshtein)	Ein Vergleich bzw. Matcher in einer Verknüpfungsregel
Blocking-Regel (eine Einschränkung der Kandidaten)	Nicht nötig – stattdessen formulieren Sie die positiven Regeln, die Datensätze verknüpfen sollen
Match-Schwellenwert	Selektivität der Regel – wie streng die Bedingungen jeder Regel sind

Der Denkwechsel führt weg von „Welche Kandidatenpaare lasse ich zu, und welcher Wert überspringt die Hürde?“ hin zu „Welche konkreten Kombinationen von Belegen bedeuten, dass dies dieselbe Entität ist?“ Für FEBRL wird daraus ein kleiner Satz überlappender Regeln: etwa eine Regel aus Name plus Geburtsdatum, eine aus Name plus Stadt und eine aus Postleitzahl plus Telefonnummer. Weil sie sich überlappen, verhindert eine Verfälschung in einem Feld die Übereinstimmung nicht, solange ein anderes Feld sauber bleibt. Setzen Sie normalisierende Transformer (Groß-/Kleinschreibung, Leerzeichen, Phonetik) auf die Eingaben an, damit sich die Vergleiche konsistent verhalten. Die für den Benchmark verwendete Konfiguration ist vollständig im öffentlichen Repository veröffentlicht; beginnen Sie damit statt mit einer leeren Datei. Die vollständige Referenz zu Regelkonfiguration und Matchern finden Sie in der Tilores-API-Dokumentation.

Schritt 3: Lesen Sie eine Stichprobe ein

Beginnen Sie nicht mit allen 1.000.000 Datensätzen. Nehmen Sie eine repräsentative Stichprobe von 10.000 bis 50.000 Zeilen, einschließlich bekannter Duplikatpaare aus Ihren Referenzdaten, und lesen Sie sie über die Tilores-API ein. Die Auflösung geschieht bei der Ingestion: Sobald ein Datensatz eintrifft, wertet Tilores Ihre Regeln gegen den bestehenden Index aus, verknüpft ihn mit der richtigen Entität und vergibt eine stabile Entitäts-ID.

Hier wird auch der operative Unterschied greifbar. Mit Splink lassen Sie den Batch erneut laufen, um neue Daten einzubeziehen; mit Tilores senden Sie einen einzelnen Datensatz (der Benchmark verpackt jede JSONL-Zeile und übergibt sie per batch-graphql), und er wird gegen alles bereits Eingelesene aufgelöst. Sobald die Stichprobe eingelesen ist, können Sie sie sofort abfragen. Der Benchmark prüft Übereinstimmungen mit einer einzigen Suche über die Datensatz-ID, und die übrigen Mitglieder der aufgelösten Entität sind die verknüpften Duplikate. Genau das ist die Frage „Ist das jetzt gerade ein Duplikat?“:

query($id: ID!) {
  entityByRecord(input: { id: $id }) {
    entity {
      id
      records { id }
    }
  }
}

Um einen eingehenden Datensatz über seine Feldwerte statt über eine bekannte ID abzugleichen, stellt Tilores zusätzlich eine search-Abfrage bereit, die Kandidatenentitäten mit score und hitScore sowie recordInsights als Beleg für den übereinstimmenden Datensatz zurückgibt. Die genaue Struktur beschreibt die Tilores-API-Dokumentation.

Schritt 4: Trockenlauf und Vergleich mit Ihrer Splink-Ausgabe

Dieser Schritt schafft intern Vertrauen. Lösen Sie die Stichprobe mit Tilores auf, exportieren Sie die verknüpften Paare und vergleichen Sie sie mit (a) Ihrer Splink-Ausgabe und (b) Ihren Referenzdaten. Wenn Sie Splink betrieben haben, besitzen Sie das nötige Prüfgerüst bereits – das Bewertungsverfahren ist dasselbe: echte Treffer, falsche Treffer und übersehene Treffer gegen die bekannten Paare zählen und daraus Precision, Recall und F1 berechnen.

Auf dem vollständigen FEBRL-Benchmark sah der Vergleich so 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

Erwarten Sie eine nahezu identische Precision, da beide Ansätze vorsichtig mit falschen Übereinstimmungen umgehen. Der Unterschied, den Sie sehen sollten, liegt beim Recall – und die Paare, die Tilores findet und Splink übersehen hat, sind fast immer Datensätze, bei denen ein Blocking-Feld verfälscht war. Sehen Sie sich genau diese Paare an: Sie sind der konkrete, belastbare Beleg dafür, dass die Migration die Abdeckung auf Ihren Daten verbessert. Verknüpft eine Regel zu viel, verschärfen Sie ihre Bedingungen; verknüpft sie zu wenig, ergänzen Sie eine überlappende Regel. Iterieren Sie auf der Stichprobe, bis sowohl die Zahlen als auch die geprüften Paare überzeugen. Jede Zahl oben ist aus dem öffentlichen Repository reproduzierbar.

Schritt 5: Gehen Sie mit der Echtzeit-API und inkrementeller Ingestion live

Sobald der Trockenlauf hält, skalieren Sie die Ingestion auf den vollständigen Datenbestand und schalten die beiden Fähigkeiten frei, die eine Paarliste nie liefern konnte:

Echtzeitsuche zur Abfragezeit. Nachgelagerte Systeme fragen den aufgelösten Index ab, statt auf einen Batch zu warten. Auf dem Index mit 1 Mio. Datensätzen aus dem Benchmark lag die Suchlatenz bei 8,6 ms im p95 im LAN – schnell genug für einen Onboarding-Prozess oder eine Abfrage am Behandlungsort.
Inkrementelle Ingestion. Neue Datensätze treffen einzeln über die API ein und werden sofort gegen den laufenden Index aufgelöst. Kein kompletter Neulauf, keine veralteten Golden Records zwischen zwei Batches.

Behalten Sie Ihren Splink-Job, wenn er weiterhin seinen Platz verdient. Viele Teams nutzen ihn weiter für die periodische Erzeugung von Referenzdaten und für Nachvalidierungen und wiederholen den Trockenlaufvergleich, sobald sich Regeln ändern. Migration bedeutet nicht Löschen; sie bedeutet, dass der Produktionspfad jetzt in Echtzeit läuft und Batch auf die Forschungs- und Entwicklungsrolle zurückgeht, in der er am stärksten ist.

Was bringt diese Migration nicht automatisch mit?

Ehrlichkeit zählt hier genauso viel wie im Benchmark. Zwei Punkte sollten Sie abwägen, bevor Sie sich festlegen.

Probabilistische Erklärbarkeit. Splink erzeugt ein Match-Gewicht je Paar und kann in einem Wasserfalldiagramm zeigen, wie viel jedes Feld beigetragen hat. Tilores liefert Ihnen die Regelherkunft, also welche Regel eine Verknüpfung ausgelöst hat. Das ist hervorragend für die Frage „Zeig mir, warum“, entspricht aber nicht einer Aufschlüsselung der Gewichte je Vergleich. Für manche regulierten Prüfprozesse ist dieser Unterschied relevant; gleichen Sie ihn mit Ihren Compliance-Anforderungen ab.

Kosten. Splink ist kostenlos, Tilores ist ein kommerzielles Produkt. Dafür erhalten Sie Echtzeitfähigkeit, inkrementelle Ingestion und die Entlastung davon, die Matching-Infrastruktur selbst zu betreiben. Ob sich dieser Kompromiss lohnt, hängt davon ab, ob Sie produktive Antworten in Echtzeit brauchen – also genau von dem Auslöser aus Schritt 0 dieses Leitfadens.

FAQ

Muss ich meine Matching-Logik in Tilores komplett neu entwerfen?

Nein. Die Felder und Vergleichsfunktionen, die Sie in Splink gewählt haben, lassen sich fast unverändert auf eine Tilores-Regelkonfiguration übertragen. Der wesentliche Wechsel ist konzeptioneller Art: Statt Blocking-Regeln plus Wahrscheinlichkeitsschwelle formulieren Sie explizite, überlappende Verknüpfungsregeln, die greifen, wenn Datensätze genügend gemeinsame Belege aufweisen, um dieselbe Entität zu sein.

Ändert sich meine Genauigkeit nach der Migration?

Im FEBRL-Benchmark blieb die Precision praktisch gleichauf, während der Recall deutlich stieg (+19,4 Prozentpunkte), weil Tilores kein Blocking-Gatter hat, das eine Übereinstimmung vorab verhindern könnte. Ihre eigenen Ergebnisse hängen von Ihren Daten und Ihrer Regelkonfiguration ab – genau deshalb sieht Schritt 4 einen Trockenlauf gegen Ihre Referenzdaten vor, bevor Sie live gehen.

Kann ich Splink nach der Migration weiter nutzen?

Ja, und viele Teams tun genau das. Splink bleibt ein ausgezeichnetes Werkzeug für Batch-Prototyping und für die Erzeugung von Referenzdaten. Ein verbreitetes Muster ist Splink für Forschung, Entwicklung und Nachvalidierung, Tilores für den produktiven Echtzeitpfad.

Wie funktioniert die Echtzeit-Auflösung in Tilores konkret?

Tilores löst und verknüpft jeden Datensatz bei der Ingestion und pflegt einen dauerhaften, abfragbaren Entitätsindex. Zur Abfragezeit durchsuchen Sie diesen Index und erhalten aufgelöste Entitäten mit Feldern wie score, hitScore und recordInsights zurück. Tilores steht neben Ihrem bestehenden MDM-, CDP-, Warehouse- oder KYC-System, statt es zu ersetzen.

Wo finde ich den Benchmark und die in diesem Leitfaden verwendete Regelkonfiguration?

Alles – der FEBRL-Datengenerator, die Konfigurationen beider Werkzeuge (einschließlich der genauen Tilores-Regeln) und die vorberechneten Ergebnisse – liegt im öffentlichen Repository unter github.com/tilotech/tilores-splink-benchmark. Die vollständige Methodik beschreiben wir im Beitrag zum Benchmark Splink vs. Tilores.

Ist Tilores ein Ersatz für mein Data Warehouse oder mein MDM?

Nein. Tilores ist eine Echtzeit-API für Entity Resolution, die den aufgelösten Entitätsschlüssel liefert, der diesen Systemen fehlt. Sie ergänzt Ihr Warehouse, Ihr MDM, Ihre CDP oder Ihren KYC/AML-Stack – Sie behalten diese Systeme und stellen ihnen die Auflösung in Echtzeit zur Seite.