Construyendo un único grafo de conocimiento a través de 46 repositorios
Soy Ryan, CTO de airCloset.
Pasé tres meses construyendo code-graph. Es un único grafo de conocimiento que unifica 46 repositorios a través de múltiples servicios.
Mucha gente piensa que basta con entregarle todo el código a una IA y hacerle preguntas. Esto falla por dos razones:
- Ventanas de contexto: No puedes meter años de código de 46 repositorios en un solo prompt.
- Alucinación: La IA comete errores cuando intenta inferir relaciones. Se le escapan las conexiones.
Para solucionar esto, utilicé análisis estático para construir una fuente de verdad.
El desafío: Cruzar fronteras
Una base de código grande es caótica. Una API puede ser llamada por cinco repositorios diferentes. Una tabla de base de datos puede ser utilizada por tres servicios distintos.
Si solo miras un repositorio, te pierdes la visión completa. Esto es peligroso. Si cambias código y no ves el radio de impacto real, rompes el sistema.
Mi enfoque utiliza tree-sitter para analizar el código en árboles de sintaxis. Pero tree-sitter por sí solo no puede ver más allá de los límites de los repositorios.
Construí nodos de frontera para solucionar esto.
Cómo funciona:
- Extraemos relaciones dentro de un repo usando tree-sitter.
- Utilizamos la TypeScript Compiler API para resolver tipos y variables.
- Utilizamos Gemini para manejar los casos dinámicos que las herramientas pasan por alto.
En lugar de pedirle a la IA que adivine, le damos hechos. Le decimos: "Esta API también es llamada desde el Repo X". Esto evita las alucinaciones.
La parte difícil: El zoológico de frameworks
La verdadera batalla fue extraer estas fronteras. Cada framework escribe las fronteras de forma diferente.
Un equipo usa decoradores de NestJS. Otro usa rutas de Express. Otro usa jQuery puro. Cada uno crea una estructura diferente en el código.
Para que esto funcionara, tuvimos que construir parsers personalizados para:
- NestJS y TypeORM
- Express y Fastify
- AngularJS y Redux
- Diversos esquemas de alias de ruta (path-alias)
Teníamos que aspirar a un 99% de precisión. Si nuestra tasa de conexión es de solo el 90%, la IA pierde el 10% de las conexiones. En un sistema de producción, ese 10% es donde se esconden los errores.
Ahora realizamos una comprobación diaria. Si nuestra tasa de conexión cae más de un 5%, recibimos una alerta. Esto detecta cuándo nuevos patrones de código rompen nuestros parsers.
Limitaciones actuales
El grafo no es perfecto.
- La búsqueda es difícil. A menudo necesitas conocer el nombre de una función para empezar la búsqueda.
- Explosión de nodos. Seguir una ruta puede arrastrar miles de pequeñas e inútiles funciones auxiliares.
- Mantenimiento. Cada vez que un nuevo framework entra en nuestro stack, debemos escribir un nuevo parser.
Esta es la Parte 1. En la Parte 2, hablaré sobre la capa de grafo servicio-producto (SPG) que construí para solucionar estas brechas.
Comunidad de aprendizaje opcional: https://t.me/GyaanSetuAi