O que é Acúmulo de Exemplos?
Acúmulo de Exemplos (Few-Shot Hoarding) é um smell de IA, ou seja, um sinal de problema em sistemas com LLM, do grupo Inchaços. O prompt tem 30 exemplos fixos e ninguém lembra por que cada um está lá.
Preparação para entrevista
Acúmulo de Exemplos
Few-Shot Hoarding
Acúmulo de Exemplos (Few-Shot Hoarding) é um smell de IA, ou seja, um sinal de problema em sistemas com LLM, do grupo Inchaços. O prompt tem 30 exemplos fixos e ninguém lembra por que cada um está lá.
- Elemento
- 05/37
- Nível
- Iniciante
- Leitura
- 4 min
- Atualizado
Como reconhecer
Um classificador de tickets começou com 4 exemplos. Cada reclamação de “classificou errado” virou um exemplo novo no prompt. Hoje ele tem 31 (trecho anonimizado):
Exemplo 1: "não consigo logar" -> acesso
Exemplo 2: "esqueci a senha" -> acesso
Exemplo 3: "senha não funciona" -> acesso
...
Exemplo 17: "boleto vencido, posso pagar?" -> cobrança # adicionado em mar/25, cliente X
Exemplo 18: "boleto venceu e o acesso bloqueou" -> acesso # adicionado em mai/25, ?
...
Exemplo 31: "app fecha sozinho no Android 9" -> bugOs exemplos 17 e 18 são quase iguais e ensinam respostas diferentes. Ninguém lembra por que o 18 entrou. Nove exemplos são variações de “não consigo entrar”. A fila de faturamento, que é a mais difícil, tem dois.
Sinais de Acúmulo de Exemplos:
- O prompt carrega dezenas de exemplos fixos.
- Cada bug corrigido virou um exemplo, sem remover nenhum.
- Há exemplos quase iguais, às vezes com respostas diferentes.
- A distribuição de exemplos não segue a dificuldade: casos fáceis têm muitos, difíceis têm poucos.
- Ninguém sabe dizer o motivo de cada exemplo.
- Tirar um exemplo dá medo, porque não há eval.
flowchart LR
B(["1. Erro reportado"]):::io --> E["2. Mais um exemplo no prompt"]:::tool
E --> P[("3. 31 exemplos fixos")]:::store
P --> M(["4. Modelo segue os mais parecidos, nem sempre os certos"]):::llm
M --> B
- Um ticket é classificado errado.
- A correção rápida é colar aquele caso como exemplo.
- O conjunto cresce sem curadoria, com redundâncias e contradições.
- O modelo imita os exemplos mais próximos, e exemplos contraditórios geram erros novos.
Por que acontece
- Exemplo é a correção mais fácil. Colar o caso que falhou resolve aquele caso na hora.
- Funciona no curto prazo. O caso corrigido passa, e o efeito nos outros não é medido.
- Os exemplos estão no código. Não há um lugar para revisar, versionar e remover.
- Sem dono. Quem acrescentou o exemplo 18 saiu do time.
A armadilha: tratar o prompt como caderno de incidentes. Cada reclamação ganha uma linha, e o caderno nunca perde página. Sem eval, ninguém descobre que nove exemplos de login não melhoram a fila de boleto.
Um caso concreto: o ticket “boleto venceu, app bloqueou” deveria ir para cobrança se a regra nova do produto for essa. Com o exemplo 18 ainda no prompt, a saída mais próxima continua “acesso”. Você não tem um bug de modelo. Tem um exemplo velho ganhando da regra nova porque está mais perto do texto de entrada.
Quanto custa ignorar
- Custo e latência. Dezenas de exemplos em toda chamada pesam na entrada.
- Qualidade. Exemplos contraditórios confundem; o modelo pode copiar o exemplo errado.
- Viés. A distribuição dos exemplos puxa as respostas para as categorias com mais exemplos.
- Manutenção. Mudar uma regra de negócio exige achar e corrigir todos os exemplos que a contradizem.
Uma conta para o viés
Os números abaixo são ilustrativos. Suponha 80 tokens por exemplo. Trinta e um exemplos são cerca de 2.500 tokens em toda classificação.
| Categoria | Exemplos no prompt | Dificuldade real (opinião do time) |
|---|---|---|
| acesso | 9 | baixa |
| bug | 6 | média |
| cobrança / boleto | 2 | alta |
| outros | 14 | mista |
O classificador vê “entrar” o tempo todo. Um “boleto venceu e o acesso bloqueou” puxa para acesso porque há mais vizinhos nessa fila. Você paga 2.500 tokens para ensinar o caso fácil demais e o caso difícil de menos.
Se a regra de negócio mudar (boleto vencido com app bloqueado passa a ser cobrança, não acesso), os 31 exemplos viram 31 linhas para caçar no diff.
Tratamento
| Refatoração | Escolha quando |
|---|---|
| Mover Exemplos para um Dataset | Sempre que os exemplos passam de um punhado. Eles saem do prompt para um conjunto versionado, curado, e são escolhidos por similaridade a cada pedido. Destinos: Seletor de Exemplos e Dataset de Ouro. |
Ordem prática:
- Monte um eval com os incidentes que geraram os exemplos. Sem isso, você não sabe o que pode apagar.
- Deduplique. Dois exemplos quase iguais com rótulos diferentes são um bug de dados, não um recurso.
- Balanceie por dificuldade, não por volume de reclamação. A fila barulhenta não precisa de nove cópias.
- Deixe no prompt só o formato (um ou dois exemplos) ou selecione 3 a 5 vizinhos por pedido.
Erro novo não volta para o prompt no mesmo dia. Entra no eval. Se o eval cair, aí sim você discute se falta um exemplo, uma regra, ou uma categoria nova.
O que você ganha
- Um prompt de tamanho fixo, com os 3 a 5 exemplos mais relevantes para cada entrada.
- Exemplos com dono, motivo e data, revisáveis em pull request.
- Contradições encontradas e resolvidas na curadoria.
- Erros novos viram casos de eval, não exemplos colados às pressas.
Quando ignorar
- Poucos exemplos estáveis. Cinco exemplos bem escolhidos, que cobrem os casos e não mudam há meses, são um bom prompt.
- Tarefa com formato rígido. Quando o exemplo serve para ensinar formato e todos são equivalentes, um ou dois bastam.
É esse smell?
Perguntas rápidas
Como corrigir Acúmulo de Exemplos?
Com Mover Exemplos para um Dataset. Cada refatoração traz o passo a passo seguro, com eval antes e depois.
Onde Acúmulo de Exemplos aparece na prática?
Nos cenários reais Tutor educacional.
Leia a seguir
RefatoraçãoMover Exemplos para um DatasetTirar exemplos do código e guardar em um conjunto versionado, escolhido na hora certa.Para ir além
Relações
- Refatorações que tratam 1
- Aparece nos cenários 1