Strona główna / Artykuły / RDF do GraphRAG: Praktyczne warstwy ontologii z przykładami VOO

ontology rdf owl shacl graphrag knowledge-graph

RDF do GraphRAG: Praktyczne warstwy ontologii z przykładami VOO

Od IRI i trójkątów przez RDFS, OWL i SHACL – kiedy ontologie przewyższają tabele i w jaki sposób wspierają GraphRAG.

2162 słów

Ontologia brzmi mistycznie, ale idea jest prosta. Jest to wyraźna umowa dotycząca określonego obszaru: jakie rodzaje rzeczy istnieją, jakie relacje są dopuszczalne, jakich zasad muszą przestrzegać te powiązania oraz co maszyna może wywnioskować na podstawie już dostępnych faktów. Klasyczne stwierdzenie Grubera – „wyraźna specyfikacja koncepcjonalizacji” – oznacza po prostu opis czytelny dla maszyny, który pokazuje, w jaki sposób zespół postanowił zrozumieć określoną część świata.

Pomaga przykład z praktyki: Vanguard S&P 500 ETF (VOO). W materiałach publicznych podano, że VOO ma na celu śledzenie indeksu S&P 500. System wiedzy powinien rozumieć przynajmniej:

Vanguard S&P 500 ETF to w istocie ETF zarządzany przez Vanguard. Śledzi on indeks S&P 500.

Tych trzech zdań już dotyka każdej z głównych warstw poniżej.

Ontologia i graf wiedzy to nie to samo

Ontologia definiuje zasady funkcjonowania świata. Graf wiedzy przechowuje fakty dotyczące tego świata.

Ontologia może określić ETF i AssetManager jako typy, managedBy jako powiązanie od ETF do menedżera, a tracksIndex jako powiązanie od ETF do indeksu. Następnie graf przechowuje instancje: VOO to ETF; VOO managedBy Vanguard; VOO tracksIndex S&P500Index.

Pomyśl o projektowaniu gier planszowych w porównaniu z obecną sytuacją na planszy. Stwierdzenie „ontologia ≈ schemat, graf wiedzy ≈ dane” jest przydatnym uproszczeniem – mimo że ontologie mogą zawierać bogatszą logikę niż typowe schematy baz danych.

Czy zawsze potrzebna jest ontologia?

Nie. Wyszukiwanie według dokładnych kluczy w kilku polach może odbywać się w tabelach lub plikach JSON. Praca nad ontologią wymaga projektowania, zarządzania, weryfikacji oraz konserwacji. Opłaca się ją stosować, gdy pojawiają się takie problemy:

Problem 1. Różne systemy używają różnych terminów

fund provider, asset manager oraz management company mogą oznaczać ten sam pojęcie. Ontologia wybiera preferowany termin i mapuje alternatywne nazwy.

Problem 2. Użytkownicy zadają pytania wymagające określenia relacji

Zapytanie „Które ETF-y zarządzane przez Vanguard odzwierciedlają indeks akcji amerykańskich?” wymaga ścieżki wieloetapowej, a nie tylko dopasowania kluczowego słowa.

Problem 3. System musi wykrywać nieważne dane

Jeśli managedBy musi wskazywać na organizację, VOO managedBy John Smith powinno zawieść – nawet jeśli John jest menedżerem portfela. W branżach regulowanych jeden błąd może podważyć zgodność z przepisami oraz poprawność odpowiedzi generowanych przez AI; ograniczenia ontologii pełnią rolę zabezpieczeń wejściowych.

Problem 4. System powinien wyprowadzać fakty, które nigdy nie zostały bezpośrednio zapisane

Rozumowanie oparte na podklasach i odwrotnych właściwościach może ujawnić domyślne typy oraz odwrotne powiązania.

Problem 5. LLM potrzebuje niezawodnej mapy domeny

Modele tworzą płynną strukturę; ontologia dostarcza sprawdzoną mapę służącą do dekompozycji, uzasadniania i walidacji – szczególnie w połączeniu z GraphRAG.

Jeden przykład, pięć warstw technologicznych

Historia VOO obejmuje pięć warstw: identyfikatory, trojki RDF, schemat RDFS, semantykę OWL oraz walidację SHACL.

