Memoria a lungo termine per agenti AI: architettura a due livelli con AlloyDB e Memorystore per Valkey

Gli agenti AI enterprise necessitano di memoria persistente per eseguire flussi di lavoro complessi che si estendono su più giorni e per gestire task a lungo orizzonte. Google Cloud ha pubblicato una guida tecnica dettagliata che descrive un'architettura a due livelli basata su Memorystore per Valkey per la memoria a breve termine e AlloyDB AI per la memoria a lungo termine, dimostrando come questo approccio possa ridurre la spesa per token fino al 70% e migliorare i tempi di risposta dell'80%.

Il problema: gli LLM sono stateless

I large language model (LLM) non mantengono stato tra una sessione e l'altra. Quando un utente torna da un agente dopo giorni, il modello riparte da una finestra di contesto vuota. Senza un meccanismo di ricostruzione del contesto passato, l'utente deve rispiegare obiettivi e vincoli, generando un'esperienza frammentata.

Due scorciatoie comuni si rivelano insufficienti su larga scala:

• Context stuffing: inserire tutto lo storico nel prompt a ogni turno. I costi dei token moltiplicano, la latenza supera i 30 secondi e il modello soffre del problema "lost in the middle", trascurando istruzioni critiche sepolle nel testo.
• Rolling summaries: chiedere all'LLM di comprimere periodicamente i messaggi più vecchi. La compressione è intrinsecamente lossy: dopo alcuni cicli, dettagli sottili ma importanti vengono filtrati come rumore e l'agente viola silenziosamente i vincoli definiti in precedenza.

L'architettura a due livelli

La soluzione proposta separa nettamente due tipi di memoria:

1. Buffer di sessione a breve termine (Memorystore per Valkey)

• Memorizza i turni di conversazione recenti in una finestra scorrevole limitata per token.
• Richiede lookup sub-millisecond ad alto throughput a ogni turno.
• Valkey (compatibile Redis) è ideale per mantenere lo stato di sessione attivo.

2. Memoria persistente a lungo termine (AlloyDB AI)

• Conserva fatti importanti, preferenze utente, memorie episodiche e regole vincolanti across sessioni.
• Richiede integrità transazionale, governance dei dati e retrieval ibrido su dati relazionali e vettoriali.
• AlloyDB AI fornisce nativamente queste capacità.

La divisione del lavoro evita write amplification e table bloat nel database relazionale: i buffer di sessione sono effimeri e generano scritture rapidissime a ogni turno; scaricarli su una cache in-memory mantiene il database primario snello e reattivo per le sue funzioni native: consistenza transazionale, hybrid vector search complessa, query analitiche di lungo periodo.

Quattro tipi di memoria organizzati sui due livelli

TipoCosa memorizzaLivelloDurata Buffer (breve termine)Turni di conversazione recentiMemorystore per ValkeySessione attiva Summary memoryStorico compresso dei turni più vecchi (compaction)Memorystore per ValkeyFinestra multi-turno Episodic memoryAzioni passate, eventi, output degli strumentiAlloyDB (hybrid retrieval: SQL + full-text + vector)Permanente Entity & rule memoryPreferenze, vincoli, veti dell'utenteAlloyDB (hybrid retrieval: SQL + full-text + vector)Permanente

Percorsi di lettura e scrittura

Read path: alla domanda dell'utente, l'applicazione recupera la finestra scorrevole attiva da Valkey, normalizza la query in-database con ai.generate e interroga AlloyDB tramite ai.hybrid_search per recuperare regole di entità e fatti episodici rilevanti.

Write path: dopo aver generato la risposta, il turno viene cachato immediatamente in Valkey. Un worker asincrono in coda estrae entità strutturate dallo scambio e le scrive in AlloyDB, dove gli auto-embedding transazionali calcolano e memorizzano le rappresentazioni vettoriali nello stesso database.

Impatto misurabile: benchmark interni

Su dialoghi di sviluppo multi-turno (45+ turni con heavy tool execution), l'architettura a due livelli ha mostrato:

• Dimensione prompt attivo (turno 45): 747.033 token (naive) vs 83.262 token (tiered) → -88,9%
• Latenza risposta turno 45: 33,5 s vs 6,7 s → -80%
• Token cumulativi sessione: 17,9 M vs 4,09 M → -72% costi token
• Recall regole e vincoli: degrada nel tempo (naive) vs non degrada (tiered, ACID-preserved)

Questi risultati dimostrano come la memoria tiered cambi l'economia unitaria dell'agente: invece di una curva di costo crescente a ogni turno aggiuntivo, le dimensioni del prompt rimangono limitate, riducendo le spese API LLM correnti e mantenendo i tempi di risposta bassi.

Vantaggi tecnici chiave di AlloyDB AI

