Benchmark de recuperação de código para agentes de codificação de IA em 60 tarefas
Um grep ajustado superou meu servidor de inteligência de código MCP em F1 por 9 pontos.
Estou publicando o resultado de qualquer maneira. Aqui está o porquê.
Por que este benchmark existe
Passei os últimos seis meses construindo sverklo, um servidor MCP local-first que fornece aos agentes de codificação de IA (Claude Code, Cursor, Windsurf) um verdadeiro gráfico de símbolos em vez de correspondência de padrões baseada em grep. O posicionamento do produto sempre foi "impede o agente de alucinar nomes de funções que não existem em seu código".
Esse posicionamento é vago sem números. Seis meses depois, eu não tinha um benchmark público. Qualquer história de velocidade de iteração que eu contasse a mim mesmo era apenas isso, uma história.
Então eu construí um: 60 tarefas de recuperação verificadas manualmente em dois verdadeiros repositórios de código OSS (expressjs/express e o repositório sverklo em si), três linhas de base (grep ingênuo, grep inteligente, sverklo) e métricas que medem tanto a qualidade da recuperação (F1, recall, precisão) quanto a coisa que os agentes de IA realmente pagam (tokens de entrada, chamadas de ferramentas, tempo total).
Os resultados estão disponíveis em sverklo.com/bench. As saídas JSONL brutas estão no repositório em benchmark/results/<timestamp>/. O sistema funciona em um comando npm. Desacordos com meus números são úteis — registre um problema com a especificação da sua máquina.
A manchete
| linha de base | F1 | tokens | chamadas de ferramentas |
|---|---|---|---|
| grep-ingênuo | 0.35 | 15,814 | 7.6 |
| grep-inteligente (ajustado) | 0.67 | 731 | 11.8 |
| sverklo | 0.58 | 255 | 1.0 |
Um grep ajustado supera sverklo em F1 por 9 pontos. Isso não era o que eu esperava quando comecei a construir isso. Se você consegue escrever uma invocação limpa do ripgrep com filtros de linguagem e padrões em forma de definição, você obtém um F1 mais alto do que minha pilha de recuperação híbrida retorna.
O que sverklo ganha:
- 62× menos tokens do que o grep ingênuo (255 vs 15,814)
- 2.9× menos tokens do que o grep inteligente (255 vs 731)
- 1 chamada de ferramenta vs 7-12 do grep por tarefa
- ~1ms de tempo total após um início a frio de 3.7 segundos (a construção do índice)
Por que "tokens por resposta correta" é a métrica fundamental
Se você está em um terminal com rg, F1 é o que importa. Você lê as correspondências. O agente não está pagando por elas.
Se você é um agente de IA com uma janela de contexto de 200K tokens, cada token tem um custo de oportunidade. Queimar 15,000 tokens em ruído do grep para encontrar uma função deixa você com 14,750 tokens a menos para a mudança real. O agente que obtém a resposta em 255 tokens tem 14,750 tokens a mais para gastar fazendo o trabalho.
A métrica que realmente importa é tokens por resposta correta: tokens de entrada divididos pelo recall. O benchmark relata isso para execuções com e sem restrições (F1 ≥ 0.8). Para sverklo no subconjunto restrito, são 203 tokens por resposta correta. Para grep ingênuo, 3,557. Para grep inteligente, 165 — o grep inteligente é genuinamente competitivo em custo por resposta correta quando seu F1 é alcançado.
O erro que quase cometi: otimizar para F1. A coisa que os agentes de codificação de IA realmente precisam é a recuperação correta mais barata, não a recuperação de alta precisão que leva 12 chamadas de ferramentas para montar.
Por categoria: onde cada linha de base brilha
| Categoria | Melhor F1 | Melhor economia de tokens |
|---|---|---|
| P1 — Busca de definição (n=20) | sverklo (0.75) | grep inteligente (196 tok) |
| P2 — Busca de referência (n=20) | grep inteligente (0.81) | sverklo (157 tok) |
| P4 — Dependências de arquivo (n=10) | sverklo (0.86) | sverklo (74 tok) |
| P5 — Código morto (n=10) | grep inteligente (0.55) | sverklo (579 tok, F1 = 0.02) |
O padrão: sverklo ganha nas partes onde a recuperação estrutural (o gráfico de símbolos, o gráfico de importação) responde diretamente à pergunta. Busca de definição (P1) e dependências de arquivo (P4) são exatamente isso. A busca de referência (P2) acaba sendo um problema de regex que o grep lida bem, porque os padrões de referência em JS/TS são suficientemente uniformes sintaticamente para que \bsymbol\b funcione na maioria das vezes.
Onde sverklo falha: a fatia de código morto P5
P5 é a parte embaraçosa. F1 = 0.02. sverklo_refs observa o gráfico de chamadas estáticas. Ele não vê invocações dinâmicas (this[methodName]()), não vê chamadas impulsionadas por deserialização (JSON.parse + eval), e não vê chamadas através de proxies ORM que se escrevem com nomes de métodos em string-template.
O grep inteligente obtém 0.55 na mesma fatia lendo arquivos inteiros e correspondendo padrões soltos de forma agressiva. O "solto" importa: ele pega muitos falsos positivos, mas na detecção de código morto um falso positivo é "essa função está viva" — que é o erro mais seguro.
P5 é a próxima coisa que estou consertando. O plano é estender o gráfico de referência com um modo de rastreamento em tempo de execução (instrumentar a suíte de testes, registrar locais de chamadas reais, mesclar no gráfico estático). Publicarei isso como uma nova fatia de benchmark quando estiver pronto.
Arquitetura: RRF canalizado
A peça nova na recuperação do sverklo é Fusão de Classificação Recíproca Canalizada. A maioria dos recuperadores híbridos executa RRF uma vez sobre fts ∪ vector. O Sverklo executa RRF por canal — FTS, vetor, seção do documento, caminho, nome do símbolo — e funde as classificações por canal com pesos específicos para cada canal. O canal de caminho é ponderado em 1.5× porque correspondências de nomes de arquivos são tendenciosas em precisão: quando as palavras-chave de uma consulta correspondem a um nome de arquivo, é um sinal que vale a pena aumentar.
A razão completa da arquitetura está em RRF está fazendo 80% do trabalho se você quiser uma análise profunda sobre por que a ponderação por canal importa mais do que a escolha do modelo de incorporação.
Reproduzindo isso
git clone https://github.com/sverklo/sverklo
npm install
npm run build
npm run bench:primitives
As saídas brutas (raw.jsonl, summary.json, report.md) estão em benchmark/results/<timestamp>/. O report.md espelha as tabelas da página de benchmark. Se seus números diferirem, registre um problema com a especificação da sua máquina e o timestamp da execução — eu quero os desacordos.
Qual é a conclusão
Se você está escolhendo entre grep e um servidor de inteligência de código MCP para seu agente de codificação de IA hoje:
- Se seu código é pequeno (~30 arquivos), use
rg. O overhead do servidor MCP não compensa. - Se você está no terminal fazendo exploração, aprenda as flags do grep inteligente. F1 te leva ao lugar certo.
- Se você está executando um agente de codificação de IA em um código maior e o agente inventa nomes de funções que não existem em seu repositório, a diferença na economia de tokens de recuperação é real e material. A recuperação de uma chamada de ferramenta do Sverklo é o que desbloqueia isso.
Experimente
git clone https://github.com/sverklo/sverklo
npm install
npm run build
npm run bench:primitives
O artigo apresenta um benchmark que pode ajudar empresas brasileiras a escolher entre soluções de recuperação de código para agentes de IA. A eficiência na recuperação de funções é vital para otimizar o uso de tokens, impactando diretamente a produtividade em projetos de software.
