Как три ИИ могут спорить об одном тексте: когда редакционная коллегия лучше одного агента
Самый слабый редактор — тот, кому нельзя сказать «нет». В ИИ-системах это встречается буквально: один и тот же агент пишет текст, потом получает команду «проверь себя» и может подтвердить собственную версию. Внешне это выглядит как редактура, по сути — как человек, который перечитал свой абзац и решил, что он хорош.
Проблема не в том, что модель плохая. Она видит собственный текст как часть контекста, а первая версия может становиться якорем. «Проверка» в таком режиме часто сводится к пересказу того же решения другими словами: модель не ищет альтернативу, а достраивает объяснение к уже написанному. Поэтому дальше речь пойдёт не о том, как позвать больше ИИ, а о том, как разделить роли так, чтобы у каждого этапа был свой критерий качества и право остановить результат.
Одна оговорка о жанре: ниже нет отчёта о том, как я вживую свёл трёх моделей и записал их спор. Это разбор схемы, которую можно собрать из обычных вызовов модели, и обзор исследований о том, где такая схема помогает, а где создаёт видимость проверки.
Почему одной самопроверки недостаточно
В 2024 году на ICLR вышла работа с прямым названием «Large Language Models Cannot Self-Correct Reasoning Yet». Авторы показали: при внутренней самокоррекции без внешней обратной связи модели плохо исправляли ошибки рассуждения, а в некоторых экспериментах качество после перепроверки даже снижалось. Это не приговор всем моделям и не универсальный закон, но важный сигнал: просьба «посмотри ещё раз» сама по себе не создаёт независимую проверку.
Механика тут простая. Модель получает тот же текст, тот же контекст и ту же инструкцию, только с добавлением слова «проверь». У неё нет нового источника, нового критерия или нового взгляда. Если в первой версии уверенно стоит неверная дата, второй проход может оставить её на месте или заменить на другую, столь же уверенно звучащую. Редактору это знакомо: автор, которому говоришь «перечитай», часто перечитывает не смысл, а ритм.
Отсюда практический вывод: нужен не ещё один проход той же головой, а другой взгляд — с другими критериями и, желательно, с доступом к внешним данным. Это скучнее, чем «агент сам себя улучшил», зато ближе к тому, как вообще работает нормальная проверка.
Редколлегия — это не количество агентов, а разные критерии
Главная мысль, которую легко потерять в разговоре про мультиагентные системы: польза не в том, что агентов стало больше. Польза в том, что у разных этапов разные задачи и разные основания сказать «стоп». У автора критерий один — сделать текст по теме и внятно. У редактора — структура, ясность, повторы, соответствие тезису. У фактчекера — подтверждение конкретных утверждений по источникам. У контролёра — формальные ограничения и финальное «да» или «нет».
Anthropic в материалах о построении агентных систем описывает такую схему как набор архитектурных паттернов: цепочку вызовов с промежуточными «воротами», маршрутизацию, параллелизацию, схему «оркестратор — исполнители» и отдельный паттерн evaluator–optimizer, где один вызов формирует результат, а другой его оценивает. Важная деталь: оценивающий вызов имеет смысл, когда критерии сформулированы достаточно чётко и итерации дают измеримое улучшение. Если проверяющему не сказали, что считать браком, он будет изображать редактуру.
И ещё одна оговорка, без которой разговор уезжает в магию. Роли не обязаны быть разными базовыми моделями. Их можно собрать разными вызовами одной модели — с отдельными инструкциями, отдельным контекстом и отдельными инструментами. Разные модели повышают разнообразие, но сами по себе не гарантируют независимость. Можно взять три разных названия и получить три пересказа одной ошибки. ИИ-агенты в такой схеме — не взаимозаменяемые стажёры, а разные должности. Для оркестрации это важнее, чем количество участников.
Как выглядит конвейер на практике
Если собрать такую редакционную коллегию вокруг одного документа, схема будет примерно такой. Автор получает тему, аудиторию и требования, пишет текст, но не выносит окончательный вердикт о его достоверности. Редактор смотрит структуру и ясность, убирает повторы и проверяет, что статья отвечает на заявленный вопрос, а не уходит в соседнюю тему. Фактчекер получает список проверяемых утверждений и доступ к источникам и возвращает по каждому пункту одно из трёх: подтверждено, опровергнуто, не удалось проверить. Контролёр сверяет результат с формальными ограничениями и может остановить публикацию.
Смысл разделения в том, что никто не проверяет всё сразу. Редактор не перепроверяет исследование заново, фактчекер не переписывает структуру, контролёр не спорит о стиле. Зато каждый может вернуть работу на предыдущий этап. Если провален только один критерий, перезапускается только соответствующий участок: фактчекер заново смотрит неподтверждённый абзац, а не заставляет автора переписывать весь материал. Это инженерный принцип локального повтора, и он полезен не сам по себе, а потому что экономит время и не размывает ответственность.
Здесь легко увлечься и решить, что четыре агента — оптимальное число. Это иллюстрация, а не доказанное правило. В одной задаче хватит двух этапов, в другой — пяти. Важнее, есть ли у каждого этапа отдельный критерий и полномочия.
Где ломается даже хорошая схема
Первая поломка — ложное согласие. Три экземпляра одной модели обучены на сходных данных и получают одинаковый контекст. Все воспроизводят одну распространённую ошибку, после чего голосуют за неё большинством. Это не независимая фактологическая проверка, а согласование коррелированных ответов. В TACL 2026 описан эффект belief entrenchment: агенты закрепляют общую ошибочную позицию из-за сходных исходных убеждений и однородной динамики обсуждения; когда авторы принудительно повышали разнообразие подходов, результаты улучшались.
Вторая поломка — ложные разногласия. Агенты спорят о формулировках, а не о фактах, и создают видимость работы. В материалах ACL 2026 есть наблюдение, что стандартный multi-agent debate с однородными агентами нередко уступает простому большинству голосов при более высоких вычислительных расходах. Помогают разнообразие начальных ответов и явное указание уверенности, но проверка шла на шести наборах задач, и переносить её на редактуру нужно осторожно.
Третья поломка — подмена причины. В работе ICLR 2024 при сопоставимом количестве сгенерированных ответов не нашли убедительного превосходства многоагентного спора над self-consistency, то есть над несколькими независимыми вариантами с последующим выбором. Улучшение может объясняться дополнительными попытками, а не самой дискуссией. При этом сбрасывать спор со счетов тоже нельзя: в исследовании MIT и Google Brain на ICML 2024 несколько экземпляров модели предлагали ответы, критиковали друг друга и проводили несколько раундов обсуждения; в основных экспериментах использовались три агента и два раунда, и на выбранных задачах по математике, стратегии и фактологичности схема превзошла одиночную генерацию. Это конкретная постановка, а не универсальное доказательство.
Общий вывод из этих поломок простой. Спор полезен не тогда, когда агенты громко спорят, а когда у них разные задания, разные источники или разные критерии. Иначе это несколько раз одна и та же ошибка, только дороже.
Сколько стоит редакционная коллегия
Anthropic сообщала о своей внутренней исследовательской системе: в конкретном внутреннем тесте исследовательских задач многоагентная конфигурация превзошла одиночного Claude Opus 4 на 90,2%. Но там же приведены расходы: агенты тратили примерно в четыре раза больше токенов, чем обычные чаты, а многоагентные системы — примерно в 15 раз больше. Это внутренние измерения компании по конкретной системе, а не отраслевой стандарт, и переносить их на любую редактуру нельзя.
Из этого следуют три издержки, которые лучше называть прямо. Первая — деньги и токены: каждый дополнительный этап что-то стоит. Вторая — задержка: пока автор пишет, редактор правит, фактчекер проверяет, а контролёр сверяет, пользователь ждёт. Третья — риск ложных разногласий и ложного консенсуса: схема может создать ощущение проверки, не создав самой проверки.
По опыту Anthropic, многоагентная архитектура особенно полезна при параллельном поиске по независимым направлениям и работе с информацией, которая не помещается в одно контекстное окно. Задачи с множеством зависимостей и необходимостью постоянно держать общий контекст подходят хуже. Бытовое сравнение простое: звать трёх консультантов на вопрос, какую букву поставить в заголовке, — дорого и бессмысленно. А на проверку юридического абзаца, где цена ошибки высока, — нормально.
Если хочется собрать такой конвейер самому, есть GPT-Лаборатория: Telegram — https://t.me/jopotology, VK — https://vk.ru/jopotology, MAX — https://max.ru/join/fyssUhvFi8Bo2GK0bm6F_RFKZYTa1LWL8VVJnRMkTHM.
Когда коллегия оправдана, а когда это театр
Работающая схема узнаётся не по числу агентов, а по наличию разных критериев и права остановить результат. Если все роли собраны в один контекст и один вызов модели, это не редколлегия, а один сотрудник, который разговаривает сам с собой в трёх тональностях.
Признаки театра тоже видны быстро. Проверяющий не имеет доступа к источникам. Критерии сформулированы как «сделай лучше». Никто не может вернуть материал на доработку. Спор идёт о формулировках, а не о фактах. Число агентов растёт, а число различных проверок — нет. Тогда лишний участник не добавляет независимости, а только увеличивает счёт за токены и время ожидания.
Практический критерий простой: смотрите не на число моделей, а на то, есть ли у них разные задачи, разные данные и право сказать «нет». Если этого нет, перед вами не редколлегия, а дорогой способ получить тот же текст, только позже.
