Teste de carga para agentes de IA: guia prático

Um agente rápido no piloto pode travar quando o volume chega

Durante o piloto, vinte solicitações entram de forma espaçada. O agente consulta documentos, chama o modelo, atualiza o CRM e envia alguns casos para revisão. Tudo termina dentro do prazo.

Na produção, uma campanha coloca centenas de solicitações na fila em poucos minutos. A quantidade de workers aumenta, mas o CRM começa a responder devagar. As chamadas ao modelo se multiplicam porque cada caso abre subtarefas. O agente continua preparando decisões enquanto a equipe humana acumula aprovações que já perderam validade.

Esse sistema não falhou por falta de inteligência. Faltou testar a operação sob a pressão que ela realmente receberia.

Um teste de carga para agentes de IA verifica quantas unidades de trabalho o fluxo completo consegue concluir com qualidade, prazo e controle. O teste inclui modelos, filas, integrações, bancos, validações, pessoas e mecanismos de recuperação. Medir apenas requisições por segundo deixa justamente os gargalos empresariais fora da conta.

O que um teste de carga precisa responder

O objetivo não é descobrir o número máximo que a infraestrutura aguenta antes de cair. A empresa precisa tomar decisões mais úteis:

qual volume pode ser admitido sem vencer o prazo do processo;
qual etapa satura primeiro;
como latência, custo e qualidade mudam com a concorrência;
quanto trabalho humano cada faixa de volume produz;
se tarefas críticas preservam capacidade durante um pico;
quando o sistema deve reduzir entrada, degradar serviço ou pausar;
quanto tempo leva para esvaziar o backlog;
se a recuperação repete ou perde consequências.

O artigo sobre planejamento de capacidade para agentes de IA estima demanda, gargalos e folga. O teste de carga confronta essas hipóteses com uma execução controlada e produz evidência para configurar limites.

Escolha uma unidade de trabalho reconhecível

Chamadas de API são consumo técnico. O teste deve acompanhar entregas que a operação reconhece.

Exemplos:

oportunidade comercial revisada e registrada;
documento recebido, extraído e validado;
chamado classificado e encaminhado;
pedido conferido e atualizado;
reunião preparada com fontes verificáveis;
nota fiscal pronta para aprovação;
agendamento confirmado no sistema oficial.

Para cada unidade, defina a entrada válida, as etapas obrigatórias, a condição de conclusão, o prazo, a classe de prioridade e os efeitos externos permitidos.

Uma unidade que termina com uma tarefa no CRM só conta como concluída quando o CRM confirma a gravação. Uma resposta gerada em memória, sem chegar ao destino, não deve inflar o throughput do teste.

Também registre o fan-out. Uma solicitação pode gerar cinco buscas, duas chamadas de modelo, uma consulta ao ERP e três subtarefas. Cem entradas podem se transformar em mil operações internas. Sem essa relação, o teste atribui a sobrecarga ao componente errado.

Separe os tipos de teste

Carga, estresse e resistência respondem perguntas diferentes. Misturá-los em uma única bateria dificulta o diagnóstico.

Carga esperada

Reproduz o volume comum e os picos previstos. Valida se o serviço cumpre prazo, qualidade e custo dentro da faixa planejada.

Pico repentino

Concentra muitas entradas em uma janela curta, como campanha, importação, fechamento ou reativação de integração. Mostra se filas e controles absorvem a variação sem perder tarefas prioritárias.

Carga sustentada

Mantém o volume por horas ou pelo ciclo real do processo. Encontra vazamentos de memória, conexões presas, acúmulo de estado, aumento gradual de latência e filas humanas que um pico curto não revela.

Estresse

Eleva a pressão além da capacidade esperada para descobrir o ponto de saturação e observar se o sistema falha de forma controlada. O propósito é verificar limites, não criar uma meta de operação no limite.

Recuperação

Reduz ou interrompe a carga depois da saturação e mede como o fluxo volta. Essa etapa revela backlog vencido, retentativas sincronizadas, duplicidade e concorrência entre trabalho antigo e novas entradas.

Degradação de dependência

Mantém a entrada enquanto uma API, banco, modelo ou revisor perde capacidade. O teste verifica circuit breaker, backpressure, modo reduzido e contingência.

Monte um perfil de carga baseado na operação

Um teste com volume uniforme pode ser tecnicamente limpo e empresarialmente falso. Use o padrão de chegada observado ou uma hipótese explicitamente aprovada.

O perfil deve incluir:

quantidade de entradas por intervalo;
concentração por horário e dia;
proporção de casos simples, pesados e inválidos;
distribuição por cliente, unidade e prioridade;
tamanho de arquivos e contexto;
número médio e máximo de subtarefas;
percentual de casos enviados para revisão;
probabilidade de retentativa;
latência das dependências;
eventos em lote e picos sazonais;
prazo útil de cada classe.

Se ainda não existe produção, use dados do processo atual, amostras anonimizadas e cenários conservadores. Marque claramente o que veio de observação e o que continua como hipótese.

