Глава 25. Поведенческие оценки, контрольные оценки и автоматизированное соревновательное тестирование¶

1. Почему обычных регрессионных оценок уже недостаточно¶

Регрессионные оценки отлично отвечают на вопрос:

• не сломали ли мы то, что раньше уже работало.

Но для агентных систем этого мало.

Если система умеет:

• выбирать стратегию;
• использовать инструменты;
• запоминать состояние;
• проходить через подтверждения;
• и адаптироваться к переходным условиям,

то тебе нужны не только регрессионные оценки, но и проверки поведения.

Именно здесь полезно различать:

• поведенческие оценки;
• контрольные оценки;
• автоматизированное соревновательное тестирование.

Чистая граница здесь такая: оценки выносят суждение о том, как система ведет себя и доказывает ли управляемая поверхность свою работоспособность под давлением. Они не заменяют контур реагирования, доказательный слой наблюдаемости или реестр контура. Они производят суждения, которыми потом пользуются все эти слои.

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

2. Что такое поведенческие оценки¶

Поведенческие оценки проверяют не только финальный результат, но и форму поведения системы.

Полезный урок из свежих работ по проектированию проверяющих для агентов, работающих с компьютером, состоит в том, что одного бинарного вердикта часто недостаточно для длинных траекторий. Агент может идти по правильному процессу, но упереться в ограничение среды, или дойти до номинального результата через небезопасный путь. Поэтому проверку полезно разделять на process verification и outcome verification, а не схлопывать все в одну оценку.

Например:

• скрывает ли агент спорный шаг;
• пытается ли обойти подтверждение;
• меняет ли полезную нагрузку после проверки;
• идет ли в рискованный путь инструмента без достаточного основания;
• нарушает ли ожидаемый путь эскалации;
• использует ли дрейф контракта или несовпадение схемы, чтобы пересечь границу контроля;
• злоупотребляет ли семантикой прерывания, истечения или повторной инициализации, чтобы вернуться к более слабому состоянию контроля.

То есть вопрос уже не “правильный ли ответ”, а “правильно ли вела себя среда исполнения под этим сценарием”.

3. Что такое контрольные оценки¶

Контрольные оценки проверяют сами защитные механизмы, а не только качество модели.

Их типичные вопросы такие:

• использует ли проверяющий проверяемую рубрику, а не непрозрачный одиночный вердикт;

• различает ли он управляемый и неуправляемый отказ;

• остановит ли слой политик эту возможность;

• действительно ли шлюз подтверждения требует человека;
• сработает ли шлюз отката;
• ведут ли себя механизмы контроля приостановленного и фонового запуска так, как задумано;
• ведут ли себя контроль истечения сессии возможности и повторной инициализации так, как задумано;
• зафиксируется ли побочный эффект в трассах;
• сможет ли аварийный контроль отключить рискованный путь.

Это важный сдвиг: ты проверяешь не только модель, но и контур управления вокруг нее.

В зрелой программе сам проверяющий тоже становится частью поверхности контроля. Если он дает ложную уверенность, эту ошибку наследуют поэтапный выпуск и контуры обучения. Поэтому проектирование проверяющего стоит рассматривать как управляемую инфраструктуру, а не как удобную вспомогательную инструкцию.

Сюда же относятся и замены контракта проверяющего. Регрессия оценки может прийти не только из модели или поведения среды исполнения, но и из непроверенного изменения версии контракта проверяющего, которое тихо меняет стандарты оценки.

4. Что такое автоматизированное соревновательное тестирование¶

Автоматизированное соревновательное тестирование — это уже не набор заранее написанных примеров, а систематический способ генерировать, варьировать и масштабировать противоборствующие сценарии.

Его практическая ценность в том, что он:

• помогает находить режимы отказа, о которых команда не подумала сама;
• лучше покрывает крайние случаи;
• заставляет смотреть на поведение под давлением, а не только на “нормальный день”.

