Claude Sonnet 5: come misurare l’impatto del nuovo tokenizer prima della migrazione

Che cosa cambia e che cosa non dimostra il numero di token

La documentazione di migrazione di Anthropic indica che Claude Sonnet 5 usa un nuovo tokenizer. A parità di testo in ingresso, il conteggio può essere circa il 30% più alto rispetto a Claude Sonnet 4.6, anche se l’aumento specifico dipende dal contenuto. L’annuncio del modello esprime la variazione come un intervallo approssimativo da 1,0 a 1,35 volte, anch’esso dipendente dal tipo di testo. Sono due descrizioni orientative dello stesso cambiamento, non la promessa che tutti i prompt aumentino nella stessa proporzione.

La prima conseguenza è contabile: un testo che prima generava un certo numero di token può registrarne di più con Sonnet 5. La seconda è operativa: se un’applicazione occupa quasi tutta la finestra di contesto, lo stesso materiale potrebbe assorbire una quota maggiore del budget. La guida avverte inoltre che un valore di max_tokens calibrato per Sonnet 4.6 può troncare una risposta equivalente quando si usa Sonnet 5. Perciò non basta cambiare l’identificativo del modello e supporre che le misurazioni precedenti descrivano ancora il nuovo comportamento.

Il dato, da solo, non consente di concludere che il costo aumenterà nella stessa proporzione, che tutti gli input cresceranno del 30%, che il modello avrà prestazioni peggiori o che si ridurrà la finestra di contesto massima dichiarata. Il costo dipende dalle tariffe applicabili e dai token fatturati in ingresso e in uscita, oltre che dall’eventuale uso della cache. L’utilità di una risposta va valutata separatamente. Un maggior numero di token contabilizzati descrive una differenza di rappresentazione, non la qualità del risultato.

La pagina sulle novità indica che Sonnet 5 supporta una finestra di contesto di un milione di token e un massimo di 128.000 token in uscita. Anche se il limite nominale del contesto può essere più ampio rispetto a una configurazione precedente, la quantità di testo che rientra in quel limite dipende da come viene tokenizzato il contenuto. È quindi opportuno distinguere il limite del modello dalla capacità effettiva di un’applicazione di includere documenti, istruzioni, cronologia e strumenti entro quel limite.

Che cosa misurare in un’integrazione reale

Un confronto utile non si limita a mettere a confronto due conteggi degli input. Deve osservare che cosa accade all’intero budget di una richiesta: istruzioni di sistema, domanda, documenti recuperati, cronologia, definizioni degli strumenti e risposta generata. In un’attività con molto contesto, l’aumento dei token dei documenti può essere più rilevante di quello di una domanda breve; in un’applicazione che produce risposte lunghe, anche i limiti di generazione e il valore di max_tokens meritano una verifica specifica.

Il conteggio dei token è una metrica intermedia. Per capire se il cambiamento incide sul prodotto occorre registrare almeno le richieste che superano il budget previsto, le risposte troncate, gli errori dovuti ai limiti, i nuovi tentativi, le risposte scartate e i risultati accettati. L’attività accettata va definita prima di eseguire il test: per esempio, una risposta che soddisfa i criteri di validità, formato e qualità stabiliti dal team. Senza una definizione preventiva, è facile presentare come risparmio un’esecuzione meno costosa che, semplicemente, non ha completato il lavoro.

Il costo per attività accettata si può esprimere come la spesa complessiva delle esecuzioni incluse divisa per il numero di attività che soddisfano il criterio di accettazione stabilito in anticipo. Il numeratore deve includere le risposte non riuscite, i nuovi tentativi e le generazioni scartate che hanno prodotto consumo fatturabile. Occorre inoltre precisare come viene contabilizzata la cache, quale tariffa è stata applicata e quale canale di accesso è stato usato. Questa metrica non è una tariffa ufficiale: è una misura operativa proposta per confrontare un’integrazione.

È inoltre necessario distinguere un prompt ripetuto da uno nuovo. Se una parte del contesto viene riutilizzata tramite cache, l’importo risultante può differire da quello di un input elaborato senza tale trattamento. Le pagine ufficiali dei prezzi descrivono le tariffe e i moltiplicatori della cache, ma il team deve verificare i valori in vigore per il modello, la regione e la piattaforma al momento della misurazione. Non è opportuno trasferire a una previsione attuale un dato storico o relativo a un’altra piattaforma.

Progettare un corpus che consenta di attribuire il cambiamento

