Ontologiegesteuerte Datenagenten in Microsoft Fabric IQ: Ein Praxisleitfaden

TL;DR Enterprise AI durchläuft eine bedeutende Veränderung. Die erste Welle der unternehmensinternen generativen KI konzentrierte sich hauptsächlich auf Datenabruf. Die nächste Welle der unternehmensinternen Agenten wird über den bloßen Datenerhalt hinausgehen – sie werden mithilfe von geregeltem Geschäftsverständnis argumentieren.

Question
   ↓
LLM
   ↓
Vector Search / RAG
   ↓
Documents
   ↓
Answer

Das neue Modell konzentriert sich auf Argumentieren auf der Grundlage von Geschäftsverständnis:

Business Question
                           │
                           ▼
                    Agent / Planner
                           │
                 ┌─────────┴─────────┐
                 ▼                   ▼
          Semantic Model          Ontology
          "How measured?"      "What does it mean?"
                 │                   │
                 └─────────┬─────────┘
                           ▼
                    Enterprise Data
                           │
                           ▼
                   Insight / Decision
                           │
                           ▼
                         Action

Dieser Unterschied ist von großer Bedeutung.

Eine einfache Datenbank kann einem Agenten etwas wie Folgendes mitteilen:

customers.CustomerId = sales.CustomerId

Im Gegensatz dazu kann eine Ontologie dem Agenten mitteilen:

Customer ── PURCHASES ──> Product

Und ein semantisches Modell kann noch einen Schritt weiter gehen und ihm mitteilen:

Total Revenue = governed enterprise measure

Das repräsentiert drei völlig unterschiedliche Ebenen des Verständnisses.

Microsoft verbindet diese Konzepte unter Fabric IQ – dabei liefert das semantische Modell zuverlässige analytische Messwerte, die Ontologie ein gemeinsames Unternehmensvokabular sowie eine Beziehungsstruktur, die Graphschicht ermöglicht das Durchqueren vernetzter Daten, und Data Agents bringen all diese Erkenntnisse durch Gespräche zum Vorschein. Microsoft betrachtet Fabric IQ als die Schicht für den Geschäftskontext, die rohe analytische und operative Daten in Geschäftskonzepte umwandelt, über die ein Agent tatsächlich nachdenken kann.

Der architektonische Aspekt, der das Ganze wirklich interessant macht, ist folgender:

Man kann einen Fabric Data Agent veröffentlichen und ihn über das Model Context Protocol (MCP) zugänglich machen, sodass Microsoft Foundry-Agents – oder jeder andere MCP-kompatible Agent – die kontrollierte Unternehmensintelligenz wie ein weiteres Werkzeug nutzen können.

Microsoft unterstützt nun genau diesen Ablauf: Ein veröffentlichter Fabric Data Agent kann sich einem Foundry-Agent als MCP-Tool präsentieren, und ein einziger Foundry-Agent kann anschließend mehrere Fabric Data Agents zusammen mit anderen Tools und Wissensquellen koordinieren.

1. Warum Ontologien plötzlich wieder wichtig sind

Ontologien sind keine neue Idee.

Auch Wissensgraphen sind nicht neu.

Ebenso wenig semantische Modelle.

Was tatsächlich geändert hat, ist, wer sie nutzt.

Historisch gesehen wurden unternehmensbezogene semantische Technologien hauptsächlich von folgenden Parteien genutzt:

• Suchplattformen
• BI-Tools
• Datenintegrationssysteme
• Taxonomieverwaltung
• graphbasierte Anwendungen
• Fachexperten

Nun gibt es einen neuen Nutzerkreis:

KI-Agenten.

Doch hier stoßen die Agenten auf ein echtes Hindernis.

Große Sprachmodelle können gut mit den ihnen zur Verfügung gestellten Informationen arbeiten, doch Unternehmensdatenbanken beschreiben die Geschäftsprozesse fast nie so, wie Menschen sie im Alltag betrachten.

Zum Beispiel:

CUSTOMER_MASTER.CUST_ID
SALES_TXN.CUST_ID
SALES_TXN.PROD_NM
SALES_TXN.NET_REV

