Quando exemplos vencem instruções

Você precisa classificar cada mensagem de suporte que chega como bug, billing, feature_request ou other. Você escreve a instrução com cuidado:

Classifique esta mensagem de suporte como bug, billing, feature_request ou other.
Responda apenas com a categoria.

Funciona, quase sempre. Aí você lê a saída e encontra Billing, "billing", feature request e uma resposta que começa com "Claro! Esta mensagem é sobre billing." São quatro jeitos de quebrar o parser que você escreveu em volta disso.

Você poderia continuar afiando a instrução: sem maiúsculas, sem aspas, underscore e não espaço, sem preâmbulo. Ou poderia parar de descrever a saída e mostrá-la:

Mensagem: Meu cartão foi recusado de novo.
Categoria: billing

Mensagem: O botão de exportar não faz nada no Safari.
Categoria: bug

Mensagem: Vocês podem adicionar modo escuro?
Categoria: feature_request

Mensagem: Meu cartão foi cobrado duas vezes este mês.
Categoria:

O problema de formatação some, porque agora o modelo completa um padrão em vez de interpretar uma descrição. Isso é prompting few-shot: você demonstra o mapeamento em vez de descrevê-lo.

O que o few-shot muda

O curso de nível Estágio "Prompting de IA: zero-shot" ensinou você a especificar com precisão: a assinatura do método, o formato de retorno, os casos extremos. Essa habilidade continua valendo aqui. Few-shot é o recurso para quando o que você precisa é difícil de dizer e fácil de mostrar.

Exemplos funcionam bem em três coisas.

Formato

Cada exemplo mostra o formato da saída, até o underscore. Não é preciso descrever nada.

Critérios implícitos

"Profissional, mas sem ser engessado" é um parágrafo de instrução que cada leitor entende de um jeito. Três exemplos do seu tom real resolvem a questão como nenhum adjetivo resolve.

Casos de fronteira

O seu time decidiu que "fui cobrado por um recurso que não funciona" é billing, e não bug. Isso é uma decisão de política; nada no texto da mensagem impõe essa resposta. Um exemplo registra a decisão.

Exemplos não servem para fornecer conhecimento. Mostrar três respostas corretas sobre os seus preços não ensina os preços ao modelo. Isso é recuperação, o assunto dos três cursos anteriores. Few-shot molda comportamento; recuperação fornece fatos. É a mesma divisão entre fine-tuning e recuperação, a um custo muito menor.

Zero, um, poucos

flowchart LR
  Z["Zero-shot: só instrução"] --> O["One-shot: + um único exemplo"]
  O --> F["Few-shot: + vários exemplos"]
  F --> D["Few-shot dinâmico: exemplos escolhidos por requisição"]

Os nomes só contam demonstrações, e avançar na fileira não melhora o resultado automaticamente. Cada passo acrescenta tokens de entrada a toda requisição e, a partir de certo ponto, só acrescenta custo. Onde o ganho para é algo que se mede, e esse é o assunto da aula 3.

A quarta caixa é onde este curso chega. Em vez dos mesmos exemplos fixos para todo mundo, você escolhe exemplos a cada requisição, com base na entrada. Isso é um problema de recuperação, resolvido com a busca vetorial que você levou três cursos construindo.

O custo, sem rodeios

Cada exemplo é token de entrada em toda requisição, para sempre:

só instrução                        ~50 tokens/requisição
instrução + 5 exemplos             ~400 tokens/requisição
× 100.000 requisições/mês          35.000.000 tokens extras/mês

É uma conta de verdade, e por isso o few-shot é uma troca, e não um upgrade de graça. Duas coisas deixam o custo menor do que parece. O cache de prompt, do curso de RAG, barateia muito um bloco estável de exemplos em requisições repetidas, desde que o prefixo em cache passe do tamanho mínimo do modelo (4.096 tokens no claude-haiku-4-5; prefixos menores ficam sem cache, sem aviso). E um bom conjunto de exemplos muitas vezes permite que um modelo menor faça o trabalho: cinco exemplos diante do claude-haiku-4-5 costumam vencer uma instrução seca diante de um modelo maior, com uma tarifa por token bem menor, que pode compensar os tokens extras dos exemplos.

O que este curso cobre

1. Quando exemplos vencem instruções (você está aqui).
2. A anatomia de um bom conjunto de exemplos.
3. Quantos exemplos, e quais.
4. Os três vieses: rótulo majoritário, recência e tokens comuns.
5. Quando um schema substitui os exemplos por completo.
6. Exemplos como dados: construindo isso em Rails.
7. Medindo, e evitando que apodreça.

A seguir: o que separa um conjunto de exemplos que funciona de um que ensina a coisa errada sem ninguém perceber.