Echtzeit- vs. Batch-Entity-Resolution: Wann Sie was brauchen

Von Steven Renwick, CEO und Mitgründer, Tilores.

Kurzfassung: Setzen Sie Entity Resolution in Echtzeit ein, wenn eine laufende Anwendung, ein KI-Agent, eine Betrugsprüfung oder ein Support-Prozess auf dem aktuellen aufgelösten Datensatz handeln muss. Setzen Sie Batch-Entity-Resolution für abgegrenzte Offline-Arbeit ein: regelmäßige Deduplizierung, historische Backfills, Warehouse-Ladeläufe und kostenkontrollierte Abstimmung, bei denen keine Live-Entscheidung wartet.

Sehen Sie es an Ihren Daten: Buchen Sie eine Demo, um Entity Resolution in Echtzeit für Ihre Live-Prozesse durchzugehen, oder holen Sie sich den Evaluierungs-Build, um es lokal zu testen – und sehen Sie sich anschließend die Tilores Entity-Resolution-Software für Teams an, die aktuellen aufgelösten Kundenkontext in Live-Systemen brauchen.

Echtzeit vs. Batch bei Entity Resolution: Was ändert sich?

Entity Resolution, Identity Resolution und Record Linkage beschreiben alle dasselbe Kernproblem: zu entscheiden, welche Datensätze sich auf dieselbe reale Person, dasselbe Unternehmen oder denselben Gegenstand beziehen. Das Springer-Standardwerk zum Data Matching beschreibt dies als das Erkennen, Abgleichen und Zusammenführen von Datensätzen, die in einer oder mehreren Datenbanken denselben Entitäten entsprechen.

Bei der Entscheidung zwischen Echtzeit und Batch geht es nicht darum, ob der Abgleich deterministisch oder probabilistisch erfolgt. Gute Entity Resolution kombiniert häufig deterministische Regeln, probabilistisches ML-Matching und Fuzzy Matching. Es geht darum, wann der Abgleich stattfindet, ab wann die aufgelöste Sicht nutzbar ist und ob ein Live-System davon abhängt.

Dimension	Entity Resolution in Echtzeit	Batch-Entity-Resolution
Wann der Abgleich stattfindet	Sobald Datensätze oder Events eingelesen werden, sodass sich die aufgelöste Entität laufend aktualisieren kann.	Während eines geplanten oder ausgelösten Jobs über einen abgegrenzten Datenbestand, Export oder Dateisatz.
Latenz bis zu einem nutzbaren aufgelösten Datensatz	Für den Live-Einsatz nach Ingestion und Abgleich ausgelegt – abhängig von der Implementierung und der Verzögerung im Quellsystem.	Verfügbar, sobald der Batch-Job abgeschlossen und das Ergebnis in das verbrauchende System geladen ist.
Eignung für KI-Agenten und Live-Entscheidungen	Sehr gut geeignet, wenn ein Agent, eine Anwendung oder ein Support-Prozess aktuellen aufgelösten Kontext zur Abfragezeit abrufen muss.	Kaum geeignet für Live-Entscheidungen; nützlich zur Aufbereitung von Offline-Datenbeständen oder regelmäßigen Momentaufnahmen.
Eignung für Betrugs- und AML-Prüfungen	Sehr gut geeignet, wenn Onboarding-, Zahlungsrisiko- oder Monitoring-Entscheidungen von der aktuellsten Kunden- und Beziehungssicht abhängen.	Nützlich für regelmäßige Überprüfung, rückblickende Ermittlung und Offline-Risikoanalyse.
Eignung für regelmäßige Deduplizierung und Backfill	Kann neue Datensätze nach dem Erstladen aufnehmen, ist aber womöglich unnötig, wenn nichts Live-Relevantes vom Ergebnis abhängt.	Sehr gut geeignet für einmalige historische Ladeläufe, monatliche Deduplizierung, statische Exporte und kostenbegrenzte Abstimmung.
Aktualität der aufgelösten Sicht	Aktuell bis zum Stand des Ingestion-Pfads und der Korrekturlogik.	Eine Momentaufnahme der Daten zum Zeitpunkt des Job-Laufs.
Typisches Kostenprofil	Laufende Servicekosten und operative Verantwortung – gerechtfertigt, wenn Aktualität Ergebnisse verändert.	Begrenzte Compute- und Speicherkosten, effizient, wenn die Arbeit warten kann.
Operative Komplexität	Erfordert zuverlässige Ingestion, idempotente Aktualisierungen, Korrekturbehandlung, Observability und ein durchdachtes Abfrage-Design.	Erfordert Exportdisziplin, Scheduling, Job-Monitoring, das Laden der Ergebnisse und ein sauberes Wiederanlaufverhalten.