Menschen hingegen denken in Begriffen wie:

Customer
   │
   │ PURCHASES
   ▼
Product
   │
   └── generates → Revenue

Die Differenz zwischen diesen beiden Darstellungsweisen ist die Ursache für einen großen Teil der Unsicherheit bei den Agenten.

Weil es an semantischer Grundlage fehlt, muss der Agent raten:

• welche Tabellen zu welchen Geschäftskonzepten gehören
• welche Verknüpfungen tatsächlich gültig sind
• was eine bestimmte Spalte wirklich darstellt
• welche Metrikdefinition als autoritativ angesehen werden sollte
• wie sich Entitäten zueinander verhalten
• ob zwei unterschiedlich benannte Felder tatsächlich dasselbe bedeuten

In einer Demo mit fünf Tabellen ist das ein erträgliches Problem.

In Hunderten von Unternehmensdatenprodukten wird das tatsächlich riskant.

Fabrics Ontologie-Funktion ist speziell dafür konzipiert, ein maschinenlesbares, gemeinsames Geschäftslexikon zu bilden, das aus Entity-Typen, Eigenschaften, Beziehungen, Einschränkungen sowie Verbindungen zu den tatsächlichen OneLake-Daten besteht. Dieses Lexikon kann gleichermaßen von menschlichen Benutzern und Agenten genutzt werden.

2. Doch „Knowledge Graph“ bedeutet nicht eine einzige Architektur

Ein visueller Entscheidungsfluss, der dieser Diskussion beiliegt, hilft dabei zu verdeutlichen, warum die Wahl eines Graphen- und Ontologie-Ansatzes keine universelle Lösung ist.

[Einfügen: Entscheidungsfluss für Graph- und Ontologie-Lösungen]

Es gibt keine einzige richtige Art, einen Graphen zu architektonieren.

Das Spektrum lässt sich grob in fünf Muster einteilen.

Muster 1 – RDF / Semantischer Knowledge Graph

Das ist der traditionelle Ansatz des semantischen Web:

Subject ─ Predicate ─> Object

Er wird in der Regel mit folgendem kombiniert:

RDF
RDFS
OWL
SPARQL

Vorteile: reichhaltige, ausdrucksstarke Semantik, standardsbasierte Interoperabilität, ausgereifte Methoden zum Ontologiemodellieren sowie Unterstützung für formales Reasoning.

Kompromisse: höhere Modellierkomplexität, Bedarf an spezialisierten Fähigkeiten sowie Infrastruktur, die oft über das hinausgeht, was die eigentliche Anwendung benötigt.

3. Beschriftete Eigenschaftsgraphen

Das Modell der beschrifteten Eigenschaftsgraphen (LPG) verfolgt einen anwendungsorientierteren Ansatz:

(Customer)
    │
    │ PURCHASED
    │ {date, quantity}
    ▼
(Product)

Sowohl Knoten als auch Kanten können eigene Eigenschaften enthalten.

Tools wie Neo4j haben dieses Modell populär gemacht, da es sich gut für Anwendungen eignet, die viel mit Durchqueren von Graphen arbeiten.

Vorteile: intuitives Graphenmodellieren, hohe Leistung bei der Durchquerung von Graphen, ausgereifte Graphenalgorithmen sowie umfangreiche Erfahrung in der Anwendungsentwicklung.

Kompromisse: Das Graphenschema allein ergibt noch kein reguliertes unternehmensweites semantisches Vokabular – diese Bedeutungsebene muss weiterhin separat modelliert und geregelt werden.

Microsoft Fabric Graph folgt diesem LPG-Ansatz, wobei OneLake-Tabellen in Knoten- und Kantenarten umgewandelt werden und die Durchquerung über GQL ermöglicht wird. Microsofts Implementierung von GQL folgt der ISO-standardisierten Graph Query Language.

4. Ein leichterer Weg: Ontologie plus In-Memory-Graph

Nicht jeder Agent benötigt eine vollständige unternehmensweite Graphen-Datenbank.

