Agentes de vendas da AWS: saudáveis e financeiramente errados. A correção foi avaliação em cada release

Perguntaram a um agente da AWS qual era a receita de um cliente ao longo de três meses. O número nos dados era $410.08. O agente reportou como “$410.08 Million.”

Nada alertou. O agente respondeu, a latência estava normal e todo dashboard continuou verde, porque os dashboards mediam se o agente respondia, não se a resposta estava certa.

Esse exemplo abre um relato de engenharia incomumente franco que a AWS publicou em 16 de outubro sobre o sistema multiagente que seu time de operações de Sales, Marketing and Global Services construiu para vendedores de campo. Os vendedores fazem perguntas em inglês comum pelo Amazon Quick; subagentes cuidam de insights de desempenho, insights de clientes e text-to-SQL sobre dados de vendas, com respostas limitadas ao território e ao papel de cada usuário. O post lista as outras falhas que deram início ao trabalho: Sales Revenue rotulado como Sales Revenue excluding Adjustments, uma estimativa de Annual Recurring Revenue que não aparecia em lugar nenhum nos dados, e cálculos do próprio agente apresentados como fatos com fonte.

A parte útil não é que a AWS avalia seus agentes. É onde cada checagem fica.

O “correto” é definido antes de qualquer teste

A primeira das nove etapas da AWS define qualidade: resultados de negócio mapeados para métricas e limites, orçamentos de latência e custo, e seis tipos nomeados de falha de precisão. Os templates de avaliador nativos do Amazon Bedrock AgentCore não cobriam esses tipos de falha, então o time escreveu avaliadores customizados para eles.

A ordem importa. Muitos times começam com um LLM judge genérico que pontua utilidade, depois descobrem que as falhas que custam dinheiro, como um erro de unidade na receita, não são o que o judge procurava. A taxonomia de falhas é o design da avaliação; a ferramenta vem depois.

Checagens determinísticas onde a resposta é conhecida, juízes LLM onde não é

Checagens determinísticas verificam fatos com respostas conhecidas: receita, datas de renovação, status de contrato, se a entidade de cliente correta foi resolvida. Um juiz LLM pontua o que não tem uma única resposta certa, como relevância, fidelidade e qualidade do raciocínio. A AWS também roda avaliadores de terceiros do DeepEval e do AutoEval.

Essa divisão é a correta. Um modelo juiz questionado se “$410.08 Million” é fiel a uma tabela pode ou não notar o problema; uma comparação com o data warehouse vai notar. Como mostrou a pesquisa da Anthropic sobre recompensar auditores de IA, um avaliador de modelo é um componente com a própria taxa de erro.

1. Fundação: definir qualidade e tipos de falha
2. Experimento: comparar versões
3. Merge: conjunto sentinela em cada deploy de staging
4. Gate: conjunto golden completo com respostas de ferramenta congeladas
5. Canário: avaliação agendada em produção
6. Adversário: guardrails em entradas e saídas
7. Drift: amostrar tráfego ao vivo, A/B antes do rollout
8. Pulse: traces, alarmes, dashboards
9. Feedback: falhas viram casos de teste

• Antes do release: Fundação: definir qualidade e tipos de falha · Experimento: comparar versões · Merge: conjunto sentinela em cada deploy de staging · Gate: conjunto golden completo com respostas de ferramenta congeladas
• Em produção: Canário: avaliação agendada em produção · Adversário: guardrails em entradas e saídas · Drift: amostrar tráfego ao vivo, A/B antes do rollout · Pulse: traces, alarmes, dashboards
• De volta ao desenvolvimento: Feedback: falhas viram casos de teste

Onde a maioria dos times investe de menosO que pega falhas que ninguém lançou

A janela de 38%

Um achado merece um lugar na parede de todo time de plataforma. Em um teste de pré-produção, uma mudança de dados, uma mudança de ferramenta e uma atualização correspondente de prompt deveriam ser lançadas juntas e, em vez disso, chegaram em momentos diferentes. Durante o descompasso, a taxa de aprovação caiu de 78% para 38%. Nenhum componente estava quebrado. A combinação estava.

Um release de agente não é um prompt. É o prompt, as definições das ferramentas, o código das ferramentas, os dados que as ferramentas leem e o modelo, e tudo isso precisa ser versionado e promovido como uma unidade. Se o seu processo deixa o time de prompt lançar na terça e o time de dados na quinta, a janela de 38% está embutida nele.

Canários que acionam por persistência, não por ruído

Em produção, a avaliação roda em janelas de 30 minutos que percorrem o conjunto golden ao longo de cerca de 24 horas, com uma execução diária completa como scorecard autoritativo. O time testou 15 e 60 minutos antes de ficar com 30. O on-call só é acionado depois de três janelas consecutivas estourando o limite, porque alertas de uma única janela corroíam a confiança.

Canários pegam o que a pré-produção não pega: uma tabela upstream muda a definição, e um agente que passou em todos os gates ontem está errado hoje. É o mesmo motivo pelo qual um agente pode retornar um 200 e ainda estar errado. O conjunto golden é alimentado por três lugares: consultas de produção amostradas, incluindo sessões ao vivo com pontuação baixa; casos de regressão de falhas passadas; e casos de borda sintéticos. Toda falha vira um teste.

O que os números dizem, e o que não dizem

A AWS reporta taxa de aprovação subindo de 93% para 96% estável ao longo de três meses, alucinações puras caindo de 138 para menos de 52 por 10,000 respostas, cálculos não autorizados caindo de 59 para menos de 44, e tempo médio de detecção caindo de dias ou semanas para menos de quatro horas. Esses são os números da AWS para o próprio sistema, e o post marca vários de seus gráficos como ilustrativos.

Leia os 96% com cuidado: quatro respostas em cada cem ainda falham em uma checagem. O pipeline não faz o agente estar certo; ele torna os erros visíveis em horas e transforma cada um em teste. Para um assistente de analytics cujas respostas um vendedor lê antes de agir, isso pode ser aceitável. Para um agente que escreve em um sistema de registro, a mesma taxa de aprovação precisa de um controle diferente antes da escrita: aprovação.

Nada disso exige o AgentCore. Exige alguém que seja dono do “correto” como métrica operacional, do jeito que alguém já é dono do uptime, e um processo de release que se recusa a lançar meio agente.