Memoria attiva e memoria persistente nell’IA: come l’IA ricorda, recupera e dimentica

La memoria attiva è l’insieme delle informazioni a disposizione di un sistema di IA per svolgere il compito che sta affrontando. La memoria persistente è costituita dalle informazioni che l’applicazione circostante conserva affinché possano essere riutilizzate in seguito. Il rapporto tra le due determina se un assistente può portare avanti un progetto, applicare una preferenza, correggere un presupposto non più valido o smettere di riproporre qualcosa che avrebbe dovuto dimenticare.

Immagina un assistente che ti aiuta a preparare una relazione di ricerca. Nel corso di una conversazione può fare riferimento alla scaletta, alle tue modifiche più recenti e alle fonti che gli hai appena fornito. Se apri una conversazione separata una settimana dopo, la continuità dipende da un meccanismo diverso: occorre che l’applicazione abbia salvato le informazioni pertinenti, sia in grado di trovarle e le fornisca di nuovo al modello.

Ecco perché un’IA può sembrare ricordare un dettaglio e dimenticarne un altro emerso nello stesso scambio. Ricordare è una catena di operazioni. Un errore può verificarsi quando le informazioni vengono acquisite, archiviate, cercate, selezionate, interpretate o aggiornate.

Questa guida esamina nel dettaglio i passaggi di questa catena. Per una panoramica più ampia della classificazione della memoria episodica, semantica e procedurale, consulta la nostra introduzione alle tipologie di memoria degli agenti di IA. Qui ci concentriamo sul confine tra ciò che è attivo nel presente e ciò che può persistere oltre il compito in corso.

Che cosa significano davvero memoria attiva e memoria persistente?

Questi termini descrivono distinzioni architetturali utili, ma non costituiscono una coppia universalmente standardizzata. Nelle interfacce dei prodotti e negli articoli di ricerca, «memoria di lavoro», «memoria a breve termine», «contesto», «stato» e «memoria a lungo termine» sono usati con significati che in parte si sovrappongono. Per spiegarli con precisione, è quindi necessario definirli.

In questo articolo, per contesto attivo si intendono le informazioni fornite al modello per la risposta corrente: istruzioni, messaggi, risultati selezionati degli strumenti, materiali recuperati e altri input che il modello può elaborare. Lo stato attivo dell’attività è un concetto più ampio. Può includere un piano, una lista di controllo o variabili che l’applicazione mantiene, ma che non ha ancora inserito nel contesto del modello. Usiamo «memoria attiva» come termine generale e pratico per indicare questo insieme di lavoro corrente, distinguendo i due concetti quando è importante.

Per memoria persistente si intendono le informazioni conservate che sopravvivono alla conclusione di una risposta o di una sessione e restano disponibili per un utilizzo successivo. Possono essere una preferenza salvata, una nota di progetto, la registrazione di un evento, un campo strutturato in un database o un punto di controllo che consente di riprendere un’attività incompiuta. La persistenza indica che le informazioni vengono conservate; non garantisce che siano condivise in ogni conversazione.

Di conseguenza, le domande sono due: Le informazioni esistono ancora? e Il modello le riceverà quando ne avrà bisogno? Una trascrizione salvata può rispondere alla prima domanda senza risolvere la seconda.

L’eccezione importante: lo stato a breve termine può essere salvato

«Breve termine» non significa sempre «conservato solo nella RAM volatile». Lo stato di lavoro di una conversazione può essere salvato in un punto di controllo su un database e ripristinato dopo un’interruzione. Per esempio, la documentazione sulla memoria di LangChain distingue lo stato circoscritto a un thread, conservato tramite punti di controllo, dalla memoria a più lungo termine, organizzata in spazi dei nomi separati.

Immagina un addetto all’assistenza che si ferma in attesa che un cliente carichi una ricevuta. Il punto di controllo salvato appartiene a quella richiesta di assistenza. È permanente, ma non dovrebbe diventare automaticamente un’informazione generale sul cliente né comparire in richieste non correlate.

Un modo utile per valutare qualsiasi funzionalità di memoria consiste nel considerare tre dimensioni: la sua durata, il suo ambito e la sua disponibilità per la chiamata corrente al modello. Un’etichetta come «lungo termine» non risponde in modo completo a nessuna di queste domande.

Memoria attiva e memoria persistente a colpo d’occhio

Lo stesso dato può comparire in entrambe le colonne. Una preferenza di progetto salvata è persistente; la copia inserita nel prompt di oggi è attiva. Rimuovere quella copia dal prompt non comporta necessariamente la rimozione dell’originale salvato.

Che cosa accade durante una singola risposta dell’IA?

In una tipica applicazione basata su un modello linguistico, il software che la circonda assembla un input, il modello genera un output e il software decide che cosa fare dopo. L’input può contenere la conversazione visibile, ma anche istruzioni di sistema, descrizioni degli strumenti, note recuperate e informazioni che l’utente non vede nella trascrizione della chat.

Il contesto così assemblato costituisce le evidenze a disposizione immediata del modello. Se un messaggio precedente non è più incluso, il modello non può recuperarne con sicurezza il contenuto esatto solo perché l’applicazione lo aveva mostrato in precedenza. Potrebbe dedurre una risposta plausibile dagli indizi circostanti, ma dedurre è diverso dal ricordare.

Uno strumento estende ciò a cui il sistema può accedere. Il modello potrebbe richiedere un file di progetto, riceverne il contenuto e usarlo in una risposta successiva. Il file era a disposizione dell’applicazione prima di diventare un’evidenza attiva. Questa distinzione spiega perché un agente possa accedere a un archivio di grandi dimensioni senza leggerlo tutto a ogni turno.

Al loro interno, anche le implementazioni dei transformer mantengono uno stato computazionale, comprese cache usate per evitare di ripetere operazioni. Questi meccanismi sono utili per rendere efficiente l’inferenza, ma non vanno confusi con un registro modificabile, consapevole delle autorizzazioni, delle preferenze di un utente o della cronologia di un progetto. Una risposta più rapida non dimostra che sia stata creata una memoria personale.

Perché una finestra di contesto più ampia non risolve il problema della memoria

Una finestra di contesto più ampia consente all’applicazione di fornire più materiale in una volta sola. Può essere utile quando la risposta dipende dai rapporti tra elementi distribuiti in un lungo documento o in diverse fonti correlate. Non determina quali materiali meritino di essere conservati, quale versione sia quella autorevole o se un utente possa accedervi.

Inoltre, inserire informazioni in una finestra di contesto non garantisce che il modello le utilizzi correttamente. Lo studio Persi nel mezzo ha mostrato che i modelli esaminati potevano ottenere risultati diversi a seconda della posizione delle evidenze pertinenti nei prompt lunghi. Il risultato invita a valutare l’efficacia dell’uso del contesto, anziché considerare la capacità dichiarata una garanzia di ricordo; non è una previsione fissa delle prestazioni di ogni modello più recente.

Supponiamo che un archivio di progetto contenga quaranta discussioni sulla data di lancio. Trent nove riportano la data originale, mentre l’ultima modifica approvata la sposta. Fornire tutte e quaranta le discussioni crea un problema di lettura e di individuazione della fonte autorevole. Un registro dello stato attuale, mantenuto con cura e collegato alla modifica approvata, può rendere più facile stabilire la risposta pertinente.

Il contesto lungo e il recupero selettivo possono quindi integrarsi a vicenda. Il recupero individua un insieme utile di evidenze; un contesto sufficientemente ampio consente al modello di esaminarle nel loro insieme. La scelta progettuale dipende dall’attività, dalle dimensioni del materiale di partenza e dalle conseguenze di un’eventuale omissione di una precisazione.

Come le informazioni diventano memoria persistente

Una memoria duratura nasce da una decisione di scrittura. Un’applicazione può salvare un’istruzione esplicita dell’utente, ricavare un possibile dato da una conversazione, conservare un evento o creare un riepilogo. Ciascuna modalità produce un tipo diverso di evidenza.

«Per il Progetto Cedar, usa il sistema metrico» è una preferenza esplicita relativa al progetto. «L’utente sembra preferire il sistema metrico» è un’inferenza. «Gli ultimi tre rapporti di Cedar usavano il sistema metrico» è un’osservazione. Un registro utile conserva queste differenze, invece di appiattirle in un’affermazione senza qualificazioni valida per ogni attività futura.

Che cosa contiene un registro utile

Per un ipotetico assistente di progetto, una scheda potrebbe contenere l’affermazione, l’identificativo del progetto, l’utente o l’organizzazione a cui si riferisce, l’interazione da cui proviene, un timestamp, uno stato di validità e le eventuali eccezioni. Questi campi permettono di chiedersi da dove provenga l’informazione e se sia ancora valida.

{
  "scope": "project:cedar",
  "statement": "Use metric units in project reports",
  "source_type": "explicit_user_instruction",
  "source_ref": "conversation_17/message_8",
  "status": "current",
  "exception": "Client edition may require dual units"
}

Si tratta di uno schema esemplificativo, non di uno standard universale. Serve a mostrare perché una memoria dovrebbe contenere più di una semplice frase. Un riferimento alla fonte facilita la verifica; l’ambito evita generalizzazioni eccessive; un campo di stato permette di apportare correzioni.

Scritture immediate e elaborazione in background

Una scrittura immediata può rendere disponibile una correzione esplicita già per la richiesta successiva. L’elaborazione in background può esaminare un’interazione conclusa, accorpare i duplicati o produrre un riepilogo più ponderato. La documentazione di LangChain descrive entrambi gli approcci e i relativi compromessi, compreso il lavoro aggiuntivo che comportano nel flusso di risposta immediata.

Una progettazione pratica potrebbe salvare subito una preferenza confermata ed elaborare in un secondo momento una lunga sessione di ricerca. Deve comunque gestire l’intervallo tra queste due fasi. Se il sistema comunica all’utente di aver salvato una preferenza prima che la scrittura vada a buon fine, la conversazione successiva potrebbe rivelare un’interruzione della continuità.

Le scritture in memoria richiedono anche una gestione degli errori. Se l’archiviazione è temporaneamente indisponibile, l’applicazione può segnalare che il salvataggio non è stato completato oppure mantenere un’operazione in sospeso, contrassegnandola chiaramente. Considerare riuscita una scrittura solo tentata crea un’esperienza fuorviante per l’utente.

Come la memoria persistente rientra nel contesto attivo

Il recupero consiste in una serie di decisioni relative all’ammissibilità, alla pertinenza e alle prove disponibili. Per prima cosa, il sistema deve identificare l’utente, il tenant, il progetto o l’attività di cui può consultare le schede. In seguito individua le schede candidate e seleziona quali includere nel contesto della risposta.

Il metodo di recupero dovrebbe essere adeguato alla domanda. «Qual è la scadenza approvata per Cedar?» potrebbe trovare la risposta migliore consultando direttamente il campo corrispondente del progetto. «Ci è già capitato questo errore di distribuzione?» potrebbe invece trarre vantaggio da una ricerca per parole chiave e dalla somiglianza semantica tra gli incidenti passati. Un database vettoriale è una delle possibili soluzioni in questo processo, non un requisito per ogni tipo di memoria.

La ricerca semantica è particolarmente utile quando cambia la formulazione. Una richiesta come «mantenere concisi i rapporti» potrebbe trovare corrispondenza con una preferenza registrata per «brevi riepiloghi dirigenziali». Tuttavia, un’affermazione correlata potrebbe riguardare un altro cliente o una versione del progetto abbandonata. La somiglianza individua possibili corrispondenze, ma non ne dimostra la veridicità né autorizza a usarle.

Il recupero deve prevedere un esito «nessun risultato»

Consideriamo la domanda: «Quale limite di spesa ho approvato il mese scorso?». Se non è possibile trovare alcun importo approvato, una risposta utile segnala la mancanza di prove e chiede un chiarimento. Fornire una cifra plausibile trasforma l’assenza di una memoria in un’autorizzazione inventata.

L’interfaccia di memoria dovrebbe quindi distinguere tra una corrispondenza confermata, una incerta, un conflitto e l’assenza di informazioni a supporto. Questi esiti possono portare a comportamenti diversi: rispondere direttamente, formulare la risposta con cautela, chiedere chiarimenti oppure rifiutarsi di agire sulla base di un presupposto non supportato.

