Головна / Статті / RDF у GraphRAG: практичні шари онтологій із прикладами VOO

ontology rdf owl shacl graphrag knowledge-graph

RDF у GraphRAG: практичні шари онтологій із прикладами VOO

Від IRI та тріплів через RDFS, OWL та SHACL — коли онтології кращі за таблиці та як вони підтримують GraphRAG.

2162 слів

Онтологія звучить містично; ідея ж проста. Це чітка домовленість щодо певної сфери: які види об’єктів існують, які зв’язки є допустимими, яких правил мають дотримуватися ці зв’язки та що машина може вивести з наявних фактів. Класична фраза Грубера — «чітке формулювання концептуалізації» — означає просто опис, придатний для читання машиною, про те, як команда вирішила зрозуміти певну частину світу.

Допоможе приклад: Vanguard S&P 500 ETF (VOO). У публічних матеріалах зазначається, що VOO має на меті відстежувати індекс S&P 500. Система знань повинна розуміти принаймні наступне:

Vanguard S&P 500 ETF — це ETF, який керується компанією Vanguard. Він відстежує індекс S&P 500.

Ці три речення вже охоплюють усі основні аспекти.

Онтологія та граф знань — це не одне й те саме

Онтологія визначає правила світу. Граф знань містить факти про цей світ.

Онтологія може оголосити ETF та AssetManager як типи, managedBy як зв’язок від ETF до менеджера, а tracksIndex — як зв’язок від ETF до індексу. Потім граф зберігає екземпляри: VOO є ETF; VOO managedBy Vanguard; VOO tracksIndex S&P500Index.

Уявіть собі проектування настільної гри та поточне становище фігур на дошці. Твердження „онтологія ≈ схема, граф знань ≈ дані“ є корисною скороченою формулою — хоча онтології можуть кодувати більш складну логіку, ніж звичайні схеми баз даних.

Чи завжди потрібна онтологія?

Ні. Пошук за точними ключами у кількох полях може здійснюватися в таблицях або JSON. Робота з онтологіями вимагає розробки, керування, перевірки та підтримки. Вона виправдовує себе, коли з’являються такі проблеми:

Проблема 1. Різні системи використовують різні терміни

fund provider, asset manager та management company можуть означати одну й ту саму концепцію. Онтологія обирає основний термін та прив’язує аліаси.

Проблема 2. Користувачі ставлять запитання, які вимагають визначення зв’язків

Запитання на кшталт „Які ETF, якими керує Vanguard, відстежують індекс американських акцій?“ потребує багатоетапного пошуку, а не простого знаходження за ключовим словом.

Проблема 3. Системі потрібно виявляти недійсні дані

Якщо managedBy має вказувати на організацію, тоді VOO managedBy John Smith має завершитися невдачею — навіть якщо Джон є менеджером портфеля. У регульованих галузях одна помилка може підірвати дотримання правил та точність відповідей ШІ; обмеження онтології виступають у ролі захисних механізмів.

Проблема 4. Система має отримувати факти, які ніколи не зберігалися безпосередньо

Міркування на основі підкласів та зворотних властивостей дозволяють визначити неявні типи та зворотні посилання.

Проблема 5. ШІ потребує надійної карти домену

Моделі створюють логічну структуру; онтологія надає перевірену карту для розкладання, обґрунтування та верифікації — особливо у поєднанні з GraphRAG.

Один приклад, п’ять технологічних шарів

Історія VOO охоплює п’ять шарів: ідентифікатори, трипли RDF, схему RDFS, семантику OWL та верифікацію SHACL.

Шар 1: ідентифікатори та простори імен

Стабільні IRI запобігають зіткненням імен. Менеджер може мати таку назву:

https://example.org/finance/Vanguard

Префікси забезпечують читабельність файлів:

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

Це дозволяє розширювати локальні назви, такі як:

fin:Vanguard

Рівень 2: RDF представляє факти у вигляді трійок

Кожне твердження має форму суб’єкт–предикат–об’єкт:

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

Формат Turtle:

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

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

JSON-LD може передавати ту саму структуру даних для веб-систем:

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

Рівень 3: RDFS вводить базову схему

RDFS додає класи, властивості, область/діапазон та посилання на підкласи. Проста таксономія продуктів:

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

Оголошення ETF у межах цієї структури:

FinancialProduct
└── Fund
    └── ETF

Рівень 4: OWL додає більш складну семантику

OWL дозволяє визначати обернені зв’язки, кардинальність та неперетинання. Якщо managedBy є оберненим до manages, зберігання одного напрямку може означати інший:

fin:VOO fin:managedBy fin:Vanguard .

Скетч оберненого зв’язку:

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

