Autocorreção e criação de prompts reflexivos

A criação de instruções reflexivas é uma técnica na qual se pede ao agente que avalie a própria saída antes de finalizá-la. Em vez de produzir uma resposta e parar, o agente revisa sua resposta em relação ao objetivo original, identifica lacunas ou erros e gera uma versão corrigida. Isso imita a maneira como as pessoas revisam o próprio trabalho e melhora significativamente a qualidade das saídas em tarefas complexas sem exigir um modelo crítico separado.

O loop reflexivo básico tem três etapas: Generate uma resposta inicial, Critique essa resposta com base em critérios claros e Revise com base na crítica. Esse loop pode ser executado uma ou mais vezes. Cada iteração melhora a resposta até que a crítica a considere satisfatória ou até que seja atingida uma contagem máxima de revisões. A etapa de crítica é, por si só, uma chamada de LLM com uma instrução de reflexão especializada.

A instrução de crítica deve especificar critérios concretos de avaliação, em vez de pedir simplesmente que o modelo “melhore” a resposta. Liste os aspectos específicos a verificar: Todas as afirmações estão corretas? A resposta abordou todas as partes da pergunta? Falta alguma etapa? Há conteúdo desnecessário? Uma instrução de crítica com itens de verificação explícitos produz comentários acionáveis que a etapa de revisão pode usar diretamente.

Estruture o resultado da crítica como um modelo Pydantic para que possa decidir programaticamente se deve revisar. O campo is_satisfactory determina a saída do ciclo. A lista issues informa exatamente o que a etapa de revisão deve corrigir. O campo severity permite ignorar a revisão de problemas estilísticos menores, mantendo sempre a revisão de erros factuais.

O prompt de revisão recebe a tarefa original, a resposta inicial e o feedback da crítica. Peça ao modelo que produza uma versão aprimorada que trate especificamente cada problema identificado pela crítica, preservando as partes corretas da resposta original. Inclua sempre a palavra 'only' para impedir que o modelo faça alterações desnecessárias em aspectos que a crítica já aprovou.

A autocorreção é especialmente poderosa na geração de código. Depois de gerar o código, execute nele um analisador estático ou verificador de tipos, envie o resultado dos erros de volta ao modelo e peça que ele corrija os erros. Essa reflexão fundamentada na execução é mais confiável do que uma crítica baseada apenas na linguagem, pois o feedback vem de uma ferramenta objetiva, e não do julgamento de outro LLM.

Uma falha comum em sistemas reflexivos é a correção excessiva: o modelo piora o problema original ao tentar corrigir outra coisa. Reduza esse risco limitando o escopo da revisão: o prompt de revisão deve dizer explicitamente 'do not change anything that was not flagged.' Compare também a resposta revisada com a original usando uma verificação de diferenças — se a versão revisada for radicalmente diferente, algo deu errado e deverá manter a original.

Em um agente com várias etapas, adicione um ponto de verificação de reflexão depois de concluir um conjunto de etapas — por exemplo, depois de reunir toda a pesquisa, mas antes de escrever o relatório final. O agente revisa o que coletou, identifica lacunas e decide se deve reunir mais informações ou prosseguir. Essa reflexão durante a tarefa impede que os agentes avancem para a etapa de síntese com evidências incompletas ou contraditórias.

Registre cada rodada de reflexão: as pontuações da crítica, os problemas identificados e se a revisão realmente os resolveu. Esses dados revelam se os prompts de reflexão são eficazes. Se a resposta revisada reintroduzir consistentemente os mesmos problemas apontados pela crítica, o prompt de revisão não é específico o suficiente. Se a maioria das críticas disser 'APPROVE' na primeira rodada, a qualidade da geração inicial já será alta, e o custo adicional da reflexão talvez não compense.

A reflexão aumenta a latência e o custo — um processo de reflexão e revisão em duas rodadas pelo menos triplica o número de chamadas ao LLM para essa tarefa. Use a reflexão de forma seletiva: sempre para resultados de alto risco (código que será executado e respostas a questões empresariais relevantes), opcionalmente para respostas voltadas ao usuário e nunca para etapas intermediárias internas que serão verificadas imediatamente por uma ferramenta. O custo compensa quando a qualidade é mais importante do que a velocidade.

Acompanhe se a reflexão realmente melhora seus resultados realizando testes A/B: processe aleatoriamente 50% das tarefas com reflexão e 50% sem reflexão e, em seguida, avalie os dois conjuntos com seu avaliador baseado em LLM. Se o grupo reflexivo obtiver uma pontuação significativamente maior (e a melhoria superar a latência e o custo adicionais), a reflexão estará compensando. Se as pontuações forem semelhantes, a qualidade da geração inicial já será suficientemente alta, e a reflexão estará apenas adicionando custo sem benefício.

Nesta lição, você aprendeu que: os ciclos de reflexão e revisão melhoram a qualidade do resultado fazendo o agente criticar e corrigir as próprias respostas; critérios concretos de crítica produzem feedback acionável, em vez de sugestões vagas de melhoria; e a reflexão fundamentada na execução, com ferramentas objetivas como analisadores estáticos, é especialmente poderosa para a geração de código. A seguir, implementaremos pontos de verificação de agentes e retomada de tarefas.