5 Questões de Prática CCA-F: Engenharia de Prompt e Saída Estruturada (com Explicações)

Resposta correta: B

Categorias com altos falsos positivos minam a confiança em todo o bot, incluindo categorias precisas. Desabilitar temporariamente a categoria com falhas restaura a confiança dos desenvolvedores enquanto você itera no prompt offline e a reabilita quando a precisão for aceitável.

• Adicionar uma instrução extra para 'verificar duas vezes' está incorreto. Instruções vagas de auto-verificação raramente corrigem falsos positivos categóricos, e os desenvolvedores continuam vendo o ruído até que a precisão melhore mensuravelmente.
• Aumentar o tamanho do modelo está incorreto. A causa raiz são critérios ausentes/ambíguos no prompt; um modelo maior ainda aplica as mesmas regras vagas e a confiança não se recupera.
• Publicar achados como rótulos de baixa prioridade está incorreto. O ruído continua aparecendo no fluxo e os desenvolvedores continuam ignorando todo o bot; a degradação da confiança não é causada pela cor do rótulo, mas pelo sinal-ruído.

Resposta correta: D

Definir uma tool com seu JSON schema como input_schema e forçar o modelo a chamar essa tool (tool_choice = {type: 'tool', name: ...}) é a abordagem mais confiável para saída estruturada compatível com o esquema. O modelo produz a entrada da tool conforme o esquema declarado, eliminando erros de sintaxe JSON e problemas de chaves ausentes.

• Pedir em prosa simples está incorreto. Solicitações em texto livre por 'JSON válido' frequentemente produzem comentários adicionais, code fences ou pequenos erros de sintaxe que quebram parsers downstream.
• Preencher previamente o turno do assistente está incorreto. O prefill pode sugerir o formato mas não impõe esquema, e ainda produz texto que o parser deve validar (ao contrário do tool use, onde a saída do modelo é restrita por um esquema).
• Envolver a solicitação em tags XML está incorreto. Tagueamento XML melhora a clareza mas não fornece imposição; a resposta ainda é texto sem governança.

Resposta correta: A

A Message Batches API foi feita para cargas de alto volume e tolerantes a latência. Cobra 50% do preço padrão e processa lotes de forma assíncrona em uma janela de 24 horas, o que se encaixa exatamente em um trabalho noturno de extração de 50.000 documentos.

• Messages API síncrona padrão com solicitações paralelas está incorreto. Você paga o preço cheio e ainda precisa gerenciar concorrência, retentativas e rate limits.
• Messages API de streaming está incorreto. O streaming reduz a latência percebida em UIs interativas mas não reduz preço nem ajuda em throughput em massa.
• Files API com chamadas síncronas está incorreto. A Files API armazena documentos mas não oferece um nível assíncrono com desconto; você ainda paga preço cheio por requisição.

Resposta correta: B

A Message Batches API explicitamente não oferece garantia de latência; a maioria dos lotes termina em menos de uma hora, mas a janela documentada é de até 24 horas. Fluxos bloqueantes como verificações pré-merge exigem latência previsível e limitada e devem usar a Messages API síncrona.

• Os lotes não suportam saída JSON está incorreto. Qualquer requisição enviável à Messages API, incluindo tool use para JSON, pode ser enviada como requisição de lote.
• Os lotes custam mais do que as chamadas síncronas está incorreto. Os lotes são 50% mais baratos; o problema é a latência, não o custo.
• Os lotes exigem um nível enterprise pago está incorreto. A Batches API está disponível na API padrão; o acesso não é o obstáculo.

Resposta correta: B

Quando a instância revisora compartilha o mesmo histórico de conversa que a instância geradora, ela herda o raciocínio original e é tendenciosa a confirmar suas conclusões anteriores. Instâncias de revisão independentes que recebem apenas o código e os achados (sem o raciocínio anterior) capturam erros sutis de forma mais confiável.

• Consome 2x os tokens e gera timeout está incorreto. O uso de tokens é uma preocupação de custo, não a razão pela qual a auto-revisão perde falsos positivos.
• Claude se recusa a se autocriticar por segurança está incorreto. O modelo critica sua própria saída quando solicitado; o problema é viés, não recusa.
• A auto-revisão só funciona com extended thinking desativado está incorreto. Extended/adaptive thinking não altera o viés fundamental em favor do raciocínio anterior.