Graphify, OKF y RAG: ¿Qué capa de contexto necesita tu código?
Las pruebas de referencia muestran que Graphify iguala a vector RAG en precisión. Aquí se explica cómo se relacionan Graphify, OKF de Google y vector RAG, junto con los factores que provocan fallos y una matriz de decisión.
El propio archivo de pruebas de Graphify contiene un resultado que el entusiasmo en torno al proyecto tiende a pasar por alto. En cuanto a la precisión en tareas de respuesta a preguntas cara a cara, empata con RAG de vectores densos, mientras que en cuanto a la capacidad de recuperación queda ligeramente por detrás. Sin embargo, en blogs de desarrolladores se le ha calificado como un “asesino de RAG”, y los equipos empresariales lo han integrado, junto con el Open Knowledge Format (OKF) de Google, en sus agentes de programación basados en IA en el mismo mes. ¿Por qué?
Porque la forma en que se presenta este tema es incorrecta. Graphify y OKF no compiten para reemplazar a RAG. Ambos son capas especializadas, una estructural y otra narrativa, que se añaden junto a un índice vectorial, y cada una solo resulta necesaria debido a un modo específico de fallo en el sistema. Si los consideras como sustitutos de RAG, perderás tiempo de ingeniería manteniendo grafos de conocimiento y paquetes de Markdown curados para problemas que en realidad no tienes.
Lo que sigue explica qué hace cada capa, por qué la verdadera ventaja de Graphify radica en el costo de procesamiento y no en una recuperación superior, además de una matriz de decisión para un conjunto de códigos del año 2026.
Qué dice realmente el archivo de pruebas
Abra BENCHMARKS.md en el repositorio de Graphify y allí encontrará los números que los artículos de lanzamiento omiten.
Empecemos con LongMemEval-S, con 50 muestras. El modo de expansión de grafos de Graphify alcanza una precisión de QA del 76% y un recuerdo de 0.844@10. Una línea de base de RAG vectorial denso con el mismo modelo (Kimi K2.6), el mismo embedder BGE-m3 y presupuestos de tokens iguales también obtiene un 76%, con un recuerdo de 0.848@10. Así que los grafos de conocimiento no ganan aquí: la precisión es igual y el recuerdo es ligeramente menor. Peor aún para el bombo publicitario, el propio proveedor reportó el conjunto de datos y lo validó de forma ciega (90.6% de acuerdo en la calificación, kappa de Cohen de 0.81), por lo que ningún tercero hostil seleccionó un resultado deficiente.
En LOCOMO (n=300), la situación es similar, aunque el criterio importante pasa a ser el costo de ingestión.
Graphify alcanza una precisión del 45,3% y cuesta aproximadamente 1,40 dólares para procesar el conjunto de datos. Supermemory obtiene un porcentaje ligeramente mayor, del 49,7%, pero su costo de ingestión es de 15,67 dólares, casi 11 veces más. Por lo tanto, Graphify tampoco gana en términos de precisión aquí; gana en costo y eficiencia.
Este patrón se mantiene en ambos benchmarks públicos. Graphify no supera a un pipeline RAG vectorial bien ajustado en términos de rendimiento de búsqueda. Empata con el RAG vectorial en precisión, pero su costo de implementación es mucho menor que el de otros sistemas de memoria. Dos características explican su ventaja:
- Costo de ingestión bajo, ya que el análisis AST no requiere llamadas a la API de LLM en absoluto.
- Extracción estructural sin riesgo de alucinaciones, ya que el análisis determinista con Tree-sitter identifica con precisión las relaciones entre códigos (llamadas, importaciones, herencia de clases) sin que ningún modelo participe en ese proceso.
Para quienes han leído que Graphify reemplaza a las bases de datos vectoriales, esto cambia el enfoque de la pregunta. La decisión no radica en determinar qué herramienta gana, sino en saber qué capa gestiona qué contexto y qué modo de fallo en la pila de agentes aún no se ha abordado.
Tres capas en lugar de tres competidores
Las elecciones arquitectónicas sólidas requieren separar la realidad técnica del lenguaje de marketing. Las configuraciones modernas de agentes se basan en tres capas de contexto distintas.
┌─────────────────────────────────────────────────────────────────┐
│ AI CODING AGENT CONTEXT │
└────────────────────────────────┬────────────────────────────────┘
│
┌─────────────────────────────┼─────────────────────────────┐
▼ ▼ ▼
┌───────────────────┐ ┌───────────────────┐ ┌───────────────────┐
│ VECTOR RAG │ │ GRAPHIFY │ │ GOOGLE OKF │
│ (Unstructured) │ │ (Structure) │ │ (Narrative) │
├───────────────────┤ ├───────────────────┤ ├───────────────────┤
│ • Docs & Tickets │ │ • AST Call Graphs │ │ • Architecture │
│ • Slack Threads │ │ • Class Hierarchies│ │ • Data Schemas │
│ • Long Tail Text │ │ • Imports/Exports │ │ • Playbooks & Run │
└───────────────────┘ └───────────────────┘ └───────────────────┘
Vector RAG
Vector RAG divide el texto no estructurado en bloques de tokens de tamaño fijo (por ejemplo, 512 tokens), los incrusta en un espacio vectorial y, al recibir una consulta, devuelve los k vecinos más cercanos. Es rápido, económico y adecuado para documentación plana e independiente.
Su defecto fundamental es estructural: aplana la jerarquía. Un análisis de Prism Labs de 2026 lo expresa así: cuando la causa y el efecto no se encuentran en el mismo bloque de 512 tokens, el sistema no tiene idea de que están relacionados. Los modelos de incrustación más avanzados no pueden solucionar esto, ya que forma parte inherente del proceso de dividir el texto en bloques.
Graphify
Graphify es un motor local y determinista. Realiza el análisis sintáctico mediante Tree-sitter en más de 36 lenguajes de programación, incluidos Python, TypeScript, Go, Rust, Java, C/C++, Swift, SQL y Terraform/HCL; extrae los elementos del código y construye un grafo estructural con aristas tipadas como calls, imports, inherits y mixes_in.
Cada arista lleva una etiqueta. EXTRACTED indica que fue leída directamente del AST con total confianza, mientras que INFERRED significa que fue generada mediante una heurística con menor confianza. Además, Graphify aplica el método de detección de comunidades de Leiden para separar los subsistemas naturales y marca los “nodos divinos”, es decir, archivos altamente centrales que interactúan con muchos módulos.
Al ejecutar /graphify . se generan tres archivos locales:
graph.htmles una representación visual interactiva del gráfico.GRAPH_REPORT.mdes un resumen escrito de los subsistemas de la base de código.graph.jsones el índice legible por máquinas y susceptible de consultas.
Formato de Conocimiento Abierto
Google Cloud anunció OKF en junio de 2026. No se trata de un algoritmo de recuperación ni de un motor de base de datos. Es una especificación de metadatos en Markdown neutral con respecto a los proveedores. Un paquete es un directorio de archivos Markdown en formato UTF-8 simples con poco contenido preliminar en YAML, donde solo un campo, type, es obligatorio. Un encabezado tiene este aspecto:
---
type: Architecture Concept
title: Payment Gateway Routing
description: Canonical sequence for multi-tenant payment provider dispatch.
tags: [billing, architecture]
---
No existe un registro de esquemas ni un entorno de ejecución pesado. Los paquetes están diseñados para almacenarse en Git y ser leídos con herramientas habituales de la terminal como cat. Lo que almacena OKF es una memoria institucional cuidadosamente seleccionada, escrita por personas o redactada por agentes: la narrativa estable de por qué los sistemas se construyen de la manera en que lo hacen, y no símbolos de código en bruto ni registros de chat sin procesar.
Cómo dividen el trabajo las capas
Juntas, dividen la tarea: Graphify extrae lo que el código es, OKF captura lo que los ingenieros saben, y vector RAG se encarga del resto no estructurado.
De un tuit a un repositorio con 63K estrellas en 90 días
La prisa por adoptar estas herramientas cobra más sentido si se considera el cronograma, ya que todo el ecosistema surgió dentro de un único período de 90 días.
2026-04-01: Karpathy posts "LLM Wiki / Knowledge Compiler" concept on X
│
2026-04-03: Safi Shamsi launches Graphify on GitHub (YC S26)
│
2026-06-01: Graphify reaches 58.3K GitHub stars & 1.2M PyPI downloads
│
2026-06-12: Google Cloud releases Open Knowledge Format (OKF) spec
│
2026-07-01: Graphify ↔ OKF hybrid integration toolkit ships (71.5x token claim)
│
2026-07-05: Graphify hits ~78K stars; Level Up Coding scrutinizes "70x token" claims
La misma secuencia en prosa:
- 1 de abril de 2026: Andrej Karpathy comparte un experimento mental en X: colocar artículos de investigación, notas del código, capturas de pantalla y documentos de arquitectura en una sola carpeta, y luego consultarlos mediante una IA que entienda cómo se relacionan, con los LLMs desempeñando el papel de “compiladores de conocimiento”.
- 3 de abril de 2026: Safi Shamsi publica Graphify en GitHub, convirtiendo esa idea en un proyecto en 48 horas. Se une al lote S26 de Y Combinator.
- 1 de junio de 2026: el proyecto supera las 58,300 estrellas en GitHub y 1.2 millones de descargas desde PyPI.
- 12 de junio de 2026: Google Cloud presenta OKF junto con su especificación abierta, paquetes de ejemplos (comercio electrónico GA4, Stack Overflow y Bitcoin) y un agente que extrae metadatos de BigQuery.
- 15 de junio de 2026: El Catálogo de Conocimientos de Google Cloud ahora procesa de forma nativa los paquetes OKF y los entrega a los agentes de IA empresarial.
- 1 de julio de 2026: Llega una herramienta que conecta Graphify y OKF en ambas direcciones. Los gráficos de código de Graphify se exportan como catálogos en formato markdown OKF mediante divulgación progresiva, lo que supone un ahorro en tokens de consulta de hasta 71.5 veces en comparación con leer archivos en bruto.
- 5 de julio de 2026: Graphify se acerca a las 78,000 estrellas, y publicaciones técnicas como Level Up Coding comienzan a cuestionar las afirmaciones sobre su eficiencia.
Andrus, al escribir durante ese período de análisis crítico, señaló que un ahorro cercano a 70 veces depende de una característica de un proyecto que casi ningún artículo posterior menciona abiertamente. Dicha característica es la topología del corpus. La prueba que sustenta la cifra de 70 veces utilizó un conjunto específico de 52 archivos (los repositorios públicos de Karpathy, 5 artículos de investigación y 4 diagramas); en bases de código empresariales con estructuras de paquetes simples o monorepos enormes, el ahorro en tokens varía enormemente.
¿Qué fallos justifican la adición de alguna de estas herramientas?
El entusiasmo no es un requisito arquitectónico, al igual que la insatisfacción vaga con la configuración actual de RAG. Una nueva infraestructura necesita un modo de fallo concreto y observable como base.
Primero, una verificación de la realidad
Las encuestas en toda la industria indican que la proporción de implementaciones empresariales de RAG que no cumplieron con las expectativas o fallaron por completo en un año es del 72%. La mayoría de esas fallas se deben a un procesamiento deficiente de los datos, índices vectoriales obsoletos o modelos de incrustación inadecuados, y no a la falta de una base de datos gráfica. Un grafo de conocimiento integrado en un pipeline de recuperación defectuoso solo genera ese mismo problema además de otros costos adicionales de operación.
┌─────────────────────────────────────────┐
│ Does your AI coding agent underperform? │
└────────────────────┬────────────────────┘
│
┌──────────────────┴──────────────────┐
▼ ▼
[ Sifting multi-file code ] [ Loss of tribal context ]
[ dependencies & calls ] [ across team silos ]
│ │
▼ ▼
Multi-Hop Reasoning Failure Knowledge Sprawl Failure
│ │
▼ ▼
TRIGGER: Add Graphify TRIGGER: Add Google OKF
(AST Structural Graph) (Curated Narrative Spec)
Desencadenante uno: fallos en el razonamiento multi-hop (añadir Graphify)
Este problema surge cuando una respuesta depende de conectar datos de varios archivos que nunca comparten un mismo fragmento de texto.
Un síntoma típico es que el agente no puede responder a preguntas como "¿qué se rompe en la capa API si cambia el esquema en db/migrations/04_users.sql?"
Dado que RAG vectorial incrusta cada bloque de forma independiente, no tiene conocimiento alguno sobre referencias de claves foráneas, implementaciones de interfaces o llamadas entre archivos. Mejores instrucciones o ventanas de contexto más grandes no ayudarán, ya que esas relaciones nunca llegaron al espacio vectorial.
Desencadenante dos: conocimiento tribal disperso (añadir OKF)
Este problema aparece cuando el contexto institucional importante está distribuido en canales de Slack, páginas de wiki desactualizadas y la memoria no escrita de los desarrolladores.
El síntoma aquí es la existencia de agentes que generan código sintácticamente válido pero que violan las pautas arquitectónicas internas, utilizan APIs internas obsoletas o ignoran las reglas de negocio específicas del dominio.
Graphify no puede ayudar, ya que los analizadores AST solo leen el código fuente y no pueden extraer la intención de negocio. OKF llena esta brecha con una estructura ligera en formato Markdown versionada con Git, donde los ingenieros registran convenciones de sistema estables que los agentes pueden analizar de manera fiable.
Las investigaciones sobre RAG en el ámbito legal revelaron que las herramientas estándar de recuperación generan información errónea en entre el 17 % y el 33 % de las consultas complejas, ya que la recuperación por sí sola no modela la lógica que existe entre los documentos. La guía de Atlan resume el orden lógico: primero RAG, y luego un grafo cuando la profundidad se convierta en un cuello de botella.
Costo de cada herramienta cuando falla
Cada capa adicional introduce sus propios modos de fallo. Ambos proyectos son recientes, por lo que sus riesgos operativos requieren atención antes de su uso en producción.
Dónde falla Graphify
- Instantáneas obsoletas. El índice del grafo se crea una sola vez y permanece estático. No se actualiza cuando los desarrolladores editan archivos, por lo que, sin un hook de pre-commit de Git o un paso de CI/CD, se desvía del código original. Un grafo estructural obsoleto es peor que ninguno, ya que el agente proporciona respuestas erróneas con total confianza.
- Comunidades ruidosas en monolitos heredados. En aplicaciones grandes de Java o C++, la detección de Leiden a menudo agrupa módulos no relacionados simplemente porque todos utilizan infraestructura compartida como singulares de registro o telemetría.
- Alucinaciones en el enriquecimiento semántico. La fase de procesamiento del código principal es determinista, pero la fase semántica opcional que analiza documentación, PDFs e imágenes sigue utilizando un LLM. Por lo tanto, las relaciones extraídas de estos archivos no relacionados con código pueden ser falsas.
- Afirmaciones no verificadas. Según el arquitecto de software Saurabh Sharma, nadie fuera del proyecto ha reproducido una comparación entre las consultas de gráficos de Graphify y los archivos originales, ni un punto de referencia RAG en un conjunto de pruebas compartido. Los números proporcionados por los proveedores deben considerarse solo como una orientación aproximada.
Donde OKF falla
- Falta de control o validación. El formato excluye deliberadamente los registros de esquemas y las reglas estrictas, por lo que la calidad de un paquete depende exclusivamente de quien escriba los archivos.
- Decadencia silenciosa. El contrato básico indica a los agentes que toleren tipos de metadatos desconocidos y enlaces rotos. Esto acelera la adopción, pero permite que los paquetes se conviertan en archivos desvinculados y obsoletos sin generar ningún error de compilación.
- Carga de mantenimiento. Los documentos en Markdown requieren una disciplina constante. Si los flujos de trabajo de ingeniería no exigen actualizaciones de OKF junto con los cambios en el código, la capa narrativa se vuelve rápidamente obsoleta.
El pipeline combinado en la práctica
Para bases de código empresariales complejas, la mejor configuración para 2026 no consiste en elegir una sola herramienta, sino en vincularlas en un pipeline de contexto de múltiples etapas.
┌──────────────────────────────────────────────────────────────────┐
│ USER / AGENT QUERY: "What breaks if I modify UserService.py?" │
└─────────────────────────────────┬────────────────────────────────┘
│
▼
┌──────────────────────────────────────────────────────────────────┐
│ STAGE 1: OKF Progressive Disclosure Catalog │
│ Read high-level module narrative & owner specs (~2K tokens) │
└─────────────────────────────────┬────────────────────────────────┘
│ (Targeted node identified)
▼
┌──────────────────────────────────────────────────────────────────┐
│ STAGE 2: Graphify Structural Graph Query │
│ Traverses AST edges: calls, imports, inherits (Zero-LLM cost) │
└─────────────────────────────────┬────────────────────────────────┘
│ (Unstructured edge cases)
▼
┌──────────────────────────────────────────────────────────────────┐
│ STAGE 3: Vector RAG / Sparse Search │
│ Search raw Slack incident logs, GitHub issues, & PR comments │
└──────────────────────────────────────────────────────────────────┘
Paso uno: generar los artefactos estructurales de Graphify
Instale Graphify en un entorno aislado y luego ejecute el analizador en el espacio de trabajo.
# Install Graphify via uv
uv tool install graphifyy
# Register the skill with your local agent environment (Claude Code, Cursor, Codex, Gemini CLI)
graphify install
# Execute AST graph compilation inside your repository root
/graphify .
# Generated Local Artifacts:
# graph.html --> Interactive visual network representation
# GRAPH_REPORT.md --> Natural language summary of communities & god nodes
# graph.json --> Queryable AST relational graph database
Una vez que esto esté completo, se puede consultar directamente el índice estructural local para inspeccionar las rutas de relación.
# Query dependency paths between components
graphify path "UserService" "DatabasePool"
# Trace architectural blast radius before refactoring
graphify query "What components depend on AuthTokenValidator?"
Paso dos: escriba los conceptos seleccionados como OKF
Exporte lo que encontró la fase estructural a un paquete de conceptos compatible con OKF en .well-known/okf/ o docs/knowledge/. Un archivo de concepto mínimo utiliza enlaces normales de Markdown, y esos enlaces se corresponden directamente con los bordes del grafo de conocimiento.
---
type: Database Table Context
title: orders_fact
description: Canonical order transaction table joining billing and fulfillment streams.
resource: bigquery://production-data.commerce.orders_fact
tags: [finance, core-model]
timestamp: 2026-06-20T14:00:00Z
---
# Business Domain Summary
The `orders_fact` table serves as the primary source of truth for revenue calculations.
Modifications to columns must align with the [Customer Profile Spec](./customer_profile.md).
# Schema & Join Constraints
| Column Name | Data Type | Structural Constraint |
|---|---|---|
| `order_id` | STRING | Primary Key; joins with [billing_events](./billing_events.md) |
| `customer_id` | STRING | Foreign Key; see [customers](./customers.md) |
| `status` | STRING | Enum: `pending`, `completed`, `refunded` |
# Related Runbooks
- Incident Protocol: [/runbooks/billing-reconciliation.md](/runbooks/billing-reconciliation.md)
Kopp, especialista en búsquedas e ingeniería de contexto, señala que la estructura de enlaces de OKF se adapta perfectamente a GraphRAG, ya que un enlace desde orders_fact.md hacia customers.md ya constituye un arco en un grafo de conocimiento.
Evidencia de ERPNext
El enfoque combinado se probó en ERPNext, un código empresarial de código abierto con más de un millón de líneas de Python y JavaScript.
Las evaluaciones utilizaron Claude Opus 4.8, con un límite de 14 turnos por tarea:
- Un agente de programación de referencia que empleaba RAG vectorial y grep logró una cobertura del 70.8% de los hechos clave.
- El pipeline híbrido Graphify y OKF alcanzó una cobertura del 82.0% de los hechos clave, con un promedio de unos 140,000 tokens por sesión de consulta.
Un aumento de 11.2 puntos en una base de código de ese tamaño significa un número notablemente menor de errores en la ejecución de los agentes. Esto refleja mejor el valor en entornos de producción que las cifras de reducción de tokens sintéticos.
Elegir según el tipo de base de código
Encuentre su entorno de base de código y su principal modo de fallo en la matriz para seleccionar una arquitectura adecuada.
La versión breve
Graphify es el más eficaz para el análisis estructural determinista sin costos asociados a APIs de LLM. OKF ofrece un estándar portátil y compatible con Git para el contexto generado tanto por personas como por agentes. Vector RAG sigue siendo la opción más efectiva para buscar texto no estructurado. Apilar capas sin un modo de fallo claro añade complejidad y no mejora el rendimiento de los agentes.
Defina el problema primero
Antes de que Graphify u OKF ingresen al proceso de desarrollo, decida cuál de los tres problemas es real: un contexto de código obsoleto, fallos en dependencias de múltiples niveles o conocimiento institucional fragmentado.
Ambas herramientas son adiciones útiles a una pila de IA moderna, y los resultados de ERPNext demuestran un valor real en bases de código complejas. Sin embargo, el paso de un tuit a un repositorio viral es una razón más para actuar con rigor. Lea los datos directamente en BENCHMARKS.md, pruebe las arquitecturas candidatas en su propio código y cree una pila de contexto que se adapte a sus necesidades de ingeniería. Combinar su configuración con las condiciones de monolito, microservicios o monorepo en la matriz es un buen punto de partida.
Leer más
- RAG avanzado en Milvus: Búsqueda híbrida, HyDE, reescritura de consultas y reclasificación — Construye un pipeline RAG para Milvus paso a paso: vectores densos y BM25, búsqueda híbrida RRF, filtros de metadatos, reescritura de consultas, HyDE, descomposición y reclasificación con cross-encoder.
- Un LLM local útil en 30 minutos: programación, preguntas y respuestas en documentos y voz — Crea un asistente de programación local, un script de búsqueda de notas y un sistema de voz sin conexión con Ollama, Qwen3 y Whisper.cpp, además de las reglas de ancho de banda de memoria para elegir el tamaño del modelo.