Il corpus di valutazione deve rappresentare l’uso reale e restare invariato durante il confronto. Un campione stratificato può separare l’italiano e le altre lingue usate dal prodotto, il codice, i documenti lunghi, i testi brevi e i contenuti ripetuti. La stratificazione non implica che queste categorie cambieranno sempre nella stessa direzione; serve proprio a scoprire se l’effetto varia tra loro. Se il prodotto lavora con conversazioni, includete cronologie rappresentative. Se usa il recupero di documenti, conservate anche le query e i frammenti che vengono effettivamente forniti al modello.

Salvate il testo esatto di ogni input, la sua composizione, il conteggio ottenuto con ciascun modello e l’esito dell’attività. Evitate di normalizzare gli spazi, modificare le istruzioni o aggiornare i documenti tra un’esecuzione e l’altra, a meno che quella trasformazione non sia una parte esplicita del test. Registrate anche la configurazione, la data e il canale di accesso. Così, se i conteggi cambiano, sarà possibile indagare la differenza invece di attribuirla genericamente alla migrazione.

Per confrontare la qualità servono criteri identici e una revisione coerente. Quando possibile, valutate i risultati senza rivelare a chi li esamina quale modello li abbia prodotti. L’obiettivo non è proclamare che una versione sia superiore in assoluto, ma verificare se la sostituzione mantiene il risultato richiesto per le attività del team. Un conteggio più alto può coesistere con una qualità simile o migliore; un costo inferiore può coesistere con più errori. Per questo è importante considerare insieme consumo e accettazione.

Protocollo per confrontare Sonnet 5 con Sonnet 4.6

Prima di eseguire il test, stabilite a quale domanda volete rispondere. Potreste voler sapere se i prompt attuali rientrano ancora con un margine adeguato, se occorre rivedere i limiti di output o se la spesa per attività accettata cambia in modo significativo. Non riunite queste domande in un’unica conclusione: ognuna richiede una metrica diversa. Definite inoltre che cosa sarebbe rilevante per il prodotto, per esempio una riduzione del margine di contesto tale da imporre la rimozione di contenuti necessari o una variazione dei costi superiore alla soglia interna del team.

Eseguite gli stessi input con entrambe le versioni e mantenete uguali, per quanto possibile in base al canale di accesso, le istruzioni, gli strumenti, i parametri di generazione e le regole di accettazione. Se una funzionalità non ha un equivalente tra le versioni, documentate la differenza e non attribuitene automaticamente l’effetto al tokenizer. Registrate separatamente il conteggio in ingresso, quello in uscita, gli stati di completamento, gli errori e l’uso della cache. Per ogni esecuzione, annotate il costo calcolato con la tariffa applicabile a quel canale.

Confrontate poi i risultati per strato, non soltanto attraverso una media complessiva. Una media può nascondere che l’italiano cresca poco mentre alcuni documenti lunghi aumentano di più, oppure che il problema si presenti solo nelle richieste vicine al limite. Esaminate i valori estremi e le attività non riuscite. Se il tasso di accettazione cambia, analizzate esempi concreti per distinguere gli errori di contenuto dai tagli dovuti ai limiti, dai formati non validi o dalle modifiche introdotte dalla configurazione.

Ripetete il test quando cambia una variabile rilevante. Se vengono aggiornati le tariffe, la documentazione, il corpus o il sistema di cache, un dato precedente non descrive più esattamente le nuove condizioni. Conservare una versione datata del set di test e del calcolo permette di confrontare i risultati nel tempo senza confondere i cambiamenti del modello con quelli dell’ambiente.

Distinguere tokenizer, tariffe e canale di accesso

Per attribuire un cambiamento al tokenizer non basta confrontare una fattura prima e dopo la migrazione. Il prezzo può essere cambiato, l’uso della cache può variare, il prompt può essere stato modificato e le risposte possono avere lunghezze diverse. Il confronto più chiaro tiene separate tre domande: quanti token registra lo stesso contenuto, quanto viene fatturato nelle condizioni in vigore e quante attività accettate produce ciascuna configurazione. Una differenza in una di queste misure non spiega automaticamente le altre.

Non bisogna neppure supporre che tutti i canali offrano condizioni identiche. La documentazione di Amazon Bedrock contiene informazioni specifiche sul servizio relative a disponibilità, endpoint, regioni, API e fatturazione del modello. La documentazione della piattaforma Anthropic è invece il riferimento per l’API diretta. Le fonti verificate disponibili non consentono di affermare che ogni dettaglio di conteggio, cache, limiti o fatturazione sia uguale tra i diversi canali. Se l’applicazione accede tramite un provider terzo, misurate il comportamento su quel canale e consultate la documentazione e le condizioni aggiornate, invece di estrapolare i risultati dell’API diretta.

