Resumo Técnico: Usuário como Código (UaC)

1. Declaração do Problema

Agentes de IA personalizados requerem um modelo persistente do usuário ("memória do usuário") que se acumula através das sessões. Os sistemas de memória atuais tipicamente armazenam essa informação como texto não estruturado, grafos de conhecimento ou repositórios de fatos planos, dependendo de mecanismos de recuperação (ex: similaridade vetorial) para buscar entradas relevantes. Os autores identificam três limitações críticas neste paradigma de "saco de fatos":

1. Separação entre Representação e Verificação: Armazenar um fato e agir sobre ele são etapas distintas. Sistemas baseados em recuperação têm dificuldade em resolver contradições, agregar dados através de muitos registros ou aplicar regras lógicas porque a representação não é diretamente executável.
2. Incapacidade de Lidar com Consultas Agregadas: Perguntas que exigem computação sobre todo o histórico (ex: "Quantas viagens internacionais eu fiz no ano passado?") fazem com que os sistemas baseados em recuperação colapsem, pois a recuperação top-k vê apenas um subconjeto de registros.
3. Falta de Serviço Proativo: Benchmarks existentes focam em recall reativo. Eles falham em testar o "Serviço Ativo" — a capacidade de um agente de gerar alertas não solicitados e críticos para a segurança (ex: conflitos de alergia a medicamentos) disparados por mudanças de estado em vez de consultas do usuário.

2. Metodologia: A Arquitetura Usuário como Código

O artigo propõe o Usuário como Código (UaC), um paradigma onde o modelo de um usuário para o agente é um projeto de software vivo. O estado do usuário é representado como objetos Python tipados, e as regras que os governam são codificadas como funções Python comuns. Isso unifica representação e raciocínio em um único meio executável por um interpretador.

A arquitetura baseia-se em um pipeline de duas fases para converter conversas brutas neste código executável:

Fase 1: Memorizar (Extração de Somente Anexo)

• Processo: Para cada sessão de conversa, um LLM extrai fatos individuais como strings planas.
• Característica Chave: Esses fatos são anexados a um log contínuo e nunca são sobrescritos ou deletados. Datas relativas são resolvidas para datas absolutas contra o timestamp da sessão.
• Armazenamento: Os fatos são indexados em um banco de vetores (ChromaDB) para fallback de recuperação. Fragmentos de conversas brutas também são arquivados.

Fase 2: Estruturar (Regeneração Periódica)

• Processo: Periodicamente, um LLM regenera todo o código Python estruturado a partir do corpus completo de fatos acumulados.
• Saída: Os fatos são organizados em instâncias de dataclass tipadas (ex: PassportInfo, Medication).
• Geração de Restrições: Um "agente de codificação" escreve funções Python (restrições) que operam sobre este estado tipado. Essas funções são executadas deterministicamente em um sandbox.
• Alertas: Os resultados dessas restrições (ex: ACTIVE_ALERTS) são apresentados em um manifesto compacto carregado no início de cada nova sessão, permitindo alertas proativos sem consultas do usuário.

Recuperação e Uso

O UaC emprega um sistema de Recuperação Multi-Estratégica que compõe três canais:

1. Estado de Código Estruturado: O estado Python tipado é incluído literalmente no prompt (truncado se necessário).
2. Recuperação de Vetor de Fatos: Top-k fatos do log de somente anexo são recuperados via similaridade de cosseno para cobrir detalhes não capturados pelo esquema.
3. Recuperação de Arquivo: Fragmentos de conversas brutas são recuperados como um fallback para consultas literais.

3. Principais Contribuições

