Backends de Memória

Todos os backends implementam o mesmo MemoryService trait, então você escolhe um habilitando uma feature flag e o construindo — seu código de agent não muda. Existem seis.

Visão geral

Back-end	Funcionalidade	Persistência	Busca	Usar quando
`InMemoryMemoryService`	(padrão)	Apenas processo	Palavra-chave	Desenvolvimento, testes, demonstrações
`SqliteMemoryService`	`sqlite-memory`	Um arquivo	Palavra-chave	Aplicativos de nó único, persistência local
`PostgresMemoryService`	`database-memory`	Postgres + `pgvector`	Vector similarity	Pesquisa semântica de Produção
`RedisMemoryService`	`redis-memory`	Redis (TTL opcional)	Palavra-chave	Cache rápido, efêmero, compartilhado
`MongoMemoryService`	`mongodb-memory`	MongoDB	Keyword / vector	Existing Mongo infra
`Neo4jMemoryService`	`neo4j-memory`	Neo4j	Grafo	Infraestrutura Neo4j existente

(O bi-temporal GraphMemoryService é um sétimo, abordado em sua própria página — Knowledge graph.)

InMemory — comece aqui

Configuração zero. Tudo reside no processo e desaparece ao sair.

use adk_memory::InMemoryMemoryService;
let memory = InMemoryMemoryService::new();

Perfeito para desenvolvimento e para o conjunto de testes; troque-o por um backend durável com uma mudança de uma linha porque o trait é idêntico.

SQLite — um arquivo

Durável, arquivo único, sem servidor. Ótimo para aplicativos de desktop e serviços de nó único.

use adk_memory::SqliteMemoryService;
let memory = SqliteMemoryService::new("sqlite://memory.db").await?;
// or build from an existing pool: SqliteMemoryService::from_pool(pool)

Postgres + pgvector — busca semântica em produção

O backend para busca de similaridade real. Ele armazena embeddings em pgvector e permite que você escolha a estratégia de índice.

use adk_memory::{PostgresMemoryService, VectorIndexType};

let memory = PostgresMemoryService::builder(pool, embedding_provider)
    .vector_index(VectorIndexType::Hnsw { m: 32, ef_construction: 128 })  // or IvfFlat / None
    .build()
    .await?;

VectorIndexType::None faz busca exata (força bruta) — bom para conjuntos pequenos; Hnsw (o padrão) e IvfFlat escalam para conjuntos grandes. A busca vetorial precisa de um embedding provider.

Redis, MongoDB, Neo4j

Use estes quando você já executa a infraestrutura:

use adk_memory::{RedisMemoryService, RedisMemoryConfig};
use std::time::Duration;

let memory = RedisMemoryService::new(RedisMemoryConfig {
    url: "redis://localhost:6379".into(),
    ttl: Some(Duration::from_secs(60 * 60 * 24 * 30)),   // optional expiry
}).await?;

MongoMemoryService::new(...) e Neo4jMemoryService::new(...) seguem a mesma forma. Todos eles respeitam o isolamento (app, user, project) de Conceitos.

Embeddings

Backends que realizam similaridade de vetores (Postgres, opcionalmente Mongo) precisam transformar texto em vetores. Forneça um EmbeddingProvider:

#[async_trait]
pub trait EmbeddingProvider: Send + Sync {
    async fn embed(&self, texts: &[String]) -> Result<Vec<Vec<f32>>>;
}

Backends de palavra-chave (InMemory, SQLite, Redis) não precisam de um. Combine o modelo de embedding que você indexa com o que você consulta.

Migrações

Os serviços baseados em SQL executam migrações versionadas e idempotentes para criar e atualizar seu esquema, de modo que a implantação de uma nova versão não exija DDL manual. Chame o migrate() do serviço (ou deixe a construção lidar com isso) na inicialização.

Escolhendo

Construção / teste → InMemory.
Um nó, quer que persista → SQLite.
Recuperação semântica real em escala → Postgres + pgvector.
Você já executa Redis / Mongo / Neo4j → esse backend.
Você quer um modelo consultável do usuário, não uma transcrição → GraphMemoryService.

Próximo: Grafo de conhecimento →