Knowledge Graph im Unternehmen: Ihr Data Warehouse versteht nichts

Stand: Juli 2026.

1. Die Bestellfrage: ein Beispiel aus dem E-Commerce

Beginnen wir im Tagesgeschäft eines Online-Händlers. Eine Bestellung ist eingegangen, fünf Positionen, der Kunde erwartet einen Liefertermin. In der Versandabteilung fällt jetzt die Frage, die dort hundertfach am Tag beantwortet wird:

«Wie versenden wir diese Bestellung? Wie viele Pakete werden es, aus welchem Logistikstandort, mit welchem Logistiker?»

Ein erfahrener Disponent beantwortet sie in Sekunden. Er weiss, dass Position drei nur am Standort Ost an Lager liegt und der Rest aus dem Zentrallager kommt. Er weiss, dass daraus zwei Pakete werden und dass für das schwere nur ein Logistiker in Frage kommt. Er hat die Antwort nicht berechnet. Er hat sie hergeleitet, entlang von Beziehungen, die er im Kopf trägt: Artikel zu Bestand, Bestand zu Standort, Standort zu Logistiker, Logistiker zu Tarif und Laufzeit.

Ihre Datenbasis hat dieselben Zutaten, ob sie nun als Data Warehouse, SAP BW oder Lakehouse betrieben wird. Bestellungen, Positionen, Artikel, Bestände, Standorte, Tarife, Logistiker: alles sauber gespeichert, historisiert, abfragbar. Und trotzdem liefert sie die Antwort nicht in Sekunden, sondern in einem Projekt. Die Antwort liegt nicht in einer Tabelle. Sie liegt zwischen den Tabellen.

Genau diese Lücke schliesst ein Knowledge Graph im Unternehmen, und dort beginnt dieser Beitrag. Wer eine Enterprise-AI plant, die Beziehungsfragen beantworten soll, entscheidet über eine Datenstruktur, nicht nur über ein Modell. Die Bestellfrage begleitet uns durch den ganzen Text. Jede Architektur, die hier vorkommt, muss sich an ihr messen lassen.

2. Was ein Knowledge Graph ist, und was er nicht ist

Sie kennen das Bild aus jedem Krimi: die Pinnwand im Ermittlerbüro. In der Mitte das Foto des Opfers, darum herum Verdächtige, Orte, Zeitpunkte, und dazwischen die roten Fäden: kannte, wurde gesehen mit, hat ein Alibi von. Kein Ermittler löst den Fall mit einer Liste aller beteiligten Personen. Er löst ihn über die Fäden. Genau dieses Prinzip, übertragen auf Geschäftsdaten, hat einen Namen: Ein Knowledge Graph ist die strukturierte Repräsentation eines Geschäftsbereichs als Netzwerk aus Knoten, Kanten und Eigenschaften.

Die drei Bausteine entsprechen der Pinnwand. Knoten sind die Fotos und Karten, im Geschäft also eine Bestellung, ein Artikel, ein Logistikstandort, ein Logistiker. Kanten sind die Fäden, gerichtet und typisiert. Eine Kante sagt nicht bloss, dass Artikel und Standort etwas miteinander zu tun haben. Sie sagt «ist an Lager in», mit Richtung und Bedeutung. Eigenschaften sind die Notizzettel an Karte und Faden: der Bestand an der Lagerkante, das Maximalgewicht am Logistiker.

Beziehungen sind im Graphen vollwertige Datenobjekte mit Richtung, Typ und eigenen Eigenschaften. Die Fachsprache nennt sie First Class Citizens, gleichrangig mit den Daten selbst. In der relationalen Welt sind Beziehungen Nebenprodukte aus Fremdschlüsseln, die erst eine Abfrage zum Leben erweckt. Im Graphen steckt die Bedeutung in der Struktur des Netzes. Dass dieses Prinzip im grossen Massstab trägt, zeigt Google: Der Konzern bezifferte seinen Knowledge Graph bereits im Mai 2020 auf über 500 Milliarden Fakten zu rund 5 Milliarden Entitäten. Die Info-Panels neben den Suchresultaten sind Traversierungen dieses Netzes, also verfolgte Kanten, keine Volltexttreffer.

