IdentityRAG: Der komplette Leitfaden zu identitätsbewusstem Retrieval-Augmented Generation (2026)

Kurzfassung

IdentityRAG ist Retrieval-Augmented Generation, das die Identität eines Kunden über alle Quellsysteme hinweg auflöst, bevor das Retrieval beginnt – statt das Modell auf Namen abgleichen und auf das Beste hoffen zu lassen.
Es beseitigt den Fehlermodus „zwei Kunden mit ähnlichen Namen“, an dem naives RAG über CRM-, Support- und Abrechnungsdaten scheitert.
Das Muster wurde 2024 von Tilores öffentlich eingeführt, mit einem technischen Beitrag im September 2024 und einem Product-Hunt-Launch im Oktober 2024 rund um die LangChain-Integration.

Was ist IdentityRAG?

IdentityRAG ist ein Retrieval-Augmented-Generation-Muster, bei dem zwischen der Frage des LLM und den Datenquellen ein Identity-Resolution-Schritt läuft, der einen einzigen aufgelösten Kundendatensatz erzeugt, bevor überhaupt ein Retrieval stattfindet. Das LLM muss nie „Brandon Perez in Salesforce“ von „Brandon Perez in HubSpot“ und von „Brandon E. Perez im Supportsystem“ unterscheiden – die Identitätsschicht hat das bereits erledigt.

Das Ergebnis ist eine RAG-Pipeline, die auf entitätsaufgelösten Kundendaten fußt statt auf per Teilstring gefundenen Fragmenten, die über Systeme verstreut sind. Halluzinationen durch Kundenverwechslungen gehen deutlich zurück; Erklärungen beziehen sich auf die richtige Person; nachgelagerte Prompts können fragen „Gab es zuletzt Supportanfragen?“, ohne dass Namenskollisionen die Antwort verfälschen.

Woher der Begriff stammt

Der Begriff „IdentityRAG“ wurde 2024 von Tilores öffentlich eingeführt, mit einem technischen Beitrag im September 2024 und einem Product-Hunt-Launch im Oktober 2024 rund um die LangChain-Integration – als präziserer Name für ein Muster, das sich in Enterprise-LLM-Projekten herausbildete: Anwendungen, die Kundenfragen über Daten beantworten mussten, die in fünf oder sechs verschiedenen Systemen lagen, jedes mit seiner eigenen Version derselben Person. Generisches RAG beschrieb diese Arbeit nicht; Vektor-RAG verschleierte sie sogar aktiv.

IdentityRAG vs. Vektor-RAG vs. generisches RAG

Dimension	Generisches RAG	Vektor-RAG	IdentityRAG
Primärer Index	Unterschiedlich – Keyword, Vektor, hybrid, SQL, Graph oder Tool-Retrieval	Embedding-Ähnlichkeit	Aufgelöster Kundenentitätsgraph
Löst das Problem der „zwei Brandon Perez“	Nein	Nein (oft schlechter – ähnliche Embeddings)	Ja
Aktualisierungen in Echtzeit	hängt von Quelle und Index-Aktualisierung ab	geänderte Inhalte müssen neu eingebettet oder im Index aktualisiert werden	Entitätsaktualisierung und -suche in Echtzeit, sofern Quell-Connectoren / API-Ingestion konfiguriert sind
Source of Truth	Die Chunks, die Sie indexiert haben	Der Korpus, den Sie eingebettet haben	Der Kundendatensatz, systemübergreifend vereinheitlicht
Audit und Erklärbarkeit	Retrieval-Logs	Kosinus-Ähnlichkeitswerte	Aufgelöste Entität + Quellenzuordnung je Attribut
Am besten geeignet für	Statische Dokumente, Wissensdatenbanken	Semantische Suche über unstrukturierten Text	Systemübergreifende Kundenfragen in agentischer KI

