So verhindern Sie, dass KI-Agenten zwei Kunden verwechseln

Kurzfassung: Verhindern Sie, dass KI-Agenten zwei Kunden verwechseln, indem Sie die Kontextschicht in Ordnung bringen, bevor das Modell schlussfolgert. Kundendatensätze sollten bereits bei der Ingestion zu dauerhaften Entitäts-IDs aufgelöst werden, mehrdeutige Übereinstimmungen sollten nach Konfidenz und Belegen weitergeleitet werden, und der Agent sollte zur Abfragezeit einen bereits aufgelösten Customer-360-Kontext abrufen. Ein besserer Prompt kann eine Retrieval-Schicht nicht zuverlässig reparieren, die dem Modell doppelte Personen, veraltete CRM-Datensätze und zwei plausible Kunden mit demselben Namen liefert.

Identitätsschicht

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

Lösen Sie Kundendatensätze auf, bevor sie Ihren KI-Agenten erreichen. Tilores liefert Identity und Entity Resolution in Echtzeit.

Tilores Kundendatensätze auflösen, bevor sie Ihren KI-Agenten erreichen

Auflösungspfad

Vektordatenbank

Dokumente

MDM / CDP

Datensätze

Tilores API

aufgelöste Identität

Warum verwechseln KI-Agenten Kunden mit ähnlichen Namen?

Ein LLM verfügt über keinen dauerhaften Identitätsgraphen für Kunden. Es sagt auf Basis des Kontexts voraus, den es erhält. Enthält das Kontextfenster zwei Datensätze für John Smith, eine alte E-Mail-Adresse, ein Ticket der Ehepartnerin und einen Abrechnungsdatensatz aus einem anderen Konto, kann das Modell eine flüssig formulierte Antwort erzeugen, die Fakten mehrerer Personen vermischt.

Der übliche Fehler besteht nicht darin, dass dem Modell eine bessere Anweisung fehlt. Der Fehler besteht darin, dass das Retrieval-System das Modell implizit mit Entity Resolution beauftragt hat. Das Modell sieht einen Stapel plausibler Datensätze und wählt aus, was stimmig wirkt. In Kundenprozessen reicht stimmig nicht aus.

Für Entwicklungsteams lautet die nützliche Lehre nicht, dass jeder Agent denselben Anbieter braucht. Sie lautet, dass Agenten eine aufgelöste Identitätsschicht benötigen, bevor sie Kundenkontext erhalten.

Fehler im Kontext	Was der Agent sieht	Was schiefgehen kann	Sichereres Muster
Ähnliche Namen	Zwei Personen namens Daniel Meyer in CRM und Support	Die Antwort vermischt Tickets, Bestellungen oder Berechtigungen	Vor dem Retrieval zu einer dauerhaften Entitäts-ID auflösen
Doppelte Datensätze	Eine Person hat einen alten und einen neuen CRM-Kontakt	Der Agent behandelt einen veralteten Datensatz als aktuell	Datensätze bei der Ingestion verknüpfen und eine Entität abrufen
Fragmentierte Systeme	Abrechnung, Support und CRM widersprechen sich	Das Modell wählt ein Feld ohne Beleg	Quell-IDs, Scores, Kanten und freigegebene Felder zurückgeben
Schwache Übereinstimmung	Die Suche findet mehrere plausible Entitäten	Das Modell antwortet selbstbewusst aus dem falschen Datensatz	Zur Prüfung weiterleiten oder eine klärende Rückfrage stellen
Übermerge	Ein gemeinsamer Haushalt oder eine gemeinsame Geschäftsadresse verknüpft zwei Personen	Private Daten können zwischen Kunden abfließen	Starke Kennungen und Prüfpfade für Splits verlangen

• Wie sollte die Identitätsschicht für Kunden funktionieren?
• Was bedeuten score und hitScore für Entscheidungen von Agenten?
• Wie verhindert ein Workflow mit aufgelösten Entitäten Verwechslungen?
• Wie sieht ein CRM-Beispiel von Anfang bis Ende aus?
• Welche Fehlerfälle sollte der Workflow abdecken?
• Welche Fallstricke gefährden die Identität von Agenten weiterhin?
• FAQ

Wie sollte die Identitätsschicht für Kunden funktionieren?

Setzen Sie die Identity-Resolution-Schicht vor die Retrieval-Schicht des Agenten. Neue Datensätze aus CRM, Support, Abrechnung, Produktanalytik und Marketing sollten der Auflösungsschicht übergeben werden, sobald sie eintreffen. Die Auflösungsschicht verknüpft den Datensatz mit einer bestehenden Entität oder legt eine neue Entität an. Der Agent fragt später die aufgelöste Entität ab, nicht die rohen Quelltabellen.

Der Ablauf ist bewusst unspektakulär:

1. Kundendatensätze bei der Ingestion übergeben.
2. Datensätze zu dauerhaften Entitäts-IDs auflösen.
3. Belege für die Übereinstimmung und Konfidenzsignale erhalten.
4. Schwellenwerte für automatische Nutzung und manuelle Prüfung festlegen.
5. Aufgelösten Kontext zur Abfragezeit abrufen.
6. Falsche Kundenzuordnungen und Prüfergebnisse überwachen.

Die Reihenfolge ist entscheidend. Wird die Identität erst nach dem Retrieval zusammengesetzt, hat das Modell den unaufgeräumten Zustand bereits gesehen. Findet die Auflösung bei der Ingestion statt, kann die Retrieval-Anfrage eng gefasst sein: Finde die aufgelöste Entität zu dieser E-Mail-Adresse, Telefonnummer, Konto-ID oder angegebenen Kennung und gib nur die freigegebenen Felder zurück.

Diese Grenze markiert die Übergabe von der Architektur an die Implementierung. In Tilores werden Identitäten während der Ingestion anhand konfigurierter Regeln und probabilistischem Matching aufgelöst. Die Abfragezeit dient dazu, den bereits aufgelösten Kunden- oder Entitätskontext abzurufen und zu nutzen. Der Agent sollte keine Kundenidentität zusammensetzen, während er eine Frage stellt.

Die konkrete API-Form ergibt sich aus dieser Übergabe. Die Seite zur Entity-Resolution-Software von Tilores erläutert die Echtzeit-Identitätsschicht, auf der dieses Muster aufbaut, und die Tilores-API-Dokumentation zeigt die GraphQL-Operationen für Suche, Übergabe und Entitäten. In den Beispielen zu Suche und Entitäten legt Tilores Datensätze, Kanten, Duplikate, Treffer, score und hitScore offen. Genau solche Artefakte ermöglichen es einem Engineering-Team zu erklären, warum ein bestimmter Kundenkontext an einen Agenten zurückgegeben wurde.

Was bedeuten score und hitScore für Entscheidungen von Agenten?

Felder zur Match-Konfidenz machen aus Entity Resolution eine operative Entscheidung und nicht bloß ein Suchergebnis. Ein Signal sollte dem Workflow sagen, ob die zurückgegebene Entität sauber zusammengesetzt ist; ein anderes kann angeben, ob diese konkrete Suchanfrage ein naheliegendes Ergebnis für die übergebenen Kennungen gefunden hat.

In der Tilores-API-Dokumentation gibt score die Gesamtqualität der Übereinstimmungen innerhalb einer Entität wieder, während hitScore anzeigt, wie genau die zurückgegebene Entität zu den Suchparametern passt. Beide liegen auf einer Skala von 0,0 bis 1,0 und sind als Float-Werte im Bereich (0.0, 1.0] dokumentiert, wobei höher eine bessere Matching-Qualität bedeutet. Dieselbe API-Referenz zeigt die GraphQL-Operationen für Suche, Übergabe und Entitäten, und die Beispiele legen Datensätze, Kanten, Duplikate, Treffer, score und hitScore offen.

Machen Sie aus diesen Feldern keine universellen Schwellenwerte, ohne sie zu testen. Ein produktiver Schwellenwert hängt von Datenqualität, Aussagekraft der Kennungen, Vertrauenswürdigkeit der Quelle, Risiko des Workflows und den Kosten falsch positiver gegenüber falsch negativer Treffer ab.

