Prompt zero-shot, one-shot e few-shot

Três formas de ensinar durante a conversa

Em zero-shot, você descreve a tarefa sem demonstrar uma resposta. Em one-shot, inclui um único par entrada–saída. Em few-shot, fornece poucas demonstrações antes do caso novo. Todos são formas de aprendizado no contexto: o modelo usa padrões presentes naquela solicitação, sem ser treinado novamente.

O termo “shot” conta demonstrações, não perguntas anteriores nem quantidade de documentos. Um prompt pode conter muito contexto e continuar zero-shot se não houver exemplo da transformação esperada. Também pode ser few-shot com exemplos curtos e uma instrução pequena.

Essas categorias são um contínuo prático. A pergunta importante não é qual nome parece mais avançado, mas qual configuração atinge os critérios com menor complexidade, custo e risco.

Quando começar com zero-shot

Use zero-shot quando a tarefa é comum, a instrução é objetiva e o formato pode ser descrito diretamente: resumir um texto, traduzir uma frase, extrair uma data ou listar perguntas. Ele estabelece uma linha de base limpa e mostra o que o modelo já consegue fazer.

Escreva rótulos por extenso, defina critérios e inclua uma resposta para informação ausente. Em classificação, “positivo” pode significar sentimento, teste clínico ou aprovação; a definição elimina ambiguidade. Para saída estruturada, declare campos e tipos ou use schema nativo.

Se os erros se concentram em uma regra que cabe em uma frase, melhore a instrução antes de adicionar exemplos. Exemplos desnecessários aumentam custo e tornam a manutenção mais difícil.

O valor e o risco de um único exemplo

One-shot é eficiente para revelar estrutura, tom ou nível de detalhe. Um exemplo de ficha preenchida costuma comunicar melhor do que uma lista extensa de regras. É útil quando o formato é novo, mas a variação entre casos é pequena.

O risco é a supergeneralização. Se o único exemplo tem três tópicos, o modelo pode concluir que toda resposta deve ter três; se contém uma marca ou gênero, pode reproduzir esse traço sem necessidade. Escolha um caso representativo e explique quais propriedades devem ser copiadas.

Não use uma demonstração incorreta esperando que o modelo a corrija silenciosamente. Valide rótulo, cálculo, fonte e estilo. Quando a fronteira da tarefa possui exceções, migre para few-shot ou reescreva a política.

Como montar um conjunto few-shot

Cada demonstração deve conter uma entrada realista e a saída considerada correta. Cubra classes importantes, diferentes comprimentos e casos próximos à fronteira. Para classificação desbalanceada, não deixe a classe mais frequente dominar os exemplos; para extração, inclua campo ausente e formatos variados.

Mantenha o mesmo delimitador e a mesma estrutura em todas as demonstrações. Separe a instrução geral dos exemplos e marque claramente o caso que deverá ser resolvido. Ordem pode influenciar a resposta; teste ordens diferentes quando a decisão for sensível.

Poucas demonstrações boas superam um bloco grande de exemplos redundantes. Remova detalhes que não devem virar padrão e evite informações pessoais. Se o conjunto cresce continuamente, considere recuperação dinâmica de exemplos, ferramenta especializada ou fine-tuning.

• Inclua pelo menos um caso normal, um limite e uma ausência quando relevantes.
• Equilibre rótulos e diversidade de linguagem.
• Explique a propriedade comum que os exemplos demonstram.
• Revise se as saídas realmente obedecem à política atual.
• Mantenha exemplos separados dos dados não confiáveis do usuário.

Exemplos para formato, classificação e estilo

Em extração e formatação, as demonstrações devem mostrar campos, valores nulos, unidades e ordem. Em classificação, devem ensinar definições e fronteiras entre rótulos. Em redação, podem mostrar voz, densidade e estrutura, mas é melhor descrever também os princípios do estilo para evitar imitação mecânica.

Para tarefas numéricas ou lógicas, exemplos ajudam a indicar procedimento, porém não garantem cálculo correto. Combine com calculadora, código ou validação. Para conteúdo factual, uma demonstração com citação não prova que referências futuras serão reais; a fonte deve ser fornecida ou recuperada e conferida.

Em saídas destinadas a máquinas, use validação externa. O modelo pode reproduzir o JSON dos exemplos e ainda quebrar aspas, tipos ou enumerações em um caso raro.

Meça se os exemplos realmente ajudam

Compare zero-shot, one-shot e few-shot no mesmo conjunto de casos, mantendo modelo e parâmetros. Avalie exatidão, formato, consistência, latência, custo e erros críticos. Não escolha pela resposta mais bonita de um único teste.

Separe exemplos de demonstração dos exemplos de avaliação. Se você testa apenas os mesmos casos mostrados no prompt, mede cópia, não generalização. Preserve um conjunto oculto ou ao menos uma amostra nova para validação.

Analise por classe e segmento. A média pode melhorar enquanto um grupo raro piora. Registre falsos positivos, falsos negativos e recusas inadequadas de acordo com o impacto da aplicação.

Limites de contexto, seleção e manutenção

Exemplos ocupam a janela de contexto junto com instruções, documentos e resposta. Em tarefas longas, exemplos demais podem deslocar evidências importantes ou elevar latência. Comprima sem apagar distinções críticas e priorize demonstrações próximas ao caso novo.

Seleção dinâmica recupera exemplos semelhantes a cada entrada. Isso pode aumentar relevância, mas introduz uma nova etapa que precisa de avaliação: exemplos errados, manipulados ou com dados sensíveis podem contaminar a resposta. Controle a coleção, os metadados e o acesso.

Versione o conjunto. Quando rótulos ou políticas mudarem, exemplos antigos viram instruções conflitantes. Registre proprietário, data, origem e motivo de cada demonstração, e execute testes de regressão após alterações.

Few-shot não é fine-tuning

Few-shot fornece demonstrações em cada solicitação; o efeito termina com aquele contexto. Fine-tuning ajusta um modelo com um conjunto de treinamento e cria comportamento mais persistente. RAG recupera informação externa; ferramentas executam ações ou cálculos. São mecanismos diferentes e podem ser combinados.

Considere fine-tuning quando há muitos exemplos consistentes, formato ou estilo recorrente e ganho econômico em escala. Antes disso, construa avaliação, política de dados e linha de base por prompt. Fine-tuning não é a melhor forma de ensinar fatos que mudam frequentemente; fontes recuperáveis costumam ser mais adequadas.

Se o problema é falta de conhecimento atual, adicione fonte. Se é cálculo, use ferramenta. Se é regra determinística, escreva código. Escolher a arquitetura certa é mais importante do que multiplicar exemplos.

Checklist de decisão

Comece em zero-shot, observe erros e acrescente a menor intervenção capaz de corrigi-los. Use one-shot para um padrão simples e few-shot para fronteiras ou estilos que precisam de contraste. Reavalie sempre que o modelo, a política ou a população de entradas mudar.

1. Defina a métrica e crie casos de avaliação separados.
2. Teste uma instrução zero-shot clara.
3. Classifique os erros: conteúdo, formato, fronteira, fonte ou ferramenta.
4. Adicione uma demonstração apenas se ela tratar o erro observado.
5. Inclua diversidade e casos limítrofes, sem dados pessoais.
6. Compare ganho contra custo, latência e manutenção.
7. Versione exemplos e repita os testes após qualquer mudança.