Claude Sonnet 5: como medir o efeito do novo tokenizador antes de migrar

O que muda e o que o número de tokens não demonstra

A documentação de migração da Anthropic informa que o Claude Sonnet 5 usa um novo tokenizador. Para o mesmo texto de entrada, a contagem pode ser aproximadamente 30% maior do que no Claude Sonnet 4.6, embora o aumento específico dependa do conteúdo. O anúncio do modelo expressa a variação como uma faixa aproximada de 1,0 a 1,35 vez, também conforme o tipo de texto. São duas descrições orientativas da mesma mudança, não uma promessa de que todos os prompts aumentarão na mesma proporção.

A primeira consequência é contábil: um texto que antes gerava determinada quantidade de tokens pode registrar mais unidades no Sonnet 5. A segunda é operacional: se um aplicativo ocupa quase toda a janela de contexto, esse mesmo material pode consumir uma parcela maior do orçamento. O guia também alerta que um valor de max_tokens ajustado para o Sonnet 4.6 pode truncar uma resposta equivalente ao usar o Sonnet 5. Portanto, não basta trocar o identificador do modelo e presumir que as medições anteriores ainda representem o novo comportamento.

O número não permite concluir, por si só, que o custo aumentará na mesma proporção, que todas as entradas crescerão 30%, que o modelo terá desempenho pior ou que o contexto máximo anunciado será reduzido. O custo depende das tarifas aplicáveis e dos tokens de entrada e saída faturados, além de qualquer tratamento de cache. A utilidade de uma resposta exige uma avaliação separada. Mais tokens contabilizados descrevem uma diferença de representação, não a qualidade do resultado.

O guia de novidades informa que o Sonnet 5 oferece uma janela de contexto de um milhão de tokens e um máximo de saída de 128 mil tokens. Mesmo que o limite nominal de contexto seja maior do que o de uma configuração anterior, a quantidade de texto que cabe nesse limite depende de como o conteúdo é tokenizado. Portanto, é importante distinguir o limite do modelo da capacidade efetiva de um aplicativo para acomodar documentos, instruções, histórico e ferramentas dentro desse limite.

O que medir em uma integração real

Uma comparação útil não se limita a confrontar duas contagens de entrada. Ela deve observar o que acontece com o orçamento completo de uma solicitação: instruções do sistema, pergunta, documentos recuperados, histórico, definições de ferramentas e resposta gerada. Em uma tarefa com contexto extenso, o aumento de tokens dos documentos pode ser mais relevante do que o de uma pergunta curta; em um aplicativo com saídas longas, os limites de geração e o valor de max_tokens também merecem uma verificação específica.

A contagem de tokens é uma métrica intermediária. Para descobrir se a mudança afeta o produto, é preciso registrar pelo menos as solicitações que excedem o orçamento previsto, respostas truncadas, erros de limite, novas tentativas, respostas descartadas e resultados aceitos. A definição de tarefa aceita deve ser estabelecida antes da execução do teste: por exemplo, uma resposta que atende aos critérios de validade, formato e qualidade definidos pela equipe. Sem uma definição prévia, é fácil apresentar como economia uma execução mais barata que simplesmente não concluiu o trabalho.

O custo por tarefa aceita pode ser calculado dividindo o gasto total das execuções incluídas pelo número de tarefas que atendem ao critério de aceitação predefinido. O numerador deve incluir respostas malsucedidas, novas tentativas e gerações descartadas que tenham gerado consumo faturável. Também é preciso especificar como o cache é contabilizado, qual tarifa foi aplicada e qual canal de acesso foi usado. Essa métrica não é uma tarifa oficial: é uma medida operacional proposta para comparar uma integração.

Também é necessário distinguir um prompt repetido de um prompt novo. Se uma parte do contexto for reutilizada por meio de cache, o valor resultante pode ser diferente daquele de uma entrada processada sem esse tratamento. As páginas oficiais de preços descrevem tarifas e multiplicadores de cache, mas a equipe deve consultar os valores vigentes para seu modelo, região e plataforma no momento da medição. Não convém transferir para uma previsão atual um número histórico ou referente a outra plataforma.

Como criar um corpus que permita atribuir a mudança

