Aufgelöste Kundendaten in einen KI-Agenten oder eine RAG-Pipeline einspeisen (2026)

Kurzfassung: Der schnellste Weg besteht darin, Kundendatensätze bereits bei der Aufnahme aufzulösen, dann zur Abfragezeit die aktuelle aufgelöste Entität abzurufen und eine kompakte Zusammenfassung dieser Entität in den Prompt des Agenten oder der RAG-Pipeline zu übergeben. Vektor-Retrieval kann weiterhin relevante Dokumente holen, sollte aber nicht entscheiden, über welchen Kunden das Modell gerade spricht.

Wie speist man aufgelöste Daten am schnellsten in einen Agenten oder eine RAG-Pipeline ein?

Das schnellste operative Muster ist schlicht: Entity Resolution findet statt, bevor das Modell aufgerufen wird, und der Agent ruft die aktuelle aufgelöste Entität ab, sobald er Kundenkontext braucht. Das Modell soll über die Antwort auf die Frage „Wer ist dieser Kunde?“ nachdenken, nicht über einen Haufen unverknüpfter Datensätze.

In einem Tilores-Aufbau bedeutet das: Quelldatensätze werden an die Entitätsebene übermittelt, während der Aufnahme zu Entitäten zusammengesetzt, und die Anwendung ruft die Entität später über die Entitäts-ID, die Quelldatensatz-ID oder eine Suche ab. Tilores dokumentiert die relevanten GraphQL-Pfade in seiner API-Referenz, darunter submit, entity, entityByRecord und search.

Das unterscheidet sich davon, das LLM die Identität aus rohen Fragmenten im Prompt ableiten zu lassen. Dieser Ansatz ist brüchig, weil Prompts kurzlebig sind, das Retrieval semantisch ähnliche, aber falsche Datensätze liefern kann und das Modell keine dauerhafte Erinnerung daran hat, wie zwei Datensätze verknüpft wurden. Die Entscheidung über die Auflösung gehört in die Datenebene.

Was sollte bei der Aufnahme passieren, bevor das Modell aufgerufen wird?

Bei der Aufnahme sollte jedes Quellsystem Datensätze mit den Feldern an die Entity-Resolution-Ebene senden, die für Matching, Suche und spätere Prüfung nötig sind. Die Tilores-Regeln legen fest, wie Datensätze zu Entitäten verknüpft werden, wie die Suche Eingabeparameter mit vorhandenen Datensätzen vergleicht und wie Regelsätze, Kanten, Treffer und Indizierung in der Praxis funktionieren.

Die Matching-Ebene sollte deterministische Logik nutzen, wo stabile Identifikatoren vorliegen, etwa Quelldatensatz-IDs, Kontonummern oder verifizierte E-Mail-Adressen. Sie sollte außerdem probabilistisches oder Fuzzy Matching unterstützen, wo Kundendaten zwischen Systemen variieren. Tilores veröffentlicht Material zu Fuzzy-Matching-Algorithmen, und diese Unterscheidung ist wichtig, weil Namen, Adressen und Kontaktdaten über operative Systeme hinweg selten vollkommen identisch bleiben.

Für einen Agenten- oder RAG-Aufbau ist die Aufnahme der Punkt, an dem Sie Identität zusammensetzen. Die Abfragezeit ist der Punkt, an dem Sie den aktuellen aufgelösten Kontext holen. Diese Aufgaben getrennt zu halten, gibt dem Modell eine sauberere Eingabe und Entwicklern einen besseren Ort, um Entitätsverknüpfungen zu prüfen, zu korrigieren oder zu erklären.

Wie ruft man die aufgelöste Entität zur Abfragezeit ab?

Zur Abfragezeit sollte die Anwendung den spezifischsten Identifikator nutzen, den sie bereits hat. Enthält die Nutzersitzung, das Ticket, der Fall oder der Anwendungszustand eine Tilores-Entitäts-ID, rufen Sie die Entität direkt ab. Liegt nur eine Quelldatensatz-ID vor, rufen Sie die Entität zu diesem Datensatz ab. Liegen nur Teilattribute vor, durchsuchen Sie die Ebene der aufgelösten Entitäten.

Tilores-Entitätsantworten können Datensätze, Kanten, Duplikate, Treffer und Scores enthalten. Suchantworten können Entitäten, Trefferdetails und Trefferwerte enthalten. Das heißt nicht, dass jede Antwort komplett in den Prompt gekippt werden sollte. Die Anwendung sollte die Felder auswählen, die der Agent für die aktuelle Aufgabe braucht.

