Il limite di token è un budget, non una piccola restrizione

Da diverse settimane, ho notato che Paperclip può consumare la mia quota settimanale di token in un solo giorno. Il problema non è l'elevato consumo in sé. Se portasse a cambiamenti proporzionali e visibili nelle applicazioni, potrebbe essere considerato un costo di lavoro. Nel frattempo, una parte significativa dell'attività ruotava attorno allo sviluppo e alla documentazione del sistema, mentre i progetti che questo lavoro avrebbe dovuto supportare si evolvevano molto più lentamente.

Ho quindi impostato Paperclip in modo che si fermi al 75% del limite. Il limite rimanente serve a proteggere altri utilizzi di Codex, dato che Paperclip non è la mia unica area di lavoro. Si tratta di una semplice misura di sicurezza, ma rivela un problema più importante: i token non sono un numero astratto visibile da qualche parte in una dashboard. Sono un budget operativo condiviso per il quale attività, progetti e agenti competono.

Preferisco parlare di intelligenza computazionale piuttosto che di intelligenza artificiale. Non è solo una questione di stile. Una buona definizione dovrebbe descrivere la realtà nel modo più fedele possibile. Il termine "artificiale" può suggerire qualcosa di irreale, illusorio o inferiore all'intelligenza umana. "Computazionale", d'altro canto, indica un meccanismo: algoritmi, matematica ed esecuzione di calcoli. Ciò non implica l'assunto che l'intelligenza umana sia l'unica vera o la più elevata forma di risoluzione dei problemi.

Un buon esempio dei limiti di questa visione antropocentrica è il Physarum polycephalum. Nell'esperimento, sono stati distribuiti punti di alimentazione in posizioni corrispondenti a 20 grandi aree metropolitane degli Stati Uniti. Il miceto mucillaginoso unicellulare li ha collegati con una rete che, in un grafico semplificato, ha ricreato 36 dei 41 collegamenti del sistema autostradale interstatale degli Stati Uniti (Adamatzky e Ilachinski, 2012). Questo non significa che il miceto mucillaginoso possieda una personalità umana o che abbia progettato autostrade perfette. Tuttavia, ciò dimostra che il calcolo utile e l'ottimizzazione della rete non sono prerogativa esclusiva della mente umana.

Da questa prospettiva, un limite di token è simile a un limite di tempo umano, di larghezza di banda del team o di potenza di calcolo disponibile. Non determina ancora quanto valore verrà creato. Piuttosto, determina quanto lavoro il sistema può tentare di completare prima di perdere la capacità di portare a termine i compiti successivi.

Il consumo di risorse non è prova dei risultati

Non esiste un unico numero corretto di token da assegnare a ciascun compito. Scrivere una breve poesia e preparare un foglio di calcolo che confronti costi e ricavi richiedono quantità di impegno diverse. Pertanto, è impossibile valutare equamente un sistema basandosi esclusivamente sul rapporto tra token e numero di file, risposte o compiti generati.

Il punto di partenza deve essere un problema. All'agente devono essere forniti un obiettivo, un contesto e una descrizione del risultato che, una volta eseguito, sarà utile all'essere umano o all'agente successivo. Solo allora ci si può chiedere se il costo sia stato giustificato. Un artefatto non acquisisce valore semplicemente perché ha richiesto un'ampia deliberazione. La documentazione è necessaria se sblocca il lavoro. Se sostituisce la modifica che avrebbe dovuto abilitare, consuma il budget senza chiudere l'attività.

Paperclip oggi lascia due possibili diagnosi. Forse il budget disponibile è troppo limitato rispetto alla portata dei progetti assegnati. Forse il problema risiede nell'organizzazione del lavoro: attività troppo ampie, contesto mal definito, attività ripetute o criteri di accettazione che privilegiano una documentazione facilmente consultabile. È anche possibile che entrambi i vincoli agiscano simultaneamente. Il semplice fatto che il limite sia stato raggiunto non permette di separarli.

Un pacchetto più ampio non risolverà un problema mal definito. Permetterà solo di continuare a lavorare nello stesso modo più a lungo. D'altra parte, un budget troppo esiguo può interrompere una sequenza pianificata correttamente prima che i suoi componenti vengano combinati in un risultato. Pertanto, il limite dovrebbe essere analizzato insieme alla struttura delle attività, non come un ostacolo tecnico separato.

Contesto minimo indispensabile

La seconda risorsa limitata è il contesto. L'agente ha bisogno di informazioni per comprendere il problema, le dipendenze e le condizioni di accettazione. Se riceve informazioni insufficienti, deve procedere per tentativi o fermarsi a una soluzione locale che non tiene conto del resto del sistema. Se invece riceve tutte le informazioni mai registrate sul progetto, le informazioni necessarie per una determinata fase possono perdersi nel rumore di fondo.

Il mio principio di lavoro è paradossale: all'agente dovrebbe essere fornita la quantità massima di dati necessaria, che corrisponde anche alla quantità minima sufficiente. Non si tratta di salvare ogni singolo token, ma di garantirne l'adeguatezza. Il contesto dovrebbe includere tutto il necessario per il corretto completamento di una specifica fase e non dovrebbe contenere contenuti che non siano utili per la decisione o l'azione in corso.

