🤖 machine learning

The Replay Gap: Static Evaluation of Model Switching in LLM Agents Scores the Wrong World

Questo articolo dimostra che i metodi di valutazione basati sulla riproduzione statica falliscono fondamentalmente nel valutare i router di agenti LLM perché la sostituzione degli output del modello nelle traiettorie registrate ignora la divergenza a cascata delle azioni successive dell'agente, portando a metriche di prestazione fuorvianti che non riflettono i risultati del mondo reale.

Autori originali: Ashritha Gonuguntla

Pubblicato 2026-08-11

📖 5 min di lettura🧠 Approfondimento

CC BY 4.0

Autori originali: Ashritha Gonuguntla

Articolo originale sotto licenza CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ Questa è una spiegazione generata dall'IA dell'articolo qui sotto. Non è stata scritta né approvata dagli autori. Per precisione tecnica, consulta l'articolo originale. Leggi il disclaimer completo

Immaginate di essere il capitano di una nave spaziale che naviga in un campo di asteroidi pericoloso. Avete una flotta di diversi piloti IA: alcuni sono veloci ed economici ma commettono piccoli errori, altri sono lenti, costosi e incredibilmente precisi. Per risparmiare carburante, decidete di cambiare pilota a metà viaggio in base a ciò che sta accadendo in quel momento. Se il percorso è libero, usate il pilota economico; se appare un enorme asteroide, passate all'esperto. Questo è il sogno del "routing agentico" nel mondo dei Large Language Models (LLM). Questi modelli sono i cervelli dietro gli agenti IA che possono scrivere codice, risolvere problemi matematici o giocare a videogiochi compiendo una serie di passi. La grande domanda per gli ingegneri è: come facciamo a sapere se la nostra strategia di cambio pilota funziona davvero?

Tradizionalmente, gli scienziati hanno testato queste strategie come un regista cinematografico che recensisce una sceneggiatura. Esaminano un viaggio registrato (una "traiettoria") dove un singolo pilota ha volato per tutto il percorso. Poi, fingono: "E se avessimo cambiato il pilota al passo 10?". Semplicemente incollano le risposte registrate del nuovo pilota nella vecchia sceneggiatura e vedono se il finale sembra soddisfacente. Questo è chiamato "valutazione di riproduzione" (replay evaluation). È economico, veloce e presuppone che, se cambiassimo il pilota al passo 10, il resto del viaggio della nave sarebbe rimasto esattamente uguale alla registrazione originale. Ma nel mondo reale, una nave spaziale è un ciclo chiuso: l'azione del pilota al passo 10 cambia la visuale al passo 11, il che cambia la decisione al passo 12, e così via. Se il nuovo pilota vede un campo di asteroidi diverso a causa della propria azione precedente, l'intera sceneggiatura cambia. Questo articolo pone una domanda semplice e terrificante: il nostro metodo di test basato sulla "sceneggiatura cinematografica" sta in realtà misurando la realtà sbagliata?

I ricercatori della Carnegie Mellon University hanno deciso di smettere di tirare a indovinare e hanno iniziato a testare. Invece di modificare una sceneggiatura cinematografica, hanno costruito una macchina del tempo. Hanno preso veri agenti IA che risolvevano problemi di ingegneria del software e, in momenti specifici, hanno "ramificato" la linea temporale. Hanno creato due universi paralleli: uno in cui il pilota originale continuava il viaggio, e un altro in cui avevano inserito un modello diverso. Fondamentalmente, non si sono limitati a incollare nuove risposte nella vecchia storia; hanno lasciato che il nuovo pilota prendesse effettivamente il controllo, interagisse con l'ambiente informatico e vedesse cosa sarebbe effettivamente successo dopo. Hanno eseguito circa 900 di questi esperimenti paralleli per vedere quanto le storie divergessero.

I risultati sono stati uno shock per il sistema. L'assunto che il resto del viaggio rimanga invariato era completamente errato. Quando si cambiavano i modelli, il nuovo pilota non si limitava a prendere il controllo del percorso esistente; riscriveva l'intero futuro. Nelle fasi iniziali di un compito, il cambio di modello causava il cambio di idea dell'agente nel 74% - 77% delle sue azioni immediatamente successive. Entro il momento in cui i ricercatori hanno esaminato l'intero viaggio, il nuovo pilota aveva riscritto il 61% - 94% di tutti i passi successivi al cambio. Per dare un termine di paragone, se sostituiste un pilota in un videogioco, il mondo di gioco cambierebbe così drasticamente che la "sceneggiatura" che stavate cercando di leggere starebbe descrivendo un livello che non esiste più.

