Ciao a tutti, qui Alex di agntai.net. Siamo nel marzo 2026, e sto lottando con qualcosa che probabilmente è nella mente di molti di voi: come costruire agenti che non sembrino semplicemente delle chiamate API potenziate, ma che mostrino realmente un certo livello di comportamento intelligente e persistente? Più precisamente, sto riflettendo molto sulle architetture di memoria per gli agenti IA. È una cosa far rispondere un modello GPT a una domanda; è un’altra avere un agente che si ricordi di un progetto di diversi giorni, che adatti la propria strategia in base ai fallimenti passati e che impari veramente dalle interazioni.
Da un po’ di tempo, molti di noi si basano fortemente su database vettoriali come la nostra memoria esterna principale per gli agenti. E non fraintendetemi, sono fantastici per la generazione aumentata da recupero (RAG) e per dare ai nostri agenti accesso a enormi quantità di informazioni fattuali o contestuali. Ma dopo aver costruito alcuni prototipi per clienti – uno cercando di essere un assistente di ricerca personale, l’altro un bot di supporto clienti dinamico – ho cominciato a notare le loro limitazioni. Sono eccellenti per “di cosa abbiamo parlato martedì scorso?” o “quali sono le caratteristiche chiave del prodotto X?”, ma faticano con “ricordati di quella preferenza sottile che ho espresso tre settimane fa e integrala nella tua raccomandazione attuale.”
Ho avuto una rivelazione cercando di far capire al mio assistente di ricerca che io *odio davvero* gli articoli troppo accademici, a meno che non sia assolutamente necessario. Glielo dicevo, lui annuiva, poi due giorni dopo mi lanciava un altro articolo denso da arXiv tra le braccia. I vettori di rappresentazione per “non mi piacciono gli articoli accademici” erano lì, ma l’agente non imparava realmente dal mio feedback in un modo che modificasse effettivamente la sua strategia di ricerca a lungo termine. Era come parlare con qualcuno con un’ottima memoria a breve termine, ma senza memoria a lungo termine per le preferenze personali o il contesto evolutivo.
Oltre la ricerca vettoriale: Il bisogno di una memoria multimodale
La mia conclusione? Dobbiamo andare oltre una dipendenza unica dai database vettoriali per la memoria degli agenti. Non si tratta di sostituirli, ma di integrarli con altre forme di memoria che rispondano a diversi tipi di informazioni e a diversi orizzonti temporali. Pensate a come gli esseri umani si ricordano delle cose. Abbiamo una memoria di lavoro a breve termine, una memoria episodica (eventi), una memoria semantica (fatti) e una memoria procedurale (come fare le cose). Un solo vettore di codifica di un estratto di conversazione non separa questi elementi in modo chiaro.
Il problema di basarsi esclusivamente sulla ricerca vettoriale per tutto è che tratta tutti i ricordi come ugualmente importanti e ugualmente strutturati. Una preferenza sottile, una convinzione fondamentale, un obiettivo a lungo termine o un’osservazione transitoria – tutti vengono mescolati in rappresentazioni. Quando l’agente interroga la sua memoria, recupera ciò che è semanticamente simile, ma non necessariamente ciò che è *più pertinente* in un modo profondamente contestuale o temporalmente consapevole. È come avere una biblioteca in cui ogni libro è solo una raccolta di parole chiave, e dove è possibile trovare cose solo abbinando queste parole chiave, non comprendendo il genere del libro, l’intenzione dell’autore o la sua posizione in una serie.
Quindi, come appare un’architettura di memoria “multimodale” per un agente IA? Per me, si tratta di segmentare e strutturare diversi tipi di informazioni, poi fare in modo che il motore di ragionamento centrale dell’agente decida in modo intelligente quale archivio di memoria consultare e come aggiornarlo.
1. Memoria a breve termine / memoria di lavoro: Il taccuino
Questo è il contesto immediato del tuo agente. È ciò a cui l’agente sta pensando attivamente in questo momento. Per me, si tratta generalmente di una semplice lista dei turni recenti di una conversazione, dei parametri di attività correnti e delle osservazioni transitorie. È volatile e viene frequentemente cancellato o riassunto. Pensateci come alla RAM dell’agente.
esempio: Se il mio assistente di ricerca è attualmente incaricato di “trovare articoli sulle migliorie all’architettura dei trasformatori del 2024”, la sua memoria di lavoro contiene questa richiesta specifica, gli ultimi articoli che ha esaminato e forse un’indicazione che sta ancora cercando. Questo viene generalmente gestito passando la cronologia recente della conversazione direttamente al LLM o mantenendola in un semplice buffer in memoria.
2. Memoria episodica: Il diario degli eventi
È qui che i database vettoriali brillano davvero, ma con una twist. Invece di integrare semplicemente pezzi di conversazione grezzi, trovo più utile *riassumere* e *taggare* gli eventi prima di integrarli. Un “evento” può essere un’interazione con l’utente, un’azione dell’agente, una decisione presa o un’osservazione chiave. Ogni evento ha un timestamp, una breve descrizione e forse alcune entità associate o un’indicazione di sentimento.
Perché riassumere/taggare? Perché un transcript di conversazione grezzo può essere troppo rumoroso. “L’utente ha detto ‘è interessante’ poi ‘puoi mostrarmene di più’ poi ‘che mi dici di X?'” può essere riassunto in “L’utente ha espresso interesse, ha chiesto più informazioni, poi ha fatto domande su X.” Questo rende le rappresentazioni più concentrate sul *significato* dell’interazione piuttosto che sulla formulazione specifica. Questo consente anche un filtraggio più facile per tag in seguito.
# Pseudo-codice Python per un'entrata di memoria episodica
class EpisodicMemoryEntry:
def __init__(self, timestamp, description, tags=None, associated_entities=None, raw_context=None):
self.timestamp = timestamp
self.description = description # Evento riassunto dal LLM
self.tags = tags if tags is not None else []
self.associated_entities = associated_entities if associated_entities is not None else {}
self.raw_context = raw_context # Interazione originale per un richiamo dettagliato se necessario
def to_embedding_text(self):
# Concatenare i campi rilevanti per l'embedding
return f"Evento a {self.timestamp} : {self.description}. Tag : {', '.join(self.tags)}. Entità : {self.associated_entities}"
# Esempio di utilizzo :
# Supponiamo che 'llm_summarize_event' sia una funzione che chiama un LLM
# per condensare un estratto di conversazione in una descrizione e estrarre tag/entità.
conversation_chunk = "Utente : Ho davvero bisogno di finire questo rapporto entro venerdì. Agente : Va bene, come posso aiutarti? Utente : Puoi trovare le tendenze di mercato recenti per l'IA nel settore sanitario? Sono particolarmente interessato ai turni di finanziamento."
# Chiamata LLM per elaborare questo estratto
summary, tags, entities = llm_summarize_event(conversation_chunk)
# summary : "L'utente ha chiesto le tendenze di mercato recenti per l'IA nel settore sanitario, concentrandosi sui turni di finanziamento, da rendere entro venerdì."
# tags : ["richiesta_di_ricerca", "sensibile_al_termine", "IA_sanità", "turni_di_finanziamento"]
# entities : {"topic": "IA nel settore sanitario", "deadline": "venerdì", "focus": "turni di finanziamento"}
event = EpisodicMemoryEntry(
timestamp=datetime.now(),
description=summary,
tags=tags,
associated_entities=entities,
raw_context=conversation_chunk
)
# Poi, integrare event.to_embedding_text() e memorizzare nel database vettoriale
Quando l’agente ha bisogno di richiamare eventi passati, interroga questa memoria episodica, ma ora può anche filtrare per tag, entità o intervalli di tempo, oltre alla similarità semantica.
3. Memoria semantica: Il grafo delle conoscenze di fatti e credenze
Questo è forse il campo meno sviluppato in molte architetture di agenti, ma è qui che l’agente può memorizzare fatti strutturati, relazioni e le sue stesse credenze o preferenze evolutive. I database vettoriali sono sufficienti per fatti generali, ma non sono ideali per rappresentare le relazioni (ad esempio, “Alex preferisce X a Y”, “Il progetto Z è un sotto-task del progetto A”).
È qui che ho iniziato a sperimentare con grafi di conoscenze. Invece di integrare semplicemente tutto, utilizzo LLM per estrarre triplette (soggetto-predicato-oggetto) a partire dalle interazioni e memorizzarle in un database grafico (come Neo4j o anche un semplice database relazionale se il grafo non è troppo complesso).
Perché un grafo di conoscenze? Perché modella esplicitamente le relazioni. Se il mio agente impara “Alex non ama gli articoli accademici”, è una relazione diretta. Se poi impara “gli articoli sull’IA nel settore della salute sono spesso accademici”, può dedurre “Alex probabilmente non ama gli articoli sull’IA nel settore della salute.” Questo tipo di inferenza è difficile semplicemente con la similarità vettoriale.
# Pseudo-codice Python per estrarre e memorizzare i tripli
def extract_and_store_triples(agent_id, text_input):
# Chiamata LLM per estrarre tripli.
# Prompt: "Estrai tripli fattuali (soggetto, predicato, oggetto) dal seguente testo.
# Esempio: 'Alex preferisce il caffè' -> (Alex, preferisce, caffè)."
# text_input = "L'utente Alex ha menzionato che preferisce riassunti concisi e non ama articoli troppo accademici."
triples_str = call_llm_for_triple_extraction(text_input)
# Esempio di output: "[(Alex, preferisce, riassunti concisi), (Alex, non ama, articoli accademici)]"
extracted_triples = parse_triples_string(triples_str) # Convertire la stringa in lista di tuple
for s, p, o in extracted_triples:
# Memorizzare in un database grafico (ad esempio, utilizzando un semplice dizionario Python per la dimostrazione)
# In un sistema reale, sarebbe una chiamata client Neo4j o simile
graph_db_add_triple(agent_id, s, p, o)
# Esempio di 'graph_db_add_triple' (semplificato)
knowledge_graph = {} # {soggetto: {predicato: [oggetti]}}
def graph_db_add_triple(agent_id, s, p, o):
if agent_id not in knowledge_graph:
knowledge_graph[agent_id] = {}
if s not in knowledge_graph[agent_id]:
knowledge_graph[agent_id][s] = {}
if p not in knowledge_graph[agent_id][s]:
knowledge_graph[agent_id][s][p] = []
if o not in knowledge_graph[agent_id][s][p]: # Prevenire duplicati
knowledge_graph[agent_id][s][p].append(o)
# Per interrogare:
# Cosa non ama Alex? -> knowledge_graph[agent_id]["Alex"]["non ama"]
L’agente può interrogare questo grafo non solo tramite parole chiave, ma anche attraverso relazioni. “Quali sono le preferenze di Alex?” o “Quali compiti sono legati al Progetto A?” È un modo molto più potente per recuperare conoscenze strutturate.
4. Memoria Procedurale: La Libreria delle Competenze
Questo non corrisponde alla memoria in senso tradizionale, ma piuttosto a una collezione di strumenti, funzioni e flussi di lavoro che l’agente sa eseguire. Quando un LLM decide che deve svolgere un’azione, consulta questa “libreria delle competenze.” Potrebbe essere un elenco di funzioni Python, specifiche API o anche flussi di lavoro multi-passaggio predefiniti.
La mia esperienza: Ho trovato utile rendere queste competenze scopribili dal LLM utilizzando docstring descrittive e firme di funzione chiare. Il LLM può quindi scegliere lo strumento giusto in base all’obiettivo attuale.
class AgentSkills:
def search_web(self, query: str) -> str:
"""
Cerca sul web informazioni relative alla richiesta.
Utile per conoscenze generali, notizie e eventi recenti.
Args:
query (str): La richiesta di ricerca.
Returns:
str: Un riassunto dei risultati di ricerca.
"""
# ... implementazione reale della ricerca sul web ...
return f"Risultati di ricerca web per '{query}': ..."
def analyze_document(self, document_id: str, analysis_type: str) -> str:
"""
Analizza un documento specificato per vari approfondimenti.
Utile per riassumere, estrarre punti chiave o per l'analisi del sentiment di un documento.
Args:
document_id (str): L'ID del documento da analizzare.
analysis_type (str): Il tipo di analisi da eseguire (ad esempio, 'riassunto', 'parole chiave', 'sentiment').
Returns:
str: Il risultato dell'analisi.
"""
# ... implementazione dell'analisi del documento ...
return f"Analisi del documento {document_id} per {analysis_type}: ..."
def get_user_preferences(self, user_id: str, preference_type: str = None) -> dict:
"""
Recupera le preferenze memorizzate per un utente specifico.
Utile per personalizzare le risposte e le azioni.
Args:
user_id (str): L'ID dell'utente.
preference_type (str, opzionale): Tipo specifico di preferenza da recuperare (ad esempio, 'non ama', 'argomenti').
Returns:
dict: Un dizionario delle preferenze dell'utente.
"""
# Questo interrogherebbe la memoria semantica (grosso di conoscenze)
# Per semplificare, restituisce dati fittizi qui
if user_id == "Alex" and preference_type == "non ama":
return {"non ama": ["articoli accademici", "spiegazioni verbose"]}
return {"preferenze": "..."}
# Il LLM sarebbe invitato a selezionare e chiamare queste funzioni in base al proprio ragionamento.
Implementazione: Il Livello di Orchestrazione
La vera magia si verifica nel modo in cui il motore di ragionamento centrale dell’agente (il LLM stesso, tipicamente) interagisce con questi diversi magazzini di memoria. Non è semplicemente un sistema di recupero passivo; l’agente deve decidere attivamente:
- Di quali informazioni ho bisogno in questo momento?
- Quale magazzino di memoria è più probabile contenga queste informazioni?
- Come dovrei aggiornare la mia memoria in base a questa nuova interazione/osservazione?
Questo processo decisionale è dove l’agente diventa davvero dinamico. Di solito structuro questo con un prompt che guida il LLM a riflettere ad alta voce, pianificare e poi eseguire operazioni di memoria. È una catena di processi di pensiero che integra l’interazione della memoria.
Il mio approccio attuale:
- Percepire: L’agente riceve un input (richiesta dell’utente, evento di sistema).
- Riflettere & Pianificare: Il LLM analizza l’input, considera gli obiettivi attuali e formula un piano. Questo piano implica spesso interrogare la memoria.
- “Ho bisogno di richiamare interazioni passate (episodiche)? Quali sono le preferenze conosciute dell’utente (semantiche)? Ho strumenti per raggiungere questo (procedurale)?”
- Potrebbe interrogare la memoria episodica per situazioni passate simili o la memoria semantica per fatti pertinenti.
- Agire: A seconda del piano e dei ricordi recuperati, il LLM decide un’azione (ad esempio, generare una risposta, chiamare uno strumento, aggiornare la memoria).
- Memorizzare & Imparare: Dopo un’azione, il LLM riflette sul risultato e aggiorna i suoi diversi magazzini di memoria.
- Una nuova interazione è riassunta e aggiunta alla memoria episodica.
- Fatti o preferenze nuovi vengono estratti e aggiunti al grafo di conoscenze semantiche.
- Se una strategia fallisce, potrebbe generare un input “lezione appresa” nella memoria semantica.
Questo processo iterativo consente all’agente di sviluppare una comprensione più ricca e sfumata del suo ambiente, del suo utente e di se stesso nel tempo. Va oltre il semplice recupero di fatti per formare realmente credenze persistenti e adattare il proprio comportamento.
Consigli Pratici per l’Architettura del Tuo Agente
Se stai costruendo agenti AI in questo momento e raggiungendo i limiti del semplice RAG, ecco cosa ti consiglio di provare:
- Non trattare tutta la memoria allo stesso modo. Categorizza il tipo di informazioni che devi memorizzare: contesto a breve termine, cronologia degli eventi, fatti/preferenze strutturati e capacità.
- Aumenta il tuo database vettoriale. È eccellente per la memoria episodica, soprattutto quando riassumi e etichetti le entrate. Ma non farne l’unico magazzino di memoria.
- Sperimenta con grafi di conoscenze per la memoria semantica. Anche un semplice magazzino di tripli può fare una grande differenza nel modo in cui il tuo agente memorizza e recupera relazioni strutturate e credenze fondamentali. Questo consente un vero ragionamento, non solo una ricerca di similarità.
- Progetta per una gestione attiva della memoria. Il motore di ragionamento centrale dell’agente (il tuo prompt LLM) dovrebbe includere esplicitamente passaggi per interrogare, aggiornare e riflettere sui suoi diversi magazzini di memoria. Non limitarti a riversare tutto il contesto in un solo prompt.
- Mantieni la memoria procedurale (utilizzo degli strumenti) organizzata. Descrizioni chiare ed esempi per i tuoi strumenti aiutano il LLM a utilizzare efficacemente le sue capacità.
Costruire veri agenti intelligenti non si limita a modelli più grandi; si tratta di design più intelligenti. Offrendo ai nostri agenti un sistema di memoria più simile a quello umano, possiamo avvicinarci a agenti che non solo si ricordano, ma apprendono e si adattano realmente. È un percorso difficile ma incredibilmente gratificante, e non vedo l’ora di vedere dove tutti noi lo porteremo successivamente.
🕒 Published: