Ganhos:
- Determina para quais cargas de trabalho o processamento em lote é adequado
- Compreende a compensação custo/latência entre processamento síncrono, assíncrono e em lote
- Projeta um fluxo de trabalho em lote robusto que combina custom_id com os resultados
A maioria das integrações LLM concentra-se em cenários “ao vivo”, onde um usuário aguarda uma resposta na frente de uma tela. Mas a maioria das cargas de trabalho profissionais não são realmente ativas: marcar milhares de documentos durante a noite, resumir um conjunto de dados inteiro, classificar gravações de chamadas inteiras no arquivo. Nestas questões, ninguém espera uma resposta instantânea; O importante é terminar o trabalho de forma barata e confiável. O lote é exatamente para essas cargas de trabalho. Nesta unidade, você aprenderá a diferença entre processamento síncrono, assíncrono e em lote, quando o lote é a escolha certa, e um fluxo robusto que corresponde com confiança ao custom_id e aos resultados.
Três modos de trabalho
modo
Como funciona
atraso
Custo típico
trabalho adequado
síncrono
Você faz uma solicitação e aguarda a resposta
segundos
Padrão
Bate-papo ao vivo, assistente instantâneo
assíncrono
Você coloca o trabalho na fila e é notificado quando ele terminar.
Segundos-minutos
Padrão
Tarefas em segundo plano, etapas de automação
Lote
Envia milhares de solicitações em um pacote e obtém os resultados
Minutos-horas
Geralmente com desconto
Trabalhos de alto volume e tolerantes a atrasos
O processamento em lote é o seguinte: você envia centenas/milhares de solicitações como um único "trabalho" para o provedor; O provedor os processa em seu próprio ritmo e retorna todos os resultados em massa depois de concluídos. Em troca, você obtém duas coisas: (1) custo unitário geralmente mais baixo, (2) a capacidade de movimentar grandes volumes sem ter que lidar com limites de velocidade. O preço é que os resultados não vêm instantaneamente, mas depois de algum tempo.
Quando lotear, quando não?
A decisão se resume a uma pergunta: o usuário está aguardando o resultado agora?
- Não, posso segurá-lo → candidato em lote. Marcação noturna, resumo de lote, classificação de arquivo, enriquecimento de dados, execução de avaliação (eval).
- Sim, aguardando na tela → sincronizar. Chat ao vivo, aconselhamento instantâneo, ajuda no preenchimento de formulários.
Dica: Dois modos podem coexistir no mesmo produto. O usuário trabalha de forma síncrona no chat ao vivo; À noite, você entrega todas as conversas daquele dia ao lote para análise de qualidade. Separar a “necessidade viva” da “necessidade coletiva” é a primeira decisão da arquitetura.
Anatomia do fluxo de lote robusto
A regra técnica mais importante do processamento em lote é a correspondência de resultados.
- Dê a cada solicitação um `custom_id` exclusivo. Este é o seu ID gerado que identifica a solicitação (por exemplo, fatura-2026-07-18-000431).
- Envie o trabalho. Todas as solicitações vão em um pacote; cada um com seu próprio custom_id.
- Pesquise a situação. Você solicita o status em intervalos até que o trabalho esteja “concluído”.
- Combine os resultados com `custom_id`. Os resultados poderão ser devolvidos numa ordem diferente da ordem de submissão; portanto, nunca combine por posição, mas pelo custom_id que cada resultado carrega.
- Verifique o tipo de cada resultado. Uma solicitação pode ser bem-sucedida, outra pode falhar, outra pode expirar. Processo baseado em sucesso/fracasso.
{ "requests": [ { "custom_id": "invoice-000431", "params": { "model": "claude-haiku-4-5", "max_tokens": 128, "system": "Classificar fatura. Retornar somente JSON.", "messages": [{ "role": "user", "content": "{{invoice_text}}" }] } }, { "custom_id": "invoice-000432", "params": { "model": "claude-haiku-4-5", "max_tokens": 128, "system": "Classificar fatura. Retornar somente JSON.", "messages": [{ "role": "user", "content": "{{invoice_text_2}}" }] } } ]}
Cuidado: A correspondência de resultados com base na ordem de envio é o erro número um no lote. A fila não é preservada. Sem custom_id você não pode saber com segurança qual resultado pertence a qual documento – a correspondência errada leva silenciosamente a dados errados.
Modelos copiáveis
# regra de geração de custom_id (única e rastreável)Formato: <isture>-<date>-<sequence>. Exemplo: request-20260718-000431Regra: nunca repita no trabalho; Incorpore o ID do registro de recurso nele.
# Cartão de trabalho em lote (modelo de agendamento)Nome do trabalho: .............Número de registros: .............Modelo: ............. (trabalho simples → modelo rápido)Max_tokens por solicitação: .............Tolerância de tempo de entrega esperado: .........horasChave de correspondência de resultados: custom_idEm caso de erro: nova tentativa / fila / relatório
# Prompt de solicitação única em lote (curto e esquemático)Classifique este documento. Basta retornar este JSON, comentando:{"category":"...","urgency":"low|medium|high"}Documento: """{{document}}"""
# Pseudocódigo de processamento de resultado para cada resultado: if result.status == "success": record = find(custom_id) save(record, result.output) caso contrário: add_to_fail(custom_id, result.error) # então tente novamente
Prompt fraco / Prompt forte (design de trabalho em lote)
# FRACO (design frágil)Envie 10.000 documentos em ordem com o modelo forte, salve os resultados retornados na ordem em que chegam.
# FORTE (design durável) Envie 10.000 documentos em um lote com um modelo rápido. Dê a cada documento um custom_id exclusivo contendo o ID do registro de origem. Combine os resultados com custom_id; coloque os que falharam na fila e tente novamente. Execute na janela noturna; Tolerância de entrega 6 horas.
Versão poderosa; Ele pré-define a seleção do modelo, a chave correspondente, o tratamento de erros e o tempo. Esta é a diferença no processamento seguro de dezenas de milhares de registros.
Três Mini Estojos
Caso 1 — Marcação noturna. Uma equipe de comércio eletrônico classificaria 200.000 avaliações de produtos em tags de sentimento. A transmissão síncrona ao vivo estava sujeita a limites de velocidade e era cara. Eles levaram o trabalho noite adentro em lote com um modelo rápido; O custo unitário caiu, todo o conjunto ficou pronto pela manhã e não houve problemas de limite de velocidade.
Caso 2 — Confusão de ordens. Uma equipe de pesquisa abstraiu 5.000 artigos, mas escreveu os resultados em arquivos na ordem em que chegaram. Como os resultados foram retornados em uma ordem diferente, aproximadamente 900 dos 5.000 resumos estavam vinculados ao artigo errado. Eles remapearam para custom_id; problema resolvido e essa experiência se tornou regra permanente: "Sempre custom_id em lote."
Caso 3 — Espera ao vivo no modo errado. Uma equipe de suporte tentou fornecer em lote as respostas ao vivo que o usuário esperava na tela; Os usuários abandonaram porque os resultados chegaram minutos depois. Eles moveram o trabalho ativo de volta para sincronização, deixando apenas a análise noturna de qualidade no lote. Lição: o lote não é para espera ao vivo.
Erros comuns
- Resultados correspondentes por posição: A ordem não é preservada; Use custom_id.
- Transferindo trabalho ativo para lote: o usuário não pode esperar minutos; batch é para trabalhos tolerantes a atrasos.
- Não tratando casos de erro: algumas solicitações podem retornar com falha/expirada; Coloque-o em uma fila separada e tente novamente.
- Forte reflexo de uso do modelo em lote: Modelo rápido + lote é a combinação mais barata em trabalhos simples.
- Não tornar o custom_id rastreável: se nenhum registro de origem estiver incorporado no ID, será difícil vincular o resultado novamente.
- Esquecer de examinar a situação: Esperar resultados antes de terminar o trabalho; Verifique o status de conclusão.
Mais profundo: monitoramento de lote e gerenciamento de falhas parciais
O aspecto mais maduro do processamento em lote é que ele requer uma mentalidade diferente das chamadas individuais: um trabalho em lote é um “processo”, não um “evento”. Presumir que dezenas de milhares de solicitações serão bem-sucedidas é frágil; O design realista aceita falhas parciais desde o início. O status de cada resultado pode ser diferente: bem-sucedido, com falha (por exemplo, entrada inválida), cancelado ou expirado. Um fluxo robusto processa o status de cada resultado separadamente à medida que passa por ele, coloca as falhas em uma "fila de novas tentativas" separada e executa essa fila separadamente.
A segunda prática é projetar para idempotência (executar o mesmo trabalho duas vezes não causa nenhum dano). Se um lote for interrompido e você o reiniciar, não deverá reprocessar e gravar duas vezes os registros já processados. Vincular o custom_id ao seu registro de origem também funciona aqui: "este registro já foi processado?" antes de salvar o resultado. A verificação evita digitação dupla.
O terceiro ponto é escalonar as transmissões ao vivo em lote. Alguns trabalhos têm dimensões ativas e em lote: quando o usuário carrega um documento, você fornece um rápido resumo preliminar (síncrono) e reprocessa o mesmo documento para uma análise mais profunda à noite (lote). Separar conscientemente os dois modos otimiza a experiência do usuário e o custo.
Finalmente, o batching também é uma forma de lidar com limites de velocidade (unidade 8). O envio de alto volume no fluxo síncrono ao vivo produz a constante 429, enquanto o envio do mesmo volume para transferências em lote limita a pressão ao agendamento do próprio provedor e torna o trabalho mais previsível.
Resumindo
O processamento em lote geralmente é um modo mais barato e robusto para cargas de trabalho tolerantes à latência e de alto volume. Sua decisão foi “o usuário está aguardando o resultado agora?” determina a questão. A regra técnica mais crítica é fornecer a cada solicitação um custom_id exclusivo, combinar os resultados por ID em vez de localização e tratar o sucesso/falha de cada resultado separadamente.
Tarefa de aplicativo
Escolha um trabalho de alto volume (por exemplo, classificação de arquivo). (1) Decida se este trabalho é ao vivo ou coletivo e justifique-o. (2) Projete um formato custom_id (inclua o registro do recurso). (3) Preencha o cartão de trabalho em lote (modelo, max_tokens, tolerância, política de erros). (4) Escreva o pseudocódigo de processamento de resultados para incluir solicitações com falha.
lista de verificação
- [ ] Consigo distinguir os modos síncrono, assíncrono e em lote no eixo custo/atraso.
- [] Posso decidir se um trabalho é adequado para lote ou não fazendo a pergunta certa.
- [] Dou a cada solicitação um custom_id exclusivo e combino os resultados por ID.
- [] Posso lidar com resultados com falha/expirados separadamente.
- [] Conheço os benefícios de escolher um modelo rápido em trabalhos em lote simples.