Genie Ontology: Semantik-Layer vor dem Rollout klären
Die Kernaussagen auf einen Blick.
- Die Genie Ontology ist die Wissensbasis, auf der Genie und Genie Agents fachliche Fragen in SQL übersetzen.
- Sie liefert Kennzahlenlogik, Tabellenbeziehungen, Geschäftsregeln, Synonyme und Beispielfragen. Sie ergänzt Unity Catalog Business Semantics und das UC Glossary, ersetzt sie aber nicht.
- Self-Service-BI mit Genie funktioniert nur dann zuverlässig, wenn vor dem Rollout klar ist, wer die Ontology pflegt und freigibt.
- Fachlicher Owner, Plattformteam und BI-Team müssen die Pflege klar untereinander aufteilen. Nur dann werden automatisch vorgeschlagene Definitionen und Snippets zu einer verlässlichen Grundlage.
- Mein Vorschlag: Zuerst Verantwortliche und die wichtigsten strittigen Kennzahlen klären, bevor Genie über ein kleines Pilotteam hinaus freigegeben wird.
Inhaltsverzeichnis
Genie halluziniert, wenn die Kennzahlen wackeln
Nach vier Wochen Genie sieht ein Workspace oft so aus. Vertrieb, Customer Success und Vorstand fragen nach „aktiven Kunden", meinen aber nicht dasselbe. Das Ergebnis sind drei Antworten, drei Zahlen und drei unterschiedliche SQL-Abfragen. Im Workspace liegen mehrere Definitionen nebeneinander: zum Beispiel im dbt-Modell, als Tabellenkommentar und im KPI-Handbuch. Genie nutzt eine davon. Für die Nutzer ist aber nicht nachvollziehbar, warum genau diese Definition gewählt wurde.
Dieses Problem ist sehr realistisch. Viele Plattformteams laufen genau in diese Situation hinein, seit Databricks am 16. Juni 2026 Genie One, Genie Ontology und Genie Agents angekündigt hat. Genie wird für erste Nutzer freigeschaltet und die ersten Antworten sind schneller verfügbar als klassische Ad-hoc-Auswertungen durch das BI-Team. Gerade dadurch werden uneinheitliche Definitionen schneller sichtbar.
Die zentrale Frage lautet dann: Wo werden verbindliche Kennzahlen, Begriffe und Regeln für Genie gepflegt? Wer ist pro Fachbereich für Pflege und Freigabe verantwortlich? Solange das offen ist, ist jede Genie-Antwort potenziell nur eine von mehreren möglichen Definitionen, die im Workspace nebeneinander leben. Deshalb gehört die Ontology vor jeden größeren Genie-Rollout.
Was ist die Genie Ontology?
Die Genie Ontology ist die fachliche Wissensbasis, mit der Genie und Genie Agents arbeiten, wenn eine Frage in eine SQL-Abfrage übersetzt wird. Sie ist im Kontext eines Genie Space verankert und verweist auf Tabellen, Spalten und Views im Unity Catalog. Sie enthält die Informationen, die Genie für fachlich passende Antworten benötigt.
Wenn ein Nutzer eine Frage stellt, nutzt Genie die Ontology, um passende Definitionen, Joins, Filter und Synonyme zu finden und generiert daraus den SQL-Aufruf gegen Unity Catalog. Ohne Ontology muss Genie stärker aus Tabellennamen, Spaltennamen, Kommentaren und Beispielen ableiten, was gemeint ist. Dann steigt das Risiko fachlich plausibler, aber falscher Antworten.
Data & AI Beratung mit ruhrdot
Als offizieller Databricks-Partner begleiten wir dich von der Datenstrategie bis zur produktiven KI-Lösung.
Genie Ontology vs Unity Catalog Business Semantics vs UC Glossary
In Unity Catalog gibt es bereits Schichten für Begriffe, Beschreibungen und Kennzahlen: Business Semantics am Asset und das UC Glossary am Katalog. Genie Ontology wirkt deshalb zunächst wie eine zusätzliche Semantikschicht. Sie erfüllt jedoch eine andere Aufgabe.
Der Ablauf macht den Unterschied konkret. Eine Nutzerfrage startet eine Konversation in Genie oder einem Genie Agent. Dort übersetzt die Genie Ontology die fachliche Bedeutung in eine SQL-Abfrage, die gegen Unity Catalog ausgeführt wird. Die Antwort kommt inklusive des geprüften SQL zurück. Alle drei Schichten dieses Ablaufs (Konversation, Bedeutungs-Übersetzung, SQL-Ausführung) greifen dabei durchgängig auf dieselbe Unity-Catalog-Foundation zurück: Glossary, Business Semantics und die zugrunde liegenden Tabellen und Views.
Eine kurze Aufteilung, an welche Schicht welche Information gehört:
| Information | UC Glossary | UC Business Semantics | Genie Ontology | Tabellen-Kommentar |
|---|---|---|---|---|
| Fachliche Begriffsdefinition („Was bedeutet ‚aktiver Kunde' fachlich?") | führend | kann abgeleitet oder gespiegelt werden | verweist darauf | nein |
| Berechnungslogik der Kennzahl (SQL/Logik) | nein | optional | führend | nein |
| Tabellenbeziehungen für die SQL-Erzeugung | nein | nein | führend | nein |
| Synonyme und Alltagssprache der Fachbereiche | optional | nein | führend | nein |
| geprüfte Fragen für Genie | nein | nein | führend | nein |
| Beschreibung einzelner Spalten („was steht in ?") | nein | führend | nein | optional |
Die Aufteilung ist klar. Unity-Catalog-Schichten bilden die Grundlage im Datenkatalog. Sie beschreiben Begriffe, Spalten, Tabellen und deren Governance. Die Genie Ontology ist die operative Übersetzungsschicht für Genie. Sie hilft Genie dabei, aus einer fachlichen Frage eine passende SQL-Abfrage zu erzeugen. Beide Schichten sollten zusammenspielen. Die fachliche Definition einer Kennzahl gehört verbindlich in Glossary oder Business Semantics. Die konkrete Übersetzung für Genie gehört in die Ontology. Wenn diese Schichten unterschiedliche Wahrheiten enthalten, entsteht ein Governance-Problem.
Ein gepflegter Unity Catalog erleichtert den Aufbau der Ontology deutlich. Ohne gepflegte UC-Schichten wird die Ontology noch wichtiger, aber auch aufwendiger. Wie der Katalog-Layer im Detail organisiert ist, klären wir im Überblick zu Unity Catalog Business Semantics und im UC Glossary. Eine Übersicht über die Genie-Familie und den BI-Hub gibt es im Überblick zu Business Intelligence auf Databricks.
Was gehört in den Semantik-Layer?
Ein Ontology-Eintrag besteht typischerweise aus vier bis fünf Bausteinen:
Definition der Kennzahl
Was bedeutet „aktiver Kunde" konkret: Login in den letzten 30 Tagen, Bestellung im aktuellen Quartal oder aktiver Status?
Tabellenbeziehungen & Joins
Welche Tabellen werden über welche Schlüssel verknüpft, und welche Filter müssen immer angewendet werden?
Fachliche Regeln
Welche Testkonten, internen Nutzer oder gesperrten Mandanten müssen ausgeschlossen werden?
Begriffe & Synonyme
Verschiedene Fachbereichsbegriffe wie „aktiver User", „Bestandskunde mit Aktivität" oder „MAU" müssen auf dieselbe Definition zurückgeführt werden.
Geprüfte Beispielfragen
Geprüfte Fragen mit erwarteter Antwort oder Logik als Grundlage für Tests und Reviews.
Databricks ergänzt diese Schicht durch automatisch extrahierte Wissensbausteine (automatische Snippet-Extraktion). Dafür werden Hinweise aus Tabellen, Abfragen, Dashboards, Pipelines und angebundenen Anwendungen genutzt. Darunter sind Google Drive, Slack, Confluence, SharePoint, Jira und Salesforce. Diese Hinweise werden zu einem Wissensgraphen zusammengeführt und nach Relevanz, Nutzung, Aktualität und Vertrauenswürdigkeit sortiert. Intern berichtet Databricks von 4,5 Millionen solcher Snippets. Das zeigt, warum rein manuelle Pflege in großen Datenlandschaften kaum skalierbar ist.
Wer pflegt die Genie Ontology?
Automatische Extraktion ersetzt kein Pflege- und Verantwortungsmodell. Sie kann den Einstieg erleichtern, muss aber geprüft werden. Eine Ontology ohne klare Verantwortliche, fachliche Prüfung und Konfliktlösung wird schnell zu einem weiteren veralteten Metadatenbestand. Genau dafür braucht es ein Betriebsmodell.
Drei Regeln sollten für die Pflege verbindlich sein:
Ein Owner pro Kennzahl
Ohne dokumentierte Verantwortung existiert die Ownership im Betrieb praktisch nicht: sonst landen mehrere Definitionen derselben Kennzahl als „certified" nebeneinander in der Ontology.
Snippets bleiben Vorschläge
Das PageRank-Ranking von Databricks gewichtet Nutzung und Aktualität. Auch eine häufig verwendete falsche Definition kann prominent vorgeschlagen werden: fachliche Reviews bleiben deshalb Pflicht.
Konflikte extern klären
Wenn Vertrieb und Finance eine Kennzahl unterschiedlich definieren, dokumentiert die Ontology die freigegebene Definition. Den Konflikt löst das Data-Governance-Board.
In der Wirkung verschiebt sich der Aufwand von manueller Pflege zu fachlicher Klärung bei den wichtigsten Kennzahlen, die im Unternehmen häufig genutzt werden. Wie wir Data-Governance-Strukturen für genau diese Konsens-Arbeit aufsetzen, klären wir im Überblick zum Governance Hub im Unity Catalog.
Genie Ontology vs klassischer Semantic Layer: dbt, LookML und Cube im Vergleich
Eine naheliegende Frage lautet bei vorhandenem dbt Semantic Layer, LookML oder Cube: Brauche ich die Genie Ontology zusätzlich oder ersetzt sie den bestehenden Semantic Layer? Das hängt vom Zweck des bestehenden Semantic Layers und vom tolerierbaren Pflegeaufwand ab.
Klassische Semantic Layer und Genie Ontology lösen ähnliche Probleme, aber für unterschiedliche Nutzungsszenarien:
| Eigenschaft | Klassischer Semantic Layer (dbt, LookML, Cube) | Genie Ontology |
|---|---|---|
| Wie Definitionen gepflegt werden | deklarativ über Code oder YAML im Repository | hybrid aus automatisch vorgeschlagenen Inhalten und kuratierten Anpassungen im Genie Space |
| Pflege | Pflege über Engineering-Prozess (PR, Review, Merge) | Pflege über Oberfläche, Vorschläge und manuelle Korrekturen |
| Führende Quelle | Repo | Genie Space |
| Nutzer oder System, das die Definition verwendet | BI-Tool (Power BI, Tableau, Looker), Custom Apps | Genie, Genie Agents, Fragen in natürlicher Sprache |
| Stärke | Konsistenz über alle BI-Frontends | Unterstützung für Synonyme, Beispielfragen und natürlichsprachliche Fragen |
| Schwäche | manueller Pflege-Aufwand, keine Konversations-Logik | nur Genie-zentrisch, stärkere Bindung an Databricks |
Drei Konstellationen treten typisch auf:
Möglicher Ersatz
Ein dbt Semantic Layer für Power BI oder Tableau lässt sich langfristig durch die Ontology ersetzen, wenn der Fokus künftig auf Genie und Self-Service liegt. dbt bleibt für Datenmodellierung und Transformationen zuständig.
Gezielter Parallelbetrieb
Ein dbt Semantic Layer für eingebettete Analytics in einem SaaS-Produkt lässt sich durch die Ontology nicht ablösen. Dann läuft die Ontology daneben: pro Kennzahl muss eine führende Definition explizit festgelegt werden.
Ergänzung und Spiegelung
Bei Beibehaltung beider Schichten wird der dbt Semantic Layer als führende Quelle geführt und in die Genie Ontology übernommen (manuell oder über Asset-Bundles). Aufwendiger, aber sauberer als zwei divergente Wahrheiten.
Ohne Ontology skalieren Genie Agents nicht
Bei einfachen Genie-Fragen geht es oft um eine einzelne Frage und eine einzelne Antwort. Ohne Ontology kann die Ungenauigkeit dort noch manuell auffallen, weil Nutzer einzelne Ergebnisse eher prüfen können. Bei Genie Agents ist das Risiko größer. Agents bearbeiten Fragen über mehrere Schritte hinweg: Schritt 1 zieht eine Kohorte, Schritt 2 berechnet darauf eine Metrik, Schritt 3 vergleicht gegen Vorperiode, Schritt 4 generiert eine Empfehlung. Jeder Schritt übernimmt Annahmen aus dem vorherigen Schritt.
Databricks beschreibt Genie Ontology als die Schicht, die Genie One und Genie Agents trägt. Databricks nennt zum Launch Benchmarkwerte für die Qualität der SQL-Erzeugung: 84,5 Prozent First-Attempt-Accuracy gegenüber 52,4 Prozent beim stärksten Coding-Agent-Wettbewerber. Solche Werte sind hilfreich zur Einordnung, ersetzen aber keine Prüfung auf den eigenen Daten. Entscheidend bleibt ein eigener Test mit den eigenen Begriffen, Tabellen und Fragen. Die Richtung ist trotzdem plausibel: Ohne Ontology fehlt Agents eine stabile fachliche Grundlage, in dem Schritt 2 prüfen kann, ob in mehreren Analyseschritten dieselbe Definition verwendet wird.
Praktisch heißt das: Ein Agent, der „Welche wichtigen Kunden verlieren wir gerade?" beantwortet, muss der Begriff „verlieren" in allen Schritten gleich verstanden werden. Heißt das „kein Login in den letzten 14 Tagen", „kein Umsatz im aktuellen Quartal" oder „registrierte Kündigung"? Ohne Ontology kann jeder Schritt eine andere Bedeutung verwenden. Das Ergebnis kann plausibel wirken und trotzdem falsch sein.
Für einen ernsthaften Genie-Agents-Pilot sollte die Ontology für die betroffenen Kennzahlen vorher stehen. Für die Kennzahlen, die der Agent berührt, muss sie sauber stehen. Wie wir Agentic-BI mit Genie Agents sauber aufsetzen, klären wir im Überblick zu Genie Agents.
Steward, Plattform-Team und BI-Review
Drei Rollen tragen den laufenden Betrieb der Ontology und ihrer Pflege.
Fachlicher Kennzahl-Owner
Entscheidet, welche Definition fachlich gilt, welche Filter, Ausschlüsse und Regeln dazugehören und wann sich eine Definition ändert. Verantwortet die fachliche Korrektheit, meist im Fachbereich oder in einer Steward-Rolle.
Plattform-Team
Übersetzt fachliche Definitionen in Joins, Filter, Synonyme und Beispielfragen. Verantwortet technische Konsistenz, Performance und Anbindung an Unity Catalog.
BI-/Analytics-Team
Testet Beispielfragen und Antwortqualität, prüft, ob unterschiedliche Formulierungen zur gleichen fachlichen Antwort führen, und meldet Abweichungen an Kennzahl-Owner und Plattform zurück.
Ohne diese drei Rollen verteilt sich die Verantwortung diffus über mehrere Teams. Sobald eine Kennzahl falsch interpretiert wird, bleibt offen, wer den Eintrag korrigieren muss.
Was der Semantik-Layer nicht löst
Die Ontology verbindet fachliche Definitionen mit der SQL-Erzeugung für Genie. Sie ersetzt aber nicht die darunterliegenden Daten- und Governance-Schichten. Vier Punkte sind in der Diskussion mit Plattform-Teams wichtig:
Keine Datenmodellierung
Eine Ontology kann ein schlecht modelliertes Datenmodell nicht reparieren. Falsche Granularität, inkonsistente Historisierung oder undokumentierte Soft-Deletes macht sie sichtbar, behebt sie aber nicht.
Keine Datenqualität
Auch eine gute Definition liefert falsche Ergebnisse, wenn die zugrunde liegenden Daten fehlerhaft sind: verspätete Dimensionen, doppelte Kunden-IDs oder leere Zeitstempel bleiben Aufgabe der Datenpipelines.
Keine automatische Optimierung
Die Optimierung von SQL Warehouses, Materialized Views und Datenmodell bleibt ein eigenes Thema (siehe Genie ZeroOps): die Ontology übernimmt das nicht automatisch.
Keine Klärung von Verantwortung
Die wichtigste Einschränkung: Eine fachlich gute Ontology ohne klare Pflegeverantwortung veraltet genauso schnell wie die alte KPI-Liste in Excel, die sie ersetzen sollte.
Michael Leone von der Enterprise Strategy Group bringt diese Grenze auf eine Linie: Wer Datenmodell, Qualität und Governance noch nicht im Griff hat, macht mit der Ontology bestehende Unordnung nur schneller sichtbar und wirksamer. Die Ontology ist hilfreich, aber kein Ersatz für Governance.
Die Ontology verbessert die Qualität der Fragen und Antworten. Die Grundlagen darunter bleiben Aufgabe von Plattform, BI und Fachbereichen: UC-Lineage, Owner pro Asset, klare Kennzahl-Definitionen im Glossary. Diese Hausaufgaben gehören vor den Rollout.
Erst Ownership klären, dann Genie freigeben
Genie One, Genie Agents und Genie Code sind seit dem Launch generell verfügbar; Genie App Builder und Genie ZeroOps gehen in Private Preview. Erste Referenzen wie Albertsons, Uplight und Foot Locker laufen produktiv. Die Produktreife einzelner Komponenten ist vorhanden, aber die eigene Plattformreife entscheidet über den Erfolg. Entscheidend ist die Reihenfolge im eigenen Workspace. Sie entscheidet, ob der Pilot Vertrauen schafft oder fachliche Zweifel auslöst. Eine sinnvolle Reihenfolge, die wir in Architecture Reviews empfehlen:
Verantwortliche je Fachbereich klären
Pro Geschäftsbereich (Vertrieb, Finance, Operations) wird festgelegt, wer die zehn wichtigsten Kennzahlen des Fachbereichs verantwortet. Die Antwort sollte dokumentiert werden, zwei bis drei Wochen Aufwand, zunächst ohne neues Tool.
Grundlagen in Unity Catalog aufräumen
Glossary-Einträge für die wichtigsten Kennzahlen, Business-Semantics-Definitionen für die relevanten Tabellen und Kennzahlen, nachvollziehbare Herkunft der Daten. Ohne diese Grundlage wird die Ontology instabil. Vier bis acht Wochen, je nach Stand.
Ontology-Pilot in einem Genie Space
Ein Fachbereich und eine überschaubare Zahl wichtiger Kennzahlen, mit sauber gepflegten Joins, Synonymen und Beispielfragen. Automatische Vorschläge nutzen, aber fachlich prüfen. Zwei bis drei Wochen.
Genie für ein Pilotteam freigeben
Eine begrenzte Nutzergruppe, vier Wochen Beobachtung, regelmäßige Prüfung von Fragen, Antworten und Definitionen mit Kennzahl-Owner und BI. Abweichungen werden hier erstmals sichtbar und messbar.
Genie schrittweise erweitern
Fachbereich für Fachbereich, immer mit demselben Operating-Model: erst Verantwortliche, dann Ontology, dann Freigabe für Nutzer.
Was diese Sequenz vermeidet: einen workspaceweiten Genie-Rollout direkt nach der Lizenzfreigabe, ohne vorher geklärte Kennzahlenverantwortung. Diese Variante endet mit dem Vertriebs-Vorstand am Telefon, der drei Zahlen für „aktiven Kunden" auf seinem Dashboard sieht. Das beschädigt Vertrauen und erzeugt später deutlich mehr Reparaturaufwand.
Fazit
Die Genie Ontology ist die operative Wissensbasis für Genie und Genie Agents.
Sie hilft dabei, aus fachlichen Fragen passende SQL-Abfragen zu erzeugen. Sie ergänzt UC Glossary und Business Semantics, ersetzt sie aber nicht. Sie funktioniert nur so gut wie die Verantwortlichkeiten, Definitionen und Datenmodelle darunter. Automatische Extraktion und Ranking helfen beim Start, ersetzen aber keine fachliche Prüfung.
Drei Entscheidungen stehen vor dem Genie-Rollout an: Wer verantwortet jede zentrale Kennzahl? Welche Information liegt in Glossary, Business Semantics oder Ontology? Wie wird ein vorhandener dbt-, LookML- oder Cube-Semantic-Layer eingebunden oder abgelöst? Mein Vorschlag: Diese drei Fragen sollten im Betriebsmodell geklärt werden, bevor Genie über den ersten Pilot hinaus skaliert. Das ist deutlich günstiger als spätere Korrekturen an Definitionen, Vertrauen und Governance.
Mit sauberer Ontology kann Genie den geplanten Nutzen liefern: konsistente Antworten auf fachliche Datenfragen, ohne dass das BI-Team jede einzelne Frage manuell beantworten muss. Wer die Ontology überspringt, baut im schlimmsten Fall nur eine Chat-Oberfläche vor alte KPI-Konflikte. Dann werden uneinheitliche Zahlen nicht gelöst, sondern schneller verteilt.
FAQ
Die Ontology ist die operative Wissensbasis, mit der Genie SQL aus Fragen erzeugt. Sie hält Kennzahl-Formeln, Joins, Geschäftsregeln, Synonyme und Beispielfragen. Das UC Glossary ist der kontrollierte Begriffsdefinitions-Layer am Katalog: Es hält die fachliche Definition eines Begriffs. Beide arbeiten zusammen. Das Glossary sagt, was „aktiver Kunde" bedeutet; die Ontology liefert die SQL-Logik dafür.
