Um grupo de pesquisa liderado por Haobo Zheng e Yingcai Wu propõe o SpeakerMem-R1. Tan Tang, Yan Chen e Weijie Wang assinam como coautores.
O sistema de memória para agentes de linguagem mantém dois trilhos paralelos. Um guarda mensagens verbatim com falante, tempo e canal.
O outro organiza estados derivados por pessoa e por grupo.
O trabalho treina um Writer pequeno, um Qwen2.5-3B, com aprendizado por reforço. Os módulos de recuperação e de resposta ficam congelados.
Os autores relatam ganhos de 3,3, 12,4 e 9,4 pontos percentuais sobre os melhores resultados de frameworks avaliados em GroupMemBench, SocialMemBench e EverMemBench, respectivamente.
O que os autores propõem
O SpeakerMem-R1 responde a um problema específico. Memória de longo prazo para conversas em grupo não se reduz a um fluxo linear de mensagens comprimido em ordem.
Segundo os autores, o gargalo não está em encontrar texto relevante. Está em preservar e recuperar relações e estrutura histórica.
Daí a arquitetura de trilho duplo, descrita no paper no arXiv.
O primeiro trilho, chamado System 1, é a única camada verbatim. Armazena cada mensagem com texto, falante, horário e canal, sem passar por um modelo de linguagem.
O segundo, System 2, é uma estrutura derivada de quatro camadas. Core e Profile têm escopo PERSON: identidade estável, fatos, posições, comportamento recorrente e cognição cruzada sobre outra pessoa.
Interaction e Insight têm escopo GROUP: eventos entre falantes, relações, decisões, normas de grupo, consenso e exceções.
Cada registro derivado carrega conteúdo, origem (source), proprietário (owner), escopo, evento, tempo, estado e referência de origem.
A distinção source–owner é central. Um autorrelato tem source igual a owner.
"Alice acredita que Bob concordou" tem source igual a Alice e owner igual a Bob.
O sistema organiza a consulta em quatro operações nomeadas pelos autores: Anchor, Separate, Resolve e Compose. O Writer é treinado com SpeakerLevenshtein e GRPO condicionado por falante.
Contexto: qual problema está sendo atacado
Trabalhos anteriores de memória conversacional, como LoCoMo e LongMemEval, miram históricos de um usuário ou de duas pessoas. Dividem, comprimem, indexam e recuperam conversas por relevância.
Diálogos multi-participante acrescentam relações entre falantes, estrutura de resposta, ramificações entre tópicos e revisões de estado. Isso impede o achatamento em uma sequência simples.
Os autores organizam o problema em dois desafios acoplados. O primeiro é atribuição de mensagem: distinguir quem disse o quê, sobre quem o conteúdo versa e se a informação é pessoal ou compartilhada.
O segundo é reconstrução de estado: recuperar estados atuais ou históricos a partir de pistas distribuídas entre membros, grupos e tempo.
O material cita GroupMemBench, SocialMemBench e EverMemBench como evidência de que sistemas de memória de propósito geral degradam em conversas multi-participante ou de longo prazo. BM25 ou recuperação densa podem permanecer competitivos em algumas configurações.
Recuperação por relevância global, argumentam, não garante que um membro de baixa frequência ou o ramo correto entrem em um conjunto candidato limitado. Sumários, agregação de fatos e grafos genéricos de memória tendem a perder source/owner, escopo PERSON/GROUP ou versões de estado.
A conclusão dos autores é que memória multi-participante precisa de evidência verificável com relações entre participantes. E de reconstrução de estado local condicionada pela consulta.
Como funciona
Na escrita, cada mensagem entra no System 1 sem intervenção de modelo. O Writer lê o segmento local junto com o roster de participantes e o estado atual do System 2.
O Writer emite uma de três ações: Add, Update ou Noop. Código determinístico valida a ação, adiciona proveniência e grava no System 2.
As atualizações são não destrutivas. Um Update cita um entry_id existente, anexa um novo nó reaproveitando owner, source e coordenadas de camada do registro identificado.
Liga os estados por links do tipo superseded_by, sem sobrescrever o histórico. A cadeia resultante permite consultas à cabeça (estado atual) e ao histórico completo.
Na consulta, o componente Project compila a pergunta e o roster em restrições comuns: linhas PERSON/GROUP a endereçar, restrição de questão ou evento, modo temporal e restrição de source–owner.
"Todas as pessoas" expande todas as linhas do roster. "A decisão final" seleciona linhas GROUP.
"A visão de Alice sobre Bob" fixa source em Alice e owner em Bob.
Dois caminhos de recuperação operam com orçamentos independentes. O System 1 busca redação exata e contexto local, podendo expandir mensagens vizinhas com Expand e fazer uma busca suplementar via Sufficiency/ASK.
O System 2 expande linhas PERSON/GROUP e seleciona registros dentro de cada linha por questão, relação, evento e tempo.
Quando uma linha derivada está vazia, o sistema recorre às mensagens verbatim da pessoa correspondente. Se ainda não houver evidência, preserva uma linha vazia explícita.
O treinamento por reforço atua apenas sobre as decisões Add/Update/Noop do Writer. O SpeakerLevenshtein, inspirado no pareamento de memória em nível de estado do DeltaMem, combina F1 em nível de token com uma taxa normalizada de casamento de sequência, em vez de distância de edição padrão.
Faz pareamento um-a-um consistente por coordenada dentro de cada owner. Detalhes e artefatos estão na página do projeto.
Resultados reportados
Os autores reportam acurácias binárias de 47,9% no GroupMemBench, 69,2% no SocialMemBench e 61,9% no EverMemBench. Comparadas aos melhores resultados dos frameworks mainstream avaliados em cada benchmark, as diferenças seriam de 3,3, 12,4 e 9,4 pontos percentuais, respectivamente.
No leaderboard público do EverMemBench, mantido pela EverMind-AI, o SpeakerMem-R1 alcança 62,33%. É o melhor resultado reportado entre os frameworks de última geração mais recentes, segundo o paper.
Em uma avaliação controlada de 305 perguntas sob o protocolo principal, o Writer-R1 baseado em Qwen2.5-3B chega a 68,20%. São 10,82 pontos acima do SFT e dentro de 3,28 pontos da referência de Writer com LLM.
Em termos relativos, os autores afirmam que o Writer treinado por RL atinge 95,4% da acurácia da referência. As ablações, dizem, confirmam papéis complementares dos dois trilhos e das visões estruturadas.
O sistema também é avaliado no LoCoMo.
Limitações e o que não foi provado
O extrato disponível não inclui uma seção de limitações, e o resumo original não foi fornecido. O paper também não traz informação de venue ou comentário de revisão.
Isso limita o escrutínio independente: os números acima são afirmações dos autores, não resultados replicados por terceiros.
Alguns pontos merecem cautela. A acurácia absoluta no GroupMemBench, 47,9%, significa que mais da metade das perguntas binárias permanece incorreta, ainda que a comparação relativa seja favorável.
Há uma diferença entre os 61,9% reportados no EverMemBench e os 62,33% do leaderboard público. O texto não explica se são protocolos, subconjuntos ou agregações distintas.
A comparação com "melhores resultados de frameworks mainstream" depende da seleção de baselines e de configurações. O extrato não informa variância, número de execuções nem testes de significância.
A avaliação controlada do Writer cobre 305 perguntas, uma amostra pequena para conclusões firmes sobre generalização. Como recuperação e resposta permanecem congeladas, os ganhos medidos referem-se à organização da memória, e não à capacidade de geração.
É uma escolha metodológica legítima, mas restringe o que se pode atribuir ao sistema como um todo.
Por que isso importa para quem constrói com IA
Quem implementa agentes em canais coletivos enfrenta exatamente o problema de atribuição que o paper endereça. Copilotos corporativos, assistentes em Slack ou WhatsApp, ferramentas de suporte com múltiplos atendentes.
Confundir quem disse o quê, ou tratar uma fala sobre outra pessoa como fato sobre ela, produz erros difíceis de depurar. Em contextos regulados, difíceis de auditar.
Três decisões de engenharia do SpeakerMem-R1 são diretamente reaproveitáveis. A primeira é manter uma camada verbatim como fonte de verdade, com coordenadas de origem, e tratá-la como fallback quando a camada derivada não tem evidência.
A segunda é a atualização não destrutiva com superseded_by, que permite responder tanto pelo estado atual quanto pelo histórico sem reescrever registros. A terceira é separar source de owner como campos de primeira classe, o que torna explícita a diferença entre o que alguém relata e sobre quem o relato versa.
O treinamento de um Writer de 3B com GRPO também é relevante em custo. Substituir um Writer baseado em prompt por um modelo local reduz dependência de APIs caras e melhora previsibilidade de latência, desde que a qualidade se mantenha perto da referência.
Os autores medem 95,4%.
Para equipes que constroem pipelines de RAG sobre conversas, a lição mais ampla é que relevância lexical ou semântica, sozinha, não garante cobertura de participantes, escopo correto nem consistência de versão de estado.
Referências
- Zheng, H.; Tang, T.; Chen, Y.; Wang, W.; Wu, Y. SpeakerMem-R1: Speaker-Centered Dual-Track Memory for Multi-Party Dialogue. arXiv:2609.26780. Disponível em arXiv.org/abs/2609.26780.
- Página do projeto: 2022hpsk.GitHub.io/SpeakerMemR1.
- Benchmarks citados pelos autores: GroupMemBench, SocialMemBench, EverMemBench, LoCoMo, LongMemEval, MemBench, MemoryAgentBench, StoryBench, REALTALK.
- Trabalhos de referência mencionados no paper: DialogueGCN, Molweni, MemoryBank, Mem0, A-MEM, MemGPT, Zep, HippoRAG, RAPTOR, GraphRAG, LightRAG, Memory-R1, DeltaMem.
