Embutir Etapa Trivial

Problema

Um passo do pipeline não muda o resultado de forma mensurável, mas custa uma chamada inteira. O caso mais comum é o smell Autocrítica Inútil: o modelo gera um texto e, na chamada seguinte, revisa o próprio texto sem receber nenhuma informação nova.

Imagine um portal de notícias que gera 10 mil resumos por dia. O pipeline tem duas chamadas: resumir e revisar. Quando o time compara as saídas, vê que a revisão devolve o rascunho idêntico, ou com uma vírgula trocada, na grande maioria dos casos. A segunda chamada virou um carimbo caro.

Solução

Remova a chamada que não muda o resultado e leve o que ela tinha de útil (um critério, um formato, uma checagem) para o passo vizinho ou para o código.

Antes e depois

 def write_summary(document):
-    draft = llm("Resuma o documento em até 150 palavras.", document)
-    reviewed = llm("Revise o resumo abaixo: corrija erros, deixe mais claro "
-                   "e garanta no máximo 150 palavras.", draft)
-    return reviewed
+    summary = llm("Resuma o documento em até 150 palavras. Mantenha nomes, "
+                  "números e datas exatamente como no original.", document)
+    if word_count(summary) > 150:
+        summary = truncate_to_sentence(summary, max_words=150)   # regra em código
+    return summary

Antes: duas chamadas, e a segunda quase sempre devolve a primeira.

flowchart LR
  D(["1. Documento"]):::io --> G(["2. Resumir"]):::llm
  G --> R(["3. Revisar o próprio resumo"]):::llm
  R --> OUT(["4. Resumo"]):::io

Depois: uma chamada com o critério útil incorporado, e a regra objetiva em código.

flowchart LR
  D(["1. Documento"]):::io --> G(["2. Resumir com o critério"]):::llm
  G --> C["3. Checar tamanho em código"]:::tool
  C --> OUT(["4. Resumo"]):::io

1. O mesmo documento entra.
2. O prompt de geração recebe o critério que a revisão tentava aplicar.
3. A parte objetiva (tamanho) vira código, que conta palavras sem errar.
4. O resultado sai com uma chamada a menos.

Por que funciona

Um passo de revisão sem informação nova lê a mesma coisa com o mesmo modelo e tende a concordar com ela. O que ele tem de valor costuma ser uma instrução que caberia no passo anterior (“mantenha os números exatos”) ou uma regra objetiva que o código faz melhor (“no máximo 150 palavras”).

Repare num detalhe do código antigo: a revisão recebe só o rascunho, não o documento. Ela não tem como saber se um número está certo. O máximo que consegue é reescrever, e cada reescrita é mais uma chance de trocar “R$ 1,2 milhão” por “R$ 12 milhões”.

A pesquisa aponta na mesma direção. O paper “Large Language Models Cannot Self-Correct Reasoning Yet” (Huang et al., 2023) mostrou que, sem um sinal externo, pedir ao modelo para revisar a própria resposta não melhora o raciocínio e às vezes piora.

Embutir o critério no passo que gera evita o erro em vez de tentar corrigi-lo depois. O gerador é quem vê o documento original, então é ele quem precisa ouvir “mantenha os números”. Passar a regra objetiva para o código troca uma chamada probabilística por uma checagem determinística.

A conta do passo trivial

Uma conta ilustrativa ajuda a ver onde o custo mora. Suponha um documento de 3.000 tokens e um resumo de 200.

	Entrada	Saída	Espera
Resumir	3.000 tokens	200 tokens	uma geração
Revisar	cerca de 250 tokens	200 tokens	mais uma geração inteira

A entrada da revisão é barata. O que pesa é a saída: o modelo escreve o resumo de novo, token por token. Tokens de saída costumam custar várias vezes mais que os de entrada, e são eles que definem quanto o usuário espera. Com 10 mil resumos por dia, são 2 milhões de tokens de saída extras para devolver quase o mesmo texto.

Checagem +20 XP de primeiraSeu pipeline gera um resumo e depois chama o mesmo modelo com 'revise o resumo abaixo', passando só o rascunho. O que essa revisão consegue garantir sobre os números do texto?

Que estão corretos, porque o modelo relê o texto com mais atenção

Nada: ela não vê o documento original, então não tem como conferir

Que estão corretos, desde que a revisão rode com temperatura zero

Passo a passo seguro

0. Meça. Rode o eval com o pipeline atual e guarde qualidade, custo e latência. Guarde também a saída antes e depois do passo suspeito, para cada caso.
1. Compare entrada e saída do passo. Conte em quantos casos a saída difere de forma relevante. Uma métrica simples basta para começar: a proporção de caracteres alterados. Se 95% dos casos mudam menos de 2%, o passo quase não trabalha.
2. Leia os casos que mudaram. A mudança melhorou, piorou ou só trocou palavras? Às vezes o pouco que muda é exatamente onde o passo estraga.
3. Rode o eval sem o passo. Se a qualidade não cai, ele é candidato a sair.
4. Liste o que o passo tentava garantir. Separe o que é critério (vai para o prompt anterior) do que é regra objetiva (vai para o código).
5. Mova o critério e a regra, e remova a chamada.
6. Meça de novo. Qualidade igual ou melhor, uma chamada a menos, latência menor. Confira também por categoria, não só a média.

Riscos

• O passo ajudava em casos raros. A média não mostra. Confira o eval por categoria e os casos difíceis.
• O prompt anterior incha. Se o critério movido é longo, avalie se o passo merecia virar uma checagem com sinal externo, como na Reflexão.
• Truncar em código pode cortar mal. Corte em fim de frase e registre quando o corte acontece. Se o corte é frequente, o prompt de geração precisa de ajuste.

Erro comum: jogar fora a revisão que tinha sinal

Nem toda revisão é trivial. O que separa as duas é a informação que o passo recebe.

Sinal	Passo trivial	Passo que vale manter
O que ele vê	Só a saída anterior	A saída e algo novo: o documento, um teste, um resultado de ferramenta
Quem julga	O mesmo modelo, com o mesmo pedido vago	Uma rubrica clara, outro modelo ou código
O que produz	Quase sempre o mesmo texto	Problemas concretos que mudam o resultado

Um passo que compara o resumo com o documento e lista números divergentes tem sinal. Um passo que roda os testes de um código gerado também. Esses viram um Avaliador e Otimizador, não uma etapa a embutir.

Checagem +20 XP de primeiraVocê está auditando um pipeline com várias chamadas de revisão. Qual delas você NÃO deveria embutir no passo anterior?

Uma chamada que pede 'melhore o texto' e recebe só o rascunho

Uma chamada que confere se o texto ficou abaixo de 150 palavras

Uma chamada que compara o resumo com o documento original e aponta números divergentes

Desafio

Este pipeline de classificação de tickets tem um passo que talvez seja trivial. Qual, e o que fazer com ele?

1. classificar(ticket) -> categoria
2. confirmar("A categoria X está correta para este ticket? Responda sim ou não.")
3. se "não": classificar de novo

Ver solução

O passo 2 pede ao modelo para confirmar a própria resposta, sem informação nova. Ele quase sempre diz “sim”. Remova os passos 2 e 3. No lugar, peça uma confiança junto com a categoria (saída estruturada com confidence, ou as probabilidades dos tokens quando a API oferece) e calibre o limiar no eval, porque a confiança declarada pelo modelo nem sempre bate com a taxa real de acerto. Os casos de baixa confiança vão para revisão humana ou para um modelo maior, como numa Cascata de Modelos.

Teste seu entendimento

Checagem +20 XP de primeiraVocê removeu a revisão e a acurácia média do eval ficou igual: 92% antes e 92% depois. O que falta conferir antes do deploy?

O resultado por categoria e nos casos difíceis

Nada, a média igual prova que o passo era inútil

Se o pipeline antigo continua mais barato em horário de pico

Checagem +20 XP de primeiraA revisão antiga garantia 'no máximo 150 palavras'. Para onde essa regra vai depois da refatoração?

Só para o prompt de geração, que agora pede o limite

Para uma chamada nova e menor, dedicada só a contar palavras

Para o código, que conta as palavras e corta em fim de frase

Checagem +20 XP de primeiraPor que embutir 'mantenha nomes, números e datas exatamente como no original' no passo que gera funciona melhor do que pedir essa correção depois?

Porque prompts mais longos sempre produzem respostas melhores

Porque o gerador vê o documento e pode evitar o erro, enquanto o revisor só via o rascunho

Porque a primeira chamada de um pipeline recebe mais atenção do modelo

Checagem +20 XP de primeiraSeu classificador de tickets pergunta ao modelo 'a categoria X está correta? sim ou não' depois de cada classificação. Qual troca resolve melhor?

Pedir uma confiança na saída estruturada, calibrar o limiar no eval e mandar os casos incertos para uma pessoa ou um modelo maior

Fazer a pergunta de confirmação três vezes e ficar com a maioria

Trocar a pergunta por 'tem certeza absoluta?' para pressionar o modelo