Tokens por Resposta Correta, Não por Consulta
Custo por consulta faz a falha parecer desconto. Medido por resposta correta, o navegador de floresta gasta 0.58x os tokens de um baseline de RAG iterativo, mesmo modelo 12B. Aqui está a aritmética.
Todo dashboard de custo precifica sistemas LLM por consulta, e por consulta, a falha parece desconto. No nosso benchmark o navegador de floresta gasta 0.58x os tokens de um baseline de RAG iterativo por resposta correta, no mesmo modelo 12B. O denominador é a história inteira.
O denominador errado
Tokens por consulta responde à pergunta "quanto custa tentar?". Ninguém entrega um produto que tenta. O que você de fato compra de um sistema de perguntas e respostas são respostas corretas, então a unidade honesta é tokens por resposta correta: o gasto total na carga de trabalho, dividido pelas respostas que você pôde realmente usar.
No momento em que você troca o denominador, pipelines baratos-mas-errados deixam de parecer baratos. Cada consulta que falhou ainda queimou suas recuperações e seu enchimento de contexto, e depois te comprou algo de valor negativo: um retry, uma escalada para um modelo maior, ou uma resposta errada e confiante em que alguém age. Falhar barato não é economia (failing cheaply is not economy).
Um exemplo honesto
Estes números são inventados para a aritmética e rotulados como tal; nossa razão medida vem depois. Pegue dois sistemas sobre as mesmas 100 perguntas:
- O sistema A gasta 1.000 tokens por consulta e acerta 40. Total de 100.000 tokens, o que dá 2.500 tokens por resposta correta.
- O sistema B gasta 1.500 tokens por consulta e acerta 75. Total de 150.000 tokens, o que dá 2.000 tokens por resposta correta.
B é 50 por cento mais caro por consulta e 20 por cento mais barato por resposta correta, falhando ainda 35 vezes menos. Um dashboard por consulta coloca A em primeiro. Um dashboard por resposta correta coloca B em primeiro, e ele é o único dos dois que liga a sua fatura ao valor que você recebeu.
O que medimos
Nas 11 perguntas estritamente multi-hop (cada uma exigindo pelo menos três saltos encadeados), o mesmo modelo 12B rodou como loop de RAG iterativo e como navegador de floresta do MonkeyLLM. Contando cada token gasto e dividindo pelas respostas corretas, o navegador fica em 0.58x o custo do baseline.
Ele também é mais rápido onde dói: 8.4 s p95 contra 17.5 s do baseline. O confronto completo, incluindo como o baseline funciona, está em RAG agêntico vs navegação orçada.
De onde vêm os 42 por cento
O RAG iterativo paga aluguel pelo mesmo terreno a cada rodada: cada reformulação recupera chunks sobrepostos e o modelo os relê. O navegador lê passaportes (um passaporte é o título, o resumo e as tags curados do nó), segue links e abre um nó inteiro só quando precisa de um, com cada salto orçado em tokens via MCP.
Essa parcimônia é comprada no tempo de escrita. A ingestão gasta 1.71 s por documento construindo a curadoria, com 100% dos resumos passando num contrato de sessenta tokens. Gaste inteligência no ambiente para gastar menos no modelo (spend intelligence on the environment so you can spend less on the model).
A correção também segue auditável. Na tela Ask do Studio toda resposta chega apoiada nos nós que a sustentam, então "correta" é algo que você verifica, não algo que você sente.
Confira a aritmética
O corpus, os conjuntos de perguntas e o harness estão commitados, e cada tabela é regenerada com um comando. Leia o preprint (chamamos de preprint porque é o que ele é), refaça os números a partir do repo e encontre o resto em monkeyllm.com.