Boyko Constraint Engine — набор ограничителей, а не «то самое узкое место»

Происхождение

Пользователь принёс идею «Universal Bottleneck Discovery Engine»: найти в готовой системе скрытый механизм, ограничивающий её потенциал, и предложить минимальное изменение. Текста «Causal Optimization Engine v0.1.0» из того описания у нас нет (скиллов, плагинов и заметок с таким именем не найдено), поэтому ничего из него не заявляется как заимствованное. Главная поправка пользователя: ограничитель может быть не один. Отсюда дизайн: реестр вместо одной находки, измерение взаимодействий, проверка «части не больше целого», перемер после каждого исправления.

Взято снаружи (ссылки: references/method-and-sources.md): теория ограничений (несколько ограничителей, ранжирование, смещение после исправления, политика и метрика тоже бывают ограничителями); Coz (вклад измеряется виртуальным вмешательством, а не долей времени); DoWhy-GCM и взаимодействия по Шепли (вклад причин; скрытая переменная их искажает). Придумано здесь: реестр с типами взаимодействия, скрипт расчёта, защитная метрика, калибровка подсаженным дефектом, правила из наших ошибок (references/lessons-from-our-stack.md).

Когда использовать

Есть работающая система и измеримая конечная метрика, стабильно ниже ожидаемой; неочевидно, сколько причин и как они связаны; нужно знать, не маскирует ли одна причина другую. Не использовать без метрики и повторяемого запуска (шаг 0 останавливает) и не навязывать простым задачам с очевидным одним ответом.

Жёсткие правила

1. Набор, не одиночка. Реестр может содержать любое число записей, включая ноль. «Ограничитель один» заслуживается измерением (SINGLE_DOMINANT), а не принимается заранее.
2. Потенциал измеряется. «Есть запас» без замера потолка (все ограничители сняты) не утверждение; «щедро», «консервативно», «верхняя граница» требуют числа (Gate 4).
3. Части не больше целого. budget_ratio_sum_solo_over_total печатается рядом с разрывом; больше 1 значит перекрытие.
4. Каждое число из закоммиченного скрипта. Число из консоли не идёт в отчёт. Таблицу запусков хранит файл, ранжирует constraint_rank.py.
5. «Не измерено» не равно нулю. Пропуск остаётся value: null; пустая страта — UNDEFINED.
6. Порог до данных и уже, чем даёт нулевая конструкция. MCID и шум фиксируются до запусков; серая зона между «не отличимо от шума» и «стоит усилий» обязательна. Любая переформулировка проб или порога после просмотра данных раскрывается в отчёте.
7. Проверяет не тот, кто написал. Оракул и held-out, созданные в этой сессии тем же агентом, дают только [VERIFIED-SYNTHETIC]. Принятие требует независимой проверки.
8. Вмешательство только в песочнице (отдельный worktree или копия). Живая система, деньги, учётные данные, отправка наружу — Red/Black, только по явному «да».
9. Кандидат-код лежит на пути выполнения (цепочка вызовов от точки входа). Факт «реализовано, но не подключено» сам является кандидатом («недоподключённый компонент»). Для политик, ресурсных пределов и метрики нужно другое доказательство (конфигурация, документ, замер).
10. Метрика как кандидат оценивается на неизменном втором оценщике, отдельной линейкой; held-out не может быть тем же оценщиком, который «исправлялся».
11. Охранная метрика G в каждой строке. Каждая строка таблицы несёт guard_changed — сколько уже верных случаев это подмножество правок сломало. Строка с G>0 нечиста: из неё нельзя делать вывод «безопасное исправление» (скрипт даёт best_clean_subset).
12. Скрытая половина данных. Если метрика построена на размеченных данных, часть размеченного остаётся невидимой для искателя и проверяется только после его вердикта (references/gold-and-holdout.md).

Шаг 0 — Применимость, дешёвое исправление, личность системы

