Sintesi Tecnica: Engram – Un Motore di Memoria Bi-Temporale per Agenti LLM

1. Definizione del Problema

La memoria a lungo termine rimane una lacuna critica per gli agenti LLM, che sono intrinsecamente stateless tra le sessioni. Il metodo di fortuna prevalente — la concatenazione dell'intera cronologia della conversazione nel prompt — soffre di tre problemi cumulativi:

1. Costo e Latenza: I costi dei token e la latenza di inferenza crescono linearmente con la lunghezza della cronologia.
2. Degradazione dell'Accuratezza: Man mano che si accumulano turni irrilevanti ("distrattori"), il modello fatica a individuare l'evidenza pertinente, un fenomeno noto come "lost in the middle" (perso nel mezzo).
3. Crisi della Riproducibilità: I benchmark di memoria esistenti soffrono di harness di valutazione inconsistenti (metodi di ingestione, prompt di risposta e giudici variabili), portando a report sulle prestazioni contraddittori dove lo stesso sistema produce punteggi vastamente diversi tra diverse fonti.

Gli attuali sistemi di memoria spesso ottimizzano per costo o velocità, ma non riescono a superare l'accuratezza del baseline a contesto completo. Il paper postula che una fetta di contesto precisamente recuperata e snella non dovrebbe solo essere più economica, ma anche più accurata rispetto alla finestra completa e rumorosa.

2. Metodologia: Il Sistema Engram

Engram è un motore di memoria dual-process open-source costruito su un modello di dati bi-temporale. Separa le operazioni di memoria in un percorso di scrittura rapido e un percorso di consolidamento asincrono, alimentando un percorso di lettura ibrido.

2.1 Modello di Dati Bi-Temporale

Il sistema tratta il tempo come un cittadino di prima classe utilizzando due assi:

• Tempo dell'Evento (Valid Time): Quando un fatto era vero nel mondo.
• Tempo della Transazione (Transaction Time): Quando il sistema ha appreso o ritrattato il fatto.
• Strutture Dati:
  • Episodi: Turni/eventi lossless (senza perdita) con timestamp su entrambi gli assi temporali.
  • Fatti: Claim atomici (Soggetto, Predicato, Oggetto) con testo superficiale, punteggi di salienza e provenienza. I fatti portano i timestamp valid_at/invalid_at e created_at/expired_at.
  • Grafo: Entità e relazioni con archi bi-temporali.
• Invariante: I fatti non vengono mai eliminati in modo definitivo. I fatti contraddetti vengono invalidati (contrassegnati come invalid_at) e sostituiti da nuovi fatti, preservando una traccia di audit e provenienza completa.

2.2 Architettura Dual-Process

• Sistema-1 (Percorso di Scrittura Hot):
  • Operazione: Appende episodi lossless, risolve l'identità attraverso le sessioni, calcola embedding leggeri e mette in coda per il consolidamento.
  • Vincolo: Nessuna chiamata LLM sul percorso critico; la latenza è mantenuta sotto i 50ms.
• Sistema-2 (Consolidamento Async):
  • Operazione: Estrae fatti atomici (basati su regole o LLM), costruisce il grafo della conoscenza bi-temporale, rileva conflitti e invalida i fatti superati.
  • Risoluzione dei Conflitti: Utilizza una politica "economica-poi-escalation". Corrispondenze esatte di slot o chiari contrasti temporali vengono risolti senza chiamate LLM. I casi ambigui vengono scalati a un giudice LLM.
  • Salienza: Applica punteggi di decadimento/rinforzo per far svanire le memorie non rinforzate.
