Few-shot e iteração: ensine por exemplos e compare versões

Regras descrevem o comportamento desejado; exemplos mostram como esse comportamento aparece em casos concretos. Few-shot prompting é a técnica de fornecer alguns pares de entrada e saída para orientar a tarefa. Nesta aula, você vai usar exemplos como material de especificação, não como decoração, e aprender a comparar versões sem confundir mudança de prompt com mudança de caso.

Imagine ensinar alguém a separar materiais recicláveis. A regra “papel limpo vai para o recipiente azul” ajuda, mas surgem fronteiras: caixa engordurada, recibo térmico, embalagem composta. Mostrar casos escolhidos revela distinções que uma frase geral pode esconder. O limite da analogia é que uma pessoa pode perguntar e construir uma regra duradoura; o modelo usa os exemplos apenas dentro do contexto recebido e ainda pode responder de forma inesperada.

Use exemplo para esclarecer uma decisão

Um exemplo precisa ter propósito. Na classificação de comentários, três casos fáceis mostram o formato, mas não resolvem uma mensagem como “não consigo pagar, onde peço ajuda?”. Ela contém problema e dúvida. A equipe precisa decidir qual categoria tem prioridade ou permitir mais de um rótulo. O exemplo de fronteira documenta essa decisão.

Comece com um contrato pequeno:

Categorias permitidas: elogio, dúvida, problema.
Quando a mensagem relatar falha que impede uma ação, use problema, mesmo que
também exista uma pergunta.

Depois acrescente somente exemplos que ensinam algo não evidente. Se dez frases quase iguais recebem “elogio”, elas consomem espaço sem ampliar a cobertura. Um conjunto melhor varia vocabulário, tamanho, tom e proximidade entre categorias.

Diferencie saída esperada de saída observada

No laboratório, as saídas foram escritas pela equipe do curso. Elas são fixtures, casos preparados para teste, e não foram geradas por um modelo. Essa distinção evita usar uma resposta anterior como verdade só porque parece plausível. Para cada exemplo, alguém responsável pelo domínio precisa confirmar o rótulo e o motivo.

Registre a origem: “criado para cobrir dúvida de endereço” ou “anonimizado e aprovado pela equipe”. Nunca copie conversa de cliente, prontuário, currículo ou documento interno sem base legal, necessidade e tratamento adequado. Trocar o nome não remove todos os identificadores; detalhes combinados podem reconhecer uma pessoa.

Um exemplo pode conter entrada, saída esperada e, quando necessário, uma nota curta sobre a decisão:

Entrada: "A cobrança apareceu duas vezes. Como resolvo?"
Saída esperada: problema | contém dúvida
Decisão coberta: falha financeira tem prioridade sobre a forma interrogativa.

A nota é para revisão do conjunto e pode nem entrar no prompt final. Separar material de teste de instrução de produção reduz o risco de ensinar explicações desnecessárias junto com o formato desejado.

Exemplos negativos precisam mostrar a correção

Um contraexemplo apresenta uma resposta inadequada e explica qual regra ela viola. Apenas mostrar erro pode reforçar o padrão ou deixar ambígua a alternativa. Em vez de “não escreva problema técnico”, diga que a categoria permitida é “problema” e mostre a forma correta. O foco continua no resultado, não em humilhar uma resposta.

Use contraexemplos com moderação. Se o formato correto cabe numa regra clara e dois exemplos positivos, uma galeria de erros aumenta custo e manutenção. Eles são úteis quando uma falha reaparece: categoria inventada, campo omitido, informação extrapolada ou tom incompatível com o canal.

Itere com uma comparação justa

Quando você altera prompt, modelo, exemplos e casos ao mesmo tempo, qualquer melhora fica sem causa conhecida. Guarde uma versão inicial, selecione casos e mude uma coisa. Rode a mesma coleção e registre quais critérios passaram. A resposta não precisa ser textual e perfeitamente igual; avalie categoria, campos, evidência e limites relevantes.

Uma ficha mínima de experimento pode ser:

Hipótese: o caso de fronteira reduzirá dúvidas classificadas como problema leve.
Mudança: adicionar um exemplo com falha de pagamento e pergunta.
Casos mantidos: 12, sem alteração.
Critério: categoria correta em todos os 4 casos financeiros.

Se o novo exemplo corrige quatro casos e piora mensagens simples, o resultado não é “melhor” sem ressalva. Você descobriu uma troca que precisa ser analisada. Talvez a regra esteja ampla, talvez as categorias sejam insuficientes ou a tarefa deva ser dividida.

No laboratório, acrescente um caso que combine elogio e problema. Decida a prioridade antes de escrever a saída esperada. Depois tente remover um dos três exemplos fáceis e veja se o contrato ainda é compreensível para uma pessoa. A interface apenas guarda e organiza o prompt; o teste contra modelos diferentes deve ser feito separadamente e seus resultados precisam ser identificados como observações, não como fatos universais.

O erro comum é escolher exemplos depois de ver a prova e ajustá-los até todos os casos conhecidos passarem. Isso produz memorização do conjunto, não confiança no uso real. Reserve casos que não entram no prompt, inclua fronteiras e atualize o conjunto quando novos padrões aparecerem. Você concluiu a aula quando cada exemplo tem uma decisão clara para ensinar e quando uma mudança pode ser comparada contra a mesma prova.