Phase 2 · Praxis-Step 6 von 9
Identität und Zeit stabilisieren
Dubletten, Aliase, Rollenwechsel und Gültigkeitszeiträume als eigene Graphqualität behandeln.
Was du mitnimmst
Graphqualität entsteht nach der Extraktion: stabile Identität und klare Zeiträume machen Pfade fachlich belastbar.
Praxisziel
Was du praktisch entscheidest
Du erstellst ein JSON für Identitätsentscheidungen mit Entscheidung, Grund, Risiko und Zeitregel.
Szenario
Ausgangslage im Mini-Use-Case
Die Projektliste nennt "CRM". Der Systemkatalog nennt "Customer Relationship Management". Eine Verantwortlichkeitsnotiz spricht vom "Kunden-System". Jetzt braucht das System eine Entscheidung: dieselbe Entität, getrennte Entitäten oder ein unklarer Fall mit Review-Bedarf.
Für Menschen ist diese Frage oft schnell geklärt, weil sie Kontextwissen besitzen. Für ein System ist sie ein Qualitätsrisiko. Zu großzügige Zusammenführung vermischt Objekte. Zu enge Trennung erzeugt Dubletten. Beides schwächt Pfade.
Zeit verschärft das Problem. Ein System kann früher einem anderen Team gehört haben als heute. Eine Richtlinie kann ersetzt worden sein. Eine Verantwortlichkeit kann nur für ein Projektquartal gegolten haben. Ein Zeitmodell hält alten und aktuellen Kontext auseinander.
Heuristik
Arbeitsprinzip
Identitäts- und Zeitentscheidungen folgen klaren Regeln:
Merge-Bedingungen: Kontext, Zeitraum, Domäne und Eigenschaften passen zum selben Objekt. Beispiel: "CRM" und "Customer Relationship Management" zeigen auf dieselbe System-ID im Systemkatalog.
Flag-Bedingungen: Der Name klingt ähnlich, Kontext fehlt oder widerspricht. "Kunden-System" bleibt dann sichtbar unklar, bis eine ID, Aliasliste oder fachliche Bestätigung vorliegt.
Temporale Gültigkeit: Jede Aussage über Rollen, Status oder Werte braucht ein Gültigkeitsintervall oder mindestens ein Stand-Datum. So kann eine Antwort gezielt "aktuell", "damals" oder "im Zeitraum X" beantworten.
Führe Entitäten zusammen, wenn die Belege reichen. Halte unklare Fälle sichtbar und ergänze Zeiträume, wenn Rollen, Verantwortlichkeiten oder Regeln sich ändern können.
Für den Lernpfad reicht eine einfache Regel: Match, getrennt oder unklar. "Unklar" ist ein Qualitätszustand, der fehlende Belege sichtbar macht.
Greifbar machen
Praxisartefakt
Praxis-Hinweis: In der Umsetzung heißt dieser Schritt oft Entity Resolution oder Record Linkage. Systeme nutzen IDs, Aliaslisten, Ähnlichkeitssuche, Regeln und Review-Queues. Praktisch wichtig ist die Entscheidungsmatrix: Wann wird automatisch zusammengeführt, wann bleibt ein Fall sichtbar unklar und welche Zeitangabe macht eine Aussage aktuell oder historisch?
entity-resolution.jsonjson
{
"resolution_cases": [
{
"mention": "CRM",
"candidate_entity_id": "system-crm",
"decision": "match",
"reason": "gleicher Besitzer, gleiche Beschreibung, gleiche Projektzuordnung",
"risk": "niedrig"
},
{
"mention": "Kunden-System",
"candidate_entity_id": "system-crm",
"decision": "unclear",
"reason": "ähnliche Bedeutung, eindeutige ID fehlt",
"risk": "mittel",
"needed_proof": ["System-ID", "offizielle Aliasliste"]
}
],
"time_rule": "Verantwortlichkeiten brauchen valid_from und valid_to oder mindestens ein Stand-Datum."
}Schlüssel kurz erklärt
resolution_casessammelt einzelne Identitätsentscheidungen.mentionist der gefundene Name im Text.candidate_entity_idist die mögliche Zielentität.decisionhält fest, ob zusammengeführt wird, getrennt bleibt oder unklar ist.reasonbegründet die Entscheidung.riskzeigt die Fehlerschwere.needed_proofbenennt fehlende Belege.time_rulelegt fest, wie Zeitangaben behandelt werden.
Achten auf
Typischer Qualitätsfehler
Worauf du achten musst
Ähnliche Namen werden automatisch zusammengeführt oder getrennt, während die fachlichen Belege offen bleiben. Dadurch entstehen falsche Pfade oder doppelte Objekte.
Ein zweiter Fehler ist zeitlose Modellierung. Eine Kante wie owned_by sieht stabil aus, obwohl Verantwortung wechseln kann. Besser ist eine Beziehung mit valid_from, valid_to oder zumindest einem Stand-Datum.
Prüfen
Woran du es erkennst
Signal
Antworten vermischen historische, alte oder doppelte Entitäten. Ein System erscheint mehrfach oder eine frühere Verantwortlichkeit wird als aktuell ausgegeben.
Ein weiteres Signal: Das System beantwortet "wer ist verantwortlich?" und lässt offen, ob die Antwort für heute, das letzte Quartal oder den Zeitpunkt einer alten Richtlinie gilt.
Üben
Mini-Aufgabe
Entscheide für "Customer DB" und "CRM", ob du sie zusammenführen würdest. Notiere, welche zusätzlichen Belege du brauchst.
Musterlösung
Entscheidung
Bis zur Klärung bleibt offen, ob "Customer DB" und "CRM" dasselbe System meinen.
Benötigte Belege
System-ID, Besitzer, Systemkatalogeintrag, Datenklassifikation, Projektzuordnung oder offizielle Aliasliste.
Möglicher Merge
Wenn der Systemkatalog beide Namen derselben System-ID zuordnet, können sie zusammengeführt werden.
Warum wichtig
Entity Resolution ist eine pflegbare Qualitätsentscheidung. Die Entscheidung muss nachvollziehbar bleiben, damit falsche Merges später gefunden werden können.
Reflektieren
Selbsttest
1.Warum braucht LLM-Extraktion zusätzlich Entity Resolution?
LLM-Extraktion findet Kandidaten. Entity Resolution entscheidet, ob mehrere Kandidaten dasselbe reale Objekt meinen.
2.Welche Fehlertypen entstehen bei instabiler Identität und Zeit?
Zu aggressive Zusammenführung erzeugt falsche Pfade. Zu vorsichtige Trennung erzeugt Dubletten. Ohne Zeitbezug kann alter Kontext als aktuell erscheinen.
3.Wann sollte man zwei Entitäten mergen und wann flaggen?
Mergen ist sinnvoll, wenn ID, Kontext oder fachliche Belege übereinstimmen. Flaggen ist besser, wenn nur der Name ähnlich ist oder wichtige Belege fehlen.
Kernaussage
Graphqualität entsteht nach der Extraktion: stabile Identität und klare Zeiträume machen Pfade fachlich belastbar.