Der Trade-off: Der erste Entwurf eines Graphen ist heute automatisierbar, die Verantwortung dafür nicht. Werkzeuge wie die Genie Ontology lernen Geschäftskontext aus Metadaten und Nutzung, und Sprachmodelle extrahieren Entitäten und Beziehungen aus Dokumenten. Was dabei entsteht, ist ein Vorschlag: beobachtete Zusammenhänge. Ob eine Kante als Geschäftsregel gilt, welcher Tarif verbindlich ist, wer eine Änderung freigibt, das bleibt eine Entscheidung im Haus. Zwei Gründe sprechen gegen den blind übernommenen Automatik-Graphen: Wer unter Nachvollziehbarkeitspflichten arbeitet, muss die Herleitung einer Antwort verteidigen können, und ein Graph, den niemand im Haus versteht, kann das nicht leisten (Kapitel 6). Und der eigentliche Wert des Graphen liegt darin, dass er Ihr Wissen abbildet, nicht bloss Ihre Datenmuster.

3. Warum Tabellen an Beziehungsfragen scheitern

Zurück zur Bestellfrage. Als Modellrechnung: In einem typischen E-Commerce-Datenmodell berührt die Bestellfrage neun bis elf Tabellen und verkettet acht bis zwölf Joins. Bestellung, Bestellposition, Artikel, Bestand, Logistikstandort, Zonenzuordnung, Tarif, Logistiker, Serviceart, dazu je nach Modell Sendung und Paket. Die eigentliche Logik liegt danach immer noch nicht in der Abfrage. Bestandssplit, Paketbildung nach Gewicht und Volumen, Logistikerwahl nach Zone und Laufzeit wandern in Applikationscode oder in eine Prozedur ausserhalb der Plattform. Jede zusätzliche Ecke der Frage multipliziert die Zwischenergebnisse. Dokumentendatenbanken verschieben das Problem nur: Dort sind Beziehungen Verweise zweiter Klasse, und die Applikation klebt die Teile per Lookup zusammen.

Eine native Graph-Engine speichert Beziehungen physisch bei den Daten: Das Verfolgen einer Kante kostet einen Schritt, keinen Tabellenscan. Die Fachliteratur nennt dieses Prinzip Index Free Adjacency. Die Antwort auf die Bestellfrage ist dann ein Pfad über vier Beziehungstypen statt ein Join-Gebirge. Der Pfad: Bestellung enthält Position, Position ist an Lager in Standort, Standort wird bedient von Logistiker, Logistiker bietet Serviceart mit Tarif. Die Kosten der Traversierung wachsen mit der Länge des Pfads, nicht mit der Grösse des Gesamtbestands.

Für alle, die nachrechnen wollen: die Rechnung hinter dem Unterschied. Nehmen Sie als Modellrechnung einen Shop mit 50'000 Bestellungen pro Jahr, im Schnitt drei Positionen je Bestellung, jeder Artikel an zwei bis vier Standorten bevorratet. Die SQL-Variante der Bestellfrage joint zuerst Positionen gegen Bestände und erzeugt damit sechs bis zwölf Zwischenzeilen je Bestellung. Danach kommen Zonen, Servicearten und Tarife dazu, je Logistiker mehrere Einträge. Vor der eigentlichen Auswahllogik stehen so schnell 50 bis 150 Zwischenzeilen für eine einzige Bestellung, und der Optimizer muss jede Stufe über den Gesamtbestand planen. Die Traversierung startet dagegen beim Knoten der einen Bestellung und berührt nur deren eigene Kanten, in dieser Grössenordnung 15 bis 40. Alles daran ist Bandbreite und Modell, kein Messwert. Aber die Richtung des Unterschieds ist strukturell, und sie wächst mit jeder weiteren Ecke der Frage.