A página sobre dados sintéticos para testar agentes ajuda a preservar distribuição, exceções e privacidade sem copiar registros pessoais para o ambiente de teste.

Prepare um ambiente que possa falhar com segurança

Carga sobre produção pode gerar mensagens, tarefas, cobranças, alterações e custo real. O ensaio precisa de fronteiras próprias.

O ambiente de teste para agentes de IA deve separar:

credenciais;
bancos e filas;
endpoints de escrita;
contas de fornecedores;
dados e índices;
webhooks;
políticas de permissão;
alertas e painéis;
limites financeiros.

Use mocks quando o fornecedor não oferece sandbox ou quando o teste poderia afetar terceiros. O mock precisa reproduzir latência, limites, erros e respostas relevantes. Um endpoint que sempre responde em dez milissegundos aprova uma arquitetura que pode falhar no primeiro contato com o sistema real.

Para integrações críticas, combine simulação com uma bateria pequena em ambiente homologado pelo fornecedor. Nunca presuma que um mock representa cota, concorrência ou confirmação externa com fidelidade total.

Instrumente antes de gerar volume

Sem telemetria por unidade e etapa, o teste produz apenas a sensação de lentidão.

Registre:

identificador da unidade;
cenário e intensidade da carga;
versão completa do agente;
horário de entrada, início e conclusão;
tempo em cada fila;
duração de modelo, ferramenta e validação;
tentativas e timeouts;
chamadas internas por unidade;
estado final e motivo da falha;
revisão solicitada e concluída;
efeito externo confirmado;
custo por unidade válida;
memória, CPU, conexões e utilização dos recursos;
tamanho, idade e tempo de drenagem das filas.

O tracing de agentes de IA conecta essas etapas sob a mesma trajetória. Métricas agregadas mostram onde a curva piorou. Traces revelam por que uma classe de caso ficou lenta ou duplicou trabalho.

Defina uma linha de base

Execute primeiro uma faixa baixa e estável. Ela serve para validar o cenário, conferir dados, verificar contagens e estabelecer o comportamento sem pressão relevante.

A linha de base deve mostrar:

taxa de conclusão válida;
latência mediana e de cauda;
custo por unidade;
erros por categoria;
chamadas e subtarefas por unidade;
tempo de revisão;
confirmação no sistema de destino;
diferença entre entrada e saída.

Se a linha de base já apresenta erro, duplicidade ou baixa qualidade, aumentar a carga só tornará o diagnóstico mais caro. Corrija o fluxo antes de testar escala.

Aumente carga em degraus

Subir diretamente ao pico máximo esconde o ponto em que a degradação começa. Use degraus com duração suficiente para estabilizar filas e recursos.

Um roteiro pode seguir esta ordem:

validar carga mínima;
alcançar volume comum;
sustentar o volume comum;
elevar para pico esperado;
manter o pico durante a janela prevista;
ultrapassar a faixa para localizar saturação;
reduzir entrada;
observar a drenagem;
restaurar a admissão;
reconciliar estados e efeitos.

Em cada degrau, registre a taxa de chegada, conclusão, falha, expiração e crescimento do backlog. Pare quando um limite de segurança for atingido. O teste não precisa danificar o ambiente para provar que o próximo nível seria inadequado.

Inclua dependências e revisão humana

O modelo costuma ser apenas uma parte da capacidade.

Sistemas de registro

CRM, ERP, help desk e bancos podem aceitar leitura em grande volume e restringir escrita. Meça conexão, lock, cota, latência e confirmação.

Provedores de modelo e OCR

Observe limites por minuto, tokens, tamanho de arquivo, filas internas, erro transitório e mudança de latência por perfil.

Filas e workers

Aumentar concorrência local pode pressionar todas as dependências seguintes. Verifique distribuição, reserva por classe e trabalho preso.

Revisores humanos

Simule disponibilidade, tempo de decisão, horário, substituição e devolução por falta de contexto. Uma fila humana não responde com erro técnico, mas pode ser o primeiro recurso saturado.

Canais externos

WhatsApp, e-mail e calendários possuem limites, janelas e consequências reputacionais. Em teste, bloqueie envio real e valide o contrato até o ponto anterior à consequência.

Verifique qualidade sob pressão

Um sistema pode manter throughput degradando o trabalho.

Compare por degrau:

completude;
uso da fonte correta;
classificação por categoria;
respeito a permissão;
saída dentro do esquema;
escalonamento adequado;
confirmação da ação;
correção humana;
estabilidade entre execuções equivalentes;
erro impeditivo.

Amostre casos comuns, difíceis e críticos. Uma média única pode esconder que a carga preservou solicitações simples e prejudicou todos os casos que usam documentos grandes ou revisão especializada.

O guia sobre como avaliar agentes de IA ajuda a montar critérios por classe. No teste de carga, a avaliação precisa acompanhar o aumento de concorrência para detectar perda de qualidade causada por timeout, contexto truncado, fallback ou simplificação indevida.

Teste backpressure e prioridades