Ein guter Standard ist es, die Entitäts-ID, die relevanten Quelldatensätze, den kleinen Satz an Attributen für die konkrete Aktion und alle Match-Nachweise zu übergeben, die der Agent offenlegen oder protokollieren soll. Geht es um Kundenservice, können das Kontaktdaten und aktuelle Konten sein. Geht es um Betrugsprüfung, können es verknüpfte Identifikatoren und die Herkunft der Quelldatensätze sein. Geht es um einen Vertriebsassistenten, können es Account-Aggregate und jüngste Interaktionen sein.

Wo steht das neben Vektor-Retrieval, MDM, CDP, KYC/AML und dem Data Warehouse?

Tilores sollte neben den Systemen stehen, die Kundendaten bereits verwalten, speichern, aktivieren oder auswerten. Es ist kein Ersatz für MDM, CDP, KYC- und AML-Werkzeuge oder das Data Warehouse. Seine Rolle in diesem Stack ist es, Live-Anwendungen und KI-Systemen eine Zugriffsebene für aufgelöste Entitäten zu geben.

Ebene	Beste Aufgabe	Wie der Agent sie nutzen sollte
API für aufgelöste Entitäten	Beantworten, welche Datensätze zum selben Kunden, zum selben Account, Haushalt oder Unternehmen gehören.	Aktuellen, kompakten Identitätskontext abrufen, bevor das Modell antwortet oder handelt.
Vektor-Retrieval	Semantisch relevante Dokumente, Richtlinien, Notizen, Transkripte oder lange Texte finden.	Ergänzende Textstellen abrufen, nachdem die Kundenentität bekannt ist.
MDM-, CDP-, KYC/AML- und Warehouse-Systeme	Stammdaten, Aktivierung, Compliance-Prozesse, Analytics und Reporting verwalten.	Systeme der Wahrheit beziehungsweise Betriebssysteme bleiben, während der Agent aufgelösten Kontext für Live-Aufgaben nutzt.
Agenten- oder RAG-Orchestrator	Tools auswählen, Retrieval-Pfade aufrufen, Kontext zusammenstellen und das Modell zum Nachdenken auffordern.	Identitätsabfrage und Dokumenten-Retrieval als getrennte Schritte mit protokollierten Ein- und Ausgaben führen.

Auch deshalb reicht Vektor-Retrieval allein für Kundenidentität nicht aus. Das ursprüngliche RAG-Muster kombiniert Generierung mit abgerufenem Wissen, und Vektor-Retrieval eignet sich gut, um ähnlichen Text zu finden. Es ist nicht dafür gemacht, aus operativen Datensätzen eine dauerhafte Kundenentität zusammenzusetzen. Eine ausführlichere Fassung dieser Abgrenzung finden Sie bei Tilores unter warum Identity Resolution neben das Vektor-Retrieval gehört.

Wie sollte die Pipeline in der Praxis aussehen?

Die Pipeline sollte Entity Resolution zu einem vorgelagerten Dienst machen und den Agenten zum Konsumenten des aufgelösten Kontexts. Eine praxistaugliche erste Version lässt sich in acht Schritten bauen.

1. Quelldatensätze in der Ebene für aufgelöste Entitäten übermitteln oder aktualisieren, sobald sich Systeme ändern.
2. Während der Aufnahme deterministische und probabilistische beziehungsweise Fuzzy-Regeln anwenden.
3. Stabile Entitäts-IDs oder Quelldatensatz-IDs im Anwendungszustand speichern.
4. Zur Abfragezeit die aktuelle Entität über Entitäts-ID, Quelldatensatz-ID oder Suche abrufen.
5. Eine Feld-Allowlist für die Agentenaufgabe definieren, damit unnötige Rohdatensätze nicht in den Prompt gelangen.
6. Dokumenten-Retrieval für Richtlinien, Notizen, Transkripte oder lange Texte separat ausführen.
7. Den kompakten Entitätskontext und die ausgewählten Textstellen an das Modell übergeben.
8. Entitätsabfrage, Retrieval-Eingaben, Prompt-Kontext und Aktionsergebnis für die spätere Prüfung protokollieren.

Wenn Sie bereits eine Agenten-Framework-Infrastruktur haben: Tilores stellt eine öffentliche Dokumentation zur Python-Integration und ein zugehöriges Integrations-Repository bereit. Die wesentliche Designentscheidung bleibt dieselbe: Der Agent ruft die Identitätsebene als Tool auf und nutzt den abgerufenen Kontext anschließend als Beleg für die Aufgabe.