Für chatbasierte Anwendungen, Randfälle, auf eng definierte Aufgaben beschränkte Assistenten oder Proof-of-Concept-Projekte kann eine einfache Ontologie in Form von reinem JSON dargestellt werden:

{
  "entities": {
    "Customer": {},
    "Product": {}
  },
  "relationships": {
    "Purchases": {
      "from": "Customer",
      "to": "Product"
    }
  }
}

Ihre Anwendungs Schicht kann diese Definition anschließend in NetworkX, Memgraph, eine RDF-Bibliothek oder jede andere In-Memory-Graphstruktur laden.

Dieser Ansatz ist schnell einzurichten und kostengünstig in der Nutzung.

Der Nachteil ist, dass Sie selbst für Governance, Sicherheit, Rückverfolgbarkeit der Datenquellen, Skalierbarkeit, Synchronisierung der Daten sowie die gemeinsame Verwaltung der semantischen Definitionen sorgen müssen.

5. Warum Microsoft Fabric hier hervorsticht

Fabric geht dem Problem von einer anderen Perspektive aus.

Anstatt davon auszugehen, dass alle Unternehmensdaten in eine Graph-Datenbank migriert werden müssen, kann die Architektur stattdessen davon ausgehen, dass die Unternehmensdaten dort bleiben, wo sie sind – in OneLake – und dass semantische sowie relationale Informationen darauf aufgebaut werden.

In Diagrammform:

Fabric IQ
                            │
          ┌─────────────────┼──────────────────┐
          │                 │                  │
          ▼                 ▼                  ▼
   Semantic Model        Ontology            Graph
          │                 │                  │
   trusted metrics     business meaning    traversal
          │                 │                  │
          └─────────────────┼──────────────────┘
                            │
                         OneLake

Microsoft zieht eine klare Trennung zwischen diesen Verantwortungsbereichen: Semantische Modelle liefern zuverlässige KPIs und analytische Strukturen, die Ontologie stellt ein gemeinsames Geschäfts-Vokabular bereit, der Graph kümmert sich um die Durchquerung voneinander verbundener Daten, und Datens- oder Ablaufagenten sorgen für intelligente Interaktionen und Aktionen, die auf diesem Kontext basieren.

Diese Trennung der Aufgaben ist aus architektonischer Sicht wichtig.

6. Semantisches Modell, Ontologie und Graph sind drei verschiedene Dinge

Oft werden diese Begriffe so verwendet, als wären sie Synonyme. Das sind sie jedoch nicht.

Eine nützliche Sichtweise dazu:

DATA
"What happened?"
       │
       ▼
SEMANTIC MODEL
"How should it be measured?"
       │
       ▼
ONTOLOGY
"What does it mean?"
       │
       ▼
GRAPH
"How is everything connected?"
       │
       ▼
AGENT
"What should I investigate or do?"

Ein semantisches Modell in Power BI kann Maße wie folgt definieren:

Total Revenue
Average Order Value
Customer Count
Revenue by Segment

Eine Ontologie kann Entitäten und Beziehungen wie folgt definieren:

Customer

Product

Customer ── PURCHASES ──> Product

Der Graph ist es, der tatsächlich diese Verbindungen instanziert und durchquert:

Customer A
   │
   ├── PURCHASES → Laptop
   │
   ├── PURCHASES → Monitor
   │
   └── PURCHASES → Dock

Der Datenagent stellt anschließend all diese Informationen über eine Interaktion in natürlicher Sprache zur Verfügung.

Fabric ermöglicht es außerdem, direkt aus einem vorhandenen semantischen Modell eine Ontologie abzuleiten: Tabellen werden zu Entitätsarten, Spalten zu Eigenschaften, und die bereits im semantischen Modell definierten Beziehungen werden zu Ontologie-Beziehungen.

7. Aufbau: Ein minimales Verkaufsdatenprodukt

Um den Fokus auf die Architektur statt auf die Datenverarbeitung zu legen, bleibt das Beispiel absichtlich einfach.

Es werden nur zwei Quelltabellen verwendet:

NP_SalesDataProduct_LH

customers
──────────────
CustomerId
CustomerName
Segment
City
State
Country
sales
──────────────
OrderId
OrderDate
CustomerId
ProductName
ProductCategory
Quantity
UnitPrice
DiscountPct
Revenue
SalesChannel

Die Beziehung zwischen ihnen ist eindeutig:

customers.CustomerId
         1
         │
         *
sales.CustomerId

Das reicht aus, um die gesamte Architektur zu durchgehen, ohne dass die Modellierungskomplexität der zugrundeliegenden Lektion im Weg steht.

8. Schritt 1 – Das Fabric-Datenprodukt erstellen

Die beiden CSV-Dateien werden in ein Fabric Lakehouse geladen:

NP_SalesDataProduct_LH
│
├── Tables
│   └── dbo
│       ├── customers
│       └── sales
│
└── Files
    ├── customers.csv
    └── sales.csv

[Einfügen von Screenshot: Lakehouse mit Kunden und Verkäufen]

In dieser Phase verfügen Sie bereits über einen funktionsfähigen Fabric Data Agent.

Der Agent kann Fragen beantworten wie z. B., welches die Gesamteinnahmen sind, welche Produktkategorien den größten Umsatz erzeugen und wie sich die Einnahmen nach Kundensegmenten aufteilen.

Aber im Hintergrund geschieht etwas, das man beachten sollte.

Da keine zusätzlichen Semantiken definiert wurden, muss der Agent die Verknüpfung selbst ableiten:

customers.CustomerId
       =
sales.CustomerId

und er muss auch folgendes ableiten:

Revenue → SUM(Revenue)

Das gibt Ihnen eine Grundlage zum Vergleichen.

9. Schritt 2 – Hinzufügen des semantischen Modells

Danach führen Sie den analytischen Vertrag ein.

Customer
    1
    │
    *
Sales

mit geregelten Messgrößen wie:

Total Revenue =
SUM(sales[Revenue])

und:

Total Orders =
DISTINCTCOUNT(sales[OrderId])

Zu diesem Zeitpunkt muss der Agent nicht mehr erraten, was „Gesamteinnahmen“ bedeutet.

Diese Definition gehört zur semantischen Schicht.

Das weist auf ein wichtiges Prinzip für Unternehmensagenten hin:

Agenten sollten regulierte Metriken verwenden, anstatt jedes Mal bei einer Anfrage Unternehmensberechnungen aus Rohdatenspalten neu zu erstellen.

10. Schritt 3 – Ontologie hinzufügen

Von hier an wechseln Sie von analytischen Definitionen zu einer unternehmensbezogenen Bedeutung.

Die Ontologie in dieser Übung definiert lediglich zwei Entity-Typen:

Customer

Product

Kunde entspricht:

customers.CustomerId
customers.CustomerName
customers.Segment
customers.City
customers.State
customers.Country

Verwendung von:

KEY = CustomerId

Produkt hingegen wird direkt aus der vorhandenen sales-Tabelle abgeleitet:

sales.ProductName
sales.ProductCategory

Verwendung von:

KEY = ProductName

Auch hier war es nicht notwendig, eine separate physische Produkttabelle zu erstellen, damit dies funktioniert.

11. Definition der Geschäftsbeziehung

Danach wird eine Beziehung hinzugefügt:

Customer
     │
     │ PURCHASES
     ▼
Product

Interessant ist hier, wie die Datenbindung funktioniert.

Die sales-Tabelle selbst dient als Brücke für diese Beziehung:

Customer.CustomerId
        ↑
sales.CustomerId

sales.ProductName
        ↓
Product.ProductName

So wird eine rohe Verkaufszeile wie:

sales row:

CustomerId = C001
ProductName = Laptop Pro

zu:

Customer(C001)
       │
       │ PURCHASES
       ▼
Product(Laptop Pro)

Genau in diesem Moment verwandelt sich ein einfaches relationales Datensatz in etwas, das das Unternehmen tatsächlich als Wissen erkennt.

