Benchmarks de Graph Indexer

Graph Indexer coincide con el propio compilador del lenguaje al buscar referencias: 99,7 % de precisión y 96,2 % de recall frente al compilador de TypeScript en 400 símbolos de nestjs, donde grep por los mismos nombres llega al 12,8 % de precisión. En sesiones reales de Claude Code, los agentes con Graph Indexer respondieron 12 de 12 preguntas de código con exactitud frente a 9 de 12 sin él, y salieron más baratos que sin índice; en las rondas con subagentes también salieron más baratos que con grep solo. Todas las cifras vienen de los documentos públicos de benchmarks y del benchmark agéntico, medidas con Graph Indexer 3.0.0.

¿Cómo se miden los benchmarks de Graph Indexer?

Graph Indexer se evalúa contra los compiladores reales, no contra opiniones. De cada repositorio se toma una muestra aleatoria con semilla de funciones, métodos, clases e interfaces. Para cada símbolo, un oráculo construido sobre el front end del propio lenguaje lista todas las líneas que de verdad lo referencian, y la respuesta de find_references se compara con él a nivel de file:line.

Del resultado del compilador se derivan dos oráculos. El oráculo de dispatch cuenta las referencias al propio miembro, a los miembros que sobrescribe o implementa (una llamada a través del tipo base puede terminar ahí) y a sus propias sobrescrituras. Es lo que promete find_references, y todas las tablas de abajo lo usan con promedios micro salvo que se indique otra cosa. El oráculo de rename es más estricto: todo lo que el compilador tocaría en un renombrado, incluidas las llamadas a sobrescrituras hermanas.

Sobre la misma muestra corren dos líneas base. grep es cada línea que contiene el nombre como palabra completa, sin imports. Solo nombre es cada referencia sintáctica con ese nombre, sin enlazarla a una definición. La precisión es la proporción de líneas devueltas que son referencias reales; el recall es la proporción de referencias reales que se devolvieron.

¿Qué muestras se usaron?

La muestra de TypeScript son 400 símbolos de packages/core y packages/common de nestjs (semilla 11), más una segunda muestra de 149 símbolos (semilla 7). Go y Java usan la semilla 7 con entre 111 y 200 símbolos por repositorio. Twenty usa 400 símbolos de packages/twenty-server/src (semilla 11). Todos los repositorios son públicos y están fijados a commits exactos.

¿Qué precisión y recall tiene Graph Indexer por repositorio?

Graph Indexer alcanza entre un 95,5 % y un 100 % de precisión y entre un 86,1 % y un 98,9 % de recall en ocho repositorios de tres lenguajes, mientras que la precisión de grep va del 0,9 % al 60,9 %. Cada fila se mide contra el compilador o el comprobador de tipos del lenguaje.

Cómo leer la tabla: en nestjs, una búsqueda por nombre devuelve unas siete coincidencias falsas por cada referencia real. Graph Indexer enlaza cada referencia con la definición a la que apunta, así que casi todas desaparecen. En nestjs el conjunto exacto de referencias coincide con el del compilador en el 91,5 % de los símbolos; en gin, en el 98,6 %.

El recall de grep ronda el 99 % en estas muestras por construcción, porque devuelve toda coincidencia textual. El recall de Graph Indexer es menor, y las referencias que se le escapan se listan como llamadas con el mismo nombre que no pudo enlazar, de modo que el agente sabe qué revisar.

¿Se mantiene en un monorepo grande?

Sí. En el código de servidor de Twenty (28.512 archivos, 2,3 millones de líneas) Graph Indexer llega al 99,9 % de precisión y al 92,4 % de recall, frente al 0,9 % de precisión de grep. Lo que sigue sin detectar allí son llamadas por uniones y objetos registro, implementadores en literales de objeto y builders fluidos a través de this genérico.

¿Cómo rinden los agentes con y sin Graph Indexer?

En sesiones reales de Claude Code, un agente con Graph Indexer respondió 12 de 12 preguntas de código con exactitud en nestjs, frente a 9 de 12 sin él; los tres fallos fueron preguntas sobre llamadores a dos niveles. Las sesiones las califica un oráculo oculto (el compilador de TypeScript, el comprobador de tipos de Go o tests ocultos de arreglos reales), con el mismo modelo, tarea y repositorio en todas las ramas.

El coste se mide en tokens equivalentes de entrada (entrada, escrituras de caché, lecturas de caché y salida ponderadas por precio). Tiempos y costes comparan ejecuciones emparejadas de la misma tarea. La ronda de Go la calificó el comprobador de tipos de Go sobre caddy 2.8.4.

