Por qué los críticos multiagente siguen revisando en lugar de desplegar
Esta es una traducción. La versión de referencia es el original en inglés; cite esa.
En una prueba aleatorizada, cuando se ofrecieron dos opciones a los críticos de modelos en una oración de una única indicación, eligieron añadir un control 68 veces y eliminar uno una sola vez. Ese resultado, y el registro de campo que lo respalda, explican por qué los bucles de críticos multiagente tienden a seguir revisando en lugar de desplegar.
El resultado 68-a-1
El artículo ejecutó su propia prueba propuesta en una canalización pequeña: un trabajador y dos críticos de modelos, 144 ejecuciones, tres intervenciones asignadas al azar, y dieciocho defectos plantados con anticipación en seis tareas, de modo que un defecto omitido es un recuento en lugar de un juicio.
- Agregar versus eliminar. Ofrecidas ambas opciones "en la misma oración del mismo mensaje", los críticos pidieron agregar un control 68 veces y eliminar uno una vez. La única eliminación nombró un control admitido momentos antes en la misma ejecución, y el arnés no consiguió hacerlo coincidir, por lo que nunca se ejecutó.
- Rechazar las adiciones no mostró ningún costo medido en defectos: 0.13 omitidos por ejecución frente a 0.18, IC del 95% [-0.16, +0.05]. El artículo señala que este intervalo incluye un pequeño aumento y no establece equivalencia.
- Elevar el presupuesto de ronda aumentó los bloqueadores reclamados 2.3 veces y refutó reclamos 3.7 veces, mientras que los bloqueadores confirmados aumentaron 1.7 veces.
La prueba es pequeña y el artículo lo dice: "una ejecución de un sistema en seis tareas pequeñas con un costo de $3.47", preregistrada antes de la primera ejecución. "Muestra que el diseño es ejecutable y lo que produce, pero no es una tasa para nada en el campo."
Agentes de IA atrapados en bucles de revisión: el registro de campo
La prueba aleatorizada se construyó para verificar patrones observados por primera vez en los propios proyectos multiagente del autor. Una ronda de crítica es un paso en el que los modelos críticos revisan una etapa y devuelven ACCEPT o RETURN.
- La etapa 01 de una ejecución de largo horizonte pasó por cinco rondas y 18 informes críticos. El parche creció de 626 a 1,545 líneas.
- La etapa 1b-a pasó cinco rondas y 4 h 21 min en un módulo deshabilitado por defecto. La ronda tres se abrió aunque la ronda dos había terminado con cinco aceptaciones y cero bloqueos confirmados.
- En toda la ejecución, los críticos afirmaron seis bloqueos. Tres fueron confirmados por reproducción.
Cuando el principal humano pidió un límite en los críticos, se implementó un indicador "perfeccionista" por familia en menos de una hora, y la única familia que fue marcada era la única familia cuyos bloqueos habían sido confirmados.
Presupuestos de tokens para agentes de IA e impuesto de control
El artículo utiliza el término «impuesto de control» de Terekhov et al. (2025), el costo de añadir medidas de control a una canalización de IA. En la ejecución de largo horizonte, el conductor añadió «una pequeña etapa» de cobertura que el objetivo declarado no contenía. La etapa 1b-a sola consumió más de la mitad de los tokens de agente medidos en la ejecución, y sus dos subetapas en conjunto consumieron aproximadamente tres cuartos. Ninguna de las capacidades solicitadas fue entregada en el pase inicial.
A la mañana siguiente, el principal humano estableció un límite de dos horas, prohibió nuevas complicaciones y ordenó ejecución paralela. La subetapa hermana se cerró en una ronda de crítica y una ronda de corrección. El artículo es cuidadoso aquí: las dos etapas también diferían en límite de reloj de pared, ejecución serial versus paralela y el módulo bajo revisión, por lo que la comparación es descriptiva.
Los presupuestos también cuestan algo
La prueba aleatoria también valoró los propios remedios del artículo. Un corte de presupuesto de una ronda va de 2.86 a 1.00 a un costo de 0.11 defectos no detectados por ejecución (95% CI [0.005, 0.204], permutation p = 0.07), recayendo todo ese costo en un defecto de una tarea. Un control negativo obligatorio rechazó diez victorias, todas las cuales fueron trabajo correcto.
Fiabilidad de LLM como juez
El artículo señala propiedades conocidas de los jueces modelo: sesgos de posición y verbosidad, una preferencia por sus propias generaciones, y modelos de revisión de código que juzgan implementaciones correctas como no conformes, donde indicaciones de revisión más detalladas elevan la tasa de error. En un estudio de 2026, un juez de última generación etiquetó incorrectamente "74.4% de las llamadas de consecuencia estándar pero solo 3.3% cuando la consecuencia se invierte". La transcripción no cambió, pero la calificación sí.
Lo que el artículo propone
La proposición P4 predice que añadir críticos, o hacerlos más estrictos, aumenta las rondas y los hallazgos más que aumenta los defectos confirmados. El módulo del artículo implementa reglas presupuestarias en lugar de veredictos: stop_rule permite una ronda de crítica y una ronda de correcciones por etapa, un bloqueador cuenta solo con un escenario concreto, un vínculo al objetivo de la misión y confirmación del coordinador, y una nueva verificación, ronda o rol se admite solo con un token de autoridad.
Cada mecanismo de la definición del artículo está documentado en sus registros, pero con qué frecuencia las tres condiciones se cumplen en un componente "no está establecido por los registros aquí". La prueba aleatoria existe para empezar a responder eso.
Secciones completas: la prueba aleatoria (9.5), bucles que se alimentan a sí mismos (5.4), el mandato se amplía (5.1), guardias contra guardias (5.3), noche contra mañana (5.7), jueces modelo (3.3), el juez que se mueve (3.4), Proposición P4, diseño de 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 también construye Poly A1, una aplicación en la que las IA de diferentes empresas se revisan el trabajo.