Der Trade-off: Für Aggregationen über Millionen Zeilen bleibt das Lakehouse mit SQL das richtige Werkzeug, mit grossem Abstand. Das Lakehouse, Databricks' Zusammenführung von Data Warehouse und Data Lake auf einer Plattform, spielt dort seine Stärke aus: Umsatz je Monat, Bestandsreichweite je Sortiment, Kohortenanalysen, alles Tabellenarbeit. Der Graph gewinnt bei Fragen über mehrere Ecken mit wenigen Startpunkten. Wer eines der beiden Werkzeuge zum Universalwerkzeug erklärt, wiederholt die Tool-Religion mit neuem Vorzeichen.

4. Der Kontextlayer: wo der Knowledge Graph im Unternehmen sitzt

«AI hat ein Kontextproblem, kein Intelligenzproblem.» Der Satz stammt vom Databricks-CEO aus der Keynote der DAIS 2026, dem Data + AI Summit. Dieselbe Konferenz sprach von über 100'000 gebauten Agenten und davon, dass der eigentliche Agent-Loop rund 1 Prozent des Aufwands ausmacht, gegen 99 Prozent Kontext- und Infrastrukturarbeit. Die Diagnose deckt sich mit dem Modell, das ich als Kontextlayer eingeführt habe. Der Kontextlayer hat vier Schichten: Das Glossar definiert die Begriffe, der Semantic Layer die Kennzahlen, die Ontologie die Beziehungen, der Agentenkontext die Rechte und Sichten des Agenten. Der Knowledge Graph ist die dritte Schicht in ausführbarer Form.

Databricks baut diese Schichten sichtbar in die Plattform. Zur DAIS 2026 kündigte Unity Catalog ein Glossary für verbindliche Geschäftsbegriffe an (Preview angekündigt, Stand Juni 2026). Metrics definieren Kennzahlen einmal zentral als wiederverwendbare Objekte (in Teilen Public Preview). Domains schneiden Datenbereiche fachlich zu, damit Agenten begrenzten, relevanten Kontext sehen statt den ganzen Katalog (Public Preview). Die Genie Ontology lernt Geschäftskontext fortlaufend aus diesem semantischen Fundament. Schicht eins, zwei und vier nehmen damit direkt im Katalog Form an.

Tabelle 1: Die vier Schichten des Kontextlayers und ihre Databricks-Entsprechung. Sichtbar wird: Drei Schichten liefert die Plattform, die dritte bleibt Modellierungsarbeit im Haus.

Die dritte Schicht ist die anspruchsvollste: Werkzeuge können die fachliche Topologie vorschlagen, verantworten muss sie Ihr Fachbereich. Lineage und Tabellenstatistiken beschreiben, wie Daten technisch zusammenhängen. Die Bestellfrage verlangt jedoch Geschäftswissen: welcher Standort welchen Logistiker bedient, welcher Tarif ab welchem Gewicht gilt. Wer den Kontextlayer plant, dimensioniert die dritte Schicht deshalb an Fragen wie der Bestellfrage und nicht am Featurekatalog. Wie die vier Schichten im eigenen Haus entstehen, von der Begriffsinventur bis zum Agentenkontext, beschreibt mein Whitepaper zum Kontextlayer Schritt für Schritt. Den Einstieg in dasselbe Modell finden Sie auch im Beitrag Daten AI-ready machen.

5. Wie der Graph ins Lakehouse kommt: Connector, Unity Catalog, GraphRAG

