Ontologías y knowledge graphs en LLMOps: la nomenclatura linneana que sostiene las seis etapas del pipeline

Wed, 03 Jun 2026 03:30:00 +0200

Este post atraviesa las seis etapas del pipeline LLMOps desde una perspectiva transversal: la nomenclatura común que hace que las etapas compartan vocabulario. Conecta directamente con RAG corpus curation (el corpus se cura contra una ontología), embeddings (la ontología enriquece el embedding con metadatos tipados), retrieval híbrido (el KG es un cuarto canal junto a denso/esparso/multi-vector), evals (los golden sets se estratifican por clase ontológica), structured output (las JSON Schemas derivan de OWL/SHACL), y los tres marcos de ISO 42001, ENS y EU AI Act (cada uno es una ontología de control).

TL;DR

La conversación de ontologías y LLMs ha oscilado entre dos posturas igualmente equivocadas en los últimos tres años: o “los LLMs ya extraen conocimiento solos, las ontologías son del siglo pasado”, o “todo el RAG hay que tirarlo y construir un knowledge graph encima”. La realidad operativa de mid-2026 es más sobria: la ontología no es un sustituto del RAG sino su nomenclatura común, sin la cual las seis etapas del pipeline LLMOps trabajan con vocabularios distintos sin saberlo. El corpus se cura sin saber qué clases de entidad existen; los embeddings perforan documentos sin enriquecerse con metadatos tipados; los evals reportan una accuracy global que oculta gaps enteros de clase; el guardrail bloquea por listas de palabras en vez de por clasificación formal; el incident response agrupa mal porque cada alerta nombra “el activo afectado” a su manera; el compliance no puede mapear sus controles porque ENS, ISO 42001 y EU AI Act son tres ontologías y el sistema no tiene ninguna. Este post desmonta qué es una ontología en términos prácticos —TBox y ABox, RDF y SPARQL, los cuatro perfiles de OWL 2 (EL para terminologías enormes tipo SNOMED, QL para OBDA, RL para reasoning con reglas, DL para el full description-logic), SHACL para validación con shapes, SKOS para tesauros, JSON-LD como serialización viable—, recorre las seis etapas LLMOps mostrando dónde la ontología cambia la operación, repasa el campo GraphRAG en 2026 con datos verificables (Microsoft GraphRAG v2 oct-2025, LightRAG dual-level y actualizaciones incrementales, HippoRAG 2 con Personalized PageRank, KAG sobre OpenSPG ontology-grounded), inventaria las ontologías verticales realmente desplegadas en producción (FIBO, SNOMED CT, schema.org, IEC 81346, GS1, Wikidata, ENS Anexo I-II del RD 311/2022, EU AI Act Anexo III), fija el stack open source on-prem viable con las salvedades de licencia (Neo4j Community es GPLv3 con implicaciones AGPL en algunos features, KuzuDB upstream archivado oct-2025, forks bighorn y ryugraph), describe los cinco patrones de integración LLM × ontología y cierra con siete trampas operativas. La regla del pulgar: el knowledge graph no es la respuesta; la nomenclatura formalizada compartida sí.

La analogía: Carl Linneo, 1735

En 1735 publicó Carl von Linné la primera edición de Systema Naturae. Antes de Linneo, los naturalistas europeos tenían un problema operativo: la misma especie podía aparecer en cinco tratados con cinco nombres latinos distintos —cada uno una descripción polinómica del tipo “Felis cauda elongata cum maculis nigris in dorso et lateribus”— y dos naturalistas que se carteaban tardaban meses en darse cuenta de que estaban discutiendo del mismo animal. La biología era un campo de ruido lexicográfico: imposible comparar observaciones, imposible verificar replicación, imposible construir teoría acumulativa.

Linneo no descubrió biología. Lo que descubrió fue que el campo necesitaba una nomenclatura común con tres propiedades:

Jerarquía estricta. Reino → Filo → Clase → Orden → Familia → Género → Especie. Cada nivel es una clase con subclases bien definidas. Una propiedad de Felis (la dieta carnívora) se hereda automáticamente a Felis catus y a Felis silvestris sin redeclararse.
Naming inequívoco. Cada especie tiene un único nombre binomial (Genus + epíteto específico) y un único type specimen anclado en un museo. “Felis silvestris” significa exactamente lo mismo en Madrid, Estocolmo y Calcuta.
Reglas de prioridad. Si dos botánicos publican el mismo género con nombres distintos, gana el primero que lo registró válidamente. La convención de naming no se debate en cada paper: hay un metanivel de gobernanza explícita.

Tras Linneo, la biología comparada se vuelve posible. Mendel puede hablar de Pisum sativum y un botánico polaco sabe exactamente qué planta cultivar para replicarlo. Darwin puede comparar pinzones de las Galápagos con pinzones de otras islas sin confusión sobre qué es “el mismo tipo de pájaro”. El cambio no es de instrumentación —el microscopio existía desde Hooke (1665)—. El cambio es de vocabulario formal compartido.

Una ontología en computación es exactamente esto:

Linneo (1735)	Ontología (2026)
Jerarquía Reino → … → Especie	Jerarquía de clases (`Person ⊑ Agent ⊑ Thing`) — el TBox
Type specimen en museo	Instancia anclada con IRI única — el ABox
Nombre binomial	IRI / URI única por concepto
Reglas de prioridad	Axiomas de la ontología + gobernanza
“Felis silvestris” significa lo mismo en Madrid y Estocolmo	`<http://example.org/ont/Felis_silvestris>` significa lo mismo en cualquier sistema