1. Применимость. Нужны конечная метрика, повторяемый базовый запуск с известным шумом и способ менять отдельные части. Иначе — NEEDS_INSTRUMENTATION с перечнем, что добавить, и остановка. Честное сравнение: ядро метода — факторная абляция из планирования эксперимента; для k ≥ 5 её дешёвый вариант «по одному + снятие одного от потолка» (2k+2 запусков) отвечает на большую часть вопросов. Движок добавляет реестр, защитные метрики и калибровку, а не заменяет знание статистики.
2. Дешёвое исправление раньше поиска (векторизация цикла, индекс, кэш, готовая библиотека): применить, перемерить, а движок использовать для остатка («Using Wheels First»).
3. Личность системы. Записать ветку, HEAD, дату, версии данных. Базовый запуск делать на выборке, которую система реально потребляет после своих фильтров, а не на сыром источнике.

Шаг 1 — Замороженное утверждение и план обнаружимости

До запусков записать n, baseline_or_sigma, alpha, power, MDE, MCID (estimand-ops.md, MDE). Считать независимые единицы: 76 случаев из пяти шаблонов — около пяти наблюдений. Отделить скрытую половину данных (правило 12). Построить нулевой и потолочный варианты, чтобы убедиться, что порог можно провалить. Для детерминированной системы (шума запусков нет) noise — это неопределённость выборки: биномиальное отклонение sqrt(n·p·(1−p)) в тех же единицах, что и значения (штуки со штуками, доли с долями), repeats = 1.

Шаг 2 — Карта системы и карточка адаптера

references/system-card.md: этапы, состояния, управляющие решения, пороги, пределы, пять операций адаптера (описать, наблюдать, базовый запуск, вмешаться в песочнице, проверить). Невыполнимая операция — находка (NEEDS_INSTRUMENTATION), а не повод придумать результат.

Шаг 3 — Разрыв и потолок

Потолок считается по кандидатам шага 4: набросать их, вернуться и измерить метрику при снятии всех сразу против базового запуска. Обязателен разрез разрыва по стратам (по типам ошибок, этапам, категориям): именно он подсказал кандидатов в обоих калибровочных прогонах; скрипт страты не разделяет, прогонять его по каждой отдельно. Страта без наблюдений — UNDEFINED. Если известно идеальное значение, передать perfect_value: скрипт вернёт residual_to_perfect, и остаток выше порога означает, что в списке не все ограничители (unlisted_constraints_suspected). Разрыв не больше двух стандартных ошибок разности → NO_CONSTRAINT_DETECTED (только «среди перечисленных»). Снятие всех РОНЯЕТ метрику → ANOMALOUS_NEGATIVE_GAP, не нулевой результат.

Шаг 4 — Реестр кандидатов

Для каждого: механизм одним предложением, место (файл:строка), что он должен менять в наблюдаемом, конкурирующее объяснение, дешёвая проба. Перебрать типы: порог, маршрутизация, фильтр, ранжирование, порядок операций, устаревшее состояние, конфликт компонентов, ограничение ресурса или политика, сама метрика или оценщик, недоподключённый компонент. Кандидатов называть по данным (разрез из шага 3), а не по типичным багам. Не искать одним словарём: назвать, как это назвали бы в смежной области.

Шаг 5 — Проба и калибровка

Виртуальное вмешательство: заменить выход кандидата эталоном или минимально подправить его, остальное оставить. До замера записать, как патчи складываются (независимые переключатели, порядок применения, запасной шаг); переделка после просмотра данных раскрывается (правило 6). Для k ограничителей:

• k ≤ 4: полная таблица 2^k, скрипт даёт доли Шепли;
• 5–6: одиночные, «снять всё кроме одного» (k запусков; без них замаскированные и дополняющие ограничители пропадают), парные для верхних;
• больше 6: сгруппировать по механизму.

В каждой строке: среднее по repeats повторам и guard_changed. Пороги скрипта — две стандартные ошибки соответствующей разности или взаимодействия, а не сам шум.

