Anatomia de um Passaporte de Nó

Todo nó em uma floresta MonkeyLLM viaja com um passaporte: um título, um resumo limitado a sessenta tokens, tags e aliases. Parece metadado. É a decisão de design mais deliberada do sistema: o lugar exato onde a inteligência é gasta para que o modelo possa gastar menos.

Quatro campos, um trabalho

Um passaporte existe para que um agente possa julgar um nó sem pagar para abri-lo. Durante uma caçada um agente passa os olhos por dezenas de passaportes e abre só alguns nós, então cada campo precisa valer o próprio custo.

Título. Um nome específico o bastante para se decidir a partir dele, do tipo que uma wiki bem cuidada teria. "Política de backoff de retry de pagamentos", não "Notas (final v2)".

Resumo. O contrato de sessenta tokens. Não um teaser, um veredito: o que este nó sabe e quando abri-lo compensa. Sessenta tokens porque passaportes são lidos o tempo todo, e ler um precisa custar quase nada.

Tags. Geografia grossa: billing, infra, compliance. O bastante para se orientar, nunca um projeto de taxonomia.

Aliases. Os nomes que as pessoas realmente usam. "SSO" ao lado de "single sign-on", o codinome do projeto, o nome antigo do serviço que metade do time ainda fala. Aliases são onde o descompasso de vocabulário vai morrer.

Pago uma vez, no tempo de escrita

Nada disso é grátis, e o lugar honesto de pagar é a ingestão. Medimos a troca no tempo de escrita em 100 documentos heterogêneos do mundo real: 1.71 s por documento, com 100% dos resumos passando no contrato de sessenta tokens e zero links quebrados depois. A tela de Ingestão (a capa deste post) mostra esse trabalho como um job que você acompanha: arquivos, pastas e clipes entrando, passaportes saindo.

Este é o Princípio da Floresta aplicado a um schema: gaste inteligência no ambiente para gastar menos no modelo (spend intelligence on the environment so you can spend less on the model). O tempo de leitura nunca paga o custo da curadoria de novo, e o tempo de leitura é onde vivem cada caçada, cada sessão, cada dia. O argumento mais longo está em o Princípio da Floresta.

O BM25 com pesos por campo colhe o resultado

A busca de entrada, o jeito como um agente cai na floresta pela primeira vez, é BM25 sobre SQLite. BM25 é a clássica função de ranqueamento por palavras-chave por trás da maioria dos buscadores, e o SQLite a traz de fábrica: sem embeddings, sem banco vetorial, sem GPU no caminho de entrada.

No nosso corpus de benchmark ela chega a recall@5 = 1.00 a 1.3 ms p95. A razão é o passaporte: dar peso aos campos curados, título e aliases acima de tudo, fechou completamente a lacuna para a busca híbrida. Os descompassos que um embedder costuma ser contratado para suavizar ("dunning" versus "retries de pagamento") são resolvidos por um alias deliberado sentado exatamente onde a função de ranqueamento olha.

O embedder é opcional e suportado, não removido. Se o seu corpus genuinamente precisa de recall semântico, plugue um. Ele só não é mais o pedágio na porta da frente.

Como é a disciplina na prática

Curadoria soa preciosista até você reduzi-la a reflexos. Se um resumo não consegue dizer por que o nó existe em sessenta tokens, são dois nós. Se uma caçada erra porque o agente buscou uma palavra que o passaporte nunca usa, o conserto é um alias de uma linha, não uma nova stack de recuperação. Tags ficam grossas e poucas. E agentes plantando nós novos respondem ao mesmo contrato do pipeline de ingestão, mecanicamente, para que a floresta não apodreça em silêncio. Cada passaporte que você afia torna cada caçada futura mais barata.

Reproduza a tabela

O corpus, os conjuntos de perguntas e o harness estão commitados, e cada número deste post é regenerado com um comando; o paper é um preprint e dizemos isso. Os docs de primitivos descrevem os campos do passaporte com precisão. Reproduza você mesmo a tabela de busca de entrada a partir de https://github.com/JimmyWesley/MonkeyLLM, ou leia o preprint via https://monkeyllm.com.