RAG-Genauigkeit mit IdentityRAG verbessern

Kurzfassung: Standard-RAG-Pipelines rufen Fragmente von Kundendaten ab, ohne zu wissen, dass „S. Johnson”, „SARA JOHNSON” und „sarah@johnson.me” dieselbe Person sind. IdentityRAG schaltet vor das Retrieval einen Entity-Resolution-Schritt von Tilores: Datensätze werden in unter 150 ms zu einem vollständigen Golden Record aufgelöst, und das LLM antwortet auf Basis eines einheitlichen, deduplizierten Kontexts statt auf Teildaten.

Dimension	Standard-RAG	IdentityRAG
Retrieval-Verfahren	Vektorähnlichkeit auf Rohtext	Identity Resolution + Aufbau eines Golden Record
Umgang mit Namens- und E-Mail-Varianten	Nein: übersieht Varianten mit geringer Ähnlichkeit	Ja: probabilistisches Fuzzy Matching über Systeme hinweg
Systemübergreifende Deduplizierung	Findet nicht statt	Aufgelöst bei der Datenaufnahme; abgerufen zur Abfragezeit
Ergebnisqualität	Teildaten; verknüpfte Datensätze können fehlen	Vollständiger, deduplizierter Kundenkontext
Latenz	Lookup im Vektorindex	Tilores-Auflösung in unter 150 ms
LangChain-Kompatibilität	Standard-Retriever-Schnittstelle	TiloresRetriever zum direkten Einsetzen

Auf dieser Seite

Das Problem mit Standard-RAG bei Kundendaten
So funktioniert IdentityRAG
Integration mit LangChain
Jenseits von Vektordatenbanken
Integration mit Amazon Bedrock
Selbst ausprobieren
Häufig gestellte Fragen

Retrieval-Augmented Generation (RAG) hat verändert, wie Unternehmen KI-Anwendungen bauen. Doch es gibt ein grundlegendes Problem, das Vektordatenbanken allein nicht lösen können: Ihre Kundendaten sind fragmentiert.

Wenn ein LLM Kundenkontext aus einer Vektordatenbank abruft, bekommt es Fragmente – hier ein CRM-Datensatz, dort ein Support-Ticket, dazu eine Bestellung aus einem dritten System. Diese Fragmente gehören oft zu demselben Kunden, doch das LLM weiß das nicht. Das Ergebnis sind unvollständige, mitunter widersprüchliche Antworten.

IdentityRAG löst das, indem es vor dem Retrieval eine Identity-Resolution-Schicht einzieht.

Das Problem mit Standard-RAG bei Kundendaten

Nehmen wir einen Chatbot für den Kundenservice. Ein Nutzer fragt: „Wie sieht die Bestellhistorie von Sarah Johnson aus?”

In einem Standard-RAG-Aufbau durchsucht das System die Vektordatenbank nach Datensätzen, die zu „Sarah Johnson” passen. Es könnte finden:

Einen CRM-Datensatz für „Sarah Johnson” mit E-Mail-Adresse und Kontodaten
Eine Bestellung von „S. Johnson” aus Shopify – doch die Vektorähnlichkeit reicht nicht aus, um sie abzurufen
Ein Support-Ticket von „sarah@johnson.me” – abgerufen, aber das LLM weiß nicht, dass es dieselbe Person ist
Einen ERP-Datensatz für „SARA JOHNSON” – wegen abweichender Groß-/Kleinschreibung und leichter Namensvariation komplett übersehen

Das LLM antwortet auf Basis von Teildaten. Es meldet vielleicht 3 Bestellungen, obwohl die Kundin tatsächlich 14 hat. Es übersieht womöglich, dass diese Kundin ein offenes Support-Ticket hat. Die Antwort ist gemessen an dem, was abgerufen wurde, technisch korrekt – aber sachlich unvollständig.

So funktioniert IdentityRAG

IdentityRAG ergänzt die RAG-Pipeline um einen Entity-Resolution-Schritt von Tilores:

