← Капитанский журнал

Отбор вместо починки — генерируем нескольких кандидатов и выбираем лучшего

Почему мы перестали пытаться чинить сломанные игровые графы и начали генерировать нескольких кандидатов — позволяя движку выбрать победителя.

Цикл исправлений не сходился. Это не проблема промпта и не проблема силы модели — это структурная проблема. Loom-пайплайн был построен на схеме «генератор + ремонтник»: одна модель генерирует граф, Inspector находит ошибки, fix-Shuttle чинит, повторяем. После месяцев такой работы эмпирический результат — ноль играбельных игр. Ceiling probe (task-184) это доказал: даже fix-Shuttle фронтирной модели исчерпал бюджет, не починив ни одного семантического бага.

ADR-028 переворачивает парадигму: генератор + отборщик вместо генератора + ремонтника.

Новый поток: Shuttle генерирует k кандидатов (начинаем с 3-5) дешёвыми/средними моделями, с вариацией. Каскад верификаторов ранжирует их: грамматика/схема (constrained decoding + Golem) → property-инварианты (статические) → headless-симуляция → playthrough. Кандидат, упавший на уровне N, не тратит бюджет уровней N+1. Победитель — кандидат с лучшим объективным скором, а не последняя итерация ремонта.

Цикл исправлений по-прежнему существует, но понижен до вторичного: применяется к лучшему кандидату для добивания остаточных findings с маленьким бюджетом. Основной механизм сходимости — отбор, а не ремонт.

Это согласуется с исследованиями 2024-2026 (Weaver, Multi-Agent Verification, GAVEL), показывающими, что отбор на основе верификации систематически поднимает качество выше pass@1, а слабые генераторы + отбор ≈ дорогие модели. Ключевая асимметрия: в литературе верификаторы слабые (LM-judges, reward-модели). У нас есть что-то ближе к оракулу — исполняемый движок со структурной валидацией, property-инвариантами, headless-симуляцией и playthrough.

Взаимодействие с ADR-026 (IR) мультипликативно: IR сжимает пространство кандидатов (структурные ошибки становятся непредставимыми), отбор выбирает в сжатом пространстве (закрывает остаточный семантический класс полноты). Отбор без IR малоэффективен (почти все кандидаты на свободном JS мертвы). IR без отбора оставляет класс полноты на единственном сэмпле.

Каждый прогон теперь логируется как структурированный датасет: входные правила → конфигурация моделей → кандидаты → вердикты каскада верификаторов → исход. Дёшево сейчас; в будущем — опция для RL-дообучения.

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