Nosso benchmark tem uma seção de falhas. De propósito.
O critério de convergência do trail learning não foi batido, e está no relatório mesmo assim. Um benchmark que só dá para passar não é um benchmark.
Publicamos recentemente o preprint do MonkeyLLM, uma "floresta de conhecimento" open source e self-hosted que agentes de IA navegam via MCP, em vez de um banco vetorial que eles consultam. Em bom português: o corpus é um grafo de nós, cada um carregando um passaporte curado (título, resumo, tags), e o agente entra pela busca e caminha, lendo rótulos, seguindo links, abrindo só o que precisa.
Este post não é sobre as vitórias. É sobre por que o relatório também contém uma seção que poderíamos ter apagado em silêncio.
Os números que um marketeiro amaria
Em 11 perguntas estritamente multi-hop, em que cada pergunta precisa de pelo menos 3 saltos encadeados, o mesmo modelo local de 12B marcou 0/11 como leitor de RAG top-k clássico e 11/11 como navegador de floresta.
Fez isso a 0.58x os tokens por resposta correta de um baseline de RAG iterativo, a 8.4 s p95 contra 17.5 s do baseline. Por resposta correta é a unidade que importa: falhar barato não é economia.
A busca de entrada é BM25 sobre SQLite: recall@5 = 1.00 a 1.3 ms p95, sem embeddings, sem banco vetorial, sem GPU. Pesar o ranking a favor dos campos curados (título, aliases) fechou por completo o gap de recall para a busca híbrida.
A ingestão roda a 1.71 s por documento em 100 documentos heterogêneos do mundo real, com 100% dos resumos gerados passando em um contrato de sessenta tokens e zero links quebrados depois. Você paga uma vez na escrita, em vez de em toda consulta para sempre.
Os números que um marketeiro esconderia
São três.
Primeiro, 11 perguntas é um benchmark pequeno. Perguntas estritamente multi-hop são caras de criar e verificar, mas pouco é pouco, e dizemos isso.
Segundo, o paper é um preprint. Não passou por revisão de pares. Dizemos isso também.
Terceiro, o que dói. Caçadas bem-sucedidas depositam trilhas de feromônio que cunham links de atalho, então caminhos que funcionam deveriam ficar mais fáceis de achar e a contagem de hops deveria cair com o tempo. Definimos um critério de convergência para esse efeito antes de rodar o experimento. O critério não foi atingido: os hops caíram cerca de metade do limiar que definimos. A seção está no relatório, escrita como qualquer outro resultado.
Por que publicar o erro
Porque um benchmark impossível de reprovar não é um benchmark. Se o relatório só contivesse vitórias, as vitórias valeriam menos. A seção de falhas é o que torna o 11/11 crível.
E porque o ponto central de infraestrutura self-hosted é nunca ter que aceitar a palavra de um fornecedor. Então removemos a etapa de confiança: o corpus, os conjuntos de perguntas e o harness estão commitados no repositório, e toda tabela do paper se regenera com um comando. O rig é uma única RTX 3060 com 12 GB.
Prove que estamos errados
Não é retórica, é o pedido. Clone o repo, rode o harness no seu próprio corpus e, se um número não reproduzir, abra uma issue com a tabela anexada. Falseável vale mais que impressionante.
Repo: https://github.com/JimmyWesley/MonkeyLLM Site e preprint: https://monkeyllm.com