LycheeMemory V2: la memoria dell’agente si scrive quando cambia argomento, non a ogni battuta

Chi ha tenuto il verbale di una riunione lo sa: non si scrive una riga dopo ogni battuta. Si ascolta finché un punto dell’ordine del giorno è chiuso, e allora si annota che cosa è stato deciso, da chi, per quando. Scrivere a ogni intervento vorrebbe dire correggere continuamente, lasciare frasi a metà, riempire pagine di «come dicevo prima». Scrivere solo alla fine della riunione vorrebbe dire dimenticare i dettagli. Il buon verbalista chiude il punto quando il discorso cambia argomento.

È l’idea di LycheeMemory V2: Efficient Long-Term Memory for LLM Agents via Semantic Segment-Level Consolidation, uscito su arXiv il 13 agosto 2026 (2608.12990) e firmato da otto ricercatori dell’Harbin Institute of Technology di Shenzhen, con Dongfang Li e Zixuan Liu primi autori a pari merito e Baotian Hu come autore di riferimento. Il bersaglio non è l’accuratezza in sé, ma un costo che nei sistemi di memoria per agenti si vede poco finché la conversazione non diventa lunga: quello di scrivere la memoria.

Il costo nascosto del ricordare tutto subito

Un agente che deve fare da assistente per settimane non può tenere tutta la storia nella finestra di contesto. Per questo sistemi come Mem0, A-Mem o MemoryOS affiancano al modello una memoria esterna: dopo ogni scambio, un modello linguistico legge la battuta, estrae i fatti, aggiorna le note esistenti, crea collegamenti. Gli autori chiamano questo schema consolidamento anticipato, e il suo difetto è aritmetico: ogni scambio costa una chiamata, e la spesa cresce con la conversazione.

Le due vie di fuga note hanno il loro prezzo. Riassumere in modo grossolano costa meno ma perde proprio i dettagli su cui spesso cadono le domande: un nome, una data relativa, a chi si riferiva un pronome. Recuperare di più al momento della domanda, allargando i risultati o facendo ragionare il modello in più passaggi, sposta semplicemente il conto dalla scrittura alla lettura.

Aspettare che l’argomento si chiuda

LycheeMemory tiene in un buffer gli scambi in arrivo e chiama il modello solo quando un segmento è finito. Decidere dove finisce non costa nessuna chiamata generativa: ogni scambio viene trasformato in un vettore di embedding e confrontato con il centroide del segmento aperto, $c_k$, e con lo scambio immediatamente precedente, $h_k$. La sorpresa semantica è

$$s_t = 1 – \max\big(\mathrm{sim}(e_t, c_k),\ \mathrm{sim}(e_t, h_k)\big),$$

alta solo se il nuovo scambio si allontana sia dal tema generale sia dal filo locale del discorso. A questa si aggiunge il calo di coesione che il nuovo scambio provocherebbe nel segmento, più due spinte di lunghezza, una sui token e una sul numero di scambi. Il tutto finisce in una sigmoide:

$$p_t = \sigma\big(b + w_s\,\phi(s_t) + w_c\,d_t + w_l\,L_t + w_n\,N_t\big),$$

e il segmento si chiude quando $p_t$ supera 0,5 o quando si raggiunge un tetto rigido. Nella configurazione di default il segmento punta a 600 token, sotto i 300 la spinta di lunghezza scoraggia il taglio, a 900 token o a dieci scambi la chiusura è obbligata. Su LoCoMo la media risulta di 5,8 battute per segmento: le chiamate al modello diventano una per segmento invece di una per battuta.

Schede che si leggono da sole

Quando il segmento si chiude, una sola chiamata al modello fa tre cose insieme: spezza il testo in unità d’informazione atomiche, risolve pronomi ed ellissi, trasforma le date relative («la settimana scorsa») in date assolute usando il timestamp della sessione. Il risultato è un insieme di schede autosufficienti, ognuna con un tipo scelto da un elenco chiuso (fatti, preferenze, eventi, vincoli, procedure, schemi di fallimento, capacità degli strumenti), le entità nominate, gli argomenti, l’eventuale riferimento temporale e il collegamento alle battute originali.

Il rischio di scrivere più di rado è perdere il filo fra un segmento e l’altro: chi è «lei» nel segmento successivo? Per questo l’encoder restituisce anche uno stato di disambiguazione, con alias e nomi canonici, che viene passato al segmento dopo insieme a un sunto delle schede più recenti, entro un budget fisso che non cresce con la storia.

Le schede finiscono in un archivio a sola aggiunta, con un indice vettoriale e cinque indici strutturati costruiti dai metadati già estratti, senza altre chiamate al modello: per entità, per argomento, per coppia entità-argomento, per data e per «cornice d’evento», cioè il segmento da cui la scheda viene. Le battute originali restano comunque indicizzate.

Al momento della domanda, prima di scrivere la risposta, il modello interviene una volta sola: un pianificatore legge la domanda e la scompone in più percorsi di ricerca, ciascuno con il suo obiettivo e i suoi vincoli, per esempio temporali. Da lì non ci sono altre chiamate generative: ricerca sulle schede, sui nodi strutturati, sulle date e sulle battute grezze, riordino con un cross-encoder dentro ogni percorso, fusione delle liste con la reciprocal-rank fusion, selezione che preserva la varietà dei percorsi. In caso di contraddizione, il modello che risponde è istruito a preferire l’informazione più recente.