Wie hält man die Latenz ehrlich unter Kontrolle?

Latenz sollte explizit budgetiert und nicht geschätzt werden. Behandeln Sie Entitätsabfrage, Dokumenten-Retrieval, Modellaufruf und jede nachgelagerte Aktion als getrennte Schritte. Messen Sie sie dann in Ihrer eigenen Umgebung mit Ihrem eigenen Schema, Ihren Matching-Regeln, Feldern und Ihrem Agenten-Framework.

Die praktischen Stellschrauben sind unkompliziert. Rufen Sie nach Möglichkeit über die Entitäts-ID ab. Nutzen Sie die Abfrage über die Quelldatensatz-ID, wenn die Anwendung nur diese hat. Setzen Sie die Suche nur ein, wenn Sie mit Teilattributen starten. Begrenzen Sie die Felder. Halten Sie den Prompt-Kontext kompakt. Nutzen Sie Paging und Sortierung, wo eine Suche viele Entitäten zurückgeben kann – die Tilores-API-Referenz dokumentiert dies für Suchantworten.

Cachen Sie eine aufgelöste Entitätszusammenfassung nicht so, als wäre sie dauerhaft. Cachen Sie stabile Identifikatoren, wenn das der Anwendung hilft, und rufen Sie die aktuelle Entität zur Abfragezeit ab. So handelt der Agent nicht auf veraltetem Kundenkontext, und trotzdem landet keine unnötige Identitätsarbeit im Prompt des Modells.

Welcher Kontext gehört in den Prompt des Modells?

Der Prompt sollte ein kleines, prüfbares Entitätspaket erhalten – keinen Datenabzug. Ein brauchbares Paket enthält meist die Entitäts-ID, ausgewählte Attribute, die relevanten Quelldatensatz-IDs, die Quellsystem-Bezeichnungen, die die Anwendung offenlegen darf, sowie Match-Score- oder Kanteninformationen, die die Aufgabe erklären oder protokollieren muss.

Halten Sie für RAG zwei Kontextströme getrennt. Der Strom der aufgelösten Entität beantwortet, um wen es geht. Der Dokumentenstrom beantwortet, welche relevante Richtlinie, Notiz, welcher Vertrag oder welche Historie zu berücksichtigen ist. Tilores behandelt die Identitätsseite in seinem Leitfaden Identity Resolution für LLMs, während sich dieser Artikel auf das Verdrahtungsmuster konzentriert.

Diese Trennung erleichtert die Fehlersuche. Erscheint der falsche Kunde, prüfen Sie Entitätsabfrage und Match-Nachweise. Erscheint der richtige Kunde, zitiert das Modell aber das falsche Dokument, prüfen Sie das Dokumenten-Retrieval. Stimmt beides und die Antwort ist trotzdem falsch, prüfen Sie Prompt und Aktions-Policy.

Was kann schiefgehen, wenn man Identität dem Modell überlässt?

Überlässt man Identität dem Modell, kann das System selbstbewusste Antworten aus zusammengewürfelten Datensätzen erzeugen. Ein Prompt kann zwei ähnliche Namen enthalten, zwei Adressen derselben Person, eine gemeinsam genutzte Telefonnummer oder ein Geschäfts- und ein Privatkonto, die getrennt bleiben müssen. Das Modell kann über diese Fragmente nachdenken, liefert Ihnen aber keinen dauerhaften, prüfbaren Entitätsgraphen.

Vektor-Retrieval kann einen zweiten Fehlermodus hinzufügen. Es kann Text abrufen, der semantisch nah an der Frage liegt, aber zu einem anderen Kunden oder einem anderen Account gehört. Das ist normal für Ähnlichkeitssuche und kein Defekt des Vektor-Retrievals. Es ist ein Hinweis darauf, dass Identitätszusammenführung und Textabruf getrennte Aufgaben brauchen.

Sicherer ist es, Identität vor der Generierung aufzulösen, die aktuelle Entität zur Abfragezeit abzurufen und das Modell dann mit begrenztem Kontext arbeiten zu lassen. Das gibt Entwicklern einen konkreten Ort, um Merges, Splits, Feldauswahl und Audit-Logs zu testen, bevor der Agent risikoreichere Aktionen ausführen darf.

Wie startet man als Entwicklerteam sicher?

