The Pulse

Amazon: Strands Decider ha sostituito Sonnet per etichettare i ticket

Gli ingegneri di Amazon affermano di aver sostituito Claude Sonnet 4.6 con Strands Decider E4B in un sistema interno di etichettatura dei ticket. Riferiscono prestazioni simili nell’etichettatura, con costi inferiori del 98%, sulla base dei

AI.info Team · Scritto con l’IA · verificato · 2026-11-09

Un modello diverso per una scelta predefinita

Gli ingegneri di Amazon affermano di aver sostituito Claude Sonnet 4.6 con Strands Decider E4B per etichettare i ticket nel sistema interno di Amazon, ottenendo prestazioni simili a un costo inferiore del 98%. Il resoconto di Strands Agents, datato 9 novembre, descrive il cambiamento come il passaggio da un modello linguistico di grandi dimensioni a un modello decisionale.

I team di Amazon usavano Sonnet per classificare in 20 categorie le segnalazioni dei clienti inoltrate a un livello superiore, le richieste di capacità, gli allarmi automatici, le anomalie di sicurezza e altri ticket aziendali. La configurazione precedente inviava ogni ticket insieme a un lungo prompt di sistema e chiedeva al modello di ragionare su etichette predefinite e restituire un JSON. Strands descrive Decider come un modello che restituisce una probabilità per ogni opzione disponibile e un punteggio di confidenza, invece di generare testo.

Gli ingegneri hanno prima testato Strands Decider 2B, poi sono passati a una build E4B di Gemma 4, dopo che questa aveva ottenuto risultati migliori su un insieme di test. Affermano che, dopo aver regolato la soglia di confidenza necessaria al modello per applicare un’etichetta, E4B ha superato Sonnet in produzione su un insieme separato di ticket. Il team ha sintetizzato le descrizioni delle 20 etichette in criteri di una o due frasi e ha aggiunto un’opzione «nessuna» all’elenco delle scelte.

La verifica del cambiamento sul traffico reale

Per servire il modello, il team ha usato istanze SageMaker ml.g5.xlarge, ciascuna con una A10G e 24 GB di memoria; il modello ne utilizzava circa 19 GiB. Il post indica un tempo per richiesta di circa 640 millisecondi su una singola istanza e afferma che SageMaker copia i pesi del modello da S3 prima dell’avvio. L’endpoint si adatta al traffico, mentre la sua rete è isolata dall’accesso in uscita verso il container.

La pipeline dei ticket usa SQS, Lambda, un SageMaker AI Endpoint, AppConfig e CloudWatch, con fasi di deployment chiamate Beta, Gamma e Prod. Gli ingegneri hanno usato un’impostazione di AppConfig con tre opzioni per gestire la transizione: BEDROCK eseguiva solo Sonnet, DUAL eseguiva entrambi i modelli e DECIDER eseguiva solo Strands Decider. Durante il funzionamento in modalità DUAL, ai ticket venivano applicate le etichette di Sonnet, mentre i suoi risultati venivano confrontati con quelli di Decider.

Il post riporta tempi medi di chiamata di 4.215 millisecondi per Sonnet e 897 millisecondi per Strands Decider E4B, un miglioramento del 78%. Indica un utilizzo complessivo di 6.724 token per ticket per Sonnet e 2.010 per Decider, una riduzione del 70%. Il team afferma che il minor numero di token è dovuto al prompt più breve di Decider e al suo output con una sola scelta, mentre i ticket lunghi possono perdere i commenti più vecchi per rientrare nel contesto del modello. Il post riporta anche un calo del 74% nella durata media di esecuzione di Lambda nel giorno in cui l’uso di Sonnet è stato disattivato.

Costi e limiti

Usando i prezzi on demand pubblicati per us-east-1, gli ingegneri stimano un costo di 0,0222 dollari per ticket per Sonnet e di circa 0,0005 dollari per ticket per Decider. Per un milione di ticket, le loro cifre sono di circa 22.200 dollari per Sonnet e circa 500 dollari per Decider, con quest’ultimo costo che dipende dal grado di utilizzo di ogni istanza. Affermano che la stima esclude i costi di Lambda e presuppone un margine di capacità per i picchi; a pieno utilizzo, un’istanza potrebbe gestire circa 5.600 ticket all’ora per 250 dollari per milione di ticket.

Gli ingegneri hanno constatato che modificare l’ordine delle chiavi JSON poteva variare le probabilità in output fino a 0,19, quindi ora ordinano le chiavi in ogni richiesta. Affermano che l’approccio si è rivelato adatto a un’attività ad alto volume con un catalogo fisso di etichette, ma potrebbe non essere adatto ai casi che richiedono testo esplicativo, un catalogo che cambia ogni settimana o più contesto di qualche migliaio di token. Il team afferma che eseguire entrambi i modelli sul traffico reale lo ha aiutato a valutare le discrepanze e che annullare il passaggio ha richiesto una modifica alla configurazione della durata di 45 secondi.