Búsqueda vectorial contra grafo de conocimiento: cuánto cuesta realmente construir y mantener un GraphRAG

• Corpus original y tamaño del grafo: 10.019 fichas de conocimiento convertidas en 5.237 nodos y 19.803 aristas (archivo SQLite de 15 MB)
• Ahorro en la fase de construcción: reducción del costo de extracción de los $1.500 estimados (con 117K tokens de prefijo por llamada) a unos pocos dólares
• Compresión de entidades con un diccionario canónico: 1.213 variantes de nombres de proyectos se redujeron a 81 proyectos canónicos (15 veces menos)
• Velocidad del circuito híbrido: 13 ms para una búsqueda rankeada con FTS5 sobre 538.956 mensajes, y 87 ms para un JOIN de grafo en dos saltos

Tras un año operando mi propio sistema de memoria, resumí la diferencia entre ambos enfoques en una frase: la búsqueda vectorial responde "encuéntrame una cita sobre X", mientras que el grafo responde "explícame cómo está estructurado X y quién se relaciona con él". Cuando preguntas "qué herramientas usamos en el proyecto durante año y medio y quién participó", la respuesta correcta no cabe entera en ningún fragmento de texto: la búsqueda vectorial devuelve tres fragmentos al azar, y el modelo rellena con seguridad el 80% restante de la imagen, aunque sea inventado.

El estudio de Microsoft Research que tanto se cita (`arXiv:2404.16130`), que promete la victoria de GraphRAG en el 72-83% de las comparaciones por pares en cuanto a completitud de la respuesta, es correcto, pero con condiciones de contorno muy estrictas. La medición se hizo sobre una tarea de resumen global del corpus (`query-focused summarization` de 1,0 a 1,7 millones de tokens), y ese rango de 72-83% incluye además la configuración `TS`, que ni siquiera usa un grafo, sino que hace `map-reduce` directamente sobre los textos originales.

¿Cómo evitar quemar $1.500 en el prompt del sistema al extraer

entidades de 10.019 registros?

Cuando me senté a construir un grafo sobre 10.019 fichas de conocimiento (5.658 notas de aprendizaje, 2.

657 fragmentos de código, 1.209 discusiones y 155 análisis de errores), la primera implementación ingenua casi arruinó el proyecto. Parecía lógico cortar el corpus en lotes de 200 registros y lanzar un agente de consola como subproceso para cada lote.

La primera llamada de prueba costó 15 centavos: el cliente CLI volvía a cargar el prompt de sistema, las reglas y las descripciones de las skills en cada arranque, 117.000 tokens de prefijo de servicio por llamada. En 49 lotes eso ya suponía más de $7 en pura pérdida, y al procesar uno por uno los 10.

019 registros, la cuenta habría superado los $1.500.

Rediseñamos el pipeline: filtramos previamente 287 registros basura y lanzamos oleadas de 5 a 7 subagentes en paralelo dentro de una única sesión padre activa, donde el prefijo ya estaba en caché. Intentar levantar 20 workers de golpe chocó con un throttling del servidor después de 411 de 672 tareas, así que fijamos el punto óptimo: IDs de lote estables en un manifiesto y oleadas de hasta 6-8 agentes en paralelo.

¿Por qué operar el grafo es más caro que construirlo, y cómo comprime

un diccionario canónico los proyectos 15 veces?

Cada nueva oleada de extracción de entidades trae decenas de variantes de escritura para los mismos nombres y marcas. Si se guardan tal cual en la base de datos, al cabo de un mes un solo proyecto se convierte en quince islas aisladas dentro del grafo. El único remedio es un diccionario canónico determinista (`_MAPS`) aplicado antes de escribir en la base de datos:

```python def canon(entity_kind: str, raw_name: str) -> str: # Normaliza el nombre crudo de una entidad a su forma canónica, o descarta el ruido (cadena vacía) cleaned = (str(raw_name) if raw_name is not None else "").strip() return _MAPS.get(entity_kind, {}).get(cleaned, cleaned) ```

Después de aplicar los mapas de normalización, 1.213 formas de escribir proyectos se redujeron a 81 proyectos reales (15 veces menos), las 2.542 variantes de herramientas se comprimieron a 1.

068, las empresas pasaron de 1.427 a 1.115, y las personas de 783 a 590.

Otras 66 pseudoherramientas y 11 "empresas" abstractas ("Holding", "Biblioteca") se mapearon a una cadena vacía. De paso, corregimos dos errores clásicos: un bucle `for t in stack` sobre un campo de tipo cadena en vez de lista, que había generado 96.000 aristas basura hacia letras sueltas del alfabeto (solucionado con una verificación `isinstance(v, list)`), y una explosión de autoenlazado por coincidencia de subcadenas en los títulos que produjo 27.

000 conexiones falsas (solucionado con un filtro de longitud mínima de 5 caracteres y la condición de que una clave no apareciera en más de 4 proyectos, lo que dio 543 aristas `about` precisas).

¿Cuándo bastan dos tablas de SQLite en lugar de un servidor de grafos dedicado?

La primera versión de nuestro grafo vivía en un servidor con FalkorDB (sobre Redis y GraphBLAS). Allí descubrimos que el dialecto Cypher no soporta expresiones regulares `=~` ni `shortestPath()` no dirigido, y debido al conector MCP desactivado y a la necesidad de mantener un túnel SSH, un grafo con 4.743 nodos quedó completamente desconectado de los agentes durante 7 semanas.

Trasladamos todo el grafo a un archivo SQLite local de 15 MB, compuesto por dos tablas (`nodes` y `edges`). A escala de 5.237 nodos y 19.803 aristas, una consulta SQL normal con dos `JOIN` encuentra los proyectos principales por número de herramientas y sesiones (el líder tiene 277 sesiones y 285 herramientas) en 87 ms, mientras que la búsqueda de texto completo con FTS5 sobre medio millón de mensajes responde en 13 ms.

Esta búsqueda híbrida, sin demonios adicionales, está integrada en la arquitectura de [Nomad AI](https://nomadnet.ai) y de la plataforma en la nube [agent.nomadnet.ai](https://agent.nomadnet.ai). Se puede aprender a construir RAG y grafos de conocimiento a nivel profesional en [Hamidun Academy](https://academy.hamidun.com) (con una prueba gratuita de 72 horas disponible), y los scripts de canonización están disponibles en [Vibe Club](https://hamidun.com/club).