Inicio / Artículos / GraphRAG consciente de la ontología: cuando los vectores necesitan relaciones tipadas

graphrag ontology rag knowledge-graph retrieval security

GraphRAG consciente de la ontología: cuando los vectores necesitan relaciones tipadas

Cómo los anclajes de identificador, los contratos ontológicos, la fusión de rangos y las puertas de citar-o-rechazar solucionan los fallos de RAG en CVEs, la propiedad multi-hop y los hechos implícitos en el grafo.

2819 palabras

La recuperación densa responde bien a muchas preguntas, pero sigue fallando de manera sistemática: con identificadores exactos, relaciones de múltiples pasos y hechos que existen únicamente como estructura de grafo. GraphRAG, consciente de la ontología, considera esos fallos como elementos para el diseño, no como razones para abandonar los vectores, sino como motivos para añadir una capa de conocimiento tipada junto a ellos.

Parte 1: Cómo funciona exactamente RAG

El RAG clásico incrusta una pregunta, obtiene los fragmentos más cercanos y genera contenido a partir de ese contexto. En el caso de una consulta sobre vulnerabilidades como esta:

question: "path traversal apache httpd"

los rangos vectoriales y léxicos pueden no coincidir:

VECTOR (cosine)                       LEXICAL (keyword overlap)
1. CVE-2021-41773  0.746  ← correct   1. CVE-2021-28544  6.60
2. CVE-2021-23797  0.735              2. CVE-2021-40525  6.47
3. CVE-2021-32643  0.728              5. CVE-2021-41773  5.57  ← correct, buried

Cuando el CVE correcto está presente pero no es predominante, la generación inventa respuestas con confianza. Los dominios con muchos identificadores (CVE, SKU, IDs de tickets) revelan rápidamente esa brecha.

Parte 2: El obstáculo al que se enfrenta, medido

Fallo 1: Identificadores exactos

La coincidencia léxica ayuda, pero los “vecinos ruidosos” siguen ganando. La prosa recuperada incluso puede rechazar el enfoque basado en la vulnerabilidad:

[S1] "Rejected reason: This vulnerability does not meet the criteria for a
      security vulnerability…"

Luego, la generación refleja al vecino incorrecto.

Fallo 2: completitud relacional

“¿Qué productos se ven afectados?” necesita conexiones entre elementos, no solo el párrafo más cercano. La similitud devuelve CVEs relacionados; no sigue los enlaces que indican afectación.

Fallo 3: hechos que nadie anotó

Algunas respuestas existen únicamente como intersecciones entre entidades, nunca como oraciones completas. Ningún fragmento contiene esa información; solo un grafo lo hace.

Parte 3: qué aporta un grafo de conocimiento

Los nodos y conexiones tipificados convierten a los identificadores y relaciones en elementos de primer orden:

(:Vulnerability {cve_id: 'CVE-2021-41773', cvss_base_score: 9.8, cvss_severity: 'CRITICAL'})
   -[:AFFECTS {version: '2.4.49'}]-> (:Product {key: 'apache:http_server'})
   -[:HAS_WEAKNESS]->                (:Weakness {cwe_id: 'CWE-22'})

El recorrido por el grafo responde a preguntas relacionales; los vectores siguen siendo útiles cuando la prosa constituye la evidencia adecuada.

Ontología vs. grafo de conocimiento: una distinción operativa

Una ontología es el contrato que define qué tipos de entidades, qué tipos de relaciones y qué propiedades son necesarios. Un gráfico de conocimiento es la instancia poblada según ese contrato. Sin una ontología, la extracción se desvía y las uniones de datos pierden fiabilidad. Con ella, los pipelines validan y rechazan los triples defectuosos antes de que afecten negativamente a la recuperación de información.

Tres interpretaciones comunes de “GraphRAG”

El gráfico como índice — almacenar fragmentos de texto, pero recuperarlos a través de los vecinos en el gráfico.
El gráfico como memoria — las entidades y relaciones son el almacenamiento principal; el texto sirve como evidencia.
El gráfico como planificador — el agente planea los pasos a seguir antes de obtener el texto.

Los diseños conscientes de la ontología suelen combinar (2) y (1): hechos estructurados para mayor precisión, y texto original para citaciones.

Parte 4 — La arquitectura, capa por capa

La ingestión extrae entidades/relaciones de la ontología, escribe hechos del grafo, conserva los segmentos de origen y, al mismo tiempo, crea un índice vectorial/lexical a partir del texto. El tiempo de consulta ancla los identificadores, expande los vecinos del grafo, ejecuta búsquedas densas/lexicales, fusiona las clasificaciones y genera una respuesta con secciones separadas de HECHOS y EVIDENCIAS, además de reglas de citación.

Tres decisiones impuestas por los datos

