Sintesi Tecnica: Agenti ReAct Stateful per l'Esperimentazione Autonoma Efficiente dal Punto di Vista dei Token

Definizione del Problema

Il pattern "autoresearch" consente l'esperimentazione autonoma permettendo a un Large Language Model (LLM) di modificare iterativamente il codice per ottimizzare una metrica target. Sebbene efficace, l'implementazione standard è stateless: ad ogni iterazione, l'agente deve ricostruire l'intero contesto sperimentale rileggendo la cronologia completa dei risultati e delle modifiche al codice accumulate in un file di direttiva di ricerca (ad esempio, program.md).

Questo design introduce un'inefficienza strutturale:

• Costo dei Token: La dimensione del prompt cresce linearmente ($O(n)$) con il numero di iterazioni, portando a un costo totale di token di $O(n^2)$.
• Ridondanza: L'agente ritrasmette informazioni che ha già elaborato nei passaggi precedenti.
• Scalabilità: Man mano che gli esperimenti si accumulano, il prompt si avvicina ai limiti della finestra di contesto, rendendo necessaria la troncatura o la sintesi, il che rischia di perdere sfumature sperimentali critiche.

Il documento postula che, poiché gli LLM non possono mantenere uno stato transitorio tra le interazioni (Huang et al. [10]), la gestione di uno stato esterno è una necessità architettonica per rompere questa curva di costo quadratica.

Metodologia

Gli autori riformulano il pattern autoresearch come un agente ReAct stateful utilizzando LangGraph. Invece di prompt monolitici contenenti l'intera cronologia, l'agente interagisce con il sistema ML tramite chiamate a strumenti (tool calls), mentre la cronologia sperimentale, le tracce di ragionamento e le metriche di convergenza persistono in un grafo di stato persistente tipizzato.

Architettura

L'agente opera come un grafo di stato con tre nodi primari:

1. REASON (Ragionamento): Invoca l'LLM (Claude Haiku 4.5) con il contesto dello stato corrente. Il modello genera tracce di ragionamento e chiamate a strumenti.
2. TOOLS (Strumenti): Esegue le chiamate agli strumenti in modo deterministico (ad esempio, eseguendo esperimenti, interrogando i risultati) e restituisce osservazioni.
3. CHECK (Controllo): Valuta i criteri di convergenza (soglia della metrica target, budget di iterazione o conclusione dell'LLM) senza l'intervento dell'LLM.

Gli archi condizionali indirizzano il flusso: se l'LLM produce chiamate a strumenti, il controllo passa a TOOLS; altrimenti, procede verso CHECK. Se non c'è convergenza, il ciclo ritorna a REASON.

Gestione dello Stato

L'innovazione principale è l' AgentState (un dizionario tipizzato) che persiste attraverso le iterazioni. Include:

• messages: Una finestra scorrevole degli ultimi 20 messaggi per limitare il costo di input.
• experiment_history: Una lista di tutti i risultati passati.
• current_best: Il miglior risultato trovato finora.
• train_py_content: Lo stato corrente del codice.

Fondamentalmente, l'agente utilizza una classe helper (ExperimentState o CodeState) per generare un riassunto compatto per l'LLM ad ogni step. Questo riassunto include:

• Conteggio delle iterazioni correnti e migliori metriche aggregate.
• Gli ultimi 5 esperimenti (o risultati recenti).
• Note sulla strategia e approcci falliti.

Ciò garantisce che l'LLM riceva solo $O(1)$ token di input per iterazione, indipendentemente dal numero totale di esperimenti eseguiti. La cronologia completa rimane accessibile nello stato, ma viene esclusa dal prompt a meno che non venga esplicitamente interrogata tramite strumenti.

Strumentazione (Tooling)

L'agente interagisce con il sistema ML attraverso strumenti specifici:

• Tuning degli Iperparametri: get_experiment_history e run_experiment.
• Ottimizzazione del Codice: get_current_train_py, modify_train_py (con guardrail per preservare la logica di valutazione), submit_training_job e query_results.

Contributi Chiave

1. Riformulazione Architetturale: Trasformazione del pattern autoresearch stateless in un agente ReAct stateful utilizzando LangGraph, disaccoppiando la memoria di lavoro dell'agente dal suo contesto di prompt.
2. Efficienza dei Token: Dimostrazione di una riduzione strutturale del costo dei token da $O(n^2)$ (stateless) a $O(n)$ (stateful) totale, con un costo per iterazione di $O(1)$.
3. Blueprint di Implementazione: Fornitura di un'architettura dettagliata e riproducibile (inclusi schemi di stato, logica di grafo e definizioni di strumenti) per consentire ai professionatori di implementare agenti stateful.

Risultati Sperimentali

Gli autori hanno valutato l'agente stateful contro un baseline stateless su due task di benchmark utilizzando 3 seed casuali.

Task 1: Tuning degli Iperparametri (Osservazioni Piccole)

• Setup: 15 iterazioni per ottimizzare XGBoost sul dataset UCI Covertype. Le osservazioni erano piccole (~200 token: configurazione JSON + metriche).
• Risultati:
  • Riduzione dei Token: L'agente stateful ha consumato il 90% in meno di token (2.492 vs 24.465), una riduzione di 9,8×.
  • Performance: Entrambi gli agenti hanno ottenuto punteggi F1 comparabili (0,779 vs 0,764), con differenze attribuite alla varianza del seed piuttosto che alla superiorità architettonica.
  • Curva dei Costi: Il costo di input stateless è cresciuto linearmente da circa 700 a circa 1.900 token per iterazione; il costo stateful è rimasto piatto a circa 100 token.

Task 2: Ottimizzazione delle Performance del Codice (Osservazioni Grandi)

• Setup: 40 iterazioni per ottimizzare una funzione di elaborazione dati in Python. Le osservazioni erano grandi (~1.500–3.000 token: codice sorgente completo + benchmark).
• Risultati:
  • Riduzione dei Token: L'agente stateful ha consumato il 52% in meno di token (627K vs 1.275K), una riduzione di 2,0×.
  • Performance: Entrambi gli agenti hanno ottenuto accelerazioni comparabili (~1,9× rispetto al baseline).
  • Curva dei Costi: Sebbene l'agente stateful abbia comunque sostenuto un costo fisso per inviare il "miglior codice attuale" (~1.500 token) ad ogni step, il costo totale si è stabilizzato. Al contrario, il costo stateless ha continuato a salire linearmente, accumulando oltre 80.000 token di cronologia all'iterazione 40.

Analisi Comparativa

Il rapporto di riduzione dei token è inversamente proporzionale alla dimensione dell'osservazione rispetto al riassunto dello stato.

• Osservazioni Piccole: Il riassunto a dimensione fissa è drasticamente più piccolo della cronologia accumulata, producendo alti rapporti di riduzione (9,8×).
• Osservazioni Grandi: L'agente stateful deve comunque trasmettere l'artefatto del codice corrente, limitando il rapporto (2,0×). Tuttavia, il documento nota che all'aumentare delle iterazioni (ad esempio, a 100 o 200), la divergenza tra $O(n^2)$ e $O(n)$ causerà un allargamento significativo del rapporto (proiettato tra 4× e 7×).

Significatività e Claim

Il documento sostiene che il contributo primario sia l'efficienza strutturale, non necessariamente la qualità dell'ottimizzazione. L'agente stateful raggiunge una qualità di ottimizzazione comparabile al baseline stateless riducendo drasticamente il consumo di token.

• Scalabilità: Il costo per iterazione di $O(1)$ consente sequenze sperimentali arbitrariamente lunghe senza necessità di troncamento del prompt o perdita di capacità decisionale.
• Impatto Economico: Sebbene i risparmi siano modesti per sessioni brevi, diventano materiali per la ricerca su larga scala (centinaia di esperimenti giornalieri), dove il costo quadratico dell'esecuzione stateless diventa un collo di bottiglia dominante.
• Prospettive Future: Gli autori suggeriscono che, man mano che gli orizzonti sperimentali si allungano, il costo quadratico dei token dell'esecuzione stateless diventerà il vincolo primario, rendendo le architetture stateful essenziali per un'esperimentazione autonoma sostenibile.

Gli autori rimangono modesti riguardo alla qualità dell'ottimizzazione, dichiarando esplicitamente che le differenze osservate nelle metriche rientrano nel rumore e non devono essere interpretate come vantaggi qualitativi dell'approccio stateful. Il focus rimane strettamente sui guadagni di efficienza derivanti dal cambio architettonico.