Cuando hoy un LLMOps team dice “nuestro corpus está curado, los embeddings son bge-m3 y los evals miden recall@5”, pero la pregunta “¿qué proporción de queries sobre activos categoría alta del ENS están bien cubiertas?” no tiene respuesta — porque en el sistema no existe una clase formal “activo categoría alta ENS”—, el problema es pre-Linneo: el campo todavía no se ha dotado de la nomenclatura que hace comparable cada etapa.

La ontología atraviesa las seis etapas como vocabulario compartido. Sin ella, cada etapa tiene su propia definición de "cliente", "documento sensible" o "incidente".

Qué es una ontología en términos operativos

La palabra “ontología” tiene un parentesco filosófico ineludible —Aristóteles, las categorías de Kant, Quine— que confunde a la primera. En infraestructura LLM da igual: una ontología es un grafo dirigido con tipos, descrito formalmente, sobre el que se puede razonar, validar y consultar. Lo importante son seis conceptos prácticos.

TBox y ABox

La distinción que se usa todos los días. La TBox (de terminology) es el esquema: clases, jerarquía de subclases, propiedades, axiomas. La ABox (de assertions) son las instancias.

# TBox — esquema
:Person rdfs:subClassOf :Agent .
:Employee rdfs:subClassOf :Person .
:worksFor rdfs:domain :Employee ; rdfs:range :Organization .

# ABox — instancias
:alice a :Employee .
:alice :worksFor :acme .

Un reasoner verifica que la ABox es consistente con la TBox: si declaras :alice :worksFor :acme pero :alice no es :Employee, el reasoner detecta la inconsistencia. Esa es la palanca: validación automática del conocimiento que ningún sistema basado solo en embeddings densos puede dar.

RDF y la unidad de información

La unidad atómica del Semantic Web es la tripla RDF (sujeto, predicado, objeto). Todo dato se expresa como una colección de triplas. Esto da la propiedad operativa más útil del paradigma: dos grafos se mergean trivialmente uniéndolos. Si tu sistema indexa el corpus médico con SNOMED CT y el corpus legal con FIBO, ambos en RDF, fusionarlos para una query que cruce los dos dominios es literalmente g1 ∪ g2. En propiedad-graph (Neo4j) esto requiere más cirugía.

Los cuatro perfiles de OWL 2

La gente nueva al campo asume que OWL es una cosa. Son cuatro perfiles con trade-offs distintos, todos W3C Recommendation:

Perfil	Expresividad	Coste de razonamiento	Casos de uso
OWL 2 EL	restringido (subclase, intersección, propiedades)	polinomial en tamaño de ontología	terminologías enormes — SNOMED CT (350k+ conceptos)
OWL 2 QL	subset que mapea a SQL/UCQ	LOGSPACE en datos	OBDA (ontology-based data access) sobre DBs relacionales
OWL 2 RL	subset implementable como reglas (Datalog)	escalable, sin DL completo	reasoning en producción con motores de reglas
OWL 2 DL	SROIQ completo (la “full ontology”)	decidible pero NEXPTIME en peor caso	ontologías académicas, validación profunda

Regla operativa: si tu equipo no va a leer un paper de description logics todos los meses, no uses OWL 2 DL. Casi todo el valor está en EL/QL/RL. Para terminologías médicas grandes, EL. Para razonar sobre datos relacionales existentes, QL. Para reglas de negocio, RL.

SHACL — la validación que sí se opera

OWL hace reasoning (“dadas estas axiomas, ¿qué se puede deducir?”). SHACL hace validación (“dado este grafo concreto, ¿cumple estos shapes?”). En producción, SHACL gana porque su semántica es más cercana al chequeo de tipos que el desarrollador entiende:

:PersonShape a sh:NodeShape ;
 sh:targetClass :Person ;
 sh:property [
 sh:path :nombre ;
 sh:minCount 1 ;
 sh:datatype xsd:string ;
 ] ,
 [
 sh:path :nif ;
 sh:pattern "^[0-9]{8}[A-Z]$" ;
 ] .

Validar un grafo entrante contra este shape detecta :alice :nombre 42 (tipo incorrecto), :alice :nif "12345678X9" (formato incorrecto) o :alice a :Person sin nombre (min count violado). Es JSON Schema para grafos, conceptualmente. La spec SHACL 1.2 está en draft W3C 2025; SHACL 1.0 lleva en producción desde 2017.

SKOS — el tesauro ligero

No todo conocimiento merece OWL. Para vocabularios controlados —tesauros, taxonomías, glosarios— hay SKOS:

:Mamifero a skos:Concept ;
 skos:prefLabel "Mamífero"@es , "Mammal"@en ;
 skos:broader :Animal ;
 skos:narrower :Felino , :Canido .

SKOS no expresa axiomas formales —skos:broader no es rdfs:subClassOf—. Sirve para clasificar contenidos sin pretensión de razonamiento, que es el 80% de los casos corporativos. Empieza por SKOS: la mayoría de “ontologías” empresariales son en realidad tesauros que se sobreelevaron a OWL por moda y arrastran complejidad innecesaria.

JSON-LD y SPARQL — las superficies prácticas

JSON-LD 1.1 (W3C Rec 2020) es la serialización que sí se usa en sistemas reales: JSON normal con un campo @context que mapea las claves a IRIs. El microformato de schema.org en páginas web es JSON-LD. Para un equipo LLMOps, JSON-LD es el formato natural de intercambio con tools y APIs.

SPARQL 1.1 (W3C Rec 2013; 1.2 en draft 2025) es SQL para grafos:

SELECT ?empleado ?empresa WHERE {
 ?empleado a :Employee ;
 :worksFor ?empresa ;
 :pais "España" .
 ?empresa :sector "fintech" .
}

Toda triple store moderna lo habla. Los Federation features permiten que una sola query toque varios endpoints —SNOMED CT + ontología corporativa propia—.

Por qué importa para un LLM en producción

La promesa romántica del año 2023-2024 era: “ahora que tenemos LLMs, no necesitamos ontologías; el modelo entiende el lenguaje natural y extrae conocimiento”. La realidad operativa de mid-2026 es más matizada y descansa sobre cuatro observaciones que cualquiera con un RAG en producción ha hecho ya:

El LLM tiene memoria semántica pero no esquema declarado. Si preguntas “¿qué entidades de tipo Person aparecen en este documento?”, responde algo razonable. Si preguntas “¿qué personas aparecen y cuáles son empleados del cliente?”, la respuesta depende de cómo el modelo interpreta “empleado del cliente” en ese contexto. Sin un esquema externo que diga “Employee es subclase de Person y se relaciona con Organization vía worksFor”, la coherencia entre dos llamadas al mismo LLM no está garantizada.
La calidad varía por dominio sin que el sistema sepa por qué. Tu RAG tiene una accuracy global del 78% pero falla sistemáticamente en queries sobre instrumentos financieros derivados. Como no tienes una clasificación formal de queries por categoría, el problema es invisible hasta que un cliente se queja.
El compliance exige nomenclatura formal. ENS clasifica activos en cinco dimensiones (Confidencialidad, Integridad, Disponibilidad, Autenticidad, Trazabilidad) con tres niveles cada una. EU AI Act enumera ocho áreas de alto riesgo en Anexo III. Sin un mapeo formal entre tus assets y esas categorías, no puedes auditar lo que no sabes nombrar. El auditor pregunta “¿qué chunks del corpus tocan datos personales especialmente protegidos?” y tu sistema no tiene esa columna.
La interoperabilidad entre componentes exige tipos. Tu retrieval devuelve “chunks relevantes”. Tu reranker los reordena. Tu guardrail filtra los sensibles. Si cada componente tiene su propia definición de qué es un “chunk sensible”, la cadena rompe en cada interface. Una ontología compartida es el contrato de tipos del pipeline.

La consecuencia operativa: la ontología no reemplaza el RAG. Lo tipa. Lo hace auditable, comparable y debuggable. La pregunta correcta no es “¿necesito un knowledge graph?” sino “¿en qué etapas del pipeline gano si introduzco una nomenclatura formal compartida?”.

Las seis etapas LLMOps × ontología

Recorramos las seis etapas del pipeline preguntando qué cambia en cada una cuando hay ontología. Esto es el eje del post: la palanca no es “instalar Neo4j”, es introducir tipos donde antes había texto plano.

Etapa 1 — Data

La curación del corpus se vuelve curación dirigida por ontología:

Cada chunk no es solo “texto + embedding”, lleva además chunk:tipoDocumento, chunk:nivelClasificacion, chunk:categoriaENS, chunk:contienePII.
Estos tipos vienen de una ontología corporativa explícita, no de strings ad-hoc del data engineer del turno de mañana.
La regla 4 de corpus curation —anti-contaminación— se beneficia: los chunks del golden eval set llevan dataset:goldenEval=true declarado como tripla; cualquier reindexación que filtre por goldenEval=true se vuelve trivial.
El detector de PII deja de ser una expresión regular para volverse un clasificador contra el tesauro categorías de datos personales: identificador, contacto, financiero, salud, biométrico. La columna chunk:pii ya no es booleana sino una lista de categorías SKOS.

# Ingestion con tipado ontológico
chunk = {
 "@context": "https://ontology.fibercli.es/v1/context.jsonld",
 "@id": f"chunk:{uuid4()}",
 "@type": "Chunk",
 "tipoDocumento": "ContratoComercial",
 "nivelClasificacion": "ConfidencialMedio",
 "categoriaENS": ["Disponibilidad-M", "Confidencialidad-A"],
 "contienePII": ["IdentificadorFiscal", "Contacto"],
 "embedding": [...],
 "text": "...",
}

Bajo el contexto JSON-LD, todas esas claves resuelven a IRIs y son consultables vía SPARQL.

Etapa 2 — Train / Adapt

El fine-tuning continuo y el retrain ganan dos palancas:

Datasets estratificados por clase. Cuando el feedback de producción se convierte en dataset de entrenamiento, cada ejemplo viene etiquetado por la clase ontológica del incidente que lo originó. Permite muestrear n ejemplos por clase en vez de n ejemplos globales — corrige los gaps de cobertura del modelo.
Generación sintética guiada por ontología. Para clases con pocos ejemplos en el corpus real, se generan datos sintéticos contra el esquema: “genera 50 preguntas sobre FIBO:DerivativeInstrument que un trader podría hacer”. La salida pasa por structured output validado contra el shape SHACL del schema antes de entrar al dataset.

Etapa 3 — Eval

La capa de evals cambia más que ninguna. Sin ontología, el eval reporta una accuracy global que oculta:

accuracy = 0.78

Con ontología, reporta una matriz de cobertura por clase:

 accuracy n_queries covered_in_corpus
ContratoComercial 0.82 142 si
EmpleadoENS-Alto 0.31 18 parcial
DerivadoFinanciero 0.74 67 si
SOAP_3.0_Endpoint 0.05 9 no