Los anclajes de identificadores superan a la coincidencia difusa cuando está presente un token de CVE/producto.
La fusión ponderada debe elevar las clasificaciones del grafo en consultas por identificadores sin ocultar el texto narrativo en solicitudes de tipo descriptivo.
Las verificaciones de fidelidad deben rechazar respuestas que citen etiquetas ausentes o contradigan las propiedades del grafo.

Parte 5: Una pregunta, de principio a fin

Pregunta:

Q: "which products are affected by CVE-2021-41773"

Resolución de anclajes:

ANCHOR  Vulnerability  CVE-2021-41773  method=identifier  conf=1.00

Pesos de fusión cuando un identificador sirve como anclaje:

weights = {graph: 2.0, vector: 1.0}     # identifier match
# a lexical product match would be 1.2; no anchor at all, 0.0

Listas competidoras:

VECTOR  1. CVE-2021-21022 (Magento IDOR)   2. CVE-2021-27385  …
GRAPH   1. CVE-2021-41773 (anchor)         2. CVE-2021-25216 (shares netapp:cloud_backup)

Puntuaciones de fusión por rango recíproco:

CVE-2021-41773   2.0/(60+1) = 0.03279   ← graph, rank 1
CVE-2021-21022   1.0/(60+1) = 0.01639   ← vector, rank 1

Hechos del grafo compactados para el modelo:

FACTS (from the knowledge graph):
[G1] CVE-2021-41773 | CRITICAL 9.8 (CVSS 3.1) | CWE: CWE-22
     affects: apache:http_server 2.4.49, fedoraproject:fedora 34,
              fedoraproject:fedora 35, netapp:cloud_backup,
              oracle:instantis_enterprisetrack 17.1 / 17.2 / 17.3
     source: https://nvd.nist.gov/vuln/detail/CVE-2021-41773

Evidencia de origen:

EVIDENCE (source text):
[S1] "A flaw was found in a change made to path normalization in Apache
      HTTP Server 2.4.49. An attacker could use a path traversal attack…"

Respuesta estructurada con citas:

{"answer": "CVE-2021-41773 is CRITICAL with a CVSS base score of 9.8 [G1].
            It affects apache:http_server 2.4.49, fedoraproject:fedora 34,
            fedoraproject:fedora 35 [G1].",
 "sources": ["G1"],
 "entities": [{"label": "Vulnerability", "key": "CVE-2021-41773"}],
 "confidence": "high"}

Compuertas posteriores a la generación:

✓ every cited tag exists in the context
✓ the answer cites something at all
✓ every CVE id in the answer appears in the context
✓ entity labels are real ontology classes
✓ numbers that look like CVSS scores match the graph facts
→ ACCEPTED

Una respuesta deficiente que falla en las compuertas:

{"answer": "CVE-2021-41773 scores 4.3 and affects nginx [G1]."}

Razones de rechazo:

✗ states 4.3 but the graph facts say [9.8]
✗ entity Product nginx:nginx is not in the context
→ REJECTED → one repair attempt → still bad → REFUSAL

La misma maquinaria, un paso más allá

Las uniones de inventario convierten a “productos afectados” en “aplicaciones de nivel 1 afectadas y los equipos responsables”:

application        criticality  team            library  pinned    match_precision
checkout-web       tier1        payments        httpd    2.4.49    version-exact
log-aggregator     tier2        infrastructure  httpd    2.4.49    version-exact
api-gateway        tier1        platform-core   httpd    1.15.17   product-level

Misma maquinaria de anclaje y fusión; un paso adicional a través de los puntos de conexión de las aplicaciones.

Parte 6 — Resultados, costos y los errores

En los identificadores y conjuntos de múltiples saltos, la fusión consciente de la ontología mejora la precisión en comparación con las líneas base basadas únicamente en vectores; en preguntas de prosa pura, el mejoramiento es menor, por lo que se deben mantener los vectores. Los costos radican en la extracción, las operaciones con grafos y prompts ligeramente más extensos, no en abandonar los embeddings.

Los errores, porque son el contenido real

Errores típicos en producción: deriva ontológica (aparición de nuevos tipos de aristas), alucinaciones del extractor (gravedad incorrecta), errores por copiar y pegar pesos de fusión, etiquetas de citación que no existen en el contexto, y cachés que sirven snapshots obsoletos de grafos tras una actualización CVE. Cada error se relaciona con una prueba: validación de esquemas, límites de propiedades, configuraciones de fusión, verificaciones de existencia de citaciones y TTL/invalidación.

Parte 7: Cuándo construir esto y cuándo no