Anche dopo il recupero, l’interpretazione resta importante. Un record che riporta «budget massimo proposto: 5.000 $, in attesa di approvazione» non deve diventare «budget approvato: 5.000 $». Conservare le precisazioni nella rappresentazione archiviata e nel contesto fornito è importante quanto trovare il documento corretto.

Un esempio pratico: ricordare un progetto nel tempo

Immaginiamo un assistente che aiuta un team a realizzare il rapporto di ricerca Cedar. L’esempio che segue è ipotetico, ma mette in luce alcune scelte comuni nella progettazione della memoria.

Sessione uno: definire il progetto

L’utente chiede un rapporto, specifica di usare le unità metriche, fornisce tre fonti e dice che la bozza deve essere pronta entro venerdì. Il contesto attivo comprende queste istruzioni e gli estratti delle fonti. Lo stato dell’attività registra quali sezioni sono state completate e quali affermazioni devono ancora essere verificate.

I potenziali record persistenti hanno funzioni diverse. La preferenza per le unità metriche riguarda il progetto. La scadenza della bozza riguarda la tappa attuale. Le fonti fornite vanno archiviate tra i materiali probatori del progetto. Le affermazioni non verificate vanno inserite in un elenco delle ricerche da completare, conservando l’incertezza che le riguarda.

Sessione due: riprendere con le fonti giuste

Tre giorni dopo, l’utente chiede di completare la sezione sui metodi. L’assistente ha bisogno della versione più recente della scaletta, delle fonti pertinenti, dello stato attuale dell’attività e della regola di formattazione applicabile. Non ha necessariamente bisogno di ogni frase scartata durante la precedente sessione di brainstorming.

Se il punto di controllo indica che la revisione della letteratura è completa, prima di apportare modifiche alle altre parti l’assistente dovrebbe comunque aprire il documento salvato. «Completata» è un’affermazione sullo stato di avanzamento; il documento effettivo costituisce la prova di ciò che è stato completato. Riferimenti persistenti ai documenti possono essere più utili di un riepilogo che cerca di riprodurne per intero il contenuto.

Sessione tre: applicare un’eccezione senza riscrivere tutto

L’utente chiede un’edizione per i clienti che riporti sia le unità metriche sia quelle imperiali. L’attività corrente deve quindi usare entrambe le unità. La modifica della regola generale del progetto dipende da come è formulata la richiesta e dal suo ambito: «per questa edizione» è più circoscritto di «da ora in poi, usa entrambe le unità».

Un assistente scrupoloso registra un’eccezione specifica per quell’edizione. Un assistente che generalizza eccessivamente riscrive la preferenza globale e introduce errori nei rapporti successivi. È un errore di memoria anche se tutte le operazioni di scrittura nel database e tutte le richieste di recupero vanno a buon fine.

Sessione quattro: concludere e archiviare lo stato temporaneo

Dopo la consegna, la tappa dovrebbe essere contrassegnata come completata. Se l’utente chiede di «continuare il rapporto», l’assistente dovrebbe ripartire dalla versione consegnata e chiedere quale revisione occorre, invece di riprendere una lista di controllo ormai superata. Gli appunti temporanei possono scadere secondo le regole del progetto, mentre il rapporto finale e le decisioni importanti restano disponibili.

Qui si vede il valore della memoria persistente: meno spiegazioni ripetute e maggiore continuità. Se ne vede anche il costo: l’applicazione deve mantenere i legami tra preferenze, eccezioni, documenti e stato mutevole delle attività.

Riepilogo, compattazione e rischio di perdere l’eccezione

Le interazioni prolungate possono accumulare più materiale di quanto sia utile per la risposta successiva. La compattazione sostituisce parte della cronologia con una rappresentazione più breve. Un riepilogo può conservare l’obiettivo, le decisioni, le questioni irrisolte e i riferimenti al lavoro svolto.

Le indicazioni di Anthropic sull’ingegneria del contesto descrivono la compattazione e le note archiviate al di fuori della finestra di contesto come approcci per mantenere la continuità durante attività prolungate. Entrambe le tecniche modificano il materiale disponibile per le risposte future, quindi la loro qualità è importante.

