Um benchmark recente mostra que um design de memória de duas camadas — um scratchpad baseado em RAM mais um cofre (vault) local SQLite-vec — entrega tempos de consulta medianos abaixo de 100 ms, eliminando a fatura de US$ 135 por mês associada a um popular banco de dados vetorial em nuvem. Desenvolvedores que constroem agentes de IA autônomos podem executar uma configuração puramente on-premise que, no benchmark, foi mais rápida e não gerou custos mensais.
Por que as abordagens de memória existentes deixam a desejar
Agentes de IA frequentemente precisam recordar milhares de interações passadas, fatos ou resultados de chamadas de ferramentas (tool-calls) dentro de uma janela de resposta curta. A maioria das equipes envia cada embedding para um banco de dados vetorial gerenciado e depende de busca vetorial remota para cada consulta. Esse modelo escala, mas força cada consulta a passar pela rede, inflando o tempo de ida e volta (round-trip time) e os gastos mensais. No benchmark, a latência mediana do serviço em nuvem foi de 127 ms e a fatura ultrapassou US$ 135 no mês; o período de teste também registrou uma interrupção (outage).
Dividindo a memória em dois níveis
A arquitetura de dois níveis separa a "memória de trabalho" do "armazenamento de longo prazo":
L1 Scratchpad (RAM)
- Vive inteiramente na memória do processo.
- Mantém o contexto da tarefa atual e as chamadas de ferramentas mais recentes.
- Armazena strings brutas; nenhum embedding é gerado.
- Retorna resultados em menos de 3 ms, comparável a um cache de CPU.
L2 Vault (SQLite-vec)
- Persiste todos os outros embeddings em um banco de dados SQLite local estendido com capacidades de busca vetorial.
- Lida com o conjunto completo de 14.726 memórias usadas no benchmark.
- Retorna correspondências em cerca de 94 ms, confortavelmente abaixo da meta de 100 ms para muitos agentes em tempo real.
- Não custa nada além do armazenamento da máquina host.
O SQLite-vec é uma extensão de código aberto que adiciona busca de vizinho mais próximo aproximado (approximate nearest-neighbor search) a um arquivo relacional padrão. Como o banco de dados reside na mesma máquina que o agente, não há salto de rede (network hop), e o mecanismo reutiliza truques de indexação existentes do SQLite para manter as consultas rápidas.
Números que importam
| Sistema | Latência mediana | Custo mensal | Confiabilidade relatada |
|---|---|---|---|
| Cloud vector store (Pinecone) | 127 ms | ~$135 | Interrupções observadas |
| Local SQLite-vec vault | 94 ms | $0 | 100% uptime |
A diferença de custo é de US$ 0 contra aproximadamente US$ 135 por mês.
Mantendo o cofre organizado
Um despejo (dump) bruto de todos os embeddings pode diluir a relevância. O autor do benchmark introduziu um sistema de decaimento que pontua as memórias por recência e frequência:
- Itens novos ou acessados com frequência recebem um peso maior.
- Itens que não são acessados há algum tempo perdem peso gradualmente.
- O decaimento ponderado reduz o "ruído de recuperação" (retrieval noise) — correspondências irrelevantes — em 34%.
Ao podar (pruning) entradas de baixa pontuação ou rebaixá-las no índice, o agente evita dados obsoletos, mantendo o cofre enxuto o suficiente para um desempenho consistente.
Conclusão
Para agentes de IA que precisam lidar com milhares de memórias sob prazos apertados, um scratchpad focado em RAM combinado com um cofre SQLite-vec local oferece uma alternativa pragmática aos bancos de dados vetoriais totalmente baseados em nuvem. A abordagem reduz os tempos de resposta, elimina taxas recorrentes de nuvem e entrega um serviço ininterrupto, tudo isso preservando a capacidade de podar dados irrelevantes. Portanto, a adoção do modelo de dois níveis pode tornar os agentes mais rápidos, baratos e confiáveis.