AWS Entity Resolution und Tilores im Vergleich
Kurzfassung: Im selben Test mit 10 Datensätzen ordnete Tilores — eine Echtzeit-API für Entity Resolution — jeden Datensatz bereits beim Einfügen innerhalb von Millisekunden zu und löste die Daten nach rund 3 Minuten Einrichtung auf die korrekten 4 Entitäten auf. AWS Entity Resolution, zum Zeitpunkt des Tests ein Batch-Dienst, benötigte 9–11 Minuten und kam auf 7 Entitäten (Regeln) beziehungsweise auf gar keine Übereinstimmung (ML). Inzwischen hat AWS ein Near-Real-Time-Matching ergänzt (Juni 2025), das über die Generate Match ID API „innerhalb von Sekunden“ eine Match-ID zurückgibt — wobei AWS anmerkt, dass Near-Real-Time für fortgeschrittenes Fuzzy Matching nicht verfügbar ist. Tilores gleicht dagegen beim Einfügen in Millisekunden ab, Fuzzy Matching eingeschlossen, und macht die Daten über seine GraphQL-API gleichzeitig durchsuchbar. Die eigentliche Frage lautet 2026 also nicht mehr „Batch oder nicht“, sondern wie niedrig die Matching-Latenz ausfällt und ob Fuzzy Matching Teil davon ist.
Wie schnell sind Echtzeit-APIs für Entity Resolution im Vergleich zu Batch-Matching?
Für diesen Vergleich liefen beide Systeme auf derselben, nicht normalisierten CSV-Datei mit 10 Datensätzen, die sich auf vier Personen auflösen sollten. Die Tabelle fasst zusammen, was jedes System geleistet hat; die vollständige Schritt-für-Schritt-Beschreibung, die Screenshots und die Ergebnistabellen finden Sie in den Abschnitten darunter.
| Kriterium | AWS Entity Resolution | Tilores |
|---|---|---|
| Verarbeitungsmodell | Zum Testzeitpunkt Batch; Near-Real-Time-Matching im Juni 2025 ergänzt — gibt über die Generate Match ID API „innerhalb von Sekunden“ eine Match-ID zurück, allerdings nicht für fortgeschrittenes Fuzzy Matching | Echtzeit — gleicht jeden Datensatz beim Einfügen in Millisekunden ab, Fuzzy Matching eingeschlossen, mit gleichzeitiger Suche |
| Zeit bis zum Ergebnis (dieser Test) | 9–11 Minuten (Einrichtung der Umgebung + Batch-Auflösungsjob) | ~3 Minuten Einrichtung; das Matching selbst dauert wenige Millisekunden |
| Matching-Genauigkeit (Ziel = 4 Cluster) | ML: 0 Übereinstimmungen (10 Entitäten); Regeln: 7 Entitäten | 4 Entitäten (korrekt), ohne Feinjustierung |
| Einrichtungsaufwand | ≥1 Stunde für Nutzer ohne AWS-Erfahrung; Minuten für AWS-Experten; benötigt S3, Glue, IAM und Entity Resolution | 4 Klicks; die integrierte KI schlägt vorkonfigurierte Regeln vor |
| Matching-Verfahren | Regelbasiert oder ML (ML in diesem Test nicht durch Nutzer trainierbar); inkrementelles ML-Matching 2026 ergänzt; IDs von Datendienstleistern (z. B. Ramp ID, TruAudience, UID2.0) | Per ODER verknüpfte Regeln mit einem Konfidenzwert pro Verknüpfung; konfigurierbar für Personen- und Firmendaten |
| Deployment | AWS-nativ, eng in das AWS-Ökosystem integriert | Im AWS-Konto des Kunden oder als SaaS betreibbar; auf dem AWS Marketplace; eigene GraphQL-API |
In unserer datengetriebenen Welt ist die Genauigkeit von Informationen entscheidend für den Unternehmenserfolg. Diese Genauigkeit sicherzustellen wird jedoch zur Mammutaufgabe, sobald Daten redundante oder widersprüchliche Einträge zu denselben realen Entitäten enthalten. Eine „Entität“ kann eine Person sein, ein Unternehmen, eine Maschine oder jedes andere materielle oder immaterielle Objekt.
Zum Glück schafft Entity-Resolution-Software Abhilfe, indem sie diese verstreuten Informationsfragmente effizient verknüpft und dedupliziert. Solche Systeme erzeugen saubere, gut zugängliche Datenbestände ohne Redundanzen und bewahren dabei alle wesentlichen Informationen in deduplizierter Form. Indem sie die Daten harmonisieren und Duplikate beseitigen, versetzen Entity-Resolution-Systeme Organisationen in die Lage, verlässlichere und fundiertere Entscheidungen auf Basis einer einheitlichen Sicht auf ihre Daten zu treffen.
Die ER-Systeme in diesem Vergleich haben unterschiedliche Funktionen und Fähigkeiten, das Ergebnis sollte aber dasselbe sein – saubere, korrekt abgeglichene Daten.
Da das Thema Entity Resolution durchaus komplex sein kann, sollten ER-Systeme einen einfachen Einstieg bieten, um Daten schnell abzugleichen, und anschließend Funktionen bereitstellen, um den Matching-Prozess feinzujustieren.
Allgemeine Testanordnung
Wir verwenden 10 Personendatensätze mit ähnlichen Namen und derselben Adresse. Diese Datensätze liegen in einer einzigen CSV-Datei, da beide Systeme mit CSV arbeiten können. Die Datei ist nicht normalisiert und enthält teilweise Leerzeichen in den Daten.
Die resultierende Matching-Tabelle darf zwei verschiedene Personen nicht vermischen, sollte aber auch keine Datensätze übersehen, die zur selben Person gehören.
Anhand dieser Daten sollten wir 4 verschiedene Cluster erhalten:
| Cluster-ID | Datensatz-IDs |
|---|---|
| 1 | 1, 2, 3, 4, 8, 9 |
| 2 | 5, 6 |
| 3 | 7 |
| 4 | 10 |
AWS Entity Resolution
Anmerkung der Redaktion (2026): Dieser Praxisdurchlauf beschreibt AWS Entity Resolution so, wie der Dienst zum Marktstart funktionierte. AWS hat seither Near-Real-Time-Matching und weitere Funktionen ergänzt — siehe Was sich seit diesem Vergleich geändert hat weiter unten. Die ursprüngliche Testbeschreibung bleibt als Momentaufnahme erhalten.
AWS hat kürzlich einen eigenen Entity-Resolution-Dienst gestartet. Der Dienst lässt sich wahlweise für regelbasiertes Matching oder für Machine Learning konfigurieren. Derzeit läuft er als Batch-Dienst und hat keine Echtzeitfähigkeiten. Die Konfigurierbarkeit ist im Moment sehr begrenzt, und der Abgleich von Datensätzen ist nur für Personendaten wie Name und Adresse möglich. Da der Dienst erst vor wenigen Wochen gestartet ist, dürften die Fähigkeiten bald erweitert werden.
Produktseite: https://aws.amazon.com/de/entity-resolution/
Dokumentation: https://docs.aws.amazon.com/entityresolution/latest/userguide/setting-up.html
Voraussetzungen:
- AWS-Konto (am besten mit Administratorrechten, da mehrere Dienste benötigt werden)
- AWS S3 für die Eingabe- und Ergebnisdateien
- AWS Glue zum Anlegen der Tabellen
- AWS IAM zum Anlegen der Rollen, die den Zugriff auf alle benötigten Dienste erlauben
- AWS Entity Resolution für den eigentlichen Abgleich der Daten
Einrichtung:
Zuerst müssen die erforderliche Infrastruktur und die Dienste eingerichtet und die Daten in eine Glue-Tabelle geladen werden. Anschließend legen Sie ein Schema-Mapping an und definieren, welche Spalten für das Matching genutzt und welche lediglich durchgereicht werden. Danach gruppieren Sie die Eingabefelder, damit sie abgeglichen werden können.
Je nach Matching-Verfahren gibt es nun zwei unterschiedliche Abläufe:
- ML-basiert: Dieses Verfahren benötigt keinerlei Konfiguration und versucht, die Datensätze auf Basis eines Machine-Learning-Modells abzugleichen. Das Modell kann vom Nutzer weder verändert noch trainiert werden. Es ist also ein schneller Weg zur Entity Resolution, doch in unserem Testfall waren die Ergebnisse nicht gut, da das Modell keine Datensätze zusammenführte.
- Regelbasiert: Beim regelbasierten Matching lassen sich Regeln definieren, die die Daten abgleichen. Die Regeln haben Prioritäten: Die erste Regel, die zwei Datensätze zusammenführt, wird verwendet, danach wird die Verarbeitung für diesen Datensatz beendet. Für das regelbasierte Matching lässt sich die Taktung der Matching-Läufe festlegen (beim ML-Verfahren ist das nicht möglich). Für den Test haben wir „manuell“ gewählt; bei sich ändernden Daten ist jedoch die automatische Taktung sinnvoll, die den Job bei jeder Datenänderung startet.
Wie im Screenshot unten zu sehen, lassen sich verschiedene Kombinationen der Match-Keys verwenden. Wie bei jedem Entity-Resolution-System gilt: Je mehr unabhängige Attribute zur Verfügung stehen, desto besser der Abgleich.
Da die Match-Keys mehrere Attribute wie Vor- und Nachname enthalten, kann der Nutzer über den Vergleichstyp festlegen, wie abgeglichen werden soll.
Ergebnisse:
ML-basiert
| Cluster-ID | Datensatz-IDs |
|---|---|
| 1 | 1 |
| 2 | 2 |
| 3 | 3 |
| 4 | 4 |
| 5 | 5 |
| 6 | 6 |
| 7 | 7 |
| 8 | 8 |
| 9 | 9 |
| 10 | 10 |
Der ML-basierte Ansatz liefert keine einzige Übereinstimmung und lässt keine zusätzliche Konfiguration zu.
Regelbasiert
| Cluster-ID | Datensatz-IDs |
|---|---|
| 972d03fa0efc489c9707e4756e7867e9 | 7 |
| 5291e16cc8c14368a5db34760a6c9c3f | 9 |
| 23b30c5fd03a3407b61aaa932cc74eb2 | 3, 2, 1 |
| 303f56fbf9ce472cb34ad1ebbdf1d8d9 | 10 |
| 7bda65da2d66499daad1438773658105 | 4 |
| 6de6133e05b43af4ba9a22245cb02358 | 5, 6 |
| f4f85d56361e405588337896dde55af2 | 8 |
Der regelbasierte Ansatz erlaubt es, einfache Regeln für das Matching zu konfigurieren. Der übrige Ablauf entspricht dem ML-basierten Ansatz. Beim regelbasierten Ansatz wurden die Datensätze zu 7 Entitäten zusammengeführt.
Tilores
Tilores ist eine Entity-Resolution-Software, die Datensätze in Echtzeit verknüpft und dedupliziert. Die Daten lassen sich durchsuchen, während sie in Tilores eingefügt werden. Die Software kann im AWS-Konto des Kunden betrieben oder als SaaS-Dienst genutzt werden. Dieser Test verwendet die Oberfläche des öffentlichen SaaS-Dienstes.
Tilores lässt sich für alle Arten von Daten konfigurieren, einschließlich Abgleich und Deduplizierung von Personen- und Firmendaten.
Produktseite: https://tilores.io/de/
Dokumentation: https://docs.tilotech.io/
AWS Marketplace: https://aws.amazon.com/marketplace/pp/prodview-2yn5oirwdwq74?sr=0-1&ref_=beagle&applicationId=AWSMPContessa
Voraussetzungen:
- Registrierung per E-Mail/Passwort oder Google-Anmeldung unter app.tilores.io (der Dienst lässt sich kostenlos testen)
Einrichtung:
Nach erfolgreicher Registrierung kann der Nutzer wählen, ob Tilores eine Beispieldatei bereitstellen soll, ob eine eigene Datei hochgeladen wird (diese Variante haben wir für den Test genutzt) oder ob Tilores manuell konfiguriert werden soll.
Der erste Schritt ist das Hochladen der Beispieldatei.
Die integrierte KI von Tilores erkennt die Daten und schlägt vorkonfigurierte Regeln für diesen Anwendungsfall vor:
Mit dieser Konfiguration richtet Tilores nun eine Instanz für uns ein und lädt die Daten.
Sobald das Deployment abgeschlossen ist, wird eine der Entitäten in der Tilores-Suchoberfläche angezeigt.
Die gesamte Einrichtung erforderte 4 Klicks vom Nutzer, der Rest lief automatisch ab.
Üblicherweise werden Daten über die eigene GraphQL-API nach Tilores geladen und auch darüber durchsucht; diese API ist Teil jeder Instanz.
Für den Test konfigurierte der Einrichtungsprozess zwei Regeln, die auf Name und Adresse abgleichen. In Tilores sind die Regeln per ODER verknüpft, das heißt, es werden stets alle Regeln ausgeführt, woraus sich ein Konfidenzwert für jede Verknüpfung ergibt.
Da die Daten nicht normalisiert waren und Leerzeichen enthielten, mussten sie vor dem Abgleich vom System transformiert werden. Dafür sorgen die Feldtransformation und -extraktion, die während der Einrichtung der Instanz automatisch konfiguriert wurden. Je nach Anwendungsfall lässt sich das weiter feinjustieren.
Für Analysen, Exporte und die Bereitstellung sauberer Daten für Machine Learning steht die Analytics-Engine von Tilores zur Verfügung. Im Test wurde sie zum Export der Daten genutzt.
Ergebnisse:
| Cluster-ID | Datensatz-IDs |
|---|---|
| 976a6fdc-f6da-4719-920d-8c60f0fe6c91 | 1, 2, 3, 4, 8, 9 |
| dda2d449-03d2-461d-9012-326b7b01d2ee | 5, 6 |
| 5b92221d-df4f-4acc-aaf8-bcfe0f0aac75 | 7 |
| b41199ac-2fb3-44a5-ad87-0ba7ca05e31b | 10 |
Das Ergebnis zeigt 4 Entitäten. Erreicht wurde das ohne jede zusätzliche Feinjustierung.
Fazit
Das wichtigste Kriterium für Entity-Resolution-Anwendungsfälle (ER) ist die Matching-Qualität, an zweiter Stelle steht die Bedienbarkeit, an dritter die Performance.
AWS hat einen neuen ER-Dienst geschaffen, um die steigende Nachfrage nach qualitativ hochwertigen Entitätsdaten zu bedienen, und ihn eng in das eigene Ökosystem integriert. Wie bei jedem AWS-Dienst ist zu erwarten, dass dies nur der Anfang ist und je nach Kundennachfrage weitere Funktionen hinzukommen.
Tilores ist eine zum Patent angemeldete Technologie, die von unterschiedlichsten Kunden eingesetzt wird und über zahlreiche Funktionen verfügt, mit denen sie sich für alle möglichen ER-Anwendungsfälle konfigurieren lässt.
Um den Vergleich fair zu halten, wurde für beide Systeme nur die einfachstmögliche Konfiguration verwendet.
Bei Kriterium 1 führte der AWS Entity Resolution Service die Datensätze im besten Fall (Regeln) zu 7 Entitäten zusammen. Tilores kam auf 4 Entitäten.
Kriterium 2 zeigt, wie eng der AWS-Dienst in sein Ökosystem integriert ist. Viele andere AWS-Dienste werden genutzt, gleichzeitig ist auf diesem Weg auch die Anbindung an weitere Dienste möglich. Für Nutzer ohne AWS-Erfahrung dauert die Konfiguration mindestens eine Stunde, für AWS-Experten nur wenige Minuten, da eine ausführliche Dokumentation erstellt wurde. Tilores benötigt dagegen nur 4 Klicks, um die Datensätze abzugleichen.
Kriterium 3: AWS ER brauchte zwischen 9 und 11 Minuten für den Testlauf. Wir gehen davon aus, dass diese Zeit für das Aufsetzen der gesamten Umgebung und das anschließende Ausführen des Auflösungsjobs nötig ist. Das werden wir mit einem größeren Datenbestand erneut testen. Die Einrichtung von Tilores dauerte 3 Minuten. Wie bei AWS ER muss zunächst die Instanz bereitgestellt werden. Der Abgleich selbst dauert nur wenige Millisekunden.
Was hat sich seit diesem Vergleich geändert? (Update 2026)
Der Praxistest oben beschreibt AWS Entity Resolution zum Marktstart, als der Dienst reiner Batch war. AWS hat ihn seither erweitert, sodass das heutige Bild differenzierter ist als „Batch vs. Echtzeit“:
- Near-Real-Time-Matching (Juni 2025). AWS hat Near-Real-Time-Matching ergänzt: Über die Generate Match ID API wird ein eingehender Datensatz mit den vorhandenen Datensätzen verglichen und „innerhalb von Sekunden“ eine konsistente Match-ID zurückgegeben. AWS weist darauf hin, dass dieser Near-Real-Time-Pfad für fortgeschrittenes regelbasiertes Fuzzy Matching nicht zur Verfügung steht.
- Inkrementelles ML-Matching (2026). AWS hat inkrementelle Machine-Learning-Matching-Workflows ergänzt, sodass ML-Übereinstimmungen sich mit eingehenden neuen Daten aktualisieren können und nicht nur in vollständigen Batch-Läufen.
- Drei Matching-Ansätze. Laut den FAQs zu AWS Entity Resolution bietet der Dienst inzwischen regelbasiertes Matching, ML-gestütztes Matching und den Abgleich über Datendienstleister (Matching auf IDs von Drittanbietern wie Ramp ID, TruAudience und UID2.0).
Was bedeutet das für die Echtzeitfrage? Near-Real-Time und Echtzeit sind nicht dasselbe. AWS liefert über einen API-Aufruf „innerhalb von Sekunden“ eine Übereinstimmung und schließt fortgeschrittenes Fuzzy Matching auf diesem Pfad aus; Tilores gleicht jeden Datensatz beim Einfügen in Millisekunden ab und verknüpft ihn — Fuzzy Matching eingeschlossen — und die aufgelösten Daten sind gleichzeitig über die GraphQL-API von Tilores durchsuchbar, betreibbar im eigenen AWS-Konto oder als SaaS. Für periodische Deduplizierung in großem Umfang ist ein Batch-Workflow oft das richtige Werkzeug; wenn der Abgleich im Moment der Datenaufnahme erfolgen soll und Fuzzy Matching dabei sein muss, passt eine Echtzeit-API nach wie vor besser.
Sehen Sie es an Ihren eigenen Daten: Buchen Sie eine Demo, um Echtzeit-Matching an Ihren eigenen Daten zu sehen, oder holen Sie sich den Evaluation Build, um es lokal auszuprobieren. Anschließend zeigt Ihnen die Entity-Resolution-Software von Tilores, wie Sie Echtzeit-Matching im eigenen AWS-Konto oder als SaaS betreiben.
Häufige Fragen
- Wie schnell sind Echtzeit-APIs für Entity Resolution im Vergleich zu Batch-Matching?
- Sie bewegen sich in unterschiedlichen Zeitdimensionen. Ein Batch-Dienst wie AWS Entity Resolution führt das Matching als geplanten oder ausgelösten Job aus; in diesem Test dauerte der AWS-Lauf zwischen 9 und 11 Minuten, inklusive Einrichtung der Umgebung und Auflösungsjob. Eine Echtzeit-API für Entity Resolution wie Tilores verknüpft und dedupliziert jeden Datensatz bereits beim Einfügen, wobei das Matching selbst nur wenige Millisekunden dauert – die Datensätze lassen sich also durchsuchen, während die Daten eintreffen. Batch-Matching eignet sich für periodische, geplante Deduplizierung.
- Unterstützt AWS Entity Resolution Echtzeit-Matching?
- Zum Zeitpunkt dieses Praxistests nicht — AWS Entity Resolution lief als Batch-Dienst. Seit Juni 2025 bietet AWS ein Near-Real-Time-Matching, das über die Generate Match ID API „innerhalb von Sekunden“ eine Match-ID zurückgibt; AWS merkt allerdings an, dass Near-Real-Time für fortgeschrittenes regelbasiertes Fuzzy Matching nicht verfügbar ist. Tilores gleicht jeden Datensatz beim Einfügen in Millisekunden ab, Fuzzy Matching eingeschlossen.
- AWS Entity Resolution vs. Tilores: Welches System hat die Testdaten genauer abgeglichen?
- Bei 10 nicht normalisierten Datensätzen, die sich auf 4 Cluster auflösen sollten, erzeugte das Machine-Learning-Matching von AWS null Übereinstimmungen (10 separate Entitäten) und das regelbasierte Matching von AWS 7 Entitäten, während Tilores die Datensätze ohne zusätzliche Feinjustierung zu den korrekten 4 Entitäten auflöste.
- Kann Tilores in meinem eigenen AWS-Konto laufen?
- Ja. Tilores kann im AWS-Konto des Kunden betrieben oder als SaaS-Dienst genutzt werden und ist auf dem AWS Marketplace verfügbar. Für diesen Vergleich wurde die Oberfläche des öffentlichen SaaS-Dienstes genutzt.
- Was hat sich an AWS Entity Resolution seit diesem Vergleich geändert?
- Seit diesem Test hat AWS Near-Real-Time-Matching (Juni 2025), inkrementelle Machine-Learning-Matching-Workflows (2026) und den Abgleich über Datendienstleister auf IDs von Drittanbietern wie Ramp ID, TruAudience und UID2.0 ergänzt. Die ursprüngliche Beschreibung bezieht sich auf die reine Batch-Version des Dienstes zum Marktstart.
Sehen Sie, was aufgelöste Entitätsdaten für Ihr Unternehmen — und Ihre KI — leisten.