Dê 300 anúncios de concorrentes para um modelo e ele devolverá quatro adjetivos: faça isto em vez disso

Você coleta trezentas headlines de concorrentes em uma biblioteca pública de anúncios e quer entender o que eles realmente estão promovendo. O caminho preguiçoso é colar tudo no chat e pedir: "resuma os argumentos de venda destes anúncios". A resposta vem rápido: eles destacam bom custo-benefício, enfatizam a experiência do usuário, criam urgência e mantêm um tom emocional positivo. Quatro linhas que você conseguiria escrever sem ler um único anúncio.

O problema não está nos dados. As bibliotecas de anúncios e centrais de criativos das plataformas são públicas, podem ser consultadas pela sua própria conta e nada está sendo contornado. O problema é a pergunta. Você entregou ao modelo uma questão agregada; ele só consegue devolver uma resposta agregada. Comprimir trezentos anúncios em quatro adjetivos gera uma taxa de compressão tão alta que toda a informação se perde. Sobram apenas afirmações verdadeiras e inúteis.

Para que a análise em massa de copy produza algo aproveitável, primeiro defina o que significa "aproveitável". Dizer que um anúncio "vende custo-benefício" não orienta nenhuma ação. Já dizer que há "uma promessa de economia, acompanhada de prova numérica e limite de tempo, combinação presente em 40% deste lote e direcionada a públicos sensíveis a preço" é acionável: você sabe exatamente quais variáveis ajustar no próximo criativo. Para chegar ao segundo tipo de resposta, não dá para fazer tudo de uma vez. É preciso dividir o processo em duas etapas.

Por que pedir um resumo dos argumentos de venda só gera generalidades

O fracasso da abordagem de etapa única é estrutural, não consequência de um prompt mal escrito.

Você está pedindo que o modelo execute simultaneamente duas tarefas de naturezas diferentes: extrair informações de cada anúncio e classificar as informações extraídas. A extração é determinística. Qual promessa o anúncio fez? Ele apresentou alguma prova? Em geral, existe uma resposta bem definida. Já a classificação exige julgamento. Decidir quais promessas pertencem à mesma categoria e onde ficam as fronteiras entre elas demanda raciocínio. Ao colocar as duas tarefas na mesma chamada, o modelo toma um atalho: pula a extração anúncio a anúncio, resume uma parede de texto por impressão geral e produz uma pilha de adjetivos positivos que imagina que você quer ler.

Além disso, a abordagem de uma só chamada não deixa nenhum artefato intermediário. Você recebe "destaca custo-benefício" como conclusão, mas não consegue rastrear quais anúncios levaram a ela, qual foi sua participação na amostra ou se havia contraexemplos. Execute de novo com um lote diferente e a conclusão muda. Uma análise sem produto intermediário não pode ser revisada nem aprimorada.

Transforme uma etapa em duas: extraia campos e depois agrupe

O caminho certo tem duas fases, conectadas por uma camada de campos estruturados.

Na primeira, extraia os campos de cada copy individualmente, seguindo um esquema fixo. Trabalhe ao menos com quatro dimensões: promessa central, tipo de evidência, mecanismo de urgência e público implícito. Essa etapa analisa um anúncio por vez e devolve JSON estrito, sem texto corrido.

You will receive one ad headline. Break it apart along the fixed fields below.
Output JSON only, no explanation.

<copy>
{{one piece of copy}}
</copy>

Fields and allowed values (pick only from the given enum; when unsure pick
unknown; do not invent values):

- promise: [save money, save time, look better, get healthier, make money,
  learn a skill, belong, identity, unknown]
- evidence: [testimonial, data/numbers, authority, before/after, demo,
  none, unknown]
- urgency: [time limit, scarcity, price-rise warning, fear of missing out,
  none, unknown]
- audience: a short phrase, inferred from the wording, for who it's talking to
  (e.g. "night owls", "moms with kids", "junior designers")

Output:
{"promise":"...","evidence":"...","urgency":"...","audience":"..."}

Depois de extrair trezentos anúncios, você terá trezentos registros estruturados, não trezentos blocos de texto. Nesse ponto, "resumir os argumentos de venda" deixa de ser uma tarefa semântica vaga e se torna um problema de dados: você pode contar, agrupar e visualizar distribuições.