Fabrics Ontologiemodell ist speziell für diesen Workflow konzipiert: Zuerst werden Entity-Typen und ihre Beziehungen definiert, anschließend werden diese abstrakten Definitionen mit konkreten Daten in OneLake verknüpft.

12. Was ändert sich für den Agenten?

Nehmen wir diese Frage:

Welche Produkte kaufen Enterprise-Kunden?

Ohne eine vorhandene Ontologie muss der Agent so etwas wie folgendes durchdenken:

Find customers table
      ↓
Find Segment
      ↓
Filter Enterprise
      ↓
Determine CustomerId join
      ↓
Join sales
      ↓
Find ProductName

Mit der verfügbaren Ontologie reduziert sich das Abwägen auf:

Customer
   │
Segment = Enterprise
   │
   └── PURCHASES ──> Product

Die Frage entspricht fast direkt dem Modell selbst.

Microsoft beschreibt diesen Wandel als den Übergang von Agenten, die in Begriffen einzelner Tabellen denken, zu einem strukturierten Ansatz, der aus Entitäten, Beziehungen, Definitionen, Regeln und Quellzuordnungen besteht.

13. Schritt 4 – Der Fabric Data Agent erstellen

Der Data Agent ist es, der all das in eine Schnittstelle in natürlicher Sprache umwandelt:

User
                        │
                        ▼
                NP_Sales_DataAgent
                        │
          ┌─────────────┼─────────────┐
          ▼             ▼             ▼
      Lakehouse    Semantic Model   Ontology
          │             │             │
      raw facts     trusted KPIs   relationships
          │             │             │
          └─────────────┼─────────────┘
                        ▼
                     OneLake

Microsoft beschreibt Fabric Data Agents als eine schriftsprachbasierte Frage-Antwort-Schicht, die auf einem definierten Datenumfeld beschränkt ist, wobei die Ontologie den tieferen Geschäftskontext liefert, auf den diese Agenten zurückgreifen.

14. Dann kommt der wichtige architektonische Schritt: MCP

Ein Fabric Data Agent muss nicht unbedingt innerhalb von Fabric bleiben.

Man kann ihn veröffentlichen.

Sobald er veröffentlicht wurde, stellt Fabric diesen Agenten als Model Context Protocol Server zur Verfügung.

Konzeptionell sieht der Ablauf so aus:

Fabric Data Agent
       │
       │ Publish
       ▼
MCP Server
       │
       ├── tool description
       ├── input schema
       └── governed execution

Ab diesem Punkt wird Ihre Unternehmensdatenintelligenz zu etwas Wiederverwendbarem – einer Agenten-Tool, die andere Systeme aufrufen können.

15. Microsoft Foundry wird zur Orchestrierungsschicht

Dies ermöglicht eine deutlich interessantere Architektur.

USER
                              │
                              ▼
                   Microsoft Foundry Agent
                              │
                   planning / orchestration
                              │
          ┌───────────────────┼───────────────────┐
          │                   │                   │
          ▼                   ▼                   ▼
      CRM Tool            Search Tool        Fabric MCP
                                                  │
                                                  ▼
                                        Fabric Data Agent
                                                  │
                              ┌───────────────────┼───────────────┐
                              ▼                   ▼               ▼
                         Semantic Model       Ontology        Lakehouse
                              │                   │               │
                              └───────────────────┼───────────────┘
                                                  ▼
                                               OneLake

Die Trennung der Aufgaben ist hier von Bedeutung.

Der Foundry-Agent ist für das Workflow-Reasoning zuständig.

Der Fabric Data Agent ist für das Daten-Reasoning zuständig.

In seiner aktuellen Form ermöglicht die Foundry-Integration von Microsoft es einem Foundry-Agenten, über den Fabric IQ / OneLake Catalog veröffentlichte Fabric Data Agents zu entdecken und sie als MCP-Tools zu verwenden. Ein einzelner Foundry-Agent ist außerdem nicht auf ein bestimmtes Domänenfeld beschränkt – er kann mehrere Fabric Data Agents gleichzeitig abrufen und nutzen.

16. Ein Arbeitsbeispiel

