I test di coerenza degli agenti IBM rivelano perché un solo successo non basta

I test di coerenza degli agenti IBM hanno messo in luce un netto conflitto tra il successo nei benchmark e un comportamento affidabile. Un agente GPT-4.1 ha completato il 77,4% delle sue esecuzioni AppWorld, ma ha superato tutti e cinque i tentativi soltanto nel 53,0% delle attività.

Questo divario di 24,4 punti cambia il significato di una dimostrazione di successo di un agente. Una singola esecuzione corretta può dimostrare che un agente possiede la capacità richiesta. Non può dimostrare che gli utenti otterranno lo stesso risultato domani, o persino cinque minuti dopo.

IBM Research affronta questa distinzione con nuove linee guida sulla coerenza in ALTK-Evolve. Il sistema individua decisioni instabili in una traiettoria registrata dell'agente, quindi trasforma tali debolezze in istruzioni riutilizzabili. I primi risultati suggeriscono che i miglioramenti dell'affidabilità non richiedono sempre un modello più grande.

Il lavoro mette inoltre sotto pressione il modo standard in cui i fornitori presentano le prestazioni degli agenti. Una media in classifica può premiare un agente che funziona spesso, nascondendo però quanto frequentemente fallisca dopo aver avuto successo in precedenza.

I risultati sulla coerenza degli agenti IBM evidenziano la metrica mancante

La conclusione centrale di IBM è che l'accuratezza media e il successo ripetibile descrivono due prodotti sostanzialmente diversi.

I ricercatori hanno testato un agente ReAct basato su GPT-4.1 su 168 attività della suddivisione test_normal di AppWorld. ReAct è un'architettura di agente che alterna passaggi di ragionamento e azioni, come chiamare un'applicazione o cercare informazioni archiviate.

Ogni attività ha ricevuto cinque nuove esecuzioni. Secondo lo studio IBM sulla coerenza, l'agente di base ha ottenuto un punteggio Mean@5 del 77,4%. Mean@5 calcola la media del tasso di successo su cinque tentativi.

Questa cifra sembra adatta a una solida dimostrazione di prodotto. Tuttavia, l'agente ha ottenuto un punteggio Pass^5 di appena il 53,0%. Pass^5 considera un'attività riuscita soltanto quando hanno successo tutti e cinque i tentativi.

La differenza tra questi risultati è il divario di coerenza. In questo caso ha raggiunto 24,4 punti percentuali. Sul gruppo di attività più difficile, IBM afferma che il divario ha raggiunto 30 punti.

Questa distinzione è importante perché Pass^5 non corrisponde alla più nota metrica Pass@5 usata in alcune valutazioni di coding. Pass@5 chiede se almeno uno dei cinque tentativi ha successo. Pass^5 chiede se ogni tentativo ha successo.

Queste metriche supportano prodotti diversi. Pass@5 funziona quando un sistema può generare più candidati, testarli e conservare il vincitore. Pass^5 si adatta ai flussi di lavoro in cui ogni esecuzione deve essere affidabile.

Uno sviluppatore che chiede a un agente cinque possibili patch di codice può trarre vantaggio da una risposta valida. Un team contabile che chiede a un agente di riconciliare una transazione non può accettare in sicurezza quattro esecuzioni corrette e un errore dannoso.

Lo stesso problema si applica all'analisi dei contratti. Un agente che identifica un obbligo durante una revisione ma lo trascura durante un'altra non è semplicemente variabile. Produce decisioni aziendali incoerenti a partire da prove identiche.

I risultati di IBM non dimostrano che GPT-4.1 non sia in grado di svolgere queste attività. Una media del 77,4% stabilisce che spesso può farlo. I risultati mostrano che la capacità non ha resistito in modo affidabile alla ripetizione all'interno di questa particolare configurazione dell'agente.

Questo è il ribaltamento centrale dell'articolo. Il primo successo è una prova di possibilità, non una prova di affidabilità operativa.

La più ampia comunità di valutazione è giunta a una conclusione simile. Le linee guida di Anthropic per la valutazione degli agenti distinguono Pass@k da Pass^k e raccomandano di adattare la metrica ai requisiti del prodotto.

Anthropic offre un'illustrazione semplice. Un'attività con un tasso di successo per prova del 75% ha circa il 42% di probabilità di riuscire in tre prove indipendenti. La qualità apparente diminuisce perché il requisito cambia dal successo occasionale al successo ininterrotto.

Le medie mantengono comunque valore. Aiutano a confrontare la capacità complessiva e rivelano se una modifica migliora i risultati su un insieme di attività. Diventano fuorvianti quando gli acquirenti le interpretano come una garanzia di affidabilità.

Per le implementazioni aziendali, entrambi i numeri appartengono alla valutazione. Mean@k indica ai team quanto spesso un agente funziona. Pass^k indica quante attività rimangono affidabili nell'uso ripetuto.

Perché un agente può cambiare rotta con temperatura zero

Un agente può diventare incoerente anche quando prompt, modello, strumenti e temperatura di decodifica sembrano invariati.

Un LLM sceglie ogni token successivo da una distribuzione di probabilità. Alcune decisioni hanno un favorito netto, mentre altre contengono diverse opzioni quasi a pari merito.

IBM le descrive come decisioni nette e piatte. Una distribuzione netta concentra la maggior parte della probabilità su una scelta. È improbabile che piccoli cambiamenti computazionali alterino il vincitore.

Una distribuzione piatta distribuisce la probabilità tra diverse scelte plausibili. Un minuscolo spostamento numerico può cambiare quale token arriva per primo, indirizzando l'agente su un percorso diverso.

Questa differenza diventa importante nei sistemi che usano strumenti. Un singolo token alterato può cambiare la selezione di un'API, una query di ricerca, un argomento dello strumento, una decisione di ripetere il tentativo o l'interpretazione di un risultato intermedio.

Un normale chatbot può assorbire una certa variazione nella formulazione senza cambiarne il significato finale. Un agente agisce in base alle proprie scelte intermedie. Ogni scelta modificata cambia le informazioni disponibili al passaggio successivo.

Il rischio si accumula lungo una traiettoria estesa. Se un agente prende decine di decisioni, diverse possono trovarsi vicino a confini instabili. Ne basta una sola invertita perché una chiamata a uno strumento successiva o la risposta finale falliscano.

IBM ha eseguito il proprio agente ReAct a temperatura 0,0. I ricercatori sostengono quindi che il normale campionamento non abbia causato la variabilità osservata.

La temperatura zero non rende ogni esecuzione di un modello ospitato matematicamente identica. Il batching delle richieste, il comportamento dell'hardware, le operazioni in virgola mobile e i dettagli di implementazione lato provider possono modificare leggermente le probabilità.

Questi spostamenti spesso restano invisibili nella normale generazione di testo. Diventano rilevanti quando due scelte sono quasi a pari merito. Una lieve modifica può invertirne l'ordine, nonostante la richiesta dell'utente non cambi.

Anche un seed fisso ha dei limiti. Controlla una parte del processo di generazione, ma non blocca ogni livello di un sistema di inferenza remoto. Né rende più netta una decisione incerta.

Questo meccanismo spiega perché una prova riuscita possa fallire durante una dimostrazione dal vivo. L'agente non ha necessariamente dimenticato l'attività. È entrato in un ramo diverso dello stesso albero decisionale.

Si consideri un agente a cui viene chiesto di contare le attività completate in una nota. In un'esecuzione potrebbe contare ogni marcatore di checkbox. In un'altra potrebbe contare anche una legenda che spiega il formato delle checkbox.

Entrambi i percorsi possono inizialmente sembrare ragionevoli. Solo uno produce il totale previsto. L'errore nasce da una decisione irrisolta su come interpretare il documento, non dalla mancanza di accesso alla nota.

I flussi di lavoro più lunghi amplificano questo comportamento. Un agente di ricerca potrebbe scegliere una fonte diversa, fraintendere una data ambigua o fermarsi dopo il primo documento corrispondente. Ogni scelta plasma tutto ciò che segue.

Questo rende l'affidabilità degli agenti AI in parte un problema di orchestrazione. Un modello di base migliore può aumentare la probabilità di prendere buone decisioni, ma non garantisce che le sue scelte al limite scompaiano.

Le condizioni esterne aggiungono un ulteriore livello. ReliabilityBench valuta l'esecuzione ripetuta insieme a richieste parafrasate e guasti degli strumenti. Il suo framework di stress per la produzione tratta coerenza, robustezza e tolleranza ai guasti come dimensioni separate.

L'esperimento attuale di IBM isola più strettamente le esecuzioni ripetute. Questo approccio rende più facile esaminare il divario di coerenza, ma non rappresenta ogni guasto di produzione che un agente incontrerà.

Le implementazioni reali affrontano dati modificati, credenziali scadute, limiti di frequenza delle API, risposte parziali e schemi in evoluzione. Un comportamento stabile a fronte di input identici è quindi un requisito iniziale, non l'intero standard di affidabilità.

ALTK-Evolve trasforma l'incertezza in indicazioni mirate

ALTK-Evolve cerca di correggere decisioni instabili senza rieseguire ogni attività in un ambiente live.

Il nuovo processo inizia con una traiettoria registrata. Una traiettoria è il registro ordinato di prompt, decisioni, chiamate agli strumenti, osservazioni e risposte prodotte durante l'esecuzione di un agente.

Il Consistency Analyzer di IBM riesamina ogni punto decisionale utilizzando il contesto già archiviato in quella traccia. Richiede diverse completamenti alternativi e misura quanto varia la scelta del modello.

La configurazione predefinita genera cinque completamenti tramite un'ulteriore chiamata al modello per ogni fase decisionale. Non ripete le chiamate agli strumenti esterni né riesegue l'intera attività.

Questo design è importante in produzione. Una riproduzione completa potrebbe inviare un'altra email, modificare due volte un record, duplicare un acquisto o incontrare dati già cambiati.

Il ricampionamento offline evita questi effetti collaterali. Elimina inoltre la necessità di un'etichetta ground truth durante la fase diagnostica.

L'analizzatore è una black box, ossia non richiede logits del modello né accesso interno. I team possono applicarlo a un modello ospitato se dispongono della traccia originale e possono inviare nuovamente i relativi contesti decisionali.

Ogni decisione riceve un punteggio di coerenza. I passaggi con completamenti divergenti diventano candidati per indicazioni aggiuntive.

ALTK-Evolve trasforma quindi questi candidati in istruzioni comportamentali concise. Il suo scopo più ampio è estrarre insegnamenti utili dalle traiettorie precedenti e recuperarli durante le attività successive.

Per l'esempio del conteggio delle note, le indicazioni generate consigliavano un'espressione regolare ancorata alla riga anziché un semplice conteggio di sottostringhe. Istruivano inoltre l'agente a esaminare più risultati di ricerca prima di selezionare una nota.

Queste istruzioni affrontano schemi di fallimento generali. Non si limitano a salvare la risposta numerica corretta dell'attività originale.

Questa differenza è essenziale. Memorizzare una risposta migliorerebbe un elemento del benchmark senza rafforzare l'agente. Una regola riutilizzabile può aiutare con nuove note, diversi formati di checkbox o decisioni di ricerca correlate.

Il repository ALTK-Evolve include ora il Consistency Analyzer e i componenti per la generazione delle linee guida. Il progetto usa una licenza Apache 2.0 e supporta l'integrazione tramite il Model Context Protocol.

Il suo livello di recupero inserisce le linee guida pertinenti nel contesto dell'agente al momento dell'inferenza. Questo fornisce al modello promemoria mirati senza richiedere che ogni traccia storica rimanga nel prompt attivo.

L'approccio ricorda una forma mirata di memoria operativa. Invece di chiedere all'agente di rileggere tutto ciò che ha fatto, il sistema distilla insegnamenti ricorrenti e recupera quelli associati all'attività corrente.

Questa distinzione conta anche per il lavoro basato sulla conoscenza. Un archivio più grande non produce automaticamente decisioni migliori. Una memoria utile richiede selezione, gestione dei conflitti e un contesto appropriato alla richiesta attiva.

Lo stesso principio è alla base di una knowledge base AI ben strutturata. Il materiale archiviato diventa prezioso quando un sistema può recuperare le prove giuste senza inondare il contesto di lavoro.

Il metodo di ALTK-Evolve è più ristretto rispetto a una piattaforma di conoscenza generale. Mira al comportamento degli agenti e utilizza linee guida derivate dalle traiettorie. Tuttavia, entrambi i casi evidenziano lo stesso vincolo: conservare informazioni è più facile che applicare le informazioni giuste nel momento giusto.

Il meccanismo crea anche un ciclo di feedback. I team possono raccogliere tracce, rilevare passaggi instabili, generare indicazioni candidate e valutare se tali indicazioni migliorano le esecuzioni successive.

Tuttavia, il sistema non elimina la necessità di test. Una regola generata può essere errata, eccessivamente ampia o dannosa al di fuori della situazione che l'ha prodotta.

I team hanno comunque bisogno di versionamento e rollback. Devono inoltre tracciare quale linea guida ha influenzato una decisione, soprattutto quando un agente svolge attività regolamentate o con conseguenze finanziarie.

Il guadagno in affidabilità è ampio, ma le evidenze sono circoscritte

IBM riporta un miglioramento sostanziale, sebbene lo studio resti una valutazione iniziale su una configurazione di benchmark principale.

Dopo l'aggiunta delle linee guida di coerenza, Pass^5 è aumentato dal 53,0% al 69,0% sui 168 task di AppWorld. Ciò rappresenta un miglioramento di 16 punti nei task superati in tutte e cinque le esecuzioni.

Anche Mean@5 è salito, passando dal 77,4% all'81,0%. Il divario di coerenza si è quindi ridotto da 24,4 punti a 12,0 punti.

Questo risultato è importante perché la media non è diminuita. Un metodo che migliorasse la ripetibilità costringendo l'agente a una strategia costantemente mediocre non risolverebbe il problema di fondo.

IBM afferma che le linee guida hanno mantenuto o migliorato Mean@5 a ogni livello di difficoltà. Il gruppo di difficoltà media ha guadagnato 22,9 punti in Pass^5, mentre il gruppo difficile ha guadagnato 14,3 punti.

I guadagni relativi sono stati del 44% per i task medi e del 45% per quelli difficili. I task facili hanno guadagnato 12,2 punti, con minori margini di miglioramento.

IBM ha inoltre testato le linee guida su un task diverso ma correlato nello stesso scenario AppWorld. Pass^5 è aumentato di 13 punti, rispetto al guadagno di 16 punti sullo stesso task.

Il risultato sostiene l'affermazione secondo cui alcune linee guida si trasferiscono oltre una singola traiettoria registrata. Non dimostra una generalizzazione ampia tra applicazioni, settori o architetture di agenti non correlate.

Un secondo esperimento ha utilizzato gpt-oss-120b. Il suo Pass^5 sullo stesso task è aumentato dal 10,1% al 16,1%, mentre la performance su task simili ha guadagnato 8,7 punti.

La base di partenza più debole mostra che le indicazioni non possono sostituire completamente la capacità. Un miglioramento di sei punti è significativo, ma un tasso di successo su tutte le esecuzioni del 16,1% resta inadeguato per l'automazione con conseguenze rilevanti.

Il rapporto tecnico completo illustra la metodologia alla base di queste affermazioni. Ciononostante, i lettori dovrebbero considerare i risultati come evidenze provenienti dalla valutazione degli autori, non come conferme indipendenti su sistemi di produzione.

Il test principale utilizza una configurazione ReAct, una suddivisione principale del benchmark e cinque ripetizioni per task. AppWorld offre scenari realistici multi-applicazione, ma un benchmark rimane un ambiente controllato.

Cinque esecuzioni rivelano un'instabilità che una sola esecuzione nasconde. Non stimano con precisione i fallimenti rari che potrebbero emergere in migliaia di interazioni con i clienti.

La valutazione solleva anche una questione statistica. Pass^k diminuisce naturalmente all'aumentare di k, perché ogni prova aggiuntiva crea un'altra occasione di fallimento.

Un team di prodotto deve quindi scegliere k in base all'esposizione effettiva. Cinque esecuzioni riuscite possono costituire un ragionevole filtro di sviluppo. Non dimostrano l'affidabilità su scala enterprise.

Anche le linee guida possono diventare obsolete. Le API cambiano, le policy evolvono e le soluzioni alternative precedenti possono entrare in conflitto con il nuovo comportamento del sistema.

Una regola derivata da un ramo instabile potrebbe sopprimere un'alternativa valida altrove. Più linee guida accumula un sistema, più diventano importanti la risoluzione dei conflitti e la qualità del recupero delle informazioni.

Esiste inoltre una differenza tra comportamento coerente e comportamento corretto. Un agente che ripete la stessa azione sbagliata ha una stabilità comportamentale perfetta e valore nullo per il task.

L'esperimento di IBM tutela da questo problema riportando Mean@5 insieme a Pass^5. I team di produzione dovrebbero mantenere lo stesso abbinamento e aggiungere misure di sicurezza specifiche per gli esiti.

Per i flussi di lavoro sensibili, la correttezza coerente deve essere l'obiettivo. La sola stabilità non dovrebbe mai sostituire accuratezza fattuale, conformità alle policy, controlli di autorizzazione o revisione umana.

I modelli più grandi ora affrontano un concorrente a livello di sistema

Le nuove evidenze mettono in discussione l'assunto secondo cui i problemi di affidabilità debbano essere risolti anzitutto sostituendo il modello sottostante.

Gli aggiornamenti dei modelli restano interessanti perché possono migliorare molti task contemporaneamente. Richiedono inoltre una diagnosi meno personalizzata rispetto alla ricostruzione del sistema di memoria o valutazione di un agente.

Tuttavia, un modello più grande non rivela dove un agente esistente diventa instabile. Può aumentare la performance media lasciando al contempo un divario significativo tra successo occasionale e successo ripetuto.

L'approccio di IBM rappresenta una strada concorrente. Invece di modificare il modello, modifica le informazioni fornite nei punti decisionali ad alto rischio.

Il confronto non è strettamente tra modello e memoria. I sistemi più solidi utilizzeranno insieme modelli capaci, strumenti ben progettati, contesto mirato, controlli deterministici e valutazioni ripetute.

La pressione ricade sui fornitori di agenti e sugli acquirenti enterprise che riportano ancora un singolo tasso di successo. Una volta che Pass^k entra nelle discussioni di procurement, una media elevata diventa solo una parte dell'evidenza.

Gli acquirenti possono chiedere se lo stesso task sia stato ripetuto, se l'ambiente sia stato reimpostato e se ogni esecuzione abbia raggiunto un risultato accettabile. Possono inoltre richiedere risultati per difficoltà invece di un unico valore aggregato.

Gli sviluppatori affrontano un cambiamento correlato. Una segnalazione di bug che afferma che un agente ha fallito una volta potrebbe non riprodursi più su richiesta. I team necessitano di tracce complete per individuare la decisione precedente che ha deviato.

L'osservabilità diventa parte della qualità del prodotto. Senza prompt memorizzati, argomenti degli strumenti, risultati e scelte intermedie, un'esecuzione instabile può scomparire senza spiegare se stessa.

Questo rende importante l'architettura di valutazione prima della distribuzione. I team necessitano di task rappresentativi, stati iniziali controllati, criteri di successo espliciti e un numero sufficiente di ripetizioni per far emergere la variabilità.

Devono inoltre separare il lavoro ripetibile dalle azioni una tantum. La generazione di una bozza può tollerare più tentativi. L'invio di un pagamento, l'eliminazione di un file o l'approvazione di un contratto richiedono controlli più rigorosi.

Pass@k è adatto al primo gruppo quando gli output possono essere verificati automaticamente. Pass^k è più informativo per il secondo gruppo, in particolare quando gli utenti si aspettano che il primo risultato sia sicuro.

Alcuni flussi di lavoro non dovrebbero basarsi soltanto su nessuna delle due metriche. Un agente transazionale necessita anche di limiti di autorizzazione, controlli di idempotenza, registri di audit e convalida deterministica prima di eseguire un'azione irreversibile.

Le linee guida possono ridurre il ragionamento incerto, ma non sostituiscono queste salvaguardie. Un agente affidabile è una proprietà del sistema, non un punteggio del modello.

I risultati rafforzano inoltre l'argomentazione a favore di un contesto di lavoro curato. I team usano già il knowledge blending per collegare le evidenze archiviate al lavoro attivo. Le linee guida per gli agenti applicano un'idea simile alle lezioni comportamentali.

La chiave è la moderazione. Un maggiore contesto recuperato può creare distrazioni, contraddizioni e latenza aggiuntiva. Un'istruzione mirata ha valore solo quando raggiunge il task corretto e non sostituisce evidenze essenziali.

È qui che risiede la sfida di lungo periodo di ALTK-Evolve. La sua diagnostica può identificare decisioni variabili, ma il sistema circostante deve gestire una raccolta crescente di lezioni.

Un'implementazione riuscita richiederà policy di scadenza, rilevamento dei conflitti, provenienza e valutazioni per le modifiche alle linee guida. In caso contrario, la correzione di ieri può diventare la fonte nascosta di fallimenti di domani.

Cosa mostrerà se l'approccio di IBM regge nel tempo

Tre segnali determineranno se le linee guida di coerenza diventeranno un livello standard degli agenti o rimarranno una promettente tecnica di benchmark.

Il primo segnale è la riproduzione indipendente su altri benchmark e architetture di agenti. I ricercatori dovrebbero testare il metodo su agenti browser, agenti di coding, sistemi di assistenza clienti e flussi di lavoro con reali fallimenti delle API.

Una replica del miglioramento di 16 punti in Pass^5 rafforzerebbe l'affermazione centrale di IBM. Guadagni minori o incoerenti suggerirebbero che AppWorld contiene schemi di fallimento particolarmente adatti alla correzione tramite linee guida.

I confronti dovrebbero includere diversi modelli di base. Dovrebbero inoltre riportare l'uso di token, la latenza, il costo dell'analizzatore, il sovraccarico di recupero e il numero di linee guida iniettate per task.

Il secondo segnale è la performance su periodi più lunghi. Un sistema di apprendimento utile deve gestire nuove indicazioni senza accumulare regole in conflitto o obsolete.

I team dovrebbero misurare se il beneficio sopravvive dopo centinaia o migliaia di traiettorie. Dovrebbero inoltre verificare se il recupero delle linee guida resta preciso man mano che l'archivio cresce.

Occorre osservare le valutazioni che congelano un insieme di linee guida e lo testano rispetto a versioni successive delle applicazioni. Una performance solida mostrerebbe che le regole catturano comportamenti durevoli. Un rapido deterioramento rivelerebbe un onere di manutenzione.

Il terzo segnale è l'adozione della rendicontazione delle esecuzioni ripetute. Le schede di valutazione dei fornitori dovrebbero pubblicare Mean@k e Pass^k insieme, indicando chiaramente k.

Questo cambiamento consentirebbe agli acquirenti di distinguere i modelli che riescono spesso dai sistemi che riescono in modo affidabile. Scoraggerebbe inoltre dimostrazioni costruite attorno a una sola esecuzione favorevole.

Il settore dovrebbe andare oltre, combinando la ripetizione con parafrasi e fallimenti controllati degli strumenti. Prompt identici rappresentano solo un tipo di pressione in produzione.

Il lavoro di IBM sostiene in modo convincente che una sola esecuzione riuscita sia uno standard troppo debole. Offre inoltre un metodo pratico per individuare l'incertezza senza ripetere ogni azione nel mondo reale.

La questione rimanente è se questi guadagni persistano al di fuori del contesto di ricerca. Gli sviluppatori possono rispondervi rieseguendo i propri flussi di lavoro importanti, conservando tracce complete e misurando il successo in tutte le esecuzioni.

Se il vostro agente gestisce attività con conseguenze rilevanti, non chiedetevi soltanto se ha completato il task. Chiedetevi con quale frequenza completa correttamente lo stesso task, quali decisioni variano e cosa accade quando le indicazioni di ieri incontrano le condizioni di domani.