Ein Graph neben dem Lakehouse klingt nach einer zweiten Insel, und genau die Silos wollten wir beenden. Die Sorge ist berechtigt, die Antwort beruhigend. Die Verbindung von Graph und Lakehouse ist seit 2024 Standard. Seit Juni 2024 gibt es einen offiziellen, von beiden Herstellern geprüften Connector zwischen Databricks und Neo4j. Er bewegt Daten in beide Richtungen: aus Delta-Tabellen in den Graphen und zurück. Der Graph wird damit aus denselben geprüften Quellen gespeist wie jeder Bericht im Haus. Wer worauf zugreift und woher eine Zahl stammt, bleibt in Unity Catalog sichtbar.

Bleibt die Frage, wie die AI den Graphen nutzt. Databricks hat dafür im Mai 2025 ein durchgerechnetes Beispiel veröffentlicht, einen sogenannten GraphRAG-Agenten. Hinter dem Fachwort steckt ein Ablauf in drei Schritten. Erstens: Ein Sprachmodell übersetzt die Frage, etwa unsere Bestellfrage nach Paketen, Standort und Logistiker, in eine Abfrage an den Graphen. Zweitens: Der Graph beantwortet die Abfrage, indem er den modellierten Beziehungen folgt, von der Bestellung über die Bestände zu Standorten und Tarifen. Drittens: Das Sprachmodell formuliert aus dem Ergebnis eine Antwort in ganzen Sätzen, samt dem Weg dorthin. Das ist keine Ähnlichkeitssuche mit gutem Marketing. Es ist eine Herleitung entlang der Geschäftsbeziehungen. Bemerkenswert am Beispiel: Als Quelle dienten ausgerechnet SAP-ERP-Daten, also die Sorte Beziehungsgeflecht, aus der auch unsere Bestellfrage stammt.

Zum Vertiefen: die Ankündigung des Neo4j-Databricks-Connectors (Juni 2024), die GraphRAG-Referenzimplementierung auf dem Mosaic AI Agent Framework (Mai 2025) und die Unity-Catalog-Neuerungen der DAIS 2026. Dort stehen die technischen Details: eingesetztes Sprachmodell, Erzeugung der Cypher-Abfragen, Bereitstellung über Model Serving.

Für alle, die es betreiben werden: was der Alltag zusätzlich verlangt. Drei Dinge stehen in keiner Ankündigung und entscheiden trotzdem über den Erfolg. Erstens die Ladefrequenz: Der Graph wird aus Delta-Tabellen gespeist, je nach Anwendungsfall als nächtlicher Batch oder als Stream; wer Bestände traversiert, braucht den Stream, sonst begründet der Agent mit dem Lagerstand von gestern. Zweitens die Rechtespiegelung: Zugriffsregeln aus Unity Catalog gelten nicht automatisch im Graphen, sie müssen je Knotentyp und Beziehungstyp nachgezogen werden. Drittens die Bewertung: Die Databricks-Referenz evaluiert ihre Agentenantworten über menschliches Feedback und modellgestützte Metriken. Diese Schleife ist kein Zusatz für später, sie ist der einzige Weg zu wissen, ob die erzeugten Abfragen das Modell richtig nutzen.

Der Trade-off: Die Referenzimplementierung ist Demo-Massstab, kein Betriebskonzept. GraphRAG kostet gegenüber Vektor-RAG spürbar mehr Aufbau und laufende Pflege; die zitierte Databricks-Publikation benennt das selbst. Wer Neo4j neben Unity Catalog betreibt, führt zudem zwei Governance-Räume und muss sie aktiv synchron halten. Machbar, aber Betriebsarbeit, keine Fussnote.

6. Der Prüfpfad: Erklärbarkeit als Geschäftsanforderung

In regulierten Häusern scheitern AI-Vorhaben selten an der Antwortqualität. Sie scheitern an einer einzigen Rückfrage: «Woher wissen Sie das?» Ein neuronales Netz liefert Ergebnisse ohne Beweis. Ein Vektor-Retrieval liefert Ähnliches ohne Herleitung. Für beide gilt, was ich an anderer Stelle ausgeführt habe: Ähnlichkeit ist nicht Checking, und Häufigkeit ist nicht Korrektheit.