Warstwa 1: identyfikatory i przestrzenie nazw

Stabilne IRI zapobiegają kolizjom nazw. Menedżer może mieć następującą nazwę:

https://example.org/finance/Vanguard

Prefiksy umożliwiają czytelne przechowywanie plików:

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

Które rozszerzają lokalne nazwy, takie jak:

fin:Vanguard

Szczegół 2: RDF reprezentuje fakty jako trojki

Każde stwierdzenie ma postać podmiot–przedmiot–cecha:

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

Forma Turtle:

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

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

JSON-LD może przechowywać ten sam graf w kontekście stosów internetowych:

{
  "@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"
}

Szczegół 3: RDFS wprowadza podstawowy schemat

RDFS dodaje klasy, właściwości, domeny/zakresy oraz powiązania podklas. Prosta taksonomia produktów:

@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 .

Deklaracja ETF w ramach tego drzewa:

FinancialProduct
└── Fund
    └── ETF

Szczegół 4: OWL dodaje bardziej złożone semantyki

OWL umożliwia określanie odwrotów, kardynalności i nierozłączności. Jeśli managedBy jest odwrotem dla manages, przechowywanie jednego kierunku może implikować drugi:

fin:VOO fin:managedBy fin:Vanguard .

Szkic odwrotności:

@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 .

Ludzkie odczytanie implikacji:

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

Fakt stwierdzony:

fin:VOO fin:managedBy fin:Vanguard .

Wynikowa konwersja w odwrotną stronę:

fin:Vanguard fin:manages fin:VOO .

Szczegół 5: SHACL weryfikuje dane grafu

Kształty wykrywają błędy instancji, które autorzy ontologii uważają za istotne w środowisku produkcyjnym. Poprawny opis ETF:

@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
    ] .

Kompaktowa, poprawna instancja:

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

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

Nieprawidłowy typ menedżera powinien spowodować niepowodzenie weryfikacji:

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

fin:Alice a fin:PortfolioManager .

Jak inferencja tworzy nową wiedzę

Łańcuchy podklas promują instancje w górę drzewa:

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

Z wąskiego stwierdzenia typu:

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

Mechanizmy rozumowania mogą wyciągnąć wnioski dotyczące szerszych typów:

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

Inferencja wypełnia luki; SHACL nadal chroni to, co piszą ludzie lub narzędzia do wydobywania danych.

Pytania dotyczące kompetencji: projektowanie od pytań wstecz

Zacznij od pytań, na które system musi odpowiedzieć – „Które fundusze Vanguard ETF śledzą amerykańskie indeksy akcji?” – a następnie określ typy, właściwości i ograniczenia. Dzięki temu ontologie są powiązane z praktycznym zastosowaniem, a nie z filozoficzną kompletnością.

Praktyczny proces tworzenia ontologii

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

Iteruj: cele i pytania → model koncepcyjny → formalna ontologia → wypełnianie grafu → walidacja → zapytania/rozumowanie → poprawki.

Szkic koncepcyjny:

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

Przykład zapytania w formie SPARQL:

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

Napomnienie o warstwowym układzie:

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?

Czego LLM mogą zautomatyzować – a czego nie powinny decydować same

Modele pomagają w tworzeniu etykiet, proponują właściwości oraz sugestie dotyczące pytań sprawdzających kompetencje. Nie powinny jednak samodzielnie kontrolować zasad zarządzania: ostateczne systemy typów, kardynalność oraz ograniczenia regulacyjne wymagają ludzkich decydentów i testów.

Gdzie ontologia pomaga GraphRAG

1. Dekompozycja zapytania

Określone relacje informują planerów, które kroki są istotne.

2. Rozwiązanie problemu identyfikatorów

Wspólne IRI oraz tabele synonimów pozwalają połączyć „Vanguard” z „The Vanguard Group”.

3. Kontrola pobierania danych

Anchory i filtry krawędzi są skuteczniejsze od czystego algorytmu kosinusowego, gdy identyfikatory mają znaczenie.

4. Walidacja odpowiedzi