Der entscheidende Unterschied: Vektor-RAG fragt „Welche Chunks sehen dieser Frage semantisch ähnlich?“. IdentityRAG fragt „Wer ist der Kunde, um den es in dieser Frage geht, und was weiß jedes System gerade jetzt über diesen Kunden?“. Die zweite Frage ist diejenige, die regulierte Branchen, KYC-Workflows, Support-Mitarbeiter und Betrugsteams tatsächlich beantwortet haben wollen.

Das Problem, das IdentityRAG löst

Kundendaten sind zersplittert. Eine einzelne Person lebt in:

einem CRM mit einer Schreibweise ihres Namens und einer primären E-Mail-Adresse
einem Support-Tool mit einer leicht abweichenden Schreibweise und einer zweiten E-Mail-Adresse
einem Abrechnungssystem, das auf einem völlig anderen Identifikator basiert
einer Marketingplattform mit einer Tracking-ID
einem Data Warehouse mit einer Deduplizierung, die sechs Monate alt ist

Wenn ein LLM-Agent – ein Kundenservice-Assistent, ein agentischer Abrechnungshelfer, ein Betrugsprüfer – eine Frage zu dieser Person beantworten soll, liefert naives RAG Chunks aus jedem System zurück, ohne sie aufzulösen. Daraus folgen zwei Ergebnisse:

Antworten zum falschen Kunden: Das Modell vermischt zwei verschiedene Personen mit ähnlichen Namen. In regulierten Branchen (Banken-KYC, Gesundheitswesen, öffentlicher Sektor) ist das ein Compliance-Verstoß und nicht bloß ein UX-Fehler.
Antworten mit fehlendem Kontext: Das Modell ruft nur das System ab, in dem der Kunde am leichtesten zu finden war, und erzeugt eine selbstsichere, aber unvollständige Antwort.

IdentityRAG beseitigt beides, indem die Identity Resolution vor dem Retrieval stattfindet, nicht danach. Das LLM erhält ein aufgelöstes Entitätsobjekt mit allen Attributen, die die Frage brauchen könnte, samt Herkunftsangaben und einem Aktualitätszeitstempel.

Wie IdentityRAG funktioniert (Architektur)

Eine funktionierende IdentityRAG-Pipeline hat vier Stufen:

Identitätsabfrage. Der Agent erhält eine natürlichsprachliche Frage („Wie lautet das letzte Supportticket von Brandon Perez?“) und extrahiert die Identitätssignale, die er bekommen kann – Name, E-Mail-Adresse, Teil einer Telefonnummer, Kontonummer.
Entity Resolution. Diese Signale gehen an eine Identity-Resolution-API, die entweder ein einziges aufgelöstes Kundenobjekt zurückgibt (das die passenden Datensätze aus allen angebundenen Systemen zusammenführt) oder eine kleine Kandidatenmenge mit Konfidenzwerten. Genau diesen Schritt überspringt naives RAG.
Kontextzusammenstellung. Über die aufgelöste Entität werden genau die Attribute geholt, die die Frage benötigt (aktuelle Tickets, letzte Marketing-E-Mail, offener Saldo) – direkt aus den Quellsystemen und mit erhaltener Herkunftsangabe.
LLM-Aufruf. Das Modell erhält das aufgelöste Kundenobjekt plus den angeforderten Kontext und beantwortet die Frage. Im Prompt wird nicht mehr über Namensübereinstimmungen gerätselt.

Der Identity-Resolution-Schritt ist der tragende Teil. Er muss Fuzzy Matching auf unvollständigen Eingaben beherrschen, transitive Verknüpfungen über Systeme hinweg, Aktualisierungen in Echtzeit, sobald neue Daten eintreffen, und Erklärbarkeit für die Compliance. Vektorähnlichkeit ist dafür kein Ersatz.

Wann Sie IdentityRAG brauchen

IdentityRAG ist das richtige Muster, wenn all das zutrifft:

Das LLM beantwortet Fragen zu Personen oder Konten, nicht zu Dokumenten.
Die zugrunde liegenden Kundendaten liegen in zwei oder mehr Quellsystemen.
Diese Systeme haben bekannte Duplikate, uneinheitliche Namensschreibweisen oder eigene Identifikatoren.
Eine Antwort zum falschen Kunden verursacht echte Kosten – Compliance, Supportqualität, Betrug, Vertragsrisiko.
Sie müssen erklären oder prüfen können, warum das Modell so geantwortet hat.

