Können LLMs für Entity Resolution eingesetzt werden?

Wie verhindere ich, dass LLM-Agenten zwei Kunden mit ähnlichen Namen verwechseln?

Die kurze Antwort: Lösen Sie die Identität auf, bevor das LLM sie zu sehen bekommt – mit deterministischem Matching, nicht mit dem Modell. Die folgende Tabelle stellt einen reinen LLM-Ansatz einem regelbasierten bzw. probabilistischen Entity-Resolution-System gegenüber, Kriterium für Kriterium; die vollständige Begründung folgt in den Abschnitten darunter.

Konsistenz & Zuverlässigkeit

Stellen Sie einem LLM dieselbe Frage in leicht abgewandelter Form, und die Chance ist groß, dass Sie eine andere Antwort erhalten. Die Frage „Sind John Smith, 123 Main St, und J. Smith, 123 Main Street, dieselbe Person?" kann vom selben LLM ein anderes Konfidenzniveau oder sogar eine widersprüchliche Antwort erhalten als die Frage „Beziehen sich diese Kundendatensätze auf dieselbe Person?".

Dazu kommen die schlichten Halluzinationen. Das heißt: Sie können sich nicht darauf verlassen, dass LLM-basierte Entity Resolution bei gleicher Datenlage immer dieselbe Fuzzy-Matching-Antwort liefert – in einem regulierten Umfeld ist das besonders gefährlich.

Ein regelbasiertes Entity-Resolution-System liefert immer dieselben Ergebnisse, wenn dieselben Daten wiederholt durch das System laufen.

Erklärbarkeit

„Das LLM sagt es" reicht nicht als Erklärung dafür, warum zwei Datensätze verknüpft wurden. Ja, Sie könnten das LLM bitten, jede paarweise Verbindung zu begründen, aber das erzeugt Zusatzaufwand und ändert nichts am oben beschriebenen Problem mit Konsistenz und Zuverlässigkeit.

In einem regelbasierten Entity-Resolution-System kann die Regel, die die Verknüpfung zweier Datensätze ausgelöst hat, im Entitätsgraphen selbst hinterlegt sein. So sehen Anwender (oder Aufsichtsbehörden!) genau, warum zwei Datensätze verknüpft wurden – bis hinunter zu der Frage, welche Algorithmen auf welche Datenattribute mit welchen Schwellenwerten und Gewichtungen angewendet wurden.

Precision & Feinjustierung

Beim Abgleich von Datensätzen in der Entity Resolution müssen Sie Precision (Falsch-Positiv-Rate) und Recall (Falsch-Negativ-Rate) je nach Anwendungsfall steuern können. In manchen Situationen – etwa bei einer Auskunftei – kann eine falsch positive Übereinstimmung sehr gefährlich sein und zu Bußgeldern führen; hier brauchen Sie eine sehr hohe Precision. In anderen Fällen, etwa in der Betrugserkennung, suchen Sie nach potenziellen Übereinstimmungen zwischen Kundenkonten: Dort wollen Sie hohen Recall und können Falsch-Positive tolerieren.

Bei LLM-basierter Entity Resolution lassen sich Match-Schwellen nicht ohne Weiteres anpassen, und eine anwendungsfallspezifische Matching-Toleranz ist kaum umsetzbar.

Regelbasierte Entity Resolution erlaubt eine auf Ihren Anwendungsfall zugeschnittene Matching-Genauigkeit. Jede Anpassung wird sofort sichtbar und messbar, sodass Sie Ihre Matching-Konfiguration feinjustieren und letztlich die für Ihren Anwendungsfall passende Genauigkeit erreichen können.

Zeitliche und transiente Verknüpfung

In einer spezialisierten Entity-Resolution-Lösung können Daten komplex werden, doch das System verarbeitet sie auf eine logische Weise, sodass sie verständlich und nutzbar bleiben. Menschen verändern sich beispielsweise im Lauf der Zeit: Ein Name kann sich ändern, jemand kann nacheinander mehrere Adressen oder E-Mail-Adressen haben. Ein Unternehmen kann umfirmieren oder mit einem anderen fusionieren.

Diese Datenbeziehung abzubilden kann bedeuten, dass die Datensätze A bis D nur transitiv verknüpft sind – über die Datensätze B und C, in einem sogenannten Entitätsgraphen. Eine solche Verbindung muss persistiert werden, damit sie für künftige Updates schlüssig bleibt.