Der Graph verändert die Beweislage, weil die Antwort ein Pfad ist. «Zwei Pakete, ab Zentrallager und Standort Ost, mit Logistiker A und B» kommt mit Begründung: Position drei liegt nur am Standort Ost an Lager. Das Gewicht der übrigen Positionen überschreitet die Grenze der gewählten Serviceart. Der Tarif für Zone 2 gilt ab Standort Ost. Jede dieser Aussagen ist eine Kante, die ein Fachexperte prüfen, korrigieren oder freigeben kann. Wer unter Nachvollziehbarkeitspflichten arbeitet, etwa nach BCBS 239 mit seinen Anforderungen an Herkunft und Genauigkeit von Risikodaten, erkennt hier den Unterschied zwischen einer Antwort und einem Beleg. Aus der Black Box wird ein Prüfpfad. Damit wird auch die Frage vor der Unterschrift beantwortbar: Führt dieselbe Frage nächste Woche zur selben Zahl, und wer im Raum kann die Herleitung erklären?

Der Trade-off: Ein Prüfpfad ist nur so belastbar wie das Modell dahinter. Eine veraltete Kante, etwa ein Tarif, der seit Januar nicht mehr gilt, erzeugt eine falsche Antwort mit perfekter Begründung. Erklärbarkeit ersetzt die Pflege nicht. Sie macht Pflegefehler immerhin auffindbar.

7. Wann Sie keinen Graphen brauchen

Das stärkste Gegenargument verdient den vollen Auftritt. Für die Mehrheit der heutigen Enterprise-AI-Anwendungsfälle genügt Vektor-RAG. Wer Verträge, Handbücher und Tickets durchsuchbar machen will, braucht Embeddings, also Zahlenvektoren, die Bedeutung abbilden, und eine saubere Zerlegung der Dokumente. Wer Kennzahlen abfragen will, braucht Metric Views mit klaren Definitionen. Beides ist schneller gebaut, günstiger betrieben und in Unity Catalog bereits zu Hause. Wäre das das ganze Bild, wäre dieser Text eine Fingerübung.

Das Kriterium, an dem die Gegenposition scheitert, ist die Bestellfrage selbst. Sobald eine Frage über zwei oder mehr Ecken läuft und ihre Antwort einer Belegpflicht unterliegt, gehört sie auf den Graphen. Belegpflicht heisst: Die Antwort löst operativ etwas aus oder muss einem Prüfer standhalten. Ähnlichkeitssuche liefert in diesem Fall strukturell die falsche Währung. Sie findet, was so klingt wie die Antwort, und niemand kann zeigen, dass es aus den Geschäftsregeln folgt. Zählen Sie in Ihrem eigenen Backlog nach, wie viele solcher Fragen dort stehen. Nach meiner Erfahrung sind es weniger als die Hälfte der Anwendungsfälle, aber fast immer die mit dem höchsten Einsatz.

Tabelle 2: Werkzeugwahl nach Fragetyp. Das Kriterium ist die Frage, keine Technologiepräferenz.

Zwei Grenzen gehören zusätzlich ins Protokoll. Erstens die Standardfrage nach RDF, dem Resource Description Framework des W3C. Der Standard beschreibt Wissen formal sauber; in operativen AI-Pipelines hat sich das Labeled-Property-Graph-Modell durchgesetzt, weil es näher am Anwendungscode und am Echtzeitbetrieb liegt. Wer Wissen standardisiert zwischen Organisationen austauschen muss, prüft RDF trotzdem. Zweitens die Pflegefrage. Ein Graph ohne Ownership verfällt wie jedes Glossar. Ohne benannten Verantwortlichen je Beziehungstyp ist die dritte Schicht in einem Jahr ein Museum.

8. Bilanz und Prüffragen fürs eigene Haus