Stellen Sie sich vor, ein Benutzer sendet dem Foundry-Agenten einen Antrag in etwa folgender Form: Finden Sie den Kundensegment, der den größten Anteil am Umsatz beiträgt, ermitteln Sie, welche Produkte die Leistung dieses Segments beeinflussen, und wandeln Sie die Ergebnisse in eine Empfehlung um, auf die das Vertriebsteam reagieren kann.

So könnte die Ausführung ablaufen:

USER
 │
 ▼
Foundry Orchestrator
 │
 │ "I need enterprise sales intelligence."
 │
 ▼
Fabric Data Agent MCP Tool
 │
 ├── Semantic Model
 │      → trusted revenue calculation
 │
 ├── Ontology
 │      → Customer → PURCHASES → Product
 │
 └── Lakehouse
        → transaction data
 │
 ▼
Result:
Enterprise customers generate...
Laptop category contributes...
 │
 ▼
Foundry Agent
 │
 ├── reasoning
 ├── CRM lookup
 ├── recommendation generation
 └── potentially action
 │
 ▼
Sales recommendation

Was hier zählt, ist nicht, dass ein Sprachmodell eine Empfehlung ergeben hat. Entscheidend ist vielmehr, dass die Empfehlung auf einer regulierten Geschäftsrepräsentation beruht und nicht aus Rohdaten oder geschätzten Semantiken improvisiert wurde.

17. MCP verändert die Architektur von Enterprise Agents

Ohne MCP enden Teams in der Regel damit, die Dinge so zu verbinden:

Agent A → custom Fabric integration

Agent B → another custom Fabric integrationAgent C → another SQL implementationAgent D → another Power BI integration

Im Laufe der Zeit sammelt jeder einzelne Agent tiefgehende, aber brüchige Kenntnisse über die zugrunde liegende Datenplattform.

Mit MCP sieht die Situation anders aus:

Enterprise Agents
        ┌───────────┼───────────┐
        ▼           ▼           ▼
     Agent A     Agent B      Agent C
        │           │           │
        └───────────┼───────────┘
                    │
                 MCP Tool
                    │
                    ▼
             Fabric Data Agent
                    │
                    ▼
             Governed Data IQ

Der Fabric Data Agent wird zu einem Datenintelligenzprodukt, das für die Nutzung durch Agents konzipiert ist, anstatt zu einer maßgeschneiderten Integration, die jedes Team neu aufbauen muss. Das ist ein scheinbar kleiner, aber architektonisch bedeutender Wandel.

18. Eine weitere Option: Die Ontologie direkt zugänglich machen

Es gibt einen zweiten Ansatz, den man in Betracht ziehen sollte.

Anstatt alles über einen Fabric Data Agent zu leiten, kann die Fabric Ontologie selbst über MCP an jeden kompatiblen externen Agenten bereitgestellt werden. Microsoft dokumentiert einen Ontology MCP-Server, der mit Tools ausgeliefert wird, um Ontologie-Entitätsarten zu entdecken und Abfragen gegen die Ontologie auszuführen.

Das bietet Ihnen zwei unterschiedliche Ansätze:

PATTERN A

External Agent
      │
      │ MCP
      ▼
Fabric Data Agent
      │
      ▼
Ontology

im Gegensatz zu:

PATTERN B

External Agent
      │
      │ MCP
      ▼
Fabric Ontology

Wählen Sie den ersten Ansatz, wenn Sie von Fabrics eigenem konversationellen und datenagentbasierten Reasoning-Layer profitieren möchten. Wählen Sie den zweiten Ansatz, wenn der externe Agent bereits über eigene, ausgefeilte Planungsalgorithmen verfügt und lediglich einen direkteren Zugang zum Unternehmenssemantikmodell benötigt.

19. Vorteile und Nachteile des Fabric-Ansatzes

Vorteile

Zentralisierte Semantik. Die Geschäftsdefinitionen befinden sich an einem zentral verwalteten Ort, anstatt in jeden Prompt kopiert zu werden.