Das ist etwas, das ein LLM bei einem großen Datenbestand nicht leisten kann, denn ein LLM kann über Tausende oder Millionen Datensätze hinweg kein echtes Gedächtnis für die Beziehungen zwischen den einzelnen Datensätzen aufrechterhalten.

Probleme bei Performance & Skalierbarkeit

LLMs sind schlicht langsam. Die Verarbeitung eines einzelnen Datensatzes kann einige Sekunden dauern, womit sie für Echtzeit-Anwendungsfälle wie Betrugserkennung oder Kunden-Onboarding völlig ungeeignet sind. Versuchen Sie, Entity Resolution für Hunderte oder Tausende Datensätze gleichzeitig durchzuführen, und Sie stoßen auf erhebliche Probleme.

Hochleistungsfähige Entity-Resolution-Systeme wie Tilores nehmen Datensätze in Millisekunden auf und verknüpfen sie – und gleichen parallel Tausende Datensätze pro Sekunde ab, ohne Leistungseinbußen.

Kosten

Token-basierte Preismodelle machen LLM-basierte Entity Resolution in großem Maßstab extrem teuer. Millionen von Entitätspaaren über API-Aufrufe zu verarbeiten wird unbezahlbar.

Speziell entwickelte Entity-Resolution-Lösungen sind auf Kosteneffizienz ausgelegt und verursachen damit geringere Betriebskosten bei hohem Datenvolumen. Und wir sprechen hier nicht von kleinen Unterschieden. Ein LLM für Entity Resolution einzusetzen kann leicht 100-mal und möglicherweise 1000-mal teurer sein als eine maßgeschneiderte Entity-Resolution-Lösung.

Dazu kommt das API-Rate-Limiting, das die meisten LLMs anwenden …

Vorschlaghammer für eine Nuss

Es gibt noch viele weitere Nachteile beim Einsatz von LLMs für Entity Resolution, aber ich denke, das Prinzip ist inzwischen klar. Ja, sie können Entity Resolution – aber LLMs sind nicht das richtige Werkzeug für eine Aufgabe, die bestehende, spezialisierte Entity-Resolution-Systeme längst lösen. Sie sind der sprichwörtliche Vorschlaghammer, mit dem eine Nuss geknackt wird, obwohl der Nussknacker seine Sache bereits ausgezeichnet macht.

Wann sollten wir LLMs in der Entity Resolution einsetzen?

Das mag klingen, als wären wir schlicht voreingenommen und LLM-feindlich, doch das trifft es nicht (gut, voreingenommen sind wir schon). LLMs sind eine der erstaunlichsten technischen Umwälzungen unserer Lebenszeit, und sie haben ihren Platz in der Entity Resolution – wenn man sie richtig einsetzt.

LLMs in der Named Entity Recognition

Named Entity Recognition (NER) bezeichnet das Extrahieren von Entitätsattributen aus unstrukturierten oder halbstrukturierten Daten. Stellen Sie sich vor, Sie hätten eine große Zahl von Strafgerichtsakten als Freitext. Ein LLM wäre hervorragend darin, die Namen der Angeklagten und der beteiligten Anwälte zu extrahieren und daraus strukturierte Gerichtsdatensätze zu erzeugen.

Sehr wahrscheinlich würde ein LLM Gerichtsakten, die zur selben Person gehören, jedoch mit Inkonsistenzen extrahieren – vor allem, wenn diese Person in mehrere Verfahren involviert ist. Wollte ich anschließend alle Gerichtsakten zu einer bestimmten Person verknüpfen, wäre in einem weiteren Schritt Entity Resolution nötig.

In dieser Hinsicht sind LLMs ein perfektes Vorverarbeitungswerkzeug vor der Entity Resolution: für Named Entity Recognition, die sich mit klassischen Verfahren des Natural Language Processing (NLP) nur schwer erreichen ließe.

LLMs in the Loop

Ein wichtiges Merkmal eines Entity-Resolution-Systems ist der sogenannte „Human in the Loop": Ein Mensch – etwa ein Datenanalyst oder ein Fachexperte – prüft vorgeschlagene paarweise Übereinstimmungen, die zusammengehören könnten, aber keinen eindeutigen Schwellenwert erreichen und deshalb eine manuelle Prüfung rechtfertigen.

Es kann durchaus machbar sein, den Menschen in diesem Prozess durch ein agentisches LLM zu ersetzen, das diese Entscheidungen trifft. Die oben genannten Schwächen der LLMs gelten weiterhin, aber bei einem hinreichend geringen Volumen an Übereinstimmungen – und unter der Annahme, dass selbst zwei menschliche Prüfer zu unterschiedlichen Ergebnissen kommen könnten – wäre das ein angemessener Einsatz von LLMs in der Entity Resolution.

