Il tuo agente raggiunge l'80% della sua finestra di contesto. Si attiva la compattazione, che elimina i turni più vecchi. Dieci minuti dopo, rilegge un file che aveva già letto e ripropone una domanda a cui aveva già risposto.
La soglia indicava che lo spazio stava finendo. Non diceva nulla su cosa si potesse perdere senza conseguenze.
Questa è la terza nota di una serie sulla progettazione di agenti per attività di lunga durata, nata da una lettura approfondita di BEACON (Università di Zhejiang, arXiv:2605.06078). La prima trattava il rilevamento degli stalli, la seconda la progettazione dei traguardi intermedi.
Partiamo dalla nostra implementazione
Orkas è un client desktop multiagente. Qui le attività lunghe sono la norma, quindi la compattazione è una questione quotidiana. La nostra implementazione si attiva al raggiungimento di una soglia di token e compatta quando il contesto occupa circa l'80% della finestra. Finché non abbiamo messo per iscritto queste riflessioni, nessuno di noi pensava che ci fosse qualcosa di sbagliato.
Nella pratica, i criteri comuni sono più o meno tre: una percentuale della finestra, il numero di turni oppure un riepilogo dei contenuti precedenti scritto dal modello. Il nostro è del primo tipo.
I primi due non esaminano affatto il contenuto. Il terzo lo esamina, ma affida interamente al modello la decisione su ciò che conta.
Tutti e tre rispondono alla domanda quando devo eliminare qualcosa. La domanda reale è cosa posso eliminare senza conseguenze. Tagliare in corrispondenza della soglia elimina il contenuto più vecchio, non quello meno importante.
Il traguardo intermedio come confine e l'ipotesi su cui si basa
I traguardi intermedi descritti nella nota precedente potrebbero offrire un confine migliore di tutti e tre questi criteri. Ma qui c'è un'insidia, e la nota precedente l'ha presentata in modo un po' troppo semplice.
BEACON contiene un'ipotesi chiamata proprietà di Markov dei traguardi intermedi. In parole semplici: una volta raggiunto un traguardo, ciò che accade dopo dipende solo dai sotto-obiettivi rimasti, non da come ci sei arrivato. Una volta ottenuta la chiave, conta quale porta apri, non come l'hai trovata.
Sembra un via libera alla compattazione: superato un traguardo, il tratto precedente può essere messo da parte.
Ma è un'ipotesi, non un fatto. L'articolo usa ≈, non =, e gli autori discutono i casi in cui non regge.
Adeguata per l'addestramento, inadeguata per la compattazione
La stessa ipotesi, due utilizzi, con un ordine di grandezza di differenza nel rigore richiesto.
Nell'addestramento deve valere solo statisticamente. Se qualche decina di traiettorie di esecuzione su qualche migliaio la viola, la distorsione si annulla nella media. L'addestramento usa inoltre un segnale a livello di traiettoria come salvaguardia di fondo; eliminando quel livello, ALFWorld scende da 91.4 a 23.4, molto al di sotto del risultato che si ottiene senza fare nulla.
Nella compattazione deve valere caso per caso, per la singola esecuzione che hai davanti. Basta eliminare una volta l'elemento sbagliato per compromettere quell'attività. Non c'è nulla su cui fare una media.
Quindi il fatto che l'articolo si basi su questa ipotesi non significa che si possa trasferirla alla compattazione. I due utilizzi non le chiedono la stessa cosa.
Quattro casi in cui non regge
Li usiamo come lista di controllo quando ragioniamo su una politica di compattazione.
1. Conoscenze implicite accumulate lungo il percorso. In una fase iniziale, un passaggio stabilisce che una certa API restituisce i timestamp in UTC. Questo fatto non appartiene a nessun traguardo, ma serve a ogni passaggio successivo.
2. Risorse già consumate. Budget di token, quota di chiamate, tempo rimanente. Un traguardo non registra ho consumato il 60% del budget, ma quel numero determina se ci si può ancora permettere un nuovo tentativo.
3. Effetti collaterali che dipendono dal percorso. Il traguardo dice refactoring completato. Nel momento in cui inizia il debug, devi sapere quali cinque file sono stati effettivamente modificati.
4. Il traguardo stesso non è definito abbastanza precisamente. Questo è il peggiore dei quattro casi. Nell'articolo, un traguardo è uno stato completo dell'ambiente: hai la chiave oppure no, senza ambiguità. Un passaggio del piano è una frase in linguaggio naturale. "Completare la pulizia dei dati" non si avvicina neppure a descrivere tutto ciò che è accaduto in quella fase.
Cosa conservare invece
Non conservare solo un riepilogo. Il riepilogo è scritto dal modello, che decide a intuito cosa fosse importante.
Conserva un insieme fisso di campi, scelti da una persona. Almeno quattro:
- Com'è ora l'area di lavoro — quali file sono stati modificati e in quale stato si trovano.
- Quale budget rimane — token, quota di chiamate, tempo.
- Cosa è stato accertato — il fatto relativo a UTC e ogni informazione analoga che influenzerà le decisioni successive.
- Cosa è ancora irrisolto — ciò che ha causato un blocco, è stato aggirato e potrebbe ripresentarsi.
Confronta questi campi con i quattro casi di errore descritti sopra: corrispondono uno a uno. Questa corrispondenza è il modo più semplice per valutare se una politica di compattazione è sufficiente.
Metà di questo lavoro è quasi a costo zero. Come descritto nella nota precedente, il sistema ospitante registra già fatti deterministici dopo ogni chiamata a uno strumento: se un file è stato davvero riscritto, se un comando è stato effettivamente eseguito. Quei dati sono stati raccolti per verificare i traguardi, ma costituiscono l'istantanea dell'area di lavoro, quindi la compattazione può conservarli direttamente senza chiedere a un modello di riassumerli di nuovo.
La metà difficile riguarda gli altri due campi. Attualmente, ciò che è stato accertato e ciò che è ancora irrisolto esistono solo se il modello li mette per iscritto, ed è proprio per questo che sono le prime vittime della compattazione.
Si può misurare, non serve discuterne
Se dopo la compattazione l'agente rilegge un file eliminato dal contesto o ripropone una domanda a cui è già stata data risposta, l'ipotesi non ha retto per quell'attività e la prova è lì, davanti a te.
La misurazione è semplice: calcola l'intersezione tra i percorsi dei file letti dopo il punto di compattazione e quelli registrati prima.
Con quel numero, capire quali tipi di attività consentono una compattazione aggressiva e quali no diventa una questione da risolvere interrogando i dati, anziché una discussione progettuale. È lo stesso approccio della prima nota di questa serie: prima misurare, poi cambiare qualcosa.
I limiti da tenere presenti
Nulla di tutto questo è stato rilasciato. Siamo alla fase di progettazione e predisposizione delle misurazioni.
La scelta dei campi da conservare e del loro livello di dettaglio dovrebbe derivare dai dati su ciò che viene effettivamente recuperato di nuovo. Decidere ora è un buon modo per decidere male.
Ed è un approccio tra diversi possibili. In un prodotto di tipo diverso, il punto in cui fissare il confine e la definizione dei campi potrebbero essere completamente differenti. La lista di controllo dei quattro casi è trasferibile; la risposta specifica no.
La prossima e ultima nota di questa serie tratta l'autoriflessione: perché le lezioni che un agente ricava continuano a essere generiche quanto "fare più attenzione" e un aspetto davvero sorprendente di ciò che i suoi input contengono e non contengono.