Nosso primeiro writeup do BEAM-100K terminou em 70,9% de score médio com GLM-5.2 como leitor, e defendia que engenharia de memória importava mais que a escolha do leitor. Três semanas depois estamos em 75,5% de média (323 de 400 corretas, 80,8% binário) com o stealth Ox Alpha como leitor, e nesta rodada o leitor pagou quase tudo. O lado da memória moveu o número em quase exatamente zero. Esse é o achado, então abrimos com ele: quando o retrieval coloca o contexto certo na frente do modelo na maior parte do tempo, os pontos restantes moram no leitor, e um parâmetro de API compra mais deles que uma semana de trabalho de retrieval.
Dois números aparecem neste post e eles não são intercambiáveis. O placar do AMB ranqueia pela média dos scores do juiz por critério; chamamos de "média" ao longo do texto. A taxa binária de acerto (corretas/total) sempre dá mais alta; chamamos de "binário" e usamos principalmente para contar falhas. Toda tabela diz qual das duas está usando. O run com effort máximo relatado aqui foi concluído em 2026-08-23.
Onde começamos
Todos os runs deste post usam o mesmo juiz (GLM-5.2) e o mesmo split de 400 perguntas do BEAM-100K. O leitor basal era o Gemini 3.6 Flash sobre o mesmo retrieval do ValorBrain: 69,3% de média, 304/400 corretas. O post anterior, com 70,9%, usava GLM-5.2 como leitor e outro juiz, então não é diretamente comparável; ele aparece na tabela final com o setup declarado.
As perdas se concentravam em abstenção e ordenação de eventos, e a análise de erros dizia que eram problemas do lado do leitor. A pergunta era quanto dessa lacuna um leitor melhor fechava, e o que mais estava escondido embaixo.
Passo 1: trocar o leitor
Trocamos o Gemini 3.6 Flash pelo stealth/ox-alpha via OpenRouter. Nada mais mudou. (Nota de identidade: o stealth/ox-alpha foi revelado depois como o GLM-5.3-flash da Z.ai servido sob o alias stealth da OpenRouter — um modelo open-weights de tier flash.)
69,3% → 72,3% de média (304 → 313 corretas).
Três pontos com uma troca de modelo é um ganho sólido e pouco notável. E estagnou imediatamente, como acontece com todo time que joga modelos maiores em cima de sistemas retrieval-augmented: se o contexto carrega ruído ou dados velhos, raciocínio melhor se queima em entradas ruins.
Passo 2: perfil de tudo
Enquanto os benchmarks rodavam, perfilamos a infraestrutura por baixo. Três coisas apareceram.
Índices HNSW halfvec. O retrieval denso rodava em índices HNSW float32 completos, 2,5 GB em quatro tenants. Trocar para o halfvec_cosine_ops do pgvector cortou o armazenamento para 687 MB e deixou as queries 4,7x mais rápidas, com perda de recall zero no nosso eval. Os vetores ficam como fp16 dentro do índice e as distâncias exatas continuam disponíveis no momento da query.
Um bug de validação no nosso access method customizado do PostgreSQL. Todo acesso a valor multivetor rodava um scan completo do buffer de checagens isfinite, O(count x dim). Token pooling acessa valores O(tokens²) vezes por documento, então a 500 tokens por documento o build queimava bilhões de checagens redundantes. Remover a validação redundante dos caminhos quentes levou builds de horas para minutos.
Duas migrations que nunca rodaram. O runner não alcançava o banco, então duas migrations ficaram pendentes. Uma delas criava a admin_active_users_5m(), função de monitoramento que falhava em silêncio nos logs de produção havia semanas. Aplicadas.
Nada disso moveu o benchmark. Tornou a iteração possível, o que vale mais que um ponto de acurácia num ciclo de três semanas: builds que levavam horas passaram a levar minutos, e finalmente dava pra ver o que o sistema estava fazendo.
Passo 3: esforço de raciocínio
Ox Alpha é um modelo de raciocínio, e o OpenRouter roteia com esforço moderado por padrão. Setamos reasoning.effort: "max".
72,3% → 75,5% de média (313 → 323 corretas). Um parâmetro de API, 3,2 pontos.
Por categoria, score médio do juiz, 40 perguntas cada:
| Categoria | Esforço default | Esforço máx | Δ |
|---|---|---|---|
| preference_following | 86,2% | 96,5% | +10,3 |
| information_extraction | 84,2% | 89,6% | +5,4 |
| instruction_following | 83,1% | 86,9% | +3,8 |
| temporal_reasoning | 69,4% | 72,5% | +3,1 |
| summarization | 67,4% | 70,4% | +3,0 |
| contradiction_resolution | 87,2% | 90,0% | +2,8 |
| knowledge_update | 60,0% | 62,5% | +2,5 |
| multi_session_reasoning | 66,3% | 68,3% | +2,0 |
| event_ordering | 53,4% | 54,2% | +0,8 |
| abstention | 62,5% | 60,0% | −2,5 |
Nove das dez categorias sobem. A única que desce, abstenção, é a que revela o mecanismo: perguntas em que o comportamento correto é recusar responder. Mais raciocínio deixou o modelo mais confiante, e modelo confiante responde em vez de recusar. Ordenação de eventos, nossa pior categoria, quase não se move: pensar mais não fabrica estrutura cronológica que o contexto não tem.
Custo: respostas levam cerca de 44% mais tempo. Para análise em batch, troca fácil. Para chat interativo mantemos o esforço default.
Passo 4: construir o rerank ColBERT, depois desligar
Construímos um reranker ColBERT late-interaction sobre o LFM2.5-ColBERT-350M: scoring em nível de token sobre representações pooled de documentos, armazenadas como códigos sq8 quantizados num índice de grafo customizado no PostgreSQL, tokens de query embedados por um serviço sidecar, MaxSim contra os candidatos, resultados reordenados. Rodou ponta a ponta.
Efeito líquido no benchmark completo: 72,3% → 73,0% de média (313 → 312 corretas). A média esconde o formato:
- multi_session_reasoning +6,6, contradiction_resolution +4,4, preference_following +4,4, instruction_following +3,8
- information_extraction −3,6, abstention −6,3, event_ordering −2,9
MaxSim promove overlap lexical, o que ajuda perguntas que sintetizam fragmentos espalhados e atrapalha perguntas que dependem de reconhecer ausência ou cronologia estrita. Uma camada que ajuda síntese e danifica abstenção, com líquido de +0,7, ainda não é feature. É feature atrás de um roteador que saiba que pergunta é qual. Desligamos, mantemos a infraestrutura, e voltamos com gating por categoria.
O achado que mais importa
Depois dos experimentos, classificamos cada falha do run com esforço default (87 respostas erradas, binário) como retrieval miss (a memória certa não estava no contexto) ou reader error (a memória estava lá e o modelo errou mesmo assim).
77 das 87 falhas eram reader errors.
O retrieval coloca as janelas certas na frente do modelo mais de 90% do tempo. O que vem depois depende de o leitor sintetizar entre sessões, rastrear valores ao longo do tempo, reconhecer quando a informação não existe e calcular diferenças de datas. Esses agora são problemas de raciocínio, e é por isso que um único parâmetro de raciocínio rendeu mais que qualquer mudança de retrieval que tentamos neste ciclo.
Progressão completa
| Configuração | Juiz | Média | Binário |
|---|---|---|---|
| Leitor GLM-5.2 (post anterior) | deepseek-v4-flash | 70,9% | 78,0% |
| Leitor Gemini 3.6 Flash | glm-5.2 | 69,3% | 76,0% (304/400) |
| Ox Alpha, esforço default | glm-5.2 | 72,3% | 78,3% (313/400) |
| Ox Alpha, esforço máx | glm-5.2 | 75,5% | 80,8% (323/400) |
É SOTA? Ainda não.
A configuração RAG do Hindsight faz 86,2% de média no mesmo benchmark (leitor Gemini 3.1 Pro, juiz Gemini 3.5 Flash). Estamos 10,7 pontos atrás. A configuração single-query deles faz 73,4%, que ultrapassamos por 2,1 pontos. Leitores e juízes diferentes nos dois lados, então trate qualquer número cruzando sistemas como indicativo; o arreio é público e a comparação honesta é rodar os dois você mesmo.
Não estamos reivindicando SOTA hoje. Estamos reivindicando 75,5% reproduzíveis, com juiz declarado, split declarado e arreio público, mais uma taxonomia de falhas que diz onde estão os próximos dez pontos.
E um compromisso: vamos atrás dos 86,2%, em público. Os três padrões de falha abaixo são o mapa. Cada tentativa, acerte ou erre, sai escrita aqui e no X. Se estagnarmos, vocês vão ver a estagnação.
O que não funcionou
- Rerank ColBERT como camada universal. Ajuda síntese, danifica abstenção e extração. Espera um roteador.
- Expandir o orçamento de entrega de contexto. Raciocínio multi-sessão melhorou e ordenação de eventos piorou: mais janelas significa mais sequências competindo, e ordenação degrada.
- Configuração uniforme entre categorias. Cada categoria tem seu ótimo. Uma configuração só deixa pontos na mesa.
Takeaways
Se você está construindo um sistema de memória e benchmarcando ponta a ponta:
- Meça retrieval separado da leitura. Não se conserta o que não se isola, e a separação diz em que lado gastar a semana.
- Teste esforço de raciocínio antes de adicionar infraestrutura. Um parâmetro, 3,2 pontos de média, zero código.
- Mais contexto não é contexto melhor. Nossa expansão de entrega trocou uma categoria por outra.
- Publique atrás de flags. Rodamos o ColBERT ponta a ponta, medimos líquido de +0,7 e desligamos sem downtime.
- Perfile antes de otimizar. Nossa maior correção de performance veio de um stack dump do gdb, não de intuição.
Próximos passos
As 77 falhas restantes se agrupam em três padrões:
- Síntese multi-sessão: perguntas que precisam de sequências completas de eventos montadas a partir de fragmentos espalhados. Orçamentos de entrega ajustados por tipo de pergunta, não globalmente.
- Computação temporal: "quantos dias entre X e Y" exige extrair duas datas, subtrair e citar as duas. Hints de output estruturado são o próximo teste.
- Calibração de abstenção: o leitor precisa distinguir "existe um tópico adjacente" de "a resposta existe". Exemplos few-shot de abstenção no prompt são o teste mais barato.
No lado da infraestrutura: roteamento de rerank por categoria (ColBERT só para perguntas de síntese), token pooling paralelo entre documentos, e um formato de docmap 64-bit para índices MV acima de 33k documentos.
Reproduzindo
Os resultados são reproduzíveis via o Agent Memory Benchmark com o provider ValorBrain. Crie uma conta ValorBrain em valorbrain.valor.digital para obter uma chave de API.
Referências
- Tavakoli et al. (2025). "Beyond a Million Tokens: Benchmarking and Enhancing Long-Term Memory in LLMs." ICLR 2026.
- Vectorize/Hindsight. "Agent Memory Benchmark (AMB)." https://github.com/vectorize-io/agent-memory-benchmark
- Post anterior: "Qualidade de Memória Vale Mais Que o Leitor: Evidência do BEAM-100K" (2026-08-04)