I numeri

La valutazione usa due benchmark di conversazioni lunghe. LoCoMo ha dieci conversazioni da circa 600 battute e 16 mila token ciascuna e 1.986 domande, di cui gli autori tengono 1.540, escluse quelle avversariali; LongMemEval-S ha 500 storie da circa 115 mila token, con una domanda ciascuna. Il modello è GPT-4.1-Mini o GPT-4o-Mini per tutto, dalla scrittura della memoria alla risposta, e un giudice GPT-4o-Mini valuta le risposte. I conti dei token sono fatti con GPT-4.1-Mini.

Con GPT-4.1-Mini LycheeMemory è primo su entrambi i benchmark. Il miglior concorrente su LoCoMo è il contesto completo, cioè dare al modello l’intera storia; su LongMemEval-S è TiMem, mentre il contesto completo scende sulle storie più lunghe. A-Mem, il riferimento principale del confronto sui costi, resta più indietro. Con GPT-4o-Mini i margini si stringono molto: 78,90 e 78,80%, appena 2,47 e 1,00 punti sopra il migliore degli altri.

I costi sono il cuore del paper. Su LoCoMo la costruzione della memoria consuma 204,1 mila token per conversazione; A-Mem ne consuma 1.459,9 mila, Mem0 1.520,8 mila. Rispetto ad A-Mem è l’86% in meno. Su LongMemEval-S 304,7 mila contro 1.264,3 mila, il 75,9% in meno. E il risparmio non viene spostato alla lettura: per domanda servono 4,01 mila token contro 5,56 mila di A-Mem su LoCoMo, 8,88 mila contro 15,46 mila su LongMemEval-S. Mem0 spende ancora meno in lettura, ma è anche il sistema di memoria dedicato meno accurato su LoCoMo.

Gli esperimenti di ablazione, tutti su LoCoMo, sono la parte più istruttiva perché separano le due leve. Tornare a una chiamata per scambio fa scendere l’accuratezza e salire i token di costruzione. Tenere i segmenti ma tagliarli a finestre fisse costa addirittura meno, ma perde precisione, soprattutto sulle domande multi-hop e su quelle aperte. La lettura degli autori: il risparmio viene dal raggruppare, la precisione dal tagliare nel punto giusto. Sostituire le schede tipizzate con riassunti dimezza il costo e abbassa l’accuratezza, e lo stesso fa togliere il contesto fra segmenti. Il pezzo più delicato è la selezione finale: senza fusione, riordino e diversità si crolla. La soglia di taglio, invece, conta poco: fra 0,3 e 0,7 l’accuratezza oscilla di circa un punto.

Che cosa resta da verificare

Il conto dei token non è il conto completo. Sono esclusi per scelta dichiarata gli embedding, calcolati per ogni scambio, il cross-encoder e l’indicizzazione. È una scelta difendibile, perché di norma costano molto meno di una chiamata generativa, ma la latenza, la crescita dell’archivio e il costo di tenere indicizzate anche le battute grezze non sono misurati, come ammettono gli autori stessi.

Il segmento è in parte una questione di lunghezza. Dall’appendice si ricava che i segnali di lunghezza entrano nel punteggio di taglio su una scala paragonabile a quella dei segnali semantici, e che un segmento non può superare i 900 token. Che le finestre fisse, tarate sullo stesso obiettivo di 600 token, perdano quasi sette punti dice che il criterio semantico conta. Ma le finestre fisse consumano meno token di costruzione, segno probabile di segmenti in media più lunghi, e il paper non separa quanto della differenza venga dalla dimensione dei segmenti e quanto dal punto in cui si taglia.

Le preferenze restano un punto debole. Su LongMemEval-S MemoryOS arriva al 100% sulle domande di preferenza contro il 90% di LycheeMemory con GPT-4.1-Mini, e con GPT-4o-Mini MemOS è al 96,67% contro il 70%. Sono 30 domande in tutto: il distacco vale tre risposte con GPT-4.1-Mini, otto con GPT-4o-Mini. Gli autori ne deducono che un modulo dedicato al profilo dell’utente potrebbe dare un vantaggio su questo tipo di domande.

Il perimetro è stretto. Solo testo, solo due benchmark di domande e risposte, modelli generativi ed embedding presi da un unico fornitore a pagamento, con un giudice della stessa famiglia dei modelli valutati. Sostituirli con modelli aperti è possibile, scrivono gli autori, ma accuratezza e costi andrebbero rimisurati. Il paper non indica un repository: la sezione sul rilascio descrive come dovrebbe essere fatto, non dove trovarlo. E il «V2» del titolo non trova, nel testo, una versione precedente con cui confrontarsi.

Perché conta adesso

Per un agente che accompagna un utente per settimane, la memoria è una voce di spesa che si nota tardi: con il consolidamento anticipato ogni battuta fa partire, in silenzio, un’altra chiamata. LycheeMemory non inventa i segmenti, che altri sistemi usavano già, ma li usa per un obiettivo preciso e lo misura: scrivere meno spesso, senza perdere i dettagli e senza spostare la spesa sulla lettura. La conclusione più utile è quella generale che gli autori stessi propongono: il compromesso fra accuratezza e costo di una memoria non dipende solo da che cosa si conserva, ma anche dalla granularità con cui lo si consolida, cioè da quando lo si scrive. Come per il verbalista, il momento giusto è quando il discorso cambia.