La fila EmpleadoENS-Alto con accuracy 0.31 visibiliza un problema invisible sin estratificación. La fila SOAP_3.0_Endpoint con accuracy 0.05 y covered_in_corpus=no indica que la clase ni siquiera tiene corpus — antes de tocar el modelo hay que tocar la ingestión. La métrica única oculta; la métrica por clase acciona.

Esta es la regla que LLM-as-judge y evals deben implementar siempre que exista una ontología: el golden eval set se etiqueta por clase y todas las métricas se reportan estratificadas.

Etapa 4 — Deploy

En el router de inferencia LLM la ontología habilita:

Semantic routing por clase. Queries que tras una primera clasificación caen bajo FIBO:Securities se enrutan al adapter fine-tuneado en finanzas; queries bajo SNOMED:ClinicalFinding al adapter médico. Sin ontología, este routing se basa en clasificadores ad-hoc o en heurísticas léxicas frágiles.
Tool calling tipado. Las herramientas que el agente puede invocar declaran sus argumentos contra clases de la ontología. El argumento cliente_id no es string; es :ClienteCorporativo. Antes de ejecutar la tool, los argumentos se validan con SHACL. Reduce drásticamente los errores por argumentos mal poblados.
Feature flags con clase. El canary se hace “el nuevo modelo recibe el 10% de las queries de la clase X” en vez de un 10% indiferenciado: aísla el blast radius.

Etapa 5 — Observe

Es donde la ausencia de ontología duele más rápido en operación. Los runbooks de incident response requieren:

Taxonomía de incidentes formal. IncidenteSeguridad ⊑ Incidente, IncidenteIA ⊑ Incidente, FugaDatos ⊑ IncidenteSeguridad. Sin esta taxonomía, los cinco eventos del último mes etiquetados como “model issue”, “data drift”, “pii leak”, “prompt injection” y “hallucination” no son agrupables ni comparables. Keep + Kafka aplican la deduplicación contra esa taxonomía.
Lineage tipado en el KG. La observabilidad GPU + tracing emite spans con atributos. Si esos atributos son tipados contra la ontología (span.input.classification = :ConfidencialMedio), buscar todos los requests que tocaron clase ConfidencialAlto en la última hora es una query SPARQL trivial; sin ontología, es un grep sobre logs no estructurados.

Etapa 6 — Govern

Donde la ontología se hace inevitable. Cada marco regulatorio es una ontología:

ENS RD 311/2022 Anexo I: define cinco dimensiones (C, I, D, A, T) × tres niveles (Bajo, Medio, Alto). Es un esquema de clasificación de activos. Anexo II enumera 73 medidas de control con jerarquía organizativa / operacional / protección. Los controles técnicos ENS mapean cada control a componentes del stack — ese mapeo es una ontología relacional.
ISO 42001 Annex A: enumera controles agrupados (A.5 políticas, A.6 organización interna, A.7 recursos para IA, A.8 evaluación, A.9 operación). El AIMS sobre LLM on-premise los formaliza.
EU AI Act Anexo III: ocho áreas de alto riesgo. Los mapeos del expediente técnico son una traducción de la ontología legal a la ontología técnica del sistema.

Sin una ontología que mapee tu inventario de assets, datasets, modelos y endpoints a las clases de estos tres marcos, el compliance es manual, reactivo y se rompe con cada cambio del stack. Con la ontología, un cambio de modelo dispara automáticamente qué controles se ven afectados.

El campo GraphRAG en 2026

GraphRAG es el nombre genérico de una familia de técnicas que construyen un knowledge graph desde un corpus y lo usan como capa adicional de retrieval complementaria al dense / sparse / multi-vector que vimos en embeddings. La motivación es que algunas queries —“cuáles son los temas dominantes en este corpus”, “qué entidades aparecen conectadas con el cliente X en los últimos seis meses”— no se responden bien por similitud coseno entre vectores.

Microsoft GraphRAG

microsoft/graphrag (julio 2024, v1.0 dic 2024, v2.x oct 2025; cualquier referencia a v3 hay que verificar en GitHub releases antes de citar). Pipeline canónico:

Extracción. Un LLM lee el corpus por chunks y extrae entidades y relaciones — la TBox emerge de los datos en vez de declararse.
Construcción del grafo. Las entidades extraídas se desambiguan, se mergean y se conecta con las relaciones.
Detección de comunidades con el algoritmo de Leiden. El grafo se particiona en comunidades jerárquicas.
Resúmenes por comunidad. Para cada comunidad, el LLM genera un resumen.
Búsqueda local vs global. Local: traversal vecindario para queries sobre entidades específicas. Global: map-reduce sobre resúmenes de comunidades para queries temáticas.

El precio: la construcción del KG cuesta del orden de 5-20× más tokens que un pase de embeddings del mismo corpus. Para un corpus de 1 millón de chunks con embeddings bge-m3 (un día de cómputo en RTX 4090), un GraphRAG puro requiere típicamente 1-3 semanas de compute en LLM-extractor (Qwen2.5-72B o similar). La variante LazyGraphRAG (mid-2025) demora la generación de resúmenes a query-time y reduce el coste de construcción en un orden de magnitud.

LightRAG

HKUDS/LightRAG (HKU, arXiv:2410.05779, octubre 2024, EMNLP 2025). Mejoras prácticas sobre GraphRAG canónico:

Dual-level retrieval. Cada query genera tanto low-level keywords (entidades específicas) como high-level keywords (temas). El sistema busca por ambos y los fusiona. Captura tanto preguntas factuales como temáticas en el mismo pipeline.
Actualizaciones incrementales. Inserción de nuevos chunks sin reconstruir el grafo completo. GraphRAG canónico requiere reconstrucción periódica.
Coste reportado: comparativamente más barato que GraphRAG al servir queries similares.

