Wie ein Entity-Resolution-Graph aussieht und wie er abgefragt wird

Kurzfassung: Ein Entity-Resolution-Graph besteht aus Quelldatensätzen als Knoten, die über probabilistische und deterministische Match-Verknüpfungen als Kanten verbunden und zu einer Entitätssicht je Person oder Unternehmen aufgelöst werden. Wir bauen diesen Graphen bei der Ingestion auf, und unsere GraphQL-API erlaubt es, die aufgelöste Entität direkt abzufragen – per ID oder über jeden verknüpften Datensatz – und ihre verbundenen Datensätze, Match-Kanten und aggregierten Record Insights in einem einzigen Aufruf abzurufen.

Buchen Sie eine Demo, um einen aufgelösten Entitätsgraphen auf Ihren Daten zu sehen, oder holen Sie sich den Evaluierungs-Build, um ihn lokal abzufragen. Zum Retrieval-Muster siehe Tilores IdentityRAG.

Wie sieht ein Entity-Resolution-Graph konkret aus?

Jeder Datensatz, der bei uns eintrifft, wird zu einem Knoten, und die Originalwerte bleiben immer erhalten. Während der Ingestion können wir sie zusätzlich normalisieren: eine Telefonnummer vereinheitlichen, einen Namen bereinigen, eine E-Mail-Adresse korrigieren. Diese verbesserte Fassung speichern wir neben dem Original. Das Matching läuft auf den normalisierten Daten, und weil sie persistiert sind, können Sie die bereinigte Version auch nachgelagert nutzen. Der Graph hält beides vor: den Rohbeleg und die verbesserte Form.

Nun zu den Kanten. Eine Kante ist eine Verbindung, die unser Matcher zwischen zwei Knoten zieht, wenn genügend Belege dafür vorliegen, dass sie dieselbe reale Person oder dasselbe Unternehmen beschreiben – und jede Kante trägt die Regel mit sich, die sie erzeugt hat. Eine Kante bedeutet nie nur „diese beiden Datensätze passen zusammen“. Sie bedeutet „diese beiden Datensätze passen zusammen, weil ein exakter Vergleich der Steuernummer angeschlagen hat“ oder „weil ein unscharfer Namensvergleich zusammen mit einer gemeinsamen Telefonnummer den Schwellenwert überschritten hat“. Dieser Regelbezug erlaubt es einem Team, eine aufgelöste Identität bis zu dem exakten Beleg zurückzuverfolgen, der dahintersteht – genau die Spur, die Sie bei einem Audit, einem Widerspruch oder der Prüfung eines False Positive griffbereit haben wollen.

Fügt man genügend verbundene Knoten zusammen, entsteht eine aufgelöste Entität: Jeder Knoten, der von jedem anderen über mindestens eine Match-Kante erreichbar ist, wird Teil einer einzigen Entitätssicht – häufig Golden Record oder 360-Profil genannt. Die Entität ist kein neuer Datensatz, der die Quellen überschreibt; sie ist eine Sicht auf die verbundenen Datensätze, in beide Richtungen begehbar: von der Entität hinunter in einen Quelldatensatz oder von einem Datensatz hinaus in den Graphen ringsum. Jede Entität trägt zudem einen Match-Score, sodass Sie sehen, wie sicher die Auflösung ist, ohne aus dem Blick zu verlieren, warum eine Zusammenführung stattgefunden hat. Diesen Schwellenwert richtig zu setzen, ist eine Disziplin für sich, behandelt in Precision und Recall in der Entity (Identity) Resolution.

Wie bauen wir diesen Graphen bei der Ingestion auf?

Das Matching passiert, wenn ein Datensatz eintrifft, nicht erst, wenn ihn jemand später abfragt. Sobald ein neuer Datensatz eingeht, vergleichen wir ihn mit dem bereits Aufgelösten – mit deterministischen Regeln für Felder mit hoher Sicherheit (eine exakt übereinstimmende Steuernummer, eine verifizierte E-Mail-Adresse, ein amtlicher Identifikator) und mit probabilistischem, unscharfem Matching für alles andere: Namensvarianten, unterschiedliche Adressformate, phonetische Beinahe-Treffer und Teilüberschneidungen über mehrere schwächere Felder hinweg. Wo eine Regel ihren Schwellenwert überschreitet, fügen wir eine Kante hinzu; wo genügend Kanten eine Menge von Datensätzen verbinden, führen wir sie zu einer aufgelösten Entität zusammen.

