Benchmark de Ferramentas de Busca de Código: Conhecendo o Desempenho

codegraph tem 19.459 estrelas no GitHub. Nós temos zero. Então paramos de falar e começamos a medir.

A Manchete

P@10 = fração dos 10 melhores resultados que são relevantes para a tarefa. Quanto maior, melhor.

knowing é 1.53x mais preciso que codegraph (19K estrelas, tree-sitter + FTS5).
knowing é 2.76x mais preciso que GitNexus (grafo de conhecimento MCP).
knowing é 3.29x mais preciso que Gortex (motor de grafo Go, 256 linguagens).
knowing é 15.9x mais preciso que grep.

Por que 19K Estrelas Não Significam Nada

codegraph usa tree-sitter + FTS5 + pontuação heurística (bônus de co-localização, correspondência de múltiplos termos, correspondência de limites CamelCase). Sem classificação teórica de grafos. Sem caminhada aleatória. Sem propagação estrutural.

knowing usa Random Walk com Reinício em um grafo de chamadas endereçado por conteúdo. A caminhada propaga relevância através da estrutura de dependência real: "esta função chama aquela, que implementa esta interface, que é testada por aqueles testes." Relevância estrutural, não coincidência de strings.

O resultado: codegraph encontra símbolos que contêm suas palavras-chave. knowing encontra símbolos que são estruturalmente relevantes para sua tarefa. Essas são frequentemente coisas diferentes.

Análise por Repositório

Repositórios com hierarquias de classes bem estruturadas e documentação têm melhor desempenho (Flask 0.332, Terraform 0.275, Kafka 0.253). O FTS de docstring do knowing aproveita diretamente a documentação escrita pelos desenvolvedores como um sinal de recuperação, e a propagação de herança cria caminhos através das hierarquias de classes. Mesmo o repositório mais fraco (Cargo 0.132) supera o melhor do grep (0.013).

Latência de Consulta: 500x Mais Rápido em Repositórios Empresariais

codegraph consulta Kubernetes em cerca de 1 segundo (BM25, sem caminhada de grafo). knowing com seu cache de adjacência pré-computado: 2 milissegundos. Isso é 500x mais rápido.

O cache é construído uma vez no tempo de indexação e carrega todo o grafo em uma leitura do SQLite. O RWR então roda inteiramente na memória. A melhoria de 4.717x (de 9s sem cache para 2ms com cache) é uma vantagem estrutural do cache endereçado por conteúdo: o mapa de adjacência é determinístico, então nunca precisa de invalidação, exceto na reindexação.

Tempo até a Consistência: Novo Código em 167ms

Você adiciona uma função. Quão rapidamente cada sistema a encontra?

Protocolo: injete validate_authentication_token() no Flask, acione reindexação incremental, consulte por ele.

O IndexFilesIncremental do knowing leva 16ms (constante, independentemente do tamanho do repositório). O sync do codegraph reescaneia todo o repositório (escala linearmente). O Aider reanalisa tudo em cada consulta e ainda não encontra a nova função.

Por que Aider fundamentalmente não pode encontrar novo código: Uma função recém-adicionada sem chamadores tem zero grau de entrada, então o PageRank atribui a ela peso mínimo. Ela nunca aparecerá nos resultados classificados até que outro código a chame. Isso significa que toda vez que você escreve uma nova função, o contexto do Aider é cego para ela. knowing a encontra por meio da correspondência de palavras-chave FTS, contornando a necessidade de conectividade de grafo.

Eficiência do Agente: 99.9% de Eliminação de Ruído

Em Kubernetes (3.5M LOC), um agente fazendo grep Handler obtém 1.284 correspondências. Para "Controller": 14.896 correspondências. O agente deve ler/filtrar todas elas.

knowing retorna 10 resultados classificados com 72% de taxa de acerto de verdade fundamental. codegraph retorna 28/50. GitNexus retorna 0 (não consegue lidar com k8s de forma alguma).

A vantagem não é apenas a precisão. É que knowing entrega 10 resultados de 10.840 candidatos. Isso é 99.9% de eliminação de ruído antes que o agente veja qualquer coisa.

Determinismo: Mesma Pergunta, Mesma Resposta

Executamos a mesma tarefa 10 vezes por sistema.

GitNexus dá uma resposta diferente quase toda vez que você pergunta. Aider varia moderadamente. Você não pode testar regressão em um sistema de contexto não determinístico. Você não pode depurar o comportamento do agente se o contexto mudar entre execuções.

O determinismo do knowing é estrutural: o PackRoot endereçado por conteúdo garante que a mesma entrada produza a mesma saída. Sempre.

O Panorama Completo dos Concorrentes

Benchmarkamos todas as ferramentas de recuperação de código que pudemos encontrar.