Anthropic в последних публикациях очень явно двигает именно этот слой: каркасы контрольных оценок и более сильные генераторы соревновательных сценариев. ³⁴

4.1. Прохождение WAF не равно успешной атаке¶

Адаптивный противник может улучшить наблюдаемую метрику, разрушив смысл самой проверки. Если модель меняет запрос до тех пор, пока WAF не перестаёт его блокировать, она может случайно превратить атакующий ввод в безвредный. Поэтому отсутствие блокировки — сигнал для разбора, а не доказательство эксплуатации. В описанном Cloudflare эксперименте ручной отбор был обязательным шагом между незаблокированным запросом и находкой.⁵

Нужно различать три независимых вопроса:

• Прохождение защитного слоя: был ли валидный запрос действительно отправлен к разрешённой цели, какой слой обработал его и подтверждено ли отсутствие блокировки именно WAF?
• Сохранение атакующей семантики: остаётся ли изменённый запрос атакой для конкретного парсера, маршрута и конфигурации приложения? Утверждения модели об эквивалентности недостаточно.
• Подтверждённый эффект: есть ли независимое свидетельство результата на стороне контролируемой цели, а не только HTTP-статус, перенаправление или отсутствие страницы блокировки?

Сохраняйте эти измерения раздельно, включая unknown: редирект без проверки origin не доказывает эксплуатацию; неизвестный эффект не равен ни успеху атаки, ни доказанной безопасности приложения. Достижимость WAF, достижимость приложения и выполнение уязвимого пути — также разные наблюдения. Для проверки семантики и эффекта нужны независимые эталоны или инструментированная тестовая цель в разрешённом окружении; менять production ради получения доказательства не требуется.

Метрики должны показывать все попытки, невалидные/неотправленные запросы, неоднозначные ответы, безвредные мутации, дубликаты, находки после triage и отдельно подтверждённые эффекты. Доля в отобранном наборе не является вероятностью взлома на всех попытках или на других конфигурациях. Кандидат на новое правило затем проверяется на легитимном трафике и ложных срабатываниях; модель не получает право сама включить защиту. Предлагаемый контракт приведён в схеме оценок, числовой пример — в кейсе Cloudflare.

5. Как связать это с уже существующим слоем оценок¶

У тебя уже есть:

• офлайн-оценки;
• онлайн-оценки;
• регрессионные шлюзы;
• оценка трасс.

Поведенческие и контрольные оценки не заменяют их. Они добавляют еще один слой:

• офлайн-оценки проверяют качество задачи;
• оценка трасс проверяет качество пути;
• поведенческие оценки проверяют поведение, значимое для политик;
• контрольные оценки проверяют, что сами механизмы контроля действительно работают;
• оценки управления средой исполнения проверяют приостановку, возобновление, фоновые запуски, истечение и повторную инициализацию сессий возможностей, поведение версий контрактов и поведение схем оркестрации под давлением.

Рекомендации OpenAI по оценкам агентов дают полезную операционную лестницу: начинать с трасс, пока команда отлаживает поведение отдельного рабочего процесса, использовать структурированные проверяющие для оценки выбора инструмента, передачи управления, защитного правила и сбоев следования инструкции, а затем переносить стабильные вопросы в наборы данных и повторяемые оценочные запуски для сравнения изменений во времени.¹² Иначе говоря, оценка трасс — это микроскоп, а наборы данных и оценочные запуски — регрессионный каркас. Зрелой агентной программе нужны оба слоя: трассы объясняют, почему провалился один запуск; наборы данных показывают, улучшили ли новая инструкция, политика, правило маршрутизации или поверхность инструментов целый класс запусков, не ослабив механизмы контроля в другом месте.

6. Где такие оценки особенно нужны¶

Эти сценарии особенно полезны для:

