Почему ИИ-агент не должен проверять сам себя: паттерн Maker/Checker

Разработчик У Цзи описал архитектурный паттерн для надёжных ИИ-агентов — принцип разделения генерации и проверки. Идея проста: если вы попросите модель проверить собственный ответ, она почти всегда его подтвердит, даже если он содержит грубые ошибки.

Надёжность ИИ-агента достигается не «умнее моделью», а инженерным принципом: разделение генерации и валидации. Качество не возникает случайно — его проектируют.

Проблема: самопроверка не работает

Представьте команду, которая собрала агента для анализа продаж. Он тянул данные из базы и формировал отчёты. Чтобы повысить точность, добавили шаг «самопроверки» — после генерации агент сам себе говорил: «Проверь, точны ли данные».

Результат? Агент каждый раз отвечал: «Данные точны». Даже когда исследователи намеренно вставляли в исходники абсурдные цифры — скажем, минус 50 миллионов юаней выручки за месяц — модель уверенно подтверждала корректность.

Это не каприз и не «непослушание» модели. Это фундаментальная проблема: когда генератор и проверяющий — одна и та же сущность, проверка становится лишь переформулировкой процесса генерации, а не настоящей валидацией. У проверяющего те же когнитивные ограничения, та же база знаний, тот же ход рассуждений, что и у генератора.

Эффект подтверждения

Самопроверка запускает ещё одну ловушку — каскадное подтверждение предвзятости (confirmation bias). Модель формирует «состояние убеждённости» в процессе генерации, и при повторном просмотре склонна подтверждать сказанное, а не опровергать.

Исследования Anthropic это наглядно показали:

• Та же модель генерирует и проверяет: исправляет ошибки примерно в 12% случаев
• Другой экземпляр той же модели проверяет: ~37% исправлений
• Модель из другого семейства проверяет: ~52% исправлений

Разница между 12% и 52% — это не деталь, а принципиальный разрыв. Чем независимее проверяющий, тем надёжнее результат.

Паттерн: разделение Maker и Checker

Суть паттерна — инженерная реализация первого принципа обеспечения качества: проверяющий должен быть независим от генератора. В архитектуре ИИ-агентов это выражается как разделение на два отдельных компонента: Maker (создатель) и Checker (проверяющий).

Три уровня независимости

Уровень разделения зависит от задачи и допустимых рисков:

• L1: Разделение контекста. Maker и Checker используют разные системные промпты, но одну и ту же модель. Минимальные затраты — подходит для низкорисковых задач, где важна базовая sanity-проверка.

• L2: Разделение экземпляров (рекомендуемый). Разные инстансы модели с разными настройками температуры — у Checker она ниже (около 0.1 для детерминированности). Оптимальный баланс для большинства продакшн-сценариев.

• L3: Разделение моделей и вендоров (максимальный). Maker на GPT-4o, Checker на Claude — или наоборот. Разные архитектуры, разные слабые стороны, минимальный набор общих failure modes. Самый надёжный вариант, но и самый дорогой.

Что именно проверяет Checker

Checker — не «ещё одна модель с промптом «перепроверь»». Это система с чётко определёнными типами валидации:

• Фактическая непротиворечивость — совпадает ли вывод с исходными данными? Критично для отчётов и саммари.
• Соответствие правилам — не нарушает ли вывод заранее заданные ограничения? Важно в финансах, медицине, юриспруденции.
• Логическая целостность — непротиворечива ли цепочка рассуждений? Нужно для аналитики и принятия решений.
• Формат — соответствует ли вывод ожидаемой структуре? Обязательно для API и структурированного вывода.
• Безопасность — нет ли вредоносного или токсичного контента? Для пользовательских агентов.
• Полнота — выполнена ли задача целиком? Для сложных многошаговых процессов.

Структурированный вывод Checker

Ключевой момент: результат проверки должен быть машиночитаемым. Не строка «всё хорошо», а структурированный JSON с типом ошибки, серьёзностью, местом в тексте и ожидаемым значением. Это позволяет не просто узнать, что что-то не так, но и автоматически построить обратную связь для следующей итерации.

Цикл: когда останавливаться

Бесконечный цикл «сгенерировал → проверил → переделал» — тоже ловушка. Без чётких условий остановки система может зациклиться, сжигая время и токены. Автор выделяет шесть условий завершения:

• Лимит попыток — жёсткое ограничение в 3–5 итераций. Просто и предсказуемо.
• Порог качества — остановка при достижении целевого балла. Подходит для постепенной оптимизации.
• Сходимость — если два последних вывода совпадают на 95%+, улучшений больше не будет.
• Убывающая отдача — если прирост качества между итерациями ниже порога, дальнейшие попытки бессмысленны.
• Временной бюджет — тайм-аут для защиты SLA. Критично для онлайн-сервисов.
• Гибридный режим (рекомендуемый) — комбинация перечисленных выше. Используется в продакшне.

Почему «просто сделать модель умнее» — не ответ

Многие считают, что ошибки ИИ-агентов — следствие недостаточно умной модели. Это неверный фрейм.

Более умная модель снижает количество неизвестных ошибок — но никогда не доводит его до нуля. Разделение Maker/Checker устраняет известные ошибки, делая их структурно невозможными для прохождения.

Продакшн-системы не стремятся к тому, чтобы ошибок «не было вовсе». Они стремятся к тому, чтобы ошибки ловились и исправлялись автоматически. В этом принципиальная разница между «сделать модель поумнее» и «построить архитектуру с валидацией».

Практическое применение

Автор публикации, У Цзи (Wu Ji), опубликовал рабочий каркас на Python, который реализует описанный паттерн. Framework поддерживает два режима — реальный (с подключением к OpenAI API) и тестовый (с мок-данными, без ключа). Это позволяет протестировать логику цикла локально, прежде чем подключать живую модель.

Сам по себе код — учебный пример, не продакшн-решение. Но принцип, который он иллюстрирует, вполне прикладной: если вы строите агента, который генерирует что-то значимое (отчёт, рекомендацию, юридический документ), отдельная система проверки с независимым контекстом — не роскошь, а необходимость.

Итог

Статья У Цзи — не открытие чего-то принципиально нового. Принцип разделения обязанностей проверки (maker/checker) существует в банковской сфере и DevOps десятилетиями. Но применительно к ИИ-агентам он часто игнорируется: разработчики добавляют к промпту «проверь себя» и считают проблему решённой.

Данные Anthropic и логика когнитивных искажений показывают, что этого недостаточно. Настоящая надёжность строится на архитектурном уровне — с независимой валидацией, машиночитаемым результатом и чёткими условиями остановки цикла. Это инженерный подход, а не надежда на то, что следующая версия модели будет «достаточно умной».