Arquitetura de IA

Como definir o tamanho de lote para agentes de IA

Aprenda a definir tamanho e janela de lote para agentes de IA por prazo, bytes, contexto, capacidade, falhas e efeito sobre cada unidade processada.

Um lote maior pode reduzir chamadas e piorar a operação

Um agente recebe documentos durante o dia. A equipe decide agrupar cem arquivos por execução para reduzir overhead. O primeiro grupo termina bem. No segundo, alguns arquivos são grandes, o contexto ultrapassa o limite previsto e o processamento ocupa a capacidade que atendia tarefas urgentes.

A configuração parece econômica quando observada por chamada. Para quem espera o resultado, ela criou atraso. Para o worker, aumentou memória e duração. Para a recuperação, ampliou a quantidade de itens presos ao mesmo ciclo.

O tamanho de lote para agentes de IA precisa equilibrar quantidade, volume em bytes, tempo de espera, custo, capacidade e isolamento de falhas. Um número fixo escolhido no painel raramente representa sozinho o trabalho real.

O guia sobre IA em tempo real ou processamento em lote ajuda a decidir se a tarefa deve entrar em lote. Esta página começa depois dessa escolha: como dimensionar o lote e sua janela para cumprir o prazo sem pressionar o restante da operação.

Separe quatro limites que costumam virar um só

Uma política de lote precisa declarar pelo menos quatro dimensões.

Quantidade de itens

É o máximo de unidades reunidas numa execução. Funciona quando as entradas possuem tamanho e custo relativamente próximos. Dez mensagens curtas e dez contratos extensos continuam sendo dez itens, mas exigem capacidade diferente.

Volume em bytes

Controla o tamanho acumulado do payload. Protege APIs, memória, rede e serialização contra grupos pequenos formados por arquivos muito grandes.

Janela de espera

Define quanto tempo o primeiro item pode aguardar antes do envio, mesmo que o limite de quantidade ainda não tenha sido alcançado. Sem essa janela, períodos de baixo movimento podem deixar trabalho parado à espera de um lote cheio.

Peso operacional

Representa o esforço esperado por unidade. Pode considerar páginas, tokens estimados, número de ferramentas, classe de modelo, chamadas ao destino, risco e revisão humana.

A regra de disparo costuma ser: enviar quando qualquer limite for atingido primeiro. O lote fecha por quantidade, bytes, peso ou tempo. Essa composição evita exigir que uma única medida explique todos os casos.

Defina a unidade antes do agrupamento

O lote é uma embalagem. Cada unidade ainda precisa de identidade, estado e consequência próprias.

Para um fluxo de análise documental, a unidade pode ser um documento com:

  • identificador estável;
  • versão da entrada;
  • classe de documento;
  • tamanho;
  • prazo útil;
  • prioridade;
  • estimativa de peso;
  • permissões aplicáveis;
  • resultado esperado;
  • condição de confirmação no destino.

Não agrupe objetos cuja conclusão precisa ser conjunta com objetos independentes sem registrar essa dependência. Um conjunto de anexos do mesmo contrato pode formar uma unidade lógica. Cem contratos diferentes podem compartilhar execução, mas cada um precisa terminar separadamente.

A página sobre falha parcial em lotes de agentes de IA detalha estado, confirmação e recuperação por item. O dimensionamento aqui deve preservar essa granularidade.

Comece pelo prazo do item mais antigo

A janela do lote consome parte do prazo antes do processamento começar.

Considere uma rotina que promete classificar solicitações em até vinte minutos. Se o sistema espera quinze minutos para encher o lote e a execução costuma levar oito, a promessa já nasce inviável. O tempo disponível precisa cobrir:

  1. espera para agrupamento;
  2. permanência na fila;
  3. leitura e validação;
  4. chamadas de modelo e ferramentas;
  5. confirmação no sistema oficial;
  6. eventual revisão humana;
  7. margem para variação e recuperação.

Registre o horário do primeiro item e sua data limite. Feche o lote antes que a espera consuma a reserva necessária para as etapas seguintes.

Em fluxos com classes diferentes, use janelas próprias. Uma pendência comercial com prazo de minutos não deve esperar o mesmo agrupamento de uma atualização de base que pode terminar durante a madrugada.

Use quantidade e bytes ao mesmo tempo

A documentação oficial do AWS Lambda descreve batch size como a quantidade máxima de registros e batching window como o tempo máximo usado para reunir registros. O payload também pode encerrar o lote antes desses dois limites.

O Google Cloud Pub/Sub expõe lógica semelhante no publicador: quantidade de mensagens, volume acumulado e tempo de espera podem disparar o envio, valendo o primeiro limite alcançado.

Esse padrão importa para agentes porque o custo por item varia muito. Uma política apenas por quantidade pode formar:

  • lote pequeno em itens e enorme em bytes;
  • lote grande de mensagens curtas;
  • grupo que cabe na API e estoura a memória do worker;
  • contexto que cabe no modelo, mas excede o prazo;
  • execução rápida que gera escritas demais no sistema seguinte.