A segunda fase é o agrupamento, mas o que se agrupa são os campos, não o texto original. Agrupar o texto bruto só traz você de volta à névoa da similaridade semântica. Agrupar campos significa trabalhar com um pequeno conjunto de dimensões discretas e limites claros.

Como agrupar os dados — e por que exigir contraexemplos

O ponto decisivo no prompt de agrupamento não é pedir apenas para "agrupar estes dados". É obrigar o modelo a trazer um contraexemplo.

Below are N ad headlines already extracted into structured records.
The categories are frozen. Do not add categories.

<records>
{{JSON array, each with promise/evidence/urgency/audience}}
</records>

Output three things in order:

1. Combination clustering
   Group by (promise x evidence x urgency), and give each group's record
   count and one representative sample.

2. Counterexample check
   For the top 3 groups by record count, pick one record per group whose
   audience clearly departs from the group's mainstream, and explain why it
   got grouped there. Is it really the same selling point, or did step one
   extract a field wrong?

3. Gaps
   Which combinations that should be common don't appear even once in this
   batch? Are those gaps "nobody's doing it" or "my sample didn't cover it"?

É na segunda seção que esse prompt mostra seu valor. O modelo tende naturalmente a concordar com você e, se não for pressionado, entregará clusters suspeitamente coerentes. Exigir que ele retire de um grupo que acabou de formar um registro que não parece se encaixar obriga uma checagem além do ponto em que ele já se considera satisfeito. Ou isso revela uma fronteira de classificação grosseira demais, ou mostra que algum campo foi extraído errado na primeira etapa.

Fazer o modelo questionar o próprio trabalho não serve apenas para análise de anúncios. Em engenharia reversa de código, isso é a seção de contraprovas: quando o modelo identifica uma família de algoritmos, você não aceita a conclusão por fé; pede que responda "em que ponto isto difere da implementação padrão". É o mesmo princípio que reduz a tendência do modelo a concordar com você ao lidar com código ofuscado e identificar assinaturas de algoritmos. No agrupamento de copy, a checagem de contraexemplos cumpre esse papel.

O modelo certo para cada etapa

As duas etapas exigem capacidades opostas. Usar o mesmo modelo em ambas é desperdício puro:

A diferença de custo de uma ordem de grandeza vem justamente dessa divisão. A extração de campos é a única etapa que escala linearmente com o volume: trezentos anúncios exigem trezentas chamadas; mil exigem mil. O agrupamento roda uma vez por lote. Coloque o nível de raciocínio mais caro no agrupamento, executado uma ou duas vezes, e o nível mais barato na extração, executada centenas de vezes, e a conta total muda por um fator de dez. Faça o contrário — modelo caro na extração e barato no agrupamento — e você cai no desperdício mais comum que já vi: a extração recebe mais raciocínio do que precisa, enquanto o agrupamento falha exatamente onde o modelo barato é mais fraco.

Não aceite apenas a estimativa de economia ao reduzir o nível do modelo. Rode uma comparação:

1. Separe de 20 a 30 anúncios entre os que você já coletou.

2. Na extração, passe o mesmo lote por claude-sonnet-5 e claude-opus-5 e compare os quatro campos registro a registro.

3. No agrupamento, use os mesmos registros extraídos nos dois níveis e observe duas coisas: a checagem de contraexemplos está realmente questionando os grupos ou apenas reafirmando a hipótese? E as lacunas indicam um próximo passo acionável?

4. A leitura do resultado é direta: se a concordância na extração for alta, reduza essa etapa ao nível barato e economize; se o nível barato não conseguir produzir um contraexemplo útil no agrupamento, essa etapa deve permanecer no nível de raciocínio.

Armadilha 1: deixar o modelo criar as próprias categorias

A armadilha mais fácil é não fornecer um enum na extração e deixar o modelo inventar as categorias.

Em um lote, tudo parece funcionar. O modelo retorna categorias com nomes razoáveis. O problema aparece no segundo lote: o mesmo tipo de copy recebe nomes diferentes, a granularidade muda e as fronteiras se deslocam. Você tenta colocar os dois lotes lado a lado para identificar uma tendência, mas eles já não se alinham. O "desconto" do primeiro lote equivale a "economizar dinheiro" no segundo? Ninguém sabe. Quando as categorias variam a cada lote, qualquer comparação entre lotes é artificial.

A solução é separar a definição das categorias de seu uso. Primeiro, use o nível de contexto longo para ler uma grande amostra de uma vez — centenas de itens por rodada, exatamente o tipo de tarefa para contexto longo — e induzir um conjunto de enums abrangente e consistente em granularidade. Depois, revise-o manualmente e congele-o. A partir daí, toda extração só pode escolher valores daquele enum fixo, usando unknown como categoria coringa e sem inventar rótulos durante o processo. A instrução do prompt de extração — "pick only from the given enum, do not invent" — materializa exatamente essa restrição.

Em uma frase: você define as categorias; o modelo apenas preenche os campos.

Armadilha 2: confundir frequência com eficácia

Depois de extrair e agrupar os dados, é natural ordenar os resultados pela quantidade de registros e tratar o argumento de venda mais frequente como o "mais eficaz". Esse raciocínio está errado de uma forma fácil de ignorar.

Frequência alta só diz que "todos estão escrevendo assim". Não diz que escrever assim funciona. O efeito de imitação na publicidade é real: um anúncio performa, em uma semana todo o mercado embarca na ideia e dezenas de headlines quase idênticas aparecem de um dia para o outro na central de criativos. Sua contagem inclui todos esses imitadores e conclui que aquele argumento é o mais popular, quando talvez todos estejam indo mal e ninguém tenha sido o primeiro a parar. Frequência mede conformidade, não resultado.

Para separar frequência de eficácia, você precisa associar dados de desempenho a cada registro. Cada criativo em uma biblioteca pública de anúncios traz campos como reproduções, curtidas, CTR e outros. O que você deve ordenar é "a proporção de uma combinação específica de argumentos de venda que atinge um percentil alto de desempenho", não a contagem bruta de registros. Como transformar retenção segundo a segundo e percentis de CTR em sinais relevantes é assunto de outro artigo. Aqui, vale reforçar um ponto: a tabela de frequência e a tabela de efeito precisam ser duas tabelas separadas. No momento em que você as mistura, a conclusão fica comprometida.

Nesta fase, o trabalho do modelo é atribuição, não ordenação. Envie ao nível de raciocínio intermediário uma combinação de alta frequência junto de sua distribuição de desempenho e pergunte: "essa frequência é alta porque funciona ou porque todos estão copiando uns aos outros?". Peça que ele julgue usando os números. Um erro de atribuição aqui custa pouco, pois a validação final continua sendo feita contra os dados reais de desempenho.

Armadilha 3: analisar apenas os vencedores

A terceira armadilha está escondida na fonte de dados e, se você não prestar atenção, passa despercebida: por padrão, a biblioteca de anúncios e a central de criativos mostram os anúncios que rodaram bem. Entradas como "hot ads" ou "Top Ads" são, na prática, sobreviventes que a própria plataforma já filtrou por desempenho.

Você agrupa uma pilha de vencedores, encontra "as características comuns dos anúncios de sucesso" e as copia. Isso é o clássico viés de sobrevivência, pois os anúncios que fracassaram podem muito bem ter exatamente as mesmas características. Imagine que 90% dos vencedores usaram "limite de tempo" e sua conclusão seja que limites de tempo funcionam. Mas, se 90% dos anúncios fracassados também usaram limites de tempo, esse recurso não tem poder algum de diferenciação. Ele é apenas um padrão do setor, sem relação com sucesso ou fracasso.

A correção é dar um grupo de controle aos vencedores. Em geral, uma biblioteca pública de anúncios permite filtrar por setor, objetivo de marketing e período. Use os mesmos filtros para encontrar criativos que receberam impressões, mas tiveram engajamento claramente baixo; extraia e agrupe esses dados também, colocando-os ao lado do grupo vencedor. O que importa não é "o que os vencedores têm", mas o conjunto de diferenças: "o que os vencedores têm e os perdedores não". Só vale incorporar ao próximo criativo uma característica que apareça nesse conjunto de diferenças.

Você não terá uma amostra completa dos perdedores, e tudo bem. Mesmo um pequeno grupo de controle de baixo desempenho é muito mais confiável do que uma conclusão baseada apenas em Top Ads.

O resultado deve ser uma tabela de variáveis, não um resumo

Se você percorreu as duas etapas e evitou as três armadilhas, o produto final não deve ser um parágrafo dizendo que "os concorrentes deste lote promovem XX". Isso só devolve você às generalidades. O resultado precisa ser uma tabela de variáveis:

• Quais valores cada dimensão assume: promessa, evidência, urgência e público.