• Auto-embedding transazionali in-database (ai.initialize_embeddings): AlloyDB genera automaticamente embedding vettoriali per colonne di testo usando l'integrazione nativa con Agent Platform (ex Vertex AI), fino a 3.000 embedding/sec. Con incremental_refresh_mode => 'transactional' gli embedding restano aggiornati al cambiare dei dati source nella stessa transazione, eliminando pipeline custom, scheduler esterni, logiche di retry complesse.
• Funzioni generative AI in-database (ai.generate): esecuzione di modelli foundation (es. Gemini) direttamente da query SQL. Utile per decomposizione query in-database: scomporre domande composte in sub-query mono-aspetto e risolvere frasi temporali relative ("ultima sessione") in identificatori espliciti, senza roundtrip applicativi.
• Hybrid search nativo con Reciprocal Rank Fusion (ai.hybrid_search): funzione SQL built-in che esegue RRF dentro il motore, combinando similarità coseno vettoriale (su indici HNSW o ScaNN) con full-text search PostgreSQL (BM25, RUM, GIN) in una singola chiamata DB, fondendo matching semantico e recupero per keyword esatte con pushdown di filtri metadata (filter_condition) per performance e isolamento deterministico dello scope.
• Integrazione diretta Agent Platform con credenziali IAM: connessione privata verso modelli foundation via rete Google Cloud, ruoli IAM service account e autenticazione database, senza API key nel codice applicativo.
• Motore unificato operativo, vettoriale, governance: AlloyDB consolida dati relazionali business, embedding vettoriali, indici full-text, permessi enterprise in un singolo database PostgreSQL ACID-compliant, evitando data drift e complessità di integrazione tra database operazionali e vettoriali separati.

Pattern di implementazione principali

1. Schema e auto-embedding

In AlloyDB, installare le estensioni necessarie e definire la tabella agent_entities con metadati strutturati, colonna tsvector generata per full-text search e colonna embedding vettoriale. Generare gli embedding con ai.initialize_embeddings in modalità transazionale. Creare indici HNSW (vettoriale) e RUM (full-text) per hybrid search veloci.

2. Query memoria a lungo termine con hybrid search nativo

Sul read path, recuperare entità rilevanti via ai.hybrid_search. La funzione SQL nativa esegue RRF direttamente in AlloyDB, combinando e rerankando risultati di vector similarity e full-text keyword search in una singola query, con filtri su user_id, project_id, scope per isolamento multi-tenant.

3. Compaction memoria in-database con funzioni AI

Per gestire la crescita dello storage long-term senza script di pruning custom, eseguire query automatiche di estrazione e compaction direttamente in AlloyDB usando CTE con ai.generate per consolidare entry episodiche vecchie in summary ad alta densità. Esempio: una lunga interazione su complessità di cambi volo con bambini produce il summary "Preferisco voli diretti".

4. Integrazione con agenti ADK

Estendere il provider Memory di default di ADK (Agent Development Kit) per usare l'architettura 2-tier come ADKTieredMemoryProvider. Allegare la memoria long-term come tool (es. longterm_memory_tool) all'agente ADK.

Governance enterprise e sicurezza multi-tenant

• Isolamento scope e multi-tenant: indicizzare user_id, project_id, scope in agent_entities e applicare PostgreSQL Row-Level Security (RLS) per isolare gli store di memoria tra dipartimenti, team, utenti nello stesso cluster.
• Parameterized Secure Views (PSV): ulteriore layer di sicurezza applicativa deterministica contro prompt malevoli e query SQL eccessivamente ampie.
• Lifecycle management automatizzato: combinare query SQL di compaction schedulate con partition pruning time-based per mantenere footprint DB e latenze query prevedibili nel tempo.

Prossimi passi per consulenti e MSP

L'approccio di disaccoppiare finestre di contesto attive da storage persistente è una strada pratica per agenti AI production-ready. Abbinando Memorystore per Valkey (caching sessione sub-millisecond) ad AlloyDB AI (storage long-term transazionale) si ottengono risparmi significativi sui costi token e risposte più veloci, preservando regole business rigorose in task a lungo orizzonte ed esperienze agentiche many-turn.

• Seguire il tutorial hands-on completo nel AlloyDB Agent Memory Codelab per deployare l'architettura 2-tier funzionante.
• Approfondire le funzionalità ML lato database nella documentazione AlloyDB AI.
• Esplorare le guide su generazione auto embedding vettoriali ed esecuzione hybrid vector search.

Per MSP e system integrator che costruiscono soluzioni AI per PMI, questo pattern architetturale offre un template riutilizzabile: separare lo stato effimero della conversazione dalla conoscenza persistente dell'agente, sfruttando servizi gestiti che scalano indipendentemente e riducono l'operational overhead.