Главная / Статьи / 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. Разные системы используют разные термины

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

Проблема 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 и проверки, основанные на структуре данных, отклоняют ответы, содержащие недопустимые ребра.

Пять принципов проектирования, которые стоит соблюдать

Разделяйте схему (онтологию) от данных экземпляров (графа).
Проектируйте, исходя из конкретных задач, а не из модных терминов.
Даёте предпочтение небольшим, проверяемым ограничениям перед монолитными аксиомами.
Проверяйте данные при записи; используйте логические рассуждения там, где это оправдано.
Рассматривайте помощь больших языковых моделей как средство для разработки под человеческим контролем.

Заключение

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

Ведите одностраничный журнал решений для каждого основного класса и свойства: указывайте, зачем он существует, какому вопросу компетентности он отвечает и какая форма SHACL его защищает. Политики версий IRI работают аналогично версированию маршрутов в API; переименование без перенаправлений нарушает все последующие соединения GraphRAG. Когда инструменты извлечения предлагают новые ребра, требуйте наличия определенной формы или явно указанной «неконтролируемой» сети песочницы, чтобы шумный вывод больших языковых моделей не повредил управляемый хранилище. Оценивайте ценность онтологии по покрытию вопросов и коэффициенту обнаружения ошибок при верификации, а не по количеству аксиом. Наконец, сопоставляйте каждую рабочую реализацию GraphRAG с набором фикстур, содержащим законные и незаконные тройки данных, чтобы тесты CI срабатывали в случае, когда «полезная» правка схемы тайно расширяет домен/диапазон и позволяет неквалифицированным менеджерам снова привязывать к фондам данные.

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

Опишите вопросы, проверяющие уровень компетентности, рядом с конфигурациями SPARQL, чтобы изменения схемы не отклонялись от запросов, на которые система GraphRAG по-прежнему должна отвечать.

Опишите вопросы, связанные с компетентностью, рядом с конфигурациями SPARQL, чтобы изменения схемы не отклонялись от запросов, на которые система GraphRAG по-прежнему должна отвечать.

Все статьи Прислать бриф