¿Por qué gana más un modelo más pequeño?

Con un modelo más pequeño, los agentes solo con grep gastaron muchas más llamadas: 29,9 por pregunta frente a 9,0 con Graph Indexer. Las respuestas exactas de find_references sustituyen largas cadenas de búsquedas y lecturas de archivos. Las 7 preguntas de esa ronda son una muestra pequeña, y la diferencia de aciertos (7/7 frente a 5/7) no es estadísticamente significativa.

¿Dónde no ahorra dinero Graph Indexer?

Al arreglar una incidencia real a partir de un informe de error, el ahorro no fue medible. En esas sesiones el agente muchas veces ni llamó al índice, y el coste quedó a pocos puntos porcentuales del de no tener índice. Las reglas breves de búsqueda que escribe init en las instrucciones del agente aportan allí casi toda la mejora, no las herramientas. Graph Indexer está pensado para preguntas de código, refactors y renombrados, donde una respuesta exacta sustituye muchas conjeturas.

¿Qué tan rápido es Graph Indexer?

Graph Indexer indexa más de 45.000 líneas de código por segundo: el monorepo Twenty (28.512 archivos, 2.327.185 líneas, 170.126 símbolos, 554.975 referencias) se indexa por completo en 51 segundos y el índice ocupa 304 MB. Tras la primera construcción solo se reprocesan los archivos cambiados, así que resincronizar nestjs sin cambios tarda unos 0,2 segundos.

Las llamadas en caliente sobre nestjs (mediana de 5) tardan 1,1 ms en find_references, 1,2 ms en get_symbol, 1,4 ms en call_graph y 3,7 ms en change_impact, así que cada herramienta de grafo responde en menos de 4 ms. outline tarda unos 18 ms y search_code unos 30 ms. Las ocho definiciones de herramientas ocupan unos 2.400 tokens de contexto del agente y las respuestas típicas son de 400 a 1.500 tokens. Consulta las 8 herramientas MCP y cómo funciona.

¿Cuáles son los límites de estos benchmarks?

Las cifras son buenas y vienen con límites publicados. Tómalas así.

• No es un comprobador de tipos. Graph Indexer infiere tipos lo bastante bien como para enlazar la mayoría de referencias, pero los genéricos, la reflexión, los valores any y los tokens de inyección de dependencias quedan en parte invisibles. Se notan como menos recall, no como respuestas erróneas.
• La precisión en nestjs es una cota inferior. El fixture no tiene node_modules, así que los valores tipados por librerías son any para el compilador. Algunas referencias que Graph Indexer encuentra bien cuentan como falsos positivos.
• Los arreglos se afinaron con estas muestras. El trabajo de precisión iteró sobre fallos de las mismas muestras. La segunda muestra de TypeScript (semilla 7) muestra lo que queda en símbolos nuevos: 99,9 % de precisión y 88,7 % de recall.
• Java es el lenguaje más débil de los medidos. El recall baja al 86,1 % en commons-collections.
• Las muestras de agentes son pequeñas. La mayoría de las rondas usan una ejecución por tarea y rama. Las diferencias de coste por debajo del 20 % aproximado caen dentro del ruido, y con el modelo usado casi todas las tareas se resuelven en todas las ramas, así que el benchmark mide sobre todo coste y tiempo.
• Sin ahorro al arreglar incidencias reales. Ver arriba.

Para ver el resto de lenguajes y la profundidad de soporte de cada uno, consulta los lenguajes soportados.

¿Cómo puedo reproducir los benchmarks de Graph Indexer?

Clona el repositorio, instala Node.js 22.5 o superior y ejecuta los scripts de la carpeta bench/. Los repositorios son públicos y están fijados a commits exactos; una vez clonados, los oráculos se ejecutan en local.

node bench/fixtures.mjs                      # clona los repositorios fijados en test/fixtures/
node bench/eval-graph.mjs --n 400 --seed 11  # oráculo del compilador de TypeScript (necesita el paquete typescript)
node bench/eval-graph-go.mjs --n 150         # oráculo go/types (necesita Go 1.22+)
node bench/eval-graph-java.mjs               # oráculo del front end de javac (necesita un JDK 17+)

Las rondas de agentes las dirige bench/agentic/; los comandos exactos están en la sección Reproducing del benchmark agéntico. Para comparar con grep por tu cuenta, lee Graph Indexer vs grep y los resultados de la página principal.