Backends de mémoire

Tous les backends implémentent le même MemoryService trait, vous en choisissez un en activant un feature flag et en le construisant — votre code d'agent ne change pas. Il y en a six.

En un coup d'œil

(Le bi-temporel GraphMemoryService est un septième, couvert sur sa propre page — Graphe de connaissances.)

InMemory — commencer ici

Aucune configuration. Tout réside dans le processus et disparaît à la sortie.

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

Parfait pour le développement et la suite de tests ; échangez-le contre un backend durable avec un changement d'une seule ligne car le trait est identique.

SQLite — un fichier

Durable, fichier unique, sans serveur. Idéal pour les applications de bureau et les services mono-nœud.

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

Postgres + pgvector — recherche sémantique en production

Le backend pour une vraie recherche de similarité. Il stocke les embeddings dans pgvector et vous permet de choisir la stratégie d'indexation.

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 effectue une recherche exacte (par force brute) — idéal pour les petits ensembles ; Hnsw (par défaut) et IvfFlat s'adaptent aux grands ensembles. La recherche vectorielle nécessite un embedding provider.

Redis, MongoDB, Neo4j

Utilisez-les si vous utilisez déjà cette infrastructure :

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(...) et Neo4jMemoryService::new(...) suivent la même forme. Tous respectent l'isolation (app, user, project) de Concepts.

Embeddings

Les backends qui effectuent une similarité vectorielle (Postgres, optionnellement Mongo) doivent transformer le texte en vecteurs. Fournissez un EmbeddingProvider :

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

Les backends par mots-clés (InMemory, SQLite, Redis) n'en ont pas besoin. Faites correspondre l'embedding model que vous indexez avec celui avec lequel vous effectuez des requêtes.

Migrations

Les services basés sur SQL exécutent des migrations versionnées et idempotentes pour créer et mettre à niveau leur schéma, de sorte que le déploiement d'une nouvelle version ne nécessite pas de DDL manuel. Appelez le migrate() du service (ou laissez la construction le gérer) au démarrage.

Choix

• Construction / test → InMemory.
• Un nœud, persistance souhaitée → SQLite.
• Rappel sémantique réel à l'échelle → Postgres + pgvector.
• Vous utilisez déjà Redis / Mongo / Neo4j → ce backend.
• Vous souhaitez un modèle interrogeable de l'utilisateur, et non une transcription → GraphMemoryService.

Suivant : Graphe de connaissances →