HydraDB per la memoria degli agenti: cosa cambia passando da vettori a contesto strutturato
HydraDB propone un livello di memoria con grafo, versioni temporali e recupero a bassa latenza. Cosa dichiara il prodotto e come valutarlo in un progetto RAG.
Scritto da Daniel Vedovato · Revisionato il 21 luglio 2026
Articolo preparato con assistenza AI, verificato e revisionato da Daniel Vedovato.
Il problema non è soltanto trovare testo simile
HydraDB si presenta come un livello di memoria per applicazioni AI che combina relazioni a grafo, rappresentazioni semantiche, dati temporali e contesto di sessione. La proposta nasce da un limite riconoscibile nei sistemi RAG: un indice vettoriale è efficace nel trovare testi semanticamente vicini, ma vicinanza non significa sempre relazione utile per la decisione successiva di un agente.
Un assistente che gestisce ordini, ticket o una knowledge base può dover collegare una persona a una preferenza, una data, un documento sostituito e un’azione precedente. Se tutto viene trasformato in chunk indipendenti, il recupero rischia di restituire passaggi plausibili ma incompleti. Un grafo permette invece di rappresentare esplicitamente entità e legami, per esempio “cliente”, “contratto”, “versione”, “evento” e “autorizzazione”.
Sul proprio sito HydraDB dichiara un’architettura con acquisizione di contesto, riconoscimento e risoluzione di entità, unità di memoria con testo, embedding, timestamp e metadati, oltre a relazioni semantiche, temporali e causali. Descrive anche storage a livelli: cache in memoria, SSD e object storage. Sono dichiarazioni del fornitore, non benchmark indipendenti: vanno considerate ipotesi da verificare nel proprio carico di lavoro.
Cosa promette e cosa va misurato
Il sito riporta un obiettivo di richiamo inferiore a 200 millisecondi per applicazioni a bassa latenza. Il numero è utile come requisito progettuale, ma da solo è insufficiente. Non chiarisce dimensione del dataset, complessità del grafo, hardware, percentili di latenza, concorrenza, costo di estrazione dei fatti né qualità del contesto restituito. Un sistema può rispondere rapidamente e recuperare l’entità sbagliata.
La stessa prudenza vale per le percentuali di accuratezza comunicate su benchmark. Un benchmark misura un compito con un certo dataset e protocollo; non dimostra automaticamente prestazioni su documenti italiani, procedure interne o conversazioni rumorose. La domanda corretta non è “HydraDB è più accurato?”, ma “riduce gli errori che oggi impediscono al mio agente di completare un compito?”.
| Aspetto | Potenziale vantaggio | Prova minima |
|---|---|---|
| Relazioni | Recuperare legami oltre alla somiglianza testuale | Query con entità, date e documenti collegati |
| Tempo | Ricostruire cosa era valido a una certa data | Confronto fra due versioni dello stesso fatto |
| Preferenze | Evitare duplicati e contraddizioni fra sessioni | Test con record volutamente discordanti |
| Latenza | Servire agenti interattivi | p50, p95 e p99 sotto carico reale |
| Controllo | Tracciare da dove arriva un ricordo | Log con fonte, versione e regola di recupero |
La memoria è anche una superficie di sicurezza
Memorizzare il contesto di un utente non è un dettaglio neutro. Un agente può ricevere istruzioni nascoste in un documento, preferenze obsolete oppure dati che non dovrebbe riutilizzare in un’altra conversazione. Quando una piattaforma conserva ricordi attraverso le sessioni, aumenta il valore della provenienza e la gravità di un errore di autorizzazione.
Prima dell’integrazione servono almeno quattro policy: quali fonti possono scrivere memoria, quali ruoli possono leggerla, per quanto tempo un elemento viene conservato e come viene cancellato o corretto. È utile separare inoltre fatti verificati, osservazioni, preferenze e testo non affidabile. Trattare ogni frase estratta come conoscenza stabile è il modo più veloce per rendere persistente una risposta sbagliata.
La risoluzione delle entità è un esempio concreto. Unire due persone con nomi simili può migliorare il recupero in demo e creare un problema di privacy in produzione. Il sistema dovrebbe conservare il motivo dell’unione, una confidenza, la fonte e una procedura per annullarla. Senza questa capacità, il grafo diventa difficile da correggere proprio quando acquista più valore.
Come impostare un pilota utile
Un pilota ragionevole usa un archivio circoscritto e già versionato, non tutte le conversazioni dell’azienda. Si scelgono trenta o cinquanta domande reali, con una risposta attesa e una fonte identificabile. Poi si confrontano una baseline RAG con vettori e una pipeline che aggiunge relazioni e filtri temporali. Le metriche includono precisione delle fonti, accuratezza della risposta, numero di contesti inutili, latenza e interventi manuali necessari.
Per evitare un confronto favorevole, la stessa procedura di chunking e lo stesso modello generativo devono rimanere fissi. Cambiano solo il modello di memoria e le regole di retrieval. Vale anche la pena inserire casi avversari: due contratti con date diverse, una preferenza revocata, una nota con istruzioni malevole e un soggetto omonimo. Se il sistema non sa spiegare perché una memoria viene richiamata, non dovrebbe guidare azioni sensibili.
Verdetto
HydraDB intercetta un problema reale: gli agenti hanno bisogno di contesto che sia non soltanto simile, ma collegato, aggiornato e governabile. Grafi e versioni temporali possono offrire un vantaggio quando il dominio è ricco di relazioni. Il vantaggio non deriva però dal nome “memoria agentica”. Dipende dalla qualità dell’estrazione, dalle policy di scrittura, dai test di recupero e dalla possibilità di correggere il passato. Prima di migrare un RAG esistente, la prova giusta è misurare su domande con relazioni e tempo, non su un generico benchmark di similarità.