Più a lungo lavoro con gli LLM, più mi ritrovo nell'eterna battaglia tra contesto sufficiente, contesto eccessivo, spreco di token e guerra alla compattazione. Cercando sistemi di memoria agentica, si vede che esistono armi potenti per aiutarci in questo.
La scoperta che emerge costantemente dai 19 sistemi che ho analizzato è che finestre più grandi intensificano il problema del budget, anziché risolverlo. Una finestra da 200.000 token non presta uguale attenzione a tutti e 200.000 token. Le prestazioni degradano molto prima che la finestra si riempia. Il degrado non è uniforme: il materiale al centro di un contesto lungo riceve sistematicamente meno attenzione di quello ai margini. E il compito effettivo dell'agente occupa una fetta fissa della finestra, indipendentemente da quanto essa sia grande, il che significa che tutto il resto è overhead in competizione per lo stesso budget di attenzione.
I sistemi che gestiscono bene questo aspetto convergono su sei meccanismi. Nessuno di essi è esotico. Alcuni sono imbarazzantemente semplici. Ma chi li salta, li paga.
I sei meccanismi
Passaggi di compattazione
Il meccanismo più visibile. Si prende una lunga conversazione o un grande segmento di memoria, lo si riassume e si sostituisce l'originale con il riassunto. MemoryOS lo fa a livello di segmento: il suo riassuntore di segmenti scatta quando un segmento di conversazione supera una soglia, comprimendolo in una rappresentazione compatta prima che possa soffocare il contesto di lavoro. I wiki con pattern Karpathy (purpose.md, overview.md) fanno una versione di questo a livello di conoscenza: il wiki è la forma compattata di tutto ciò che l'agente ha imparato su un argomento, mantenuto tra le sessioni.
Il compromesso è la perdita di informazioni. La compattazione è un'operazione con perdita per definizione. Il riassunto cattura ciò che il riassuntore ha giudicato rilevante al momento della compattazione. Se in seguito l'agente ha bisogno di un dettaglio che non è stato giudicato rilevante, questo è perso. Non è un motivo per evitare la compattazione, ma è un motivo per non trattarla come l'unico meccanismo.
C'è un secondo costo facile da trascurare. La compattazione non è gratuita a runtime. MemoryOS può sostenere 20 o più chiamate LLM in una singola interazione per mantenere i riassunti dei suoi segmenti. Per sistemi con alta frequenza di interazione, questo è un costo operativo reale.
Troncamento con anteprima del risultato
Invece di restituire l'intero contenuto della memoria a ogni recupero, restituisci una breve anteprima e lascia che l'agente decida se recuperare il record completo. supermemory espone controlli di lunghezza dei frammenti che consentono ai chiamanti di regolare quanto testo viene restituito per risultato. mem9 va oltre: decora i turni sorgente con tre variabili d'ambiente (MEM9_SOURCE_TURN_MIN_SCORE, MEM9_SOURCE_TURN_PER_MEMORY_LIMIT, MEM9_SOURCE_TURN_TOTAL_LIMIT) che danno agli operatori un controllo preciso su quanti turni sorgente appaiono e con quale punteggio minimo di rilevanza.
Il compromesso è una chiamata extra all'strumento. Se l'agente ha bisogno del contenuto completo, deve richiederlo esplicitamente. Per la maggior parte dei pattern di recupero, questo è il compromesso giusto: l'agente riceve abbastanza segnale per decidere se il record è rilevante prima di pagare il costo in token per leggerlo integralmente.
Recupero in due fasi
Una variante specifica e importante del troncamento con anteprima. La ricerca restituisce identificatori e brevi anteprime. Una chiamata separata GetByID recupera il record completo quando necessario. L'interfaccia MemoryRepo di mem9 è costruita attorno a questo pattern: ricerca e recupero sono operazioni distinte con impronte di token distinte.
I numeri parlano chiaro. Dieci corrispondenze a 1.500 token ciascuna significano 15.000 token iniettati nel contesto, che l'agente li usi o no. Il recupero in due fasi restituisce 10 identificatori e brevi anteprime per un totale di circa 450 token, poi recupera solo i record di cui l'agente ha effettivamente bisogno. In 20 passaggi di recupero in una sessione, questa differenza si accumula fino a circa 200.000 token risparmiati.
Questa è la disciplina più economica che si possa adottare. Non richiede modifiche architetturali al deposito di memoria, nessuna chiamata LLM aggiuntiva e nessuna perdita di informazioni. È una decisione sull'interfaccia di recupero.
Scomposizione e poi recupero
Invece di inviare l'intera query dell'utente al livello di recupero, scomponila prima in sotto-query. Il pianificatore di recupero sensibile all'intento di SimpleMem scompone le query in arrivo in intenzioni di recupero atomiche prima di accedere al deposito di memoria. GitNexus fa qualcosa di simile con la scomposizione degli strumenti di query: le query complesse vengono suddivise in sotto-query mirate, ciascuna delle quali recupera una fetta focalizzata del grafo di memoria.
Il vantaggio è la precisione. Una query scomposta recupera meno materiale irrilevante, il che significa meno rumore nel contesto. Il compromesso è la latenza: la scomposizione aggiunge un passaggio di pianificazione prima che inizi il recupero. Per gli agenti interattivi questo è importante. Per gli agenti batch o in background di solito non lo è.
Archiviazione a livelli come filtro di budget
Se hai già costruito un'architettura di memoria a livelli (l'argomento dell'articolo della scorsa settimana), ottieni il filtraggio del budget come effetto collaterale. Il modello a tre livelli di supermemory significa che il materiale caldo e frequentemente accesso risiede in un livello che restituisce risultati compatti e ad alto segnale. Il materiale freddo è in un livello che non viene interrogato di default. Il livello di osservazione di Hindsight funziona allo stesso modo: le osservazioni grezze non vengono iniettate direttamente nel contesto; vengono promosse a livelli superiori prima di diventare candidati al recupero.
Il compromesso è la completezza del richiamo. Il materiale che non è stato promosso potrebbe essere rilevante ma non emergerà in un passaggio di recupero standard. Questo è lo stesso compromesso della compattazione, ma la modalità di fallimento è diversa: invece di perdere informazioni attraverso la riassunzione, le perdi attraverso la retrocessione.
Risposte auto-guidanti degli strumenti
Il meccanismo meno discusso e uno dei più interessanti. Invece di lasciare che l'agente decida cosa fare dopo una chiamata a uno strumento, la risposta dello strumento include un suggerimento su cosa fare dopo. GitNexus aggiunge un blocco \---
**Successivo:**\ alle risposte degli strumenti, suggerendo azioni di follow-up. mem9 decora i turni sorgente con metadati strutturati che guidano il passo di recupero successivo dell'agente.
L'effetto è che l'agente spende meno token per pianificare tra le chiamate agli strumenti. La risposta dello strumento porta abbastanza struttura da rendere ovvio il passo successivo. Il compromesso è lo sforzo di prompt engineering: scrivere buone risposte auto-guidanti richiede di sapere in anticipo cosa probabilmente servirà all'agente dopo, il che non è sempre possibile.
Il caso limite di Tolaria
Tolaria merita un'analisi separata perché rappresenta il punto finale logico della disciplina di budget portata al suo estremo. ADR-0009 documenta la decisione di rimuovere del tutto gli embeddings dal sistema. Tolaria usa solo la ricerca per sottostringhe. Nessun indice vettoriale, nessun recupero semantico, nessuna chiamata di embedding.
Il ragionamento è diretto: il token più economico è quello che non recuperi mai in primo luogo. Il recupero basato su embedding restituisce risultati semanticamente simili, il che significa che restituisce risultati che l'agente non ha esplicitamente richiesto. Alcuni di questi risultati sono utili. Molti non lo sono. Tutti costano token.
La posizione di Tolaria è che il costo di risultati irrilevanti ma simili, accumulato nel corso di una sessione, supera il beneficio del richiamo semantico per il suo caso d'uso. Se questo compromesso vale per il tuo sistema dipende da a cosa serve il tuo sistema. Per i sistemi in cui le query sono precise e strutturate (navigazione nel codice, ricerca di documenti per identificatore), la posizione di Tolaria è difendibile. Per i sistemi in cui le query sono vaghe ed esplorative, rimuovere gli embeddings rompe il richiamo in modi difficili da recuperare.
Il valore del caso Tolaria non è che dovresti copiarlo. È che rende visibile il costo del recupero semantico in un modo che la maggior parte dei sistemi non fa.
Il caso contro i sistemi basati solo sulla compattazione
Diversi dei 19 sistemi si affidano alla compattazione come meccanismo principale o unico di budget. Vale la pena nominare le modalità di fallimento.
La prima è che la riassunzione perde dettagli che non sono stati giudicati rilevanti al momento della compattazione ma che diventano rilevanti in seguito. Questo non è ipotetico: è la modalità di fallimento standard di qualsiasi schema di compressione con perdita applicato a informazioni la cui rilevanza futura è sconosciuta.
La seconda è che la compattazione è un costo sul percorso caldo. Il fatto che MemoryOS paghi 20 o più chiamate LLM per interazione non è insolito per i sistemi pesanti in compattazione. Su larga scala, questo costo non è trascurabile.
La terza, e la più sottile, è che la compattazione senza una via di fuga è un lento oblio. Se l'unico modo per ridurre la dimensione del contesto è riassumere, e i riassunti hanno perdita, allora il sistema scarta continuamente informazioni senza modo di recuperarle. Il recupero in due fasi, l'archiviazione a livelli e il troncamento con anteprima del risultato preservano tutti il record originale. La compattazione no.
Niente di tutto questo significa che la compattazione sia sbagliata. Significa che la sola compattazione non basta.
Ponderazione per recenza e coda persistente
Due meccanismi che non rientrano perfettamente nelle sei categorie sopra meritano di essere menzionati.
graymatter usa la fusione RRF con la recenza a metà peso. Questo non è un meccanismo di budget in senso stretto, ma funziona come tale: riducendo il peso del materiale più vecchio nei ranking di recupero, diminuisce la probabilità che record obsoleti e a basso segnale soffochino quelli recenti e ad alto segnale. L'effetto è una stratificazione morbida attraverso i pesi di ranking piuttosto che una promozione esplicita a un livello.
La macchina a stati della coda di ingest di llm-wiki, lunga 540 righe, adotta un approccio diverso. La coda serializza le operazioni di ingest e applica un ranker di rilevanza a quattro segnali prima che qualcosa entri nel deposito di memoria. Il controllo del budget avviene al momento della scrittura, non della lettura. Il materiale che non supera la soglia di rilevanza non viene memorizzato, il che significa che non può essere recuperato e non può consumare contesto. Questo è un controllo indiretto del budget, ma è durevole: i risparmi si accumulano in ogni sessione futura.
Cosa hanno in comune i sistemi ben progettati
Analizzando i 19 sistemi, quelli che gestiscono bene i budget di contesto condividono alcune proprietà.
Trattano il recupero come un'operazione in due fasi piuttosto che come un'iniezione unica. Restituiscono anteprime prima dei record completi. Preservano i record originali invece di sostituirli con riassunti. Danno agli operatori il controllo sul volume di recupero attraverso parametri espliciti anziché valori predefiniti fissi. E pensano al budget sia al momento della scrittura che della lettura.
Quelli che lo gestiscono male tendono a fare affidamento su un singolo meccanismo, di solito la compattazione, e trattano la finestra di contesto come un buffer da riempire piuttosto che come una risorsa da gestire.
La posizione conclusiva della ricerca è semplice. Finestre più grandi richiedono più disciplina, non meno. Non perché riempirle sia sbagliato in linea di principio, ma perché riempirle con il materiale sbagliato costa più che lasciare lo spazio vuoto.
Per il mio prossimo articolo, ho in programma di passare dalla memoria come iniezione alla memoria come strumento, trattando come i 19 sistemi gestiscono il confine tra ciò che viene spinto automaticamente nel contesto e ciò che l'agente deve richiedere esplicitamente.*
Come sempre, se hai trovato questo interessante, utile o vuoi solo aiutare a diffondere la conoscenza:
Per favore, condividi.
