Amazon corta 98% do custo com nova IA para rotular tickets

Tech Desk

Amazon adota nova IA para otimizar a classificação de tickets, mantendo precisão e reduzindo custos drasticamente.

Leia também: EUA investigam falha no recall da Waymo após risco a crianças

A Amazon substituiu o modelo de inteligência artificial Sonnet 4.6 pelo Strands Decider no sistema interno que rotula milhões de tickets da companhia e, com isso, reduziu em 98% o custo de processamento, mantendo a mesma precisão na categorização automática.

Economia milionária com troca de modelo

O sistema, usado por equipes da Amazon e da AWS, organiza em 20 categorias pedidos de capacidade, escalonamentos de clientes, alarmes automatizados, achados de segurança e outros tipos de tickets internos. Antes, o trabalho era feito pelo Sonnet 4.6, um modelo generativo que lia o ticket, processava um prompt longo e devolvia um JSON com o rótulo sugerido.

Com a migração para o Strands Decider, lançando mão de um modelo de decisão em vez de um gerador de texto, o custo por milhão de tickets caiu de US$ 22.000 para cerca de US$ 500 — uma redução de 44 vezes. “A mudança vai economizar milhões de dólares em custos de token em um ano”, afirmou Carr, engenheiro da Amazon envolvido no projeto.

Segundo Mehul, também engenheiro na empresa, a precisão foi preservada. “O modelo Strands Decider performou tão bem quanto o Sonnet 4.6 com uma redução de custo de 98%”, disse.

Como funciona o Strands Decider

Ao contrário de um modelo generativo, o Strands Decider não escreve respostas. “Um modelo de decisão não gera texto, ele retorna probabilidades para opções fixas”, explicou Carr. Na prática, o “estado” é o conteúdo do ticket, e as “opções” são o catálogo dos 20 rótulos possíveis, mais uma opção de “nenhum”.

O modelo recebe o ticket e uma pergunta de escolha única com essas opções resumidas em uma ou duas frases. Em vez de gerar um texto justificando a decisão, devolve a probabilidade de cada categoria e um índice de confiança, o que torna o processamento muito mais enxuto em tokens.

A equipe começou testando a versão Strands Decider 2B e depois migrou para a variante E4B Gemma 4, que mostrou desempenho claramente superior em um conjunto de testes internos. Em avaliação separada, o E4B superou inclusive a versão em produção do Sonnet na tarefa de rotulagem.

Entenda a arquitetura técnica na AWS

O novo fluxo usa apenas serviços padrão da AWS ao redor do modelo. Os eventos de tickets entram em uma fila SQS, que dispara uma função Lambda responsável por ler os dados e chamar o endpoint do Strands Decider hospedado no SageMaker como endpoint de IA.

O modelo roda em instâncias SageMaker ml.g5.xlarge, com uma GPU A10G e 24 GB de memória. O Strands Decider consome cerca de 19 GiB e leva, em média, 640 milissegundos por requisição em uma instância. A infraestrutura é isolada em rede, sem acesso de saída do container, e os pesos do modelo são carregados de um bucket S3 na inicialização.

A configuração do sistema — incluindo qual modelo usar e em que proporção — é controlada via AppConfig, enquanto logs, métricas e alarmes ficam sob responsabilidade do CloudWatch. Todo o stack é gerenciado com CDK, com ambientes separados para Beta, Gamma e Produção.

Lambda mais rápida e prompt mais curto

A mudança de arquitetura reduziu também o tempo de execução das funções Lambda encarregadas da rotulagem. No dia em que o uso do Sonnet foi desligado, a duração média das Lambdas caiu 74%, efeito direto do processamento mais simples e do prompt mais compacto no Strands Decider.

Parte importante da economia veio justamente da reescrita do prompt. As descrições completas das 20 categorias, usadas com o Sonnet, eram tão longas que sozinhas ultrapassavam a janela de 4.096 tokens do novo modelo. A solução foi condensar cada rótulo em um critério curto e colocá-los como alternativas de uma única pergunta, contendo ainda a opção “nenhum”.

O conteúdo dos tickets permaneceu o mesmo que chegava ao Sonnet, com um ajuste: em casos de histórico muito extenso, os comentários mais antigos são descartados para que tudo caiba no limite de contexto do Strands Decider, sem prejudicar a parte mais relevante da conversa.

Três vias para mitigar riscos

Para não depender de um “botão liga/desliga”, a equipe construiu um mecanismo de três vias controlado pelo AppConfig. Em cada mensagem recebida, a Lambda lê um parâmetro que define se deve usar apenas o modelo antigo, apenas o novo ou os dois em paralelo.

Rodar os dois modelos ao mesmo tempo em tráfego real permitiu comparar rótulo a rótulo cada divergência, o que deu mais segurança do que testes puramente offline. Em caso de problema com o Strands Decider, voltar ao Sonnet se tornou uma simples alteração de configuração, estimada pelos engenheiros em menos de um minuto.

Detalhe técnico: a ordem das chaves JSON

No meio da migração, a equipe esbarrou em um comportamento inesperado do modelo de decisão. “Descobrimos que a ordem das chaves JSON mudou a resposta, então agora enviamos todas as requisições com chaves ordenadas”, relatou Mehul. Em alguns casos, apenas mudar a ordem das chaves alterava as probabilidades de saída em até 0,19.

Por isso, o sistema passou a padronizar o JSON antes de cada chamada, garantindo consistência nos resultados. A recomendação interna, segundo os engenheiros, é que qualquer equipe que sirva modelos de decisão por trás de APIs verifique esse ponto ao comparar execuções.

Onde o modelo brilha — e onde não se aplica

A experiência reforçou que o Strands Decider é especialmente adequado para tarefas de escolha fechada com catalogo estável e alto volume, como a classificação de tickets internos da Amazon. Nesses cenários, a combinação de baixa latência, uso controlado de memória e custo muito menor tende a compensar com folga.

Em contrapartida, os engenheiros destacam que o modelo não substitui soluções que dependem de explicações textuais detalhadas, catálogos que mudam com frequência ou necessidade de contexto muito longo. Para esses usos, modelos generativos como o próprio Sonnet seguem mais indicados, ainda que mais caros.

Com a economia prevista e o desempenho alcançado, a expectativa é que outras equipes internas da Amazon testem o Strands Decider em fluxos de classificação e que clientes da AWS se inspirem na arquitetura para reduzir custos em aplicações semelhantes. A própria equipe já avalia formas de expandir o uso do modelo e aprofundar a integração com serviços da nuvem.