Identity Resolution für LLMs: Was IdentityRAG ist und warum es zählt

Kurzfassung:

Identity Resolution für LLMs ist der Prozess, die über verschiedene Systeme verstreuten Datensätze einer Person zu einem korrekten, einheitlichen Profil zusammenzuführen, das ein Sprachmodell zur Abfragezeit abrufen kann – statt das Modell raten zu lassen, wer der Kunde ist.

IdentityRAG ist das Muster, bei dem das LLM dieses Profil bei einem dedizierten Entity-Resolution-System in Echtzeit abfragt, statt den Identitätsabgleich selbst vorzunehmen – was es unzuverlässig, langsam und nicht nachvollziehbar tut.

Es zählt, weil ein kundenseitiges LLM, das zwei Personen verwechselt oder die falschen Datensätze zusammenfügt, nicht nur schlecht aussieht: In regulierten Prozessen wie KYC, AML und Support ist das ein Compliance- und Vertrauensversagen.

Identity Layer

Lösen Sie den Kunden auf, bevor Ihre KI schlussfolgert.

Lösen Sie den Kundenkontext auf, bevor das Modell darüber schlussfolgert.

Tilores IdentityRAG in Aktion sehen

Auflösungspfad

Vektordatenbank

Dokumente

MDM / CDP

Datensätze

Tilores API

aufgelöste Identität

Large Language Models sind außergewöhnlich gut in Sprache und unzuverlässig bei Identität. Fragen Sie ein Modell, wer „J. Smith, +44 7700 900123“ ist, und es wird selbstbewusst eine Antwort zusammensetzen – mal aus den richtigen Datensätzen, mal aus zwei verschiedenen Kunden, die zufällig denselben Namen tragen. Bei einem Marketing-Chatbot ist das peinlich. Beim Onboarding-Agenten einer Bank ist es ein aufsichtsrechtlicher Vorfall. Dieser Artikel definiert Identity Resolution für LLMs, erklärt das IdentityRAG-Muster, das dieses Problem löst, und zeigt, warum es zu einer notwendigen Schicht in jedem KI-System wird, das echte Kundendaten berührt.

Was ist Identity Resolution für LLMs?

Identity Resolution für LLMs ist der Prozess, die über CRM, Support, Billing und Produktsysteme verstreuten Datensätze einer Person oder eines Unternehmens zu einem einzigen korrekten Profil aufzulösen, das ein Sprachmodell abrufen kann, wenn es über genau diese Entität schlussfolgern soll. Entity Resolution selbst ist, in den Worten von Tilores, „das Verbinden nicht identischer, aber zusammengehöriger Daten aus verschiedenen Quellen zu ‚Entitäten’“ – wobei Entitäten Personen, Unternehmen oder Finanztransaktionen sein können. Das „für LLMs“ ist die neue Anforderung: Das aufgelöste Profil muss in der Geschwindigkeit und in der Form verfügbar sein, die ein LLM braucht – in Echtzeit, im Kontextfenster des Modells.

Entscheidend ist die Frage, wer den Abgleich vornimmt. Ohne Identity Resolution wird implizit vom LLM verlangt, den Abgleich selbst durchzuführen – also aus einem Haufen abgerufener Textstellen zu entscheiden, welche Datensätze zu derselben Person gehören. Mit Identity Resolution trifft ein eigens dafür gebautes System diese Entscheidung konsistent und nachvollziehbar genug für ein Audit, und das LLM verarbeitet lediglich das aufgelöste Ergebnis.

Was ist IdentityRAG?

IdentityRAG ist ein Retrieval-Muster, bei dem ein Large Language Model den Kundenkontext aus einem dedizierten Entity-Resolution-System in Echtzeit abruft, statt Identitäten selbst aufzulösen. Tilores beschreibt es unmissverständlich: „Tilores nutzt IdentityRAG-Technologie, um Chatbots auf Basis von Large Language Models (LLMs) Kontext über Ihre Kunden bereitzustellen“ – und verbindet das Modell über LangChain und Amazon Bedrock mit einer Tilores-Instanz, die einheitliche Identitätsdaten vorhält.