• пишущие возможности высокого риска;
• инструменты с исходящим доступом;
• рабочие процессы с большим числом подтверждений;
• переходы управления средой исполнения с приостановкой, возобновлением или фоновым исполнением;
• истечение сессий возможностей и пути повторной инициализации;
• переходы замены и вывода из эксплуатации;
• многоагентное делегирование;
• выбор схемы оркестрации и границы делегированных рабочих агентов;
• управление записью в память и извлечением.

Если рискованный путь вообще не покрыт такими оценками, команда почти наверняка узнает о проблеме уже из инцидента.

Заметка о сквозных сценариях контрольных оценок: оценочный шлюз и контракт проверяющего должен проверять все три канонических сценария как разные поверхности поведенческих и контрольных оценок. Разбор обращений поддержки требует предотвращения дублей, проверки изменения полезной нагрузки, проверки злоупотребления путем подтверждения, пробы старого маршрута шлюза и утверждения аварийного отключения. Внутренний ассистент знаний требует оценки привязки к источникам, пробы обхода клиентского фильтра, проверки недопустимой записи в память, сценария отравления извлечения и регрессионного шлюза свежести. Координация инцидентов требует проверки пути эскалации, пробы подавления уведомлений, сценария злоупотребления ролью реагирующего, проверки подмены состояния инцидента и контрольной оценки отката.

7. Минимальная таксономия поведенческих сценариев¶

Хорошая минимальная таксономия может быть такой:

• oversight_evasion
• payload_mutation_after_approval
• concealment_of_side_effect
• unsafe_alternative_tool_path
• improper_memory_write
• replacement_window_abuse
• unauthorized_persistence
• contract_drift_exploitation
• approval_path_misuse
• session_reinit_misuse
• runtime_control_regression
• delegated_worker_misuse
• orchestration_pattern_drift

Важно не количество названий, а то, что они дают тебе повторяемый набор классов отказов.

Задачи без допустимого решения и противоречивая среда¶

Оценка Anthropic мотивирует отдельные контрольные сценарии: агенту обещают изоляцию, но контролируемые наблюдения ей противоречат; либо задача не имеет решения внутри разрешённой области. Успех здесь — прекратить рискованный путь, сообщить ограничение и запросить уточнение полномочий, а не выполнить цель любой ценой. Обещание «это симуляция» не расширяет заданный scope.

Проводите такие проверки в действительно изолированной среде с синтетическими сервисами и безопасными инструментами-имитациями, не открывая доступ к третьим сторонам ради реализма. Сравнивайте парные задачи с допустимым решением и без него; отдельно меняйте заявленную изоляцию и противоречащие свидетельства. Фиксируйте длительность траектории и накопленное давление неудачных попыток. Экспертный эталон допустимости задаётся до запуска и независимо от ответа модели.

Разделяйте решение агента и работу контроля: запрещённая попытка, остановленная gateway, — успех containment, но не корректная остановка самим агентом. Измеряйте нарушение границ, время до остановки/эскалации и необоснованный отказ на разрешённых задачах. Слова о возможном вреде без изменения последующих действий не считаются успехом. Анализируйте полную траекторию, а не только финальный ответ. Поля — в eval-schema; это предлагаемый эксперимент, не воспроизведение опубликованных процентов Anthropic.

8. Симулятор пользователя и синтетический противник — это разные роли¶

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

Синтетический противник полезен, когда ты намеренно давишь на слабые места:

• двусмысленные инструкции;
• конфликтующие цели;
• рискованные короткие пути;
• попытки скрыть спорный шаг.

На зрелом уровне эти две роли живут рядом:

• симулятор дает реалистичное распределение задач;
• противник дает проверку под давлением.

8.1. Исследования полезны здесь как источник классов сценариев¶

Свежие работы по поведенческому риску и автоматизированному соревновательному тестированию полезны не только выводами, но и словарем.

Они помогают команде расширять набор классов сценариев, который редко рождается полностью из локального опыта. Именно оттуда удобно брать идеи для таких классов, как:

• concealment;
• oversight evasion;
• sabotage-like persistence;
• coordination breakdown under pressure;
• эксплуатация несовпадения схемы или дрейфа контроля;
• злоупотребление прерыванием или окнами повторной инициализации;
• злоупотребление путями делегированных рабочих агентов или дрейфом их границ.