Configure limites com base no menor componente seguro da cadeia, não apenas no teto anunciado pelo primeiro serviço.

Crie classes de peso

Nem sempre é preciso calcular tokens com precisão antes de processar. Uma classificação simples já reduz surpresa.

Exemplo conceitual com dados fictícios:

| Classe | Entrada típica | Peso atribuído | Tratamento | |---|---|---:|---| | leve | mensagem curta sem anexo | 1 | lote comum | | média | formulário com documento curto | 3 | lote menor | | pesada | arquivo extenso ou várias ferramentas | 8 | fila própria ou unidade isolada | | crítica | consequência sensível ou prazo curto | não agrupar por economia | rota prioritária |

Um lote pode ter teto de peso 20. Vinte itens leves cabem. Seis itens médios chegam perto. Dois itens pesados podem justificar execução própria.

Os números precisam nascer de medição do fluxo. O exemplo mostra a estrutura, sem recomendar pesos universais.

Não deixe um item pesado comandar todos os outros

Quando a distribuição varia muito, o item mais pesado define duração, memória e risco do lote inteiro.

Separe por atributos que alteram materialmente a execução:

  • tamanho do arquivo;
  • tipo de modelo necessário;
  • quantidade de ferramentas;
  • destino de escrita;
  • necessidade de OCR;
  • nível de prioridade;
  • região ou cliente quando existe isolamento;
  • revisão humana obrigatória;
  • sensibilidade do dado;
  • ordem por objeto.

Essa separação reduz o problema em que mensagens simples ficam presas atrás de documentos extensos. Também melhora a previsão de custo e prazo por classe.

A divisão não pode quebrar isolamento entre clientes ou permissões. O artigo sobre isolamento de clientes em agentes de IA mostra por que contexto compartilhado precisa respeitar fronteiras de acesso.

Proteja o sistema seguinte

O worker pode concluir o modelo rapidamente e derrubar o CRM, ERP ou banco com uma sequência concentrada de escritas.

Antes de aumentar o lote, verifique:

  • limite de requisições do destino;
  • concorrência segura;
  • tamanho aceito por requisição;
  • comportamento diante de resposta parcial;
  • transações e bloqueios;
  • idempotência das escritas;
  • prazo para confirmação;
  • capacidade de revisão humana;
  • política de backoff;
  • fila de recuperação.

Às vezes o lote maior melhora a leitura e piora a etapa de efeito. Nesse caso, mantenha agrupamento na análise e aplique controle de fluxo na saída.

Use rate limit para agentes de IA para distribuir capacidade e backpressure para fazer a saturação reduzir a admissão em vez de apenas aumentar a fila.

Trate o contexto compartilhado como hipótese

Agrupar itens pode economizar instruções repetidas ou permitir uma comparação conjunta. Também pode causar mistura indevida.

Contexto comum faz sentido quando as unidades compartilham legitimamente:

  • a mesma política vigente;
  • o mesmo schema;
  • o mesmo critério de classificação;
  • a mesma permissão;
  • a mesma versão do processo;
  • uma decisão que exige comparação entre itens.

Evite usar o mesmo contexto quando o agrupamento cruza cliente, finalidade, contrato, nível de acesso ou versão de regra. A redução de tokens não justifica vazamento ou aplicação da política errada.

Mesmo dentro de um lote válido, peça saída estruturada por item_id e confirme que cada entrada recebeu exatamente um resultado. Uma resposta compacta sem ligação estável entre entrada e saída torna a economia difícil de auditar.

Dimensione a recuperação junto com o lote

Um lote grande amplia o raio de uma interrupção quando o sistema não preserva progresso.

Antes de aumentar o tamanho, responda:

  • o checkpoint ocorre por lote ou por item?
  • sucessos confirmados ficam encerrados?
  • um timeout perde toda a execução?
  • o sistema sabe quais itens nem chegaram a começar?
  • estado incerto bloqueia outra escrita?
  • itens inválidos podem ser isolados?
  • a ordem exige parar depois de uma falha?
  • quanto custa repetir o grupo?

Se o único mecanismo de recuperação é repetir tudo, o lote máximo seguro tende a ser menor. Quando existe estado por item, confirmação e idempotência, a operação pode aproveitar grupos maiores sem transformar uma falha em repetição ampla.

Faça o tamanho responder ao estado da operação

Um valor fixo pode servir como ponto inicial. Em produção, a política pode variar dentro de limites aprovados.

Reduza o lote quando

  • a idade da fila se aproxima do prazo;
  • a latência do destino sobe;
  • itens pesados se concentram;
  • a taxa de falha aumenta;
  • o worker usa memória demais;
  • revisores acumulam pendências;
  • o contexto fica próximo do limite;
  • uma dependência entra em modo degradado.

Aumente o lote quando

  • entradas homogêneas chegam em volume;
  • existe folga de prazo;
  • o overhead por chamada é relevante;
  • dependências estão saudáveis;
  • falhas permanecem isoladas por item;
  • a capacidade de saída acompanha o grupo;
  • testes demonstram ganho por unidade válida.