Der entscheidende Entwurfsschritt ist, dass das Muster die Beziehung umdreht: LLMs fragen ein spezialisiertes System ab, statt die Auflösung selbst vorzunehmen. Klassisches Retrieval-Augmented Generation (RAG) holt Dokumente nach semantischer Ähnlichkeit. IdentityRAG holt eine aufgelöste Entität: jeden Datensatz, der tatsächlich zu einem Kunden gehört, zu einem Profil zusammengeführt – wobei die Matching-Logik in der Entity-Resolution-Schicht liegt und nicht im Raten des Modells.

Wie funktioniert IdentityRAG?

IdentityRAG arbeitet in drei Stufen – vereinheitlichen, auflösen, abrufen –, die zur Abfragezeit ausgeführt und nicht vorab festgeschrieben werden. Tilores gliedert den Ablauf in drei Bausteine:

Datenvereinheitlichung. Verstreute Kundendaten aus allen Quellsystemen – Salesforce, HubSpot, Zendesk, Mailchimp, Snowflake und weitere – werden zu einer durchsuchbaren Schicht verbunden.
Identity Resolution. Die Matching-Algorithmen arbeiten mit „jeder verfügbaren Ähnlichkeit von Identitätsattributen, darunter Name, Adresse, Geburtsdatum, E-Mail, Telefonnummer, Gerät“ – also mit unscharfem, probabilistischem Abgleich statt exakter Zeichenkettengleichheit.
Abruf in Echtzeit. Das System „erstellt dynamische Kundenprofile zur Abfragezeit“ und übergibt dem LLM in Echtzeit ein einheitliches, aktuelles Profil.

Was das von einer nächtlichen Datenpipeline unterscheidet, ist der Golden Record zur Lesezeit. Tilores bildet den Golden Record „zur Lesezeit statt zur Schreibzeit“ – das einheitliche Profil wird also genau dann zusammengesetzt, wenn der Agent fragt. Es spiegelt damit den aktuellen Stand in jedem Quellsystem wider, ohne veraltete vorberechnete Zusammenführung. Tilores gibt Antwortzeiten von „unter 150 Millisekunden“ an – schnell genug für ein laufendes Gespräch.

Warum kann ein LLM Entity Resolution nicht einfach selbst erledigen?

Ein LLM kann Entity Resolution nicht zuverlässig selbst erledigen, weil es an genau den fünf Punkten scheitert, die produktiver Identitätsabgleich verlangt. Das Tilores-Team hat seine Resolution-Engine ursprünglich für die Betrugsprävention und Geldwäschebekämpfung einer europäischen Verbraucher-Auskunftei gebaut. Sein Argument gegen ein LLM als Matcher: „ein Vorschlaghammer für eine Nuss“.

Konsistenz. „Stellen Sie einem LLM dieselbe Frage in leicht abgewandelter Form, und die Wahrscheinlichkeit ist hoch, dass Sie eine andere Antwort bekommen“ – dazu kommen „schlichte Halluzinationen“. Identitätsabgleich muss wiederholbar sein.
Erklärbarkeit. „‚Das LLM sagt das’ reicht nicht aus, um zu erklären, warum zwei Datensätze verknüpft wurden.“ Regulierte Prozesse brauchen einen Audit-Trail; eine konfigurierbare Matching-Engine mit einem Entitätsgraphen dahinter liefert ihn.
Precision und Feinjustierung. Verschiedene Aufgaben brauchen verschiedene Schwellenwerte: Eine Auskunftei optimiert gegen False Positives, die Betrugserkennung nimmt sie zugunsten von Recall in Kauf. Modelle lassen sich so nicht justieren, konfigurierbare Matcher schon.
Zeitliches und relationales Gedächtnis. Namensänderungen, mehrere Adressen im Zeitverlauf, Unternehmensfusionen – dafür braucht es einen persistenten Entitätsgraphen, den „ein LLM nicht wirklich pflegen kann“.
Geschwindigkeit und Kosten. „LLMs sind schlicht langsam. Die Verarbeitung eines einzelnen Datensatzes kann einige Sekunden dauern“, und LLM-basiertes Matching kann „100-mal teurer und womöglich tausendfach teurer“ sein als ein spezialisiertes System.