Eine praxistaugliche Regel könnte so aussehen – die Zahlen sind jedoch illustrativ und müssen kalibriert werden:

Entscheidungsband	Illustratives Signal	Verhalten des Agenten
Automatische Nutzung	Eine einzige Kandidatenentität, starke Kennungen, hoher hitScore, hoher score der Entität, keine widersprüchlichen Belege aus den Quellen	Den aufgelösten Kontext abrufen und im zulässigen Rahmen des Workflows antworten
Eingeschränkte Antwort	Eine wahrscheinliche Entität, aber ein veraltetes Quellfeld oder eine schwache sekundäre Kennung	Nur risikoarme Fragen beantworten oder eine weitere Kennung erfragen
Menschliche Prüfung	Mehrere Kandidaten, mittlerer hitScore, widersprüchliche Datensätze oder Belege für eine gemeinsame Adresse beziehungsweise ein gemeinsames Gerät	Eine Prüfaufgabe anlegen und dem Nutzer mitteilen, dass das Konto verifiziert werden muss
Keine Übereinstimmung	Kein Kandidat überschreitet den Schwellenwert des Workflows	Keine Identität ableiten; zusätzliche Kennungen erfragen oder einen neuen Onboarding-Pfad anlegen

Der Schwellenwert für einen Support-FAQ-Bot kann sich von dem für einen Erstattungsagenten, einen KYC-Prozess oder ein Betrugsmodell unterscheiden. Ein Agent mit geringem Risiko, der den Versandstatus erklärt, verträgt eine andere Prüfquote als ein Agent, der Abrechnungen ändert, private Daten offenlegt oder Kredite bewilligt.

Wie verhindert ein Workflow mit aufgelösten Entitäten Verwechslungen?

Ein Workflow mit aufgelösten Entitäten gibt dem Agenten ein einziges, kontrolliertes Werkzeug an die Hand. Das Werkzeug nimmt Kennungen entgegen, ruft die Identitätsschicht auf und liefert ein eingegrenztes Customer-360-Objekt zurück. Der Agent durchsucht nicht auf eigene Faust jede CRM-Notiz, jedes Support-Ticket und jede Rechnung.

Eine brauchbare Antwortstruktur enthält die aufgelöste Entitäts-ID, die Anzahl der Kandidaten, die zulässigen Profilfelder, die verknüpften Quelldatensätze, die Belege, die Konfidenzsignale und den Eskalationsstatus. Sie sollte außerdem die IDs der Quellsysteme enthalten, damit ein Mensch die Antwort später nachvollziehen kann.

Das Werkzeug kann beispielsweise diese konzeptionellen Felder zurückgeben:

Feld	Zweck
entityId	Stabiler Bezeichner, auf den sich der Agent und der nachgelagerte Workflow beziehen können
candidateCount	Ob es eine eindeutige Entität gab oder mehrere plausible Entitäten
context	Freigegebene Kundenfakten für die Rolle des Agenten, etwa Kontostatus oder offene Tickets
records	IDs der Quellsysteme aus CRM, Support, Abrechnung und Produktsystemen
edges	Warum Datensätze im aufgelösten Entitätsgraphen miteinander verbunden sind
score	Signal für die Gesamtqualität der aufgelösten Entität
hitScore	Signal für die Suchrelevanz der übergebenen Kennungen
actionPolicy	Ob der Agent antworten, weitere Verifizierung verlangen oder zur Prüfung weiterleiten darf

Damit wird Identität zu einem Systemverhalten statt zu einem Prompt-Verhalten. Das Modell kann weiterhin eine hilfreiche Antwort formulieren, ist dabei aber in einer kontrollierten Nutzlast verankert.

Wie sieht ein CRM-Beispiel von Anfang bis Ende aus?

Stellen Sie sich vor, eine Kundin schreibt: „Ich bin Maya Carter von Northline. Warum wurde meine Verlängerung zweimal abgerechnet?“ Im CRM steht Maya Carter bei Northline Ltd mit der E-Mail-Adresse maya.carter@northline.example. In HubSpot liegt M. Carter von Northline mit einer privaten E-Mail-Adresse. Beim Support existiert ein Ticket von Mayas Assistenz. In der Abrechnung gibt es zwei Kunden-IDs, weil eine frühere Migration ein doppeltes Konto erzeugt hat.