Wann brauchen Sie Entity Resolution in Echtzeit?

Sie brauchen Entity Resolution in Echtzeit, wenn die Antwort verändert, was ein System jetzt tut. Wenn ein Kunde sich registriert, eine Zahlung startet, einen Supportfall eröffnet, einem KI-Agenten eine Frage stellt oder seine E-Mail-Adresse ändert, sollte sich die Anwendung nicht auf das Deduplizierungsergebnis von gestern verlassen – jedenfalls dann nicht, wenn die Identitätsentscheidung Risiko, Zugriff, Datenschutz oder Kundenerlebnis beeinflusst.

Besonders deutlich wird das in der Betrugs- und AML-Arbeit. Die CDD-FAQs von FinCEN beschreiben laufende Kundensorgfaltspflichten als fortlaufendes Monitoring, um verdächtige Transaktionen zu erkennen und zu melden und Kundeninformationen risikobasiert zu pflegen und zu aktualisieren. Das lässt sich schwer gut unterstützen, wenn der Identitätslayer nur einen periodischen Export sieht.

Echtzeit-Auflösung ist auch dann die richtige Wahl, wenn ein aufgelöster Datensatz Teil des Auslieferungspfads einer Anwendung ist. Tilores löst Datensätze bei der Ingestion auf und verknüpft sie; Anwendungen rufen den aktuellen aufgelösten Kontext dann zur Abfragezeit ab. Diese Unterscheidung ist wichtig: Die Entität wird nicht im KI-Prompt oder erst zur Abfragezeit zusammengesetzt – die Anwendung fragt eine aktuelle aufgelöste Sicht ab, die der Identitätslayer bereits gepflegt hat.

Reicht Batch-Matching für KI-Agenten?

Batch-Matching reicht für KI-Agenten nur dann, wenn der Agent auf einem Offline-Datenbestand arbeitet und keine laufende Kunden- oder Transaktionsentscheidung von der Antwort abhängt. Es reicht nicht, wenn der Agent während einer laufenden Interaktion einem Kunden antworten, ein Ticket aktualisieren, Risiko bewerten, einen Fall weiterleiten oder ein Tool aufrufen muss.

Moderne Agenten nutzen externe Funktionen, um Daten abzurufen und Aktionen in Anwendungen auszulösen. Die offizielle Dokumentation zum Function Calling beschreibt dieses Muster als Weg für Modelle, mit externen Systemen zu kommunizieren und auf Daten außerhalb des Modells zuzugreifen. Die zugehörige Agenten-Dokumentation beschreibt dasselbe Muster für das Abrufen von Daten, das Aufrufen von APIs und das Ausführen von Aktionen.

Liefert das Tool eine veraltete oder fragmentierte Kundensicht, kann das Modell trotzdem eine flüssige Antwort erzeugen. Das Problem ist, dass sie auf dem falschen Kunden, dem falschen Konto oder einem unvollständigen Beziehungsgraphen beruhen kann. Aus demselben Grund ist Vektorsuche kein Ersatz für Identity Resolution. Vektorsuche kann ähnliche Dokumente finden; sie sollte nicht entscheiden, ob zwei Kundendatensätze dieselbe Person oder dasselbe Unternehmen betreffen.

Mehr zu dieser Abgrenzung finden Sie im Tilores-Artikel dazu, ob LLMs für Entity Resolution eingesetzt werden können, sowie im zugehörigen Artikel zu EntityRAG.

Wo ist Batch-Entity-Resolution weiterhin sinnvoll?

Batch-Entity-Resolution bleibt sinnvoll, wenn die Eingabe abgegrenzt ist und kein Live-Prozess das Ergebnis benötigt. Dazu zählen die monatliche Deduplizierung von Marketinglisten, eine einmalige Migration aus einem Alt-CRM, ein historischer Backfill vor dem Start, die Abstimmung im Data Warehouse, die Vorbereitung von Analysen und die regelmäßige Datenqualitätsprüfung.