Lo studio ha anche scoperto che il metodo "replay" è pericolosamente cieco di fronte al successo. Nei loro esperimenti, hanno osservato cinque momenti specifici in cui il cambio di pilota ha effettivamente cambiato l'esito della missione: salvando un compito fallito o perdendo uno risolto. Il vecchio metodo della "sceneggiatura cinematografica" ha mancato ogni singolo uno di questi momenti critici. Prevedeva il fallimento quando il nuovo pilota aveva invece avuto successo, e prevedeva il successo quando il nuovo pilota era fallito. La porzione di codice che il nuovo pilota ha effettivamente scritto non assomigliava affatto alla porzione che il metodo replay aveva previsto; erano essenzialmente slegate.

Inoltre, i ricercatori hanno scoperto che il "rumore" nel sistema dipende pesantemente da come i modelli vengono eseguiti. Anche utilizzando lo stesso identico modello due volte, i risultati non erano sempre identici. Se il modello veniva servito utilizzando un certo tipo di compressione hardware (FP8), le esecuzioni di "controllo" (dove non avveniva alcun cambio) divergevano il 90% delle volte. Ma con un diverso metodo di compressione (AWQ), le esecuzioni rimanevano quasi identiche. Ciò significa che anche la linea di base per il confronto è instabile, rendendo il metodo "replay" ancora meno affidabile.

L'articolo conclude che il modo attuale in cui testiamo il routing degli agenti IA sta valutando il mondo sbagliato. Il metodo "replay" è come giudicare uno chef leggendo una ricetta che ha scritto ieri, ignorando il fatto che gli ingredienti in cucina sono cambiati. L'autore suggerisce che, per comprendere davvero come indirizzare gli agenti IA, dobbiamo smettere di pretendere che il futuro sia fisso e iniziare a testare eseguendo realmente gli agenti in realtà parallele e ramificate. Hanno rilasciato i loro strumenti e i loro dati affinché altri possano smettere di tirare a indovinare e iniziare a vedere il modo vero, caotico e affascinante in cui questi agenti IA si comportano realmente quando le regole del gioco cambiano.

Sintesi Tecnica: Il Replay Gap nel Routing di Modelli Agenti

Problema
Il routing dei modelli per i Large Language Models (LLM) si è evoluto dalla selezione di query a turno singolo alla presa di decisioni per ogni step all'interno di agenti multi-step (ad esempio, ingegneria del software, uso di strumenti). Le attuali metodologie di valutazione per questi "router agentici" si affidano al replay statico: la registrazione di traiettorie generate da un modello base e la simulazione della decisione di un router sostituendo l'output registrato di un modello diverso in uno step specifico, assumendo che il resto della traiettoria rimanga invariato.

Questo articolo sostiene che tale assunzione sia fondamentalmente errata per gli agenti. A differenza delle query a turno singolo, le traiettorie degli agenti formano un ciclo chiuso dove un'azione allo step $k$ determina direttamente l'osservazione allo step $k+1$ . Il replay statico tratta implicitamente la traiettoria come un ciclo aperto, ignorando che il cambio di modello altera la distribuzione degli stati, portando a azioni future divergenti. L'articolo postula che i benchmark basati sul replay "valutino il mondo sbagliato" perché gli stati contro cui valutano non si verificano mai nello scenario controfattuale.

Metodologia: Branching Rollouts
Per misurare l'entità e la struttura di questa divergenza, l'autore introduce un protocollo di branching-rollout che va oltre il replay statico verso una valutazione controfattuale:

Setup: Gli esperimenti utilizzano lo scaffold mini-SWE-agent sul dataset SWE-bench Verified. L'ambiente è un loop ReAct minimale basato solo su bash con un budget di 50 step e un contesto di 28k token.
Modelli: Vengono utilizzati due modelli: un modello piccolo (S: Qwen3-4B-Instruct, quantizzato FP8) e un modello grande (L: Qwen3-14B, quantizzato AWQ). Entrambi sono serviti da vLLM a temperatura 0 su una singola GPU da 24GB.
Protocollo di Forking:
- Una traiettoria base viene eseguita fino al termine.
- In punti di controllo per il fork (30% e 70% della lunghezza della traiettoria), il processo si biforca in un nuovo container Docker.
- Fedeltà del Replay: Il prefisso dell'azione pre-fork viene rieseguito nel nuovo container per garantire che lo stato dell'ambiente corrisponda alla traiettoria base (verificato con un accordo del codice di ritorno del 99,99%).
- Seeding: La cronologia dei messaggi viene seminata con il prefisso registrato in modo che il modello della branca veda esattamente lo stesso contesto.
- Braccia (Arms): Ogni punto di fork genera due braccia: una braccio di swap (cambio con l'altro modello) e una braccio di controllo con lo stesso modello (continuazione con il modello base). La braccio di controllo isola il rumore derivante da campionamento, batching e replay dell'ambiente, permettendo all'autore di attribuire la divergenza specificamente al cambio di modello.
Scala: Lo studio comprende sei coppie di esecuzioni (variando difficoltà e direzione dello swap), producendo circa 900 rollout e 717 coppie di branche punteggiate.

Contributi Chiave

Metodologia: Un harness riproducibile per la valutazione controfattuale del cambio di modello per step tramite branching live, accoppiato a controlli con lo stesso modello per isolare il rumore.
Quantificazione del Replay Gap: Evidenza empirica che gli swap di modelli causano una divergenza immediata e significativa, rendendo invalido il replay statico.
Approfondimenti Strutturali: Caratterizzazione di come la divergenza dipenda dalla profondità del fork (iniziale vs tardivo) e dalla direzione dello swap (upgrade vs downgrade).
Audit del Determinismo: Una dimostrazione che il determinismo "temperatura-0" dipende dalla configurazione, con alcuni stack di serving (FP8) che introducono un rumore significativo anche nei controlli con lo stesso modello.

Risultati Chiave

Divergenza a livello di Azione: Gli swap riscrivono il 61–94% delle azioni post-fork. La distanza di edit normalizzata tra le braccia di swap e i controlli corrispondenti varia da +0,25 a +0,66 (gli intervalli di confidenza al 95% escludono lo zero).
Divergenza Immediata: Il 74–77% degli swap precoci diverge proprio alla prima azione post-fork, rispetto solo al 6–35% dei fork di controllo.
Invalidità degli Stati di Replay: Per gli swap precoci, un valutatore di replay statico punteggerebbe il 92–97% delle decisioni post-fork contro stati che non si verificano mai (solo il 3–8% degli stati riprodotti rimane valido).
Flip di Esito (Outcome Flips): Tutti e cinque i flip di esito osservati (casi in cui lo stato della soluzione è cambiato a causa dello swap) si sono verificati esclusivamente nelle braccia di swap. Zero flip si sono verificati in 359 fork di controllo. Nello specifico, gli upgrade hanno salvato istanze non risolte, mentre un downgrade ha causato la perdita dell'unica istanza risolta. Il replay statico non ha previsto nessuno di questi esiti rilevanti per il successo.
Similitudine delle Patch: Le patch predette da un valutatore di replay con stitching dei log avevano una similitudine di 0,00–0,11 con le patch effettive prodotte dal modello cambiato.
Livello di Rumore (Noise Floor): Anche i controlli con lo stesso modello non sono perfettamente deterministici. I controlli serviti con FP8 sono divergenti nel 90–96% dei fork (distanza di edit 0,49–0,67), mentre i controlli serviti con AWQ sono rimasti quasi identici (distanza di edit 0,16–0,23).
Tassa sulla Completezza (Thoroughness Tax): Sotto budget ristretti, il modello più forte (14B) ha esaurito il proprio budget di step senza sottomettere una soluzione più spesso del modello più debole (4B), suggerendo una "tassa sulla completezza" che i router consapevoli del budget devono considerare.

Significatività e Rivendicazioni
L'articolo sostiene che i benchmark basati sul replay valutano il mondo sbagliato per il routing agentico. La cecità strutturale del replay statico impedisce di osservare i flip di esito e di valutare le decisioni rispetto a stati validi.

Per la Valutazione: L'autore afferma che i benchmark per il routing agentico devono adottare una valutazione live o ramificata. Fornisce il proprio harness e dataset come punto di partenza per validare gli stimatori off-policy (ad esempio, importance sampling, stimatori doubly robust) che sono proposti come correzioni necessarie per lo shift della distribuzione.
Per le Politiche di Routing: I risultati suggeriscono che la posizione e la direzione del fork sono caratteristiche critiche: i passaggi di mano dovrebbero avvenire tardi per i downgrade (per ereditare il lavoro completato) e presto per gli upgrade (per capitalizzare su decisioni immediate).
Modestia: L'autore dichiara esplicitamente che le sue scoperte si basano su un pilota controllato (uno scaffold specifico, stack di quantizzazione specifici, bassi tassi di risoluzione) e non rivendica ancora di aver dimostrato il declassamento (mis-ranking) end-to-end dei router in "regimi competenti". Inquadra il proprio lavoro come l'instaurazione dell'invalidità degli input alla valutazione del replay piuttosto che la prova di una specifica strategia di routing superiore. L'articolo conclude che il segno del risultato (il replay è errato) è uniforme, ma la magnitudo dell'errore in regimi ad alte prestazioni richiede ulteriore validazione.

Sintesi Tecnica: Il Replay Gap nel Routing di Modelli Agenti

Articoli simili