Instruction Compliance Measurement

Правило, записанное в файле инструкций или в skill, — это гипотеза о поведении, а не свойство системы. Проверяется она прогоном при постановке задачи, которая правилу не помогает: соблюдение при дружественной формулировке не отличает работающее правило от совпадения.

Почему наличие строки ничего не доказывает

Текстовая поверхность принуждается только чтением (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 — соседний приём: проверяемый критерий вместо суждения о результате