Das Schulungsmaterial von Apache Flink liefert eine nützliche allgemeine Unterscheidung: Batch-Verarbeitung arbeitet über begrenzte Streams, Stream-Verarbeitung über unbegrenzte Streams, die verarbeitet werden, während die Daten eintreffen. Die Dokumentation zum Ausführungsmodus hält außerdem fest, dass der Batch-Modus für begrenzte Jobs mit bekannter, fester Eingabe gedacht ist, die nicht dauerhaft laufen, während der Streaming-Modus für kontinuierliche inkrementelle Verarbeitung vorgesehen ist.

Das lässt sich sauber auf Record Linkage übertragen. Ist die Eingabe ein fester Export und braucht das Unternehmen nur eine final abgestimmte Datei, ist Batch oft einfacher und günstiger. Treffen dagegen laufend neue Datensätze ein und muss die Anwendung die aktuelle Entitätssicht abfragen, erzeugt es vermeidbare Veralterung, das Problem als nächtlichen Dateijob zu behandeln.

Ein brauchbarer Test: Wenn das System auf den Abschluss des Jobs warten kann, ist Batch womöglich in Ordnung. Wenn ein Kunde, ein Agent, eine Transaktion oder eine Risikoentscheidung wartet, nehmen Sie Echtzeit-Auflösung.

Streaming vs. Batch bei Record Linkage: Worin besteht der eigentliche Unterschied?

Streaming-Record-Linkage bedeutet, dass der Identitätslayer neue Datensätze aufnehmen und die aufgelöste Sicht aktualisieren kann, während das System weiterläuft. Batch-Record-Linkage bedeutet, dass das System einen bekannten Datensatzbestand verarbeitet, eine Ausgabe erzeugt und ein anderes System diese Ausgabe anschließend verarbeitet.

Die Matching-Logik kann in beiden Modi ähnlich sein. Sie brauchen weiterhin Normalisierung, Blocking oder Indexierung, Feldvergleiche, deterministische Regeln, Fuzzy Matching, probabilistisches Scoring, Schwellenwerte, Prüfprozesse und Korrekturmöglichkeiten. Der Unterschied besteht darin, dass Echtzeitsysteme den aufgelösten Entitätszustand sicher pflegen müssen, während Datensätze eintreffen, während Batch-Systeme die Ausgabe bis zum Abschluss des Jobs zurückstellen können.

Deshalb greift die einfache Formel „Echtzeit ist schneller“ zu kurz. Die Frage ist, ob die aufgelöste Entität Teil der laufenden Betriebsfläche ist. Bei einer Live-Betrugsprüfung kann eine veraltete oder fragmentierte Identität dazu führen, dass wiederholter Missbrauch wie ein Neukunde aussieht. Bei einem KI-Support-Agenten kann veralteter Kontext dazu führen, dass der Agent aus dem falschen Ticket oder Konto antwortet. Bei einer monatlichen Warehouse-Deduplizierung kann dieselbe Verzögerung völlig unproblematisch sein.

Tilores ist für die Echtzeit-Seite dieser Entscheidung gebaut: Datensätze werden aufgelöst, sobald sie eingelesen werden, und Anwendungen können den aktuellen aufgelösten Kontext über eine API abrufen. Der Tilores-Vergleich von AWS Entity Resolution und Tilores ist eine nützliche ergänzende Lektüre für Teams, die bewerten, wie sich Batch- und API-orientierte Ansätze in der Praxis verhalten.

Wann was: die Entscheidungsliste

KI-Agent beantwortet eine laufende Kundenanfrage → Echtzeit. Der Agent muss auf dem aktuellen aufgelösten Datensatz handeln, nicht auf der Momentaufnahme der vergangenen Nacht.
Monatliche Deduplizierung einer statischen Marketingliste → Batch. Keine Live-Entscheidung hängt vom Ergebnis ab; kostenbegrenzte Offline-Abstimmung genügt.
Betrugs- oder Zahlungsrisikoprüfung in Echtzeit → Echtzeit. Eine veraltete oder fragmentierte Identität kann dazu führen, dass ein wiederkehrender Kunde, ein Konto oder ein Gerät im Entscheidungsmoment unverbunden wirkt.
Einmaliger historischer Backfill oder Erstladelauf → Batch. Ein abgegrenzter Job über einen festen Datenbestand ist meist der sauberste Weg, die erste aufgelöste Ausgangsbasis zu schaffen.
Support-Assistent aktualisiert ein laufendes Ticket → Echtzeit. Der Assistent braucht den aktuellen Konto-, Kontakt-, Anspruchs- und Beziehungskontext, bevor er formuliert oder handelt.
Ladelauf für Warehouse-Analysen → Batch. Wenn das Warehouse eine tägliche oder wöchentliche Momentaufnahme verarbeitet und Analysten daraus keine laufenden operativen Entscheidungen treffen, ist Batch angemessen.
Laufendes KYC- oder AML-Beziehungsmonitoring → meist Echtzeit für die Betriebssicht, Batch für Prüfpakete. Das Live-System braucht aktuelle Beziehungen; Compliance-Teams können weiterhin periodische Auszüge für die Prüfung nutzen.
Kostenbegrenzte Abstimmung eines alten Archivs → Batch. Ist das Archiv statisch und soll einmalig bereinigt werden, lässt sich ein Offline-Job leichter budgetieren und prüfen.