Es el GraphRAG operacionalmente más razonable cuando el corpus muta.

HippoRAG 2

OSU-NLP-Group, arXiv:2502.14802 (feb 2025; HippoRAG original NeurIPS'24). Inspirado en el modelo de indexación hipocampal de la memoria humana:

Construye un KG abierto y mantiene además los chunks originales.
Para cada query, extrae entidades y ejecuta Personalized PageRank sobre el grafo seeded por esas entidades — el PageRank “marca” los nodos relevantes y, transitivamente, los chunks asociados.
Reportado +7% en tareas de memoria asociativa sobre embedders SOTA, con coste de indexación significativamente menor que GraphRAG, RAPTOR y LightRAG.

Es el GraphRAG más eficiente para corpora donde “qué chunks son relevantes a qué entidades” importa más que “cuál es la estructura semántica del corpus”.

KAG / OpenSPG

Ant Group + OpenKG, arXiv:2409.13731 (sep 2024). Diferencia clave con los anteriores: KAG es ontology-grounded. No deja que el LLM invente la TBox; la TBox la declara el dominio (FIBO, SNOMED, ontología corporativa) y el LLM solo puebla la ABox conforme a ese esquema. Cuatro pilares:

Representación amigable al LLM — el esquema se expone en formato que el LLM puede consumir como contexto.
Índice mutuo entre KG y chunks — cada nodo del KG enlaza a los chunks donde aparece.
Razonamiento lógico-formal híbrido — combina LLM con motor de reglas declarativo.
Alineamiento semántico — desambiguación de entidades contra el catálogo ontológico.

Reportado +19.6% F1 en 2WikiMultiHopQA, +33.5% en HotpotQA sobre RAG baseline. Desplegado en Q&A de e-gobierno y e-salud de Ant en producción.

KAG es el GraphRAG que sí funciona cuando el dominio tiene una ontología estable (finanzas, salud, gobierno). GraphRAG canónico gana cuando el corpus es exploratorio y no existe TBox previa.

Otros del panorama

nano-GraphRAG: port Python ligero de GraphRAG; ideal para prototipos.
Think-on-Graph (ToG) / GraphReader: agentes que planean traversal de hops sobre el KG en vez de retrieval single-shot. Mejores en multi-hop QA.
Neo4j LLM Graph Builder + integración LangChain: el camino de menor resistencia para empresas con Neo4j ya operativo.

Ontologías verticales que sí se usan en producción

Tres ontologías cubren el 90% de casos verticales en mid-2026:

FIBO — Financial Industry Business Ontology

EDM Council + OMG, MIT license, OWL DL. Production release Q1/2026 contiene 2.446 clases distribuidas en Foundations, Business Entities, Securities, Derivatives, Loans, etc. Usado en producción para:

KYC entity resolution: desambiguación de organizaciones legales (fibo-be-le-fbo:FormalBusinessOrganization).
Clasificación de instrumentos financieros (fibo-sec-sec-bsk:Basket, fibo-der-drc-cds:CreditDefaultSwap).
Reporting regulatorio: mapeo de campos contra el esquema canónico.

Para un RAG corporativo en finanzas, FIBO es el esquema de tipos que cualquier extracción debe satisfacer. Sin FIBO, dos chunks que hablan de “swap” pueden ser un swap de tipos de interés o uno de divisas.

SNOMED CT

IHTSDO/SNOMED International. Releases mensuales (la International Edition de mayo de 2026 publicada el 15 de mayo). Aproximadamente 350.000+ conceptos activos en OWL 2 EL. Licencia gratuita en países miembros (España es miembro vía CSI / Ministerio de Sanidad), comercial fuera. En producción:

Codificación clínica asistida: el LLM propone códigos SNOMED y el sistema valida contra la ontología.
Búsqueda cross-lingüe en historiales: Diabetes mellitus type 2 y Diabetes mellitus tipo 2 resuelven al mismo concepto (73211009).
Compliance HIPAA / RGPD salud: la trazabilidad de qué tipo de dato clínico maneja cada componente.

schema.org

CC-BY-SA, ~800 tipos, JSON-LD nativo. La ontología de la web. Usado en cualquier RAG sobre crawls públicos para tipar Product, Article, Person, Organization desde los microformatos que el corpus ya trae embebidos.

Las otras a tener en el radar

Ontología	Dominio	Licencia	Cuándo usarla
IEC 81346	sistemas industriales (designación =K1-Q1)	propietario IEC	CMDB-as-graph, planta industrial
GS1	cadena de suministro (GTIN, GLN, SSCC)	membership; web vocab libre	trazabilidad EUDR, retail
NIEM	interoperabilidad gov US	CC0	integración gov-to-gov
Wikidata	KB universal (~115M items)	CC0	entity linking universal
ENS RD 311/2022 Anexo I-II	seguridad ESP sector público	BOE público	clasificación de activos en cualquier despliegue ENS
EU AI Act Anexo III	8 áreas de alto riesgo	EU regulation	tagging de compliance EU

Para un cliente español del sector público con sistemas IA, la ontología mínima que conviene tener formalizada es la unión ENS Anexo I + EU AI Act Anexo III + ISO 42001 Annex A. Ese mapeo se genera una vez, se mantiene como artefacto versionado en el repo de gobierno IA y se enlaza desde el lineage de cada modelo desplegado.

Stack open source on-prem 2026

El landscape de implementación se divide en triple stores RDF, property graphs y herramientas auxiliares.

Triple stores RDF / SPARQL

Stack	Licencia	Notas operativas
Apache Jena Fuseki	Apache 2.0	Referencia open. Storage TDB2. Releases trimestrales. El default razonable.
Eclipse RDF4J	EDL/BSD-like	Framework Java + servidor (Sesame-derived). Maduro.
Virtuoso Open Source	GPLv2	Alto rendimiento. La edición Community no incluye clustering.
Ontotext GraphDB Free	EULA propietaria, gratuita hasta 2 queries concurrentes	Razonamiento OWL 2 RL fuerte. Cap operacional en concurrencia.
Stardog	propietario	Sin tier gratuito de producción genuino en 2026 — solo developer.
Blazegraph	discontinuado	Wikidata está migrando a Qlever / otros. No empezar proyecto nuevo.

Property graphs (Cypher / Gremlin)

Stack	Licencia	Notas operativas
Neo4j Community Edition	GPLv3 (con histórico Commons Clause en algunos artefactos); Enterprise cerrado	Vector index nativo desde 5.11. Cypher 25 añade cláusula `SEARCH`. Cypher AI procedures (dic 2025) integran LLM calls y embedding generation en la query. Implicación AGPL: si redistribuyes un SaaS que expone funcionalidad de Neo4j Community puede exigir disclosure del source — verifica con legal.
Memgraph	BSL → Apache tras 4 años	In-memory, Cypher. Más rápido que Neo4j para workloads de query intensivos.
NebulaGraph	Apache 2.0	Distribuido. Para tamaños grandes.
ArangoDB	Apache 2.0 (Community); features migradas a Enterprise post-3.12	Multi-modelo (graph + document).
KuzuDB	MIT	Kùzu Inc. archivó el repo upstream en oct-2025. Forks comunitarios: `bighorn` (Kineviz), `ryugraph`. Considera el upstream sin mantenimiento.

Híbrido vector + grafo

Neo4j 5.x con HNSW nativo: vector como propiedad de nodo, búsqueda dentro de Cypher. La opción más integrada.
Memgraph + pgvector: dos stacks, dos puntos de operación.
Qdrant con payload de grafo: no es un grafo de verdad, pero permite filtros tipo k-hop básicos sobre payload.

Editores y herramientas

Protégé (Stanford, BSD): editor de ontologías de facto. Suite con HermiT, Pellet, ELK reasoners.
TopBraid Composer: comercial; útil si ya está en la organización.
Atomgraph: editor web LGPL.

Construcción del KG con LLM

GLiNER / GLiREL (Apache 2.0): NER y relation extraction zero-shot. Mucho más baratos que LLM-extractor (10-100× menos tokens).
REBEL (MIT): joint entity + relation extraction basado en BART. SOTA durante años, hoy superado por LLM-extractors pero sigue siendo razonable para baseline.
LLM-extractor con structured output: vLLM + XGrammar o Outlines enforcing un JSON Schema derivado de SHACL. XGrammar es el backend por defecto de vLLM / SGLang / TensorRT-LLM desde marzo 2026, con <40 µs/token de overhead.

SPARQL clients

rdflib (Python, BSD), Apache Jena CLI, Comunica (MIT, JS, federación SPARQL nativa).

Cinco patrones de integración LLM × ontología

Casi todo lo útil cabe en cinco patrones repetibles.

1. Extracción guiada por esquema

El LLM emite JSON conforme a un schema derivado de la ontología, validado en el decoder con structured output. La salida es ABox tipada lista para insertar como triplas:

schema = derive_json_schema_from_shacl("PersonShape.ttl")
# El LLM solo puede emitir tokens que mantengan la salida válida.
extracted = llm.generate(prompt=document, schema=schema)
graph.add_triples(jsonld_to_rdf(extracted))

Coste: prácticamente cero overhead por token con XGrammar; eliminación efectiva de “salidas que no validan”.

2. Text-to-SPARQL con firewall semántico

El LLM genera SPARQL; un firewall semántico valida cada predicado y clase contra el TBox antes de ejecutar la query:

sparql_text = llm.generate(prompt=user_query, context=ontology_summary)
query = parse(sparql_text)
for predicate in query.predicates:
 if predicate not in ontology.declared_predicates:
 raise UnknownPredicate(predicate)
result = endpoint.execute(query)

Captura el patrón clásico del LLM inventando un predicado plausible que no existe en la ontología, antes de tocar el triple store.

3. Retrieval híbrido dense + sparse + KG con RRF

El reranker hybrid retrieval se amplía con un cuarto canal: traversal en el KG seeded por las entidades extraídas de la query. Los rankings de los cuatro canales se fusionan con Reciprocal Rank Fusion:

\text{RRF}(d) = \sum_{c \in \{\text{dense}, \text{sparse}, \text{colbert}, \text{kg}\}} \frac{1}{k + \text{rank}_c(d)}

con k=60 típico. El canal KG cubre exactamente las queries que rompen los otros tres: queries con entidades nombradas que el dense malinterpreta o que aparecen rara vez en el corpus.

4. Reranking por distancia de grafo

Entre los candidatos del primer comité de retrieval, se prefieren los chunks cuyas entidades estén dentro de k hops en el KG de las entidades de la query. Implementación práctica: añadir un score graph_distance y fusionarlo en el reranker:

def graph_distance_score(chunk, query_entities):
 chunk_entities = chunk["entities"]
 distances = [
 shortest_path_length(kg, qe, ce)
 for qe in query_entities for ce in chunk_entities
 ]
 return 1 / (1 + min(distances))

5. Tool calling tipado + evals estratificados

Tools declaran sus argumentos como clases ontológicas. Antes de invocar, los argumentos pasan SHACL validation. Evita el bug clásico del agente llamando buscar_cliente(cliente_id="cliente del que se quejó ayer") — un string libre cuando esperaba un IRI.

Evals estratificados por rdf:type o skos:Concept: cada query del golden set lleva su clase ontológica como label, las métricas se reportan por clase, y la accuracy global se complementa con cobertura por clase. Es el mecanismo que evals recomienda y la ontología hace operativo.

Implicaciones para inferencia on-premise

El triple store o property graph no come GPU: corre en CPU + NVMe. Lo que sí compite por GPU es el LLM-extractor que construye y mantiene el KG.

En la RTX 4090 (24 GB)

Setup razonable para PoC y sedes pequeñas:

GPU 24 GB ┐
 ├─ TEI bge-m3 (dense + sparse + colbert) │ ~6 GB VRAM
 ├─ vLLM Qwen2.5-7B-Instruct AWQ Q4 (LLM principal) │ ~8 GB VRAM
 └─ Carga puntual: vLLM Qwen2.5-7B-Instruct para extracción nocturna │ comparte VRAM en otra ventana
CPU/RAM ┐
 ├─ Apache Jena Fuseki (TBox + ABox del KG corporativo) │ ~2 GB RAM por M triplas
 ├─ Qdrant (denso + sparse + colbert) │ ~3 GB RAM por M chunks
 └─ GLiNER + REBEL para extracción rápida en batch │ CPU-only

Para corpora de hasta unos pocos millones de chunks, una RTX 4090 hace el trabajo combinando GLiNER/REBEL en CPU para extracción masiva (barato pero menos preciso) y el LLM en GPU para casos críticos.

En el cluster 4×H100 80 GB

H100 #1 (80 GB) ── vLLM Qwen3-72B-Instruct AWQ + Qwen2.5-7B speculative │ LLM principal
H100 #2 (80 GB) ── vLLM gte-Qwen2-7B-instruct (embedding 32k ctx) │ embedder grande
H100 #3 (80 GB) ── vLLM Qwen2.5-32B-Instruct (extractor KG dedicado) │ construcción + mantenimiento KG
H100 #4 (80 GB) ── Hold-out para canary y evals offline │ ver post canary

Apache Jena Fuseki cluster (3 nodos CPU + NVMe RAID)
 ├─ Ontología corporativa (TBox)
 ├─ ABox (cientos de millones de triplas)
 └─ FIBO / ENS / EU AI Act como named graphs

Qdrant cluster (3 nodos CPU + NVMe)
 ├─ Chunks indexados con triplas en payload
 └─ Lineage hacia nodos del KG

La H100 dedicada al extractor KG es el pago real del enfoque GraphRAG. Si el corpus es estable, esa H100 puede dedicarse a evals offline o speculative decoding. Si el corpus muta a diario, está ocupada manteniendo el grafo en línea.

Las siete trampas operativas

Sobreelevar SKOS a OWL DL por ego académico. La mayoría de “ontologías corporativas” son taxonomías que no requieren razonamiento de description logic. Una SKOS con skos:broader/skos:narrower y skos:prefLabel por idioma cubre el 80% de los casos. OWL DL solo tiene sentido cuando hay axiomas de consistencia que el reasoner debe verificar. Empieza por SKOS, sube a OWL EL/RL si lo necesitas, evita OWL DL salvo necesidad probada.
Construir un KG de todo el corpus. GraphRAG canónico aplicado a 100 millones de chunks cuesta como entrenar un modelo pequeño. La alternativa correcta es HippoRAG 2 / LightRAG / KAG según el caso o GraphRAG solo sobre el subset crítico del corpus. La regla: si el coste de construcción excede el coste anual de servir el modelo, has elegido la herramienta equivocada.
TBox creada por LLM sin gobernanza. Microsoft GraphRAG genera la TBox emergente desde los datos. Para un corpus exploratorio funciona; para un dominio regulado (finanzas, salud, gobierno) la TBox no se descubre, se declara — FIBO, SNOMED, ENS. KAG es la elección correcta en esos casos.
Olvidar el mantenimiento del KG cuando el corpus cambia. Los nuevos chunks introducen entidades nuevas. Si no hay proceso de reconciliación de entidades (desambiguación, merging), el grafo acumula duplicados de la misma entidad con IRIs distintos y la calidad colapsa silenciosamente en seis meses. LightRAG tiene primitivas para esto; GraphRAG canónico requiere reconstrucción periódica.
JSON Schema desincronizado del SHACL. Si la ontología vive en RDF/SHACL y los structured outputs vienen de un JSON Schema escrito a mano, se desincronizan. Lo correcto es generar el JSON Schema desde el SHACL con herramientas como shacl-to-json-schema y regenerarlo en CI cada vez que cambia el shape.
Neo4j Community licenciado mal. GPLv3 implica que cualquier modificación que distribuyas tiene que liberarse con la misma licencia. Si vas a redistribuir un producto que embebe Neo4j Community, verifica con legal o usa una alternativa con licencia más permisiva (Memgraph BSL, Apache Jena para RDF, Kùzu fork bighorn).
Ontología de compliance no enlazada al stack técnico. Tu mapeo de ENS / ISO 42001 / EU AI Act vive en un Excel del equipo de gobierno. Tu inventario de modelos, datasets y endpoints vive en otro sistema. Sin enlace formal entre ambos, ningún cambio del stack dispara la revisión de compliance correspondiente. El mapeo va al grafo, no al Excel.

Conclusión

Una ontología no es una alternativa al RAG; es la nomenclatura que hace comparables sus piezas. Sin ella, el corpus se cura con categorías ad-hoc, los embeddings perforan documentos sin enriquecerse, los evals miden la media en vez de la varianza por clase, el guardrail bloquea por listas en vez de por tipos, el incident response agrupa mal porque cada alerta nombra a su manera, y el compliance es un Excel desincronizado del sistema. Las seis etapas LLMOps están todas mejor cuando comparten vocabulario, y compartir vocabulario quiere decir formalizar una ontología corporativa pequeña, alineada con los marcos verticales pertinentes (FIBO, SNOMED, schema.org, ENS, EU AI Act), serializada en JSON-LD para que el código la consuma sin fricción, validada con SHACL en cada interface y consultada con SPARQL cuando hace falta razonar. GraphRAG en sus variantes 2026 (Microsoft v2, LightRAG, HippoRAG 2, KAG) es una palanca complementaria, no el plato principal: el plato principal es la nomenclatura formal compartida. Lo demás —Neo4j vs Jena, OWL DL vs SKOS, GLiNER vs LLM-extractor— son decisiones técnicas que se resuelven mejor cuando ya hay claridad sobre qué nomenclatura hace falta. Linneo descubrió esto en 1735 y la biología no ha vuelto atrás; el campo LLM lo está descubriendo en 2026 y tampoco volverá.

Ver también

El pipeline LLMOps de seis etapas — el mapa maestro de las seis etapas que este post atraviesa transversalmente.
RAG corpus curation: el bibliotecario activo — la curación se vuelve curación dirigida por ontología cuando hay TBox declarado.
Embeddings en 2026: las tres familias — los embeddings se enriquecen con metadatos tipados desde la ontología.
Reranker y hybrid retrieval — el KG es el cuarto canal de retrieval, fusionado vía RRF junto a dense / sparse / multi-vector.
Structured output — los JSON Schemas con los que se construye el KG desde el LLM derivan de SHACL.
Evals para LLMs — las métricas estratificadas por clase ontológica son la palanca operacional que la ontología habilita.
Tracing LLM con OpenTelemetry GenAI — los spans llevan atributos tipados contra el TBox.
Runbooks de incident response — la taxonomía formal de incidentes habilita la deduplicación de Keep + Kafka.
Router de inferencia LLM — el routing semántico por clase ontológica.
Canary, blue-green y shadow — el canary por clase reduce el blast radius.
Controles técnicos ENS × ISO 42001 × EU AI Act — cada marco regulatorio es una ontología y se mapea como tal.
ISO/IEC 42001: AIMS — el Annex A es una jerarquía de controles formalizable como SKOS.
EU AI Act: expediente técnico — el Anexo III es una clasificación enumerable mapeable a las clases del sistema.

Referencias

W3C. RDF 1.1 Concepts and Abstract Syntax. https://www.w3.org/TR/rdf11-concepts/
W3C. OWL 2 Profiles (EL, QL, RL, DL). https://www.w3.org/TR/owl2-profiles/
W3C. SHACL — Shapes Constraint Language. https://www.w3.org/TR/shacl/
W3C. SKOS Reference. https://www.w3.org/TR/skos-reference/
W3C. JSON-LD 1.1. https://www.w3.org/TR/json-ld11/
W3C. SPARQL 1.1 Query Language. https://www.w3.org/TR/sparql11-query/
Edge et al. From Local to Global: A Graph RAG Approach to Query-Focused Summarization. Microsoft Research, 2024. https://arxiv.org/abs/2404.16130
Microsoft GraphRAG. https://github.com/microsoft/graphrag
Guo et al. LightRAG: Simple and Fast Retrieval-Augmented Generation. arXiv:2410.05779, 2024. https://arxiv.org/abs/2410.05779
Gutiérrez et al. HippoRAG: Neurobiologically Inspired Long-Term Memory for Large Language Models. NeurIPS 2024. https://arxiv.org/abs/2405.14831
Gutiérrez et al. From RAG to Memory: Non-Parametric Continual Learning for Large Language Models (HippoRAG 2). arXiv:2502.14802, 2025. https://arxiv.org/abs/2502.14802
Liang et al. KAG: Boosting LLMs in Professional Domains via Knowledge Augmented Generation. arXiv:2409.13731, 2024. https://arxiv.org/abs/2409.13731
OpenSPG / KAG. https://github.com/OpenSPG/openspg
EDM Council. Financial Industry Business Ontology (FIBO). https://spec.edmcouncil.org/fibo/
SNOMED International. https://www.snomed.org/
schema.org. https://schema.org/
Real Decreto 311/2022, de 3 de mayo, por el que se regula el Esquema Nacional de Seguridad. BOE-A-2022-7191. https://www.boe.es/eli/es/rd/2022/05/03/311
Reglamento (UE) 2024/1689 (EU AI Act). https://eur-lex.europa.eu/eli/reg/2024/1689
ISO/IEC 42001:2023 — Artificial Intelligence Management System. https://www.iso.org/standard/81230.html
Apache Jena. https://jena.apache.org/
Neo4j Cypher and AI procedures. https://neo4j.com/docs/
Protégé. https://protege.stanford.edu/
GLiNER. https://github.com/urchade/GLiNER
REBEL. https://github.com/Babelscape/rebel

Kag on lo0 — Blog Técnico