Basiert auf OneLake. Es besteht keine strenge Pflicht, Ihr gesamtes Datensystem auf eine separate Graphenplattform zu übertragen.

Drei Schichten arbeiten zusammen. Analytische Metriken sowie semantische Informationen auf Beziehungs-Ebene können im semantischen Modell, in der Ontologie und im Graphen nebeneinander existieren.

Entwickelt für Agenten. Sowohl die Fabric Data Agents als auch die Ontologie-Schicht wurden ausdrücklich dafür konzipiert, als Grundlage für KI-Agenten zu dienen.

Öffentlich über MCP. Die entstehende Intelligenzschicht kann sowohl von Foundry als auch von benutzerdefinierten MCP-Clienten genutzt werden.

Klare Trennung der Aufgabenbereiche.

Fabric → data intelligence

Foundry → orchestration intelligence

Diese Trennung schafft auf Unternehmensebene eine deutlich klare Grenze.

20. Kompromisse

Es gelten einige wichtige Einschränkungen.

Ein Großteil davon ist weiterhin Prüftechnologie. Die Ontologienunterstützung, mehrere Integrationen von Fabric IQ und Foundry sowie damit verbundene MCP-Funktionen bleiben als Prüfmerkmale bestehen, weshalb Sie diese vor der Verwendung in der Produktion gegen Microsofts aktuelle Prüfbedingungen überprüfen sollten.

Die Verwaltung von Ontologien ist eine kontinuierliche Aufgabe. Sobald mehrere Bereiche beginnen, ihre eigenen Entitäten wie Customer, Account, Product, Contract usw. zu definieren, muss jemand für die Benennung, Versionierung und Abstimmung zwischen den Bereichen verantwortlich sein.

Ontologien können schlechte Daten nicht beheben. Selbst wenn man elegante Geschäftssemantiken um ein Datenset niedriger Qualität legt, ergeben sich weiterhin Ergebnisse schlechter Qualität.

Ontologien sind nicht immer notwendig. Für einfache Aggregationen von KPIs kann das Direktabfragen des semantischen Modells einfacher und ausreichend sein.

Nicht jeder Graphen-Anwendungsfall eignet sich hierfür. Komplexe Graphenalgorithmen, spezialisierte RDF-basierte Schlussfolgerungen oder hochgradig angepasste Graphen-Arbeitslasten erfordern möglicherweise stattdessen eine spezielle Graphen-Plattform.

Deshalb ist ein schrittweises Entscheidungsframework besonders nützlich.

21. Der Roadmap, den ich verwenden würde

Anstatt direkt mit einem unternehmensweiten Ontologie-Projekt zu beginnen, macht es Sinn, schrittweise vorzugehen.

Phase 1 – Datenerzeugnisse

Sources
   ↓
OneLake
   ↓
Domain Data Products

Das Ziel hier ist es, vertrauenswürdige, eindeutig zugeordnete Domänendaten zu schaffen.

Phase 2 – Analytische Semantik

Data Product
     ↓
Semantic Model
     ↓
Measures / KPIs / Dimensions

In dieser Phase wird definiert, wie die Organisation Dinge misst.

Phase 3 – Geschäftssemantik

Semantic Models + Data Products
             ↓
          Ontology
             ↓
Entities / Relationships / Rules

In dieser Phase wird definiert, was die gemessenen Werte tatsächlich bedeuten.

Phase 4 – Vernetzte Intelligenz

Ontology
   ↓
Graph
   ↓
Traversal / dependency / impact analysis

In dieser Stufe werden Graphenstrukturen nur dann eingesetzt, wenn das Durchlaufen von Beziehungen tatsächlich sinnvoll ist.

Phase 5 – Domänen-Daten-Agenten

Ontology + Semantic Model + Data
                 ↓
             Data Agent

Hier wird dieses angesammelte Domänenwissen in etwas Verständliches umgewandelt.

Phase 6 – MCP

Data Agent
    ↓
Publish
    ↓
MCP

In diesem Schritt wird das verständliche Produkt in eine Funktionalität umgewandelt, die von anderen Agenten genutzt werden kann.