Wie passt das neben MDM, CDP, Governance und Data Warehouse?

Entity Resolution sollte nicht als Ersatz für MDM, CDP, Data Governance, KYC-/AML-Systeme oder ein Data Warehouse positioniert werden. Sie steht daneben. MDM kann die Datenpflege und das Stammdaten-Betriebsmodell verantworten. Eine CDP kann Aktivierung und Zielgruppenprozesse verantworten. Ein Data Warehouse kann die Analytik verantworten. Governance-Systeme können Richtlinien, Lineage und Aufbewahrung verantworten. KYC- und AML-Plattformen können Screening, Fallmanagement und regulatorische Abläufe verantworten.

Der Identity-Resolution-Layer beantwortet eine engere Frage: Welche Quelldatensätze gehören zu derselben realen Entität – mit genügend Belegen und genügend Aktualität, damit das verbrauchende System die Antwort nutzen kann. Sobald diese Antwort existiert, können die anderen Systeme ihre eigene Aufgabe mit weniger Dopplung und weniger Fragmentierung erledigen.

Diese Ergänzung ist architektonisch wichtig. Ein Batch-Job kann ein Data Warehouse oder eine Datenpflegeprüfung speisen. Ein Identity-Resolution-Layer in Echtzeit kann einen KI-Agenten, eine Betrugsprüfung, einen Onboarding-Flow oder eine kundenseitige Anwendung bedienen. Viele reife Teams brauchen beides. Der Fehler besteht darin, den langsameren Offline-Pfad zur Abhängigkeit einer Live-Entscheidung zu machen.

FAQ

Was ist der Unterschied zwischen Echtzeit- und Batch-Entity-Resolution?

Entity Resolution in Echtzeit löst Datensätze auf, sobald sie eintreffen, und hält die aufgelöste Sicht für Live-Abfragen aktuell. Batch-Entity-Resolution läuft über einen abgegrenzten Datenbestand oder Export und liefert Ergebnisse nach Abschluss des Jobs. Nutzen Sie Echtzeit für Live-Entscheidungen und Batch, wenn Daten und Entscheidung warten können.

Wann brauche ich Identity Resolution in Echtzeit?

Sie brauchen Identity Resolution in Echtzeit, wenn eine Anwendung, ein KI-Agent, eine Betrugsprüfung, ein Onboarding-Flow oder ein Support-Prozess auf dem aktuellen aufgelösten Datensatz handeln muss. Fällt die Entscheidung, während ein Kunde oder eine Transaktion aktiv ist, ist die Match-Datei der vergangenen Nacht in der Regel die falsche Abhängigkeit.

Reicht Batch-Matching für KI-Agenten?

Batch-Matching kann Offline-Datenbestände für KI-Systeme aufbereiten, reicht aber nicht, wenn ein KI-Agent während einer laufenden Interaktion antworten oder handeln muss. Der Agent sollte den aktuellen aufgelösten Kontext zur Abfragezeit aus Datensätzen abrufen, die bereits bei der Ingestion aufgelöst wurden.

Können Echtzeit- und Batch-Entity-Resolution nebeneinander laufen?

Ja. Viele Teams nutzen Batch-Jobs für historische Backfills, Warehouse-Abstimmung und regelmäßige Deduplizierung und setzen zugleich Echtzeit-Auflösung für neue Events und Live-Entscheidungen ein. Wichtig ist, den Auslieferungspfad ausdrücklich festzulegen, damit Anwendungen wissen, welche Sicht sie gerade nutzen.