Startseite / Artikel / RDF zu GraphRAG: Praktische Ontologie-Ebenen mit VOO-Beispielen

ontology rdf owl shacl graphrag knowledge-graph

RDF zu GraphRAG: Praktische Ontologie-Ebenen mit VOO-Beispielen

Von IRIs und Tripeln über RDFS, OWL und SHACL – wann Ontologien Tabellen übertreffen und wie sie GraphRAG stabilisieren.

2162 Wörter

Eine Ontologie klingt mystisch; die Idee dahinter ist jedoch einfach. Es handelt sich um eine ausdrückliche Vereinbarung bezüglich eines Bereichs: Welche Arten von Dingen existieren, welche Beziehungen zulässig sind, welche Regeln diese Verbindungen einhalten müssen und was eine Maschine aus bereits vorhandenen Fakten ableiten kann. Grubers klassische Formulierung – „eine ausdrückliche Spezifikation einer Konzeptualisierung“ – bedeutet lediglich eine maschinenlesbare Beschreibung davon, wie ein Team beschlossen hat, einen bestimmten Aspekt der Welt zu verstehen.

Ein aktuelles Beispiel hilft: der Vanguard S&P 500 ETF (VOO). In den öffentlichen Unterlagen heißt es, VOO solle den S&P 500 nachverfolgen. Ein Wissenssystem sollte zumindest Folgendes verstehen:

Der Vanguard S&P 500 ETF ist im Grunde ein ETF. Er wird von Vanguard verwaltet und verfolgt den S&P 500 Index.

Diese drei Sätze berühren bereits alle wichtigen Ebenen darunter.

Ontologie und Wissensgraph sind nicht dasselbe

Die Ontologie definiert die Regeln der Welt. Der Wissensgraph enthält Fakten über diese Welt.

Die Ontologie kann ETF und AssetManager als Typen deklarieren, managedBy als Verbindung vom ETF zum Manager und tracksIndex als Verbindung vom ETF zum Index. Der Graph speichert anschließend Instanzen: VOO ist ein ETF; VOO managedBy Vanguard; VOO tracksIndex S&P500Index.

Stellen Sie sich das Design eines Brettspiels im Vergleich zur aktuellen Situation auf dem Spielfeld vor. Zu sagen „Ontologie ≈ Schema, Wissensgraph ≈ Daten“ ist ein nützlicher Kurzweg – obwohl Ontologien reichere Logik als typische Datenbank-Schemata kodieren können.

Braucht man immer eine Ontologie?

Nicht unbedingt. Genaue Schlüsselabfragen für einige Felder können in Tabellen oder JSON gespeichert werden. Die Erstellung einer Ontologie erfordert Design, Verwaltung, Validierung und Wartung. Sie lohnt sich, wenn Probleme wie diese auftreten:

Problem 1: Verschiedene Systeme verwenden unterschiedliche Begriffe

fund provider, asset manager und management company können denselben Begriff bezeichnen. Eine Ontologie wählt einen bevorzugten Begriff aus und verknüpft die Synonyme miteinander.

Problem 2: Benutzer stellen Fragen, die Beziehungen erfordern

Fragen wie „Welche von Vanguard verwalteten ETFs folgen einem US-Aktienindex?“ benötigen einen mehrstufigen Suchweg, nicht nur eine Schlüsselwortabfrage.

Problem 3: Das System muss ungültige Daten erkennen

Falls managedBy auf eine Organisation verweisen muss, sollte VOO managedBy John Smith fehlschlagen – selbst wenn John ein Portfoliomanager ist. In regulierten Branchen kann bereits ein einziger Fehler die Konformität sowie die Ergebnisse der KI untergraben; Ontologiekonventionen dienen dabei als Schutzmechanismen.

Problem 4: Das System sollte Fakten ableiten, die niemals direkt gespeichert wurden

