Resumo Técnico: MemoryDocDataSet

Definição do Problema

Os benchmarks de IA atuais avaliam a memória conversacional e o raciocínio em documentos longos isoladamente, falhando em capturar as demandas de assistentes de IA do mundo real, que devem operar simultaneamente em ambos os domínios. Os benchmarks de memória existentes (ex: LoCoMo, LongMemEval) utilizam diálogos de múltiplas sessões, mas carecem de documentos longos, permitindo que os sistemas tenham sucesso através da memorização perfeita da conversa sem a capacidade de leitura. Inversamente, os benchmarks de documentos longos (ex: L-Eval, ZeroSCROLLS) fornecem textos de extensão de livros, mas carecem de estrutura conversacional, permitindo que os sistemas tenham sucesso através de janelas de contexto amplas sem a navegação de memória.

Existe uma lacuna crítica na avaliação da capacidade conjunta necessária para:

1. Navegar no histórico de conversas de múltiplas sessões para identificar o contexto.
2. Determinar qual documento específico é relevante com base nesse contexto.
3. Realizar a compreensão de leitura profunda dentro desse documento identificado para extrair uma resposta.

Esta "lacuna de recuperação conjunta" é exemplificada por cenários como um assistente jurídico que relembra qual contrato um cliente discutiu em uma sessão anterior e, em seguida, navega por 40.000 tokens desse contrato para encontrar uma cláusula específica.

Metodologia

O Benchmark MemoryDocDataSet

Os autores introduzem o MemoryDocDataSet, um benchmark sintético composto por 50 micro-mundos e 1.000 pares de pergunta-resposta (QA). Cada micro-mundo é um cenário autossuficiente definido pela tupla $M = (P, G, D, C, Q)$:

• Personas ($P$): 3–5 entidades com papéis, especialidades e relacionamentos definidos.
• Grafo de Eventos ($G$): Um Grafo Acíclico Dirigido (DAG) temporal de 5–10 eventos com carimbo de tempo abrangendo pelo menos seis meses, codificando dependências causais.
• Documentos ($D$): 3–5 documentos reais longos (20.000–50.000 tokens cada) extraídos do Caselaw Access Project (opiniões judiciais dos EUA).
• Conversas ($C$): 5 sessões de diálogo de múltiplas sessões ancoradas a eventos específicos, com pelo menos 40% das sessões referenciando explicitamente documentos.
• Pares de QA ($Q$): 20 pares por micro-mundo através de cinco categorias de raciocínio (Salto Único, Multi-salto, Temporal, Atualização de Conhecimento, Adversarial).

A Dimensão da Fonte:
A inovação definidora é a anotação da tag de fonte para cada par de QA, categorizando a fonte de informação necessária:

• Apenas-Chat (Chat-only): Resposta derivável apenas do histórico de conversa.
• Apenas-Doc (Doc-only): Resposta derivável apenas de documentos longos.
• Híbrida (Hybrid): Requer um processo de duas etapas: (1) usar o contexto da conversa para identificar o documento relevante e (2) ler esse documento para extrair a resposta.
• Distribuição: Perguntas híbridas constituem 75,1% do conjunto de dados, com um piso de design de 30% por micro-mundo.

Pipeline de Geração

O conjunto de dados é gerado via um pipeline de sete estágios totalmente automatizado e orientado por configuração usando LLMs (Claude Sonnet 4.6):

1. Coleta de Documentos: Obtenção e agrupamento de textos jurídicos reais.
2. Geração de Persona e Grafo de Eventos: Criação de papéis sintéticos e eventos temporais.
3. Geração de Conversa: Geração de diálogos fundamentados no grafo de eventos.
4. Geração de QA: Criação de perguntas com referências de evidência.
5. Verificação de Qualidade: Um protocolo de LLM-como-juiz usando prompts estritos e lenientes para medir a autossuperficialidade de sensibilidade ao prompt (mediana de Cohen's $\kappa = 0,634$).
6. Empacotamento do Conjunto de Dados: Divisão em treino/validação/teste (70/14/16) com isolamento de documentos.
7. Avaliação de Baseline.

Experimentos de Baseline

Seis configurações de baseline foram avaliadas no split de teste (160 pares de QA, 8 micro-mundos) usando F1 por nível de token e Correspondência Exata (EM):

1. LLM Base: Contexto truncado (4.096 tokens).
2. LLM de Longo Contexto: Contexto total (60.000 tokens).
3. RAG-Conv: Recuperação sobre fragmentos de conversa apenas.
4. RAG-Doc: Recuperação sobre fragmentos de documentos apenas.
5. RAG-Both: Recuperação conjunta sobre ambas as modalidades.
6. Sistema de Memória: Extração de fatos baseada em grafos a partir de conversas.

Principais Resultados

Desempenho em Perguntas Híbridas

Os resultados revelam uma significativa "lacuna de recuperação conjunta":

• O RAG-Doc alcançou um forte 0,453 F1 em perguntas de Apenas-Doc, mas colapsou para 0,267 F1 em perguntas Híbridas. Isso demonstra que a recuperação de documentos sem a navegação conversacional é insuficiente para o raciocínio conjunto.
• O RAG-Both alcançou o maior desempenho geral (0,358 F1) e melhorou o desempenho Híbrido para 0,342 F1, confirmando que a incorporação da recuperação de conversas recupera grande parte da lacuna.
• O LLM de Longo Contexto (0,323 geral) teve um desempenho apenas marginalmente superior ao Base LLM (0,317), apesar de um aumento de 15x no contexto. Ele exibiu a menor precisão de abstenção (0,844), sugerindo que a expansão das janelas de contexto sem recuperação estruturada leva ao aumento de alucinações em perguntas não respondíveis (efeito "perdido no meio").

Assimetria de Especialização

Uma clara assimetria de especialização foi observada: sistemas fortes em uma tag de fonte (ex: RAG-Doc em Apenas-Doc) eram fracos na tag complementar (Híbrida). Mesmo o melhor baseline (RAG-Both) teve um desempenho significativamente inferior às expectativas humanas, indicando que as arquiteturas atuais não suportam nativamente a estratégia de navegação de duas etapas exigida para tarefas Híbridas.

Significância e Alegações

O artigo alega as seguintes contribuições e significância:

1. Primeiro Benchmark Conjunto: O MemoryDocDataSet é o primeiro benchmark que avalia simultaneamente o histórico de conversas de múltiplas sessões e o raciocínio em documentos longos, formalizado através da tag de fonte Híbrida.
2. Lacuna Mensurável: O benchmark quantifica uma lacuna arquitetônica específica: a incapacidade dos sistemas atuais de primeiro navegar na conversa para identificar um documento e, em seguida, recuperar desse documento específico.
3. Implicações de Design de Sistema: Os resultados sugerem que simplesmente aumentar o tamanho da janela de contexto ou usar RAG padrão é insuficiente. A próxima geração de assistentes de IA requer arquiteturas que unifiquem a memória conversacional com a navegação de documentos longos, implementando especificamente uma estratégia de recuperação de duas etapas (conversa $\to$ identificação de documento $\to$ recuperação de documento).
4. Liberação de Recursos: Os autores liberam o conjunto de dados, o pipeline de geração e todas as implementações de baseline para facilitar a pesquisa sobre essa capacidade conjunta.

O artigo mantém um tom modesto em relação ao desempenho humano, observando que um limite superior humano formal não foi medido e que a verificação atual via LLM-como-juiz serve como um proxy para consistência, não para correção absoluta. As limitações reconhecidas incluem a especificidade do domínio (texto jurídico dos EUA), a natureza sintética das conversas e o escopo restrito ao inglês.