O corpus de avaliação deve representar o uso real e permanecer congelado durante a comparação. Uma amostra estratificada pode separar português, outros idiomas usados pelo produto, código, documentos extensos, textos curtos e conteúdo repetido. A estratificação não significa que essas categorias sempre mudarão na mesma direção; ela serve justamente para identificar se o efeito varia entre elas. Se o produto trabalha com conversas, inclua históricos representativos. Se usa recuperação de documentos, preserve também as consultas e os trechos que realmente são enviados ao modelo.

Guarde o texto exato de cada entrada, sua composição, a contagem obtida com cada modelo e o resultado da tarefa. Evite normalizar espaços, alterar instruções ou atualizar documentos entre execuções, a menos que essa transformação faça parte explícita do teste. Registre também a configuração, a data e o canal de acesso. Assim, se as contagens mudarem, será possível investigar a diferença em vez de atribuí-la vagamente à migração.

A comparação de qualidade exige critérios idênticos e uma revisão consistente. Quando possível, avalie os resultados sem revelar ao avaliador qual modelo os produziu. O objetivo não é declarar que uma versão é superior de forma geral, mas verificar se a substituição mantém o resultado exigido nas tarefas daquela equipe. Uma contagem maior pode coexistir com qualidade semelhante ou melhor; um custo menor pode coexistir com mais falhas. Por isso, é importante analisar consumo e aceitação em conjunto.

Protocolo para comparar Sonnet 5 com Sonnet 4.6

Antes de executar o teste, defina a pergunta que deseja responder. Pode ser se os prompts atuais continuam cabendo com margem, se é necessário reajustar os limites de saída ou se o gasto por tarefa aceita muda de forma relevante. Não reúna essas perguntas em uma única conclusão: cada uma exige uma métrica diferente. Defina também o que seria relevante para o produto, como uma redução da margem de contexto que obrigue a retirar conteúdo necessário ou uma mudança de custo que ultrapasse o limite interno da equipe.

Execute as mesmas entradas nas duas versões e mantenha iguais, na medida em que o acesso permitir, as instruções, as ferramentas, os parâmetros de geração e as regras de aceitação. Se algum recurso não tiver um equivalente entre as versões, documente a diferença e não atribua automaticamente seu efeito ao tokenizador. Registre separadamente a contagem de entrada, a de saída, os estados de conclusão, os erros e o uso de cache. Para cada execução, guarde o custo calculado com a tarifa aplicável naquele canal.

Depois, compare os resultados por estrato, e não apenas por uma média geral. Uma média pode ocultar que o português aumente pouco enquanto certos documentos extensos aumentam mais, ou que o problema apareça apenas em solicitações próximas do limite. Examine os casos extremos e as tarefas malsucedidas. Se a taxa de aceitação mudar, analise exemplos concretos para distinguir erros de conteúdo de cortes por limite, formatos inválidos ou mudanças introduzidas pela configuração.

Repita o teste quando uma variável relevante mudar. Se as tarifas, a documentação, o corpus ou o sistema de cache forem atualizados, um número anterior deixa de descrever exatamente as novas condições. Manter uma versão datada do conjunto de teste e do cálculo permite comparar resultados ao longo do tempo sem confundir mudanças no modelo com mudanças no ambiente.

Como separar tokenização, tarifas e canal de acesso

Para atribuir uma mudança ao tokenizador, não basta comparar uma fatura de antes com outra de depois da migração. O preço pode ter mudado, o uso de cache pode ser diferente, o prompt pode ter sido editado e as respostas podem ter extensões distintas. A comparação mais clara mantém separadas três perguntas: quantos tokens o mesmo conteúdo registra, quanto é faturado nas condições vigentes e quantas tarefas aceitas cada configuração produz. Uma diferença em uma dessas medidas não explica automaticamente as demais.

Também não se deve presumir que todos os canais ofereçam condições idênticas. A documentação da Amazon Bedrock traz informações específicas desse serviço sobre disponibilidade, endpoints, regiões, APIs e faturamento do modelo. A documentação da plataforma Anthropic é a referência correspondente para a API direta. As fontes verificadas disponíveis não permitem afirmar que todos os detalhes de contagem, cache, limites ou faturamento sejam iguais entre canais. Se o aplicativo acessa o modelo por meio de um terceiro, faça a medição nesse canal e consulte sua documentação e condições vigentes, em vez de extrapolar resultados da API direta.