Durch Subklassen- und umgekehrte-Attribut-Logik können implizierte Typen sowie umgekehrte Verknüpfungen erzeugt werden.

Problem 5: Ein LLM benötigt eine zuverlässige Karte des Domänenbereichs

Modelle erzeugen spontan Strukturen; eine Ontologie liefert hingegen eine überprüfte Karte zur Aufteilung, Verankerung und Validierung – insbesondere in Kombination mit GraphRAG.

Ein Beispiel, fünf Technologieebenen

Die VOO-Geschichte umfasst fünf Ebenen: Identifikatoren, RDF-Triple, RDFS-Schema, OWL-Semantik und SHACL-Validierung.

Ebene 1: Identifikatoren und Namensräume

Stabile IRIs vermeiden Namenskollisionen. Ein Manager kann beispielsweise so benannt werden:

https://example.org/finance/Vanguard

Prefixe sorgen dafür, dass Dateien lesbar bleiben:

@prefix fin: <https://example.org/finance/> .

Dadurch werden lokale Namen wie folgt erweitert:

fin:Vanguard

Schicht 2: RDF stellt Fakten als Tripel dar

Jede Aussage besteht aus Subjekt–Prädikat–Objekt:

Subject       Predicate       Object
VOO           managedBy       Vanguard
VOO           tracksIndex     S&P 500 Index

Turtle-Format:

@prefix fin: <https://example.org/finance/> .

fin:VOO fin:managedBy fin:Vanguard ;
        fin:tracksIndex fin:SP500Index .

JSON-LD kann denselben Graphen für Web-Stacks verwenden:

{
  "@context": {
    "fin": "https://example.org/finance/",
    "managedBy": {
      "@id": "fin:managedBy",
      "@type": "@id"
    },
    "tracksIndex": {
      "@id": "fin:tracksIndex",
      "@type": "@id"
    }
  },
  "@id": "fin:VOO",
  "managedBy": "fin:Vanguard",
  "tracksIndex": "fin:SP500Index"
}

Schicht 3: RDFS führt ein grundlegendes Schema ein

RDFS fügt Klassen, Eigenschaften sowie Domain/Range-Beziehungen hinzu. Eine einfache Produkttaxonomie:

@prefix fin:  <https://example.org/finance/> .
@prefix rdf:  <http://www.w3.org/1999/02/22-rdf-syntax-ns#> .
@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> .

fin:FinancialProduct a rdfs:Class .
fin:Fund             a rdfs:Class ;
                     rdfs:subClassOf fin:FinancialProduct .
fin:ETF              a rdfs:Class ;
                     rdfs:subClassOf fin:Fund .
fin:AssetManager     a rdfs:Class .
fin:MarketIndex      a rdfs:Class .
fin:managedBy a rdf:Property ;
    rdfs:domain fin:Fund ;
    rdfs:range fin:AssetManager .
fin:tracksIndex a rdf:Property ;
    rdfs:domain fin:ETF ;
    rdfs:range fin:MarketIndex .

Die Deklaration eines ETFs unter diesem Baum:

FinancialProduct
└── Fund
    └── ETF

Schicht 4: OWL fügt umfangreichere Semantik hinzu

OWL kann Inverse, Kardinalität und Disjunktheit angeben. Wenn managedBy die Inverse von manages ist, kann das Speichern einer Richtung die andere implizieren:

fin:VOO fin:managedBy fin:Vanguard .

Inverses Schema:

@prefix fin: <https://example.org/finance/> .
@prefix owl: <http://www.w3.org/2002/07/owl#> .

fin:managedBy a owl:ObjectProperty ;
    owl:inverseOf fin:manages .
fin:ETF owl:disjointWith fin:AssetManager .

Menschliche Interpretation der Implikation:

If VOO is managed by Vanguard,
then Vanguard manages VOO.

Ausgesagter Fakt:

fin:VOO fin:managedBy fin:Vanguard .

Aus dem Umkehrschluss abgeleitet:

fin:Vanguard fin:manages fin:VOO .

Schicht 5: SHACL validiert Graphendaten

Formen erkennen in der Produktion Instanzfehler, um die sich Ontologieentwickler kümmern. Eine gültige ETF-Beschreibung:

@prefix fin: <https://example.org/finance/> .
@prefix sh:  <http://www.w3.org/ns/shacl#> .

fin:ETFShape
    a sh:NodeShape ;
    sh:targetClass fin:ETF ;
    sh:property [
        sh:path fin:managedBy ;
        sh:class fin:AssetManager ;
        sh:minCount 1 ;
        sh:maxCount 1
    ] ;

    sh:property [
        sh:path fin:tracksIndex ;
        sh:class fin:MarketIndex ;
        sh:minCount 1
    ] .

Kompakte gültige Instanz:

fin:VOO a fin:ETF ;
    fin:managedBy fin:Vanguard ;
    fin:tracksIndex fin:SP500Index .

fin:Vanguard a fin:AssetManager .
fin:SP500Index a fin:MarketIndex .

Ein ungültiger Manager-Typ sollte die Validierung scheitern lassen:

fin:BrokenFund a fin:ETF ;
    fin:managedBy fin:Alice .

fin:Alice a fin:PortfolioManager .

Wie Schlussfolgerungen neues Wissen schaffen

Unterklassenzusammenhänge heben Instanzen im Baum nach oben:

fin:ETF rdfs:subClassOf fin:Fund .
fin:Fund rdfs:subClassOf fin:FinancialProduct .
fin:managedBy rdfs:range fin:AssetManager .
fin:managedBy owl:inverseOf fin:manages .

Aus einer eng gefassten Typbehauptung:

fin:VOO a fin:ETF ;
    fin:managedBy fin:Vanguard .

Reasoner können weiter gefasste Typen ableiten:

fin:VOO a fin:Fund .
fin:VOO a fin:FinancialProduct .
fin:Vanguard a fin:AssetManager .
fin:Vanguard fin:manages fin:VOO .

Schlussfolgerungen füllen Lücken; SHACL schützt weiterhin das, was Menschen oder Extraktoren schreiben.

Kompetenzfragen: Von den Fragen ausgehend entwerfen

Beginnen Sie mit Fragen, die das System beantworten muss – „Welche Vanguard-ETFs folgen US-Aktienindizes?“ – und entscheiden Sie anschließend über Typen, Eigenschaften und Einschränkungen. So bleiben Ontologien an der Anwendung gebunden und nicht an philosophischer Vollständigkeit.

Ein praktischer Workflow zur Entwicklung von Ontologien

Domain goals + user questions + source data
                  ↓
       Competency-question generation
                  ↓
       Concept and relationship extraction
                  ↓
         Initial ontology proposal
                  ↓
     Reasoning, SHACL, and query evaluation
                  ↓
       Human review and iterative revision

Iterieren Sie: Ziele und Fragen → konzeptionales Modell → formale Ontologie → Graphen füllen → Validierung → Abfragen/Logikverarbeitung → Überarbeitung.

Konzeptionaler Entwurf:

ETF ──managedBy──> AssetManager
ETF ──tracksIndex──> MarketIndex

Beispiel für eine SPARQL-ähnliche Anfrage:

SELECT ?etf
WHERE {
  ?etf a fin:ETF ;
       fin:managedBy fin:Vanguard ;
       fin:tracksIndex fin:SP500Index .
}

Hinweis zur schichtweisen Struktur:

RDF stores:
VOO managedBy Vanguard

RDFS understands:
VOO is a Fund, and Vanguard is an AssetManager

OWL can infer:
Vanguard manages VOO

SHACL checks:
Does VOO have exactly one valid AssetManager?
Does it track at least one MarketIndex?

Was KI-Modelle automatisieren können – und was sie nicht allein entscheiden sollten