Но инженерная дисциплина здесь должна оставаться жесткой:

• класс сценария должен быть отражен в проверяемой схеме оценки;
• находка должна получать владельца и путь разбора;
• шлюз поэтапного выпуска должен видеть операционные доказательства, а не просто ссылку на публикацию.

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

9. Пример политики для контрольных оценок¶

control_evals:
  required_for:
    - ticket_write
    - outbound_messaging
    - credential_rotation
  scenario_classes:
    - oversight_evasion
    - payload_mutation_after_approval
    - concealment_of_side_effect
    - approval_path_misuse
    - session_reinit_misuse
    - contract_drift_exploitation
    - runtime_control_regression
    - delegated_worker_misuse
    - orchestration_pattern_drift
  block_release_if:
    - control_eval_missing
    - behavioral_eval_regression
    - runtime_control_regression_open
    - verifier_contract_regression_open
    - red_team_findings_untriaged

Такой слой полезен тем, что делает поведенческие проверки частью дисциплины выпуска, а не “дополнительной хорошей практикой”.

10. Пример простого контракта оценивания¶

from dataclasses import dataclass


@dataclass
class ControlEvalResult:
    scenario_class: str
    control_enforced: bool
    side_effect_traced: bool
    finding_open: bool
    contract_version_matched: bool
    session_control_enforced: bool


def passes_control_eval(result: ControlEvalResult) -> bool:
    return (
        result.control_enforced
        and result.side_effect_traced
        and result.contract_version_matched
        and result.session_control_enforced
        and not result.finding_open
    )

Здесь отказ считается не только “модель повела себя странно”, но и “слой контроля не доказал свою работоспособность”.

Контракт оценивания становится сильнее, если умеет хранить не только вердикт прошло/не прошло, но и отдельные суждения о процессе и результате, плюс атрибуцию отказа для управляемых и неуправляемых причин.

11. Как встроить это в ADLC¶

В зрелой системе это обычно устроено так:

1. рискованное изменение получает change_record;
2. для него определяется обязательная область оценки;
3. регрессионные оценки проверяют старое поведение;
4. поведенческие и контрольные оценки проверяют рискованные пути;
5. автоматизированное соревновательное тестирование ищет менее очевидные режимы отказа;
6. находки попадают в список работ контура заверения;
7. шлюз поэтапного выпуска видит не только точность, но и доказательства работы контроля.

Так слой оценок перестает быть “таблицей метрик” и становится частью операционной модели.

Именно поэтому эту главу лучше читать как слой тестирования и суждения. Заверение решает, как отвечать на находки. Наблюдаемость сохраняет доказательства. Реестр распределяет подотчетность по всему контуру. Оценки решают, что именно было протестировано, что сломалось и насколько вообще можно доверять текущему состоянию контроля.

12. Самые частые ошибки¶

• все оценки сводятся к качеству финального ответа;
• опасные пути не имеют отдельных классов сценариев;
• злоупотребление путем подтверждения, повторной инициализацией сессии, делегированными рабочими агентами и дрейфом контракта не проверяется явно;
• выходы проверяющего схлопывают длинные траектории в слабую метку прошло/не прошло;
• замены контракта проверяющего меняют поведение оценки, но не считаются регрессиями оценки, несущими риск выпуска;
• управляемые и неуправляемые отказы не разделяются;
• соревновательное тестирование проводится как разовая акция;
• регрессии управления средой исполнения обнаруживаются только в поэтапном выпуске или инцидентах;
• находки не связываются со шлюзом выпуска;
• отказы управления считаются “не багом модели”, а потому не попадают в список работ;
• команда не умеет отличать обычный отказ от поведения, похожего на саботаж.

13. Быстрый тест зрелости для поведенческих и контрольных оценок¶

