L'affermazione virale: l'archiviazione verbatim grezza batte tutto per la memoria dell'IA. Abbiamo riprodotto il benchmark e trovato una risposta diversa. Il collo di bottiglia è il troncamento degli embedding, non la perdita in fase di estrazione. Ecco i dati.
Perché abbiamo eseguito questo benchmark
MemPalace (github.com/milla-jovovich/mempalace) è stato lanciato il 5 aprile 2026 e ha raggiunto 14.500 stelle su GitHub in 48 ore. La tesi centrale: archivia ogni conversazione verbatim in ChromaDB, salta del tutto l'estrazione tramite LLM e ottieni un recall del 96,6% sul benchmark standard per la memoria dell'IA (LongMemEval).
L'implicazione per il settore: ogni sistema che usa un LLM per estrarre o riassumere ricordi sta sovra-ingegnerizzando il problema. Il testo grezzo con buoni embedding vince.
Costruiamo sistemi di gestione della conoscenza basati sul modello SECI (Nonaka & Takeuchi, 1995), dove l'estrazione strutturata è un'operazione centrale. Se l'archiviazione grezza batte davvero l'estrazione, la nostra architettura è sbagliata. Quindi l'abbiamo testata.
Cosa abbiamo testato
Benchmark: LongMemEval_S (Wu et al., ICLR 2025). 500 domande che verificano cinque capacità di memoria a lungo termine: estrazione di informazioni, ragionamento multi-sessione, aggiornamenti della conoscenza, ragionamento temporale e astensione. Ogni domanda include circa 48 sessioni di conversazione "haystack", di cui da 1 a 3 contengono la risposta.
Quattro approcci di retrieval, stesso modello di embedding (all-MiniLM-L6-v2), stessi dati:
| # | Approccio | Descrizione |
|---|---|---|
| 1 | Grezzo, tutti i turni | Archivia il testo completo della sessione (utente + assistente), lo incorpora così com'è |
| 2 | Grezzo, solo utente | Il metodo di MemPalace: archivia solo i turni dell'utente, li incorpora così com'è |
| 3 | Estrazione SECI | Condensa ogni sessione in circa 500 caratteri di fatti strutturati |
| 4 | SECI ibrido + keyword | Fonde i punteggi grezzi ed estratti tramite reciprocal rank fusion, aggiunge un boost per la sovrapposizione delle parole chiave |
Tutti gli approcci usano ChromaDB con ricerca per similarità del coseno. Nessun LLM coinvolto nel retrieval. L'unica differenza è cosa viene indicizzato.
Risultati
LongMemEval_S: Retrieval a livello di sessione (500 domande, tutti i 6 tipi)
| Approccio | R@5 | R@10 | NDCG@5 | NDCG@10 |
|---|---|---|---|---|
| Grezzo, tutti i turni | 85,9% | 92,8% | 80,3% | 83,0% |
| Grezzo, solo utente (metodo MemPalace) | 92,1% | 96,3% | 86,8% | 88,5% |
| Estrazione SECI | 93,7% | 96,7% | 89,1% | 90,3% |
| SECI ibrido + keyword | 93,9% | 96,6% | 89,7% | 90,8% |
L'ibrido SECI ha battuto l'archiviazione grezza in stile MemPalace di 1,8 punti percentuali su R@5.
Dettaglio per tipo di domanda
| Approccio | Aggiorn. conoscenza (n=72) | Multi-sessione (n=121) | SS-User (n=64) | Temporale (n=127) |
|---|---|---|---|---|
| Grezzo, solo utente (MemPalace) | 98,6% | 90,6% | 92,2% | 86,9% |
| Estrazione SECI | 95,8% | 93,2% | 96,9% | 88,8% |
| SECI ibrido+kw | 96,5% | 93,7% | 96,9% | 88,4% |
L'estrazione SECI è in testa su 4 dei 6 tipi di domanda. Il metodo MemPalace vince sull'aggiornamento della conoscenza (+2,1pp), dove conta la formulazione originale dei fatti modificati. Il vantaggio SECI è più marcato sulle domande single-session-user (+4,7pp), dove la risposta è sepolta in profondità in una lunga conversazione.
Perché l'estrazione vince: il problema del troncamento a 256 token
Il risultato ci ha sorpreso. La tesi di MemPalace è intuitiva: l'estrazione perde informazioni, il grezzo conserva tutto. In teoria, il grezzo dovrebbe vincere.
Il margine è più stretto di quanto suggerito dal nostro campione iniziale di 100 domande (+4,9pp ridotto a +1,8pp alla scala completa di 500 domande). Le domande di ragionamento temporale e di aggiornamento della conoscenza hanno avvicinato il divario. È esattamente per questo che si esegue il benchmark completo.
La realtà: il modello di embedding non riesce a leggere l'intero documento.
all-MiniLM-L6-v2 (il modello predefinito di ChromaDB, usato sia da MemPalace sia dal nostro benchmark) ha una lunghezza massima di sequenza di 256 token. Sono all'incirca 1.000 caratteri.
Le sessioni di LongMemEval hanno in media 10.000 caratteri. Alcune superano i 30.000.
Quando archivi una sessione grezza e la incorpori, il modello legge i primi circa 1.000 caratteri e ignora il resto. Il 90% del contenuto è invisibile al retrieval.
La nostra estrazione SECI condensa l'intera sessione in circa 500 caratteri di fatti chiave strutturati. Ogni fatto estratto rientra nella finestra di 256 token. Nulla viene troncato.
La tesi del "grezzo vince sempre" regge solo quando il tuo modello di embedding riesce davvero a leggere l'intero documento. A 256 token, non può.
Raw session (10,000 chars):
[████████░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░]
↑ embedded (1,000 chars) ↑ truncated (9,000 chars) ← invisible to search
SECI extraction (500 chars):
[████████████████████]
↑ entire content embedded ← nothing lost
Un modello di embedding a contesto più lungo cambierebbe il risultato?
Probabilmente sì. Modelli come bge-large-en-v1.5 (512 token) o nomic-embed-text-v1.5 (8192 token) permetterebbero all'archiviazione grezza di incorporare una porzione maggiore di ogni sessione. Il 96,6% pubblicato da MemPalace potrebbe usare ottimizzazioni oltre il modello predefinito. Stiamo testando embedding a contesto più lungo come prossimo passo.
Il punto resta valido: la qualità del tuo retrieval è limitata dalla tua finestra di embedding, e la maggior parte degli sviluppatori non lo verifica.
Cosa ha fatto bene MemPalace
Merito a chi lo merita:
-
Indicizzazione solo utente. Rimuovere i turni dell'assistente ha migliorato il retrieval grezzo dal 85,9% al 92,1%, un salto di 6,2 punti. Le risposte dell'assistente aggiungono rumore (generico, verboso) che diluisce l'embedding. Scelta di design intelligente.
-
Prestazioni sull'aggiornamento della conoscenza. Il grezzo solo utente ottiene il 98,6% sulle domande di aggiornamento della conoscenza contro il nostro 96,5%. Quando i fatti cambiano nel tempo, avere la formulazione originale aiuta. L'estrazione può attenuare il segnale dell'aggiornamento.
-
Cultura del benchmarking. Pubblicare risultati LongMemEval riproducibili con gli script, essere trasparenti su quale modalità (grezzo vs AAAK vs rooms) produce quale punteggio ed emettere correzioni oneste entro 48 ore dal lancio. È così che dovrebbe funzionare l'open source.
-
L'intuizione centrale è in parte corretta. Su larga scala e con il modello di embedding giusto, l'archiviazione grezza è una base solida. Il settore ha sovra-ingegnerizzato l'estrazione con costose chiamate LLM quando funzionano approcci più semplici. La sfumatura: "più semplice" deve tenere conto della finestra di embedding.
Il modello SECI per la memoria dell'IA
Il nostro approccio all'estrazione si basa sul modello di gestione della conoscenza SECI (Nonaka & Takeuchi, 1995), adattato per la memoria degli agenti IA:
| Fase | Flusso di conoscenza | Implementazione |
|---|---|---|
| Socializzazione | Tacito → Tacito | La sessione avviene, il contesto viene vissuto |
| Esternalizzazione | Tacito → Esplicito | /distill estrae fatti strutturati in markdown |
| Combinazione | Esplicito → Esplicito | /consolidate unisce, deduplica, rileva il decadimento |
| Interiorizzazione | Esplicito → Tacito | /remember carica il contesto rilevante nella sessione successiva |
Il sistema archivia la conoscenza estratta come file markdown piatti in 10 namespace (brain, patterns, solutions, research, content, voice, clients, projects, docs, quick-reference). Ogni file è leggibile dall'uomo e versionato.
Per questo benchmark abbiamo aggiunto ChromaDB sotto i file markdown: doppia indicizzazione sia del testo grezzo sia dei riassunti estratti, con reciprocal rank fusion al momento della query.
Metodologia
Dataset: LongMemEval_S (Wu et al., "LongMemEval: Benchmarking Chat Assistants on Long-Term Interactive Memory," ICLR 2025). 500 domande, circa 48 sessioni haystack per domanda, lunghezza media della sessione 10.042 caratteri.
Modello di embedding: all-MiniLM-L6-v2 (384 dimensioni, lunghezza massima di sequenza 256 token). Predefinito di ChromaDB.
Retrieval: granularità a livello di sessione. Retrieval dei top 10. Metriche: Recall@5, Recall@10, NDCG@5, NDCG@10.
Metodo di estrazione: condensazione basata su regole (nessun LLM). Estrae l'argomento dal primo messaggio dell'utente, il follow-up dall'ultimo messaggio dell'utente, la risoluzione dall'ultimo messaggio dell'assistente. Circa 500 caratteri per sessione. Questo simula la struttura di output del nostro comando /distill.
Fusione ibrida: Reciprocal Rank Fusion (k=60) dei punteggi di retrieval grezzi ed estratti, più un boost per la sovrapposizione delle parole chiave (fino al 30% per corrispondenze esatte di termini).
Campione: 500 domande (470 valutate, 30 di astensione saltate). Tutti i 6 tipi di domanda: single-session-user, single-session-assistant, single-session-preference, multi-session, temporal-reasoning, knowledge-update.
Codice: seci_vs_mempalace.py
Avvertenze
- Retrieval dei top 10. MemPalace esegue il benchmark con retrieval dei top 50 (n_results=50) e valuta R@5 da quel pool. Il nostro top 10 è più vincolato. Un confronto equo con parametri allineati arriverà a breve.
- Estrazione basata su regole. La nostra estrazione usa condensazione tramite regex/euristica, non riassunto LLM. Un'estrazione basata su LLM migliorerebbe probabilmente la qualità, ma aggiungerebbe costo e latenza.
- Modello di embedding singolo. I risultati sono specifici per all-MiniLM-L6-v2 (256 token). Modelli a contesto più lungo restringerebbero il divario tra gli approcci grezzo ed estratto.
- L'aggiornamento della conoscenza è un punto debole. Il metodo MemPalace ottiene il 98,6% contro il nostro 96,5% sulle domande in cui i fatti cambiano nel tempo. L'estrazione può attenuare il segnale dell'aggiornamento.
Cosa significa per chi costruisce
Se stai costruendo un sistema di memoria per l'IA:
-
Controlla la tua finestra di embedding. Se il tuo modello di embedding tronca a 256 o 512 token e i tuoi documenti sono più lunghi, stai perdendo informazioni a livello di embedding indipendentemente dalla tua strategia di archiviazione.
-
L'estrazione non è sempre a perdita. Quando l'estrazione condensa un documento lungo in una rappresentazione che rientra nella finestra di embedding, conserva più informazioni recuperabili rispetto all'archiviazione grezza che viene troncata.
-
L'indicizzazione solo utente aiuta. Rimuovere i turni dell'assistente dalla memoria conversazionale riduce il rumore. Un miglioramento di 6,2 punti gratis.
-
Il retrieval ibrido aggiunge qualità di ranking. Fondere i punteggi grezzi ed estratti tramite RRF non migliora il recall rispetto alla sola estrazione, ma migliora l'NDCG (qualità del ranking). I documenti giusti si posizionano più in alto quando combini entrambi i segnali.
-
Fai il benchmark del tuo sistema. LongMemEval è gratuito, ben progettato e riproducibile. Eseguirlo richiede poche ore. I risultati potrebbero sorprenderti.
Riprodurre questi risultati
# Install dependencies
pip install chromadb sentence-transformers
# Download LongMemEval data
mkdir -p data && cd data
curl -L -o longmemeval_s_cleaned.json \
https://huggingface.co/datasets/xiaowu0162/longmemeval-cleaned/resolve/main/longmemeval_s_cleaned.json
cd ..
# Run benchmark
python seci_vs_mempalace.py --dataset s --mode retrieval
Codice completo: github.com/rankfor/ai-memory-benchmark
Cosa stiamo testando come prossimo passo
- Modelli di embedding a contesto più lungo (bge-large, nomic-embed-text) per vedere se l'archiviazione grezza recupera terreno quando il troncamento viene rimosso.
- Estrazione basata su LLM (Gemini Flash per il riassunto delle sessioni) rispetto alla nostra estrazione basata su regole.
- Boosting temporale per un retrieval consapevole delle date sulla categoria di domande di ragionamento temporale.
- Retrieval dei top 50 per replicare la configurazione esatta di MemPalace e fare un confronto equo.
Il codice è aperto. Le riproduzioni sono benvenute.
Dmitrij Żatuchin, Rankfor.AI. Aprile 2026.
Questa ricerca è indipendente. Non abbiamo alcuna affiliazione con MemPalace, LongMemEval o ChromaDB. Il codice del benchmark e i risultati sono aperti alla riproduzione.