Cómo creé Graphify: transformar cualquier entrada en un grafo de conocimiento
TL;DR
Graphify es un motor personal de orquestación de contexto. Toma cualquier entrada (preguntas, archivos, URLs, logs, capturas de pantalla) y la transforma en un grafo de conocimiento indexado. Cuando consulto a Claude con un prompt, Graphify devuelve los 5-10 nodos más relevantes en menos de 50 ms. Resultado: las respuestas de la IA se vuelven coherentes, con fuentes, y ancladas en mis decisiones reales. Es la diferencia entre un LLM que alucina y un asistente que razona.
1. Por qué existe Graphify
Antes de Graphify, mi flujo era así:
- Pregunta complicada sobre un proyecto.
- Buscar el contexto en 15 archivos dispersos (notas de Obsidian, repositorios git, slacks archivados).
- Copiar y pegar fragmentos en el prompt de Claude.
- Respuesta de la IA: a menudo coherente, pero a veces desviada porque no había copiado el detalle que importaba.
El problema: el contexto fragmentado mata la calidad de la respuesta.
Cuantos más proyectos tengo (44 reales, 11 declarados en el inventario), peor se pone. Los LLM no alucinan por malicia: inventan cuando falta información. Incluso con buenos prompts, sin el contexto exacto pierdes entre un 40 y un 60 % de precisión.
Primero probé las soluciones clásicas:
- Obsidian + plugins: bueno para las notas, débil para el retrieval en tiempo real.
- RAG ingenuo (embedding vectorial simple): olvida los metadatos, trae cosas cercanas semánticamente pero irrelevantes.
- Notion + búsqueda full-text: lento y frágil con consultas matizadas.
Ninguna atacaba el problema real: ¿cómo representar el conocimiento para que se encuentre cuando lo necesito?
2. La clave: pensar en grafo, no en documentos
Un grafo dirigido es simple: nodos (entidades: proyectos, decisiones, skills, bugs) y aristas (relaciones: "depende de", "contrasta con", "podría aplicarse a").
Ejemplo: el proyecto "dims_portfolio" tiene un nodo. Sus dependencias (Next.js, Prisma, Tailwind) son nodos. Los artículos publicados (Flutter vs RN, GigaBracket) son nodos. Las decisiones de arquitectura (dual-graph MCP, version-bump antes del commit) son nodos. El grafo codifica los vínculos semánticos, no solo las palabras clave.
Cuando hago una pregunta ("¿Cuál es mi política de versionado?"), Graphify:
- Interpreta la consulta (busca nodos etiquetados "version").
- Recorre el grafo (sube por las aristas).
- Devuelve todos los nodos conectados directamente o a dos saltos.
- Ordena por relevancia (distancia en el grafo, frescura, puntuación del prompt).
- Envía los resultados al contexto de Claude.
Es más robusto que un índice vectorial: las conexiones son explícitas.
3. Arquitectura y motor
Graphify funciona en dos formas: modo local (MCP en el ordenador) y modo servidor (para equipos o escalabilidad).
Modo local (MCP)
- Datos almacenados en SQLite local (
.claude/graphify/db.sqlite). - Proceso MCP que expone tres endpoints:
graph_continue,graph_scan,graph_add_memory. - Latencia: menos de 10 ms para leer, menos de 50 ms para indexar un nodo nuevo.
- Sin red, sin API de terceros: todo permanece privado.
Modo servidor
- PostgreSQL + Supabase RLS (aislamiento por usuario).
- API REST, webhooks para sincronizar.
- Realtime por Websocket (ver en directo lo que un compañero añade al grafo).
Uso el modo local para el portfolio (DIS, Giga, Perso), pero estoy experimentando con el modo servidor para los clientes SaaS.
Indexación
La indexación es semiautomática:
- Escaneos manuales:
graph_scan /path/to/projectlee los archivos, extrae los símbolos (funciones, tipos, tablas de BD) y crea nodos. - Ediciones activas: cuando creo o modifico una decisión, un bug o una etapa de producto, llamo a
graph_add_memorycon una frase + tags + archivos afectados. - Webhooks: los repos git envían un POST a Graphify en cada commit. El título del commit se convierte en un nodo, enlazado a los archivos modificados.
El resultado: el grafo se actualiza pasivamente sin que tenga que pensar "tengo que documentar esto". La fricción es casi cero.
4. Resultados concretos
Antes de Graphify
Prompt: "En dims_portfolio, ¿cuál es la imagen OG del artículo Flutter vs React Native 2026?"
- Tiempo para encontrarla: 2-3 min (buscar en más de 40 archivos mdx, estructura confusa).
- Respuesta de Claude (sin el contexto): "Probablemente flutter-vs-react-native.png".
- Realidad: flutter-vs-react-native-2026.png y flutter-vs-react-native-2026-en.png (se me había olvidado el -en).
Después de Graphify
Prompt: el mismo.
- Tiempo de retrieval: menos de 100 ms (Graphify devuelve el artículo mdx + los assets enlazados + las versiones EN).
- Respuesta de Claude: "flutter-vs-react-native-2026.png y flutter-vs-react-native-2026-en.png. La OG de la versión EN es flutter-vs-react-native-2026-en.png."
- Precisión: 100 %.
Impacto medido
| Métrica | Antes | Después | Mejora | |----------|-------|-------|------| | Tiempo de retrieval del contexto | 2-5 min | menos de 100 ms | 20-50× más rápido | | Alucinaciones de la IA (contexto faltante) | ~40 % | menos del 5 % | 8× menos | | Confianza en las respuestas de la IA | ~60 % | ~95 % | +35 pp | | Tiempo para incorporar una nueva decisión | 5-10 min | 30 s | 10-20× más rápido |
La mejora principal no es la velocidad (aunque 100 ms es bueno). Es la coherencia: la IA siempre tiene la información correcta.
5. Casos de uso reales
Caso 1: decisión de arquitectura en cascada
Quiero cambiar la estrategia de versionado en dims_portfolio. Prompt: "Si paso de version-bump en pre-commit a version-bump en post-merge, ¿qué se rompe?"
Graphify devuelve:
- La decisión actual (version-bump en CLAUDE.md).
- Los 3 últimos commits que tocaron version-bump.
- El propio script version-bump.
- Los 5 artículos que mencionan la estrategia.
- Todos los PRs afectados.
Claude puede entonces listar todos los impactos. Sin Graphify, habría olvidado 2-3 dependencias.
Caso 2: incorporar a un nuevo dev
Compañero: "Llego a GigaBracket, ¿cómo está construido?"
En lugar de pasar 1 h explicando, envío graph_scan /path/to/gigabracket. Graphify devuelve:
- Arquitectura (app/ → pages, components/, lib/ → formats/, pocketbase/)
- Decisiones clave (por qué PocketBase, por qué Next.js 16).
- Stack detallado (Next.js, Tailwind, Radix, next-intl, etc.).
- Los 3 últimos artículos y decisiones sobre este proyecto.
Claude genera un resumen de 2 páginas. El nuevo dev entiende el 80 % en 10 min.
Caso 3: analizar una regresión de rendimiento
Un artículo mdx carga lento. Prompt: "¿Por qué portfolio.ts es lento en producción?"
Graphify devuelve:
- El archivo portfolio.ts.
- Los componentes que lo importan (ProductCard, etc.).
- Las decisiones en torno a ese archivo (por qué está estructurado así).
- Las mediciones de Lighthouse asociadas.
- Los PRs que lo tocaron.
Claude puede analizar las capas de la dependencia. Sin Graphify, es adivinar.
6. Trampas y límites
El problema de la calidad de los datos
Graphify es garbage in, garbage out. Si mis nodos están mal etiquetados o el grafo está desorganizado, los resultados serán erróneos. Dediqué tiempo a estandarizar:
- Nombres de nodos (sin duplicados, convenciones claras).
- Tags (usar un vocabulario controlado, no 20 variantes de "bug").
- Descripciones (una frase, menos de 15 palabras).
Solución: auditar el grafo una vez al mes. Dedicar 30 min a comprobar que ningún nodo quede huérfano o mal categorizado.
Escalabilidad del grafo
Con 44 proyectos × 50-100 nodos por proyecto, estoy en ~5k nodos. Todavía es perfectamente manejable. Pero si subo a más de 10k, el rendimiento se degradará sin optimización (indexación espacial, clustering).
Estrategia: a los 8k nodos, lo divido por tenant (DIS-graph, Giga-graph, Perso-graph). Cada tenant ejecuta su propio grafo. Las consultas entre tenants pasan por una capa de fusión.
El ruido de las falsas conexiones
Cuantos más nodos añado, más riesgo hay de que se cree una arista por error. Ejemplo: "bug" y "bloqueo" pueden parecer relacionados (ambos significan "obstáculo"), pero semánticamente son cosas distintas.
Solución: validación manual antes de hacer commit de las aristas críticas, y una puntuación de confianza por arista (0.7 = probable, 0.95 = confirmada).
7. Cómo lo construí
Stack
- Backend: Node.js 22 + Fastify (modo servidor) o MCP puro (modo local).
- BD: SQLite (local) o PostgreSQL (servidor).
- Motor de grafo: propio (sin Apache Jena ni Neo4j; demasiado pesado para lo que necesito).
- LLM: API de Claude para interpretar las consultas (uso Claude para entender la pregunta antes de rastrear el grafo).
Sí, es recursivo: uso Claude para pedirle a Claude que responda. Pero funciona porque la primera consulta es rápida (solo interpretar), luego Graphify trae el contexto, y la segunda consulta es precisa.
Desarrollo iterativo
No escribí Graphify en una semana. Primero un simple SQLite + scripts bash (octubre de 2024). Después un cliente MCP (diciembre de 2024). Después la capa de API (febrero de 2025). Después el sistema de webhooks git (abril de 2025). Después la optimización del rendimiento (julio de 2026).
Cada versión resolvió un problema concreto. Nada de feature-itis.
8. Lecciones para ti
Si construyes un sistema parecido:
1. Empieza pequeño. Una BD SQLite + 5 nodos de prueba. Añade complejidad cuando la sientas necesaria.
2. Estandariza pronto. Los nombres de los nodos, los tags, los formatos. Una semana normalizando al principio te ahorra horas después.
3. Prueba el retrieval. Inventa 10 preguntas que de verdad harías. ¿Puede Graphify responderlas? Si no, ajusta el grafo.
4. Expón una API simple. Aunque sea solo para ti. Hace posible añadir tooling más adelante (webhooks, cli, UI).
5. Mide y optimiza. Graphify debe tener menos de 100 ms de latencia p99 para ser útil. Si llegas a 500 ms, nadie espera.
6. Prepárate para refactorizar. En 8 meses, mi grafo cambió 3 veces de estructura (de JSON a SQLite, y después de SQLite single-tenant a multi-tenant). Es normal. Mantén las migraciones reversibles.
9. Próximos pasos
Graphify es estable para mi uso en solitario. Los experimentos en curso:
- Multi-tenant SaaS: una versión alojada para agencias. Beta en septiembre de 2026.
- Visualización del grafo: una UI web para explorar el grafo. Por ahora solo texto.
- Auto-extracción: usar Claude para extraer las entidades de los artículos y notas y crear nodos automáticamente. Arriesgado (alucinaciones) pero interesante.
- Time-travel: ver el estado del grafo en una fecha pasada. Útil para depurar o analizar cómo han evolucionado las decisiones.
Conclusión
Graphify no es una herramienta revolucionaria. Es una respuesta simple a un problema real: cómo mantener el contexto coherente cuando tienes 44 proyectos y un cerebro limitado.
La verdadera victoria no es la tecnología. Es haber dejado de usar los LLM como máquinas de generar texto y haberlos convertido en socios de razonamiento. Con el contexto correcto, Claude casi no alucina. Con el contexto equivocado o ausente, hasta GPT-4 se descarrila.
Si tienes proyectos, decisiones dispersas, documentos olvidados por ahí: no necesitas Graphify. Solo una BD y unos cuantos scripts. La idea importa más que la herramienta.
Graphify funciona en producción en todos mis proyectos desde abril de 2025. Código disponible bajo petición (privado por ahora, apertura prevista en 2027 cuando esté más maduro).