Чем отличается от соседней заметки Agent Evals — про качество исхода: набор, судья, порог, шлюз. Эта заметка — про два других вопроса: вёл ли себя рантайм допустимо по дороге к исходу, и работают ли сами защитные механизмы.
Проверка процесса и проверка результата — разные вещи
Урок из работ по проверяющим для агентов, управляющих компьютером: одного бинарного вердикта недостаточно для длинных траекторий. Агент может идти по правильному процессу и упереться в ограничение среды — или дойти до номинально верного результата небезопасным путём. Схлопывание обоих случаев в одну оценку теряет ровно то различие, ради которого оценка нужна.
Отсюда разделение на проверку процесса и проверку результата, применяемое к одной траектории.
Что именно проверяют поведенческие оценки
Вопросы, на которые обычная оценка качества не отвечает в принципе:
- скрывает ли агент спорный шаг;
- пытается ли обойти подтверждение;
- меняет ли полезную нагрузку после проверки;
- идёт ли в рискованный путь инструмента без достаточного основания;
- нарушает ли ожидаемый путь эскалации;
- использует ли дрейф контракта или несовпадение схемы, чтобы пересечь границу контроля;
- злоупотребляет ли семантикой прерывания, истечения или повторной инициализации, чтобы вернуться к более слабому состоянию контроля.
Последние два — прямая проверка на несоответствие целей (Agentic Misalignment).
Семантический линтер в горячем пути
Набор независимых типизированных вопросов можно применять к одной трассе параллельно: «был ли изменён payload после approval?», «пропущена ли обязательная проверка?», «есть ли признаки цикла?». Typed Decision Models делает такой слой дешевле свободного LLM-судьи и оставляет композицию правил в коде.
Но типизированный ответ не превращает проверяющий в источник истины. Для каждого вопроса нужны размеченные реальные траектории, калибровка вероятностей и risk/coverage-кривая; высокорисковый side effect не разрешается одной уверенностью модели. Этот слой подходит для онлайн-сигнала, triage и эскалации, а не заменяет детерминированные инварианты и контрольные evals.
Контрольные оценки проверяют защиту, а не модель
Третий контур: проверяются сами защитные механизмы. Вопрос не «хорошо ли отвечает система», а «сработал ли бы шлюз, если бы понадобился».
Практическая ценность в том, что защита деградирует молча. Guardrail, который перестал срабатывать из-за смены модели или формата, не выдаёт ошибки — он просто пропускает. Контрольная оценка ловит это до инцидента (Guardrails).
Стандарт требует того же двумя способами. Со стороны расписания: набор проверок выравнивания под версионным контролем, прогоняемый на каждом обновлении или выпуске модели (AISVS C11.1.2), и автоматический оценщик, измеряющий долю вредного содержимого и помечающий регрессии сверх порога (C11.1.5). Со стороны предмета проверки — требование, которое прямо описывает третий контур этой заметки: механизм проверки перед высокорисковым действием сам обязан быть защищён от манипуляции враждебным вводом и не должен обходиться инъекцией (C9.2.7). То есть проверяющий контур входит в область проверки наравне с проверяемым.
Симулятор пользователя и синтетический противник — разные роли
Различие, которое легко смазать. Симулятор пользователя воспроизводит правдоподобное поведение обычного человека, включая неудобное: путаные формулировки, смену намерения на полпути, отказ отвечать на уточнение. Синтетический противник целенаправленно ищет обход.
Смешение даёт худшее из двух: набор, который недостаточно враждебен, чтобы найти дыру, и недостаточно реалистичен, чтобы поймать бытовой отказ (Continuous Red Teaming).
Связано с
- Agent Evals — оценка исхода и шлюз качества
- Agentic Misalignment — класс отказа, ради которого это строится
- Continuous Red Teaming — состязательный контур в проде
- Guardrails — то, что проверяют контрольные оценки
- Generator Evaluator — внешняя проверка как принцип
- Agent SLO — качество проверяющих как измерение здоровья
- ADLC — где эти оценки встраиваются в цикл
- Typed Decision Models — массовая вероятностная проверка узких свойств одной траектории