Ir para o conteúdo
benchmarkretrievalarchitecture

Para Onde Vai a Latência

17.5 s p95 no RAG iterativo, 8.4 s no navegador, mesmo modelo 12B. Uma dissecação dos dois loops, e por que variância medida em saltos baratos, e não em rodadas inteiras de recuperar-e-ler, derruba a cauda.

Time MonkeyLLM4 min de leitura

Mesmo modelo, mesmo corpus, mesmas 11 perguntas: o baseline de RAG iterativo responde a 17.5 s p95, o navegador de floresta a 8.4 s. O modelo não mudou e o hardware não melhorou. A diferença é o formato do loop, então vamos dissecar os dois.

Anatomia do loop de RAG iterativo

Um sistema de RAG iterativo roda um ciclo: recuperar, raciocinar, reformular, repetir. Cada rodada custa uma recuperação, depois uma passada completa do modelo sobre um contexto recém-entulhado, depois uma decisão de parar ou de reescrever a consulta e ir de novo.

Duas propriedades tornam esse loop lento na cauda. Primeiro, o corpo do loop é caro: cada rodada entulha o contexto de novo com chunks top-k que se sobrepõem fortemente aos da rodada anterior, e o modelo relê o que já leu. Segundo, o número de rodadas é guiado pela demanda: precisamente as perguntas difíceis, as que definem o seu p95, disparam mais reformulações. A cauda multiplica um corpo caro pela sua contagem de pior caso.

A unidade de trabalho do navegador

O corpo do loop do navegador é um salto: ler um passaporte (o título, o resumo e as tags curados de um nó), seguir um link, abrir o corpo completo de um nó só quando necessário. A passada de raciocínio por salto roda sobre um contexto pequeno e orçado em vez de uma pilha de chunks, então cada passada é curta.

A entrada na floresta também não é gargalo. A busca de entrada é BM25 sobre SQLite: recall@5 = 1.00 a 1.3 ms p95 neste corpus, sem embeddings, sem banco vetorial e sem GPU no caminho de busca. Dar peso aos campos curados (título, aliases) fechou completamente a lacuna para a busca híbrida, e é por isso que o embedder pode seguir opcional e suportado em vez de obrigatório.

Gráfico: busca de entrada só com BM25 chegando a recall@5 = 1.00 a 1.3 ms p95
Gráfico: busca de entrada só com BM25 chegando a recall@5 = 1.00 a 1.3 ms p95

Por que a cauda desaba

Gráfico: latência p95, 17.5 s para o baseline de RAG iterativo contra 8.4 s para o navegador de floresta
Gráfico: latência p95, 17.5 s para o baseline de RAG iterativo contra 8.4 s para o navegador de floresta

Perguntas difíceis custam saltos extras ao navegador também, mas os incrementos são baratos: um lookup ou um link seguido em escala de milissegundos, mais uma passada curta e orçada sobre um passaporte. Variância medida em unidades baratas mantém o p95 perto da mediana. Variância medida em rodadas inteiras de recuperar-e-ler, não, e essa é toda a história dos 17.5 s.

Orçamentos adicionam uma segunda garantia, mais bruta: cada salto tem orçamento de tokens via MCP, então a caminhada não pode vagar indefinidamente. O baseline não tem teto assim por construção; você aparafusa um com um knob de max-iterations, e então as perguntas difíceis batem no knob e falham devagar, que é o jeito mais caro de falhar.

O lado de tokens desta mesma comparação, 0.58x por resposta correta, está medido em RAG agêntico vs navegação orçada, e a razão de a recuperação de disparo único não poder simplesmente pular o loop está em por que multi-hop quebra o RAG.

As ressalvas de sempre, de propósito

Onze perguntas é um conjunto pequeno e dizemos isso. O paper é um preprint e dizemos isso. O corpus, os conjuntos de perguntas e o harness estão commitados, cada tabela é regenerada com um comando, e o relatório mantém um critério em que falhamos, porque números que você não consegue rederivar são marketing.

Cronometre sua própria cauda

Suba uma floresta em quatro comandos com o guia de deploy, conecte seu agente via MCP e meça o seu próprio p95. Dê uma estrela ou faça um fork do repo, e o resto vive em monkeyllm.com.

Quer a versão longa?

O paper traz a arquitetura completa, as tabelas do benchmark e os achados que não bateram seus critérios.