Ein naiver Agent sucht nach Name und Unternehmen. Er findet den CRM-Kontakt, das Support-Ticket der Assistenz und beide Abrechnungsdatensätze. Das Modell sieht genug Belege, um zu antworten, ordnet aber möglicherweise das Ticket der Assistenz Maya zu oder behandelt den doppelten Abrechnungsdatensatz als eigenständigen Kunden.

Ein aufgelöster Workflow geht anders vor:

1. Die Datensätze aus CRM, HubSpot, Support und Abrechnung wurden bei ihrem Eintreffen an die Identitätsschicht übergeben.
2. Die Identitätsschicht verknüpfte den CRM- und den HubSpot-Datensatz zu einer Entität und behielt die Assistenz als verwandten Kontakt bei, nicht als dieselbe Person.
3. Die beiden Abrechnungs-IDs wurden als Quelldatensätze derselben Kundenentität verknüpft, unter Erhalt der Belege.
4. Der Agent erhält die Nachricht und ruft das Werkzeug für aufgelöste Kundendaten mit Name, Unternehmen und – sofern vorhanden – E-Mail-Adresse auf.
5. Das Werkzeug liefert eine Entitäts-ID, die verknüpften Abrechnungs-Quell-IDs, score, hitScore, Kanten und eine Richtlinie zurück, die eine Erklärung zum Abrechnungsstatus erlaubt, für die Auslösung einer Erstattung aber eine menschliche Freigabe verlangt.
6. Der Agent erklärt, dass zwei Abrechnungsdatensätze existieren, eröffnet ein Prüfticket und gibt keine Daten aus der separaten Identität der Assistenz preis.

Die entscheidende Verbesserung besteht nicht darin, dass das Modell klüger geworden wäre. Der Kontext wurde enger und wahrhaftiger.

Welche Fehlerfälle sollte der Workflow abdecken?

Der Workflow sollte Übermerges, fehlende Verknüpfungen, veraltete Datensätze, gemeinsam genutzte Kennungen und Konflikte zwischen Quellen abdecken.

Ein Übermerge entsteht, wenn zwei reale Personen zu einer Entität werden. Das ist der riskanteste Fehler im Support, weil der Agent private Daten offenlegen kann. Gemeinsame Haushalte, Familientarife, Unternehmensdomains, Callcenter-Nummern und Geschäftsadressen dürfen Identitäten nicht automatisch zusammenfallen lassen.

Eine fehlende Verknüpfung entsteht, wenn eine reale Person über mehrere Datensätze verteilt bleibt. Der Agent verweigert dann möglicherweise eine Berechtigung, übersieht ein früheres Ticket, dupliziert Arbeit oder gibt widersprüchliche Antworten. Namensänderungen, geänderte E-Mail-Adressen, Transliterationen und Migrationen von Quellsystemen sind häufige Ursachen.

Ein Fehler durch veraltete Datensätze entsteht, wenn eine alte Adresse, eine alte E-Mail-Adresse oder ein geschlossenes Konto die aktuelle Quelle verdrängt. Die Lösung liegt nicht allein im Matching. Die Customer-360-Nutzlast braucht Angaben zur Aktualität der Quelle, Survivorship-Regeln und eine Priorisierung der Quellen.

Ein Quellkonflikt entsteht, wenn das CRM das Konto als aktiv führt, die Abrechnung eine fehlgeschlagene Zahlung meldet und der Support das Konto als gekündigt ausweist. Die Identitätsschicht kann dem Agenten sagen, welche Datensätze zusammengehören. Der Workflow braucht darüber hinaus eine Richtlinie dazu, welchen Feldern der Agent für welche Aktion vertrauen darf.

Welche Fallstricke gefährden die Identität von Agenten weiterhin?

Der erste Fallstrick besteht darin, die Vektorsuche mit dem Identitätsproblem zu beauftragen. Vektorsuche kann ähnliche Richtlinien, Dokumente und Tickets finden. Sie belegt nicht, dass zwei Datensätze denselben Kunden betreffen. Nutzen Sie Vektoren für semantisches Retrieval und Entity Resolution für die Kundenidentität.