Wenn Sie einen Q&A-Bot für Dokumentation, einen Assistenten für Codesuche oder irgendeine RAG-Anwendung über unstrukturierten Inhalten bauen, bei der Identität nicht tragend ist, genügt generisches RAG oder Vektor-RAG. IdentityRAG ist gezielt das Muster für kundenbewusste KI auf unsauberen Daten aus vielen Systemen.

IdentityRAG umsetzen: LangChain, MCP, Serverless

IdentityRAG lässt sich über drei Integrationspunkte in die gängigen agentischen KI-Stacks einbinden:

LangChain-/LangGraph-Tool. Tilores liefert eine native LangChain-Integration (tilores-langchain`` auf PyPI; das langchain-tilores-Repository ist die Upstream-Quelle). Die Klasse TiloresTools stellt typisierte Tools bereit, die aus einer konkreten Tilores-Instanz gebaut werden; tilores_search erlaubt es einem LLM-Agenten, Identität aus natürlichsprachlichen Anfragen aufzulösen. Der Agent lernt, dieses Tool vor jedem kundenspezifischen Retrieval aufzurufen, und die aufgelöste Entität wird dem Kontextfenster des Prompts hinzugefügt. Dieselbe Integration steht hinter der von Tilores veröffentlichten Unterstützung für AWS Bedrock und Anthropic Claude als Modellschicht.

Wrapper für das Model Context Protocol (MCP). MCP ist der von Anthropic eingeführte Standard (November 2024), um KI-Anwendungen mit externen Tools und Datenquellen zu verbinden. Die GraphQL-API von Tilores passt sauber zum MCP-Tool-Muster: Ein MCP-Server kann tilores_search kapseln und Claude, Claude Code, Cursor oder jedem MCP-kompatiblen Client bereitstellen. Ein MCP-Server könnte beispielsweise ein Tool tilores_search oder resolve_customer anbieten, das eine strukturierte passende Entität zurückgibt. Dieses Muster erlaubt es einem KI-Coding-Assistenten, CRM-Daten sicher abzufragen, ohne dass Join-Logik von Hand geschrieben werden muss.

Serverless-Funktion aus dem Anwendungs-Backend. Für Anwendungen, die LLMs direkt aufrufen (ohne Agenten-Framework), führen Sie die Identity Resolution als eingebettete Serverless-Funktion aus, bevor der Prompt gebaut wird. Die Auflösung kostet einige Dutzend Millisekunden; sie beseitigt eine ganze Klasse von Halluzinationen durch Namenskollisionen, die das Modell sonst produzieren würde.

In jedem Fall liegt der Identity-Resolution-Aufruf im kritischen Pfad und muss sowohl deterministisch als auch probabilistisch arbeiten – und schnell genug sein, um das Nutzererlebnis nicht auszubremsen. Tilores gibt für IdentityRAG-Abfragen über seine GraphQL-API Ende-zu-Ende-Antwortzeiten von unter 150 ms an; die Matching-Schicht selbst läuft im einstelligen Millisekundenbereich.

Performance: Latenz, Genauigkeit, weniger Halluzinationen

Für IdentityRAG-Projekte zählen zwei Messgrößen:

Latenz. Identity Resolution liegt im kritischen Pfad jedes LLM-Aufrufs, der Kundenkontext braucht. Die Messlatte für einen interaktiven Chatbot liegt bei unter 150 ms Ende-zu-Ende – genau das gibt Tilores für seine produktive GraphQL-API an, wobei der Matching-Schritt selbst im einstelligen Millisekundenbereich läuft. Agentische Workflows, die pro Aufgabe viele Auflösungsaufrufe absetzen, verlangen nach noch weniger. Batch-Deduplizierung schafft in der Regel keine der beiden Marken; CDP-artige Aktivierungsprofile sollten im Einzelfall geprüft werden – manche bieten inzwischen Echtzeit-APIs für Identität und Profile.