Die Schlussfolgerung lautet nicht „Finger weg von LLMs“. Sie lautet: Lassen Sie das LLM die Sprache übernehmen und ein dediziertes System die Identität. Genau diese Arbeitsteilung formalisiert IdentityRAG.

Wo gehört Identity Resolution im KI-Stack hin?

Identity Resolution gehört zwischen Ihre Quellsysteme und Ihr LLM – als Retrieval-Schicht, die das Modell immer dann aufruft, wenn es wissen muss, über wen es spricht. In der Praxis steht sie neben Ihrer Vektordatenbank, nicht darin. Beide lösen unterschiedliche Probleme: Ein Vektorspeicher findet semantisch ähnlichen Text, eine Entity-Resolution-API liefert die korrekte, zusammengeführte Datensatzmenge zu einer Identität. Der folgende Vergleich macht die Aufteilung greifbar.

Schicht	Was sie abruft	Gut für	Falsches Werkzeug für
Vektordatenbank (semantisches RAG)	Textabschnitte, sortiert nach Embedding-Ähnlichkeit	Dokumente, Wissen, FAQs	Die Entscheidung, welche Datensätze denselben Kunden betreffen
Entity-Resolution-API (IdentityRAG)	Ein einheitliches Profil, zusammengesetzt aus abgeglichenen Datensätzen	Präzise Kunden- und Unternehmensidentität in Echtzeit	Offene Dokumentensuche
Das LLM	Schlussfolgern und Antworten in natürlicher Sprache	Zusammenfassen, Erklären, Dialog	Wiederholbaren, auditierbaren Identitätsabgleich

Ein ausgereiftes kundenseitiges KI-System nutzt in der Regel beides: Vektor-RAG für „Was sagt unsere Rückerstattungsrichtlinie?“, IdentityRAG für „Wer ruft hier an, und was hat diese Person gekauft?“.

Warum ist Identity Resolution für LLMs gerade jetzt relevant?

Sie ist jetzt relevant, weil KI vom Verfassen von Texten dazu übergegangen ist, auf echten Kundendatensätzen zu handeln – und weil die Kosten eines Identitätsfehlers sich von peinlich zu gefährlich gewandelt haben. Ein Modell, das 2024 ein Support-Ticket zusammenfasste, durfte ungefähr richtig liegen. Ein Agent, der 2026 die Historie eines Anrufers liest, eine Rückerstattung freigibt oder eine KYC-Entscheidung trifft, darf das nicht: Zwei Kunden zu verwechseln wird zur Datenschutzverletzung, zur falschen finanziellen Handlung oder zum Compliance-Verstoß. Die folgende Tabelle zeigt, wie das Risiko mit der Autonomie wächst.

KI-Anwendungsfall	Kosten einer Kundenverwechslung	Anforderung an Identity Resolution
Assistent für Marketingtexte	Gering – generische Ausgabe	Optional
Support-Chatbot (nur lesend)	Mittel – falscher Kontokontext	Empfohlen
Agent, der Aktionen ausführt (Rückerstattungen, Änderungen)	Hoch – falsche Aktion auf dem falschen Konto	Erforderlich
KYC-, AML- oder Kreditentscheidungen	Gravierend – aufsichtsrechtlich und finanziell	Erforderlich, mit Audit-Trail

Die Kundenbelege von Tilores zeigen, was dabei zu gewinnen ist: Der Fintech-Kreditgeber Banxware berichtet von einem „Rückgang der Bearbeitungszeit für manuelle Kreditentscheidungen um 99 %“, nachdem Identitäten in Echtzeit aufgelöst wurden. Das Verfahren ist patentiert (US-Patent Nr. 12,248,479 B2), SOC-2-zertifiziert und DSGVO-konform ausgelegt – Signale, die gerade deshalb zählen, weil die Anwendungsfälle reguliert sind.

Häufig gestellte Fragen