La stessa cautela vale per i prezzi comparativi pubblicati negli annunci. Un prezzo annunciato o un confronto storico non descrive necessariamente quanto viene fatturato oggi su ogni piattaforma e in ogni regione. Usate la documentazione dei prezzi in vigore per convertire l’utilizzo misurato in un costo e conservate la data e il canale della tariffa applicata. Se non è possibile mantenere condizioni equivalenti, descrivete il confronto come una valutazione del sistema nel suo complesso, non come una misurazione isolata del tokenizer.

Decidere se migrare, modificare la configurazione o mantenere temporaneamente la versione precedente

La migrazione è meglio supportata quando il test mostra che le attività richieste continuano a superare i criteri di accettazione, che i prompt rientrano con un margine sufficiente e che il costo per attività accettata resta entro il limite definito dal team. Se i conteggi aumentano ma non causano troncamenti né una variazione significativa del budget, l’aumento può essere una differenza contabile che non richiede di riprogettare l’architettura. È comunque opportuno aggiornare le previsioni e i pannelli di monitoraggio che dipendevano dai conteggi precedenti.

Se il problema si presenta soltanto nelle richieste vicine al limite, può bastare rivedere quei casi: ridurre il contesto ridondante, modificare la selezione dei documenti o ricalibrare max_tokens quando l’applicazione richiede risposte più lunghe. Queste modifiche vanno convalidate usando le stesse attività di test, perché cambiare prompt o contenuti introduce una nuova variabile. Non si dovrebbe ridurre il contesto importante soltanto per compensare un conteggio: il risultato deve continuare a essere accettabile.

Se il confronto rivela errori frequenti, un aumento del costo per attività accettata o risultati inconcludenti a causa delle differenze tra i canali, una risposta ragionevole può essere rinviare la migrazione di quella specifica integrazione, suddividerla per tipi di attività o avviare una distribuzione controllata. Mantenere temporaneamente Sonnet 4.6 non significa che Sonnet 5 sia peggiore in generale: significa che le prove raccolte dal team non giustificano ancora il cambiamento per quel caso d’uso. La decisione dovrebbe considerare anche la disponibilità e le condizioni in vigore per entrambe le versioni.

Documentate la decisione e le condizioni che potrebbero renderla non più valida. Una conclusione come «migrare» è utile solo se specifica la versione valutata, il corpus, il canale, la tariffa e la data. Senza questi dati, i numeri non sono più riproducibili e una futura modifica dei prezzi o della documentazione può rendere obsoleto un confronto che era ragionevole al momento della prova.

Limiti delle conclusioni

Le informazioni pubblicate da Anthropic offrono un riferimento da cui iniziare il test, non un sostituto del corpus di ogni organizzazione. L’intervallo approssimativo di token varia a seconda del contenuto; perciò un campione composto soprattutto da testi brevi potrebbe non rappresentare documenti lunghi, codice, italiano o altri materiali usati in produzione. Da quell’intervallo non si può nemmeno dedurre il costo finale di un’attività, perché servono la composizione di input e output, la tariffa applicata e il trattamento della cache previsto da ogni integrazione.

Le condizioni possono cambiare nel tempo. Un annuncio del modello, una pagina di migrazione e una pagina dei prezzi possono essere aggiornati in date diverse. Prima del rilascio, verificate la documentazione ufficiale in vigore e annotate quale versione e quale canale sono stati valutati. Le fonti consultate non stabiliscono un’equivalenza universale tra conteggi, limiti e fatturazione dell’API Anthropic e quelli dei servizi di terze parti; per qualsiasi conclusione in questo senso occorre controllare il canale specifico.

La domanda utile, quindi, non è se Sonnet 5 consumi sempre una percentuale fissa in più di token, ma quanto cambia l’uso delle risorse per il carico di lavoro che si intende migrare e se questo cambiamento modifica il risultato accettabile. Un esperimento controllato permette di rispondere con meno rischi che estrapolando un dato generale. Per confrontare altre opzioni disponibili nel catalogo si può partire dall’indice dei modelli, ma una valutazione di migrazione deve mantenere gli stessi presupposti e criteri per ogni caso.

Continua a esplorare

Correzioni e trasparenza

Se trovi un dato errato o non aggiornato, inviaci la pagina e la fonte da verificare.