• Quais combinações já foram validadas como eficazes, presentes no conjunto de diferenças e altas no percentil de desempenho.

• Quais combinações ninguém tentou ainda, identificadas na seção de lacunas.

Essa tabela pode alimentar diretamente uma tarefa de geração. As combinações comprovadamente eficazes servem para produzir variantes em escala; as combinações em aberto viram testes exploratórios de baixo custo. As variáveis de copy alimentam um modelo de texto para escrever roteiros, enquanto as variáveis visuais e de tom alimentam modelos de imagem e vídeo para gerar os criativos. Assim, fecha-se o caminho entre a copy dos concorrentes e a sua própria peça final. Essa tabela de variáveis é exatamente o que a etapa de briefing do pipeline criativo consome.

O objetivo do agrupamento não é criar um gráfico de classificação bonito. É produzir a tabela que orienta o próximo lote de produção.

Uma única chave para conectar os quatro níveis

O fluxo acima exige quatro níveis: um nível barato e de alta concorrência para extração, um nível de contexto longo para definir categorias, um nível de raciocínio para agrupamento e um nível de raciocínio intermediário para atribuição. Eles vêm de fornecedores diferentes, com SDKs, esquemas de autenticação e formatos de erro distintos. Integrar seu cliente a várias interfaces apenas para trocar de modelo entre etapas não vale o esforço. Esse é o verdadeiro motivo de tanta gente acabar usando um único modelo para tudo e cair no desperdício descrito antes: ou um nível caro queimando orçamento na extração, ou um nível barato incapaz de encontrar contraexemplos no agrupamento.

AIReiter simplifica essa camada: uma chave, uma interface compatível com OpenAI e os quatro níveis disponíveis por trás dela. Para trocar de modelo, basta alterar o campo model no corpo da requisição.

# Extract fields: the cheap high-concurrency tier
curl https://aireiter.com/api/v1/chat/completions \
  -H "Authorization: Bearer $AIREITER_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "claude-sonnet-5",
    "messages": [{"role": "user", "content": "<extraction prompt + one piece of copy>"}]
  }'

# Cluster: switch to the reasoning tier, leave the rest
#   "model": "claude-opus-5"
# Frequency attribution:
#   "model": "gpt-5.6-sol"

Se você já usa o SDK da OpenAI, aponte base_url para https://aireiter.com/api/v1 e não mude mais nada. No SDK da Anthropic, envie para POST /api/v1/messages usando a mesma chave.

Em preço, os modelos Claude têm 30% de desconto sobre o valor de tabela, e os modelos GPT custam metade. O desconto incide justamente sobre o principal custo deste fluxo. A extração de campos é a única etapa que escala linearmente com o volume: trezentos anúncios significam trezentas chamadas; mil, mil chamadas. Ela roda no nível Sonnet mais barato, com mais 30% de desconto, e concentra a maior parte da economia. Agrupamento e atribuição rodam poucas vezes por lote, portanto usar um nível de raciocínio nessas etapas não pesa. A definição de categorias usa o Kimi K3 de contexto longo, disponível com a mesma chave, uma vez por lote.

• Obtenha uma chave de API

• Teste sem criar uma conta: primeiro rode manualmente alguns anúncios, compare o nível barato e o de raciocínio quanto à concordância na extração e aos contraexemplos no agrupamento; depois, quando o processo estiver consistente, automatize-o.

Conclusão

A análise em massa de copy de anúncios vira uma massa de generalidades não porque o modelo seja fraco, mas porque você colocou extração e classificação na mesma chamada.

Divida o trabalho em duas etapas: extraia campos estruturados de cada anúncio contra um enum congelado, execute isso centenas de vezes no nível barato; depois agrupe os campos e obrigue o modelo a apresentar um contraexemplo, em uma única execução no nível de raciocínio. Ao longo do processo, evite as três armadilhas: não deixe o modelo inventar categorias no momento da extração, não interprete frequência como eficácia e dê um grupo de controle aos vencedores. Termine com uma tabela de variáveis que oriente o próximo lote de produção, não com uma frase como "destaca custo-benefício".

Nesse fluxo, o modelo exerce dois papéis diferentes: um extrator barato e um classificador disposto a questionar o próprio trabalho. Use cada um separadamente, no nível adequado, e algumas centenas de anúncios se transformam em insights acionáveis. Misture tudo em um único modelo e você só receberá adjetivos.