Почему наличие строки ничего не доказывает
Текстовая поверхность принуждается только чтением (Agent Instruction Surfaces). Между «правило есть в контексте» и «правило исполнено» лежат три независимых события, каждое из которых может не случиться: правило попало в окно, модель его выбрала среди конкурирующих требований задачи, модель довела его до конца, а не бросила на середине.
Три привычных способа убедиться не работают ни один:
- спросить агента — «ты соблюдал правила?» отвечает «да» практически всегда; это тот же дефект, из-за которого не работает самоаттестация в гейтах (Guardrails);
- посмотреть на успешный прогон — задача решена, значит правило, вероятно, соблюдено; но постановка могла требовать того же самого, и тогда замерено совпадение целей, а не сила правила;
- посчитать, сколько раз правило упоминалось — упоминание не действие.
Общее у всех трёх: они смотрят на исход, а правило описывает путь. Замерять надо путь.
Предмет замера — последовательность шагов, а не текст
Первым шагом из документа правила выводится ожидаемая последовательность поведения: какие действия и в каком порядке обязаны появиться в трассе, если правило исполнено. «Сначала поиск существующих реализаций, потом чтение найденного, только потом запись файла» — это проверяемое утверждение, в отличие от «переиспользуй существующий код».
Такой перевод сам по себе полезен и до всякого прогона: правило, из которого не выводится ни одного наблюдаемого шага, не будет исполнено не потому, что модель его игнорирует, а потому, что его нечего исполнять.
Три степени строгости постановки, и различает только третья
Сценарии генерируются на трёх уровнях поддержки правила со стороны формулировки задачи:
| Постановка | Что в ней сказано о правиле | Что показывает результат |
|---|---|---|
| поддерживающая | задача прямо просит того же, что требует правило | верхняя граница: способна ли система в принципе |
| нейтральная | задача о правиле молчит | фоновая частота срабатывания |
| конкурирующая | задача толкает в противоположную сторону («быстро, без лишнего», «просто допиши») | есть ли у правила сила |
Конкурирующая постановка — единственная различающая. Правило, соблюдаемое только при поддерживающей формулировке, ничего не добавляет к постановке задачи: то же поведение получилось бы и без него, а платится за него контекст на каждом запуске.
Название механизма у авторов — prompt independence: измеряется соблюдение тогда, когда постановка правило не поддерживает.
Что считает модель, а что обязано считаться детерминированно
Замер разделён по надёжности, и разделение принципиально:
- сопоставление вызова с шагом делает модель-классификатор, а не регулярное выражение: один и тот же шаг «поискать импортёров» выражается через
Grep,Glob,rgиз оболочки илиfind, и перечислить формы заранее нельзя; - порядок шагов во времени проверяется детерминированно по трассе: сравнение отметок — операция, которой модель не нужна, а её участие внесло бы шум в единственную часть замера, которая может быть точной.
Смешивать эти две части нельзя по той же причине, по которой в Agent Instruction Surfaces разведены два класса hooks: детерминированность запуска не наследуется вердиктом.
Результат — не оценка, а адрес починки
На выходе — доля соблюдения по каждому шагу ожидаемой последовательности, а не одно число на правило. Разница практическая: правило из пяти шагов с общей оценкой 60% не чинится нигде, а то же правило с провалом на третьем шаге указывает на конкретную строку.
Шаг с низкой долей — кандидат на подъём по лестнице починки: то, что не исполняется как текст, переносится на ступень, которая срабатывает сама (Harness Optimization). Замер здесь закрывает недостающую половину: лестница говорит, куда поднимать неисполняемое правило, но не говорит, как узнать, что оно не исполняется.
Возможен и обратный вывод, и он ценнее: шаг соблюдается почти всегда даже при конкурирующей постановке — значит правило описывает то, что система делает и так, и строку можно удалить (Convention Over Instruction).
Чего замер не даёт
- Он не оценивает качество самой процедуры. Правило может исполняться на сто процентов и при этом вести не туда; это предмет evals продукта (Agent Evals), а не замера соблюдения.
- Он не переносится через смену модели или обвязки. Доля соблюдения — свойство пары «правило + рантайм», и после смены поколения модели её надо снимать заново; ровно поэтому устаревшие компенсации ограничений модели живут в файлах инструкций годами.
- Он стоит прогонов. Каждый сценарий — отдельный запуск агента с полной трассой, и три уровня строгости умножаются на число сценариев. Отсюда область применения: правила, объявленные обязательными, и правила, из-за которых спорят, — а не весь файл инструкций подряд.
- Он не заменяет принуждение. Высокая доля соблюдения остаётся вероятностной величиной; требование безопасности от этого не перестаёт нуждаться в машинном гейте.
Связано с
- Agent Instruction Surfaces — куда положить инструкцию; здесь — как проверить, что положенное исполняется
- Harness Optimization — лестница надёжности починки, на которую поднимают шаг с низкой долей соблюдения
- Convention Over Instruction — обратный вывод замера: правило, дублирующее поведение по умолчанию, удаляется
- Skill Change Control — правка правила выпускается через proposal, а не заменой строки после первого же замера
- Agent Evals — оценка продукта, а не поведения обвязки; разные предметы
- Guardrails — почему самоаттестация не годится ни как гейт, ни как замер
- Verifiable Eval — соседний приём: проверяемый критерий вместо суждения о результате