Diese Auflösung und Zusammensetzung geschieht bei der Ingestion. Eine spätere Abfrage ruft die Entität in ihrem aktuellen, bereits aufgelösten Zustand ab, statt die Match-Logik bei Bedarf erneut auszuführen. Das ist überall dort entscheidend, wo die Latenz im Abfragepfad knapp bemessen ist: eine Servicekraft, die einen Kunden aufruft, eine Betrugsprüfung bei der Registrierung, ein KI-Agent mitten im Gespräch.

Diese Ingestion-Pipeline richtig hinzubekommen – Blocking, damit Vergleiche auch bei großen Mengen beherrschbar bleiben, Survivorship-Regeln dafür, welcher Wert gewinnt, wenn zwei Datensätze sich widersprechen, Nachtrainieren, wenn sich Quellen verändern – ist für sich genommen eine erhebliche technische Aufgabe. Die tatsächliche Komplexität eines korrekten Aufbaus behandeln wir in Die Komplexität der Entity-Resolution-Implementierung.

Abfragen im Entity-Resolution-Graphen: die drei Einstiegspunkte der API

Sind die Datensätze erst einmal zu einem Graphen aufgelöst, läuft die Abfrage des Entity-Resolution-Graphen auf drei Einstiegspunkte hinaus. Welchen Sie nutzen, hängt davon ab, was Sie über die gesuchte Person oder das gesuchte Unternehmen bereits wissen.

search: Gleicht Feldwerte, die Ihnen vorliegen, gegen den aufgelösten Graphen ab, wenn Sie noch keinen internen Identifikator besitzen.
entity: Ruft die vollständige aufgelöste Sicht zu einer Entitäts-ID ab, die Ihre Anwendung bereits führt.
entityByRecord: Findet die Entität, zu der ein einzelner Quelldatensatz aktuell gehört.

Einstiegspunkt	Was Sie übergeben	Was Sie zurückbekommen	Am besten geeignet für
search	Feldwerte (Name, E-Mail, Telefon, Steuernummer, Adresse)	Aufgelöste Kandidaten-Entitäten, nach Match-Score sortiert	Den Erstkontakt, wenn noch keine interne Entitäts-ID vorliegt
entity	Eine bekannte Entitäts-ID	Vollständige aufgelöste Sicht: Datensätze, Kanten, Duplikate, Insights	Eine 360-Sicht, sobald Ihre Anwendung die Entitäts-ID bereits führt
entityByRecord	Eine einzelne Quelldatensatz-ID	Die Entität, zu der dieser Datensatz aktuell gehört	Den Abgleich der eigenen Datensatz-ID eines Systems, nachdem ein neuer Match den Graphen darum herum verändert hat

Wie schreibt man eine GraphQL-Abfrage gegen eine aufgelöste Entität?

Hier zeigt sich, warum GraphQL seinen Platz im Stack verdient. Eine aufgelöste Entität kann viele verknüpfte Datensätze und wiederholte Felder tragen, und unterschiedliche Konsumenten wollen unterschiedliche Zuschnitte zurück: Ein Support-Dashboard will Namen und offene Vorgänge, ein Betrugsmodell will eindeutige Identifikatoren und Zählwerte, ein KI-Agent will eine kompakte Zusammenfassung, über die er in einem Zug schließen kann. Mit GraphQL fordert jeder Aufrufer in einer einzigen Anfrage genau die Felder und Aggregationen an, die er braucht, statt alle verknüpften Datensätze zu ziehen und die Antwort clientseitig umzubauen.

Hier eine Traversierungsabfrage gegen eine aufgelöste Entität, die die verknüpften Datensätze, die Match-Kanten und eine Aggregation über ein Feld via Record Insights anfordert:

query GetResolvedCustomer {
  entity(input: { id: "e_9f2a1c" }) {
    id
    score
    records {
      id
      sourceSystem
      firstName
      lastName
      email
      phone
      accountId
    }
    edges
    duplicates
    recordInsights {
      count
      emails: valuesDistinct(field: "email")
      phones: valuesDistinct(field: "phone")
    }
  }
}

Eine Antwort auf diese Abfrage sieht für eine Entität, die aus einem CRM-Kontakt, einem Support-Ticket und einem Zahlungsprofil aufgelöst wurde, so aus:

{
  "data": {
    "entity": {
      "id": "e_9f2a1c",
      "score": 0.94,
      "records": [
        { "id": "rec_crm_001", "sourceSystem": "CRM", "firstName": "Jordan",
          "lastName": "Alvarez", "email": "jordan.alvarez@acme.com",
          "phone": "+1-555-0134", "accountId": "A-58213" },
        { "id": "rec_support_447", "sourceSystem": "Support", "firstName": "Jordan",
          "lastName": "Alvarez", "email": "j.alvarez@acme.com",
          "phone": "+1-555-0134", "accountId": null },
        { "id": "rec_payments_112", "sourceSystem": "Payments", "firstName": "J.",
          "lastName": "Alvarez", "email": "jordan.alvarez@acme.com",
          "phone": null, "accountId": "A-58213" }
      ],
      "edges": [
        "rec_crm_001:rec_support_447:R1_PHONE_EXACT",
        "rec_crm_001:rec_payments_112:R2_EMAIL_EXACT",
        "rec_support_447:rec_payments_112:R3_NAME_FUZZY"
      ],
      "duplicates": {},
      "recordInsights": {
        "count": 3,
        "emails": ["jordan.alvarez@acme.com", "j.alvarez@acme.com"],
        "phones": ["+1-555-0134"]
      }
    }
  }
}

Drei Quelldatensätze, drei Systeme, drei leicht abweichende Schreibweisen derselben Person – aufgelöst zu einer Entität, bei der die Belege für jede Verbindung erhalten bleiben. Das Array edges zeigt genau, welche Regel welches Datensatzpaar verknüpft hat, score liefert auf einen Blick ein Maß für die Konfidenz, und recordInsights gibt eine eindeutige oder aggregierte Sicht zurück (eindeutige E-Mail-Adressen, Zählwerte, Filter, Gruppierungen), ohne dass Sie diese Logik in Ihrer eigenen Anwendung schreiben müssen. Alle Optionen für Filterung, Statistik und Aggregation finden Sie in unserer API-Dokumentation.

Wie speisen Sie aufgelöste Kundenentitäten in einen KI-Agenten oder eine RAG-Pipeline ein?

Ein Agent oder eine RAG-Pipeline, die ohne aufgelösten Entitätsgraphen im Hintergrund über „den Kunden“ schließt, schließt über das Fragment, das gerade zufällig aufgetaucht ist: ein Support-Ticket, ein Zahlungsdatensatz, eine alte CRM-Zeile – nie über das Gesamtbild. Aufgelöste Kundendaten in einen Agenten einzuspeisen bedeutet, dass der Retrieval-Schritt die Entität zurückgibt, nicht den Datensatz, und zwar aus einem einzigen Aufruf der Entity-Resolution-Graph-API.

In der Praxis sitzt die obige Abfrage vor dem Retrieval-Schritt des Agenten: Der Agent fragt die Entität an (per ID oder über eine Suche nach einem Namen oder einer E-Mail-Adresse aus dem Gespräch), erhält die aufgelösten Datensätze und aggregierten Insights zurück und schließt darüber, statt selbst Fragmente zusammenzuflicken. Unser MCP-Server stellt genau diese aufgelöste Schicht als Tools bereit, die ein Assistent direkt aufrufen kann. Er ist öffentlich, zustandslos und nur lesend, hält selbst keine Kundendaten vor und schreibt nie in eine Tilores-Instanz. So erhält ein Agent typisierte Abfragevorlagen und Validierung gegen den aufgelösten Graphen, ohne dass Sie für jeden angebundenen Assistenten eine eigene Retrieval-Schicht bauen müssen.

Ein LLM ist wirklich gut darin, mitten im Gespräch über mehrdeutige Sprache zu schließen – zwei Namen, die dieselbe Person meinen könnten, eine Nachricht, die ein Konto über einen Spitznamen referenziert. Es sollte aber nicht das System sein, das entscheidet, ob zwei Kundendatensätze dieselbe Entität bezeichnen. Diese Entscheidung gehört in die Resolution-Schicht, oberhalb des Agenten und seines Prompts – aus den Gründen, die in Können LLMs für Entity Resolution eingesetzt werden? beschrieben sind.

Warum einen aufgelösten Graphen abfragen statt Rohdatensätze?

Eine generische Graphdatenbank speichert bereitwillig die Knoten und Kanten, die Sie ihr übergeben, und ein Vektorindex liefert bereitwillig Datensätze zurück, die sich im Embedding-Raum ähneln – aber keines von beiden entscheidet, welche Datensätze überhaupt verbunden gehören. Genau diese Entscheidung – deterministische Regeln für Felder, die nie mehrdeutig sein dürfen, plus probabilistisches Matching für alles andere – ist der eigentlich schwierige Teil, und sie ist das, was ein Entity-Resolution-Graph zusätzlich zu generischer Graph- oder Vektorspeicherung liefert.

