Few-shot prompting
Objetivos de aprendizagem
- Saber quando few-shot supera instruções detalhadas: consistência de formato e casos ambíguos (task statement 4.2).
- Construir 2–4 exemplos direcionados a cenários ambíguos, mostrando o raciocínio da escolha.
- Usar exemplos para demonstrar o formato exato de saída (location, issue, severity, suggested fix).
- Entender como exemplos ensinam o modelo a generalizar julgamento para padrões novos.
- Reduzir alucinação em extração cobrindo variedade de estruturas de documento nos exemplos.
Quando few-shot é a técnica certa
Few-shot prompting — incluir exemplos completos de entrada e saída no prompt — é a técnica mais eficaz quando instruções detalhadas sozinhas continuam produzindo saída inconsistente. Descrever um formato em prosa deixa margem de interpretação; mostrar o formato elimina essa margem. O mesmo vale para decisões ambíguas: é mais fácil demonstrar o julgamento correto do que descrevê-lo.
Dois usos principais cobrados na prova:
- Consistência de formato: um exemplo que mostra exatamente os campos esperados (ex.:
location,issue,severity,suggested fix) ancora todas as saídas seguintes naquele formato. - Casos ambíguos: exemplos que mostram a decisão correta e o porquê em situações onde duas ações seriam plausíveis (qual ferramenta chamar, se um gap de cobertura de testes merece flag, se um padrão de código é aceitável ou é bug).
2–4 exemplos direcionados, com raciocínio
Mais exemplos não é melhor. A recomendação da prova é 2 a 4 exemplos direcionados exatamente aos casos ambíguos observados, cada um mostrando o raciocínio de por que uma ação foi escolhida em vez da alternativa plausível. Exemplos direcionados a casos óbvios desperdiçam tokens e não corrigem o problema; dezenas de exemplos aumentam custo e podem enviesar o modelo para "pattern matching" superficial.
Generalização: bons exemplos não ensinam o modelo a repetir casos decorados — ensinam o princípio de julgamento, que o modelo aplica a padrões que nunca apareceram nos exemplos. Por isso a prova prefere "2–4 exemplos com raciocínio" a "um exemplo para cada caso possível" (impraticável e frágil).
Exemplos contrastivos: aceitável vs problema real
Para reduzir falsos positivos em revisão de código (Lição 2), a variante mais poderosa é o par contrastivo: um exemplo de código aceitável que não deve ser sinalizado ao lado de um exemplo do problema genuíno que deve — com a explicação da diferença. Isso desenha a fronteira de decisão de forma muito mais precisa do que qualquer prosa.
Few-shot em extração: reduzir alucinação e campos vazios
Em extração de dados de documentos heterogêneos, few-shot resolve dois sintomas clássicos:
- Alucinação de valores: um exemplo em que o documento não contém determinado campo e a saída correta traz
nullensina o modelo a não inventar (junto com schema de campos opcionais — Lição 4). Exemplos também mostram como normalizar medições informais ("uns 2kg" →2.0com flag de aproximação). - Variedade estrutural: se os documentos reais variam (citação inline vs bibliografia; tabela estruturada vs descrição narrativa; nota fiscal vs recibo manuscrito), os exemplos devem cobrir formatos representativos diferentes — um exemplo por estrutura típica. Extração vazia/errada em um formato específico é sinal de que falta um exemplo daquele formato.
import anthropic
client = anthropic.Anthropic()
# 2 exemplos direcionados: (1) formato tabular, (2) campo ausente -> null.
# Cada exemplo mostra o raciocínio e o formato exato da saída.
FEW_SHOT = """<example>
<document>
NF-e 8812 | Fornecedor: ACME Ltda | Total: R$ 1.240,50 | Venc.: 10/10/2026
</document>
<reasoning>
Documento tabular: total e vencimento explícitos. Converto R$ 1.240,50
para número decimal e a data para ISO 8601.
</reasoning>
<output>{"supplier": "ACME Ltda", "total": 1240.50,
"due_date": "2026-10-10", "payment_method": null}</output>
</example>
<example>
<document>
Recibo: recebi de Beta Corp a quantia referente aos serviços de setembro.
</document>
<reasoning>
Documento narrativo sem valor nem data. NÃO invento valores:
campos ausentes no documento saem como null.
</reasoning>
<output>{"supplier": "Beta Corp", "total": null,
"due_date": null, "payment_method": null}</output>
</example>"""
def extract(document: str) -> str:
response = client.messages.create(
model="claude-opus-5",
max_tokens=1024,
system="Você extrai dados de documentos fiscais. Siga os exemplos.",
messages=[{
"role": "user",
"content": FEW_SHOT
+ "\n\n<document>\n" + document + "\n</document>\n"
+ "Extraia no mesmo formato de <output>.",
}],
)
return next(b.text for b in response.content if b.type == "text")
print(extract("Boleto 991 - Gama S.A. - R$ 320,00 - vencimento 01/11/2026"))
Atenção: few-shot melhora consistência e julgamento, mas não é garantia sintática de JSON válido. Para garantir a sintaxe, combine com structured outputs (output_config.format) ou tool use com strict: true — Lição 4. As técnicas são complementares: o schema garante a forma; os exemplos garantem o conteúdo certo dentro da forma.
Pegadinhas da prova
- Distrator típico: "adicione 10–15 exemplos cobrindo todos os casos". A recomendação é 2–4 exemplos direcionados aos casos ambíguos; volume não substitui direcionamento e infla custo/latência.
- Distrator típico: exemplos que mostram só a resposta final, sem raciocínio. Para casos ambíguos, o exame valoriza exemplos que demonstram por que uma opção venceu a alternativa plausível.
- Distrator típico: tratar few-shot como se o modelo só soubesse repetir os casos mostrados ("não funciona porque cada documento é diferente"). Errado: exemplos bem escolhidos generalizam para padrões novos.
- Distrator típico: resolver campo obrigatório extraído vazio/incorreto apenas com "reforçar a instrução de preencher todos os campos" — a resposta esperada envolve exemplos com formatos variados de documento e/ou campos nullable no schema.
Resumo em 5 linhas
- Few-shot é a técnica mais eficaz quando instruções detalhadas continuam gerando saída inconsistente.
- Use 2–4 exemplos direcionados aos casos ambíguos reais, mostrando o raciocínio da escolha.
- Exemplos demonstram o formato exato de saída e ancoram consistência entre execuções.
- Pares contrastivos (aceitável vs problema real) reduzem falsos positivos e ensinam a fronteira de decisão.
- Em extração, exemplos com formatos variados e casos "campo ausente → null" reduzem alucinação.
Documentação oficial
Questões de fixação
1. Mesmo com instruções detalhadas, o agente de suporte escolhe a ferramenta errada em pedidos ambíguos (ex.: "problema com minha compra" pode ser pedido, cobrança ou entrega). Qual abordagem o exame considera mais eficaz?
Gabarito: B. Quando instruções detalhadas já falharam em casos ambíguos, o passo eficaz é few-shot direcionado com raciocínio — o modelo aprende o princípio de decisão e generaliza. A insiste na técnica que já falhou. C infla o prompt sem direcionamento (volume ≠ qualidade). D remove a decisão em vez de calibrá-la, quebrando os casos em que a ferramenta majoritária é a errada.
2. Um pipeline extrai dados de laudos técnicos. Quando o laudo usa medições informais ("aproximadamente dois metros"), o modelo inventa valores precisos; quando o laudo é narrativo, campos obrigatórios voltam vazios. Qual mudança de prompt ataca os dois sintomas?
Gabarito: C. Few-shot com variedade estrutural demonstra como tratar medições informais e como devolver null quando a informação não existe — exatamente os dois sintomas. A já é o tipo de instrução que falha sozinha (e "sempre preencha" até incentiva fabricação). B não muda o comportamento de julgamento. D resolve problemas de contexto longo, que não é o caso descrito.
3. Por que o exame recomenda incluir no few-shot um par "código aceitável que NÃO deve ser sinalizado" + "problema genuíno que deve"?
Gabarito: D. O par contrastivo mostra onde passa a linha entre aceitável e problema, e o modelo aplica esse julgamento a casos inéditos. A é invenção — não existe exigência de paridade. B é falso: exemplos consomem tokens. C descreve pattern matching decorado, o oposto do objetivo (generalização).
4. A saída do revisor de PRs varia de formato a cada execução, dificultando o parsing para postar comentários inline. As instruções já descrevem os campos desejados. Qual é o próximo passo mais eficaz?
Gabarito: A. Quando instruções em prosa já existem e o formato ainda varia, demonstrar o formato com um exemplo é o passo de maior retorno (e, para garantia sintática total, structured outputs — Lição 4). B é mais prosa vaga. C não influencia formato. D aceita o problema e cria manutenção frágil em vez de resolver a causa.