Призмы: многоугловое независимое ревью (и когда оно вредит)

Коротко

Призма — угол независимой оценки готового артефакта от лица роли: безопасность, изоляция арендаторов, регрессии, доступность, перф, локализация и другие. Это не агент-исполнитель и не «стиль-персона»: контракт узкий — вердикт pass/warn/block, находки с severity и одно «что бы я изменил». В Quest 13 призм; каждая несёт вопросы-линзы (чек-лист своего угла), красные линии blockIf, вес голоса и право вето. Несколько призм судят артефакт независимо — каждая не видит чужих вердиктов, потом синтез сводит голоса. Статья показывает worked-пример, как так ловится дыра, и честно разбирает, в каких ситуациях многоугловое ревью вредит и его стоит не включать.

Что это

Призма (lens) — это угол независимой оценки одного артефакта от лица конкретной роли: безопасность, изоляция арендаторов, регрессии, доступность, перф, локализация, дизайн-ремесло и т.д. Ключевое: призма — не агент-исполнитель, который что-то делает, и не «стиль-персона». Её контракт узкий и проверяемый: посмотреть на готовый артефакт со своего угла и вернуть вердикт pass | warn | block плюс находки с уровнем серьёзности (info/minor/major/critical) и одно «что бы я изменил».

В базовом движке Quest таких призм 13. Каждая несёт:

• вопросы-линзы — чек-лист угла (у безопасности: «есть ли конкатенация ввода в SQL/шелл/HTML?», «утёк ли секрет в код/лог?», «достижим ли защищённый путь без auth?»);
• красные линии (blockIf) — что делает вердикт block;
• вес голоса (по умолчанию 1) и право вето.

Зачем так

Один агент, который сам написал код и сам его одобрил за один проход, — это конфликт интересов. Многоугловое ревью — встроенное недоверие: разные углы бьют по артефакту независимо (fan-out), а потом синтез сводит их голоса. Пять углов подняты в ранг вето-судей, потому что это инварианты, чья поломка дороже всего: security, tenancy (cross-tenant), gating (утечка выручки), regression, data-integrity. У них вес 2 и право вето.

Правило синтеза зашито детерминированно (и рендерится буквальным текстом в пакет, чтобы даже слабая модель его исполнила):

Любой critical у вето-призмы → общий BLOCK независимо от остальных голосов. Иначе BLOCK, если сумма весов block-голосов ≥ порога. Ничья → BLOCK (в пользу безопасности).

Worked-пример: как ловится дыра

Вход. Инженер-агент добавил роут GET /api/reports/:id, читающий отчёт по id из URL. Артефакт (code + api) уходит на фазу Review.

Что делает движок:

1. По триггерам включаются призмы для артефактов code/api: security, tenancy, gating, regression, perf, maintainability, business. Каждая смотрит независимо, не видя вердикта соседа.
2. Призма tenancy (роль «Архитектор данных», вес 2, вето) проходит по своим вопросам и ловит: id ресурса берётся из ввода клиента без проверки принадлежности к организации — классический IDOR, cross-tenant чтение достижимо. Её вердикт: block, severity critical.
3. Остальные призмы вернули pass/warn.
4. Синтез: есть critical у вето-призмы → общий вердикт BLOCK, независимо от того, что шесть других углов сказали «ок».
5. Запускается цикл loopUntilDry: чинится класс проблемы (не только этот роут — grep всех мест, где id берётся из ввода без скоупа), затем пере-суд только затронутыми углами. Повторяется до «сухо» (нет critical/block), максимум 2 круга «ревью→фикс» (3-й деградирует — Anthropic/Cloudflare), потом стоп и отчёт владельцу с открытыми пунктами.

Результат. IDOR, который один самодовольный проход пропустил бы, пойман до прода одним независимым углом с правом вето — а не «средним мнением» команды, где голос безопасности растворился бы среди семи «в целом норм».

Когда многоугловое ревью ВРЕДИТ (честно)

Больше судей — не всегда лучше. Это подтверждает и исследовательская литература, и здравый смысл:

• Коррелированные ошибки. Модели из одного семейства обучены на похожих данных и ошибаются одинаково. Добавить ещё один похожий угол на той же модели — часто не новая информация, а усиление общей ошибки («ловушка популярности»: консенсус закрепляет правдоподобный, но неверный ответ). Ценность призм — в разных ролях и разных вопросах, а не в количестве голосов одной модели.
• Стоимость и задержка. Каждый угол — это токены и время. Гонять 13 призм на переименование переменной — расточительство. Поэтому призмы скоупятся по фазам и типам артефактов (a11y — только на UI, data-integrity — только на миграции), а мелкие задачи идут лёгким циклом.
• Self-enhancement и прочие biases. LLM-судьи склонны хвалить многословное, авторитетное и «своё». Узкие проверяемые вопросы-линзы и модель серьёзности снижают это, но не убирают полностью.
• Шум топит сигнал. Если каждый угол сыплет minor-замечаниями, критичное вето теряется. Отсюда — уровни серьёзности и порог качества: полируем не бесконечно, а до заданной планки.

Вывод: призмы сильны там, где углы действительно независимы и различны по роли, а веса/вето отражают реальную цену ошибки. На тривиальной правке или при семи одинаковых углах овчинка не стоит выделки — движок это учитывает пропорциональностью.

Честная граница

Вердикты призм сегодня — ADVISORY: модели предписано подчиниться синтезу, но нет кода возврата, который физически заблокирует сдачу при BLOCK (кроме Claude-хука на опасные команды). Текст призм (вопросы, красные линии, веса) поставляется в открытом виде — его можно посмотреть ещё до покупки, а после — читать и настраивать под себя. Командам, которым нужны всегда свежие проверки, доступен server-bound-режим: judge/gate выносят вердикт на сервере, рубрики обновляются централизованно — движок получает новые проверки без переустановки (без серверного ключа модели работает детерминированная базовая проверка с честной пометкой deterministic-fallback). Вы покупаете собранную, откалиброванную и работающую из коробки вето-модель — дисциплину, которая даёт результат с первой задачи.

Sources:

• Correlated Errors in Large Language Models (arXiv)
• Exploring LLM-as-a-Judge — Weights & Biases