Der zweite Fallstrick besteht darin, dem Agenten-Workflow die Belege vorzuenthalten. Gibt das Werkzeug nur ein flaches Profil zurück, kann der Agent eine saubere Übereinstimmung nicht von einer gerade noch akzeptablen unterscheiden. Geben Sie die Belege an den Workflow zurück, selbst wenn das Modell nur einen Teil davon sieht.

Der dritte Fallstrick ist ein einziger globaler Schwellenwert. Betrug, Support, KYC, Abrechnung und Marketing tolerieren falsch positive und falsch negative Treffer unterschiedlich stark. Die Identitätsschicht sollte workflowspezifische Schwellenwerte und Prüfpfade unterstützen.

Der vierte Fallstrick besteht darin, das LLM als produktives Matching-System einzusetzen. Zu dieser Frage ist der Tilores-Artikel über LLMs und Entity Resolution eindeutig: LLMs können bei der Extraktion, der Exploration kleiner Datenmengen oder der Unterstützung menschlicher Prüfer helfen, taugen aber kaum als alleiniges, auditierbares Matching-System im Produktivbetrieb, weil Konsistenz, Erklärbarkeit, Schwellenwert-Tuning, Persistenz, Kosten und Latenz zählen.

Der fünfte Fallstrick besteht darin, die Korrektur zu vergessen. Falsche Merges und übersehene Verknüpfungen kommen vor. Ein produktives Design braucht Funktionen zum Trennen, Zusammenführen, Löschen und Neuverarbeiten sowie eine Benachrichtigung nachgelagerter Systeme, die den Entitätszustand zwischengespeichert haben.

Die Support-Agenten-Variante dieses Musters folgt derselben Grundidee wie RAG auf Basis von Entity Resolution: Das Modell sollte den richtigen Kundenkontext erhalten, nachdem die Identität aufgelöst wurde, und nicht einen Stapel semantisch plausibler Datensätze. Der Tilores-Artikel zu EntityRAG, Tilores Customer 360, die Tilores-Dokumentation zu Regeln und die Tilores-IdentityRAG-Seite helfen dabei, dieses Muster in einen produktiven Datenfluss zu überführen.

Der sechste Fallstrick besteht darin, den Agenten Unsicherheit in geschliffener Sprache verstecken zu lassen. Eine gut formulierte Antwort kann eine schwache Übereinstimmung als geklärt erscheinen lassen. Die Antwort des Werkzeugs sollte deshalb die Anzahl der Kandidaten, den Zustand der Belege und die zulässige Aktionsstufe in Feldern mitführen, die der Workflow durchsetzen kann. Der Assistent darf die Unsicherheit gegenüber dem Kunden erklären, aber er sollte einen Prüffall nicht zu einer Antwort herabstufen, nur weil das Gespräch dann flüssiger verliefe.

Wie sollten Schwellenwerte in der Praxis kalibriert werden?

Schwellenwerte sollten anhand gelabelter Kundendaten kalibriert und nicht aus einer Anbieterdemo übernommen werden. Beginnen Sie mit einem Testdatensatz, der bekannte Datensätze desselben Kunden, bekannte Datensätze verschiedener Kunden und bewusst mehrdeutige Fälle enthält. Nehmen Sie die unsauberen Beispiele auf, die Agenten tatsächlich schaden: mehrfach genutzte Geschäftsadressen, gemeinsam genutzte Familientelefone, häufige Namen, Transliterationen, kürzlich geänderte E-Mail-Adressen, fusionierte Unternehmen, doppelte Abrechnungs-IDs und veraltete Support-Anfragende.

Bewerten Sie für jeden Workflow die Kosten der beiden Fehlerarten getrennt. Ein falsch positiver Treffer bedeutet, dass zwei verschiedene Personen oder Unternehmen als eine Entität behandelt wurden. In einem KI-gestützten Support-Prozess kann das Kontoinformationen preisgeben. In KYC oder im Kreditgeschäft kann es eine Entscheidung verfälschen. Ein falsch negativer Treffer bedeutet, dass ein realer Kunde über mehrere Datensätze verteilt bleibt. Dadurch kann ein Agent eine Berechtigung verweigern, ein offenes Ticket übersehen oder doppelte Konten anlegen.