Ajuste adaptativo precisa de piso, teto, passos pequenos e motivo registrado. Permitir que o agente escolha livremente qualquer tamanho transfere uma decisão de capacidade para um componente que não enxerga toda a fila.

Use uma política executável

Uma política conceitual pode seguir esta ordem:

  1. validar cada entrada;
  2. separar por cliente, permissão e classe;
  3. estimar bytes e peso;
  4. ordenar por prazo e dependência;
  5. adicionar itens enquanto nenhum teto for excedido;
  6. fechar quando quantidade, bytes, peso ou janela atingir o limite;
  7. reservar capacidade no destino;
  8. processar com saída identificada por item;
  9. confirmar efeitos separadamente;
  10. registrar métricas e ajustar dentro da faixa permitida.

O lote não deve esperar uma unidade grande que nunca caberá. Encaminhe esse caso para uma rota própria e continue formando grupos válidos.

Teste uma matriz de tamanhos

Não escolha o valor apenas com carga média. Execute testes com dados sintéticos ou autorizados e falhas deliberadas.

Compare pelo menos:

  • lote de um item;
  • lote pequeno;
  • lote comum;
  • lote no teto planejado;
  • itens leves e homogêneos;
  • mistura de leves e pesados;
  • primeiro item próximo do vencimento;
  • destino lento;
  • falha de um item no meio;
  • confirmação perdida;
  • worker interrompido;
  • fila ordenada;
  • volume baixo que depende da janela;
  • pico que atinge quantidade e bytes rapidamente.

Meça o resultado por unidade válida. Um teste com mais itens por segundo pode reprovar se aumentar prazo, custo de recuperação, duplicidade ou trabalho humano.

O ambiente de teste para agentes de IA ajuda a isolar credenciais, dados e efeitos durante essa validação.

Métricas para ajustar o lote

Acompanhe por classe:

  • itens por lote;
  • bytes por lote;
  • peso estimado e observado;
  • motivo de fechamento do lote;
  • tempo do primeiro item até o envio;
  • tempo em fila;
  • duração do processamento;
  • custo por unidade válida;
  • uso de memória e concorrência;
  • chamadas ao modelo e às ferramentas;
  • taxa de falha por item e por lote;
  • unidades repetidas;
  • confirmações incertas;
  • prazo cumprido;
  • capacidade do destino;
  • fila de revisão humana.

O motivo de fechamento é especialmente útil. Se quase todos os lotes terminam pela janela, aumentar o teto de quantidade não muda a operação. Se terminam por bytes, a quantidade nominal também deixa de ser a restrição principal.

Erros comuns

Copiar o máximo do fornecedor

O limite técnico informa o que a plataforma aceita. O seu processo pode exigir lotes menores por prazo, memória, risco ou capacidade do destino.

Otimizar somente chamadas

Reduzir invocações pode aumentar espera, contexto, recuperação e concentração de escrita. Leia o custo do fluxo completo.

Esperar o lote encher em horário fraco

Sem janela máxima, poucos itens podem ficar parados por tempo indefinido.

Misturar itens com permissões diferentes

Contexto compartilhado pode expor dados e aplicar fontes incorretas. Separe antes de agrupar.

Ignorar bytes e peso

Quantidade igual não representa trabalho igual. Arquivos, ferramentas e revisões mudam a carga.

Ajustar automaticamente sem faixa

Uma regra adaptativa sem piso, teto e observabilidade pode oscilar, esconder degradação e criar surpresa de custo.

Repetir o lote inteiro

Sem estado por item, uma falha amplia consumo e risco de duplicidade.

Checklist de implementação

  • [ ] A unidade de trabalho possui identidade e conclusão próprias?
  • [ ] Quantidade, bytes, peso e janela estão separados?
  • [ ] O prazo inclui espera, fila, execução, confirmação e revisão?
  • [ ] Itens pesados possuem rota própria?
  • [ ] Cliente, permissão e finalidade limitam o agrupamento?
  • [ ] O sistema seguinte suporta a concentração de efeitos?
  • [ ] A resposta liga cada saída ao item_id correto?
  • [ ] Sucessos confirmados não voltam por falha de outro item?
  • [ ] Existe piso e teto para qualquer ajuste adaptativo?
  • [ ] O motivo de fechamento do lote fica registrado?
  • [ ] Testes cobrem baixo volume, pico, falha e recuperação?
  • [ ] A decisão considera custo por unidade válida e prazo cumprido?

Fontes oficiais verificadas em 25 de setembro de 2026

Parâmetros, defaults e limites variam por serviço, origem de evento, biblioteca e versão. Consulte a documentação da plataforma usada e valide a configuração no ambiente de teste antes de levar a política para produção.

O lote termina quando o primeiro limite relevante chega

Um bom tamanho de lote cabe no prazo, na memória, no contexto, nas dependências e na recuperação. Quantidade isolada não consegue representar esse contrato.

Combine teto de itens, bytes, peso e espera. Separe classes incompatíveis, proteja o destino, confirme por unidade e ajuste somente dentro de faixas testadas. A economia aparece quando o agrupamento reduz trabalho sem esconder atraso nem ampliar o raio das falhas.