Utilícelo cuando el tráfico incluya identificadores, preguntas sobre propiedad/impacto en múltiples etapas o hechos que nunca se hayan escrito como oraciones. Omítalo cuando el corpus sea lo suficientemente pequeño como para utilizar únicamente una búsqueda híbrida eficaz, o cuando nadie vaya a mantener una ontología. GraphRAG no es un símbolo de sofisticación; es una respuesta a modos de fallo medidos.

Los cinco invariantes que vale la pena mantener en cualquier escala

La ontología primero — los tipos antes que las triples.
Anclajes para identificadores — coincidencia exacta antes que el método de coseno.
Separar hechos y pruebas en la instrucción de búsqueda.
Citar o rechazar los resultados después de la generación.
Medir según las preguntas propias — no solo basándose en blogs de tasas de éxito públicas.

Esos invariantes siguen siendo útiles, ya sea en una demostración con laptop o en un plano de conocimiento de seguridad multiinquilino. Ampliar la cobertura debería significar extender la ontología y los elementos fijos, no añadir otra instrucción de prompt a un montón desestructurado de fragmentos. Mantenga las métricas de extracción (precisión/recall en entidades y aristas) junto con las métricas de respuesta; de lo contrario, un modelo “mejor” podría inventar silenciosamente relaciones que parezcan coherentes pero fallen en las auditorías. Versione la ontología como una API: los cambios adicionales son fáciles, los nombres nuevos requieren tareas de migración y las eliminaciones necesitan marcas funerarias para que los snapshots antiguos no resuciten aristas eliminadas. Para el servicio de soporte, active alertas ante picos en rechazos de puertas de enlace y tasas de error del extractor, no solo ante la latencia del Gateway; esas señales detectan fallos en el plano de conocimiento antes de que los usuarios se den cuenta de errores en las severidades CVE. Finalmente, reserve una cola de revisión humana para los CVEs controvertidos y las asignaciones de productos durante los primeros meses; las etiquetas se vuelven problemáticas con el tiempo.

Pruebas de integración que mantienen honestos los pesos de fusión a medida que crece el catálogo.

Al evaluar proveedores o frameworks, pregunte cómo codifican las restricciones ontológicas, cómo fusionan los rangos de grafos y vectores, y cómo prueban la fidelidad de las citaciones. Las demostraciones que solo muestran una interfaz gráfica atractiva sin esas tres respuestas suelen recrear el mismo problema de RAG bajo un nombre diferente. Prefiera pipelines aburridos pero bien definidos con anclajes explícitos antes que un “razonamiento gráfico agente” mágico que no puede mostrar qué arista justificó una afirmación de gravedad. Ese enfoque sencillo es lo que hace operativo a GraphRAG consciente de la ontología.

Trate los pesos de fusión como una configuración a probar: guárdelos junto con elementos fijos que definan la pregunta, las listas de candidatos y el ID principal esperado. Cuando alguien “ajuste” los pesos en un cuaderno de notas, exija una solicitud de cambios que actualice esos elementos fijos para evitar que las regresiones queden ocultas en conocimientos internos del equipo.

Trate los pesos de fusión como configuración en prueba: guárdelos junto a los archivos fijos que definen una pregunta, las listas de candidatos y el ID principal esperado. Cuando alguien “ajuste” los pesos en un cuaderno de notas, exija una solicitud de cambios que actualice esos archivos fijos para que las regresiones no queden ocultas en conocimientos internos del equipo.

Trate los pesos de fusión como configuración en pruebas: guárdelos junto a los archivos fijos que definen una pregunta, las listas de candidatos y el ID principal esperado. Cuando alguien “ajuste” los pesos en un cuaderno de notas, exija una solicitud de cambios que actualice esos archivos fijos para que las regresiones no queden ocultas en conocimientos internos del equipo.

Lecturas relacionadas

Ingeniería de contexto basada en ontologías cuando el RAG vectorial no es suficiente — Cuando el significado abarca sistemas de registro, los embeddings por sí solos no permiten realizar uniones. La ingeniería de contexto basada en ontologías valida hechos tipados, la procedencia y herramientas de vecindad para obtener respuestas fundamentadas en modelos de lenguaje grande.
Por qué el RAG empresarial necesita búsqueda híbrida y no solo vectores — Los embeddings omiten los IDs de facturas y códigos de error; la combinación de BM25 con recuperación densa mediante fusión soluciona la deficiencia en identificadores empresariales.

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ías detiene al agente en una demostración con un contrato de 2,3 millones de dólares.

RDF a GraphRAG: Capas ontológicas prácticas con ejemplos VOO — Desde IRIs y triples pasando por RDFS, OWL y SHACL: cuándo las ontologías superan a las tablas y cómo estabilizan GraphRAG.

Inyección de documentos RAG: Cómo se hackean los pipelines sin tocar el modelo — Corpus envenenados, trucos de recuperación y defensas que consideran la ingestión como una superficie de ataque.

Todos los artículos Enviar el brief