La compressione è selettiva. Un riepilogo come «Usare le unità metriche» è più breve di «Usare le unità metriche, tranne nell’edizione per i clienti, che richiede entrambi i sistemi». È anche errato in uno dei casi importanti del progetto. L’eccezione omessa può essere riproposta senza accorgersene nei riepiloghi successivi e diventare difficile da rintracciare.

Per il nostro assistente Cedar, un passaggio di consegne più efficace conserverebbe la regola generale, la relativa eccezione, le sezioni completate, le verifiche ancora da svolgere e i riferimenti ai file più recenti. Dettagli precisi, come gli importi approvati o gli identificativi, dovrebbero restare nei record strutturati o nei documenti di origine, quando un’approssimazione potrebbe essere dannosa.

Anche i riepiloghi dovrebbero conservare l’incertezza. «Abbiamo valutato l’uso del sondaggio B» non deve diventare «È stato scelto il sondaggio B». Se la cronologia compressa fa apparire definitive decisioni provvisorie, il sistema ha creato un falso ricordo nel tentativo di risparmiare spazio nel contesto.

Come dovrebbe gestire l’IA le correzioni e i conflitti nella memoria

La memoria persistente è meno utile se non può essere modificata. I progetti cambiano, le preferenze evolvono e le informazioni precedenti si rivelano errate. Aggiungere una correzione come un’altra voce priva di qualificazioni può lasciare il sistema di recupero a scegliere tra due affermazioni contraddittorie.

Un aggiornamento più utile indica quali informazioni precedenti vengono sostituite dalle nuove prove. Se il responsabile del progetto sposta la data di lancio dal 15 novembre al 29 novembre, la vecchia voce può essere contrassegnata come superata e collegata alla nuova decisione. Per le domande sulla scadenza attuale si usa la nuova versione; per quelle sul piano originario si può consultare la versione storica.

La sola recenza non basta a risolvere ogni conflitto. Una nota recente in una bozza può avere meno valore di una politica approvata in precedenza. Un utente può essere autorizzato a modificare una preferenza personale senza esserlo a modificare una regola valida per tutta l’organizzazione. La politica di aggiornamento deve tenere conto del tipo di fatto e dell’autorità della fonte.

Alcune contraddizioni dovrebbero rimanere irrisolte finché una persona non le chiarisce. Se due responsabili di progetto forniscono date incompatibili senza indicare esplicitamente che una sostituisce l’altra, l’assistente può mostrare entrambe le fonti e chiedere quale debba prevalere. Scegliere senza dirlo la voce più simile o più recente nasconde una decisione che il sistema potrebbe non essere autorizzato a prendere.

Cosa significa che l’IA dimentichi?

Dimenticare non è un semplice interruttore. Un prodotto può smettere di inserire un fatto nei prompt, escluderlo dalle ricerche abituali, contrassegnarlo come non più attuale, eliminare la relativa voce di memoria o rimuovere altre copie conservate. Queste operazioni hanno effetti diversi sul comportamento futuro e sui dati conservati.

Uscire dal contesto attivo

Un fatto può scomparire dal successivo input del modello perché i messaggi più vecchi sono stati omessi o riassunti. Questo riduce le informazioni che il modello può usare nell’immediato. La trascrizione originale o la voce di memoria potrebbero comunque esistere e riemergere con un recupero successivo.

Far scadere o sopprimere il richiamo

Una scadenza passata può rimanere in un archivio pur venendo esclusa dalle ricerche relative al lavoro attuale. La soppressione è utile quando la conservazione a fini storici è necessaria, ma non dovrebbe essere descritta come un’eliminazione completa. Una ricerca storica o una procedura amministrativa potrebbe ancora consentire di accedere alla voce.

Eliminare la memoria archiviata

L’eliminazione di una voce conservata a lungo termine dovrebbe riguardare anche le rappresentazioni di recupero che ne derivano. Se una frase viene rimossa da un profilo ma resta in un riepilogo consultabile tramite ricerca, l’assistente potrebbe ricostruire in seguito la stessa preferenza. A seconda dell’architettura, i record di origine, i vettori di embedding, i riepiloghi, le cache e le repliche possono richiedere interventi di rimozione separati.

