Rejudge — независимая проверка для ИИ-агентов: как работает панель моделей
ИИ-агенты уже умеют писать функции, менять архитектуру и готовить pull request. Но проверять их работу той же моделью и в том же контексте — всё равно что просить автора кода провести независимый аудит самого себя. Open-source проект Rejudge предлагает другой подход: один вопрос получают несколько изолированных моделей-рецензентов, а отдельная модель-судья сопоставляет их выводы и формирует итоговый ответ.
Это не «машина истины» и не замена человеку. Rejudge интересен как инженерный паттерн: он разделяет генерацию и проверку, делает разногласия видимыми и помогает команде не принимать уверенный ответ одного AI-агента за доказанный факт.
Что именно меняет Rejudge
Обычная самопроверка AI-кода часто сохраняет исходные допущения модели. Даже новый запрос в той же сессии несёт накопленный контекст, а повторная проверка той же моделью может воспроизвести похожую ошибку. Переход к другой модели уменьшает эту зависимость, но оставляет решение одному рецензенту.
Rejudge поднимает проверку ещё на уровень выше. Один и тот же вопрос отправляется трём рецензентам в отдельных контекстах. Они анализируют задачу независимо, после чего модель-судья читает отчёты, уточняет спорные места у панели и собирает единый ответ. Благодаря этому пользователь видит не только вывод, но и зоны, где модели не согласны.
Как устроен процесс проверки
- Пользователь формулирует вопрос: например, безопасна ли миграция базы данных, не нарушена ли модель прав или готов ли diff к выпуску.
- Несколько моделей получают одинаковую задачу в изолированных сессиях. Для разнообразия можно подключить разных провайдеров и разные модели.
- Рецензенты могут читать файлы, искать по проекту, смотреть структуру каталогов и git diff. По умолчанию эти инструменты доступны только для чтения.
- Отдельная модель-судья получает отчёты рецензентов. Доступа к рабочему проекту у неё нет; при противоречиях она может отправить панели дополнительные вопросы.
- Результат сохраняется с идентификатором запуска. К обсуждению можно вернуться и задать уточняющий вопрос через режим продолжения сессии.
Проект распространяется как единый npm-пакет и предлагает три режима: командную строку, нативный инструмент для Pi и Agent Skill для других coding-агентов. Для запуска требуется Node.js 22.19.0 или новее, а также доступ к выбранным провайдерам моделей.
Где такой подход особенно полезен
Наиболее понятный сценарий — проверка изменений перед merge. Команда может передать Rejudge вывод git diff и попросить найти регрессии, недостающие проверки, ошибки конкурентного доступа или проблемы с откатом. Несколько рецензентов полезны и при архитектурных решениях, где нет одного очевидного ответа, но важно выявить скрытые допущения.
- изменения схемы базы данных, блокировки и план отката;
- авторизация, разграничение прав и обработка секретов;
- контракты API и обратная совместимость;
- конкурентность, очереди, повторные запросы и идемпотентность;
- оценка технического плана до того, как агент начнёт массово менять код.
Для интеграторов ИИ в Узбекистане это особенно практично в проектах, где AI-агент получает доступ к корпоративному репозиторию. Независимая панель может стать дополнительным контрольным этапом между автономной генерацией и человеческим code review. Однако включать её в каждый маленький коммит необязательно: многомодельный запуск логичнее резервировать для дорогих, рискованных или трудно обратимых решений.
Почему три ответа ещё не гарантируют правильность
Разнообразие моделей снижает риск единственной слепой зоны, но не устраняет общие ошибки. Модели могли обучаться на похожих данных, использовать сходные эвристики и одинаково неверно понять неполное требование. Убедительный консенсус остаётся гипотезой, пока его не подтвердят тесты, документация и экспертная проверка.
Авторы Rejudge прямо предупреждают: завершённый запуск не обязательно является корректным, а измеренного преимущества над одной сильной моделью пока не заявлено. Поэтому итог панели лучше использовать как список проверяемых гипотез. Для критичных решений нужны воспроизводимые тесты, статический анализ, сканеры зависимостей и решение ответственного инженера.
Стоимость, конфиденциальность и prompt injection
Многомодельная проверка дороже обычного запроса: свежий запуск означает как минимум по одному обращению к каждому рецензенту и ещё одно — к судье. Циклы инструментов, повторные попытки и уточняющие вопросы увеличивают расход. В самом Rejudge нет встроенного лимита бюджета, поэтому команде стоит заранее определить допустимые модели и правила запуска.
Есть и риск раскрытия данных. Каждый настроенный провайдер получает запрос, а фрагменты файлов, прочитанные рецензентом, могут попасть в его сессию. Судье передаются отчёты, которые способны содержать цитаты из кода. Перед использованием с закрытым репозиторием нужно проверить договоры с провайдерами, политику хранения данных, географию обработки и исключить секреты из доступного контекста.
Текст внутри репозитория также может содержать инструкции, которые попытаются повлиять на модель. Режим только для чтения не позволяет рецензентам изменить файлы, но сам по себе не защищает от утечки данных через prompt injection. Опция расширенного доступа добавляет запись и shell-команды, причём документация подчёркивает: это не песочница. Такой режим допустим только в изолированной среде и после отдельной оценки рисков.
Как провести безопасный пилот
- Начать с некритичного репозитория и одной конкретной задачи — например, анализа diff перед ручным review.
- Выбрать модели разных семейств, но не передавать им секреты, персональные данные и производственные дампы.
- Оставить рецензентам доступ только для чтения и не включать расширенный режим по умолчанию.
- Сравнивать замечания панели с тестами и выводами инженера, фиксируя полезные находки и ложные срабатывания.
- Измерять не только качество, но и задержку, стоимость одного запуска и объём данных, отправленных внешним провайдерам.
Если пилот покажет, что панель регулярно находит дефекты, пропущенные одним агентом и человеком, Rejudge можно встроить в контрольную точку CI/CD. Но финальный допуск к выпуску должен оставаться за проверяемыми правилами и ответственным специалистом.
Первоисточники
Материал носит информационный характер. Для проверки безопасности критичного кода используйте профильные инструменты, изолированную среду и независимый аудит специалистов.
