Ciao a tutti, Alex qui da agntai.net. È marzo 2026, e sto affrontando qualcosa con cui penso che molti di voi che lavorano con agenti IA si sentiranno probabilmente a loro agio: la pura complessità di far sì che queste cose funzionino in modo affidabile nel mondo reale. Abbiamo superato la fase della “demo interessante” per molti sistemi agenti. Ora si tratta di stabilità, prevedibilità e debugging quando le cose inevitabilmente vanno male.
Specificamente, voglio parlare della memoria dell’agente. Non solo del vettore per RAG, che tutti e i loro cani stanno implementando, ma dei sistemi di memoria più sfumati e multilivello che consentono a un agente di apprendere, adattarsi e mantenere il contesto nel lungo periodo e attraverso compiti diversi. È ciò che separa un wrapper API glorificato da qualcosa che sembra veramente un assistente intelligente.
Quando ho iniziato a costruire il mio agente “project manager”, poco più di un anno fa, il mio sistema di memoria era… primitivo. Una semplice lista di interazioni passate, magari un breve riassunto allegato al prompt per il turno successivo. Funzionava per conversazioni brevi, ma in qualsiasi situazione complessa, in cui l’agente doveva richiamare una decisione presa tre giorni fa o una preferenza espressa in un contesto completamente diverso, andava semplicemente a pezzi. Era come parlare con qualcuno affetto da grave perdita di memoria a breve termine.
Oltre il Vettore: La Necessità di una Memoria Multilivello
Attualmente, l’approccio standard, e un buon punto di partenza, è un database vettoriale per recuperare blocchi di informazioni rilevanti. Scarichi le conversazioni passate del tuo agente, documenti, osservazioni – quello che vuoi – in embeddings, e poi usi la similarità semantica per estrarre ciò che potrebbe essere utile per il compito attuale. È efficace per ottenere contesto, ma non è veramente “memoria” nel senso umano. È più simile a un motore di ricerca altamente efficiente per esperienze passate.
Pensa a come ricordiamo le cose. Abbiamo memoria a breve termine (il nostro contesto attuale), memoria a lungo termine (fatti, abilità, eventi passati) e memoria episodica (specifiche esperienze legate a tempo e luogo). Abbiamo anche la capacità di generalizzare dalle esperienze, formare abitudini e aggiornare le nostre credenze. Un semplice vettore fa fatica con tutto ciò.
Il mio agente “project manager”, chiamiamolo ‘Orion’, doveva fare di più che semplicemente richiamare messaggi passati. Doveva:
- Ricordare le mie specifiche preferenze su come vengono suddivisi i compiti.
- Tenere traccia degli obiettivi complessivi del progetto, anche quando si discute di un dettaglio minuto.
- Imparare dai fallimenti passati – ad esempio, se una certa suddivisione del compito portava costantemente a ritardi, dovrebbe suggerire alternative la prossima volta.
- Comprendere le relazioni tra i vari pezzi di informazione.
Questo mi ha portato a cercare di costruire un’architettura di memoria più sofisticata. Ecco quella che ho trovato essere un approccio pratico, anche se ancora in evoluzione.
Livello 1: Il Contesto Etereo (Memoria di Lavoro)
Questo è il contesto del tuo prompt immediato. Per ogni turno, contiene l’input attuale dell’utente, gli ultimi turni di conversazione e qualsiasi fatto o direttiva immediata. Questo viene tipicamente passato direttamente all’LLM. È veloce, temporaneo e cruciale per mantenere il flusso.
Per Orion, questo sarebbe il compito attuale che le sto dando, eventuali domande di follow-up immediate e gli ultimi 3-5 scambi che abbiamo avuto. Di solito fisso un limite ai token per prevenire il prompt stuffing.
Livello 2: L’Archivio Semantico (Memoria Lunga, Dichiarativa)
È qui che entra in gioco il tuo vettore. È il tuo repository di tutte le interazioni passate, osservazioni, pensieri generati e qualsiasi documento esterno a cui l’agente ha accesso. Quando il contesto etereo non basta, Orion consulta questo archivio per recuperare informazioni rilevanti.
La chiave qui non è solo scaricare tutto. Si tratta di come suddividi e incorpori. Invece di integrare solo i turni di conversazione grezzi, spesso faccio riassumere a Orion o estrarre fatti/decisioni chiave dalle interazioni e poi incorporo quelli. Questo riduce il rumore e migliora la rilevanza del recupero.
def store_fact(agent_id, fact_text, fact_embedding, timestamp):
# Questo è un esempio semplificato. Nella realtà, useresti un client di DB vettoriale.
db.insert_embedding(
collection_name=f"{agent_id}_facts",
text=fact_text,
embedding=fact_embedding,
metadata={"timestamp": timestamp}
)
def retrieve_relevant_facts(agent_id, query_embedding, k=5):
# Ancora semplificato. Usa la funzione di ricerca del tuo DB vettoriale.
results = db.query_embeddings(
collection_name=f"{agent_id}_facts",
query_embedding=query_embedding,
top_k=k
)
return [r.text for r in results]
# Esempio d'uso:
# user_query = "Cosa abbiamo deciso riguardo al budget per il marketing la settimana scorsa?"
# query_embedding = get_embedding(user_query)
# relevant_facts = retrieve_relevant_facts("Orion", query_embedding)
# print(relevant_facts)
Ho anche trovato utile fare in modo che Orion “riflettesse” attivamente sulle sue azioni passate o su un insieme di fatti recuperati. Questo implica sollecitare l’LLM con un insieme di memorie recuperate e chiedere di sintetizzare nuove intuizioni di alto livello o generalizzare modelli. Queste intuizioni sintetizzate vengono poi archiviate anche nell’archivio semantico, creando un ciclo di feedback per l’apprendimento.
Livello 3: Il Grafico della Conoscenza (Memoria Relazionale)
Qui le cose diventano davvero interessanti, e dove Orion ha cominciato a sembrare veramente più capace. Un grafo della conoscenza consente di memorizzare relazioni tra entità, non solo fatti isolati. Invece di sapere solo che “Il Compito A dipende dal Compito B”, un grafo può mostrare che “Il Compito A è parte del Progetto X”, “Il Progetto X è gestito da Alex” e “Il Compito B è fallito l’ultima volta a causa della Risorsa Y.”
Utilizzo un semplice database a grafo di proprietà (come Neo4j o anche un’impostazione personalizzata con SQLAlchemy per progetti più piccoli) per memorizzare entità e le loro relazioni. Orion, dopo aver elaborato un’interazione o recuperato fatti, viene invitata a estrarre entità e relazioni. Queste poi vengono aggiunte al grafo.
Ad esempio, se dico a Orion: “La nuova funzionalità ‘Modalità Dark’ deve essere implementata entro la fine del mese prossimo, e dipende dal completamento del refresh dell’interfaccia utente”, Orion dovrebbe:
- Identificare le entità: “Modalità Dark” (Funzionalità), “Refresh UI” (Compito), “Fine del mese prossimo” (Scadenza).
- Identificare le relazioni: “Modalità Dark” ha_scadenza “Fine del mese prossimo”, “Modalità Dark” dipende_da “Refresh UI”.
Poi, quando chiedo della “Modalità Dark”, Orion può consultare il grafo non solo per ottenere la scadenza ma anche per vedere immediatamente la sua dipendenza. Questo consente di prendere decisioni più informate e suggerire proattivamente.
# Funzione semplificata di aggiornamento del grafo della conoscenza
from py2neo import Graph, Node, Relationship
graph = Graph("bolt://localhost:7687", auth=("neo4j", "password"))
def update_knowledge_graph(agent_id, entities_relationships_json):
tx = graph.begin()
for item in entities_relationships_json:
if item["type"] == "entity":
node = Node(item["label"], name=item["name"])
tx.merge(node, item["label"], "name")
elif item["type"] == "relationship":
source = Node(item["source_label"], name=item["source_name"])
target = Node(item["target_label"], name=item["target_name"])
rel = Relationship(source, item["relationship_type"], target)
tx.merge(rel, item["relationship_type"])
tx.commit()
# Esempio di output LLM da analizzare per l'aggiornamento del grafo:
# {
# "entities": [
# {"type": "entity", "label": "Funzionalità", "name": "Modalità Dark"},
# {"type": "entity", "label": "Compito", "name": "Refresh UI"}
# ],
# "relationships": [
# {"type": "relationship", "source_label": "Funzionalità", "source_name": "Modalità Dark",
# "relationship_type": "DIPENDE_DA", "target_label": "Compito", "target_name": "Refresh UI"}
# ]
# }
# update_knowledge_graph("Orion", parsed_llm_output)
La bellezza di questo è che il recupero dal grafo non è solo semantico; è strutturale. Puoi chiedere “tutti i compiti che dipendono dal Refresh UI” o “tutti i progetti gestiti da Alex”. Questo aggiunge una nuova dimensione alle capacità di ragionamento di un agente.
Livello 4: Il Sistema di Credenze (Memoria Adattiva)
Questo è il livello più difficile, ed è quello su cui sto ancora sperimentando attivamente. Si tratta di consentire all’agente di aggiornare i suoi modelli interni, credenze o preferenze basate sull’esperienza. Non si tratta solo di richiamare un fatto; si tratta di alterare il suo comportamento o il processo decisionale.
Per Orion, questo significa cose come:
- Se rifiuto ripetutamente una certa strategia di suddivisione del compito, Orion dovrebbe imparare a non suggerirla nuovamente, o almeno a suggerirla con delle riserve.
- Se un membro specifico del team perde costantemente le scadenze, Orion dovrebbe tenerne conto nella pianificazione futura o nell’assegnazione dei compiti.
- Se preferisco sempre spiegazioni dettagliate rispetto a riassunti generali, Orion dovrebbe adattare il suo stile comunicativo.
Il mio approccio attuale qui implica una combinazione di due cose:
- Memorizzazione delle Preferenze Esplicite: Ho una tabella dedicata (o una sezione nel grafo della conoscenza) per memorizzare le preferenze esplicite o “regole” che Orion ha appreso. Queste sono spesso generate da Orion stessa attraverso la riflessione (ad esempio, “L’utente preferisce scomposizioni dettagliate dei compiti”) o dette esplicitamente a lei. Queste preferenze vengono poi incluse nel prompt quando rilevante.
- Reinforcement Learning-lite: Questo è in fase nascenti, ma per alcuni punti decisionali (ad esempio, scegliere una strategia di scomposizione dei compiti), sto esplorando l’uso di un semplice meccanismo di feedback. Se accetto un suggerimento, riceve un segnale positivo. Se lo rifiuto, un segnale negativo. Questo segnale non aggiorna direttamente una rete neurale, ma potrebbe influenzare un “punteggio di fiducia” associato a una particolare strategia, che Orion considera quando fa suggerimenti futuri. È meno focalizzato sull’ottimizzazione di una politica e più sul pesare le sue “euristiche” interne.
Questo strato è meno incentrato sul recupero e più sull’adattamento proattivo. È la differenza tra un agente che conosce un fatto e un agente che interiorizza una lezione.
Mettendo Tutto Insieme: Un Orchestra della Memoria
Avere questi strati è una cosa; farli funzionare insieme è un’altra. Ho scoperto che è necessario un componente “Orchestratore della Memoria” che decide quale sistema di memoria interrogare e quando. Questo è spesso un’altra chiamata LLM, che funge da router.
Quando Orion riceve un nuovo input:
- L’orchestratore prima controlla il Contesto Effimero. La risposta è immediatamente disponibile?
- Se no, genera una query e interroga l’Archivio Semantico (store vettoriale) per interazioni o fatti passati rilevanti.
- Contestualmente, o se il recupero semantico non è sufficiente, potrebbe generare una query di grafo per il Grafo della Conoscenza per estrarre informazioni relazionali (dipendenze, proprietà, ecc.).
- Infine, prima di generare una risposta, consulta il Sistema di Credenze per vedere se ci sono preferenze o regole apprese che dovrebbero influenzare l’output.
Tutte queste informazioni recuperate vengono poi compilate e fornite al principale LLM per generare la risposta finale o l’azione. È una serie di recuperi e filtraggi a cascata che unisce un contesto approfondito.
Sfide e Direzioni Future
Costruire questo sistema di memoria multilivello non è stato senza difficoltà:
- Costi e Latenza: Ogni ulteriore passaggio di recupero aumenta i costi delle API e la latenza. È necessario un routing e una cache intelligenti.
- Coerenza: Mantenere i fatti coerenti nel store vettoriale, nel grafo della conoscenza e nel sistema di credenze è difficile. A volte Orion apprende qualcosa in un livello che è in conflitto con un altro.
- Debugging: Quando Orion prende una cattiva decisione, risalire a quale componente di memoria ha fornito informazioni fuorvianti o non è riuscito a recuperare qualcosa di cruciale è un incubo.
- Schema di Evoluzione: Lo schema del grafo della conoscenza non è statico. Man mano che Orion apprende nuovi tipi di entità o relazioni, devo aggiornare la struttura del grafo e il suo prompting per l’estrazione.
Guardando al futuro, sono veramente interessato a esplorare modi più solidi affinché l’agente possa auto-organizzare la sua memoria. Può Orion identificare automaticamente le lacune nel suo grafo della conoscenza? Può sintetizzare e condensare proattivamente i ricordi senza un prompting esplicito? Come possiamo integrare meglio il “sistema di credenze” con il ciclo di ragionamento centrale senza semplicemente sovraccaricare il prompt?
Osservazioni Utili per i Tuoi Agenti
Se stai costruendo un agente AI e raggiungendo i limiti del semplice recupero vettoriale, ecco cosa ti suggerisco di considerare:
- Inizia Semplice, Poi Espandi: Non cercare di costruire tutti gli strati contemporaneamente. Fai funzionare prima il tuo contesto effimero e un basic store vettoriale.
- Pensa a “Cosa” e “Come”:
- Cosa deve essere ricordato? (Fatti, relazioni, preferenze, azioni passate, piani?)
- Come dovrebbe essere recuperata e utilizzata quella informazione? (Ricerca semantica, percorrenza di grafo, lookup diretto, applicazione di regole?)
- Abbraccia la Riflessività: Invita regolarmente il tuo agente a riflettere sulle sue azioni passate, sintetizzare intuizioni e aggiornare i suoi archivi di memoria. Questo è cruciale per l’apprendimento.
- Considera un Grafo della Conoscenza per Dati Relazionali: Se il tuo agente deve comprendere dipendenze, gerarchie o relazioni complesse, un database a grafo è estremamente potente.
- Sperimenta con Componenti Adattivi: Per preferenze o comportamenti appresi, esplora semplici store di preferenze o euristiche pesate prima di passare a un reinforcement learning completo.
- Costruisci un Orchestra della Memoria: Non limitarti a scaricare tutta la memoria nel prompt. Disegna un componente che interroga intelligentemente i diversi strati di memoria in base al contesto e al compito attuali.
- Itera e Debugga: I sistemi di memoria sono complessi. Aspettati di trascorrere molto tempo a testare, fare debugging e affinare il modo in cui il tuo agente memorizza e recupera informazioni.
Il percorso verso agenti veramente intelligenti è lungo, ma costruire sistemi di memoria sofisticati e multilivello è un passo cruciale. Ci porta oltre i chatbot reattivi verso agenti che possono davvero apprendere, adattarsi e operare con una comprensione più profonda del loro mondo. Mi piacerebbe conoscere le tue esperienze e approcci alla memoria degli agenti – lascia un commento qui sotto!
🕒 Published: