O problema
Uma equipe precisa extrair dados estruturados de 50.000 contratos em PDF: partes envolvidas, valor, data de vigência, cláusulas de rescisão. Alguém roda um teste com 10 contratos, os resultados parecem ótimos, e a conclusão é "funciona, bora rodar tudo". Três semanas depois, uma auditoria encontra centenas de contratos com valores extraídos errados — não porque o modelo "piorou", mas porque os 10 exemplos testados não cobriam a variedade real dos documentos, e ninguém revisou uma amostra estatística do resultado final antes de confiar nele.
Essa lição junta dois problemas que parecem separados mas resolvem o mesmo risco: como processar volume sem gastar rios de dinheiro e como saber se o resultado é confiável antes de usá-lo. Os dois têm resposta arquitetural, não resposta de "confiar no modelo".
Batch processing: economia real, com um preço estrutural
Message Batches processa requisições de forma assíncrona com 50% de desconto em relação ao processamento padrão, dentro de uma janela de até 24 horas sem SLA de latência garantida. Isso muda o cálculo de decisão: batch é a resposta certa quando o volume justifica o corte de custo e a aplicação tolera não ter resposta imediata. Não é a resposta certa para um chat interativo, onde o usuário espera resposta em segundos.
Duas restrições estruturais valem a pena memorizar porque a prova gosta de testar exatamente essas duas: um batch não suporta múltiplas rodadas de ferramenta dentro da mesma requisição (não é o lugar certo para um loop agêntico complexo), e cada item do batch carrega um custom_id — é esse identificador, não a posição no array, que reconcilia requisição e resultado. Combinar resultado e requisição por posição de array em vez de por custom_id é um bug clássico quando itens falham fora de ordem.
Um resultado bom não prova nada sobre os outros 49.999
O erro do cenário de abertura não foi técnico — foi estatístico. Testar 10 exemplos e generalizar para 50.000 documentos ignora que a distribuição real de contratos provavelmente tem formatos, idiomas de cláusula e estruturas que os 10 exemplos não cobriram. Confiabilidade não é uma propriedade que um teste pequeno prova; é uma propriedade que se mede com amostragem representativa, contínua, do resultado real.
O framework prático:
- Amostre depois, não só antes. Uma amostra aleatória do resultado final revisada por humano (ou por um segundo passe do modelo) detecta degradação que os exemplos de desenvolvimento nunca cobriram.
- Separe quem gera de quem revisa. Um segundo passe que roda com o mesmo prompt, no mesmo contexto, tende a repetir o mesmo erro do primeiro — porque herda o mesmo viés. Um revisor independente, com instruções voltadas para encontrar problema em vez de confirmar resultado, pega erros que a passagem original não veria.
- Classifique a falha antes de reenviar. Nem toda falha em um item de batch é igual. Um erro de rate limit no meio do processamento pede reenvio do item; um erro porque o documento estava corrompido ou fora do escopo esperado não deveria ser reenviado às cegas — reenviar sem classificar a causa desperdiça outro ciclo de custo no mesmo problema.
O revisor independente não é luxo, é o controle
O distrator mais comum em cenário sobre este tópico é propor "rodar o mesmo prompt duas vezes e comparar" como controle de qualidade. Isso detecta inconsistência entre as duas rodadas, mas não detecta um erro sistemático que as duas rodadas cometem igualmente — se o prompt tem um viés (por exemplo, sempre extrai a primeira data que aparece no documento, mesmo quando não é a data de vigência), rodar duas vezes só confirma o mesmo erro duas vezes.
Um revisor de verdade tem um objetivo diferente do gerador: não é "produzir a extração", é "encontrar motivo para rejeitar a extração". Esse reposicionamento de objetivo é o que separa uma revisão real de uma segunda opinião enviesada pelo mesmo raciocínio.
Coloque em prática
O laboratório desta lição implementa um pipeline de classificação de resultados de batch: dado um conjunto de itens processados com seus custom_id, status e motivo de falha, ele separa o que deve ser reenviado do que precisa de intervenção humana — e simula um passe de revisão independente sobre uma amostra do resultado bem-sucedido.