Почему многоагентные критики продолжают рецензировать вместо выпуска
Это перевод. Основная версия — оригинал на английском; ссылайтесь на него.
В рандомизированном тесте, когда критики-модели получили выбор между двумя вариантами в одном предложении одного промпта, они рекомендовали добавить контроль 68 раз и удалить один раз. Этот результат и данные исследований в этой области объясняют, почему циклы многоагентной критики, как правило, продолжают рецензировать, вместо выпуска.
Результат соотношения 68 к 1
В статье проводился собственный предложенный тест на небольшом конвейере: один работник и два критика модели, 144 запуска, три вмешательства, назначенные случайным образом, и восемнадцать дефектов, заранее внедренных в шести задачах, так чтобы пропущенный дефект являлся счетом, а не суждением.
- Добавить или удалить. Когда обе опции предлагались «в одном предложении одного и того же запроса», критики просили добавить элемент управления 68 раз и удалить один раз. Единственное удаление назвало элемент управления, признанный моментом ранее в том же запуске, и тестовая система не смогла его совместить, поэтому он никогда не был выполнен.
- Отказ от добавлений не показал измеримых затрат в виде дефектов: 0,13 пропущено на запуск против 0,18, 95% CI [-0,16, +0,05]. В статье отмечается, что этот интервал включает небольшое увеличение и не устанавливает эквивалентность.
- Повышение бюджета раунда повысило заявленные блокировщики в 2,3 раза и опровергло претензии в 3,7 раза, в то время как подтвержденные блокировщики выросли в 1,7 раза.
Тест небольшой, и в статье это отмечается: «один запуск одной системы на шести небольших задачах стоимостью $3,47», предварительно зарегистрирован перед первым запуском. «Это показывает, что дизайн выполним и что он дает, но это не является ставкой на что-либо в этой области.»
ИИ-агенты, застревающие в циклах рецензирования: полевые данные
Рандомизированный тест был создан для проверки паттернов, впервые замеченных в собственных многоагентных проектах автора. Раунд критики — это один проход, при котором модели-критики рецензируют этап и возвращают ACCEPT или RETURN.
- Этап 01 долгосрочного запуска прошёл пять раундов и 18 отчётов критиков. Патч вырос с 626 до 1,545 строк.
- Этап 1b-a потратил пять раундов и 4 ч 21 мин на модуль, отключенный по умолчанию. Раунд три открылся, несмотря на то что раунд два завершился пятью одобрениями и без подтверждённых блокирующих проблем.
- На протяжении запуска критики выявили шесть блокирующих проблем. Три были подтверждены воспроизведением.
Когда главный руководитель запросил ограничение на критиков, в течение часа был внедрён флаг "perfectionist" на семейство, и единственное семейство, которое он отметил, было единственным, чьи блокирующие проблемы были подтверждены.
Бюджеты токенов агентов ИИ и налог контроля
В статье используется термин «налог контроля» из работы Terekhov et al. (2025), обозначающий стоимость добавления мер контроля в конвейер ИИ. При выполнении с длительным горизонтом дирижёр добавил «небольшой этап» страховки, которого не было в объявленной цели. На один этап 1b-a ушло более половины всех измеренных токенов агента, а его два подэтапа вместе составили примерно три четверти. Ни одна из запрашиваемых возможностей не была предоставлена в первом проходе.
На следующее утро человеческий инициатор установил двухчасовой лимит, запретил новые усложнения и потребовал параллельного выполнения. Соседний подэтап завершился за один раунд критики и один раунд исправлений. Здесь статья проявляет осторожность: два этапа также отличались по лимиту настенного времени, последовательному и параллельному выполнению и модулю под рассмотрением, поэтому сравнение носит описательный характер.
И бюджеты что-то стоят
Рандомизированный тест также оценил стоимость собственных мер исправления. Сокращение бюджета в один раунд переходит от 2,86 к 1,00 с расходом в 0,11 пропущенных дефектов за запуск (95% CI [0.005, 0.204], permutation p = 0.07), вся эта цена приходится на один дефект одной задачи. Обязательный отрицательный контроль отклонил десять побед, все десять из которых были правильной работой.
Надежность LLM-судьи
Статья указывает на известные свойства моделей-судей: смещения позиции и многословности, предпочтение своих собственных выходов и то, что модели проверки кода оценивают правильные реализации как несоответствующие, при этом более подробные подсказки проверки повышают частоту ошибок. В одном исследовании 2026 года передовая модель-судья неправильно оценила "74,4% вызовов со стандартным результатом, но только 3,3%, когда результат был инвертирован". Транскрипт не изменился, но оценка изменилась.
Что предлагает статья
Предложение P4 предсказывает, что добавление критиков или ужесточение их увеличивает раунды и находки больше, чем увеличивает подтвержденные дефекты. Модуль статьи реализует бюджетные правила, а не вердикты: stop_rule позволяет один раунд критики и один раунд исправлений на этап, блокер учитывается только с конкретным сценарием, ссылкой на миссионную цель и подтверждением координатором, и новая проверка, раунд или роль допускаются только с маркером полномочий.
Каждый механизм, определяемый в статье, документирован в её записях, но как часто все три условия совпадают в одном компоненте "не определяется записями здесь". Рандомизированный тест существует, чтобы начать отвечать на это.
Полные разделы: рандомизированный тест (9.5), циклы, которые питают себя (5.4), мандат расширяется (5.1), охранники против охранников (5.3), ночь против утра (5.7), модели-судьи (3.3), судья, который движется (3.4), Предложение P4, дизайн модуля (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 также разрабатывает Poly A1, приложение, в котором ИИ из разных компаний проверяют работу друг друга.