Phase 7 – Orchestrierung von Unternehmensagenten

Foundry Agent
                          │
       ┌──────────────────┼──────────────────┐
       ▼                  ▼                  ▼
 Sales Data Agent    Supply Agent       Finance Agent
       │                  │                  │
       └──────────────────┼──────────────────┘
                          │
                     Fabric IQ

Microsoft bewegt sich bereits in diese Richtung: Foundry-Agenten können über Fabric IQ auf mehrere veröffentlichte Fabric Data Agents zugreifen, wobei jeder dieser Agenten als MCP-Tool bereitgestellt wird.

Wohin es geht

Der größere architektonische Wandel sieht so aus:

GENERATION 1

                        LLM + RAG
                           │
                       Documents

zu etwas, das sich weiterentwickelt zu:

GENERATION 2

                    LLM + Tools + Data
                           │
                     SQL / APIs / RAG

und letztendlich zu:

GENERATION 3

                      Agent Systems
                           │
             ┌─────────────┼─────────────┐
             ▼             ▼             ▼
         Documents       Tools       Enterprise IQ
                                         │
                              ┌──────────┼──────────┐
                              ▼          ▼          ▼
                          Semantics   Ontology    Graph
                              │          │          │
                              └──────────┼──────────┘
                                         ▼
                                   Enterprise Data

Der Wettbewerbsvorteil in diesem Bereich wird zunehmend nicht mehr darin bestehen, welches Modell am stärksten ist.

Stattdessen wird er davon abhängen, welche Organisation die umfangreichste Enterprise-Context-Schicht für diese Modelle entwickelt hat, auf die sie zurückgreifen können.

Microsoft beschreibt seine allgemeine Ausrichtung als Microsoft IQ, wobei Fabric IQ Kontext zu Geschäftsentitäten und Daten liefert und dabei mit Work IQ, Foundry IQ sowie Web IQ zusammenarbeitet.

Diese Sichtweise hält stand.

Man kann einem Agenten nicht einfach deshalb vertrauen, dass er gut darin ist, Dokumente abzurufen, damit er Teile eines Unternehmens betreut.

Er muss verstehen:

Was die Dinge sind.

Wie sie miteinander verbunden sind.

Wie die Organisation sie tatsächlich misst.

Welche Definitionen Autorität haben.

In welchem Zustand sich diese Dinge derzeit befinden.

Und letztendlich:

Welche Handlungen angesichts all dessen sinnvoll sind.

Fazit: Vom RAG zum unternehmensweiten Reasoning

RAG gab der UnternehmenskI einen Weg, auf Wissen zuzugreifen.

Der Einsatz von Tools gab Agenten einen Weg, auf Systeme zuzugreifen.

Ontologien bieten ihnen etwas völlig anderes:

Bedeutung.

Sobald diese Bedeutung mit gesteuerten Metriken, Graphenbeziehungen, Echtzeit-Operationaldaten sowie Agent-Orchestrierung kombiniert wird, entsteht eine deutlich überzeugendere Architektur:

DATA
 │
 ▼
SEMANTICS
 │
 ▼
ONTOLOGY
 │
 ▼
CONNECTED INTELLIGENCE
 │
 ▼
DATA AGENTS
 │
 ▼
MCP
 │
 ▼
ENTERPRISE AGENTS
 │
 ▼
DECISIONS
 │
 ▼
ACTIONS

Das ist letztendlich der eigentliche Wertvorschlag hinter ontologiebasierten agentengetriebenen Analysen.

Es handelt sich dabei nicht einfach um einen weiteren Chatbot, der an eine Datenbank angehängt wird.

Es handelt sich um eine Unternehmensintelligenzarchitektur, in der Datenprodukte die Fakten liefern, semantische Modelle zuverlässige Messwerte, Ontologien Bedeutung, Graphen Beziehungen, Domänenagenten Intelligenz und MCP all diese Komponenten im gesamten Agentenökosystem miteinander verknüpfbar macht.

Genau diese Kombination macht die nächste Generation von UnternehmenskI deutlich interessanter zum Entwickeln.