Modulos
4.1
Prompts com Criterios Explicitos
Criterios explicitos, severidade, falsos positivos, categorias
~25 min · 6 topicos
4.2
Few-Shot Prompting
Exemplos direcionados, consistencia, casos ambiguos, formato
~25 min · 6 topicos
4.3
Saida Estruturada com tool_use
JSON schemas, tool_choice, campos opcionais, estrutura forcada
~30 min · 6 topicos
4.4
Validacao, Retry e Feedback Loops
Retry com feedback, detected_pattern, limites, erros especificos
~25 min · 6 topicos
4.5
Processamento em Lote (Batch API)
Message Batches API, economia 50%, custom_id, janela 24h
~20 min · 6 topicos
4.6
Arquiteturas de Revisao Multi-Instancia
Self-review, instancias independentes, multi-pass, confianca
~25 min · 6 topicosConteudo Detalhado
4.1
Prompts com Criterios Explicitos
Aprenda por que criterios explicitos superam instrucoes vagas e como definir severidade, lidar com falsos positivos e calibrar categorias de classificacao.
O que e: Criterios explicitos sao regras concretas e mensuráveis incluidas no prompt, como "flagueie se o valor exceder R$10.000" em vez de "flagueie valores altos". Instrucoes vagas como "seja conservador" ou "analise cuidadosamente" deixam a interpretacao aberta, gerando resultados inconsistentes entre chamadas.
Por que aprender: A principal causa de inconsistencia em saidas do Claude e a ambiguidade nos criterios. O exame CCA testa a capacidade de transformar requisitos vagos em criterios explicitos que produzem resultados reproduziveis.
Conceitos-chave: Criterios mensuráveis vs subjetivos, limiares numericos explicitos, definicoes operacionais, eliminacao de ambiguidade, consistencia entre chamadas.
O que e: Instrucoes como "seja conservador" ou "erre pelo lado da cautela" nao definem um limiar claro. Claude interpreta "conservador" de forma diferente dependendo do contexto, levando a resultados imprevisiveis. Um prompt pode produzir excesso de flags em um caso e omissoes em outro.
Por que aprender: Este e um anti-padrao classico testado no CCA. A solucao e substituir adjetivos qualitativos por criterios quantitativos: em vez de "seja conservador", especifique "flagueie transacoes acima de 2x a media historica".
Conceitos-chave: Ambiguidade de adjetivos qualitativos, inconsistencia entre chamadas, substituicao por limiares numericos, calibracao iterativa, reproducibilidade.
O que e: Falsos positivos ocorrem quando o sistema flageia itens que nao deveriam ser flagueiados. Em sistemas de classificacao ou revisao, excesso de falsos positivos faz os usuarios perderem confianca e passarem a ignorar os alertas — o efeito "cry wolf" que torna o sistema inutil.
Por que aprender: O exame CCA avalia sua capacidade de projetar prompts que equilibram sensibilidade e especificidade. Entender que falsos positivos destroem a confianca do usuario e fundamental para sistemas de producao.
Conceitos-chave: False positive rate, efeito cry wolf, erosao de confianca, trade-off precisao vs recall, calibracao de limiares.
O que e: Quando uma categoria de classificacao gera consistentemente falsos positivos, a abordagem recomendada e desabilita-la temporariamente enquanto se refina os criterios. E melhor ter menos categorias com alta precisao do que muitas categorias com alertas nao confiaveis.
Por que aprender: O exame testa cenarios onde categorias problematicas devem ser removidas em vez de ajustadas. A estrategia de desabilitar temporariamente e preferivel a manter categorias imprecisas em producao.
Conceitos-chave: Desabilitacao temporaria vs ajuste, precisao por categoria, rollback de categorias, analise de performance por classe, iteracao incremental.
O que e: Em vez de pedir para Claude classificar severidade como "alta/media/baixa", fornecer exemplos concretos de codigo para cada nivel. Por exemplo: "severidade alta = SQL injection sem sanitizacao", "severidade media = variavel nao utilizada em funcao critica", "severidade baixa = formatacao inconsistente".
Por que aprender: Definicoes de severidade sem exemplos sao interpretadas de forma inconsistente. O exame CCA testa a tecnica de ancorar niveis de severidade com exemplos de codigo reais para calibrar o julgamento do modelo.
Conceitos-chave: Ancoragem por exemplo, definicoes operacionais de severidade, calibracao com codigo real, escala consistente, eliminacao de subjetividade.
O que e: Criterios explicitos nao sao definidos de uma vez — eles sao refinados iterativamente. Analise os resultados, identifique padroes de erro (falsos positivos e negativos), ajuste os limiares e adicione exemplos para casos ambiguos. Cada iteracao melhora a precisao do sistema.
Por que aprender: O CCA testa a mentalidade de melhoria continua. Prompts de producao sao documentos vivos que evoluem com base em feedback real, nao artefatos estaticos definidos uma unica vez.
Conceitos-chave: Ciclo de refinamento, analise de erros, ajuste de limiares, adicao de edge cases, versionamento de prompts, metricas de qualidade.
4.2
Few-Shot Prompting
Domine a tecnica mais eficaz para consistencia: exemplos direcionados que demonstram formato, julgamento e tratamento de casos ambiguos.
O que e: Few-shot prompting e a inclusao de 2-4 exemplos completos de entrada e saida no prompt. E a tecnica mais eficaz para garantir que Claude produza saidas consistentes em formato e julgamento, superando instrucoes detalhadas sem exemplos.
Por que aprender: O exame CCA reconhece few-shot como a tecnica numero um para consistencia. Quando um sistema produz saidas inconsistentes, a primeira intervencao recomendada e adicionar exemplos ao prompt.
Conceitos-chave: Few-shot vs zero-shot, 2-4 exemplos como sweet spot, demonstracao por exemplo vs instrucao, consistencia de formato e julgamento.
O que e: Os exemplos mais valiosos no few-shot sao aqueles que demonstram como lidar com casos ambiguos — situacoes onde a resposta correta nao e obvia. Incluir um exemplo de caso limite mostra ao modelo como exercer julgamento, nao apenas seguir regras mecanicas.
Por que aprender: Casos ambiguos sao onde a maior inconsistencia ocorre. O CCA testa se voce sabe que exemplos devem priorizar edge cases sobre casos triviais para maximizar o impacto no comportamento do modelo.
Conceitos-chave: Exemplos de edge cases, demonstracao de julgamento, priorizacao de casos ambiguos, calibracao de fronteira de decisao.
O que e: Few-shot examples reduzem alucinacao ao ancorar o modelo em padroes concretos de resposta. Quando o modelo ve exemplos de "nao sei" ou "dados insuficientes", ele aprende que omitir informacao e aceitavel, reduzindo a tendencia de fabricar dados.
Por que aprender: Alucinacao e um risco critico em sistemas de producao. O exame CCA testa como few-shot pode ser usado nao apenas para formato, mas para ensinar ao modelo quando admitir incerteza.
Conceitos-chave: Ancoragem comportamental, exemplos de "nao sei", reducao de fabricacao, demonstracao de honestidade, calibracao de confianca.
O que e: A quantidade ideal de exemplos e 2-4. Menos de 2 nao estabelece um padrao confiavel; mais de 4 consome tokens excessivamente sem ganho proporcional. Cada exemplo deve ser direcionado — escolhido para cobrir um aspecto diferente do comportamento desejado, nao variantes do mesmo caso.
Por que aprender: O CCA testa a eficiencia no uso de tokens. Saber que 2-4 exemplos bem escolhidos superam 10 exemplos redundantes e essencial para sistemas de producao onde cada token conta.
Conceitos-chave: Sweet spot de 2-4 exemplos, diversidade sobre quantidade, custo por token, exemplos complementares, cobertura de cenarios distintos.
O que e: Exemplos few-shot servem como templates visuais do formato de saida esperado. Em vez de descrever "retorne um JSON com campos X, Y e Z", mostre um JSON completo preenchido. O modelo replica a estrutura exata vista nos exemplos, incluindo indentacao, ordem de campos e convencoes de nomenclatura.
Por que aprender: Descrever formatos em texto natural e propenso a ambiguidade. O CCA enfatiza que mostrar e superior a descrever para garantir conformidade de formato.
Conceitos-chave: Template visual, show don't tell, replicacao de estrutura, consistencia de formato, especificacao implicita por exemplo.
O que e: O valor maximo do few-shot esta em ensinar julgamento — como Claude deve decidir em situacoes nao triviais. Exemplos que incluem raciocinio ("este caso e severidade media porque X, embora Y sugira alta") transferem criterios de decisao, nao apenas formato de saida.
Por que aprender: O CCA testa a diferenca entre few-shot que ensina formato (superficial) vs few-shot que ensina julgamento (profundo). Exemplos com raciocinio explicito produzem decisoes mais consistentes em casos novos.
Conceitos-chave: Raciocinio explicito nos exemplos, transferencia de criterios, chain-of-thought embutido, calibracao de julgamento, generalizacao para casos novos.
4.3
Saida Estruturada com tool_use
Use tool_use com JSON schemas para garantir saida estruturada e confiavel. Entenda tool_choice, campos opcionais e a diferenca entre estrutura sintatica e semantica.
O que e: A combinacao de tool_use com JSON schemas e o metodo mais confiavel para obter saida estruturada de Claude. Em vez de pedir "retorne um JSON", voce define uma ferramenta com input_schema que especifica exatamente a estrutura esperada. Claude retorna os dados como parametros da ferramenta, garantindo conformidade com o schema.
Por que aprender: O CCA posiciona tool_use como a abordagem padrao para saida estruturada. Outras tecnicas (como pedir JSON no prompt) sao menos confiaveis e propensas a erros de formatacao.
Conceitos-chave: Tool_use como mecanismo de saida, input_schema JSON, conformidade automatica, eliminacao de erros de parsing, estrutura garantida.
O que e: O parametro tool_choice controla como Claude seleciona ferramentas: "auto" (padrao, Claude decide), "any" (Claude deve usar alguma ferramenta), ou {"type": "tool", "name": "X"} (forca uma ferramenta especifica). Para saida estruturada, forcar a ferramenta garante que Claude sempre retorne no formato desejado.
Por que aprender: O exame CCA testa quando usar cada opcao de tool_choice. Forcar uma ferramenta e essencial para pipelines onde a saida estruturada e obrigatoria, enquanto "auto" e melhor para agentes que precisam decidir.
Conceitos-chave: tool_choice: auto, any, tool com name, forcagem de ferramenta, garantia de formato, trade-off autonomia vs estrutura.
O que e: JSON schemas garantem que a saida seja sintaticamente valida (campos corretos, tipos corretos), mas NAO garantem correcao semantica. Um campo "revenue" pode ter o tipo "number" correto mas conter o valor errado. Schemas previnem erros de parsing, nao erros de raciocinio.
Por que aprender: E um erro comum assumir que saida estruturada = saida correta. O CCA testa essa distincao critica: schemas resolvem problemas de formato, mas voce ainda precisa de validacao semantica separada.
Conceitos-chave: Correcao sintatica vs semantica, validacao de tipo vs valor, limitacoes de schemas, necessidade de validacao adicional, erros de raciocinio vs formato.
O que e: Quando alguns dados podem nao existir no documento fonte, o schema deve usar campos opcionais (fora do "required") ou tipos nullable. Isso permite que Claude sinalize "dado nao encontrado" em vez de ser forcado a fabricar um valor para preencher um campo obrigatorio.
Por que aprender: Campos required sem alternativa nullable forcam alucinacao — Claude inventa dados para satisfazer o schema. O CCA testa o design de schemas que acomodam dados ausentes sem incentivar fabricacao.
Conceitos-chave: Optional vs required, tipos nullable, prevencao de alucinacao por schema, design de schema defensivo, sinalizacao de dados ausentes.
O que e: Forcar uma ferramenta especifica via tool_choice garante que Claude sempre retorne dados na estrutura definida pelo schema. Essa tecnica e usada em pipelines de extracao onde a saida precisa ser processada programaticamente — cada chamada retorna exatamente os campos esperados.
Por que aprender: Em pipelines de producao, saida inconsistente quebra o processamento downstream. O CCA testa quando usar forced tool vs auto, considerando que forced tool impede Claude de decidir que a ferramenta nao e necessaria.
Conceitos-chave: Forced tool via tool_choice, pipeline de extracao, saida deterministica, limitacao da autonomia do modelo, trade-off estrutura vs flexibilidade.
O que e: Cada campo no JSON schema pode incluir uma propriedade "description" que orienta Claude sobre o que colocar naquele campo. Descricoes como "revenue_usd: receita anual em dolares americanos, extrair do demonstrativo de resultados" sao instrucoes embutidas no schema que guiam a extracao.
Por que aprender: Descricoes de campos sao uma forma subestimada de engenharia de prompt. O CCA testa a combinacao de schemas com descricoes ricas para maximizar a precisao de extracao.
Conceitos-chave: Propriedade description no schema, instrucoes embutidas, orientacao por campo, combinacao schema + prompt, precisao de extracao.
4.4
Validacao, Retry e Feedback Loops
Implemente loops de validacao com feedback especifico, entenda quando retries funcionam e quando falham, e aprenda a detectar padroes de erro.
O que e: Quando a saida de Claude falha na validacao, o retry eficaz inclui feedback especifico sobre o que esta errado — nao apenas "tente novamente". Feedback como "o campo revenue retornou 0, mas o documento na pagina 3 mostra receita de R$4.2M" permite que Claude corrija o erro especifico.
Por que aprender: Retries sem feedback especifico frequentemente produzem o mesmo erro. O CCA testa a tecnica de incluir informacao diagnostica no retry para maximizar a taxa de correcao.
Conceitos-chave: Feedback especifico vs generico, diagnostico no retry, taxa de correcao, informacao contextual, loop de correcao.
O que e: Retries sao ineficazes quando a informacao nao existe no documento fonte. Se o dado nao esta no texto fornecido, Claude nao conseguira extraĂ-lo independentemente de quantas vezes voce tente. Neste caso, retries desperdicam tokens e podem forcar Claude a alucinar um valor.
Por que aprender: Saber quando parar de fazer retry e tao importante quanto saber quando fazer. O CCA testa a capacidade de distinguir entre erros corrigiveis (extracao incorreta) e impossibilidades (dado ausente na fonte).
Conceitos-chave: Distincao erro vs ausencia, retry futeis, risco de alucinacao forcada, limites de retry, fallback para null/ausente.
O que e: Incluir um campo como "detected_pattern" ou "reasoning" no schema permite que Claude explique seu raciocinio junto com os dados extraidos. Isso facilita o diagnostico: se o valor extraido esta errado, voce pode ver o raciocinio que levou ao erro e ajustar o prompt de acordo.
Por que aprender: Campos de diagnostico transformam saidas opacas em saidas depuraveis. O CCA testa a pratica de incluir campos de raciocinio que facilitam a identificacao e correcao de erros sistematicos.
Conceitos-chave: Campos de diagnostico, raciocinio explicito, depuracao de extracao, auditoria de decisoes, transparencia do modelo.
O que e: O padrao ouro de feedback de retry inclui tres elementos: o valor retornado ("revenue era 0"), a evidencia correta ("o documento na pagina 3 mostra 4.2M"), e a instrucao especifica ("extraia o valor correto do demonstrativo de resultados"). Essa combinacao maximiza a taxa de correcao.
Por que aprender: O CCA testa a formulacao de feedback de retry. A combinacao valor-errado + evidencia-correta + instrucao-especifica e o padrao que o exame espera como resposta ideal para loops de correcao.
Conceitos-chave: Triade valor-evidencia-instrucao, feedback acionavel, maximizacao de taxa de correcao, referencia a fonte, correcao guiada.
O que e: Definir limites de retry e criterios de abandono e essencial. Se apos 2-3 tentativas com feedback especifico o erro persiste, o problema provavelmente nao e corrigivel por retry — pode ser ambiguidade no documento, dado ausente, ou limitacao do modelo. Neste ponto, escalar para revisao humana ou marcar como incerto.
Por que aprender: Retries infinitos sao caros e podem degradar a qualidade (Claude comeca a adivinhar). O CCA testa a capacidade de definir limites pragmaticos e rotas de fallback para casos nao resolvidos.
Conceitos-chave: Limite de 2-3 retries, criterios de abandono, escalacao para humano, marcacao de incerteza, custo cumulativo de retries.
O que e: Um pipeline de validacao completo combina: extracao inicial com tool_use, validacao programatica (tipos, ranges, regras de negocio), retry com feedback especifico para erros detectados, limite de tentativas, e fallback para revisao humana ou marcacao de incerteza. Cada etapa tem criterios claros de passagem.
Por que aprender: O CCA testa a arquitetura completa de validacao, nao apenas tecnicas isoladas. Saber montar o pipeline end-to-end com cada etapa corretamente configurada e essencial para sistemas de producao.
Conceitos-chave: Pipeline end-to-end, extracao → validacao → retry → fallback, criterios de passagem, orquestracao de etapas, monitoramento de qualidade.
4.5
Processamento em Lote (Batch API)
Aproveite a Message Batches API para economia de 50%, entenda a janela de 24 horas, limitacoes e estrategias de correlacao e reenvio.
O que e: A Message Batches API permite enviar multiplas requisicoes de uma vez para processamento assincrono, com desconto de 50% no preco por token. Em vez de chamar a API uma vez por documento, voce envia um lote inteiro e recebe os resultados quando estiverem prontos.
Por que aprender: Para workloads de alto volume (extracao de centenas de documentos, classificacao em massa), a Batch API reduz custos pela metade. O CCA testa quando usar batch vs real-time e como dimensionar lotes.
Conceitos-chave: Message Batches API, desconto de 50%, processamento assincrono, lotes de requisicoes, economia em escala.
O que e: Resultados de batch sao entregues dentro de uma janela de ate 24 horas, sem garantia de latencia especifica. A maioria dos lotes completa em minutos a horas, mas nao ha SLA. Isso torna batch inadequado para cenarios que exigem resposta imediata, como revisao pre-merge em CI/CD.
Por que aprender: O CCA testa a capacidade de identificar quando batch e inadequado. Cenarios que exigem feedback rapido (pre-merge checks, chat interativo) devem usar a API sincrona mesmo com custo maior.
Conceitos-chave: Janela de 24h, sem SLA de latencia, inadequado para real-time, trade-off custo vs velocidade, planejamento de pipeline.
O que e: A Batch API nao suporta tool calling multi-turn — cada requisicao no lote e uma chamada unica sem continuacao. Isso significa que workflows agenticos (loop com multiplas chamadas de ferramenta) nao podem ser executados em batch. Tambem nao e adequada para pre-merge checks que precisam de feedback antes do merge.
Por que aprender: O CCA testa limitacoes especificas da Batch API. Saber que nao suporta multi-turn tool calling e essencial para evitar arquiteturas invalidas.
Conceitos-chave: Sem multi-turn tool calling, chamada unica por requisicao, inadequado para agentes, inadequado para pre-merge, single-shot extraction.
O que e: Cada requisicao no lote pode incluir um custom_id que e retornado no resultado, permitindo correlacionar qual resultado pertence a qual requisicao original. Por exemplo, usar o ID do documento como custom_id permite mapear resultados de volta para os documentos processados.
Por que aprender: Sem custom_id, correlacionar resultados com requisicoes em lotes grandes se torna impossivel. O CCA testa a pratica de incluir IDs de correlacao para rastreabilidade.
Conceitos-chave: custom_id como correlator, rastreabilidade de resultados, mapeamento requisicao-resultado, IDs de documento, processamento pos-batch.
O que e: Quando um lote completa, alguns itens podem ter falhado (erro de API, timeout, etc). A estrategia correta e reenviar apenas os itens com falha em um novo lote, nao reprocessar o lote inteiro. O custom_id permite identificar quais itens precisam de reenvio.
Por que aprender: Reprocessar lotes inteiros por causa de falhas parciais desperdicam recursos. O CCA testa a estrategia de reenvio seletivo como pratica padrao para batch processing.
Conceitos-chave: Reenvio seletivo, identificacao de falhas por custom_id, novo lote com itens falhados, eficiencia de reprocessamento, idempotencia.
O que e: Use Batch para: extracao em massa, classificacao de backlog, analise de documentos historicos. Use Real-time para: interacao com usuario, pre-merge checks, agentes com tool calling, qualquer cenario que exija resposta em segundos. A decisao principal e: o resultado pode esperar ate 24 horas?
Por que aprender: O CCA apresenta cenarios e pede para escolher entre batch e real-time. Saber aplicar o criterio de latencia vs custo e fundamental para arquitetar sistemas eficientes.
Conceitos-chave: Criterio de latencia, batch para background, real-time para interativo, custo vs velocidade, dimensionamento de workload.
4.6
Arquiteturas de Revisao Multi-Instancia
Entenda por que self-review e limitado, como instancias independentes melhoram a qualidade, e como implementar revisao multi-pass com scores de confianca.
O que e: Self-review — pedir para Claude revisar sua propria saida na mesma conversa — e limitado porque o modelo retem o contexto de raciocinio que levou a resposta original. Isso cria um vies de confirmacao: Claude tende a concordar consigo mesmo pois o raciocinio original ainda esta na janela de contexto.
Por que aprender: O CCA testa a compreensao de que self-review tem eficacia reduzida comparado a revisao por instancia independente. E um erro comum assumir que pedir "revise sua resposta" e suficiente para controle de qualidade.
Conceitos-chave: Vies de confirmacao, contexto de raciocinio retido, limitacao de self-review, independencia de revisao, mesma sessao vs nova sessao.
O que e: Usar uma segunda instancia de Claude (nova sessao, sem contexto da primeira) para revisar a saida produz resultados significativamente melhores. A instancia revisora ve apenas a saida + o documento original, sem o raciocinio que levou aquela saida, eliminando o vies de confirmacao.
Por que aprender: O CCA recomenda instancias independentes como padrao para revisao de qualidade. O exame testa cenarios onde self-review e apresentado como opcao e a resposta correta e usar instancia separada.
Conceitos-chave: Instancia revisora independente, eliminacao de vies, contexto limpo, revisao sem raciocinio original, custo adicional justificado.
O que e: Revisao multi-pass divide a verificacao em etapas: primeiro, revisao por arquivo (cada arquivo/documento e verificado individualmente), depois revisao cross-file (verificacao de consistencia entre arquivos, como totais que devem bater). Cada pass usa criterios diferentes e pode usar instancias diferentes.
Por que aprender: Revisao single-pass perde inconsistencias entre documentos. O CCA testa arquiteturas multi-pass que combinam verificacao local e global para maximizar a deteccao de erros.
Conceitos-chave: Revisao per-file, revisao cross-file, consistencia entre documentos, passes sequenciais, criterios diferenciados por pass.
O que e: A instancia revisora pode atribuir scores de confianca a cada campo verificado (ex: "confidence": 0.95 para campos com evidencia clara, 0.4 para campos inferidos). Esses scores permitem roteamento automatico: alta confianca passa direto, baixa confianca vai para revisao humana.
Por que aprender: Scores de confianca permitem automacao parcial com seguranca. O CCA testa a arquitetura de roteamento baseado em confianca para otimizar o balanco entre automacao e revisao humana.
Conceitos-chave: Confidence scores, roteamento por confianca, threshold de automacao, revisao humana seletiva, calibracao de scores.
O que e: Na pratica, a implementacao envolve: (1) primeira chamada de API gera a saida, (2) segunda chamada de API (nova sessao) recebe a saida + documento original + instrucoes de revisao. A segunda instancia nao tem acesso ao raciocinio da primeira, verificando a saida de forma independente.
Por que aprender: O CCA testa a implementacao pratica de revisao multi-instancia. Saber que sao duas chamadas de API separadas (nao continuacao da mesma conversa) e essencial para a arquitetura correta.
Conceitos-chave: Duas chamadas de API separadas, contexto limpo para revisor, instrucoes de revisao especificas, custo de 2x chamadas, ganho de qualidade.
O que e: A arquitetura completa combina: extracao com instancia 1, revisao per-file com instancia 2, revisao cross-file com instancia 3, scoring de confianca, roteamento (auto-approve ou humano), e retry para itens de baixa confianca. Cada etapa agrega qualidade ao resultado final.
Por que aprender: O CCA testa a visao sistemica de revisao multi-instancia. Saber conectar as pecas — extracao, revisao, scoring, roteamento — em uma arquitetura coerente e essencial para sistemas de alta qualidade.
Conceitos-chave: Pipeline extracao → revisao → scoring → roteamento, multiplas instancias, custo vs qualidade, automacao parcial com oversight humano, monitoramento end-to-end.