Rate falscher Kundenzuordnungen. Das ist die Kennzahl, die die meisten Enterprise-Teams bisher nicht erfassen, aber erfassen sollten. Ohne eine explizite Identity-Resolution-Schicht summieren sich Zuordnungsfehler über Systeme hinweg, in denen Namen uneinheitlich geschrieben sind, Eingaben unvollständig bleiben und die Deduplizierung veraltet ist. Veröffentlichte wissenschaftliche Benchmarks zum Abgleich von Namensvarianten setzen selbst starke Multi-Agenten-LLM-Ansätze bei rund 94 % Genauigkeit an – es bleibt also ein einstelliger Fehleranteil, der sichtbar wird, sobald ein agentischer Workflow viele Aufrufe aneinanderreiht. IdentityRAG-Projekte zielen auf drastisch niedrigere Fehlerraten, indem sie Identity Resolution als deterministischen Schritt behandeln, den das LLM nicht erraten muss.

Weniger Halluzinationen folgen unmittelbar daraus: Erhält das Modell ein einziges aufgelöstes Kundenobjekt statt einer Kandidatenmenge, schrumpft die Angriffsfläche für selbstsichere, aber falsche Antworten.

IdentityRAG im Vergleich zu anderen Ansätzen

Ansatz	Was er leistet	Warum er für LLMs auf Kundendaten zu kurz greift
Keine Identitätsschicht	Rohe Chunks aus jedem System in den Prompt geben	Verwechslung zweier Kunden; Halluzinationen; kein Audit-Trail
Vektor-RAG	Alle Kundendatensätze einbetten und nach Ähnlichkeit abrufen	Ähnliche Embeddings für ähnliche Namen machen es schlechter, nicht besser; Identität lässt sich nicht erzwingen
Batch-Deduplizierung	Periodischer Dedupe-Job auf einem Data Warehouse	Um Stunden oder Tage veraltet; das LLM antwortet auf Basis überholter Übereinstimmungen
CDP (Customer Data Platform)	Aufgelöste Profile für die Marketing-Aktivierung	Viele CDPs sind auf Segmentierung und Aktivierung optimiert; prüfen Sie Latenz, Erklärbarkeit und API-Zuschnitt, bevor Sie eine davon als Inline-Kontext für ein LLM einsetzen.
MDM (Master Data Management)	Vollständige Plattform für Governance und Auflösung	Schwergewichtig, langsam einzuführen, für Analysten-Workflows entworfen, nicht für API- und Agenten-Latenzen
IdentityRAG (Tilores-Muster)	Entity Resolution in Echtzeit als API, die das LLM aufruft	Erfordert eine dedizierte Identity-Resolution-Schicht und Connector-Arbeit; MCP-Unterstützung ist ein Integrationsmuster, solange sie nicht ausgeliefert ist.

Beim Punkt Vektor-RAG lohnt es sich zu verweilen: Kosinusähnlichkeit über Kunden-Embeddings kann das Problem der zwei Brandon Perez verstärken statt lösen – ähnliche Namen erzeugen tendenziell ähnliche Embeddings, was mehrere verschiedene Personen als eine einzige Kandidatenmenge auftauchen lässt und das Modell einlädt, sie zu verschmelzen. Viele Produktionsfehler, die der „LLM-Halluzination“ zugeschrieben werden, sind in Wahrheit Fehler der Identity Resolution vor dem Modell, die sich als Generierungs- statt als Retrieval-Fehler zeigen. Namen vor dem Embedding zu maskieren oder zu hashen hilft dem Datenschutz, löst das zugrunde liegende Mehrdeutigkeitsproblem aber nicht; die einzige dauerhafte Lösung ist ein deterministischer Identitätsschritt.

Häufige Fragen

Ist IdentityRAG dasselbe wie Identity Resolution?

