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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Например:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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. Инвентаризация агентов, реестр и борьба с разрастанием