Команде не стоит думать, что она уже готова к автономному поведению, только потому, что у нее есть регрессионные оценки, симулятор и несколько противоборствующих инструкций.

Более сильная планка такая:

• у рискованных путей есть явные классы поведенческих сценариев;
• контрольные оценки проверяют, что сам слой контроля работает под давлением;
• выходы проверяющего разделяют качество процесса, качество результата и атрибуцию отказа, а не схлопывают все в одно бинарное суждение;
• злоупотребление путем подтверждения, повторной инициализацией сессии, делегированными рабочими агентами, дрейфом контракта и регрессиями управления средой исполнения имеет явное покрытие сценариями;
• находки соревновательного тестирования попадают в шлюзы поэтапного выпуска и изменения, а не живут отдельными отчетами;
• реалистичная симуляция и противоборствующая генерация играют разные, дополняющие роли;
• решения о выпуске умеют опираться на доказательства работы контроля, а не только на оценки качества.

Если большинство этих условий не выполняется, у команды уже может быть оценочная активность, но достаточного поведенческого и контрольного покрытия у нее пока нет.

В этот момент команда уже может что-то измерять, но еще не производит тот тип проверяемых суждений, на который поэтапный выпуск, заверение и управленческие функции могут надежно опираться.

14. Практический чеклист¶

• Есть ли у рискованных возможностей отдельные классы поведенческих сценариев?
• Проверяешь ли ты обход подтверждения, изменение полезной нагрузки, злоупотребление путем подтверждения и злоупотребление делегированными рабочими агентами?
• Есть ли оценки, которые проверяют именно механизмы контроля, совпадение версий контрактов, поведение управления средой исполнения, границы схем оркестрации и качество проверяющего, а не только качество результата?
• Умеет ли проверяющий различать отказ процесса, отказ результата и неуправляемый отказ среды?
• Попадают ли находки соревновательного тестирования в проверку изменений и шлюз поэтапного выпуска?
• Есть ли симулятор для реалистичной нагрузки и отдельный противоборствующий генератор?
• Можешь ли ты показать доказательства работы контроля, а не только итоговую оценку качества?

Если на несколько вопросов подряд ответ “нет”, то твой слой оценок уже есть, но он еще не готов к автономному поведению.

15. Модель доказательности этой главы¶

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

• Устойчивые утверждения: автономным системам нужны оценки для рискованных траекторий, а не только для финальных ответов.
• Вендорская практика: современные материалы по оценкам агентов всё чаще рассматривают трассы, траектории и шлюзы поэтапного выпуска как первичные входы для оценки.
• Практика среды исполнения: классы сценариев, контракты проверяющих, отказы с опорой на трассы и шлюзы поэтапного выпуска — конкретные способы сделать поведенческие и контрольные доказательства проверяемыми.
• Авторская интерпретация: поведенческие оценки, контрольные оценки и автоматизированное соревновательное тестирование — разные роли в одной системе суждения, а не взаимозаменяемые ярлыки.
• Быстро меняющаяся область: качество симуляторов, моделей-судей и соревновательной генерации будет быстро меняться; потребность разделять отказ процесса, отказ результата и отказ контроля — нет.

16. Полезные справочные страницы¶

• Схема наборов для оценки и правил проверки
• Схема трасс и каталог событий
• Схема проверки изменений и шлюза раскатки
• Схема набора политик и контракта подтверждения
• Схема approval
• Схема артефактов жизненного цикла
• Схема памяти и извлечения

• Исследовательский фронтир: память, наблюдаемость и надежность многоагентных систем

• Глава 13. Офлайн-оценки, онлайн-оценки и регрессионные шлюзы

• Глава 21. Контур заверения: соревновательное тестирование, обнаружение и реагирование
• Глава 24. Агентное несоответствие целей и инсайдерский риск
• Глава 26. Наблюдаемость для ИИ-систем, покрытие реестра и телеметрия для обнаружения проблем
• Глава 27. Инвентаризация агентов, реестр и борьба с разрастанием