Presentation, Not Mechanism: A Render Confound in Deprecation-Aware Memory Evaluation

Resumo Técnico: Apresentação, Não Mecanismo: Um Confundimento de Renderização na Avaliação de Memória com Consciência de Depreciação

Definição do Problema

Sistemas de IA dependem cada vez mais da recuperação de registros que se autorrevisam, como threads de problemas de software, históricos enciclopédicos e logs de políticas. Nesses fluxos, a resposta correta não é necessariamente a frase mais recente ou a maioria das passagens recuperadas, mas o valor que permanece "em vigor" após sucessões, refinamentos e correções. O desafio central é a Revisão de Estado de Evidência (ESR - Evidence-State Revision): determinar quais afirmações estão atualmente ativas, quais foram substituídas e quando um sistema deve se abster devido a conflitos não resolvidos.

As abordagens existentes variam desde a recuperação plana (tratando toda a evidência como aditiva) até memórias estruturadas (usando arestas tipadas, atualizações temporais e status de conflito). No entanto, as avaliações desses sistemas frequentemente sofrem de um confundimento crítico: os sistemas de memória estruturada frequentemente alteram tanto o mecanismo (por exemplo, implementando tipagem de relação refinada ou invalidação de aresta) quanto a apresentação (por exemplo, fornecendo layouts mais limpos e ordenados temporalmente com campos explícitos) simultaneamente. Consequentemente, os ganhos de desempenho atribuídos a mecanismos de memória sofisticados podem, na verdade, advir do fato de o modelo de resposta encontrar mais facilidade em ler um prompt melhor formatado.

Metodologia

Os autores introduzem o ESR-Bench, um benchmark projetado para isolar a necessidade de primitivas de memória específicas, mantendo a tarefa fixa enquanto varia a estrutura da memória. O benchmark compreende 2.907 perguntas de alto acordo derivadas de históricos de problemas do GitHub, logs de múltiplos repositórios, revisões da Wikipedia e fluxos temporais do tipo DyKnow.

Classes de Memória Avaliadas:

1. GraphRAG+abstain (d-blind): Uma linha de base (baseline) plana que recupera evidências e pode se abster, mas carece de marcadores de depreciação explícitos ou arestas de sucessão.
2. Invalidação de Arestas de Depreciação Coarse (ex: estilo Graphiti/Zep): Um armazenamento que invalida arestas antigas quando novas as substituem, mantendo um status binário de "vivo/morto" sem tipagem de relação refinada.
3. RevisionLedger (fine-d): Um livro de registro refinado que mantém tipos de relação (SUPERSEDES, REFINES, CONTRADICTS) e status não resolvido, oferecendo uma representação de estado rica.

Controles Experimentais Chave:

• Controle de Correspondência de Renderização (Render-Matched Control): Para separar mecanismo de apresentação, os autores construíram um controle onde o layout estruturado do livro de registro refinado é preservado, mas o mecanismo de depreciação é desativado (forçando todas as relações para "SAME-STATE"). Isso isola o efeito de "renderização" do efeito de "mecanismo".
• Varreduras de Ruído Controladas: Rótulos de relação e extrações de átomos foram sistematicamente corrompidos para testar se mecanismos refinados tornam-se vantajosos apenas sob alto ruído.
• Consultas de Proveniência: Testes exigindo que o sistema recupere o valor em vigor imediatamente antes do atual, para avaliar estratégias de retenção.

Contribuições Principais e Resultados

1. O Confundimento de Renderização Domina os Ganhos Refinados
Em consultas de "reversão de reversão" (onde um valor muda e depois retorna ao original), o RevisionLedger refinado pareceu superar a linha de base plana em +0,182. No entanto, o controle de correspondência de renderização revelou que +0,159 desse ganho deveu-se exclusivamente ao layout estruturado (apresentação), enquanto o resíduo real do mecanismo refinado foi indistinguível de zero (+0,021 a +0,025). O layout estruturado torna o estado atual mais fácil de identificar para o LLM, mas a tipagem refinada em si não adiciona nenhuma acurácia mensurável para consultas de estado atual.

2. Depreciação Coarse é Suficiente para Consultas de Snapshot
Para consultas que perguntam "qual é o valor atual?" (consultas de snapshot), um mecanismo coarse-d (invalidação binária de vivo/morto) é teórica e empiricamente suficiente.

• A Proposição 2b estabelece que a partição binária de átomos vivos vs. depreciados é um estatístico suficiente mínimo para consultas de snapshot; a tipagem de relação mais fina não carrega valor adicional de informação ($b_{type} = 0$).
• Em configurações limpas, o armazenamento coarse-d na verdade superou o livro de registro refinado em 0,084, pois o livro de registro incorreu em custos de implementação (renderização mais pesada, erros de pontuação/scorer) sem ganhar benefícios de oráculo.

3. Proveniência Requer Retenção, Não Tipagem
Para consultas de proveniência (perguntando por valores anteriores), o fator crítico é a retenção, não a granularidade.

• Um armazenamento coarse que descarta arestas invalidadas falha completamente (acurácia de piso) porque o valor anterior está ausente de seu estado.
• Um armazenamento coarse que retém arestas invalidadas (com seus carimbos de tempo de invalidação) recupera a maior parte da vantagem aparente do livro de registro fino.
• A pequena lacuna restante entre um armazenamento coarse que retém e um livro de registro fino é atribuída amplamente à apresentação (o livro de registro fino apresenta um histórico pré-ordenado, enquanto o armazenamento coarse apresenta arestas não ordenadas que devem ser sorteadas), não aos rótulos de relação.

4. Tipagem Fina Só Vale a Pena Quando a Consulta Lê o Tipo
A tipagem de relação refinada (ex: distinguir "Refines" de "Supersedes") só gera ganhos quando a consulta pede explicitamente por essa coordenada (ex: "O valor refinou ou substituiu o anterior?"). Nesses casos, os ganhos foram observados apenas quando a coordenada da relação foi recuperada com sucesso por um pontuador (scorer) treinado; caso contrário, o mecanismo tipado permaneceu ocioso.

Significância e Alegações

O artigo argumenta que a área tem superatribuído ganhos de desempenho a arquiteturas de memória complexas quando, em muitos casos, os ganhos são impulsionados por efeitos de renderização (melhor layout de prompt) em vez de efeitos de mecanismo (melhor representação de estado).

• Protocolo de Avaliação: Os autores propõem que as avaliações de arquitetura de memória devem manter o render fixo. Sem um controle de correspondência de renderização, as comparações correm o risco de recomendar arquiteturas elaboradas quando uma representação de estado mais simples, renderizada efetivamente, seria suficiente.
• Estratégia de Implantação: O artigo defende uma abordagem de suficiência de consulta: implantar o estado retido mais grosseiro (coarsest) que cubra a mistura de consultas.
  • Para consultas de estado atual, a depreciação binária (coarse-d) é suficiente.
  • Para consultas de proveniência, a retenção de evidências invalidadas é necessária, mas a tipagem de relação fina não é.
  • A tipagem fina só é justificada se a distribuição de consultas exigir explicitamente a leitura de coordenadas de relação que a partição grosseira colapsa.

Os autores concluem que o "melhor sistema de memória" é mal definido sem um prior de fluxo e uma distribuição de consulta específicos. Suas descobertas sugerem que, para consultas de estado atual não monótonas, a depreciação grosseira é o mecanismo de carga, e adicionar tipagem refinada frequentemente introduz custos de implementação (erros de pontuação, complexidade de renderização) sem benefícios intrínsecos de acurácia.