Graph Engineering: la siguiente habilidad del ingeniero

Durante los últimos años, la IA ha evolucionado desde la predicción de palabras y la búsqueda de similitudes hacia sistemas capaces de trabajar con conocimiento cada vez más complejo. En este contexto, Graph Engineering para IA plantea una pregunta fundamental: ¿qué pasa cuando un modelo necesita razonar sobre relaciones, conectar evidencias y comprender cómo diferentes entidades están vinculadas?

Aquí entra el Graph Engineering: una disciplina orientada a diseñar, construir y mantener estructuras de conocimiento que permiten a los sistemas de IA no solo recuperar información, sino también conectar evidencias, recorrer relaciones, razonar sobre múltiples saltos y explicar de dónde proviene una respuesta.

El objetivo no es reemplazar el RAG tradicional, sino llevarlo un paso más allá: combinar recuperación semántica, Knowledge Graphs y razonamiento estructurado para construir sistemas de IA más contextuales, trazables y capaces de trabajar con la complejidad del conocimiento real.

De datos aislados → conocimiento conectado

No estamos hablando simplemente de aprender Neo4j, sino de aprender a diseñar las relaciones que permiten que una IA encuentre, conecte, cuestione y explique la evidencia. Porque durante mucho tiempo construimos sistemas de datos pensando principalmente en el dato aislado al dato conectado.  Porque una tabla puede decir:

👤 Cliente  →  🏢 Empresa  →  📦 Producto

Pero un grafo puede expresar algo mucho más cercano a la realidad:

Y de repente ya no estamos solamente almacenando datos, estamos almacenando contexto; porque los nodos representan entidades o conceptos y las aristas representan relaciones semánticas entre ellos y eso cambia la naturaleza de las preguntas que podemos hacer. No solamente: “¿qué documento contiene esta palabra?” sino “¿qué entidades están relacionadas con este problema y qué cadena de evidencia conecta unas con otras?”

RAG tradicional: cuando la similitud semántica no es suficiente

Actualmente, el estándar de la industria para dar contexto a los LLMs es el RAG tradicional, basado en bases de datos vectoriales. Funciona increíble para buscar similitudes semánticas, pero tiene un punto ciego masivo: el razonamiento multi-salto (multi-hop reasoning).

Si le preguntas a un LLM vectorial “¿Cómo impacta la escasez de litio en las políticas de energía renovable en Europa?”, buscará fragmentos de texto similares, pero la realidad no es plana; es una red.

El RAG funciona extraordinariamente bien cuando necesitamos recuperar fragmentos relevantes de información. Pero hay problemas donde la similitud semántica no es suficiente, cuando la respuesta requiere: múltiples saltos de relaciones, contexto global, dependencias, jerarquías, entidades compartidas entre documentos, trazabilidad, contradicciones, evolución temporal; buscar solamente los chunks más parecidos puede quedarse corto.

El Graph Engineering para IA (mediante Knowledge Graphs y Graph Neural Networks) no almacena fragmentos aislados, almacena entidades y sus relaciones. No fuerza una respuesta basada en proximidad de palabras; cuantifica la distancia real entre nodos de información, permitiéndonos explorar la topología de la evidencia.

¿Qué es Graph Engineering para IA?

Es el conjunto de técnicas, patrones y herramientas para diseñar, construir y mantener grafos (estructuras de nodos y aristas) que alimentan pipelines de IA: desde recuperación de contexto y razonamiento hasta enriquecimiento de datos y explicabilidad.

Por qué importa hoy

• Los LLMs y sistemas de RAG dependen cada vez más de señales relacionales (conexiones entre entidades, temporalidad, causalidad).
• Los grafos permiten consulta semántica, fusión de fuentes heterogéneas, explicabilidad y razonamiento estructurado.
• Cuantificar en tareas de recuperación de contexto, usar un grafo bien diseñado puede aumentar la precisión de recuperación y la coherencia de respuestas en un rango medible (ejemplo: mejoras del 10–40% en métricas de recuperación según configuración y dominio). 
• Porque obliga a pensar en algo que muchas arquitecturas de IA todavía esconden: la estructura del conocimiento. No basta con tener:

En determinados problemas necesitamos empezar a pensar en:

Y esto introduce nuevas preguntas de ingeniería, eso ya no es simplemente prompt engineering, eso es engineering del conocimiento y de la evidencia.

Principios de Graph Engineering

• Modela intenciones, no solo entidades: nodos = entidades, conceptos, documentos, fragmentos; aristas = relaciones semánticas, temporales, de citación, de confianza.
• Normaliza y versiona el grafo: los cambios en esquemas deben ser trazables.
• Diseña para consultas híbridas: soporta búsquedas por similitud (embeddings) y por topología (caminos, vecinos).
• Métricas y A/B testing: mide impacto en downstream (recall@k, MRR, F1, coherencia humana).
• Explicabilidad nativa: mantener metadatos en aristas (peso, fuente, confianza, timestamp).

Arquitectura típica y componentes

1. Ingesta: ETL que extrae entidades y relaciones desde texto, bases, APIs.
2. Enriquecimiento: embeddings, desambiguación, linking.
3. Almacenamiento: base de grafos (Neo4j, JanusGraph, TigerGraph) o índices híbridos (Milvus + RedisGraph).
4. Consulta: motores de consulta por patrón (Cypher, Gremlin) y por similitud (ANN).
5. Orquestación: pipelines reproducibles (Airflow, Dagster).
6. Evaluación: tests automáticos y dashboards.

Vector RAG vs. GraphRAG

Para entender por qué esto es un game changer, veamos los datos crudos. Así es como cambia la arquitectura de nuestras soluciones:

Experimento: RAG simple vs RAG + Graph

Ejemplo de un sistema de generación aumentada por recuperación (RAG) avanzado que combina dos enfoques:

• Recuperación semántica: uso de embeddings y FAISS para encontrar información similar por significado.
• Grafo de conocimiento: uso de NetworkX para conectar conceptos relacionados y expandir la búsqueda más allá de la similitud textual.

A continuación, código mínimo y funcional (Python) que puedes ejecutar localmente, que usa datos de ejemplo y librerías comunes.

Preparación: dependencias

!pip install sentence-transformers faiss-cpu networkx numpy scikit-learn

Dataset de ejemplo

# data.py
documents = [
    {"id":"d1","text":"Graph databases store nodes and edges and are great for relationships."},
    {"id":"d2","text":"Embeddings map text to vectors for semantic search."},
    {"id":"d3","text":"RAG systems combine retrieval and generation to ground LLM outputs."},
    {"id":"d4","text":"Neo4j is a popular property graph database used in production."},
    {"id":"d5","text":"Causal relations help reasoning about events and their effects."},
]Lenguaje del código: PHP (php)

Construir embeddings y vector store (FAISS)

# vector_store.py
from sentence_transformers import SentenceTransformer
import numpy as np
import faiss

model = SentenceTransformer('all-MiniLM-L6-v2')
texts = [d['text'] for d in documents]
ids = [d['id'] for d in documents]
embs = model.encode(texts, convert_to_numpy=True)

d = embs.shape[1]
index = faiss.IndexFlatIP(d)
faiss.normalize_L2(embs)
index.add(embs)

def query_vector(q, k=3):
    v = model.encode([q], convert_to_numpy=True)
    faiss.normalize_L2(v)
    D, I = index.search(v, k)
    return [ids[i] for i in I[0]], D[0]Lenguaje del código: PHP (php)

Construir grafo simple con NetworkX (relaciones sintéticas)

# graph_store.py
import networkx as nx

G = nx.DiGraph()
for d in documents:
    G.add_node(d['id'], text=d['text'], source='synthetic')

