Construindo um único Grafo de Conhecimento através de 46 Repositórios

Eu sou Ryan, CTO da airCloset.

Passei três meses construindo o code-graph. É um único grafo de conhecimento que unifica 46 repositórios em múltiplos serviços.

Muitas pessoas pensam que basta entregar todo o seu código para uma IA e fazer perguntas. Isso falha por dois motivos:

  • Janelas de contexto: Você não consegue encaixar anos de código de 46 repositórios em um único prompt.
  • Alucinação: A IA comete erros quando tenta inferir relacionamentos. Ela perde conexões.

Para resolver isso, usei análise estática para construir uma fonte da verdade.

O Desafio: Cruzando Fronteiras

Uma base de código grande é bagunçada. Uma API pode ser chamada por cinco repositórios diferentes. Uma tabela de banco de dados pode ser usada por três serviços diferentes.

Se você olhar apenas para um repositório, perderá a visão completa. Isso é perigoso. Se você alterar o código e não enxergar o real raio de impacto, você quebrará o sistema.

Minha abordagem utiliza tree-sitter para analisar o código em árvores sintáticas. Mas o tree-sitter sozinho não consegue enxergar através das fronteiras dos repositórios.

Eu construí nós de fronteira para resolver isso.

Como funciona:

  • Extraímos relacionamentos dentro de um repo usando tree-sitter.
  • Usamos a TypeScript Compiler API para resolver tipos e variáveis.
  • Usamos o Gemini para lidar com casos dinâmicos que as ferramentas ignoram.

Em vez de pedir para a IA adivinhar, nós damos fatos. Dizemos a ela: "Esta API também é chamada do Repo X". Isso evita alucinações.

A Parte Difícil: O Zoológico de Frameworks

A verdadeira batalha foi extrair essas fronteiras. Cada framework escreve as fronteiras de forma diferente.

Uma equipe usa decoradores NestJS. Outra usa rotas Express. Outra usa jQuery puro. Cada uma cria uma estrutura diferente no código.

Para fazer isso funcionar, tivemos que construir parsers customizados para:

  • NestJS e TypeORM
  • Express e Fastify
  • AngularJS e Redux
  • Diversos esquemas de path-alias

Tivemos que buscar 99% de precisão. Se nossa taxa de conexão for de apenas 90%, a IA perderá 10% das conexões. Em um sistema de produção, esses 10% é onde os bugs se escondem.

Agora realizamos uma verificação diária. Se nossa taxa de conexão cair mais de 5%, recebemos um alerta. Isso detecta quando novos padrões de código quebram nossos parsers.

Limitações Atuais

O grafo não é perfeito.

  • A busca é difícil. Muitas vezes você precisa saber o nome de uma função para iniciar sua busca.
  • Explosão de nós. Seguir um caminho pode trazer milhares de pequenas e inúteis funções auxiliares.
  • Manutenção. Cada vez que um novo framework entra em nossa stack, precisamos escrever um novo parser.

Esta é a Parte 1. Na Parte 2, discutirei a camada service-product-graph (SPG) que construí para corrigir essas lacunas.

Source: https://dev.to/ryantsuji/building-one-knowledge-graph-across-46-repositories-with-static-analysis-part-1-egm

Optional learning community: https://t.me/GyaanSetuAi