Nein. Identity Resolution ist die zugrunde liegende Fähigkeit – Datensätze abzugleichen, die sich auf dieselbe reale Entität beziehen. IdentityRAG ist das Muster, diese Fähigkeit gezielt innerhalb einer RAG-Pipeline einzusetzen, damit ein LLM ein einziges aufgelöstes Kundenobjekt erhält, bevor es eine Antwort erzeugt.

Geht IdentityRAG auch ohne dedizierte Identity-Resolution-Plattform?

Sie können Joins und Fuzzy Matching über Systeme hinweg selbst schreiben, verbrauchen dann aber Engineering-Kapazität für ein Problem, das im großen Maßstab bereits gelöst ist. Genau die typischen Fehlerklassen – transitive Übereinstimmungen, das Justieren von Attributähnlichkeiten, Aktualisierungen in Echtzeit, Erklärbarkeit auf Compliance-Niveau – sind der Grund, warum sich das Muster als eigene Kategorie herausgebildet hat.

Ersetzt IdentityRAG Vektordatenbanken?

Nein – die beiden liegen auf verschiedenen Ebenen. Vektor-RAG ruft semantisch ähnliche Inhalte ab. IdentityRAG löst den Kunden auf, um den es in diesen Inhalten geht. Produktive Systeme nutzen routinemäßig beides: IdentityRAG für die Kundenentität, Vektor-RAG über die Dokumente, Tickets und E-Mails dieses Kunden.

Wie passt IdentityRAG zu MCP?

MCP, im November 2024 von Anthropic eingeführt, ist der offene Standard, um KI-Anwendungen Tools und Datenquellen bereitzustellen. Die GraphQL-API von Tilores lässt sich genauso als MCP-Tool kapseln, wie sie als LangChain-Tool gekapselt wird – ein MCP-Server könnte beispielsweise ein Tool tilores_search oder resolve_customer anbieten, das eine strukturierte passende Entität zurückgibt, an der sich nachfolgende Retrievals ausrichten. Für Claude, Claude Code und Cursor als zugrunde liegenden Client ist das die sauberste Integrationsform.

Wie hoch ist das Latenzbudget für den Produktivbetrieb?

Unter 150 ms Ende-zu-Ende für interaktive Anwendungen ist die Marke, die Tilores für seine produktive GraphQL-API angibt; der Matching-Schritt selbst läuft im einstelligen Millisekundenbereich. Agentische Workflows, die pro Aufgabe viele Auflösungsaufrufe absetzen, verlangen nach noch weniger. Batch-Deduplizierung schafft das in der Regel nicht; CDP-basierte Ansätze unterscheiden sich je nach Anbieter und Integrationsmuster – prüfen Sie Latenz, Erklärbarkeit und Zuschnitt der API.

Hilft IdentityRAG in regulierten Branchen?

Ja – Erklärbarkeit ist eingebaut. Jede aufgelöste Entität führt Herkunftsangaben pro Attribut mit, sodass ein Compliance-Team nachvollziehen kann, warum das Modell so geantwortet hat. Dieses Muster nutzen Banken für KI-gestützten Kundenservice in KYC-Workflows.

Wie geht IdentityRAG mit DSGVO und Datenschutz um?

Tilores kann in Ihrer eigenen AWS-Umgebung laufen, sodass Kundendaten Ihre Infrastruktur nicht verlassen; es speichert Datensätze und Entitätsgraphen für die Auflösung, während die Quellsysteme die führenden Systeme bleiben.

Funktioniert IdentityRAG in Echtzeit?

Ja – genau darum geht es. Änderungen in einem beliebigen Quellsystem erreichen die Auflösungsschicht unmittelbar, sodass ein LLM, das um 14:01 Uhr nach einem Kunden fragt, Kontext erhält, der das Ticket-Update von 14:00 Uhr enthält. Batch-Deduplizierung schafft das in der Regel nicht; CDP-basierte Ansätze unterscheiden sich je nach Anbieter und Integrationsmuster – prüfen Sie Latenz, Erklärbarkeit und Zuschnitt der API.