Few shot prompting: por que dar exemplos resolve antes de treinar modelo

Equipe Viver de IA · 2026-07-17

A maioria acha que IA erra por falta de treinamento. Quase sempre erra por falta de exemplo.

Treinar o modelo quase nunca é o problema

A crença mais cara que ouço de gestor é que a IA erra porque "não foi treinada pro nosso negócio". A conclusão vem colada: precisamos de fine-tuning, de um modelo customizado, de um projeto de meses. Na prática, o que trava a resposta não é falta de treino. É falta de exemplo dentro do pedido.

Quando você abre o ChatGPT e escreve "resuma esse e-mail", ele resume do jeito dele. Você queria três bullets, ele te deu um parágrafo. Você queria tom formal, ele veio informal. Aí você conclui que a ferramenta é burra. A ferramenta não é burra. Você não mostrou o que "resumir" significa pra você. Mostrar isso, com um ou dois exemplos, fecha a maioria dos casos antes de qualquer coisa mais complicada.

O que é few shot prompting, em português de gestor

Few shot prompting é dar exemplos prontos dentro do próprio pedido pra IA entender o padrão que você quer, sem treinar modelo nenhum. "Shot" aqui é exemplo. Zero-shot é pedir sem exemplo ("classifique esse comentário"). One-shot é dar um exemplo. Few-shot é dar alguns, dois, três, quatro, e deixar a IA imitar o padrão.

O mecanismo é simples de enxergar. A IA aprende a tarefa no ato de ler seus exemplos, não num processo de treinamento anterior.

Você mostra 2-3 exemplos → IA extrai o padrão → Você dá o caso novo → IA responde no mesmo molde

Pense num funcionário novo: dizer "faça um relatório" produz um resultado. Entregar dois relatórios antigos dizendo "faça igual a esses" produz outro, muito mais próximo do que você quer. A IA funciona na mesma lógica. Ela copia padrão com precisão e erra feio quando precisa adivinhar o que está na sua cabeça.

Como escrever os exemplos que funcionam

Quem começa trata exemplo como enfeite. O exemplo carrega a regra que você não consegue explicar em palavras. Se você quer que a IA classifique reclamações de cliente em "urgente" e "pode esperar", explicar o critério em texto é difícil. Dar seis reclamações já classificadas é trivial, e a IA pega a régua sozinha.

A estrutura de um bom prompt few-shot tem sempre a mesma anatomia:

1. Uma instrução curta do que você quer ("classifique cada mensagem abaixo").
2. De dois a quatro exemplos completos, cada um mostrando a entrada e a saída que você considera certa.
3. O caso novo, no mesmo formato dos exemplos, esperando resposta.

Detalhe que muda tudo: os exemplos precisam ter o mesmo formato que você espera de volta. Se você quer resposta em JSON, seus exemplos são em JSON. Se você quer três bullets, seus exemplos têm três bullets. A IA copia o formato antes de copiar o conteúdo. Por isso dar um exemplo aproximado não resolve: ela imita exatamente o que você mostrou, inclusive os defeitos.

Quantos exemplos usar

Menos do que você imagina. Pra tarefa de formato (resumir, classificar, reescrever num tom), dois ou três exemplos já entregam quase todo o ganho. A partir do quarto ou quinto, o retorno cai e você só está gastando espaço do prompt. Comece com dois, teste, e só adicione mais se a IA ainda estiver errando um caso específico. Quando isso acontecer, adicione um exemplo justamente daquele caso problemático.

Onde isso resolve de verdade

A maioria das tarefas repetitivas de escritório é problema de padrão, não de inteligência. E problema de padrão é exatamente o que few-shot resolve.

Na Costa e Savian Advogados, a IA entrou pra condensar e organizar grandes volumes de documentos financeiros e contábeis, funcionando como complemento ao trabalho dos advogados no aprimoramento de rascunhos. Esse tipo de tarefa, transformar documento bruto em rascunho no padrão do escritório, vive de exemplo: você mostra como um bom resumo de contrato se parece, e a IA replica em cima dos próximos cem. O resultado ali foi R$ 48.000 em economia anual gerada.

Outro terreno óbvio é o atendimento. No Centro Médico Alphaview, a jornada do paciente foi automatizada da confirmação de consulta em diante, chegando a 80%, 87% de automação. Grande parte dessa automação depende da IA responder no tom e no formato certo, e isso se ensina com exemplos de conversas boas, não com treinamento de modelo. Você cola dez atendimentos exemplares e a máquina aprende a voz da clínica.

O mesmo vale pra qualquer tarefa que hoje tem um funcionário fazendo "do jeito da casa": triagem de e-mail, padronização de proposta comercial, extração de dado de nota fiscal, resposta de primeiro nível no WhatsApp. Se existe um jeito certo que você reconhece quando vê, existe exemplo pra dar, e existe few-shot pra resolver.

