Inicio / Artículos / RDF a GraphRAG: Capas ontológicas prácticas con ejemplos de VOO

ontology rdf owl shacl graphrag knowledge-graph

RDF a GraphRAG: Capas ontológicas prácticas con ejemplos de VOO

Desde IRIs y triples hasta RDFS, OWL y SHACL: cuando las ontologías superan a las tablas y cómo estabilizan GraphRAG.

2162 palabras

Una ontología suena mística; la idea es sencilla. Se trata de un acuerdo explícito sobre un dominio: qué tipos de cosas existen, qué relaciones son válidas, qué reglas deben seguir esos vínculos y qué puede inferir una máquina a partir de los hechos ya disponibles. La frase clásica de Gruber —“una especificación explícita de una conceptualización”— simplemente significa una descripción legible por máquinas que muestra cómo un equipo eligió comprender una parte del mundo.

Un ejemplo práctico ayuda: el Vanguard S&P 500 ETF (VOO). Los materiales públicos indican que VOO busca seguir el índice S&P 500. Un sistema de conocimiento debería entender al menos lo siguiente:

El Vanguard S&P 500 ETF es, en esencia, un ETF. Es gestionado por Vanguard y sigue el índice S&P 500.

Esas tres oraciones ya abarcan cada capa importante relacionada.

La ontología y el grafo de conocimiento no son lo mismo

La ontología define las reglas del mundo. El grafo de conocimiento almacena hechos sobre ese mundo.

La ontología podría declarar ETF y AssetManager como tipos, managedBy como un enlace desde el ETF hasta el administrador, y tracksIndex como un enlace desde el ETF hasta el índice. Luego, el grafo almacena las instancias: VOO es un ETF; VOO managedBy Vanguard; VOO tracksIndex S&P500Index.

Pensemos en el diseño de juegos de mesa frente a la situación actual en el tablero. Decir “ontología ≈ esquema, grafo de conocimiento ≈ datos” es un atajo útil, aunque las ontologías pueden codificar una lógica más rica que los esquemas típicos de bases de datos.

¿Siempre se necesita una ontología?

No. Las búsquedas por clave exacta en unos pocos campos pueden realizarse en tablas o JSON. El trabajo con ontologías implica costos de diseño, gobernanza, validación y mantenimiento. Vale la pena cuando surgen problemas como estos:

Problema 1. Los diferentes sistemas utilizan palabras distintas

fund provider, asset manager y management company pueden referirse al mismo concepto. Una ontología elige un término preferido y mapea los alias.

Problema 2. Los usuarios hacen preguntas que requieren relaciones

“¿Qué ETFs gestionados por Vanguard siguen un índice bursátil de EE. UU.” necesita un camino multietapa, no un resultado por palabra clave.

Problema 3. El sistema debe detectar datos inválidos

Si managedBy debe apuntar a una organización, VOO managedBy John Smith debería fallar, incluso si John es un gestor de carteras. En industrias reguladas, un solo error puede socavar el cumplimiento normativo y las respuestas generadas por IA; las restricciones de la ontología actúan como límites de seguridad.

Problema 4. El sistema debe derivar hechos que nunca se almacenaron directamente

El razonamiento basado en subclases y propiedades inversas puede hacer realidad tipos implícitos y enlaces inversos.

Problema 5. Un LLM necesita un mapa fiable del dominio

Los modelos crean estructuras fluidas; una ontología proporciona un mapa verificado para la descomposición, el anclaje y la validación, especialmente en combinación con GraphRAG.

Un ejemplo, cinco capas tecnológicas

La historia del VOO abarca cinco capas: identificadores, triples RDF, esquema RDFS, semántica OWL y validación SHACL.

Capa 1: identificadores y espacios de nombres

Los IRIs estables evitan las colisiones de nombres. Un administrador podría llamarse:

https://example.org/finance/Vanguard

Los prefijos mantienen los archivos legibles:

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

Lo cual expande los nombres locales como:

fin:Vanguard

Nivel 2: RDF representa los hechos como triples

Cada declaración sigue la estructura sujeto–predicado–objeto:

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 puede transportar el mismo grafo para stacks web:

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

Nivel 3: RDFS introduce un esquema básico

RDFS agrega clases, propiedades, dominio/rango y enlaces de subclase. Una taxonomía simple de productos:

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

Declarar un ETF bajo ese árbol:

FinancialProduct
└── Fund
    └── ETF

Nivel 4: OWL añade semántica más rica

OWL puede especificar inversos, cardinalidad y disyunción. Si managedBy es el inverso de manages, almacenar una dirección puede implicar la otra:

fin:VOO fin:managedBy fin:Vanguard .

Boceto inverso:

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

Lectura humana de la implicación:

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

Hecho afirmado:

fin:VOO fin:managedBy fin:Vanguard .

Inferencia inversa:

fin:Vanguard fin:manages fin:VOO .

Nivel 5: SHACL valida los datos del grafo

Las formas detectan errores en las instancias que los autores de ontologías consideran importantes en entornos de producción. Una descripción de ETF válida:

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

