Amazon AWS trasforma la valutazione degli agenti in un gate di produzione con Strands e AgentCore

Amazon AWS e Motorway hanno realizzato una pipeline di valutazione che ha ridotto i risultati errati degli agenti da una query su otto a una su 50. Secondo le aziende, il sistema ha inoltre ridotto il rilevamento dei problemi da alcune ore a pochi minuti.

Questi miglioramenti non sono arrivati semplicemente sostituendo il modello sottostante. Motorway ha invece cambiato il modo in cui il proprio agente per la ricerca di stock dei concessionari viene testato, rilasciato e monitorato. La pipeline combina Strands Agents SDK con Amazon Bedrock AgentCore Evaluations, lungo sviluppo e produzione.

La distinzione è importante perché risposte fluide possono nascondere azioni difettose. Un agente potrebbe presentare un elenco di veicoli convincente dopo aver selezionato lo strumento sbagliato, inviato parametri errati o perso un vincolo precedente. I test software tradizionali raramente catturano ogni risposta valida, mentre la revisione manuale individua i guasti troppo lentamente.

Il caso Motorway trasforma la valutazione degli agenti da controllo qualità finale a ciclo operativo. Strands testa scenari controllati prima del deployment. AgentCore valuta tracce di produzione campionate dopo il deployment. I fallimenti diventano quindi nuovi casi di regressione per la release successiva.

Il risultato mette sotto pressione i team che giudicano ancora gli agenti in base a demo, valutazioni aggregate degli utenti o pochi prompt predefiniti. Solleva inoltre una domanda più difficile per AWS: quanta fiducia dovrebbero riporre gli acquirenti in valutazioni che spesso dipendono da un altro modello linguistico?

Amazon AWS porta la valutazione nella pipeline di rilascio

Il cambiamento importante non è una nuova scorecard. La valutazione ora determina se un agente arriva in produzione e con quale rapidità i team rilevano le regressioni in seguito.

Motorway gestisce un marketplace online che mette in contatto i venditori di veicoli con concessionari professionali. Il suo agente per la ricerca di stock dei concessionari gestisce richieste in linguaggio naturale relative ad attributi dei veicoli, area geografica, chilometraggio, prezzo e altri vincoli.

Una richiesta può sembrare riuscita pur essendo operativamente errata. L'agente potrebbe cercare nella fonte di inventario sbagliata, omettere un filtro o passare un valore non valido a uno strumento. La risposta finale può restare sufficientemente curata da non essere notata subito né dall'utente né da un controllo testuale di base.

Motorway e AWS hanno affrontato questa lacuna con un modello di valutazione a tre livelli. Il primo livello controlla la selezione degli strumenti e i parametri. Il secondo esamina la traiettoria di ragionamento dell'agente, ovvero la sequenza di decisioni e chiamate agli strumenti alla base di una risposta. Il terzo valuta l'output finale per qualità e conformità alle policy.

Questa separazione è importante perché una risposta accettabile non dimostra che l'agente abbia seguito un percorso sicuro o ripetibile. Una risposta fortunata può nascondere una traiettoria errata. Al contrario, un agente può scegliere gli strumenti corretti ma produrre una risposta finale confusa.

AWS riferisce che l'accuratezza nella selezione degli strumenti di Motorway è salita dall'87% al 98%. Il completamento delle attività è passato dall'82% al 96%, mentre la conservazione del contesto multi-turn è aumentata dal 71% al 94%.

Gli incidenti mensili in produzione sono scesi da 12 a due. Il tempo medio di rilevamento è diminuito da alcune ore a pochi minuti. AWS afferma che i concessionari ora completano le ricerche di veicoli in pochi minuti invece di dedicare ore al processo.

Si tratta di risultati riportati dalle aziende per un singolo deployment, non di un benchmark di settore indipendente. Tuttavia, le misurazioni mostrano perché i team che sviluppano agenti abbiano bisogno di più di un singolo valore di accuratezza.

L'architettura assegna soglie diverse a diverse classi di errore. AWS raccomanda un utilizzo degli strumenti superiore al 95%, un ragionamento superiore all'85% e una qualità dell'output superiore al 90% nel suo production blueprint.

Una build che scende sotto questi gate non avanza. Questo rende la valutazione parte del controllo dei rilasci, paragonabile a un test di integrazione o a un controllo di sicurezza. Il monitoraggio in produzione verifica poi se il comportamento approvato resiste al contatto con gli utenti reali.

Questo crea la tensione centrale dell'articolo. La valutazione degli agenti promette affidabilità misurabile, ma i comportamenti più utili non possono sempre essere verificati con asserzioni deterministiche. La pipeline combina quindi controlli esatti con giudici probabilistici.

Perché l'affidabilità degli agenti mette sotto pressione i team di produzione

I team che sviluppano agenti sono ora responsabili di decisioni e azioni, non solo del testo generato, rendendo incompleti i test convenzionali sui modelli.

Un chatbot restituisce di norma testo che una persona può revisionare. Un agente può recuperare record, chiamare sistemi aziendali, modificare dati o attivare un altro workflow. Il rischio operativo si sposta da una frase imperfetta a un'azione errata.

Questo cambiamento mette sotto pressione i responsabili tecnici, i product owner e gli acquirenti aziendali. Devono sapere se un agente ha scelto lo strumento giusto, fornito parametri validi, rispettato le istruzioni precedenti e completato l'attività prevista.

Un singolo punteggio medio non può rispondere a queste domande. Due release possono avere la stessa valutazione di qualità dell'output pur mostrando comportamenti degli strumenti molto diversi. Una potrebbe fallire in modo innocuo nella formulazione, mentre l'altra recupera record obsoleti o non pertinenti.

La non determinismo aggrava il problema. I modelli linguistici possono produrre percorsi diversi per la stessa richiesta. Un test che passa una volta non dimostra che l'agente ripeterà il risultato.

AWS evidenzia questo problema attraverso pass^k, una misura di affidabilità che chiede se un'attività riesce in prove ripetute. Se un'attività riesce il 75% delle volte, la probabilità di tre successi consecutivi è solo di circa il 42%.

Questo calcolo cambia il modo in cui i team dovrebbero interpretare le dimostrazioni. Una demo riuscita dimostra che un sistema può completare un'attività. Non dimostra che il sistema la completi con una coerenza sufficiente per la produzione.

La sfida cresce nelle conversazioni multi-turn. Un utente potrebbe prima richiedere veicoli elettrici, poi restringere i risultati in base alla distanza e in seguito chiedere solo annunci recenti. L'agente deve conservare il contesto pertinente senza mantenere vincoli che l'utente ha ritirato.

Strands Evals tratta questo come un problema di sessione anziché come un punteggio di prompt isolati. I suoi valutatori possono esaminare output, traiettorie, singole chiamate agli strumenti e conversazioni complete. La guida alla valutazione del framework raccomanda inoltre di monitorare accuratezza, completamento delle attività, tempo di risposta, allucinazioni, utilizzo dei token e soddisfazione degli utenti.

Anche i team di produzione affrontano pressioni organizzative. Un fallimento dell'agente può attraversare confini tra applicazione, modello, dati e infrastruttura. Un product manager vede un risultato errato, mentre la causa principale potrebbe essere una modifica del prompt, lo schema di uno strumento, un indice obsoleto, un timeout o un aggiornamento del modello.

Senza tracce, i team discutono della risposta visibile. Con tracce strutturate, possono verificare quali strumenti fossero disponibili, cosa abbia selezionato l'agente, quali parametri abbia inviato e come ogni passaggio abbia contribuito alla risposta.

Per questo valutazione e osservabilità devono lavorare insieme. La valutazione decide se un comportamento soddisfa uno standard definito. L'osservabilità registra le prove necessarie per capire perché abbia superato o fallito il controllo.

I risultati di Motorway suggeriscono che questo approccio combinato possa ridurre il tempo di rilevamento. Non dimostrano che ogni organizzazione vedrà lo stesso miglioramento. I benefici dipendono dalla qualità delle tracce, dalla progettazione della valutazione, dai modelli di traffico e dalle conseguenze associate a un punteggio negativo.

Tuttavia, l'onere della prova si è spostato. I team che implementano agenti nei workflow dei clienti hanno sempre più bisogno di prove ripetibili, non di una raccolta di trascrizioni persuasive.

Come funziona il meccanismo di Strands e AgentCore

Strands gestisce la valutazione controllata prima del rilascio, mentre AgentCore estende lo stesso modello di qualità al traffico di produzione campionato.

Strands Agents SDK fornisce il framework utilizzato per creare e strumentare l'agente. Strands Evals organizza i test in casi, esperimenti, funzioni di attività e valutatori.

Un caso definisce uno scenario, inclusi l'input e qualsiasi output previsto o traiettoria degli strumenti. Un esperimento raggruppa i casi ed esegue uno o più valutatori. Una funzione di attività collega questi casi a un agente attivo o a dati di esecuzione acquisiti in precedenza.

Questa struttura supporta due modelli di test. I test online invocano l'agente durante un'esecuzione di valutazione, risultando adatti allo sviluppo e all'integrazione continua. I test offline valutano tracce registrate, aiutando a confrontare versioni o a studiare il comportamento storico in produzione.

La pipeline di Motorway inizia con scenari selezionati che rappresentano le comuni ricerche dei concessionari e i casi limite noti. Ogni esecuzione acquisisce la risposta dell'agente e il percorso utilizzato per produrla.

Il livello degli strumenti chiede se l'agente abbia selezionato la capacità corretta e fornito parametri appropriati. Questo livello può rilevare una richiesta di ricerca inviata alla fonte dati sbagliata o un filtro espresso in un formato non valido.

Il livello di ragionamento esamina la traiettoria. Cerca decisioni coerenti lungo l'intera sequenza anziché giudicare una chiamata agli strumenti in modo indipendente. Questo è importante quando un risultato valido richiede diverse azioni dipendenti.

Il livello dell'output valuta la risposta presentata all'utente. Può analizzare qualità come pertinenza, completezza, sicurezza e grounding. Questo livello finale resta necessario perché un'esecuzione interna corretta può comunque produrre una risposta poco chiara.

Questi controlli di sviluppo agiscono come gate di rilascio. Il team può confrontare una modifica proposta al modello, al prompt, alla definizione dello strumento o all'orchestrazione rispetto a un set di test consolidato. Una regressione blocca la promozione prima che i clienti la incontrino.

Dopo il deployment, AgentCore Evaluations legge le tracce OpenTelemetry. OpenTelemetry è uno standard aperto per registrare operazioni nelle applicazioni distribuite. Le sue convenzioni per l'AI generativa possono acquisire prompt, completamenti, impostazioni del modello, chiamate agli strumenti e dettagli di esecuzione correlati.

Questo formato di traccia comune riduce la dipendenza da un singolo framework per agenti. La documentazione AWS afferma che AgentCore supporta agenti Strands e LangGraph strumentati con OpenTelemetry o OpenInference.

AgentCore offre valutazioni on-demand e online. La valutazione on-demand assegna un punteggio a tracce o sessioni selezionate durante lo sviluppo e i test di rilascio. La valutazione online campiona il traffico live e invia i risultati ai workflow di monitoraggio.

Il servizio può applicare valutatori integrati, giudici personalizzati basati su modelli linguistici, confronti con ground truth o valutatori di codice basati su Lambda. La documentazione di AgentCore afferma che le tracce vengono convertite in un formato unificato prima dell'assegnazione del punteggio.

I giudici basati su modelli linguistici gestiscono qualità che resistono alla corrispondenza esatta. Possono valutare se una risposta soddisfi l'obiettivo dell'utente o resti fedele al contesto disponibile.

I valutatori di codice gestiscono requisiti deterministici. Una funzione può verificare un identificatore preciso, un campo obbligatorio, un intervallo di parametri o uno schema di risposta. Questo è spesso più prevedibile che chiedere a un altro modello di controllare valori esatti.

La pipeline instrada quindi i punteggi verso dashboard e avvisi CloudWatch. Un calo della qualità può creare un incidente, attivare una revisione umana o alimentare un processo di rollback.

AWS raccomanda di iniziare il monitoraggio in produzione con un campionamento dell'1%. I team possono aumentare la copertura dopo aver compreso costi, latenza e qualità del segnale dei valutatori. Le operazioni ad alto rischio possono giustificare controlli deterministici più ampi anche quando la valutazione basata su modelli linguistici resta campionata.

I fallimenti in produzione rientrano nella suite di sviluppo. Una rara espressione di un concessionario, un pattern di timeout o un follow-up inatteso diventa un nuovo caso. Il set di test cresce quindi a partire dal comportamento reale, anziché restare una raccolta statica di prompt sintetici.

Questo ciclo di feedback è il meccanismo alla base del miglioramento riportato. Nessun singolo valutatore produce affidabilità. L'affidabilità deriva dalla conversione ripetuta dei fallimenti osservati in criteri di rilascio misurabili.

La vera sfida è tra evidenza e intuizione

La pipeline di Motorway mette in discussione una comune abitudine nello sviluppo degli agenti: modificare i prompt a intuito e validarli con una manciata di esempi favorevoli.

L'iterazione sui prompt è rapida, e questo favorisce una revisione informale. Uno sviluppatore individua una risposta debole, modifica un'istruzione, testa alcuni prompt e rilascia quello che sembra un miglioramento.

Questo processo può risolvere il caso visibile danneggiando però un altro comportamento. Un'istruzione più rigida può migliorare la selezione degli strumenti ma ridurre il completamento delle attività. Un prompt più lungo può preservare il contesto aumentando però la latenza o incoraggiando chiamate non necessarie.

Il principale avversario nel blueprint di Amazon AWS non è quindi un altro provider cloud. È lo sviluppo di agenti guidato dall'intuizione, in cui i team non dispongono di baseline stabili e scoprono le regressioni attraverso i reclami dei clienti.

Gli esperimenti di Strands offrono un confronto controllato. I team possono eseguire gli stessi casi su due versioni e analizzare le modifiche per livello di valutazione. Questo rende visibili i compromessi prima di un rilascio.

AgentCore estende questo confronto alla produzione. Gli utenti reali introducono terminologia, richieste incomplete, vincoli in conflitto e condizioni temporali che i dataset curati raramente coprono. La valutazione shadow può assegnare un punteggio a queste interazioni senza modificare immediatamente il sistema rivolto agli utenti.

Questo modello assomiglia alla distribuzione software matura sotto un aspetto importante. I criteri di qualità diventano eseguibili e ripetibili. Tuttavia, la valutazione degli agenti non può semplicemente copiare le pratiche di unit testing perché esistono molti output validi.

Un'asserzione tradizionale può verificare che una funzione abbia restituito un valore specifico. Un valutatore di agenti deve spesso giudicare se una risposta sia stata sufficientemente utile, fondata o completa. Questi criteri richiedono interpretazione.

La pipeline risolve questo conflitto scegliendo il valutatore in base all'affermazione da verificare. Le regole esatte su dati e formati vengono affidate al codice. Le qualità semantiche vengono affidate a giudici basati su modelli linguistici. I percorsi degli strumenti possono usare traiettorie previste, giudizio contestuale o entrambi.

Questa distinzione dovrebbe influenzare le decisioni di acquisto. Una piattaforma che riporta un unico punteggio di qualità combinato può nascondere quale classe di fallimento sia cambiata. Gli acquirenti enterprise dovrebbero chiedere se possono esaminare i punteggi a livello di strumento, traccia e sessione.

Dovrebbero anche chiedere se le valutazioni possono seguire l'applicazione nei diversi ambienti. Un benchmark di sviluppo che scompare dopo il deployment non può rilevare cambiamenti di comportamento causati dai dati di produzione o dai pattern degli utenti.

AWS presenta AgentCore come il livello gestito per garantire questa continuità. Secondo la sua panoramica sulle valutazioni, il servizio gestisce modelli di valutazione, infrastruttura di inferenza, elaborazione dei dati e scalabilità.

Questa configurazione riduce il lavoro infrastrutturale, ma aumenta anche la dipendenza dai servizi AWS per valutazione, telemetria, dashboard e controlli di deployment. I team che operano già su AWS possono considerare questa integrazione un vantaggio.

Le organizzazioni con requisiti multi-cloud devono esaminare la portabilità. OpenTelemetry fornisce un formato di traccia trasferibile, ma dashboard, configurazioni dei valutatori, policy IAM e risposte automatizzate possono restare specifici della piattaforma.

I framework aperti offrono un'altra strada. LangSmith, Arize Phoenix, Braintrust e altri sistemi di osservabilità per agenti combinano anch'essi tracce, dataset, esperimenti e valutatori. Il confronto significativo non riguarda il numero di giudici disponibili.

La domanda migliore è se un sistema colleghi i fallimenti in produzione a test riproducibili e decisioni di rilascio. È questo ciclo chiuso che il deployment di Motorway sostiene di aver migliorato.

I team hanno inoltre bisogno di una conoscenza operativa disciplinata. I risultati delle valutazioni, le spiegazioni degli incidenti e le regole di dominio diventano più utili quando gli ingegneri possono recuperarli accanto a tracce e casi di test. Una base di conoscenza ingegneristica ricercabile può preservare questo contesto tra un rilascio e l'altro.

Cosa non dimostrano i miglioramenti di accuratezza riportati

I miglioramenti riportati sono significativi, ma non eliminano la varianza dei giudici, le lacune nel campionamento, il bias dei benchmark o la dipendenza dalla piattaforma.

La prima limitazione riguarda l'attribuzione. Motorway ha introdotto una pipeline di valutazione e ha poi riportato prestazioni migliori. I risultati pubblici non isolano quanto del miglioramento sia derivato da nuovi test, modifiche ai prompt, correzioni degli strumenti, maggiore attenzione operativa o da AgentCore stesso.

La seconda limitazione riguarda la costruzione del benchmark. Le suite di valutazione riflettono gli scenari che i team scelgono di includere. Un alto tasso di superamento può coesistere con una copertura debole se i casi sottorappresentano il linguaggio ambiguo, stati rari dell'inventario o percorsi conversazionali insoliti.

Il feedback dalla produzione riduce questo rischio ma non lo elimina. Gli utenti possono abbandonare un'interazione fallita senza segnalare il problema. L'organizzazione deve quindi ricorrere a segnali di business, come il perfezionamento della ricerca o l'abbandono dell'attività, per rilevare i fallimenti nascosti.

La terza limitazione è il campionamento. Un tasso di monitoraggio dell'1% controlla la spesa per la valutazione, ma i fallimenti poco comuni possono sfuggire all'osservazione. Le policy di campionamento dovrebbero riflettere il volume di traffico e le conseguenze, non solo una percentuale iniziale universale.

La quarta limitazione è l'affidabilità dei giudici. Un LLM-as-a-judge usa un modello linguistico per valutare il comportamento di un altro modello rispetto a una rubrica. Può introdurre bias posizionale, punteggi incoerenti o preferenze legate allo stile della risposta.

Una spiegazione dettagliata non garantisce un giudizio corretto. I team dovrebbero calibrare i giudici basati su modelli rispetto a esempi revisionati da persone e misurare periodicamente il livello di concordanza. Valutazioni ripetute possono rivelare una varianza che un singolo punteggio nasconde.

Anche le rubriche necessitano di controllo di versione. Modificare le istruzioni del valutatore può spostare i punteggi senza alcun cambiamento nell'agente. Le dashboard dovrebbero distinguere le regressioni del prodotto dalle modifiche alla misurazione.

AWS riconosce questo più ampio onere operativo nelle sue linee guida AgentOps. Il modello consigliato colloca i controlli on-demand prima del rilascio e il monitoraggio online dopo il deployment. Il suo framework AgentOps separa inoltre la telemetria di framework, servizio, infrastruttura e business.

La quinta limitazione riguarda l'interpretazione delle metriche. Portare l'accuratezza della selezione degli strumenti al 98% lascia comunque spazio agli errori. Il tasso residuo accettabile dipende da ciò che fa lo strumento.

Un filtro per veicoli mancato crea una cattiva esperienza di ricerca. Un'azione errata che riguarda un pagamento, una cartella clinica o una policy di accesso comporta un rischio diverso. I team dovrebbero definire le soglie in base alle conseguenze, anziché copiare invariati gli obiettivi di Motorway.

Anche la conservazione del contesto richiede una definizione accurata. AWS riporta un aumento dal 71% al 94%, ma le sintesi pubbliche non forniscono dettagli sufficienti per confrontare quel punteggio con il benchmark di un'altra azienda.

La sesta limitazione è la correlazione tra i valutatori. Diversi giudici possono premiare la stessa qualità superficiale, mancando però un medesimo punto cieco. AWS raccomanda criteri distinti, affinché ogni valutatore copra una dimensione separata della qualità.

La revisione umana resta importante per i fallimenti ad alto impatto e i punteggi contestati. Le persone possono identificare se una rubrica rappresenti il reale requisito di business, una decisione che un giudice automatizzato non può prendere autonomamente.

La limitazione finale riguarda gli incentivi. Quando una metrica diventa una barriera al deployment, i team possono ottimizzare per la suite di test. Casi di produzione, set di sfida a rotazione e valutazioni riservate aiutano a evitare che un sistema migliori solo sui prompt familiari.

Nessuno di questi problemi invalida i risultati di Motorway. Definiscono le condizioni necessarie per interpretarli responsabilmente. La valutazione è un sistema di misurazione, e i sistemi di misurazione necessitano a loro volta di test.

Cosa osservare dopo il blueprint di Amazon AWS

Il prossimo test è verificare se questa pipeline mantenga i suoi risultati con nuove versioni degli agenti, crescita del traffico reale e costi di valutazione.

Il primo segnale è l'andamento degli incidenti di Motorway. Il calo riportato da 12 incidenti mensili a due stabilisce una baseline. Prestazioni sostenute avvalorerebbero l'affermazione che la valutazione continua intercetti le regressioni, non soltanto una pulizia una tantum.

La composizione di questi incidenti conta quanto il loro numero. Se i fallimenti rimanenti si concentrano su linguaggio mai visto o contesto multi-turn, Motorway può ampliare i propri casi e valutatori. Errori ripetuti negli strumenti o nei parametri ridurrebbero la fiducia nelle barriere di rilascio.

Il secondo segnale è la performance pass^k sui nuovi modelli e prompt. I team dovrebbero osservare se l'affidabilità su esecuzioni ripetute resti stabile quando Motorway modifica versioni dei modelli, schemi degli strumenti o logica di orchestrazione.

Un rilascio può migliorare l'accuratezza media diventando al contempo meno coerente. Riportare il successo su prove ripetute renderebbe questa differenza più chiara di un singolo tasso di superamento.

Il terzo segnale è l'espansione del campionamento in produzione. AWS raccomanda di iniziare dall'1%, per poi scalare gradualmente. Una copertura più ampia senza costi di valutazione ingestibili rafforzerebbe il caso del servizio gestito.

Osservate se le organizzazioni combinano giudizi semantici campionati con controlli più estesi basati sul codice. Questo design ibrido può riservare i modelli linguistici alle questioni di qualità ambigue, applicando al contempo una validazione deterministica a ogni azione critica.

L'adozione di AgentCore oltre Strands metterà inoltre alla prova il valore della sua architettura basata sulle tracce. Il supporto per dati OpenTelemetry standard conta solo se i team possono migrare gli agenti e conservare una cronologia utile delle valutazioni.

La lezione più ampia è già chiara. Gli agenti in produzione hanno bisogno di un ciclo di qualità che inizi prima del rilascio e continui dopo l'arrivo degli utenti. Test, tracce, avvisi, analisi degli incidenti e nuovi casi di regressione dovrebbero costituire un unico processo connesso.

Per gli sviluppatori, l'azione pratica consiste nello scegliere un workflow ad alto valore e definirne le modalità di fallimento prima di selezionare i valutatori. Tracciate separatamente scelta dello strumento, parametri, completamento dell'attività, contesto, latenza e output finale. Quindi ripetete gli stessi casi su più prove.

Gli acquirenti enterprise dovrebbero richiedere queste evidenze durante le revisioni degli agenti. Chiedete quali comportamenti bloccano il deployment, come viene campionato il traffico di produzione, chi convalida l'accuratezza dei giudici e come i fallimenti diventano test futuri.

I knowledge worker dovrebbero interessarsene perché questi controlli determinano se un agente possa essere considerato affidabile per lavori con conseguenze rilevanti. Quando valutate un deployment di agenti Amazon AWS, andate oltre le risposte fluide. Chiedete la traccia, il risultato delle esecuzioni ripetute e il ciclo di feedback dalla produzione che li sostiene.