O que é prompt one-shot?

Prompt one-shot é dar ao modelo exatamente um exemplo da tarefa antes de pedir a tarefa de verdade. Fica entre o prompt zero-shot, que não dá nenhum exemplo, e o prompt few-shot, que dá vários. O nome vem do “shot” que significa exemplo, e é um dos formatos básicos de prompt baseado em exemplo.

A parte interessante é que um exemplo já muda bastante o resultado, e por um motivo que não é o óbvio. A maioria das pessoas coloca o exemplo achando que está ensinando o modelo a fazer a tarefa. Não é isso que acontece. O que o exemplo faz melhor é mostrar como a resposta deve sair.

Por que um exemplo já resolve tanta coisa

Pense em como você pediria isso sem exemplo:

Extraia o nome do cliente e o valor do pedido deste e-mail. Responda em JSON com os campos nome e valor. O valor deve ser número, sem símbolo de moeda. Se não encontrar, use null.

Agora com exemplo:

Extraia o nome do cliente e o valor do pedido.

E-mail: “Oi, sou a Marina Costa, queria confirmar o pedido de R$ 1.240,50.” Resposta: {"nome": "Marina Costa", "valor": 1240.50}

E-mail: “…”

O segundo é mais curto e deixa menos coisa em aberto. Você não precisou dizer que o valor vai sem símbolo, nem que o separador decimal é ponto, nem que o JSON não vem dentro de bloco de código. O exemplo mostrou.

Isso é o que chamam de aprendizado em contexto, e vale registrar o que ele não é: o modelo não aprendeu nada de forma permanente. Os pesos dele não mudaram. Na próxima chamada, sem o exemplo, ele volta ao comportamento anterior. O exemplo só ocupou espaço na janela de contexto daquela requisição.

O que exatamente o exemplo ensina

Um exemplo carrega três informações de uma vez, e elas não têm o mesmo peso.

O formato da saída é o que o exemplo transmite melhor. Estrutura de JSON, tamanho de parágrafo, se tem markdown, se a resposta começa direto ou com uma frase de contexto — tudo isso o exemplo resolve sem você descrever.

O espaço de respostas possíveis vem em segundo. Se o exemplo classifica um ticket como cobrança, o modelo entende que existe um conjunto fechado de categorias, mesmo que você não tenha listado quais.

O registro de linguagem vem junto de carona. Um exemplo escrito de forma seca produz respostas secas. Um exemplo com emoji produz respostas com emoji. Isso costuma ser efeito colateral não intencional.

Há um resultado que vale conhecer aqui, e é contraintuitivo. Um trabalho de 2022 testou o que acontece quando você embaralha os rótulos dos exemplos — associa de propósito a entrada errada à saída errada — e o desempenho cai bem menos do que se espera¹. A leitura razoável é que o modelo usa o exemplo mais para calibrar formato e espaço de saída do que para aprender o mapeamento em si.

Isso não é permissão para escrever exemplo errado. É uma pista sobre onde investir atenção: gastar meia hora escolhendo o exemplo semanticamente mais representativo rende menos que garantir que o formato dele está exatamente como você quer a resposta.

Quando um exemplo não basta

O one-shot falha de forma previsível em alguns casos.

Quando existe fronteira ambígua. Se você está classificando ticket entre cobrança e financeiro, um exemplo mostra um dos dois lados. Ele não mostra onde a linha passa. Aqui você precisa de pelo menos um exemplo de cada lado da fronteira, e já saiu do one-shot.

Quando o caso normal e o caso de borda pedem tratamento diferente. Se o e-mail às vezes não tem valor nenhum, e o seu único exemplo tem valor, o modelo vai inventar um número em vez de devolver null. Ele aprendeu que a resposta sempre tem número.

Quando a tarefa é de raciocínio, não de formato. Para problema que exige vários passos, o que ajuda é mostrar o raciocínio, não a resposta. Isso é chain-of-thought, e um exemplo com o raciocínio inteiro escrito costuma ser mais útil que três exemplos só com a resposta final.

Existe também um efeito de calibração que atrapalha: com poucos exemplos, o modelo tende a favorecer o rótulo que apareceu por último ou o que apareceu mais vezes². Com um exemplo só, esse viés é máximo — não há nada para equilibrar.

Como escolher o exemplo

Na prática, o que funciona:

1. Pegue um caso médio. Não o mais simples, que ensina pouco, nem o mais estranho, que ensina o modelo a tratar tudo como exceção.
2. Escreva a resposta exatamente como você quer receber. Se você não quer bloco de código em volta do JSON, o exemplo não pode ter bloco de código.
3. Se existe caso vazio, mostre o caso vazio. Um exemplo em que o campo vem null vale mais que uma frase dizendo “use null se não encontrar”.
4. Teste com o exemplo trocado. Se a qualidade muda muito ao trocar o exemplo por outro equivalente, a sua tarefa é sensível a exemplo e você provavelmente precisa de few-shot.

O passo 4 é o que quase ninguém faz e é o mais informativo. Rodar o mesmo conjunto de 20 entradas com três exemplos diferentes leva alguns minutos e responde direto se one-shot é suficiente.

O custo

Um exemplo é a opção mais barata depois do zero-shot. Vale colocar isso em número, porque a decisão costuma ser tomada no escuro.

Os números são de uma tarefa de extração real e servem só para mostrar a ordem de grandeza. O que interessa é a proporção: sair de zero para um exemplo costuma custar pouco e resolver o problema mais comum, que é formato. Sair de um para cinco triplica o custo de entrada e só se paga quando existe ambiguidade real para desfazer.

Se o volume for alto e o prompt for estável, vale olhar prompt caching antes de cortar exemplo para economizar: o exemplo entra no prefixo estável e passa a ser cobrado uma fração do preço.

Não confunda com one-shot learning

Os dois termos apareceram em contextos diferentes e não significam a mesma coisa.

One-shot learning é anterior aos LLMs e vem de visão computacional. A ideia é treinar um modelo que reconheça uma classe nova a partir de um único exemplo rotulado — e ali há treino de verdade, com atualização de pesos.

Prompt one-shot não treina nada. Os pesos ficam congelados, o exemplo vive na janela de contexto e desaparece quando a requisição termina. A confusão é comum o suficiente para valer um artigo próprio.

Footnotes

1. Min et al. (2022) mostraram que substituir os rótulos corretos por rótulos aleatórios degrada bem menos do que se esperava, sugerindo que a demonstração serve principalmente para especificar formato e espaço de rótulos. ↩

2. Zhao et al. (2021) descrevem esse viés e propõem calibrar a saída antes de usá-la. ↩