Diese Schicht steht neben Ihren bestehenden MDM-, CDP-, Data-Warehouse- und KYC-/AML-Systemen, statt eines davon zu ersetzen; jene Systeme verantworten weiterhin Governance, Datenherkunft und Workflows. Der aufgelöste Entitätsgraph ergänzt darunter die Matching- und Verknüpfungslogik, sodass jedes nachgelagerte System dieselbe aktuelle, aufgelöste Sicht abfragt, statt einen eigenen Abgleich zu betreiben. Wie das neben dem Stammdatenmanagement funktioniert, behandeln wir in Entity-Resolution-Technologie für besseres Stammdatenmanagement nutzen.

FAQ

Wie sieht ein Entity-Resolution-Graph aus und wie wird er abgefragt?

Ein Entity-Resolution-Graph besteht aus Quelldatensätzen als Knoten, die über Match-Kanten verbunden sind (jede trägt die Regel, die sie erzeugt hat) und zu einer aufgelösten Entitätssicht je Person oder Unternehmen zusammengeführt werden. Abgefragt wird er über GraphQL mit drei Einstiegspunkten: search nach Feldwerten, entity per ID für die vollständige aufgelöste Sicht oder entityByRecord, um die Entität zu finden, zu der ein bestimmter Datensatz jetzt gehört.

Was sind Knoten und Kanten in einem Entity-Resolution-Graphen?

Knoten bewahren die ursprünglichen Quelldatensätze zusammen mit den normalisierten Werten, die während der Ingestion gespeichert wurden. Das Matching läuft auf den normalisierten Daten, das Original bleibt weiterhin verfügbar. Kanten sind die Verbindungen, die unser Matcher zieht, sobald genügend Belege zwei Knoten verknüpfen – jeweils beschriftet mit der Regel, die sie erzeugt hat, sodass sich eine aufgelöste Entität immer bis zu ihren Match-Belegen zurückverfolgen lässt.

Wie fragt man eine aufgelöste Entität über GraphQL ab?

Rufen Sie entity mit einer bekannten Entitäts-ID auf, search mit Feldwerten oder entityByRecord mit einer Quelldatensatz-ID und fordern Sie die Felder an, die Sie brauchen: records, edges, duplicates, score sowie recordInsights oder edgeInsights. GraphQL lässt jeden Aufrufer die Antwort selbst zuschneiden, statt alle verknüpften Datensätze zu erhalten.

Was ist der Unterschied zwischen einem Datensatz und einer aufgelösten Entität?

Ein Datensatz ist die Rohdarstellung eines einzelnen Quellsystems: ein CRM-Kontakt, ein Support-Ticket, ein Zahlungsprofil. Eine aufgelöste Entität ist die verbundene Menge von Datensätzen, die unser Matcher mit ausreichender Konfidenz verknüpft hat, weil sie dieselbe reale Person oder dasselbe Unternehmen beschreiben.

Wie speisen Sie aufgelöste Kundenentitäten in einen KI-Agenten oder eine RAG-Pipeline ein?

Stellen Sie den aufgelösten Entitätsgraphen vor den Retrieval-Schritt, damit der Agent die Entität anfragt und nicht den Rohdatensatz. Ein einzelner GraphQL-Aufruf – per Entitäts-ID oder per Suche nach einem Namen oder einer E-Mail-Adresse aus dem Gespräch – liefert die aktuellen verknüpften Datensätze und aggregierten Insights zu einer Person.

Führt jede Abfrage des Graphen das Entity-Matching erneut aus?

Nein. Das Matching passiert bei der Ingestion. Eine Abfrage ruft die Entität in ihrem aktuellen, bereits aufgelösten Zustand ab, statt Übereinstimmungen im laufenden Betrieb neu zu berechnen. Das hält die Latenz zur Abfragezeit für Betrugsprüfungen und Agentengespräche vorhersehbar.

Kann ein Entity-Resolution-Graph eine Graphdatenbank oder eine Vektordatenbank ersetzen?

Er löst ein anderes Problem. Generische Graph- und Vektorspeicher halten die Knoten, Kanten oder Embeddings, die Sie ihnen geben; sie entscheiden nicht, welche Datensätze verbunden werden sollten. Ein Entity-Resolution-Graph ergänzt die Matching-Logik, die diese Entscheidung trifft, und stellt das Ergebnis als abfragbaren Graphen bereit – neben Ihren MDM-, CDP-, Warehouse- und KYC-/AML-Systemen, nicht als deren Ersatz.