Knowledge graphs en RAG

Un knowledge graph en RAG usa una ontología de dominio y relaciones validadas como una capa de conocimiento gobernada sin sustituir los documentos primarios. Es un contrato independiente con entradas, salidas y condiciones de fallo medibles. Primero se fijan tipos de consulta, fuentes disponibles, evidencia necesaria y latencia aceptable; después se elige el modelo o la biblioteca.

Como el grafo representa relaciones explícitas entre entidades, retrieval debe devolver no solo texto, sino también el tipo de relación y la evidencia de su origen. El generador no debe convertir un edge débil o indirecto en un hecho categórico. Esto importa especialmente para dependencias, ownership, compatibilidad y afirmaciones causales.

Un flujo práctico: entity linking asigna la consulta a nodos canónicos, traversal encuentra rutas permitidas y text retrieval añade evidencia citada para las afirmaciones encontradas. El contrato debe incluir un request ID estable, versiones de configuración, confidence o motivo de fallback y suficiente provenance para reproducir el resultado. El texto sin identificadores de fuente no es un output de retrieval completo.

Un contrato útil para knowledge-graph RAG incluye canonical entity ID, relation type, source document, validFrom, validUntil y confidence. El índice textual puede reconstruirse con frecuencia, pero estas identidades deben seguir siendo reproducibles para probar por separado entity resolution, relation retrieval y el evidence bundle final.

Construye un knowledge graph cuando un esquema estable y sus relaciones tengan valor de negocio; no crees una ontología compleja para un corpus de páginas de referencia independientes. Mantén al lado el mejor baseline simple, porque la complejidad extra solo se justifica con una mejora medida. El router puede considerar tipo de consulta, riesgo, número esperado de evidencias y latency budget.

Si una entidad tiene varias relation paths incompatibles, el sistema no debe elegir silenciosamente la más conveniente. Debe mostrar el conflicto, aplicar filtros temporales o de prioridad de fuente y, si la evidencia es insuficiente, responder con una limitación explícita. Así los errores del grafo aparecen antes de convertirse en una alucinación convincente.

El riesgo principal es que una entity resolution incorrecta fusione objetos distintos y que la falta de calificadores temporales convierta una relación histórica en aparentemente vigente. Un system prompt más largo no corrige esto: hacen falta constraints deterministas, pruebas negativas y separación entre datos no confiables e instrucciones de gobierno. Cualquier fallback automático debe ser visible en el trace y no ampliar permisos ni fuentes.

Las pruebas de release deben cubrir entidades duplicadas, colisiones de alias, nodos huérfanos, relaciones conflictivas y hechos caducados. Tras cada defecto se conserva un graph fixture mínimo como caso de regresión. El rollback debe restaurar de forma coordinada la versión de ontología, el snapshot del grafo y la policy de retrieval, no solo el código de aplicación.

Las señales principales incluyen precisión de entity linking, exactitud de relation traversal, cobertura de evidencia, tasa de no respuesta para entidades desconocidas y calidad frente a un baseline text-only. La evaluación offline debe contener consultas reales y adversariales, labels congelados y segmentación por dominio, idioma y riesgo. Un promedio no puede ocultar el fallo de un segmento crítico; necesita su propio guardrail threshold.

En producción hacen falta IDs estables, schema registry, constraints, una review queue para nuevas relaciones, fechas de vigencia, source pointers y migración controlada de la ontología. Una configuración nueva se despliega primero en shadow mode o en un canary pequeño, se compara con el baseline y se revierte automáticamente si viola el SLO. Esto conecta calidad, coste y fiabilidad.

Un knowledge graph es útil para relaciones multi-hop, pero cada node y edge debe tener source, validFrom, validUntil y confidence. Las relaciones extraídas automáticamente no se convierten en hechos canónicos sin validación. El pipeline primero resuelve entidades, luego las relation paths permitidas y solo después reúne evidencia para generar. Un traversal demasiado amplio crea ruido, latencia y riesgo de fuga entre tenants.

La evaluación comprueba entity linking, corrección de rutas, validez temporal y respaldo de la respuesta. Cuando las fuentes se contradicen, el grafo conserva ambas versiones y su provenance en vez de sobrescribir el hecho. Las actualizaciones deben ser idempotentes y propagar eliminaciones. La respuesta final muestra la source chain para que el usuario pueda verificar cómo se conectan las afirmaciones.

• No crees edges sin provenance.
• Limita la profundidad de traversal.
• Prueba conflictos temporales.