• Percorso di Lettura Ibrido:
  • Recupero (Retrieval): Scompone le query e le recupera tramite quattro canali paralleli: semantico denso (embedding BGE), lessicale (BM25), attraversamento del grafo (n-hop) e recenza/salienza.
  • Fusione: Combina le liste classificate usando la Reciprocal Rank Fusion (RRF) e l'opzionale reranking tramite cross-encoder.
  • Filtraggio: Applica un filtro bi-temporale "as-of" (recuperando fatti validi in un punto specifico nel tempo) e un gate di astensione (rifiutando di rispondere se l'evidenza è assente).
  • Assemblaggio del Contesto: Costruisce un contesto compatto contenente fatti risolti dai conflitti, chunk di sessioni grezzi rilevanti e riassunti di sessione.

2.3 Harness di Valutazione Riproducibile

Gli autori contribuiscono con un harness di valutazione neutro e in-repo, progettato per eliminare i problemi di integritità della misurazione:

• Giudice Ufficiale: Utilizza i prompt del giudice specifici per categoria di LongMemEvalS, evitando giudici artigianali.
• Baseline a Contesto Completo: Include il baseline della cronologia completa in ogni confronto.
• Correzioni di Integrità: Corregge problemi come la troncatura del contesto completo (assicurando che il baseline veda tutto il "pagliaio") e la "preposizione di fatti alla cronologia completa" (assicurando che il test misuri il recupero, non solo l'aumento della memoria).
• Determinismo: Esegue test con fallback offline a zero dipendenze; i log grezzi per ogni domanda sono pubblicati per ogni metrica.

3. Contributi Chiave

1. Motore Dual-Process: Un sistema di memoria con risoluzione dei conflitti non distruttiva (invalida vs sovrascrittura) che risolve la maggior parte dei conflitti senza chiamate LLM.
2. Guadagno di Accuratezza Empirica: Dimostrazione che un contesto snello e recuperato (9.6k token) supera in accuratezza il baseline a contesto completo (79k token).
3. Harness Neutrale: Una pipeline di valutazione riproducibile con giudici ufficiali integrati, baseline a contesto completo e log grezzi pubblicati per affrontare la crisi di riproducibilità del settore.
4. Insight sul Percorso di Lettura Ibrido: Identificazione del fatto che un percorso di recupero "solo fatti" perde richiamo (recall); combinare i fatti risolti dai conflitti con i chunk di sessione grezzi è necessario per recuperare i dettagli.

4. Risultati

Valutato sul benchmark LongMemEvalS (500 domande attraverso 7 categorie) utilizzando il giudice ufficiale:

• Accuratezza Complessiva: La configurazione snella di Engram ha raggiunto un'accuratezza dell'83.6%, rispetto al 73.2% del baseline a contesto completo (+10.4 punti).
• Efficienza: La configurazione snella ha utilizzato ~8× meno token (9.6k vs 79k) mantenendo un'accuratezza superiore.
• Significatività Statistica: Il guadagno è decisivo dal punto di vista statistico (test esatto McNemar, $p < 10^{-6}$). Engram è stato corretto su 81 domande che il baseline ha mancato, contro 29 in cui è avvenuto il contrario.
• Tasso di Errore: 0 errori su 500 domande per entrambi i sistemi (nessun fallimento del sistema).
• Performance per Categoria:
  • Knowledge-Update: 87.5% (beneficia di invalidazione/sovrascrittura).
  • Ragionamento Temporale: 81.1% (beneficia del filtraggio "as-of").
  • Astensione: 86.7% (il sistema declina correttamente quando la memoria manca di risposte).
  • Aggregazione Multi-sessione e Preferenza: Punteggi più bassi (79.3% e 73.3%), identificati come aree con margine di miglioramento.
• Osservazione dall'Ablazione: Una variante che prepponeva i fatti alla cronologia completa (engram_full) ha ottenuto l'83.4%, simile alla versione snella. Ciò suggerisce che i fatti strutturati guidano il guadagno di accuratezza, mentre la cronologia completa aggiunge token senza migliorare la correttezza.

5. Significato e Rivendicazioni

Il paper rivendica due contributi primari:

1. Miglioramento della Qualità rispetto all'Ottimizzazione dei Costi: Engram dimostra che la memoria a lungo termine può essere un meccanismo di miglioramento della qualità, non solo di risparmio sui costi. Filtrando i distrattori, una fetta recuperata snella è più accurata del contesto completo.
2. Integrità della Misurazione: Il paper sostiene che i numeri dei benchmark del settore sono spesso contestati a causa di harness inconsistenti. Fornendo un harness neutro e riproducibile con il giudice ufficiale e il baseline a contesto completo, gli autori affermano che il "punteggio affidabile" è prezioso quanto il sistema stesso.

Gli autori rimangono modesti riguardo ai limiti, notando che i risultati si basano su un singolo benchmark e un singolo backbone di risposta. Identificano l'aggregazione multi-sessione e la gestione delle preferenze come sfide aperte e invitano a futuri lavori che coinvolgano molteplici backbone e ablazioni controllate dei componenti. Il sistema è progettato per essere auto-ospitabile con fallback offline, garantendo la privacy dei dati e la riproducibilità senza dipendenze da API esterne.