Zu den Leitplanken für ein „LLM in the Loop" gehört, jede paarweise Verbindung in natürlicher Sprache zu begründen. Und solche agentisch erzeugten Verknüpfungen sollten im Entity-Resolution-System für ein mögliches späteres Audit durch Menschen gekennzeichnet werden.

Entity-Resolution-basiertes RAG für LLMs

Wo wir bei Tilores das Potenzial von LLMs in der Entity Resolution hoch einschätzen, ist tatsächlich die umgekehrte Richtung: ein Entity-Resolution-System als Datenquelle für LLMs zu nutzen – das sogenannte Retrieval-Augmented Generation (RAG).

Bei Tilores nennen wir das „IdentityRAG": Ein LLM wird über LangChain mit einer Tilores-Instanz verbunden, die Identitätsdaten (etwa Kundendaten) enthält. Wenn das LLM Informationen zu bestimmten Identitäten zuverlässig abrufen soll – etwa im Kundenservice –, glänzt ein Entity- bzw. Identity-Resolution-System in zwei Punkten: 1) Es stellt sicher, dass die korrekte Identität abgerufen wird, und 2) es liefert alle verfügbaren Informationen über diese Person aus den verstreuten Datenquellen einer Organisation.

Wo LLMs in der Entity Resolution weiterhin sinnvoll sind

• Für die schnelle Analyse kleiner Datenbestände würde ich wohl eher zu einem LLM greifen als zu einem Entity-Resolution-System wie Tilores
• Als Vorverarbeitungsschritt für Named Entity Recognition
• Als Ersatz für Menschen bei der agentischen Analyse von Grenzfällen.

Der aktuelle Stand (2026): Sieht die Forschung das genauso?

Dieser Beitrag argumentiert, dass LLMs Entity Resolution zwar können, es aber meist nicht tun sollten – aus Gründen der Konsistenz, Erklärbarkeit, Precision, Skalierbarkeit und Kosten. Stand 2026 hat die begutachtete und auf Konferenzen veröffentlichte Forschung genau das geprüft und stimmt weitgehend zu:

• Die Kosten sind real und strukturell bedingt. Eine Studie aus dem Jahr 2024, On Leveraging Large Language Models for Enhancing Entity Resolution: A Cost-efficient Approach (arXiv 2401.03426), hält fest, dass aktuelle LLMs „aufgrund der Abrechnung pro API-Anfrage kostspielig" sind und dass bestehende Verfahren „entweder qualitativ unzureichend oder in großem Maßstab unbezahlbar teuer" werden – weshalb sie vorschlägt, gezielt nur die wertvollsten Match-Paare abzufragen statt jedes Paar.
• Der teure Teil ist das naive paarweise Matching. Ein SIGMOD-2026-Paper, In-context Clustering-based Entity Resolution with Large Language Models (arXiv 2506.02509, Juni 2025), stellt fest, dass auf paarweises Matching ausgerichtete Verfahren „zeitlich wie finanziell aufwendig sind, insbesondere bei großen Datensätzen", und dass stattdessen Clustering die Zahl der API-Aufrufe bei vergleichbaren Kosten um bis zu das Fünffache reduzierte.
• Matching mit einem einzelnen LLM braucht Koordination und Leitplanken. Eine Studie vom Dezember 2025 in MDPI Computers, Multi-Agent RAG Framework for Entity Resolution, berichtet von 94,3 % Genauigkeit beim Abgleich von Namensvarianten und von 61 % weniger API-Aufrufen gegenüber Baselines mit einem einzelnen LLM – ein weiterer Beleg dafür, dass produktionsreife Ergebnisse aus der Struktur rund um das Modell entstehen und nicht aus einem einzelnen LLM-Aufruf, also genau aus dem oben beschriebenen Muster „LLM in the Loop".

Die praktische Erkenntnis für 2026 zu der Frage, mit der dieser Artikel beginnt – wie verhindert man, dass ein LLM-Agent zwei Kunden mit ähnlichen Namen verwechselt –, bleibt unverändert: Halten Sie das Identitäts-Matching deterministisch und erklärbar und nutzen Sie das LLM andersherum, indem es über IdentityRAG eine einzige aufgelöste Identität abruft. Tilores hat dazu für regulierte Umfelder mehr geschrieben in LLM-Genauigkeit mit Entity-Resolution-basiertem RAG verbessern.

Häufig gestellte Fragen