# Añadimos aristas semánticas/causales manuales para el ejemplo
G.add_edge('d1','d4', relation='example_of', weight=0.9)
G.add_edge('d3','d2', relation='uses', weight=0.8)
G.add_edge('d5','d3', relation='informs', weight=0.7)

def neighbors(node, k=3):
    # devuelve vecinos ordenados por peso
    nbrs = sorted(G[node].items(), key=lambda x: -x[1].get('weight',0))
    return [n for n,_ in nbrs][:k]Lenguaje del código: PHP (php)

Estrategia de fusión: combinar vecinos del grafo con vecinos semánticos

Implementamos la lógica principal de recuperación:

• retrieve_rag: solo utiliza búsqueda semántica.
• retrieve_rag_graph: combina la búsqueda semántica con el grafo, añadiendo vecinos relacionados para enriquecer el contexto recuperado.

# fusion.py

doc_map = {d['id']: d for d in documents}

def retrieve_rag(query, k=3):
    ids, scores = query_vector(query, k=k)
    return ids

def retrieve_rag_graph(query, k=3, graph_k=2):
    # Recuperación semántica
    ids, scores = query_vector(query, k=k)
    # Expandir con vecinos del grafo
    expanded = []
    for id_ in ids:
        expanded.append(id_)
        for n in neighbors(id_, k=graph_k):
            expanded.append(n)
    # Mantener orden y unicidad
    seen = set()
    final = []
    for x in expanded:
        if x not in seen:
            seen.add(x)
            final.append(x)
    return final[:k+graph_k]

# Ejemplo de uso
q = "¿Cómo se almacenan las relaciones en bases de datos?"
print("RAG:", retrieve_rag(q))
print("RAG+Graph:", retrieve_rag_graph(q))Lenguaje del código: PHP (php)

Explicabilidad y Evidencia

Utilizamos algoritmos de caminos mínimos de networkx para explicar por qué ciertos documentos están relacionados, mostrando la ruta que conecta un concepto con otro en el grafo.

# evidencia.py
import networkx as nx

def explain_path(source_ids, target_id):
    explanations = []
    for s in source_ids:
        if nx.has_path(G, s, target_id):
            path = nx.shortest_path(G, s, target_id)
            explanations.append(path)
    return explanations

# Si la respuesta usa d4 como evidencia, mostramos caminos desde d1
print(explain_path(['d1','d3'], 'd4'))Lenguaje del código: PHP (php)

Visualización del Grafo

Generamos un gráfico interactivo (usando matplotlib) que muestra los nodos, sus relaciones y un extracto del texto de cada documento para inspeccionar visualmente la estructura del conocimiento.

import matplotlib.pyplot as plt
import networkx as nx

plt.figure(figsize=(12, 10))
pos = nx.spring_layout(G, k=1.5)  # Ajustamos k para separar más los nodos

# Dibujar nodos y aristas
nx.draw_networkx_nodes(G, pos, node_color='lightblue', node_size=3500)
nx.draw_networkx_edges(G, pos, edge_color='gray', width=1.5, alpha=0.5)

# Crear etiquetas que combinen ID y Texto (recortado para legibilidad)
labels = {node: f"{node}\n{G.nodes[node]['text'][:30]}..." for node in G.nodes()}
nx.draw_networkx_labels(G, pos, labels=labels, font_size=9, font_weight='bold')

# Añadir etiquetas a las aristas
edge_labels = nx.get_edge_attributes(G, 'relation')
nx.draw_networkx_edge_labels(G, pos, edge_labels=edge_labels, font_color='red')

plt.title('Grafo de Documentos con Contenido Textual')
plt.axis('off')
plt.show()Lenguaje del código: PHP (php)

Experimento Reproducible: RAG vs. RAG + Graph

En esta sección evaluamos cuantitativamente si la inclusión del grafo mejora la recuperación de información.

Métricas utilizadas:

• Recall@K: ¿está el documento relevante entre los K primeros resultados?
• MRR: evalúa qué tan arriba en la lista aparece el primer documento relevante.

import pandas as pd

# 1. Definir Ground Truth (Pregunta -> IDs relevantes esperados)
evaluation_set = [
    {"query": "¿Qué es Neo4j?", "expected": ["d4", "d1"]},
    {"query": "¿Cómo funcionan los sistemas RAG?", "expected": ["d3", "d2"]},
    {"query": "Bases de datos y relaciones", "expected": ["d1", "d4"]},
    {"query": "Razonamiento sobre eventos", "expected": ["d5", "d3"]}
]

def calculate_metrics(retrieved_ids, expected_ids, k=5):
    # Recall@K
    hits = len(set(retrieved_ids[:k]) & set(expected_ids))
    recall = hits / len(expected_ids) if len(expected_ids) > 0 else 0
    
    # MRR
    mrr = 0
    for rank, res_id in enumerate(retrieved_ids, 1):
        if res_id in expected_ids:
            mrr = 1 / rank
            break
    return recall, mrr

results = []

for test in evaluation_set:
    q = test["query"]
    target = test["expected"]
    
    # Ejecutar ambos métodos
    ids_rag = retrieve_rag(q, k=4)
    ids_hybrid = retrieve_rag_graph(q, k=2, graph_k=2) # k=2 semánticos + 2 grafo
    
    # Calcular métricas
    rec_rag, mrr_rag = calculate_metrics(ids_rag, target)
    rec_hyb, mrr_hyb = calculate_metrics(ids_hybrid, target)
    
    results.append({
        "Consulta": q,
        "Recall Baseline": rec_rag,
        "MRR Baseline": mrr_rag,
        "Recall +Graph": rec_hyb,
        "MRR +Graph": mrr_hyb
    })

# Mostrar resultados
df_results = pd.DataFrame(results)
display(df_results)

print(f"\nPromedio Recall Baseline: {df_results['Recall Baseline'].mean():.2f}")
print(f"Promedio Recall +Graph: {df_results['Recall +Graph'].mean():.2f}")Lenguaje del código: PHP (php)

Ejemplo avanzado: usar caminos de evidencia para explicar una respuesta

# evidencia.py
import networkx as nx

def explain_path(source_ids, target_id):
    explanations = []
    for s in source_ids:
        # nx.has_path y G ya están disponibles globalmente
        if nx.has_path(G, s, target_id):
            path = nx.shortest_path(G, s, target_id)
            explanations.append(path)
    return explanations

# Si la respuesta usa d4 como evidencia, mostramos caminos desde d1 y d3
print(explain_path(['d1','d3'], 'd4'))Lenguaje del código: PHP (php)

Uso práctico: cuando el LLM cita un documento, adjunta la ruta de evidencia (nodos y relaciones) para que el usuario verifique la cadena de razonamiento.

Ver el experimento completo en GitHub: https://github.com/Orliluq/graph_engineering.git

Buenas prácticas

• Híbrido vector+grafo: no reemplaces embeddings; combínalos. El grafo aporta estructura y trazabilidad.
• Peso y confianza: asigna pesos a aristas y usa esos pesos en la fusión (ejemplo: pondera scores de embeddings con centralidad o confianza de arista).
• Actualización incremental: que soporta inserciones y borrados sin reconstruir todo el índice.
• Pruebas A/B y métricas: instrumenta cada cambio y mide impacto en KPIs reales (tiempo de respuesta, tasa de corrección, satisfacción).
• Privacidad y gobernanza: registra orígenes y permisos en metadatos de nodos/aristas.

Graph Engineering para IA no es una panacea ni un reemplazo automático de técnicas vectoriales; es una herramienta complementaria que aporta estructura, trazabilidad y nuevas señales. La única forma responsable de decidir su adopción es medir: ejecutar experimentos controlados, cuantificar mejoras y analizar el coste operativo.