Die Silos, deren Ende der Untertitel verspricht, verschwinden weder durch mehr Speicher noch durch das nächste Modell. Sie verschwinden dort, wo Beziehungen denselben Rang bekommen wie Werte: modelliert, zentral kontrolliert, abfragbar. Genau das leistet ein Knowledge Graph im Unternehmen. Die Datenbasis bleibt das Fundament. Unity Catalog wird sichtbar zur Heimat der Schichten eins, zwei und vier. Die dritte Schicht, die Ontologie, bleibt eine Entscheidung, die Ihnen keine Plattform abnimmt.

Drei Prüffragen dafür, gestellt an Ihr eigenes Haus: Welche drei Fragen mit Beziehungscharakter kosten Sie heute am meisten Zeit, und über wie viele Ecken laufen sie? Wer könnte morgen die Herleitung einer AI-Antwort auf diese Fragen prüfen, und woran? Und wer pflegt die Beziehungstypen weiter, wenn das Projektteam weg ist?

Wenn Ihr Disponent die Bestellfrage schneller beantwortet als Ihre Plattform, ist das kein Kompliment an den Disponenten.

Wenn Sie prüfen wollen, welche Beziehungsfragen in Ihrem Haus zuerst auf den Graphen gehören: Clarity Audit.

Glossar

BCBS 239: Grundsätze des Basler Ausschusses für Bankenaufsicht zur Aggregation von Risikodaten; verlangen unter anderem belegbare Herkunft und Genauigkeit.

Cypher: Abfragesprache für Property-Graphen, in Neo4j zu Hause. Formuliert Pfade statt Joins.

DAIS: Data + AI Summit, die Jahreskonferenz von Databricks.

Delta-Tabelle: Speicherformat des Lakehouse bei Databricks, transaktionssicher auf Objektspeicher.

Embedding: Zahlenvektor, der die Bedeutung eines Texts abbildet. Grundlage der Ähnlichkeitssuche.

Genie / Genie Ontology: Databricks-Funktion, die natürlichsprachige Fragen gegen Daten beantwortet; die Genie Ontology lernt dafür fortlaufend Geschäftskontext.

GraphRAG: Retrieval Augmented Generation gegen einen Graphen statt gegen einen Suchindex. Die AI holt Fakten über modellierte Beziehungen.

Index Free Adjacency: Speicherprinzip nativer Graph-Engines. Nachbarknoten sind direkt verknüpft, das Verfolgen einer Kante braucht keinen Index-Lookup.

Kontextlayer: In diesem Blog geprägtes Modell der vier Schichten zwischen Rohdaten und verlässlicher AI-Antwort: Glossar, Semantic Layer, Ontologie, Agentenkontext.

Lakehouse: Databricks' Architekturbegriff für die Zusammenführung von Data Warehouse und Data Lake auf einer Plattform. Übernimmt die Rollen, die SAP BW und ein separater Data Lake sonst getrennt spielen.

LPG: Labeled Property Graph, das Graphmodell der operativen Praxis (unter anderem Neo4j).

Metric View: Kennzahlendefinition als zentral gepflegtes, wiederverwendbares Objekt in Unity Catalog.

Mosaic AI Agent Framework: Databricks-Rahmenwerk zum Bauen, Bewerten und Bereitstellen von AI-Agenten.

RDF: Resource Description Framework, der W3C-Standard für formale Wissensrepräsentation.

Traversierung: Das Verfolgen von Kanten durch einen Graphen, Schritt für Schritt.

Unity Catalog: Zentrale Governance-Schicht von Databricks für Daten- und AI-Assets: Zugriff, Herkunft, Semantik.

Vektor-RAG: Retrieval Augmented Generation über Ähnlichkeitssuche in Embeddings.

Revisionsvermerk: Erstfassung Juli 2026. Produktstände und Preview-Angaben gemäss DAIS 2026.