Können LLMs für Entity Resolution eingesetzt werden?

Jein. Bei zwei Datensätzen oder einer kurzen Liste kann ein LLM entscheiden, ob sie zur selben Identität gehören, und macht das vermutlich ordentlich. Für Entity Resolution im Produktivbetrieb ist es jedoch ein Vorschlaghammer für eine Nuss: LLMs sind schwach bei Konsistenz und Zuverlässigkeit, Erklärbarkeit, Precision und Feinjustierung, zeitlicher und transienter Verknüpfung, Performance und Skalierbarkeit sowie bei den Kosten. Spezialisierte Entity-Resolution-Systeme lösen diese Aufgabe längst.

Wie verhindere ich, dass LLM-Agenten zwei Kunden mit ähnlichen Namen verwechseln?

Lassen Sie das Matching nicht das LLM selbst erledigen. Setzen Sie ein deterministisches Entity-Resolution-System davor und übergeben Sie dem LLM eine einzige aufgelöste Identität. Bei Tilores heißt das IdentityRAG: Das LLM wird über LangChain mit einer Tilores-Instanz verbunden, die Identitätsdaten enthält, sodass die korrekte Identität abgerufen und alle verfügbaren Informationen zu dieser Person aus verstreuten Quellen zusammengeführt werden, bevor das LLM antwortet. Ein LLM, dem dieselbe Matching-Frage auf zwei leicht unterschiedliche Arten gestellt wird, kann widersprüchliche Antworten geben – deshalb muss die Auflösung deterministisch und erklärbar sein und darf nicht dem Modell überlassen werden.

Wo scheitern LLMs in der Entity Resolution, und wo passen sie?

LLMs scheitern an sechs Punkten: Konsistenz und Zuverlässigkeit, Erklärbarkeit, Precision und Feinjustierung, zeitliche und transiente Verknüpfung, Performance und Skalierbarkeit sowie Kosten. Sie passen in drei engere Rollen: die schnelle Analyse kleiner Datenbestände, Named Entity Recognition (NER) als Vorverarbeitungsschritt und als Ersatz für den Menschen bei der agentischen Prüfung von Grenzfällen. Am wertvollsten ist der umgekehrte Weg – ein Auflösungssystem als Datenquelle für das LLM via IdentityRAG.

Warum ist der Einsatz eines LLM für Entity Resolution in großem Maßstab so teuer?

Token-basierte Abrechnung pro API-Anfrage macht LLM-basierte Entity Resolution in großem Maßstab extrem teuer: Millionen von Entitätspaaren über API-Aufrufe zu verarbeiten wird unbezahlbar. Tilores beziffert das auf leicht das 100-Fache und möglicherweise das 1000-Fache einer maßgeschneiderten Entity-Resolution-Lösung – noch bevor das API-Rate-Limiting überhaupt berücksichtigt ist. Die begutachtete Forschung sieht das genauso: Eine arXiv-Studie von 2024 hält fest, dass aktuelle LLMs wegen der Abrechnung pro API-Anfrage kostspielig sind und dass die Verfahren entweder qualitativ unzureichend oder in großem Maßstab unbezahlbar teuer werden.

Wo ergeben LLMs in der Entity Resolution tatsächlich Sinn?

An drei Stellen. Für die schnelle Analyse kleiner Datenbestände ist ein LLM völlig ausreichend, bevor man zu einem System wie Tilores greift. Als Vorverarbeitungsschritt für Named Entity Recognition (NER), um strukturierte Attribute aus Freitext zu extrahieren. Und als Ersatz für den Menschen bei der agentischen Analyse von Grenzfällen („Human in the Loop") – bei hinreichend geringem Volumen an Übereinstimmungen und mit Leitplanken, die jede paarweise Verbindung in natürlicher Sprache begründen und für ein späteres Audit kennzeichnen.

Was ist IdentityRAG, und wie nutzt es LLMs in der richtigen Richtung?

IdentityRAG nutzt ein Entity-Resolution-System als Datenquelle für LLMs, statt das LLM die Auflösung erledigen zu lassen. Bei Tilores wird ein LLM über LangChain mit einer Tilores-Instanz verbunden, die Identitätsdaten (etwa Kundendaten) enthält. Wenn das LLM Informationen zu einer bestimmten Identität abrufen soll – etwa im Kundenservice –, stellt das Entity- bzw. Identity-Resolution-System sicher, dass die korrekte Identität abgerufen wird, und liefert alle verfügbaren Informationen zu dieser Person aus den verstreuten Datenquellen der Organisation.