Por que os críticos multi-agentes continuam avaliando em vez de entregar
Esta é uma tradução. A versão de referência é o original em inglês; cite essa.
Em um teste randomizado, críticos de modelos, aos quais foram oferecidas duas opções em uma frase de um prompt, foram solicitados a adicionar um controle 68 vezes e a remover um apenas uma vez. Esse resultado, e o registro do campo por trás dele, explicam por que loops de críticos multi-agentes tendem a continuar avaliando em vez de entregar.
O resultado 68 para 1
O artigo executou seu próprio teste proposto em um pequeno pipeline: um trabalhador e dois críticos de modelo, 144 execuções, três intervenções atribuídas aleatoriamente, e dezoito defeitos plantados antecipadamente em seis tarefas, de modo que um defeito perdido seja uma contagem em vez de um julgamento.
- Adicionar versus remover. Oferecidas ambas as opções "na mesma frase do mesmo prompt", os críticos pediram para adicionar um controle 68 vezes e para remover um uma única vez. A única remoção nomeou um controle admitido momentos antes na mesma execução, e o harness falhou em combiná-lo, portanto nunca foi executado.
- Recusar as adições não mostrou nenhum custo mensurável em defeitos: 0,13 perdidos por execução contra 0,18, IC 95% [-0,16, +0,05]. O artigo observa que este intervalo inclui um pequeno aumento e não estabelece equivalência.
- Aumentar o orçamento de rodada aumentou os bloqueadores alegados 2,3 vezes e refutou afirmações 3,7 vezes, enquanto os bloqueadores confirmados aumentaram 1,7 vezes.
O teste é pequeno e o artigo diz isso: "uma execução de um sistema em seis pequenas tarefas a um custo de $3,47", pré-registrado antes da primeira execução. "Mostra que o design é executável e o que ele produz, mas não é uma taxa para nada no campo."
Agentes de IA presos em loops de revisão: o registro do campo
O teste aleatorizado foi construído para verificar padrões primeiro vistos nos próprios projetos multiagente do autor. Uma rodada de crítica é uma passagem em que modelos críticos analisam um estágio e retornam ACCEPT ou RETURN.
- O Estágio 01 de uma execução de horizonte longo passou por cinco rodadas e 18 relatórios de críticos. O patch cresceu de 626 para 1.545 linhas.
- O Estágio 1b-a passou por cinco rodadas e 4 h 21 min em um módulo desabilitado por padrão. A rodada três começou embora a rodada dois tivesse terminado com cinco aceitações e zero bloqueadores confirmados.
- Ao longo da execução, os críticos identificaram seis bloqueadores. Três foram confirmados pela reprodução.
Quando o principal humano pediu um limite de críticos, um sinalizador de "perfeccionista" por família foi implementado em uma hora, e a família marcada era a única cujos bloqueadores tinham sido confirmados.
Orçamentos de tokens de agentes de IA e a taxa de controle
O artigo utiliza o termo "taxa de controle" de Terekhov et al. (2025), o custo de adicionar medidas de controle a um pipeline de IA. Na execução de longo horizonte, o condutor adicionou "um pequeno estágio" de seguro que o objetivo declarado não continha. O estágio 1b-a sozinho consumiu mais da metade dos tokens de agente medidos da execução, e seus dois sub-estágios juntos consumiram cerca de três quartos. Nenhuma das capacidades solicitadas foi entregue na passagem inicial.
Na manhã seguinte, o principal humano estabeleceu um limite de duas horas, proibiu novas complicações e ordenou execução paralela. O sub-estágio irmão foi concluído em uma rodada de crítica e uma rodada de correção. O artigo é cuidadoso aqui: os dois estágios também diferiam no limite de tempo de parede, na execução serial versus paralela e no módulo sob revisão, portanto a comparação é descritiva.
Os orçamentos também custam algo
O teste aleatorizado também calculou o custo de seus próprios remédios. Um corte de orçamento de uma rodada passa de 2.86 para 1.00 ao custo de 0.11 defeitos não detectados por execução (95% CI [0.005, 0.204], permutation p = 0.07), a totalidade desse custo recaindo sobre um defeito de uma tarefa. Um controle negativo obrigatório recusou dez vitórias, todas as dez sendo trabalho correto.
Confiabilidade do LLM-as-a-judge
O trabalho aponta para propriedades conhecidas de modelos juízes: vieses de posição e verbosidade, uma preferência por suas próprias gerações, e modelos de revisão de código que julgam implementações corretas como não conformes, com prompts de revisão mais detalhados elevando a taxa de erro. Em um estudo de 2026, um modelo juiz de fronteira classificou incorretamente "74,4% das chamadas de consequência padrão, mas apenas 3,3% quando a consequência é invertida". A transcrição não mudou, e a nota mudou.
O que o artigo propõe
A Proposição P4 prevê que adicionar críticos ou torná-los mais rigorosos aumenta as rodadas e os achados mais do que aumenta os defeitos confirmados. O módulo do artigo implementa regras de orçamento em vez de vereditos: stop_rule permite uma rodada de crítica e uma rodada de correções por etapa, um bloqueador conta apenas com um cenário concreto, um vínculo com o objetivo da missão e confirmação pelo coordenador, e um novo controle, rodada ou função é admitido apenas com um token de autoridade.
Cada mecanismo da definição do artigo está documentado em seus registros, mas com que frequência as três condições se encontram em um componente "não é determinado pelos registros aqui". O teste aleatorizado existe para começar a responder isso.
Seções completas: o teste aleatorizado (9.5), loops que se alimentam (5.4), o mandato se amplia (5.1), guardas contra guardas (5.3), noite contra manhã (5.7), juízes de modelo (3.3), o juiz que se move (3.4), Proposição P4, design do módulo (10.2).
Chernets, V. (2026). AI-Watchbird (Sheckley): When Automated Oversight Widens Its Own Mandate and Harms What It Guards. SSRN 7473658. https://doi.org/10.2139/ssrn.7473658
Vadym Chernets também constrói Poly A1, um aplicativo em que IAs de diferentes empresas verificam o trabalho uma da outra.