Modelle helfen dabei, Labels zu entwerfen, Eigenschaften vorzuschlagen und Kompetenzfragen zu formulieren. Sie sollten jedoch nicht stillschweigend die Verwaltung übernehmen: Endgültige Typensysteme, Kardinalitäten und regulatorische Einschränkungen benötigen menschliche Verantwortliche sowie Tests.

Wo Ontologien GraphRAG unterstützen

1. Abgrenzung der Abfragen

Typisierte Beziehungen geben den Planern an, welche Schritte sinnvoll sind.

2. Entitätsauflösung

Gemeinsame IRIs sowie Synonymkarten führen zur Zusammenfassung von „Vanguard“ und „The Vanguard Group“.

3. Steuerung der Datenerfassung

Anker und Kantenfilter sind effektiver als reiner Kosinus, wenn Identifikatoren wichtig sind.

4. Überprüfung der Antworten

SHACL sowie aus den Strukturen abgeleitete Prüfungen lehnen Antworten ab, die illegale Kanten erzeugen.

Fünf Designprinzipien, die man beibehalten sollte

Trennen Sie das Schema (Ontologie) von den Instanzdaten (Graph).
Entwerfen Sie anhand von Kompetenzfragen und nicht nach Modetrends.
Ziehen Sie kleine, testbare Einschränkungen vor monolithische Axiome.
Überprüfen Sie bei der Eingabe; nutzen Sie logisches Schließen dort, wo es sinnvoll ist.
Betrachten Sie die Hilfe von LLMs als Unterstützung bei der Erstellung unter menschlicher Leitung.

Fazit

Ontologien sind vereinbarte Strukturen, die maschinell überprüft werden können. RDF speichert Fakten; RDFS und OWL fügen Struktur sowie Inferenzmechanismen hinzu; SHACL gewährleistet die Qualität der Instanzen; GraphRAG nutzt das Ergebnis als sichereren „Plan“ im Vergleich zu Vektoren allein. Das VOO-Beispiel ist absichtlich klein: Wenn bereits drei Sätze fünf Ebenen erfordern, ist das auch bei einem echten Produktkatalog möglich – sobald es fachliche Fragen und zuständige Verantwortliche gibt.

Führen Sie für jede wichtige Klasse und Eigenschaft ein einseitiges Entscheidungsprotokoll führen: Warum sie existiert, welche Kompetenzfrage sie abdeckt und welche SHACL-Struktur sie schützt. Versionierungs-IRIs steuern die Verarbeitung genauso wie API-Versionen Routen; ein Umbenennen ohne Umleitungen zerstört alle nachfolgenden GraphRAG-Verbindungen. Wenn Extraktoren neue Kanten vorschlagen, ist eine passende Struktur oder ein explizit als „unbeschränkt“ definiertes Sandbox-Graph erforderlich, damit störende Ausgaben von Large Language Models den kontrollierten Speicher nicht verschmutzen. Messen Sie den Wert der Ontologie anhand der Abdeckung der Kompetenzfragen und der Fehlerquote bei der Validierung – nicht anhand der Anzahl der Axiome. Schließlich sollten alle produktiven GraphRAG-Einsatzfälle mit einem Satz an rechtlichen und illegalen Tripeln versehen werden, sodass die CI-Tests fehlschlagen, wenn eine „nützliche“ Schema-Änderung heimlich den Anwendungsbereich erweitert und es bösen Managern ermöglicht, erneut Konten zu nutzen.

Dokumentieren Sie die Kompetenzfragen zusammen mit den SPARQL-Fixtures, damit Schema-Änderungen nicht von den Anfragen abweichen, auf die das produktive GraphRAG weiterhin antworten muss.

Dokumentieren Sie die Kompetenzfragen neben den SPARQL-Fixtures, damit Schema-Änderungen nicht von den Anfragen abweichen, auf die GraphRAG in der Produktion weiterhin antworten muss.

Alle Artikel Brief senden