Avaliador-Otimizador (Evaluator-Optimizer)
Um LLM gera uma resposta enquanto um segundo LLM a avalia contra critérios e devolve feedback; o gerador revisa e o laço se repete até a avaliação passar. Eleva a qualidade em tarefas com critérios de avaliação claros, ao custo de chamadas extras.
Problema
Uma saída de uma única passagem pode descumprir requisitos, e não há um mecanismo embutido para verificá-la e melhorá-la antes de usá-la.
Quando usar
Use avaliador-otimizador quando puder articular critérios de avaliação claros e o refinamento iterativo melhorar o resultado de forma mensurável — por exemplo qualidade de tradução, código que deve passar em testes, ou escrita contra uma rubrica.
Solução
Um gerador produz um candidato; um avaliador (outra chamada ao LLM ou uma verificação determinística) o pontua contra critérios explícitos e devolve feedback acionável. O gerador revisa e o ciclo se repete até cumprir os critérios ou alcançar um orçamento.
Separar geração de avaliação imita como um escritor humano se beneficia de um editor: o crítico captura problemas que o autor deixa passar, e os critérios explícitos mantêm o laço convergindo.
Componentes
Benefícios
- Maior qualidade em tarefas com critérios claros.
- Captura erros que uma única passagem publicaria.
- O feedback é explícito e acionável.
Riscos
- As chamadas extras adicionam latência e custo.
- Um avaliador fraco dá feedback enganoso.
- Os laços podem não convergir sem um orçamento.
Quando não usar
- Quando os critérios não podem ser definidos com clareza.
- Quando uma única passagem já é boa o bastante.
- Quando os orçamentos de latência ou custo são muito apertados.
Tecnologias
Exemplos
- Gerar código, executar testes e revisar até passarem.
- Redigir uma tradução e refiná-la contra o original.
- Escrever contra uma rubrica com um crítico que exige cada critério.
KPIs
- Taxa de aceitação
- Proporção de saídas que o avaliador aceita de primeira; alta demais indica régua baixa, baixa demais, gerador ou rubrica ruins.
- Iterações até aceitar
- Loops avaliar→revisar médios antes de aceitar; se sobem, o gerador é fraco ou os critérios, vagos.
- Custo e latência por saída aceita
- Tokens e tempo total de todas as iterações, não só a chamada final: o loop multiplica ambos.
- Concordância avaliador–humano
- Com que frequência o veredito do avaliador coincide com um revisor humano numa amostra; o loop vale o que seu avaliador.
Modos de falha observados
- Reward hacking: o gerador aprende a satisfazer a redação do avaliador em vez do objetivo real.
- Avaliador fraco ou mal calibrado: aceita saídas ruins ou rejeita boas, somando custo sem qualidade.
- Loops infinitos ou oscilantes quando nenhum candidato supera a régua; sem um teto de iterações o custo é ilimitado.
- Deriva de critérios: rubricas vagas ou mutáveis tornam a aceitação não determinística e difícil de auditar.
Lições aprendidas
- Limite as iterações e defina um fallback (devolver o melhor até agora ou escalar) para o loop sempre terminar.
- Torne os critérios de aceitação explícitos e estáveis; um avaliador vale o que sua rubrica.
- Valide o avaliador contra o julgamento humano antes de confiar nele como portão.
- Use o loop só onde a qualidade justifique o custo multiplicado, não para saídas baratas e de baixo risco.
FAQs
- Como difere da reflexão?
- A reflexão faz o mesmo modelo se autocriticar. O avaliador-otimizador separa os papéis: um avaliador distinto julga o gerador, o que costuma dar feedback mais afiado e menos enviesado.
- O avaliador pode ser determinístico?
- Sim. Para código, um runner de testes é um avaliador ideal; para saída estruturada, serve uma verificação de esquema. Use um juiz modelo para critérios com nuances.
- Quantas iterações?
- Defina um orçamento (ex.: 2-3) e pare quando os critérios passarem. Laços sem limite desperdiçam custo e podem não convergir.