Quando a saída perde capacidade, a entrada precisa reagir. O artigo sobre backpressure em agentes de IA detalha como levar o sinal de saturação até o produtor.

Durante o teste, confirme se o sistema:

reduz admissão antes de a fila perder validade;
preserva capacidade para classes críticas;
adia lotes sem urgência;
limita fan-out;
recusa entradas inválidas cedo;
evita retentativas sincronizadas;
informa o motivo da restrição;
impede que um cliente monopolize recursos;
retoma com histerese, sem oscilar a cada melhora curta.

Prioridade precisa usar campos verificáveis. Texto em tom urgente não deveria furar a fila sozinho.

Meça a recuperação, não apenas a saturação

O teste continua depois que a carga cai.

Calcule:

tempo de drenagem = backlog restante ÷ capacidade líquida de conclusão

Capacidade líquida é a parcela disponível depois de atender novas entradas autorizadas. Se a operação conclui cem unidades por hora e recebe oitenta, apenas vinte unidades por hora reduzem o estoque antigo.

Verifique também:

itens vencidos e seu destino;
ações manuais ocorridas durante a restrição;
unidades com estado incerto;
duplicidade após retentativa;
ordem de processamento do backlog;
concorrência com trabalho novo;
retomada gradual das classes suspensas;
reconciliação no sistema oficial;
tempo até recuperar a folga.

Um sistema que sobrevive ao pico e leva dias para normalizar ainda possui um problema de capacidade.

Crie critérios de aceite antes do ensaio

Sem critérios prévios, a equipe tende a aprovar o resultado porque o sistema não caiu.

Defina por cenário:

faixa de volume autorizada;
prazo por classe;
taxa de conclusão válida;
erros impeditivos com tolerância zero;
limites de fila e idade;
custo máximo por unidade;
faixa de correção humana;
uso máximo de cada dependência;
tempo de reação do backpressure;
tempo de drenagem;
condição para interromper o teste;
evidência necessária para ampliar.

Metas devem nascer da linha de base, do impacto e da capacidade disponível. Não copie percentuais de outro produto.

O resultado pode terminar em quatro decisões: aprovar a faixa, aprovar com limites, redesenhar o fluxo ou adiar a ampliação. “Passou” sem declarar volume, cenário e restrições não autoriza produção.

Registre um relatório que leve a decisão

O relatório de teste precisa ser curto o bastante para ser usado e detalhado o bastante para reproduzir o achado.

Inclua:

versão testada;
ambiente e dependências;
unidade de trabalho;
perfil de carga;
cenários executados;
critérios de aceite;
resultados por degrau;
primeiro gargalo observado;
falhas e classes afetadas;
comportamento de filas e revisão;
custo e qualidade;
recuperação e reconciliação;
mudanças exigidas;
faixa de operação aprovada;
dono e data da próxima revisão.

Vincule gráficos e traces ao cenário correspondente. Capturas soltas, sem versão e sem intensidade, viram decoração técnica.

Erros comuns

Testar somente o modelo

O provedor responde rápido enquanto CRM, fila, validação ou pessoa já saturaram.

Usar entradas idênticas

Cache e caminhos previsíveis produzem um resultado artificial. Preserve mistura de tamanhos, categorias e exceções.

Ignorar efeitos externos

Gerar saída não prova que a tarefa chegou ao destino nem que uma repetição será segura.

Rodar até o sistema cair

O ponto útil é quando prazo, qualidade, custo ou controle saem da faixa. Colapso total raramente acrescenta informação proporcional ao risco.

Olhar apenas médias

Caudas, clientes específicos e tarefas pesadas costumam definir a experiência ruim.

Parar ao fim do pico

Backlog, duplicidade e estado incerto aparecem durante a recuperação.

Tratar pessoas como recurso infinito

A automação pode criar trabalho de aprovação mais rápido do que a equipe consegue decidir.

Checklist do teste de carga

A unidade de trabalho possui conclusão verificável?
O perfil representa volume, mistura e concentração reais?
Fan-out e chamadas internas entram na conta?
Dados e credenciais estão isolados?
Dependências simulam latência, cota e erro?
A versão testada está congelada?
Métricas e traces cobrem cada etapa?
Existe linha de base válida?
A carga aumenta em degraus?
Qualidade é medida junto com throughput?
Revisão humana faz parte do cenário?
Limites de fila, custo e prazo estão definidos?
Backpressure e prioridade são exercitados?
Critérios de interrupção estão ativos?
Recuperação e reconciliação foram medidas?
O relatório declara a faixa aprovada e suas restrições?

Capacidade comprovada vale mais que velocidade demonstrada

Um teste de carga útil transforma escala em uma decisão observável. Ele mostra o volume que o processo inteiro conclui, a etapa que limita o serviço, a qualidade preservada e a forma como o sistema reage quando a pressão aumenta.

O resultado orienta concorrência, filas, cotas, reservas, revisão humana e limites de autonomia. A empresa deixa de ampliar um agente com base em uma demonstração rápida e passa a operar dentro de uma faixa sustentada por evidência.