Se existe um jeito certo que você reconhece quando vê, existe exemplo pra dar. E se existe exemplo, o problema não é treinar modelo.

Quando few-shot não basta

Seria desonesto vender exemplo como bala de prata. Tem casos onde ele não resolve, e reconhecer isso te poupa frustração.

• Quando a resposta depende de conhecimento que a IA não tem. Se a tarefa exige saber o conteúdo dos seus contratos, dos seus processos internos, do seu catálogo, exemplo não injeta esse conhecimento. Aí você precisa de RAG (a IA consultando sua base de documentos na hora de responder), não de mais exemplos.
• Quando o padrão é complexo demais pra caber em poucos exemplos. Se pra ensinar a tarefa você precisaria de trinta, cinquenta exemplos, o prompt fica gigante, caro e lento. Esse é o sinal de que talvez fine-tuning (aí sim, treinar o modelo com centenas de casos) faça sentido.
• Quando a saída precisa ser 100% confiável e você não pode revisar. Few-shot melhora muito o acerto, mas não garante. Pra decisão automática sem humano no meio, você precisa de mais camadas de validação.

Fine-tuning existe e tem lugar. Só que ele é o passo três, não o passo um. A ordem certa é zero-shot (pede direto), few-shot (dá exemplos), e só se ainda não resolver, você pensa em treinar. A maioria das empresas pula direto pro passo três porque soa mais sério, e paga caro por um problema que dois exemplos resolveriam.

O erro mais comum: exemplo enviesado

O tropeço que mais vejo não é dar exemplo demais nem de menos. É dar exemplo que não representa a variedade real do trabalho.

Imagina que você ensina a IA a classificar reclamações e todos os seus três exemplos são reclamações de entrega atrasada. A IA vai achar que quase tudo é sobre entrega. Quando chegar uma reclamação de cobrança errada, ela força a barra pra encaixar no padrão que você mostrou. Seus exemplos viraram uma lente torta.

A regra prática é escolher exemplos que cubram os casos diferentes, não os casos parecidos. Se existem cinco tipos de reclamação, seus exemplos mostram os cinco. Se um deles é raro mas importante, ele entra justamente por isso. Exemplo bom é o que ensina a fronteira, não o meio.

Tem ainda o vício de copiar exemplo com defeito. Se um dos seus exemplos tem um erro de digitação ou um formato inconsistente, a IA copia o erro. Ela não julga a qualidade do que você mostrou, ela imita. Revise os exemplos como se fossem o manual, porque é o que eles são.

Um passo a passo pra testar essa semana

Não precisa de projeto pra experimentar. Pega uma tarefa que alguém do seu time faz repetido e roda o teste você mesmo:

1. Escolha a tarefa: uma que tem "jeito certo" reconhecível, tipo resumir ata ou classificar e-mail
2. Junte os exemplos: pegue 3 casos reais já feitos do jeito bom, com entrada e saída
3. Monte o prompt: instrução curta, cole os 3 exemplos, depois um caso novo
4. Compare: rode o mesmo caso novo sem os exemplos e com eles, veja a diferença
5. Ajuste o que erra: se falhar num tipo específico, adicione um exemplo daquele tipo

Em meia hora você descobre se a tarefa é resolvível por exemplo. Na maioria das vezes é, e você acabou de economizar meses de conversa sobre "treinar um modelo".

O trade-off que fica

Few-shot te dá velocidade e controle a um custo: cada exemplo ocupa espaço no prompt, e prompt maior significa resposta um pouco mais lenta e um pouco mais cara por uso (o modelo cobra por volume de texto processado, confira a tabela oficial atual da ferramenta que você usa). Pra tarefa de baixo volume, isso é irrelevante. Pra tarefa que roda milhares de vezes por dia, esse peso acumula, e é aí que treinar o modelo passa a compensar, porque o modelo treinado não precisa dos exemplos toda vez.

Começar por exemplos evita gastar antes de saber se precisa gastar. Você valida a ideia com meia hora de trabalho em vez de um orçamento de projeto. Abre mão de eficiência máxima em escala pra ganhar agilidade e clareza agora.

Se você quer entender quais das suas tarefas cabem em exemplo e quais já pedem uma solução mais estruturada, dá pra mapear isso com o diagnóstico de IA antes de contratar qualquer coisa. E se preferir os fluxos já montados e rodando em vez de construir do zero, vale olhar as soluções prontas. O caminho certo quase sempre começa mais simples do que a vontade de complicar sugere.

Relacionados

Automação com IA: o guia completo

Soluções de IA prontas para empresas

Mais de 500 cases reais de IA

GPT-5.5 aguenta uma tarefa de 20 horas sozinho: o que muda pra quem opera no Brasil

Consultoria e o primeiro processo de IA: por que o relatório recorrente vence