Lo studio "Lost in the Middle" ha dimostrato che, nei compiti che utilizzano un contesto esteso, le prestazioni del modello dipendevano dalla posizione delle informazioni rilevanti e spesso diminuivano quando queste si trovavano al centro dell'input (Liu et al., 2024). Questo non dimostra che ogni prompt esteso sia inefficace. Tuttavia, dimostra che l'accettazione delle informazioni da parte del modello non equivale al loro utilizzo altrettanto efficace.

Il benchmark RULER ha rivelato una differenza simile. Gli autori hanno testato 17 modelli pubblicizzati come in grado di supportare almeno 32.000 token; Quasi tutti i modelli hanno perso efficacia con l'aumentare della lunghezza e della complessità, e la metà ha mantenuto il livello di prestazioni previsto a 32.000 token (Hsieh et al., 2024). La finestra dichiarata rappresenta quindi un limite tecnico per l'input, non una garanzia di ragionamento utile per tutta la sua lunghezza.

Questo corregge l'intuizione che la finestra disponibile debba essere riempita di default. Riempirla di dati ha senso solo se i dati sono necessari per il compito e sono stati organizzati in modo che l'agente possa trovare le dipendenze. Lo spazio vuoto nel contesto non è energia sprecata. A volte protegge da informazioni che competono per l'attenzione con il problema effettivo.

Il compito deve rientrare nella larghezza di banda dell'esecutore

Se la corretta esecuzione del compito richiede più contesto, il sistema ha due opzioni ragionevoli. Può aggiungere informazioni specifiche mancanti o suddividere il problema in fasi più piccole e dipendenti. La suddivisione non implica la creazione di compiti arbitrariamente piccoli. Ogni fase richiede un input, un risultato atteso e un criterio di accettazione, e il suo risultato deve essere utilizzabile nella fase successiva.

La revisione della letteratura LLM sulla pianificazione degli agenti elenca la scomposizione dei compiti come uno dei principali meccanismi di pianificazione, insieme alla selezione del piano, alla memoria, alla riflessione e ai moduli esterni. Allo stesso tempo, evidenzia i problemi aperti relativi alla pianificazione e all'esecuzione (Huang et al., 2024). La sola divisione non garantisce il successo. Può produrre parti localmente corrette che, se combinate, non risolvono il problema originale.

Quando pianifico il mio lavoro, utilizzo una semplice euristica: non pianifico attività che richiedono meno di circa cinque minuti; cerco di suddividere le attività che richiedono più di circa 25 minuti per mantenere la concentrazione. Non si tratta di una conversione del tempo umano in token di agente. L'analogia riguarda la granularità. Un'attività deve essere sufficientemente ampia affinché il suo risultato sia significativo, ma sufficientemente piccola da permettere all'esecutore di incorporare le dipendenze necessarie.

In un sistema ad agenti, una fase dovrebbe concludersi con un risultato intermedio controllato. Se l'agente ha analizzato i requisiti, il risultato non può limitarsi a indicare che l'analisi è stata completata. Dovrebbe fornire requisiti strutturati utili al pianificatore. Se lo sviluppatore ha modificato una funzione, il risultato dovrebbe includere il codice e la prova che i flussi corretti siano ancora funzionanti. Ciò impedisce all'agente successivo di dover ricreare l'intero contesto precedente e di dover rifare il lavoro.

Il budget deve proteggere la creazione di valore

La soglia del 75% è attualmente un vincolo manuale, non una prescrizione universale. In altri sistemi, la riserva appropriata può essere superiore o inferiore. La funzione di questo limite è importante: nessun processo autonomo dovrebbe assumere incontrollato l'intera risorsa condivisa e bloccare il lavoro a priorità più alta.

Prima di avviare una sequenza più ampia, è quindi importante conoscere il budget disponibile, il risultato minimo e la condizione di arresto. Dopo ogni passo più importante, il sistema dovrebbe essere in grado di rispondere a cosa è effettivamente cambiato, quale risultato sta trasmettendo e se continuare ha ancora un valore maggiore rispetto al risparmio della risorsa per un'altra attività. Quando si avvicina al limite, dovrebbe prima mettere in sicurezza lo stato e la prova, e solo dopo ridurre l'ambito o interrompere l'attività.

L'obiettivo non è garantire che ogni agente consumi il minor numero possibile di token. Un'ottimizzazione di questo tipo potrebbe premiare risposte superficiali e l'omissione delle dipendenze. L'obiettivo è un consumo adeguato: la quantità di ragionamento e contesto necessaria per fornire correttamente il risultato concordato, senza finanziare attività infinite che non avvicinano il sistema al completamento.

Il limite di pacchetti potrebbe effettivamente essere troppo basso. Tuttavia, prima di considerarlo l'unica causa, voglio verificare che il sistema sia in grado di conservare il budget, associare il contesto a una fase, suddividere il lavoro senza perdere il quadro generale e distinguere il risultato dalla traccia dell'attività. Solo allora un pool di token più ampio si tradurrà in una maggiore produttività. Senza questi meccanismi, potrebbe trattarsi semplicemente di un serbatoio più grande che Paperclip svuoterà allo stesso modo.

Bibliografia

✦Costruire sistemi per una maggiore autonomia.