Backup e log possono avere calendari di conservazione distinti. Un prodotto dovrebbe spiegare chiaramente questi limiti e impedire che il materiale eliminato torni attivo durante un ripristino. «Non useremo più questa memoria» e «tutte le copie conservate sono state rimosse» sono promesse diverse.

Modificare i pesi del modello

L’eliminazione della memoria esterna non modifica di per sé i parametri del modello. Se un’informazione è stata usata nell’addestramento, intervenire sul modello è un problema distinto, che coinvolge i processi di addestramento e distribuzione. Allo stesso modo, eliminare una memoria personale non garantisce che il modello non generi mai un fatto simile basandosi sulle conoscenze generali o su indizi forniti in un nuovo prompt.

Un test significativo di oblio deve quindi verificare sia se il sistema conserva ancora l’informazione, sia se i normali percorsi di recupero possono reintrodurla. Una singola risposta in chat in cui il sistema dice «Ho dimenticato» non dimostra né l’una né l’altra cosa.

Memoria, RAG, addestramento e memorizzazione nella cache: dove passano i confini

La generazione aumentata dal recupero, o RAG, fornisce prove esterne a un modello durante la generazione. La ricerca originale sul RAG combinava i parametri del modello con un indice di documenti consultabile. Anche un sistema di memoria personale può ricorrere al recupero, ma ha bisogno anche di criteri per creare, aggiornare e archiviare i dati ricavati dalle interazioni.

È possibile recuperare un manuale aziendale senza che costituisca un ricordo relativo all’utente. Una nota su un’interazione precedente può essere recuperata da un semplice file, senza un indice vettoriale. Il recupero è un meccanismo; sono lo scopo e il ciclo di vita dei dati sottostanti a determinare il tipo di sistema che si sta realizzando.

L’addestramento e il perfezionamento modificano i parametri del modello. La memoria esterna ordinaria, invece, modifica le informazioni fornite al modello. Un assistente che segue una preferenza appena salvata può comportarsi in modo diverso anche se i pesi del modello restano invariati.

La memorizzazione nella cache dei prompt e delle inferenze riutilizza i calcoli precedenti, quando supportata. Può migliorare l’efficienza, ma non determina di per sé se un’informazione ricordata sia aggiornata, autorizzata o adatta a compiti futuri. Questi livelli possono coesistere; per risolvere i problemi occorre individuare quale sia responsabile del comportamento osservato.

MemGPT offre un esempio architetturale di rilievo: ha esplorato il trasferimento di informazioni tra un contesto limitato e livelli di memoria esterna, ricorrendo all’analogia con un sistema operativo. L’insegnamento utile è che la circolazione delle informazioni va gestita in modo esplicito, anziché presumere che lo spazio di archiviazione ampli automaticamente e senza limiti il contesto immediato del modello.

Perché la memoria persistente può rendere gli errori più duraturi

Una risposta errata può influire su una singola interazione. Un ricordo errato può influire su molte. Se un assistente deduce che un utente ha approvato una decisione, salva tale deduzione come un fatto e in seguito cita il dato salvato, il suo errore precedente può assumere l’apparenza di una prova indipendente.

Nel nostro assistente di progetto, la fonte originale dovrebbe restare distinguibile dall’interpretazione del modello. Un riepilogo di una decisione può facilitare la consultazione, ma qualsiasi azione con conseguenze rilevanti dovrebbe basarsi sulla decisione effettivamente approvata. La ripetizione di un’inferenza non suffragata in più note generate non la trasforma in più conferme indipendenti.

La memoria persistente crea anche un possibile canale di contaminazione delle istruzioni. Un documento non attendibile potrebbe contenere una frase che ordina all’assistente di modificare il proprio comportamento futuro. Memorizzare quella frase come regola operativa significherebbe far oltrepassare a un contenuto esterno un confine di autorità. L’applicazione dovrebbe trattarlo in base alla fonte, anziché promuoverlo a istruzione attendibile solo perché compare in un archivio di memoria.

