---
title: "Classificar ticket com LLM custa 44 vezes mais? O que a Amazon mediu ao trocar o Sonnet por um modelo de decisão"
slug: modelo-de-decisao-classificacao-44x-mais-barato
date: 2026-11-10
category: "Arquitetura"
tags: ["ia", "agentes", "llm", "typescript", "techlead"]
readTime: "3 min"
excerpt: "Dois engenheiros da Amazon trocaram o Claude Sonnet 4.6 por um modelo que só escolhe entre opções e o custo por milhão de tickets caiu de cerca de US$ 22.200 para cerca de US$ 500. O número chama atenção, mas a parte que eu copiaria é a chave de três posições que eles usaram para virar."
url: https://eliseu.dev/blog/modelo-de-decisao-classificacao-44x-mais-barato
---

Cerca de US$ 22.200 por milhão de tickets com o Claude Sonnet 4.6. Cerca de US$ 500 com um modelo de decisão. Foi isso que dois engenheiros da Amazon mediram num dos maiores sistemas internos de tickets da empresa, e acho que a lição serve para qualquer etapa de classificação que hoje roda num LLM grande.

## O que aconteceu

O sistema rotulava cada ticket em uma de 20 categorias: escalonamento de cliente, pedido de capacidade, alarme automático, achado de segurança e por aí vai. O Sonnet recebia um system prompt longo, raciocinava e devolvia JSON.

Eles trocaram isso pelo Strands Decider, na versão E4B. Um modelo de decisão não gera texto. Ele recebe um estado e uma pergunta com opções e devolve uma probabilidade para cada opção, mais uma confiança. Aqui o estado é o ticket e as opções são o catálogo de rótulos.

Os números que eles publicaram:

| | Sonnet 4.6 | Decider E4B |
| --- | --- | --- |
| Tempo médio por chamada | 4.215 ms | 897 ms |
| Tokens de entrada por ticket | 6.554 | 2.009 |
| Tokens de saída por ticket | 170 | 1 |
| Custo por milhão de tickets | cerca de US$ 22.200 | cerca de US$ 500 |

A conta do Decider depende de quão ocupada fica cada instância `ml.g5.xlarge` no SageMaker. Em uso total daria US$ 250 por milhão. Com folga para pico, eles chegam a uns US$ 500, o que dá 44 vezes menos.

## Por que funcionou

Os próprios autores dizem o limite: deu certo porque a escolha é fechada, o catálogo é conhecido, o volume é alto e a latência do caminho antigo importava. Se o rótulo precisa de texto explicando, se o catálogo muda toda semana ou se o contexto útil não cabe em poucos milhares de tokens, provavelmente não dá.

Tem um custo escondido também. A descrição dos rótulos em produção era maior que a janela de 4.096 tokens do Decider. Eles reescreveram cada um dos 20 rótulos como um critério de uma ou duas frases, mais uma opção "nenhum". Em ticket longo, os comentários mais antigos são cortados para caber.

## A parte que eu copiaria

Veja: o número chama atenção, mas o que eu levaria para o meu pipeline é a forma de virar. A Lambda que rotula lê uma chave de três posições no AppConfig a cada mensagem. `BEDROCK` usa só o Sonnet. `DUAL` chama os dois em paralelo, aplica o resultado do Sonnet e compara com o do Decider. `DECIDER` usa só o modelo novo.

Um esboço em TypeScript do que isso vira no código:

```ts
type Mode = "LLM" | "DUAL" | "DECIDER";

export async function label(ticket: Ticket): Promise<string> {
  const mode = await getFlag<Mode>("labeler.mode"); // lido a cada mensagem, sem deploy

  if (mode === "LLM") return llmLabel(ticket);
  if (mode === "DECIDER") return deciderLabel(ticket);

  const [fromLlm, fromDecider] = await Promise.all([
    llmLabel(ticket),
    deciderLabel(ticket).catch(() => null), // o modelo novo não pode derrubar o caminho atual
  ]);
  if (fromDecider !== fromLlm) recordDisagreement(ticket.id, fromLlm, fromDecider);
  return fromLlm; // em DUAL quem decide ainda é o modelo antigo
}
```

Segundo eles, rodar os dois em tráfego real e julgar cada divergência ensinou mais que qualquer avaliação offline. E voltar atrás era uma mudança de configuração de 45 segundos.

Pera. Tem um detalhe que eu não esperava. A ordem das chaves no JSON mudou a resposta. O mesmo conteúdo, com chaves em outra ordem, mexeu as probabilidades em até 0,19. Agora eles mandam tudo com chaves ordenadas. Se você compara execuções de um modelo de decisão atrás de uma API, ordene antes de comparar.

## O que muda para você

Eu faria um inventário das chamadas de LLM do produto e marcaria as que são escolha fechada: roteamento de intenção, triagem, "qual ferramenta chamar", classificação de documento. Essas são candidatas. Para cada uma, o passo seguinte seria o modo `DUAL` com log de divergência, antes de qualquer troca.

É parecido com o que eu defendi sobre o [gateway de LLM](/blog/litellm-comprometido-log-gateway-llm): a etapa que fica entre o seu código e o modelo merece o mesmo cuidado de qualquer outro serviço em produção. Quantas chamadas no seu pipeline são, no fundo, uma escolha entre 20 opções?

Sou Tech Lead de IA e esse tipo de decisão de custo por etapa de agente é o que eu gosto de discutir. Se quiser conversar sobre o seu caso, [me chama aqui](/contact).

## Fontes

- [Amazon saves millions by replacing Sonnet 4.6 with Strands Decider](https://strandsagents.com/blog/amazon-saves-millions-replacing-sonnet-with-strands-decider/), blog do Strands Agents, novembro de 2026
- [Introducing Strands Decider](https://strandsagents.com/blog/introducing-strands-decider/), blog do Strands Agents
- [strands-labs/strands-decider](https://github.com/strands-labs/strands-decider), repositório do modelo e notas de serving
- [Discussão no Hacker News](https://news.ycombinator.com/item?id=50436640)