A mesma cautela se aplica aos preços comparativos publicados em anúncios. Um preço anunciado ou uma comparação histórica não necessariamente descreve o que é faturado hoje em cada plataforma e região. Use a documentação de preços vigente para converter o uso medido em custo e registre a data e o canal da tarifa utilizada. Se não for possível manter as condições equivalentes, descreva a comparação como uma avaliação do sistema completo, não como uma medição isolada do tokenizador.

Decidir entre migrar, ajustar ou manter temporariamente a versão anterior

A migração tem melhor respaldo quando o teste mostra que as tarefas exigidas continuam atendendo aos critérios de aceitação, que os prompts cabem com margem suficiente e que o custo por tarefa aceita permanece dentro do limite definido pela equipe. Se as contagens aumentarem, mas não provocarem truncamentos nem uma mudança relevante no orçamento, o aumento pode ser uma variação contábil que não exige uma reformulação da arquitetura. Ainda assim, é recomendável atualizar as previsões e os painéis que dependiam das contagens anteriores.

Se o problema aparecer apenas em solicitações próximas do limite, pode bastar revisar esses casos: reduzir contexto redundante, ajustar a seleção de documentos ou recalibrar max_tokens quando o aplicativo precisar de respostas mais longas. Essas mudanças devem ser validadas com as mesmas tarefas de teste, pois alterar prompts ou conteúdo introduz uma nova variável. Não se deve reduzir contexto importante apenas para compensar uma contagem: o resultado ainda precisa ser aceitável.

Se a comparação revelar falhas frequentes, aumento do custo por tarefa aceita ou resultados inconclusivos por diferenças entre canais, uma resposta razoável pode ser adiar a migração daquela integração, dividi-la por tipo de tarefa ou fazer uma implantação controlada. Manter temporariamente o Sonnet 4.6 não significa que o Sonnet 5 seja pior de forma geral; significa que as evidências da equipe ainda não justificam uma mudança para aquele uso específico. A decisão também deve considerar a disponibilidade e as condições vigentes das duas versões.

Documente a decisão e as condições que podem invalidá-la. Uma conclusão como “migrar” só é útil quando acompanhada da versão avaliada, do corpus, do canal, da tarifa e da data. Sem esses dados, os números deixam de ser reproduzíveis, e uma alteração futura de preços ou documentação pode tornar obsoleta uma comparação que antes era razoável.

Limites da conclusão

As informações publicadas pela Anthropic oferecem um ponto de partida para o teste, não substituem o corpus de cada organização. A faixa aproximada de tokens varia de acordo com o conteúdo; por isso, uma amostra dominada por textos curtos pode não representar documentos longos, código, português ou outros materiais usados em produção. Também não é possível inferir dessa faixa o custo final de uma tarefa, pois faltam a combinação de entradas e saídas, a tarifa aplicável e o tratamento de cache de cada integração.

As condições podem mudar com o tempo. O anúncio de um modelo, uma página de migração e uma página de preços podem ser atualizados em datas diferentes. Antes de implantar, confira a documentação oficial vigente e registre qual versão e canal foram avaliados. As fontes consultadas não estabelecem uma equivalência universal entre contagens, limites e faturamento na API da Anthropic e nos serviços de terceiros; qualquer conclusão desse tipo exige verificar o canal específico.

Por isso, a pergunta útil não é se o Sonnet 5 sempre consome uma porcentagem fixa a mais de tokens, mas quanto o uso de recursos muda na carga de trabalho que se pretende migrar e se essa mudança altera o resultado aceitável. Um experimento controlado permite responder com menos risco do que extrapolar um número geral. Para comparar outras opções disponíveis no catálogo, o ponto de partida pode ser o índice de modelos, mas uma avaliação de migração deve manter as mesmas condições e os mesmos critérios em cada caso.

Continue a explorar

Correções e transparência

Se encontrar informação incorreta ou desatualizada, envie-nos a página e a fonte que devemos rever.