Die Nutzeranfrage trifft ein – „Wie sieht die Bestellhistorie von Sarah Johnson aus?”
IdentityRAG extrahiert Identitätsmerkmale – Name: „Sarah Johnson”
Tilores löst die Entität auf – findet alle Datensätze in allen Systemen, die zu dieser Person gehören (in unter 150 ms)
Golden Record entsteht – ein einheitliches Profil mit allen 14 Bestellungen, 2 E-Mail-Adressen und 4 Quellsystemen
Das LLM erzeugt die Antwort – auf Basis der vollständigen, deduplizierten Kundensicht

Der entscheidende Unterschied: Statt in einer Vektordatenbank nach ähnlichem Text zu suchen, nutzt IdentityRAG das Fuzzy Matching von Tilores, um alle Datensätze zu finden, die zu derselben realen Person gehören – unabhängig davon, wie ihr Name geschrieben ist, welche E-Mail-Adresse sie verwendet hat oder aus welchem System der Datensatz stammt.

Wie Identity Resolution unter der Haube funktioniert, erfahren Sie in unserem Beitrag dazu, was Entity Resolution ist und wie sie sich auf KYC und Customer 360 anwenden lässt. Einen genaueren Blick darauf, wie LLMs Entity Resolution nativ nutzen können, gibt der Beitrag zur Frage, ob sich LLMs für Entity Resolution einsetzen lassen.

Integration mit LangChain

IdentityRAG ist als LangChain-Retriever umgesetzt und lässt sich damit direkt in bestehende LangChain-Anwendungen einsetzen:

from tilores import TiloresAPI
from langchain_tilores import TiloresRetriever

# Initialize
tilores = TiloresAPI.from_credentials()
retriever = TiloresRetriever(tilores=tilores)

# Use in a chain
chain = RetrievalQA.from_chain_type(
    llm=your_llm,
    retriever=retriever,
    chain_type="stuff"
)

# Query
result = chain.run("What's Sarah Johnson's order history?")

Der Retriever übernimmt den Tilores-API-Aufruf, die Entity Resolution und den Aufbau des Golden Record automatisch. Ihr LLM erhält bei jeder Abfrage vollständigen, deduplizierten Kundenkontext.

Jenseits von Vektordatenbanken

Es geht nicht darum, Vektordatenbanken zu ersetzen – es geht darum, sie zu ergänzen. Vektorähnlichkeit eignet sich hervorragend für semantische Suche, Dokumentenabruf und unstrukturierte Inhalte. Doch bei strukturierten Kundendaten mit Identitätsmerkmalen gilt: Entity Resolution ist genauer als Vektorähnlichkeit.

Vektorähnlichkeit liefert Ihnen Datensätze, die „ähnlich aussehen” wie „Sarah Johnson”. Entity Resolution liefert Ihnen alle Datensätze, die zu Sarah Johnson gehören – auch „SARA JOHNSON” im ERP-System, das null Textähnlichkeit mit „sarah@johnson.me” hat, aber dieselbe Telefonnummer trägt.

Einen breiteren Vergleich dessen, was Identity Resolution über die Möglichkeiten von Vektordatenbanken hinaus leistet, finden Sie in Jenseits von Vektordatenbanken. Wenn Sie diese Fähigkeit selbst aufbauen möchten, zeigt dieser Leitfaden, wie Sie Ihr eigenes Identity-Resolution-System bauen.

Integration mit Amazon Bedrock

IdentityRAG funktioniert über die LangChain-Bedrock-Integration auch mit Amazon Bedrock. Das heißt, Sie können Claude, Titan oder jedes andere in Bedrock gehostete Modell mit identitätsaufgelöstem Kundenkontext nutzen – vollständig innerhalb der Sicherheits- und Compliance-Grenzen von AWS.

Selbst ausprobieren

Die vollständige IdentityRAG-Implementierung steht als Open-Source-Beispiel bereit:

