Qualidade de Memória Vale Mais Que o Leitor: Evidência do BEAM-100K

Correção (11/10/2026). Duas afirmações deste post não se sustentam. Primeiro: o juiz do run de 70,9% não foi Gemini 3.6 Flash — o arquivo do run registra judge_llm: gateway:deepseek-v4-flash (o nome do run, "gemini-judge", é que sugeriu isso). Segundo: a decomposição "58% engenharia de memória / 42% leitor" misturava runs com juízes, contagens de perguntas e métricas diferentes, e os passos não somam o total declarado; ela saiu. A decomposição que fecha, só com runs do mesmo juiz e das mesmas 400 perguntas, está no post do reasoning effort: lá, do baseline ao número principal, todo o ganho veio do lado do leitor.

O ValorBrain pontua 70,9% de média no BEAM-100K (20 conversas, 400 perguntas) usando GLM-5.2 como modelo de resposta e deepseek-v4-flash como juiz (ver a correção acima). Em comparação com o Hindsight, que faz 73,4% de média (single-query, leitor Gemini 3.1 Pro, juiz Gemini 2.5 Flash Lite), são leitor e juiz diferentes dos nossos — contexto, não comparação direta. Na tabela por categoria abaixo, o mesmo aviso vale.

A leitura que sobrevive hoje: a melhoria medida até aqui veio do lado do leitor; a parte de memória segue necessária, mas os números deste post não provam o quanto ela contribuiu.

---

Resultados

---

Por Categoria vs Hindsight

O ValorBrain vence em 5 das 10 categorias. As perdas estão concentradas em Abstenção (-30,0, uma distinção semântica do lado do leitor) e Ordenação de Eventos (-34,1, onde estrutura cronológica precisa de mais trabalho).

---

A Decomposição: Memória vs Leitor

Retirada em 11/10/2026. A tabela que estava aqui (+10,1 consolidação, +3,6 consolidação rica + timeline, +7,3 GLM-5.2 + max_tokens, +1,5 variância = "total +22,5") misturava runs com juízes, contagens de perguntas e métricas diferentes, e os passos não somam o total declarado — ela não fecha. A decomposição verificável está no post do reasoning effort, recalculada por script a partir dos arquivos de run, e nela todo o ganho do baseline ao número principal vem do lado do leitor.

---

Por Que a Consolidação Funciona

A maior melhoria individual (+10,1 pontos) veio de incluir fatos pré-sintetizados da conversa como um documento sintético na saída de recuperação. Em vez de forçar o LLM a extrair fatos específicos de janelas de conversa espalhadas, a consolidação os entrega pré-extraídos.

Isso é reader-agnostic por design. A consolidação é gerada offline e armazenada. Qualquer LLM de resposta recebe os mesmos fatos pré-sintetizados. A melhoria transfere entre leitores porque reduz o trabalho de extração, não porque depende de raciocínio específico do leitor.

O impacto foi mais visível em Sumarização (0,8% para 64,5%) e Raciocínio Multi-sessão (32,5% para 57,2%). Ambos exigem agregar fatos espalhados por muitos turnos. A consolidação faz esse trabalho antecipadamente.

---

GLM-5.2 vs Gemini 3.1 Pro

O GLM-5.2 pontua mais alto que o Gemini 3.1 Pro no Artificial Analysis Intelligence Index (51 vs 46), com força particular em tarefas agentic. O GLM-5.2 custa metade (USD 0,86 vs USD 1,74 por 1M tokens), é mais rápido (187 vs 131 tokens/s), e é open-weights.

GLM-5.2 não é um compromisso na qualidade do leitor. Pontua mais alto em inteligência, custa metade, e é open-weights.

---

Um Endpoint, Qualquer Consumidor

O ValorBrain expõe recuperação através de um único endpoint /api/v1/memory/prepare que retorna delivered_documents: chunks limpos e agnósticos ao consumidor. O mesmo endpoint serve nosso agente de produção, o benchmark AMB, e qualquer cliente externo.

Não existe modo benchmark versus modo produção. A qualidade de memória medida pelo benchmark é a qualidade de memória entregue aos usuários.

---

Limitações

• Os resultados refletem o conjunto completo de 20 conversas do BEAM-100K. O BEAM-10M foi medido em 2026-08-24 (média 51,2%, binário 56,0%); BEAM-500K e BEAM-1M ainda não foram rodados.
• Apenas GLM-5.2 e deepseek-v4-flash foram testados como LLMs de resposta. Resultados com Claude ou GPT-4o podem diferir. As melhorias reader-agnostic devem transferir.
• Abstenção: a verificação lexical de disponibilidade que implementamos não cobre os casos sutis de abstenção do BEAM (tópico existe, detalhe não). Isso precisa de raciocínio semântico além do que um sistema de memória pode fornecer sem o leitor.
• Ordenação de Eventos: a entrega da linha do tempo melhorou os resultados mas ainda fica atrás do Hindsight. Um documento estruturado de sequência de eventos (não apenas fatos ordenados) pode fechar a lacuna.
• Variância do juiz: o juiz LLM do BEAM introduz variância de pontuação. Comparações entre implementações devem considerar modelos juiz diferentes.

---

Conclusão

O ValorBrain pontua 70,9% de média no BEAM-100K usando GLM-5.2, com o juiz declarado acima; os números do Hindsight têm leitor e juiz diferentes e servem de contexto, não de comparação direta.

Para uma plataforma de memória multi-tenant onde os usuários trazem seu próprio LLM, a implicação é prática. Investir em engenharia de memória (consolidação, linha do tempo, entrega estruturada) beneficia todo usuário independentemente do LLM que escolher. Investir em um leitor mais forte beneficia apenas aquele leitor.

---

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

1. Tavakoli et al. (2025). "Beyond a Million Tokens: Benchmarking and Enhancing Long-Term Memory in LLMs." ICLR 2026.
2. Vectorize/Hindsight. "Agent Memory Benchmark (AMB)." https://github.com/vectorize-io/agent-memory-benchmark
3. Artificial Analysis. "GLM-5.2 vs Gemini 3.1 Pro Preview." https://artificialanalysis.ai/models/comparisons/glm-5-2-vs-gemini-3-1-pro-preview