Egerias Nanny Connectors sollen KI-Kontext aktuell und vertrauenswürdig halten

Kontext ist ein Betriebsproblem

In einem Beitrag im Blog der LF AI & Data Foundation, dem fünften einer Serie über aktuelle Arbeiten an Egeria, argumentiert Chessell, ein Knowledge Graph sei ein sinnvoller Weg, ein Modell zu fundieren, stelle aber eine Momentaufnahme dar und oft nur eine einzige Perspektive. Für ein Team, das mit einem Assistenten experimentiert, könne das genügen. Beim breiten Einsatz von KI müsse der Graph dagegen etwas sein, dem man vertrauen kann.

Sie zählt auf, was das für den Kontext bedeutet. Er muss aktuell bleiben, wenn Daten an neuen Orten landen, Pipelines umgebaut und Systeme abgeschaltet werden. Er muss konsistent sein, damit derselbe Kunde, dasselbe Produkt oder derselbe Lieferant nicht als ein halbes Dutzend verschiedener Dinge erscheint. Er muss Auskunft über die Herkunft geben, mit Audit-Trail an Teams und Anwendungen ausgeliefert werden, über rohe Tabellen- und Spaltennamen hinaus verständlich sein und governt werden.

Nichts davon ist ihrer Ansicht nach ein Modellierungsproblem. Es ist ein Betriebsproblem: Jemand oder etwas muss sich dauerhaft um den Katalog kümmern. In einer kleinen Umgebung übernimmt das ein Data Steward mit einer Tabelle. Im Unternehmensmaßstab, so Chessell, müsse es automatisiert werden.

Was die Nanny Connectors sind

Genau das ist die Aufgabe der Nanny Connectors von Egeria. Der Name geht auf die Idee zurück, dass eine Nanny den Haushalt versorgt, damit die Familie ihr Leben leben kann. Die Connectors beobachten eine Open-Metadata-Umgebung, analysieren sie, räumen sie auf, verbinden sie mit dem übrigen Systembestand und stellen ihre Inhalte den Menschen und Anwendungen bereit, die sie brauchen.

Es handelt sich um Integration Connectors und Governance Services, die im selben Integration Daemon und in denselben Governance Engines laufen wie andere Egeria-Connectors. Sie nutzen dieselben Open-Metadata-APIs und dasselbe Audit-Log.

Chessell begründet die Form einer Connector-Familie damit, dass ein typisches Unternehmen viele Plattformen betreibt: Datenbanken, einen Data Lake, ein Data Warehouse, Kafka-Topics, Kataloge aus unterschiedlichen Epochen, einen Scheduler, eine Notebook-Plattform und SaaS-Anwendungen. Keine einzelne Plattform überblicke das Gesamtbild, schreibt sie, deshalb fungiere Egeria als neutrale, offene Metadatenschicht dazwischen.

Jeder Connector ist nach einer Person benannt, deren Arbeit zur modernen IT beigetragen hat, darunter Charles Babbage, Ada Lovelace, Gregor Mendel, Charles Darwin und Barbara Liskov.

Babbage und Lovelace: Gesammeltes deuten

Die Babbage Analytical Engine ist ein Integration Connector, der eine Reihe von Analyse-Services namens Lovelace Services orchestriert. Jeder davon ist ein Governance Service, der eine klar umrissene Analyse auf dem Knowledge Graph durchführt und das Ergebnis als Klassifizierung an dem analysierten Element ablegt. Zum aktuellen Umfang gehören:

• Award Karma Points: erkennt und belohnt Personen, die zum Katalog beitragen.
• Build Zone Membership Profile: fasst die Zusammensetzung jeder Governance-Zone zusammen.
• Profile Pipeline Runs: analysiert die Läufe jedes Jobs in einem Open-Lineage-Log-Store und hält Häufigkeit, Regelmäßigkeit, Dauer, Fehlerquote und Datenvolumen am Job fest.
• Refine Data Scope: ermittelt anhand der Lese- und Schreibzugriffe auf jeden Datensatz, in welchem Muster er geschrieben wird und welches Datenfenster er abdeckt, auf Basis von Open-Lineage-Events.
• Summarise Data Quality: wandelt Datenqualitätsaussagen und -tests im Open-Lineage-Log-Store in einen Survey Report mit der Erfolgsquote jeder Qualitätsdimension um.

Die rohen Open-Lineage-Events liefern die Pipelines laut Chessell bereits. Es fehle die Interpretation: ob ein Job zuverlässig ist, wie viel Historie ein Datensatz enthält und ob seine Qualität ausreicht. Die Services werden unabhängig voneinander ausgewählt, sodass eine Umgebung nur die Analysen ausführt, die sie haben will.

Mendel und Darwin: Duplikate und Lineage

Der Mendel Automated Duplicate Manager kümmert sich um Beinahe-Duplikate, die entstehen, wenn viele Systeme dasselbe reale Objekt beschreiben. Seine Survivorship-Regeln legen fest, welche Eigenschaften das zusammengeführte Element übernimmt. Wird ein mögliches Duplikat gefunden, bestätigt Mendel es entweder, wenn die Übereinstimmung eng genug ist, oder erzeugt eine To-do-Aufgabe für einen Steward. Er überprüft auch seine eigenen früheren Entscheidungen und zieht eine Zuordnung zurück, die keine mehr ist, überstimmt aber nie Entscheidungen eines menschlichen Stewards.

Sobald sich genügend bestätigte Duplikate gruppieren, werden sie zu einem einzigen konsolidierten Element zusammengeführt. Muss die Zusammenführung zwischen widersprüchlichen Werten wählen, wird der unterlegene Wert ins Audit-Log geschrieben, sodass ein Steward nachvollziehen kann, was zurückgelassen wurde.

Der Darwin Product Dependency Manager verfolgt die Herkunft der Daten jedes digitalen Produkts. Die Lineage wird auf Spaltenebene erfasst, doch Menschen stellen meist gröbere Fragen, etwa welche Systeme einen Server speisen oder von welchen Produkten ein Produkt abhängt. Darwin arbeitet sich über drei Ebenen nach oben: von Schema-Elementen zu Data Assets, von Data Assets zu den Software-Servern, die sie hosten, und von Data Assets zu den digitalen Produkten, die sie bündeln. Die entstehenden Beziehungen DataFlow und DigitalProductDependency pflegt er automatisch. Von Menschen behauptete, aber durch Lineage nicht belegte Abhängigkeiten werden nicht gelöscht, sondern als Ausnahmen zur Prüfung vermerkt.

Was das für KI-Einsätze bedeutet

Der zentrale Punkt des Beitrags: Vertrauenswürdiger KI-Kontext hängt von kontinuierlicher Pflege ab, nicht nur vom Aufbau eines Graphen. Für eine Anwendung, die nach einem Kunden fragt, sei der Unterschied zwischen einer sauber gebildeten Antwort und sechs konkurrierenden der Unterschied zwischen nützlich und irreführend, schreibt Chessell.

Für Organisationen, die viele Agenten und Anwendungen betreiben wollen, werden die Nanny Connectors als offener, herstellerneutraler Weg präsentiert, diese Pflege zu automatisieren, mit denselben APIs und demselben Audit-Log wie der Rest von Egeria. Der vorliegende Quelltext behandelt die Connectors Babbage, Lovelace, Mendel und Darwin; die übrigen in der Serie genannten werden darin nicht im Detail beschrieben.