1. Uma Arquitetura de Memória de Duas Fases: O UaC alcança 78,8% de precisão no benchmark LOCOMO de 10 conversações completas (600 QAs), empatando estatisticamente com o limite de Contexto Total (Full-Context) (79,8%) e superando significativamente as re-implementações de sistemas SOTA com o mesmo backbone (MemMachine: 72,7%, Hindsight: 69,7%).
2. Benchmark de Inferência Analítica: Os autores introduzem um benchmark para perguntas agregadas (contagens, somas, médias) sobre o histórico do usuário. O UaC alcança 99% de precisão, enquanto sistemas baseados em recuperação colapsam (MemMachine: 43%, Mem0: 6%). Isso ocorre porque a resposta é uma computação de uma linha sobre o estado tipado, em vez de uma busca sobre texto.
3. Benchmark de Serviço Ativo: Um novo benchmark testando alertas proativos (40 cenários padrão + 20 cenários difíceis). O UaC alcança 100% de detecção em cenários padrão e 85% em cenários difíceis (envolvendo aritmética de datas complexas e restrições multi-domínio), uma capacidade que sistemas baseados em recuperação não podem fornecer sem consultas explícitas.
4. Estudos de Ablação:
   • Extração de somente anexo é o fator mais significativo para o recall (+19pp sobre baselines de apenas código).
   • Separação de duas fases (separar a extração de fatos da estruturação de código) evita a perda de informação vista na reescrita incremental de código (+12,3pp sobre código incremental).
   • Modularidade: Carregar apenas domínios relevantes sob demanda reduz os custos de tokens em 14,9x sem perda de precisão em grandes tamanhos de estado (500 registros).
5. Amortização de Custo: Embora a estruturação incorra em um custo único, o UaC torna-se ~15x mais barato do que recarregar registros brutos para consultas repetidas (após 3–11 consultas, dependendo do tamanho do estado).

4. Resultados e Desempenho

• LOCOMO: O UaC (78,8%) é estatisticamente indistinguível do limite de Contexto Total (79,8%, p=0.65) e vence todos os sistemas de memória concorrentes.
• LongMemEval: O UaC pontua 83,0%, empatando estatisticamente com MemMachine (84,8%) e Full Context (85,4%).
• Inferência Analítica: O UaC mantém precisão quase perfeita (99%) através de contagens de registros de 20 a 500, enquanto sistemas baseados em recuperação degradam significativamente conforme o número de registros aumenta.
• Latência: O UaC tem uma latência de resposta mediana de 3,62s (ligeiramente superior aos 1,78s do Full Context) devido à complexidade do prompt multi-canal, mas permanece dentro do ritmo conversacional.
• Robustez: Os resultados sustentam-se através de diferentes backbones de LLM (GPT-5.4 vs. Gemini 3 Flash) e avaliações de juízes cruzados (Claude Opus 4.7), com alta concordância entre juízes (Cohen's κ ≥ 0,74).

5. Significância e Alegações

O artigo argumenta que o Usuário como Código altera fundamentalmente a capacidade da memória de IA. Ao tratar a memória do usuário como um projeto de software versionado e tipado, em vez de um banco de dados passivo, o UaC permite:

• Verificação Determinística: Regras (restrições) executam deterministicamente, garantindo que verificações críticas de segurança (ex: interações medicamentosas) sejam confiáveis.
• Serviço Proativo: O sistema pode apresentar alertas baseados em mudanças de estado sem esperar por uma consulta do usuário, abordando a "assimetria de iniciação" em agentes personalizados.
• Raciocínio Escalável: Agregar sobre históricos extensos torna-se uma tarefa computacional trivial em vez de uma falha de recuperação.

Os autores posicionam o UaC não como um substituto para a recuperação, mas como uma camada complementar onde a recuperação lida com o recall de nível superficial, enquanto a camada de código executável lida com inferência analítica e verificação de restrições. O trabalho sugere que a "representação" entre o registro e o recall é a alavanca crítica para a inteligência do agente, e que código executável e tipado é um meio superior para essa representação comparado ao texto não estruturado.

Limitações Reconhecidas:

• O estado estruturado é aproximadamente neutro para recall puro de um único passo (contribuindo com apenas -1,3pp na ablação), indicando que seu valor principal reside na agregação e restrições.
• A regeneração "de uma só vez" na Fase 2 enfrenta limites de escalabilidade ao atingir centenas de sessões, motivando trabalhos futuros sobre estruturação hierárquica.
• O desempenho do Serviço Ativo em "cenários difíceis" (n=20) é promissor, mas estatisticamente inconclusivo contra o baseline mais forte (Mem0) devido ao tamanho da amostra.