Arbeiten Sie mit Schwellenwertbändern statt mit einer einzigen Zahl. Ein Band hoher Konfidenz kann den Agenten automatisch beliefern, wenn das Ergebnis eine einzige Entität ist und die Belege starke Kennungen enthalten. Ein Prüfband sollte plausible, aber riskante Übereinstimmungen abfangen, insbesondere wenn die Felder nur bei schwachen Belegen wie Name und Unternehmensdomain übereinstimmen. Ein Band ohne Aktion sollte den Assistenten zwingen, weitere Kennungen anzufordern oder einen neuen Aufnahmeweg zu eröffnen.

Kalibrieren Sie je Workflow. Ein Helpdesk-Assistent mit geringem Risiko darf allgemeine Produktfragen auch bei schwacher Identität beantworten, weil er keine privaten Kontodaten offenlegt. Ein Erstattungs-, Abrechnungs- oder KYC-Workflow sollte stärkere Belege verlangen. Betrugsteams nehmen mitunter mehr Prüfaufwand in Kauf, um den Recall zu verbessern, während datenschutzsensible Support-Prozesse häufig eine höhere Precision erfordern.

Halten Sie die Schwellenwertentscheidung außerhalb des Sprachmodells. Das Modell kann den Zustand gegenüber dem Kunden erklären, aber der Workflow sollte entscheiden, ob die Identitätsbelege eine Aktion zulassen. Das ist der Unterschied zwischen einer prüfbaren Kontrolle und einer überzeugend klingenden Vermutung.

Welches Logging und welche Auswertung sollten nach dem Launch laufen?

Das Monitoring nach dem Launch sollte Identitätsergebnisse verfolgen, nicht nur die Zufriedenheit mit dem Chatbot. Jede kundenbezogene Antwort sollte bis zur Entitäts-ID, zur Werkzeuganfrage, zur zurückgegebenen Kandidatenzahl, zu den Quelldatensätzen, zu score, hitScore, zur Aktionsrichtlinie und zu der Frage nachvollziehbar sein, ob der Assistent geantwortet, eine Verifizierung verlangt oder eskaliert hat.

Ziehen Sie wöchentlich eine Stichprobe aus aufgelösten und eskalierten Konversationen. Achten Sie auf Übermerges, unverknüpfte Konten, Konflikte zwischen Quellsystemen, veraltete Daten und Fälle, in denen der Assistent zwar die richtige Entität hatte, aber das falsche zulässige Feld genutzt hat. Diese Kategorien verweisen auf unterschiedliche Korrekturen. Ein Matching-Fehler gehört in die Identitätsschicht. Ein Richtlinienfehler gehört in die Aktionsschicht. Ein Antwortfehler gehört in die Prompt- oder Modellschicht.

Richten Sie eine Korrekturschleife ein. Wenn eine Support-Mitarbeiterin einen falschen Merge oder eine übersehene Verknüpfung entdeckt, sollte die Auflösungsschicht dieses Feedback erhalten, und nachgelagerte Systeme sollten sich nicht länger auf den alten Entitätszustand verlassen. Ohne Korrekturschleife kann derselbe falsche Kundenkontext immer wieder in Agentengesprächen auftauchen.

Behandeln Sie die Prüflast als Kennzahl erster Ordnung. Ist der Schwellenwert zu streng, wird der Assistent nutzlos, weil jeder Fall eskaliert. Ist er zu locker, steigt das Risiko falscher Kundenzuordnungen. Die richtige Einstellung ist der Punkt, an dem das Prüfvolumen operativ beherrschbar bleibt und risikoreiche Aktionen weiterhin geschützt sind.

Verfolgen Sie falsch positive und falsch negative Treffer getrennt. Falsch positive Treffer sind das Datenschutz- und Compliance-Problem: Zwei verschiedene Kunden werden zu einem Kontext. Falsch negative Treffer sind das Serviceproblem: Ein realer Kunde bleibt über mehrere Konten verteilt, und der Agent übersieht seine Historie. Eine einzelne Genauigkeitskennzahl kann verbergen, welcher Fehlerfall sich gerade verschlechtert.