Gli ambienti condivisi introducono un ulteriore confine. Un’informazione può essere pertinente a una domanda, ma riguardare un altro cliente o progetto. I controlli di accesso dovrebbero limitare il recupero prima che le informazioni raggiungano il modello. Chiedere al modello di ignorare i dati non autorizzati dopo averglieli già forniti è una soluzione meno solida.

Come valutare se la memoria funziona davvero

Una dimostrazione convincente spesso chiede all’assistente di ripetere una preferenza salvata. Una valutazione rigorosa segue informazioni soggette a cambiamento attraverso più sessioni e verifica se la memoria migliora il risultato del compito.

LongMemEval valuta l’estrazione di informazioni, il ragionamento tra sessioni, il ragionamento temporale, gli aggiornamenti delle conoscenze e l’astensione. Queste categorie mostrano perché la qualità della memoria a lungo termine va oltre il recupero di una singola frase corrispondente. I risultati pubblicati dei benchmark vanno interpretati in relazione ai sistemi e alle configurazioni testati, anziché considerarli rappresentativi di ogni prodotto attualmente disponibile.

Per il flusso di lavoro Cedar, una valutazione potrebbe introdurre una preferenza, riprendere il progetto, aggiungere un’eccezione, modificare una scadenza, eliminare una nota e poi porre domande pensate per far emergere ricordi obsoleti o non suffragati. Andrebbe testato anche lo stesso modello senza la funzione di memoria, per stabilire se il sistema aggiuntivo migliori i risultati.

• Accuratezza della scrittura: il sistema ha salvato l’affermazione prevista, mantenendone l’ambito e le precisazioni?
• Utilità del recupero: ha trovato le informazioni necessarie per il compito senza riempire il contesto di cronologia irrilevante?
• Gestione degli aggiornamenti: una correzione ha sostituito l’informazione attuale preservando le distinzioni storiche utili?
• Astensione: l’assistente ha riconosciuto quando non esisteva alcun dato a sostegno?
• Isolamento: i dati sono rimasti circoscritti all’utente, al tenant e al progetto corretti?
• Oblio: l’eliminazione o la scadenza hanno impedito il recupero futuro previsto, anche tramite riepiloghi derivati?
• Costo operativo: i miglioramenti giustificavano la latenza, le chiamate al modello, lo spazio di archiviazione e la manutenzione aggiuntivi?

I malfunzionamenti vanno ricondotti alla fase in cui si verificano. Una risposta mancante può dipendere da una scrittura non riuscita, da un ambito di ricerca errato, da una decisione di posizionamento inadeguata, da una precisazione omessa o da un modello che ha interpretato male prove valide. Aumentare la dimensione del contesto non risolverà tutti questi problemi.

Scegliere la giusta progettazione della memoria

Un riepilogo occasionale di un documento può richiedere soltanto il documento corrente e le istruzioni. Un punto di controllo dell’attività è utile quando un’analisi viene interrotta. Un assistente per un progetto ricorrente può aver bisogno di decisioni con versioni e riferimenti agli artefatti. Un assistente che opera in molte sessioni utente può aver bisogno di un archivio delle preferenze separato e modificabile.

Per cominciare, specifica a quale domanda futura dovrà rispondere la memoria. «Che cosa resta da fare?» richiede lo stato dell’attività. «Quale formato richiede questo cliente?» richiede una preferenza circoscritta. «Perché abbiamo rifiutato questo approccio?» richiede una registrazione della decisione con le prove a sostegno. A domande diverse corrispondono rappresentazioni diverse.

Meglio pochi record chiari e riconducibili a una fonte che un archivio indiscriminato presentato come personalizzazione. Tieni separato lo stato corrente dagli eventi passati, conserva i collegamenti agli artefatti di origine e considera le correzioni e la cancellazione parte integrante della progettazione fin dall’inizio.

La memoria attiva offre a un sistema di IA un presente coerente. La memoria persistente può garantirgli continuità nel tempo. La qualità di questa continuità dipende dalle decisioni che intercorrono tra le due: che cosa viene salvato, che cosa viene recuperato, quale versione prevale e che cosa può essere eliminato.