Калибровка (режим CALIBRATE, рецепт: references/calibration-recipe.md): на копии с подсаженным известным дефектом (должен быть найден) и на копии без дефекта (должен вернуться NO_CONSTRAINT_DETECTED). Дефект подсаживает не тот, кто ищет. Находка контроля показывает лишь, что метод видит дефекты такого класса. Замена этапа эталоном даёт нижестоящим этапам вход, какого в работе не бывает: записать, не искажает ли это результат.

Шаг 6 — Запись запусков

JSON-файл в папке эксперимента: fixed, value (или null), guard_changed, число повторов, шум и MCID в тех же единицах, что и значения. Значения пишет скрипт запуска.

Шаг 7 — Ранжирование

python skills/extensions/boyko-constraint-engine/scripts/constraint_rank.py runs.json

Вход и выход описаны в шапке скрипта. Вердикты:

Дополнительные поля: unclean_subsets и best_clean_subset (правило 11), residual_to_perfect, warnings (в том числе проверка единиц: шум на порядки меньше значений — вероятно, смешаны доли и штуки).

Множественные сравнения: порог в 2 SE применяется к каждой паре и вкладу без поправки; при одном реальном ограничителе ложный «замаскированный» у пустых кандидатов получился в 7–13% прогонов (k ≥ 3), на полностью нулевой системе не больше 0,6% (моделирование проверяющего, [VERIFIED-SYNTHETIC]). Любой MASKED-вывод подтверждать повторно.

Вклад на цену считается по вкладу ОРАКУЛА (верхняя граница). Реальное исправление измеряется отдельно (шаг 8) и обычно ниже: не превзошло «ничего» — перейти к следующему. Правила остановки: не больше трёх циклов подряд, раньше — если очередной разрыв меньше MCID или бюджет проб исчерпан.

Шаг 8 — Минимальное исправление

Лестница минимальности: настройка → условие → локальный алгоритм → структура данных → переход между этапами. Сравнить минимум два варианта и «ничего не менять»; принимать только то, что лучше арма «ничего» на скрытой половине при тех же ресурсах и с G=0 (или с оправданием каждого изменения). ΔQ и затраты считать раздельно; составной скаляр без согласованных единиц не делать.

Шаг 9 — Независимая проверка и решение

1. Скрытая половина и регрессии на реальных независимых данных; skeptic на отчёте без истории сессии. Свою оценку «сколько улучшения переживёт проверку» записать заранее и сравнить с фактом.
2. Переносимость: хотя бы одна смена данных или условий.
3. Решение по структуре, не из закрытого списка: ACCEPT, REJECT, NOTHING_TO_CHANGE, SPLIT, NEEDS_INSTRUMENTATION, UNIDENTIFIABLE или свой исход с пояснением.
4. Записать проверенные и опровергнутые механизмы, условия применимости, команды. Опровергнутые идут в null_results/, отложенные в parked/.

Режимы

Что скилл не делает

Не запускается на живой системе и не меняет её без «да»; не заявляет универсальность (её определяет CALIBRATE); не заменяет профайлер скорости и /sci-evidence; не гарантирует, что нашёл все ограничители (отчёт обязан перечислить, что не проверялось, а perfect_value показывает остаток).

Зрелость

maturity: described. Что известно (references/calibration-log.md): на подсаженных дефектах (хук routing-floor) оба найдены точно, нулевая копия без ложных находок; на реальном парсере вердиктов каталога набор причин найден, на скрытых 27 файлах ошибок 25 → 7. Это три системы одного автора и один класс (разбор текста по регулярным выражениям), эталон из двух разметчиков-агентов; для dogfooded нужны другие классы систем и независимая проверка людьми.

Выход

references/report-template.md. Минимум: реестр по приоритету, budget_ratio, also_real, best_clean_subset, остаток до идеала, что подтверждено и что нет, что не проверялось, порядок исправлений, условие пересмотра.