Людське розуміння наслідків:

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

Стверджуваний факт:

fin:VOO fin:managedBy fin:Vanguard .

Виведений зворотний висновок:

fin:Vanguard fin:manages fin:VOO .

Рівень 5: SHACL перевіряє дані графа

Форми виявляють помилки екземплярів, які важливі для авторів онтологій у продакшені. Валідний опис 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
    ] .

Компактний валідний екземпляр:

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

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

Невалідний тип менеджера має призводити до невдачі перевірки:

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

fin:Alice a fin:PortfolioManager .

Як виведення створює нові знання

Ланцюги підкласів допомагають піднімати екземпляри вгору по дереву:

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

Від вузького твердження про тип:

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

Механізми міркувань можуть дійти висновків щодо ширших типів:

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

Виведення заповнює прогалини; SHACL все одно захищає те, що пишуть люди чи засоби вилучення даних.

Питання компетентності: проектування, починаючи з питань

Почніть з питань, на які має відповісти система — «Які ETF Vanguard відстежують індекси акцій США?» — а потім визначте типи, властивості та обмеження. Це забезпечує прив’язку онтологій до практичного використання, а не до філософської досконалості.

Практичний процес розробки онтологій

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

Ітеруйте: цілі та питання → концептуальна модель → формальна онтологія → заповнення графа → перевірка → запити/міркування → корекція.

Концептуальний ескіз:

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

Приклад запиту у форматі SPARQL:

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

Нагадування про шарову структуру:

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?

Що можуть автоматизувати ШИМ — і що вони не повинні вирішувати самостійно

Моделі допомагають створювати мітки, пропонувати властивості та формулювати запитання щодо компетентності. Вони не повинні бездіяльно керувати процесами: остаточні системи типів, кардинальність та регуляторні обмеження потребують людського керування та перевірок.

Де онтології допомагають GraphRAG

1. Розкладання запиту

Типовані взаємозв’язки повідомляють планувальникам, які кроки є значущими.

2. Резолюція ентитетів

Спільні IRI та карти синонімів усувають розбіжності між “Vanguard” та “The Vanguard Group”.

3. Контроль отримання даних

Анкори та фільтри країв є ефективнішими за чистий косинус, коли важливі ідентифікатори.

4. Перевірка відповідей

SHACL та перевірки, отримані з форми, відхиляють відповіді, які створюють незаконні краї.

П’ять принципів проектування, які варто зберегти

Розділяйте схему (онтологію) від даних екземплярів (графа).
Проектуйте на основі конкретних запитань щодо компетенцій, а не модних термінів.
Віддавайте перевагу невеликим, перевірюваним обмеженням перед монолітичними аксіомами.
Перевіряйте під час запису; використовуйте логіку там, де це має сенс.
Розглядайте допомогу від LLM як підтримку у розробці під керуванням людини.

Висновок

Онтології — це угоди, які можна перевірити за допомогою машин. RDF зберігає факти; RDFS та OWL додають структуру та можливості висновків; SHACL забезпечує якість екземплярів; GraphRAG використовує отримані результати як більш надійну карту порівняно з векторами окремо. Приклад VOO навмисно є простим: якщо три речення можуть охоплювати п’ять шарів, то справжній каталог продуктів також може це робити — як тільки будуть визначені питання компетентності та їхні власники.

Тримайте щоденник рішень обсягом у одну сторінку для кожного основного класу та властивості: чому вони існують, яке питання компетентності вони вирішують та яка форма SHACL їх захищає. Політики версіонування IRI працюють так само, як версіонування маршрутів у API; перейменування без перенаправлень руйнує всі подальші з’єднання GraphRAG. Коли інструменти вилучення даних пропонують нові краї, необхідно вказати форму або чітко визначити граф у сandbox-режимі як „без обмежень“, щоб шумний вихід LLM не забруднював керований сховище даних. Оцінюйте цінність онтології за рівнем покриття запитань та часткою виявлення помилок під час верифікації, а не за кількістю аксіом. Нарешті, до кожної реальної реалізації GraphRAG додавайте набір фікстур із законними та незаконними тріплами, щоб процес CI завершувався з помилкою, якщо „корисна“ зміна схеми тихо розширює домен/діапазон та дозволяє поганим менеджерам знову приєднуватися до фондів.

Документуйте питання компетентності разом із фікстурами SPARQL, щоб зміни схеми не відхилялися від запитань, на які GraphRAG все одно має відповідати у реальних умовах.

Документуйте запитання щодо компетентності поруч із конфігураціями SPARQL, щоб зміни схеми не відхилялися від запитів, на які система GraphRAG все одно мусить відповісти.

Усі статті Надіслати бриф