Kubeflow startet Semantic Operator: KI-Agenten erhalten kontrollierten Zugriff auf Unternehmensdaten
Kubeflow hat mit Semantic Operator ein neues Teilprojekt vorgestellt, das KI-Agenten verlässliche Antworten aus Unternehmensdaten ermöglichen soll. Laut Projekt schreibt das Sprachmodell das SQL nie selbst: Zertifizierte Kennzahlen werden einmal definiert, die Governance greift zuerst, und deterministische Software erzeugt eine einzige Abfrage.
- Semantic Operator ist ein neues Kubeflow-Teilprojekt, das semantische Modelle von Apache Ossie (in Incubation) auf Kubernetes operationalisiert.
- KI-Agenten fragen zertifizierte Kennzahlen über MCP ab, das Sprachmodell schreibt das SQL nie selbst.
- Governance-Regeln greifen vor der Abfrageplanung, nicht autorisierte Anfragen scheitern, bevor SQL existiert.
- Deterministisches SQL läuft auf StarRocks oder Trino und trägt die Modellversion sowie einen Request-Hash.
- Der Befehl ossiectl erstellt aus vorhandenen Metadaten wie Apache Polaris und DataHub den Entwurf einer SemanticModel-YAML-Datei.
Das Problem: Agenten raten die geschäftliche Bedeutung
Der Kubeflow-Blog beschreibt ein verbreitetes Muster bei KI-Agenten für Analysen. Ein Sprachmodell verbindet sich mit einer Datenbank, entdeckt Tabellen und schreibt SQL auf Basis der Formulierung einer Frage. Es sieht Schemata und Spaltennamen, aber oft nicht die geschäftliche Bedeutung dahinter.
Der Beitrag nennt Beispiele. Eine Tabelle namens subscriptions verrät nicht, welche Status als aktiv gelten. Eine Spalte namens revenue sagt nicht, ob sie Brutto-, realisierten oder wiederkehrenden Umsatz enthält. Eine andere Formulierung kann zu einer anderen Tabelle, einem anderen Join, Filter oder einer anderen Aggregation führen, und beide Abfragen laufen womöglich erfolgreich, während nur eine der geschäftlichen Definition entspricht.
Kubeflow versteht das als Problem des Geschäftskontexts und nicht nur der Abfragegenerierung. Eine selbstbewusst präsentierte, aber falsche Zahl könne Entscheidungen zu Preisen, Investitionen, Personal und Kunden beeinflussen.
So funktioniert Semantic Operator
Semantic Operator ist ein Kubernetes-Operator und semantischer Server, der Apache-Ossie-Modelle (in Incubation) operationalisiert. Apache Ossie definiert ein herstellerneutrales Format für semantische Modelle, das Datensätze, Felder, Beziehungen, Kennzahlen und KI-Kontext abdeckt. Der Operator nimmt eine auf Apache Ossie basierende Kubernetes-Ressource vom Typ SemanticModel entgegen, validiert sie und prüft ihre Bindungen an das physische Schema. Ein gültiges Modell wird zu einem versionierten Artefakt kompiliert.
Die Serving-Schicht stellt zertifizierte Konzepte über MCP (Model Context Protocol), REST und gesteuerte SQL-Views bereit. Der Ablauf umfasst drei Schritte:
- Kennzahlen definieren. Datenteams beschreiben zertifizierte Kennzahlen einmalig in einem Apache-Ossie-Modell, das vor der Veröffentlichung gegen das aktive Datenbankschema geprüft wird.
- Kennzahlen anfragen. Agenten entdecken und fragen Kennzahlen über MCP ab und sehen nur die Kennzahlen und Dimensionen, die sie nutzen dürfen.
- Deterministisches SQL erhalten. Semantic Operator wendet die Governance an, erzeugt genau eine SQL-Anweisung, führt sie auf StarRocks oder Trino aus und liefert die Ergebnisse zurück.
Besteht eine Modellaktualisierung die Validierung oder die Schemaprüfung nicht, wird sie nicht veröffentlicht, und die letzte gültige Version bleibt verfügbar. Laut Kubeflow verhindert das, dass eine fehlerhafte Änderung unbemerkt bei allen Agenten und Anwendungen ankommt.
Dieselbe strukturierte Anfrage, dieselbe effektive Identität, dieselbe Modellversion und derselbe Dialekt der Abfrage-Engine erzeugen dasselbe SQL. Das Projekt sagt, dies erleichtere das Prüfen, Testen und Auditieren der Abfragen. Erzeugte Anweisungen tragen außerdem die Modellversion und einen Request-Hash zur Nachvollziehbarkeit.
Governance und das Hilfswerkzeug ossiectl
Die Governance läuft vor der Abfrageplanung. Richtlinien legen fest, welche Kennzahlen und Spalten eine Rolle nutzen darf, und können begrenzte Zeilenfilter anwenden. Eine nicht autorisierte Anfrage scheitert, bevor überhaupt SQL existiert. Modelle können zudem einen externen Policy-Anbieter wie Open Policy Agent oder Apache Ranger benennen. Dieser trifft vor der SQL-Erzeugung eine zweite Entscheidung und kann die eingebaute Governance des Modells nicht abschwächen.
Um das Schreiben eines ersten Modells für eine Plattform mit vielen Tabellen zu erleichtern, enthält das Projekt den Befehl ossiectl. Er kann das Information Schema einer Abfrage-Engine auslesen, auch für Tabellen, die über einen offenen Katalog wie Apache Polaris bereitgestellt werden, und das Ergebnis mit geschäftlichem Kontext aus DataHub anreichern. Daraus entsteht der Entwurf einer SemanticModel-YAML-Datei mit Datensätzen und Feldern. Ingenieure prüfen ihn anschließend, ergänzen zertifizierte Kennzahlen und Beziehungen und wenden ihn auf Kubernetes an. Kubeflow betont, dass dies ein Schritt beim Erstellen ist und nicht zum Abfragepfad gehört und dass die YAML-Datei normale, versionierte Konfiguration bleibt.
Was das für Datenteams bedeutet
Kubeflow argumentiert, dass viele Organisationen semantische Formate aufgebaut haben, die an eine Abfrage-Engine, einen Katalog oder ein Business-Intelligence-Werkzeug gebunden sind. Dadurch lassen sich Kennzahlen kaum über mehrere Datenbanken oder Lakehouse-Engines hinweg wiederverwenden. Semantic Operator soll den geschäftlichen Vertrag portabel halten, während die Abfrage selbst auf die gewählte Engine zugeschnitten ist.
Laut Projekt können Notebook, Dashboard, Pipeline, Anwendung und Agent denselben geschäftlichen Vertrag nutzen. Semantic Operator ist jetzt ein Kubeflow-Teilprojekt. Der Quellcode liegt im Kubeflow-Repository Semantic Operator, und die Dokumentation behandelt Architektur, Installation, das Erstellen von Modellen und lauffähige Beispiele.
