Few-shot: testei 2/4/8/16/32 exemplos em 3 tarefas e a qualidade caiu depois de N
Todo guia de prompt engineering fala a mesma coisa sobre few-shot: “quanto mais exemplos, melhor”. Eu acreditei nisso por uns dois anos. Depois eu rodei o benchmark de verdade e a curva bateu na cara.
Peguei três tarefas distintas (classificação, extração estruturada, tradução PT→EN), rodei cada uma com 2, 4, 8, 16 e 32 exemplos few-shot no mesmo modelo, e medi F1, custo de tokens e latência. A hipótese “mais é sempre melhor” quebrou logo no segundo experimento. Cada tarefa tem seu próprio ponto ótimo diferente, e passar desse ponto não só não ajuda — piora o F1 e triplica o custo.
Este post é o registro cru do experimento. Se você está pagando 3x mais em tokens para ganhar 0,3 pontos de F1 (ou pior, para perder), talvez esteja escolhendo N no chute como eu estava.
Setup do experimento
- Modelo: Claude Haiku 3.5 (o preço público mais recente da Anthropic — 1M input tokens custa cerca de $0,80, 1M output cerca de $4,00)
- Tarefas: (1) classificação de sentimento em reviews, (2) extração de CNPJ/valor/data de recibos, (3) tradução PT-BR → EN técnico
- Ns testados: 2, 4, 8, 16, 32 exemplos few-shot
- Volume por config: 200 amostras por tarefa por N (3 × 5 × 200 = 3.000 chamadas)
- Métrica primária: F1 macro (classificação/extração) e chrF (tradução)
- Métricas secundárias: tokens gastos por resposta, tempo médio de resposta
Os prompts foram fixados no template padrão de Anthropic: system prompt curto, exemplos em pares Q/A, depois a query real. Os exemplos foram sorteados de um pool de 100 por tarefa, mesmo pool para todos os Ns.
O que a curva mostrou
Vou colocar o resultado primeiro, a explicação depois. O padrão foi limpo demais para ficar enfeitando.
| Tarefa | Melhor N | F1 no ponto ótimo | F1 em N=32 | Custo em N=32 vs N ótimo |
|---|---|---|---|---|
| Classificação sentimento | 4 | 0,89 | 0,86 | 3,2x |
| Extração recibos | 16 | 0,94 | 0,93 | 1,9x |
| Tradução PT→EN | 8 | chrF 62,4 | chrF 60,1 | 3,8x |
Três tarefas, três pontos ótimos diferentes: 4, 16 e 8. Nenhum bateu em 32. Em todos os três, empurrar N até 32 piorou a métrica de qualidade e multiplicou o custo por 2 a 4 vezes.
O manual da Anthropic sobre use examples já dá o recado que 3 a 5 exemplos “geralmente basta”; o OpenAI cookbook para few-shot classification também prefere números modestos. Mas na prática do dia a dia, eu ainda via prompts com 20+ exemplos, “porque não custa tentar”. Custa.
Por que cada tarefa tem um N diferente
O ponto ótimo não é aleatório — dá para prever pela dimensionalidade da decisão que o modelo precisa tomar.
Classificação de sentimento: N=4 é o suficiente
Sentimento é uma tarefa binária/ternária. O modelo precisa aprender o formato da resposta (retornar positivo/neutro/negativo, nada mais) e o critério (“sarcasmo entra como negativo”, “reviews neutros de fato existem”). Dois exemplos ensinam o formato, mais dois ensinam a nuance. Do quinto exemplo em diante, o modelo começa a overfittar em superficialidades dos exemplos mostrados — o comprimento típico da resposta, palavras específicas que apareceram nos exemplos — e a qualidade cai.
Em N=32, a curva de F1 desceu 3 pontos. Não é ruído; foi consistente ao longo das 200 amostras por config.
Extração de recibos: N=16 dá o formato completo
Aqui a tarefa é mais estrutural. O modelo precisa extrair CNPJ, valor e data em JSON, e recibos brasileiros vêm em dez formatos visuais diferentes. Cada exemplo few-shot cobre um formato. Menos de 16, o modelo erra na primeira variação que não viu; mais de 16, entra em loop de “eu vi um caso parecido” e mistura campos entre linhas.
Extração se beneficia mais de exemplos que classificação, mas nem aqui 32 venceu. Mais é melhor até ficar barulhento.
Tradução PT→EN: N=8 é o ponto de virada
Tradução técnica precisa aprender vocabulário específico (“acesso” → “access” em contexto de sistemas, não “log in”; “usuário” → “user”; “aplicativo” → “app”). Oito exemplos cobrem os principais padrões de vocabulário; passar disso, o modelo começa a imitar as construções sintáticas específicas dos exemplos em vez de traduzir a query — e o chrF cai porque o output fica “colado” no jeito de exemplo em vez de fluido.
Esse é o comportamento que a literatura chama de context poisoning por few-shot: os exemplos param de ensinar padrão e começam a impor um estilo.
O custo que ninguém coloca no cálculo
A parte que me deixou surpreso não foi o F1 cair — foi quanto de token eu estava desperdiçando por não ter medido.
| Tarefa | Custo médio por chamada em N ótimo | Custo em N=32 | Delta mensal (10k chamadas) |
|---|---|---|---|
| Sentimento (N=4) | R$ 0,003 | R$ 0,010 | +R$ 70 |
| Extração (N=16) | R$ 0,018 | R$ 0,034 | +R$ 160 |
| Tradução (N=8) | R$ 0,012 | R$ 0,046 | +R$ 340 |
R$ 570 por mês só nesses três casos, para piorar a qualidade. Multiplicado por um app com 100k chamadas/mês, vira R$ 5.700. Não é o tipo de vazamento que dashboard de cloud pega, porque não é um bug — é uma decisão de prompt design ruim que ficou embutida no código.
Como achar o seu N sem virar um projeto de pesquisa
Você não precisa rodar 3.000 chamadas para saber qual N usar. O que funcionou pra mim:
Passo 1: comece em N=3. Não em zero, não em dez. Três exemplos cobrem formato + variação mínima, e são o baseline realista pra maioria das tarefas.
Passo 2: rode 50 amostras em N=3 e em N=8. Se N=8 ganhou mais de 5 pontos de F1 (ou chrF, ou o que for a sua métrica), a tarefa se beneficia de mais exemplos — teste N=16. Se N=8 empatou ou perdeu, o ponto ótimo está em ≤3-8. Não vá mais alto.
Passo 3: mensure o custo por chamada em cada N. Se subir N vai melhorar 0,3 pontos e triplicar o custo, é uma escolha, não uma otimização.
Passo 4: aceite que não existe “melhor N universal”. O ponto ótimo depende da tarefa, do modelo (Haiku é diferente de Sonnet aqui), e da distribuição do seu dataset. Um valor fixo hardcoded no seu prompt vai envelhecer mal.
O que eu mudei no meu código
Depois dessa medição, mudei os prompts do harness que uso para revisão de PRs:
- Classificação de “esse comentário é blocking ou nit?” → N=3 (era N=10)
- Extração de “quais arquivos esse PR toca?” → N=8 (era N=15)
- Sumarização de PR → N=4 (era N=12)
Custo caiu 42% no bucket de prompts do harness. Qualidade medida pelo mesmo eval interno subiu ligeiramente (não é significativo, mas pelo menos não caiu). Continuo checando essas curvas a cada trimestre, porque cada release nova de modelo pode mover os pontos ótimos.
Few-shot é um dos poucos knobs em prompt engineering que têm um ponto ótimo real e mensurável. Vale medir antes de chutar. O manual da Anthropic estava certo em “3-5 costuma bastar” — só que a maioria dos guias que citei não. E eu era um dos que ia no automático em N=10 “por segurança”.
Segurança que custava R$ 570 por mês de aluguel silencioso.
Esse experimento é um recorte do capítulo sobre few-shot do livro Context Engineering (edição PT), onde eu detalho os prompts, os pools de exemplos e as tabelas completas de F1 por N.
ken imoto · WebRTC & Voice AI engineer · kenimoto.dev · TabNews
Livro relacionado Transformando LLMs de Mentirosos em Especialistas Engenharia de Contexto na Prática | RAG · MCP · CLAUDE.md · Agentic RAG, com benchmarks de ponta a ponta Ver a página do livro → Este artigo foi útil?