SHACL oraz sprawdzenia oparte na strukturze odrzucają odpowiedzi, które tworzą nielegalne krawędzie.

Pięć zasad projektowania, które warto zachować

Rozdzielaj schemat (ontologię) od danych instancji (grafu).
Projektuj na podstawie konkretnych pytań, a nie modnych terminów.
Wolij małe, sprawdzalne ograniczenia zamiast monolitycznych aksjomatów.
Waliduj podczas zapisu; używaj rozumowania tam, gdzie jest to opłacalne.
Traktuj pomoc od LLM jako wsparcie przy opracowywaniu tekstów pod nadzorem człowieka.

Wniosek

Ontologie to umowy, które można sprawdzić za pomocą maszyn. RDF przechowuje fakty; RDFS i OWL dodają strukturę oraz możliwości wnioskowania; SHACL zapewnia jakość instancji; GraphRAG wykorzystuje te wyniki jako bezpieczniejszy model niż same wektory. Przykład VOO jest celowo prosty: jeśli trzy zdania mogą obejmować pięć warstw, to realny katalog produktów również może – gdy tylko pojawią się pytania dotyczące kompetencji oraz osoby odpowiedzialne.

Zachowuj jedenstronicowy rejestr decyzji dla każdej głównej klasy i właściwości: dlaczego istnieje, do jakiego pytania o kompetencję służy oraz jaka forma SHACL go chroni. Polityki IRI wersjonują się w taki sam sposób, jak wersjonowanie tras w API; przemianowanie nazw bez przekierowań psuje każde połączenie GraphRAG poniżej w łańcuchu. Gdy narzędzia do wydobywania danych proponują nowe krawędzie, wymagaj określonej formy lub wyraźnego grafu „bez ograniczeń”, aby hałaśliwe wyniki modeli językowych nie zatruwały zarządzanego magazynu danych. Oceniaj wartość ontologii na podstawie stopnia pokrycia pytań i wskaźnika wykrywania błędów, a nie liczby aksjomatów. Wreszcie łącz każdą produkcję GraphRAG z zestawem przykładowych danych obejmującymi trójki prawidłowe i nieprawidłowe, aby proces CI zawodził w przypadku, gdy „przydatna” modyfikacja schematu po cichu rozszerza zakres domeny i umożliwia złym menedżerom ponowne przypisywanie środków.

Dokumentuj pytania o kompetencje obok przykładowych danych SPARQL, aby modyfikacje schematu nie odbiegały od zapytań, na które produkcja GraphRAG nadal musi odpowiadać.

Zapisz pytania dotyczące umiejętności obok konfiguracji SPARQL, aby edycje schematu nie odbiegały od zapytań, na które system GraphRAG musi nadal odpowiadać w środowisku produkcyjnym.

Zapisz pytania dotyczące umiejętności obok konfiguracji SPARQL, aby edycje schematu nie odbiegały od zapytań, na które system GraphRAG musi nadal odpowiadać.

Zapisz pytania dotyczące umiejętności obok konfiguracji SPARQL, aby edytacje schematu nie odbiegały od zapytań, na które system GraphRAG musi nadal odpowiadać.

Zapisz pytania dotyczące umiejętności obok konfiguracji SPARQL, aby edycje schematu nie odbiegały od zapytań, na które system GraphRAG musi nadal odpowiadać.

Literatura pokrewna

SHACL TDD dla agentów GraphRAG: Jedna reguła górnej granicy executive, która zatrzymuje złe działania — Zapisz politykę z górną granicą odpowiedzialności na poziomie 30% w formacie SHACL, udowodnij jej poprawność za pomocą pytest i zobacz, jak firewall oparty na ontologii zatrzymuje agenta podczas demonstracji umowy o wartości 2,3 mln dolarów.
GraphRAG z rozumieniem ontologii: Gdy wektory wymagają tipowanych relacji — Jak ankiety identyfikatorów, kontrakty ontologiczne, fuzja rankingu oraz mechanizmy cytuj-albo-odrzuć naprawiają błędy RAG w przypadku CVE, wieloetapowej własności oraz niewypowiedzianych faktów grafowych.

Wszystkie artykuły Wyślij brief