GitHub: tilotech/identity-rag-customer-insights-chatbot
Python-SDK: pip install tilores-sdk
LangChain-Integration: pip install langchain-tilores

Möchten Sie Ihrer KI-Anwendung identitätsaufgelösten Kontext hinzufügen? Starten Sie mit dem kostenlosen Tarif und binden Sie Ihr LLM in wenigen Minuten an.

Übertrifft IdentityRAG Standard-RAG bei Kundendaten?

Ja, bei strukturierten Kundendaten mit Identitätsmerkmalen. Standard-RAG ruft auf Basis von Textähnlichkeit ab, sodass Namensvarianten, E-Mail-Adressen und systemübergreifende Datensätze derselben Person unbemerkt untergehen. IdentityRAG löst diese Identitäten zuerst auf, baut daraus einen vollständigen Golden Record und gibt dem LLM präzisen, deduplizierten Kontext. Die Vergleichstabelle oben zeigt die vollständige Aufschlüsselung nach Dimension.

FAQ

Was ist IdentityRAG, und worin unterscheidet es sich von Standard-RAG?

IdentityRAG ergänzt die Retrieval-Phase vor dem LLM um einen Entity-Resolution-Schritt von Tilores. Standard-RAG durchsucht eine Vektordatenbank nach Textähnlichkeit und übersieht dabei möglicherweise Datensätze derselben Person, wenn diese in verschiedenen Systemen unterschiedlich geschrieben ist. IdentityRAG löst die Identität zuerst mit probabilistischem Fuzzy Matching auf, baut aus allen Quellsystemen einen vollständigen Golden Record und übergibt diesen einheitlichen Kontext an das LLM.

Warum versagt Vektorähnlichkeit bei strukturierten Kundendaten?

Vektorähnlichkeit findet Datensätze, die einander textlich ähneln. Ein Datensatz für „SARA JOHNSON” in einem ERP-System hat nahezu keine Textähnlichkeit mit „sarah@johnson.me” in einem Support-Ticket, sodass eine Vektorsuche die Verbindung übersieht, obwohl beide Datensätze zu demselben Kunden gehören. Entity Resolution nutzt Identitätsmerkmale (Name, E-Mail-Adresse, Telefonnummer, Adresse) und probabilistisches Matching, um solche systemübergreifenden Verknüpfungen unabhängig von Schreibweise oder Groß-/Kleinschreibung zu finden.

Wie lässt sich IdentityRAG in eine LangChain-Anwendung integrieren?

IdentityRAG ist als LangChain-Retriever umgesetzt (TiloresRetriever aus dem Paket langchain-tilores). Sie übergeben ihn RetrievalQA.from_chain_type als retriever-Argument. Der Retriever übernimmt den Tilores-API-Aufruf, die Entity Resolution und den Aufbau des Golden Record automatisch, sodass das LLM bei jeder Abfrage vollständigen, deduplizierten Kundenkontext erhält.

Funktioniert IdentityRAG mit Amazon Bedrock?

Ja. IdentityRAG funktioniert über die LangChain-Bedrock-Integration mit Amazon Bedrock. Das heißt, Sie können Claude, Titan oder jedes andere in Bedrock gehostete Modell mit identitätsaufgelöstem Kundenkontext nutzen – vollständig innerhalb der Sicherheits- und Compliance-Grenzen von AWS.

Wo finde ich den Quellcode von IdentityRAG, und wie fange ich an?

Die vollständige IdentityRAG-Implementierung steht als Open-Source-Beispiel auf GitHub unter tilotech/identity-rag-customer-insights-chatbot bereit. Installieren Sie das Python-SDK mit pip install tilores-sdk und die LangChain-Integration mit pip install langchain-tilores. Ein kostenloser Tarif ist unter app.tilores.io/signup verfügbar.

Sehen Sie es an Ihren eigenen Daten: Demo buchen für einen Durchgang an Ihren Datensätzen, oder Evaluierungs-Build holen, um aufgelöste Entitätsdaten lokal auszuprobieren.