Avaliação e benchmarks
O que os números medem, quais são reproduzíveis, e as regras que os mantêm honestos.
Os números desta página vêm do registro de benchmarks do engine; o espelho público deles está na página de benchmarks do produto. São números de evidência de recuperação, salvo rótulo em contrário — tratá-los como acurácia de resposta é um erro de categoria (veja abaixo).
Dois tipos de número
Recall de recuperação (R@K) — a evidência certa entrou no top-K? Medido contra evidência gold, sem LLM no circuito.
Acurácia de resposta — um juiz LLM aceitou a resposta? O que leaderboards comerciais normalmente publicam.
Comparar o R@10 do ValorBrain com a acurácia julgada de outro sistema é a leitura errada mais comum desta página. Quando o engine publica acurácia (BEAM via AMB), ele avisa.
Registro reproduzível
| Benchmark | Métrica | Resultado | Notas |
|---|---|---|---|
| LoCoMo | R@10 de evidência | 96.58% | 1986 QAs, duas execuções idênticas e limpas (2026-07-29). A base honesta. |
| LoCoMo | R@1 / R@5 | 69.4% / 91.3% | Mesmas execuções. |
| LongMemEval-S (500 completas) | R@5 / R@10 | 95.2% / 97.6% | Pendente de reverificação com o gate de índice corrigido. |
| LoCoMo, só denso | R@10 | 63.5% | Só a perna de embedding — uma medição de componente, não do pipeline. |
| BEAM-100K (harness AMB) | acurácia | ver o placar público | Par leitor/juiz fixo; comparável com o leaderboard da AMB. |
O registro LoCoMo mais antigo, de 97.4% R@10, explicitamente não é reproduzível — foi medido num corpus meio indexado (documentos contados antes de seus vetores chegarem ao índice híbrido) e a documentação do engine o marca como do not cite. O delta entre 96.58% e 97.4% é sistemático, não ruído; está documentado em vez de silenciosamente esquecido.
Pontos de referência que não são do ValorBrain: o R@5 93.9% (LoCoMo) e o 98.4% (LongMemEval) da Engram pertencem àquele sistema. Compará-los com a tabela acima é recall-contra-recall e é justo; adotá-los como se fossem do ValorBrain, não.
O pipeline por trás dos números
O R@10 de 96.58% é o stack completo — BM25 (pgturbohybrid) + denso (LFM2.5-Embedding-350M-finetuned-v3, 1024-d) + RRF + rerank de grafo PPR + cross-encoder BGE-Reranker-v2-m3. Cada perna é mensurável sozinha (só denso: 63.5%); a fusão é de onde vem o resto. A troca de embedding que importou historicamente: Jina → LFM2.5 levou o R@10 só-denso de 32.7% para 63.5% (+30.8pp) no mesmo corpus.
Regras que o engine impõe a si mesmo
Estas vieram de erros reais e caros; um benchmark que as quebra mede o harness, não o sistema.
- Espere o índice, não o embedding. Um documento só é buscável pela perna densa depois que chega ao índice híbrido. Gates que esperavam o estado de embedding mediram um corpus meio indexado e produziram o 97.4% irreproduzível.
- Nunca faça benchmark contra um sistema em movimento. Sem restarts nem deploys no meio da execução; sem um segundo benchmark compartilhando as estatísticas BM25 ou o orçamento de dedup.
- Gere o fingerprint do corpus. O corpus é vivo; execuções só são comparáveis sob o mesmo fingerprint.
- Conheça o piso de ruído antes de comparar. No LoCoMo é ±2 documentos em 10 conversas; abaixo disso, "regressão" é clima.
- O juiz nunca é o respondente. Benchmarks de qualidade de resposta usam um modelo juiz de família diferente da do leitor — o viés de autopreferência é real e mensurável.
- Uma resposta vazia do leitor é um defeito de harness — contabilizada, nunca diluída na média.
De onde vêm os números
- Execuções públicas canônicas: o harness AMB (agent-memory-benchmark,
vectorize-io), o mesmo que o placar público usa. - Iterações de pesquisa dentro do engine (
beam-qa.ts) usam um par prompt/juiz diferente e são rotuladas internal — servem para escolher o que corrigir, nunca para publicar.
Numa instalação on-premise (Enterprise), para medir a sua própria instância: bun run gate:locomo (piso de recall do nightly, R@10 ≥ 0.90 por padrão) e bun run gate:beam (acurácia via AMB) vêm com o engine. Custam tokens de LLM e tempo; são gates, não testes de unidade.