Ist Identity Resolution dasselbe wie RAG? Nein. RAG ruft relevante Dokumente nach semantischer Ähnlichkeit ab. Identity Resolution ruft eine einheitliche Entität ab – jeden Datensatz, der zu einem Kunden gehört, zusammengeführt. IdentityRAG verbindet beides: Es ist RAG, bei dem der abgerufene Kontext eine aufgelöste Identität ist und kein Dokumentabschnitt.

Ist IdentityRAG ein Tilores-Produkt oder ein allgemeines Muster? IdentityRAG ist der Name, den Tilores für das Muster verwendet, ein LLM in einem dedizierten Entity-Resolution-System zu verankern. Die zugrunde liegende Idee – Identität in einer spezialisierten Schicht auflösen und das LLM sie abfragen lassen – ist allgemein; Tilores ist die Implementierung, die den Begriff geprägt und zum Produkt gemacht hat.

Wie schnell muss Identity Resolution für ein laufendes LLM-Gespräch sein? Schnell genug, um innerhalb eines Dialogschritts unbemerkt zu bleiben. Tilores gibt unter 150 Millisekunden an – damit fügt der Auflösungsschritt einem Chatbot oder Sprachagenten keine spürbare Latenz hinzu.

Warum nicht einfach das LLM auf Kundendaten feinjustieren? Fine-Tuning brennt eine Momentaufnahme ins Modell ein, veraltet sofort, kann Daten zwischen Kunden durchsickern lassen und kann trotzdem nicht garantieren, welche Datensätze zu derselben Person gehören. Ein Abruf in Echtzeit aus einem Resolution-System bleibt aktuell und hält die Identitätslogik prüfbar.

Was ist ein Golden Record zur Lesezeit? Ein Golden Record ist die einzelne, zusammengeführte Version eines Kunden, gebildet aus vielen Quellen. „Zur Lesezeit“ heißt, dass er beim Abfragen zusammengesetzt und nicht vorberechnet wird – er spiegelt also den aktuellen Stand in jedem System wider und kann für unterschiedliche Fragen unterschiedlich zugeschnitten werden.

Ersetzt Identity Resolution meine CDP oder mein MDM? Nicht zwangsläufig. Eine CDP zentralisiert Marketingdaten, ein MDM steuert Stammdaten – häufig im Batch. Eine Entity-Resolution-API in Echtzeit liefert die aktuelle Identität zur Abfragezeit, die ein LLM oder ein Agent braucht. Viele Teams betreiben beides parallel; der unten verlinkte Vergleich erläutert, wann was die richtige Wahl ist.

Ist Fuzzy Matching für regulierte Anwendungen genau genug? Probabilistischer Abgleich über mehrere Attribute (Name, Adresse, Geburtsdatum, E-Mail, Telefon, Gerät) ist genau die Arbeitsweise, mit der Auskunfteien und Betrugsteams heute schon arbeiten. Konfigurierbare Schwellenwerte und ein erklärbarer Entitätsgraph liefern die Precision und den Audit-Trail, die Aufsichtsbehörden erwarten – etwas, das das undurchsichtige Urteil eines LLM nicht leisten kann.

Wie ergänze ich eine bestehende LLM-Anwendung um Identity Resolution? Binden Sie eine Entity-Resolution-API in Echtzeit als Retrieval-Werkzeug ein, das das Modell aufruft – etwa über eine LangChain-Integration oder indem Sie die API Ihrem Agenten als Tool bereitstellen. Die unten verlinkte Anleitung führt durch die Umsetzung.

Zum Autor

Steven Renwick ist CEO und Mitgründer von Tilores. Er arbeitet dort an Entity Resolution in Echtzeit, an IdentityRAG und an Infrastruktur für Kundenidentität in KI-Systemen.

Weiterführende Lektüre

Entity Resolution für KI: API vs. Vektordatenbank vs. MDM vs. CDP – und wie Sie 2026 richtig wählen
Wie Sie einem KI-Agenten eine aufgelöste Kundensicht in Echtzeit geben (RAG + MCP)
Tilores: IdentityRAG für LLMs
Tilores-Dokumentation
Glossar zur Identity Resolution