Pflegen Sie schließlich ein adversariales Testpaket. Nehmen Sie jeden Produktionsvorfall und jeden Beinahefehler in ein Regressionsset auf: Kunden mit gleichem Namen, gemeinsame Haushalte, doppelte Quell-IDs, geänderte E-Mail-Adressen, migrierte Abrechnungskonten und Fälle mit Firmenaliassen. Lassen Sie dieses Paket vor Modelländerungen, Retrieval-Änderungen und Änderungen an Identitätsregeln laufen.

FAQ

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

Lösen Sie Kundendaten auf, bevor der Agent Kontext erhält. Der Agent sollte eine stabile Entitäts-ID und ein aufgelöstes Customer-360-Objekt samt Konfidenzbelegen abfragen, statt zwischen rohen Fragmenten aus CRM, Support und Abrechnung wählen zu müssen.

Sollte ein LLM entscheiden, ob zwei Kundendatensätze dieselbe Person sind?

Nicht als produktives führendes System. LLMs können beim Extrahieren von Kennungen, beim Zusammenfassen von Belegen oder bei der Prüfung kleiner Fallzahlen helfen, doch produktives Identitäts-Matching sollte bewertbar, wiederholbar, auditierbar und außerhalb des Sprachmodells gesteuert sein.

Worin unterscheiden sich score und hitScore in den Suchergebnissen von Tilores?

Der Unterschied liegt zwischen Entitätsqualität und Übereinstimmung mit den Suchparametern. Die Tilores-Dokumentation beschreibt score als die Gesamtqualität der Übereinstimmungen innerhalb einer Entität und hitScore als das Maß dafür, wie genau ein Suchergebnis zu den Suchparametern passt. Teams sollten beide auf ihren eigenen Daten kalibrieren, bevor sie Schwellenwerte für automatische Aktionen einsetzen.

Ab welchem Konfidenzwert sollten Kundendatensätze automatisch zusammengeführt werden?

Es gibt keinen universellen Schwellenwert. Ein sicheres Muster ist, nur eine einzelne Entität mit hoher Konfidenz, starken Kennungen und sauberen Belegen automatisch zu verwenden, mittlere Konfidenz oder widersprüchliche Belege zur Prüfung weiterzuleiten und auf eine Aktion zu verzichten, wenn kein Kandidat den Schwellenwert des Workflows erreicht.

Löst die Vektorsuche das Problem verwechselter Kundenidentitäten?

Nein. Die Vektorsuche kann semantisch ähnliche Dokumente oder Tickets finden, belegt aber nicht, zu welchem Kunden, Konto oder Unternehmen die Daten gehören. Nutzen Sie die Vektorsuche für Wissensabrufe und Entity Resolution für den Kundenkontext.

Wo gehört die menschliche Prüfung hin?

Die Prüfung gehört dorthin, wo die Belege mehrdeutig sind, wo zwei Entitäten plausibel zusammenpassen könnten, wo Quellsysteme sich widersprechen oder wo die Aktion des Agenten Daten offenlegen, den Kontostatus ändern, Kredite bewilligen, Erstattungen auslösen oder die Compliance berühren könnte.

Wie teste ich, ob Agenten weiterhin Kunden verwechseln?

Bauen Sie Testfälle mit ähnlichen Namen, gemeinsamen Domains, geänderten E-Mail-Adressen, gemeinsamen Adressen, doppelten Kontakten, Familienmitgliedern, Unternehmen mit Aliassen und bekannten Nicht-Übereinstimmungen. Messen Sie falsche Kundenzuordnungen im Retrieval, Übermerges, fehlende Verknüpfungen, Prüfvolumen und Auflösungslatenz.

Löst Tilores Identitäten zur Abfragezeit auf?

Nein. Tilores löst Identitäten bei der Ingestion auf. Zur Abfragezeit ruft der Agent den bereits aufgelösten Kunden- oder Entitätskontext über APIs ab und nutzt ihn.