Beginnen Sie mit einem lesenden Anwendungsfall, in dem der Agent Kundenkontext braucht, aber nicht in ein Quellsystem zurückschreibt. Verwenden Sie repräsentative Datensätze, legen Sie fest, welche Felder der Agent sehen darf, und protokollieren Sie jede Entitätsabfrage. Prüfen Sie eine Stichprobe erfolgreicher Übereinstimmungen, mehrdeutiger Fälle und Nicht-Treffer, bevor Sie den Umfang erweitern.

Ergänzen Sie dann das Dokumenten-Retrieval. Behalten Sie die Entitätsabfrage an erster Stelle, denn sie grenzt die Aufgabe auf den richtigen Kunden ein. Führen Sie das Vektor-Retrieval danach aus, denn es findet relevantes Langtextmaterial für diesen Kunden oder diese Aufgabe. Der IdentityRAG-Implementierungsleitfaden behandelt das umfassendere Retrieval-Muster, und der Vergleichsleitfaden zu Entity-Resolution-APIs hilft dabei, die Ebene neben den bestehenden Unternehmenssystemen einzuordnen.

Wenn sich die lesende Version bewährt hat, ergänzen Sie Leitplanken für schreibende Aktionen: Tools auf einer Allowlist, menschliche Prüfung bei sensiblen Entscheidungen, Aktionsprotokolle und klare Rollback-Pfade. Ziel ist nicht, das Modell für Identität verantwortlich zu machen. Ziel ist, das Modell zu einem sorgfältigen Konsumenten aufgelöster Identität zu machen.

FAQ

Sollte der KI-Agent die Kundenidentität selbst auflösen?

Nein. Der Agent sollte aufgelösten Kontext aus der Datenebene erhalten und nicht anhand roher Fragmente entscheiden, ob zwei Kundendatensätze dieselbe Person oder denselben Account betreffen.

Welche Abfrage sollte ein Agent zuerst stellen?

Hat die Anwendung bereits eine Entitäts-ID, nutzen Sie diese. Hat sie nur eine Quelldatensatz-ID, rufen Sie die Entität zu diesem Datensatz ab. Hat sie nur Teilattribute, durchsuchen Sie die Ebene der aufgelösten Entitäten.

Wo hilft Vektor-Retrieval weiterhin?

Vektor-Retrieval ist nach wie vor nützlich für semantisch relevante Dokumente, Notizen, Richtlinien und Support-Material. Es sollte neben der Abfrage der aufgelösten Entität stehen, nicht an ihrer Stelle.

Ersetzt das ein MDM, eine CDP, ein KYC/AML-System oder ein Data Warehouse?

Nein. Tilores sollte neben diesen Systemen stehen, als Zugriffsebene für aufgelöste Entitäten für Live-Anwendungen, Agenten und RAG-Systeme.

Welcher Kontext sollte an das Modell übergeben werden?

Übergeben Sie eine kompakte Zusammenfassung mit Entitäts-ID, ausgewählten Feldern, relevanten Quelldatensätzen, bei Bedarf Match-Nachweisen und Verweisen zurück in die Quellsysteme. Übergeben Sie nicht standardmäßig jeden Rohdatensatz.

Wie greifen deterministisches und Fuzzy Matching ineinander?

Nutzen Sie deterministische Regeln, wo stabile Identifikatoren vorliegen, und probabilistisches beziehungsweise Fuzzy Matching, wo Namen, Adressen, E-Mail-Adressen und andere Attribute zwischen Systemen variieren.

Wie vermeiden Teams veralteten Entitätskontext?

Cachen Sie stabile Identifikatoren, wo es sinnvoll ist, rufen Sie die aktuelle aufgelöste Entität aber zur Abfragezeit ab, bevor das Modell antwortet oder handelt.

Was ist der sicherste erste Aufbau?

Beginnen Sie mit einem lesenden Anwendungsfall, einer eng gefassten Feld-Allowlist, protokollierten Entitätsabfragen und einer menschlich geprüften Stichprobe, bevor Sie schreibende Aktionen erlauben.

Was ist das Fazit für die Umsetzung?

Die sauberste Agenten- und RAG-Architektur ist kein größerer Prompt. Sie ist eine bessere Übergabe aus der Datenebene. Lösen Sie Kundenentitäten auf, sobald Datensätze eintreffen, rufen Sie die aktuelle Entität ab, wenn der Agent Kontext braucht, und halten Sie das Vektor-Retrieval auf relevanten Text fokussiert. Das gibt dem Modell weniger Mehrdeutigkeit und dem Engineering-Team mehr Kontrolle.

Einen Blick auf diese Ebene auf Produktniveau finden Sie in der Tilores-Produktübersicht.