Instancia válida y compacta:

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

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

Un tipo de administrador inválido debería hacer que fallara la validación:

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

fin:Alice a fin:PortfolioManager .

Cómo la inferencia crea nuevo conocimiento

Las cadenas de subclases permiten ascender en el árbol jerárquico con las instancias:

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

A partir de una afirmación de tipo específica:

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

Los razonadores pueden concluir tipos más amplios:

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

La inferencia llena las lagunas; SHACL sigue protegiendo lo que escriben los humanos o los extractores.

Preguntas sobre competencias: diseñar desde las preguntas hacia atrás

Comience con las preguntas que el sistema debe responder —“¿Qué ETFs de Vanguard siguen índices bursátiles estadounidenses?”— y luego decida los tipos, propiedades y restricciones. Esto mantiene las ontologías vinculadas al uso práctico, no a una completitud filosófica.

Un flujo de trabajo práctico para el desarrollo de ontologías

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

Itere: objetivos y preguntas → modelo conceptual → ontología formal → población del grafo → validación → consulta/razonamiento → revisión.

Boceto conceptual:

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

Ejemplo de consulta en formato SPARQL:

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

Recordatorio sobre la estructura en capas:

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?

Qué pueden automatizar los LLMs — y qué no deben decidir solos

Los modelos ayudan a redactar etiquetas, sugerir propiedades y proponer preguntas relacionadas con las competencias. No deben asumir de forma silenciosa la responsabilidad de la gobernanza: los sistemas de tipos finales, las cardinalidades y las restricciones regulatorias requieren responsables humanos y pruebas correspondientes.

Dónde la ontología ayuda a GraphRAG

1. Descomposición de consultas

Las relaciones tipadas indican a los planificadores qué pasos son significativos.

2. Resolución de entidades

Los IRIs compartidos y los mapas de sinónimos unifican “Vanguard” y “The Vanguard Group”.

3. Control de recuperación

Los anclajes y filtros de aristas superan al coseno puro cuando los identificadores son importantes.

4. Validación de respuestas

SHACL y las verificaciones derivadas de la estructura rechazan respuestas que crean aristas ilegales.

Cinco principios de diseño que vale la pena mantener

Separar el esquema (ontología) de los datos de instancia (gráfico).
Diseñar a partir de preguntas sobre competencias, no de modas del sector.
Preferir restricciones pequeñas y verificables sobre axiomas monolíticos.
Validar al escribir; razonar donde realmente sea necesario.
Tratar la ayuda de los LLM como asistencia en la redacción bajo supervisión humana.

Conclusión

Las ontologías son acuerdos que pueden verificarse automáticamente por máquinas. RDF almacena hechos; RDFS y OWL añaden estructura e inferencia; SHACL garantiza la calidad de las instancias; GraphRAG utiliza el resultado como un mapa más seguro que los vectores por sí solos. El ejemplo de VOO es pequeño a propósito: si tres oraciones pueden representar cinco capas, un catálogo de productos real también puede hacerlo, una vez que existan las preguntas relacionadas con las competencias y sus responsables.

Mantenga un registro de decisiones de una página para cada clase y propiedad importante: por qué existe, a qué pregunta de competencia responde y qué forma SHACL la protege. Las políticas IRI versionan de la misma manera que las APIs versionan las rutas; cambiar el nombre sin redirecciones rompe todas las uniones GraphRAG posteriores. Cuando los extractores propongan nuevos enlaces, exija una forma específica o un grafo de entorno “sin restricciones” explícito para que las salidas ruidosas de los LLM no dañen el almacenamiento regulado. Mida el valor de la ontología mediante la cobertura de preguntas y la tasa de detección de errores en la validación, no mediante el conteo de axiomas. Finalmente, associe cada implementación en producción de GraphRAG con un conjunto de datos fijos que contenga triples legales e ilegales, de modo que las pruebas de integración fallen cuando una edición de esquema “útil” amplíe silenciosamente el dominio/rango y permita que gerentes inadecuados vuelvan a vincular fondos.

Documente las preguntas de competencia junto con los datos fijos SPARQL para que las ediciones de esquema no se desvíen de lo que GraphRAG en producción debe seguir respondiendo.

Documente las preguntas de competencia junto a los elementos SPARQL para que las modificaciones en el esquema no se desvíen de las consultas a las que GraphRAG debe seguir respondiendo en producción.

Lecturas relacionadas

SHACL TDD para agentes GraphRAG: Una regla límite ejecutiva que detiene acciones perjudiciales — Codifique una política de aprobación ejecutiva con límite de responsabilidad del 30% en formato SHACL, pruébela con pytest y observe cómo un firewall de ontología detiene al agente en una demostración de contrato por 2,3 millones de dólares.
GraphRAG con conciencia ontológica: Cuando los vectores necesitan relaciones tipadas — Cómo los anclajes de identificadores, los contratos ontológicos, la fusión de rangos y las puertas de citar o rechazar solucionan los fallos en RAG relacionados con CVEs, la propiedad multi-hop y hechos gráficos no expresados verbalmente.

Todos los artículos Enviar el brief