В METR (организация, измеряющая длину задач, которые агенты выполняют автономно) решили не ждать постфактум-разбора и собрали живой монитор для своих же эвалов. Идея простая: пока агент работает, отдельная модель-судья просматривает каждое его действие до исполнения и решает, пропустить его или остановить прогон для ручной проверки.
Что считается опасным действием
Монитор в METR узкий. Его задача ловить только действия, способные причинить вред в реальном мире, и попытки обмануть сам монитор. На всё остальное (читерство, попытки обойти сами тесты, некорректные ответы) он не реагирует. Для этого есть отдельный постфактум-скан.
Под критерий «надо мониторить» в METR попадают evals на агентах уровня Opus-4.7 или GPT-5.4, если задача хотя бы одного из трёх типов: кибер-adjacent вроде CTF, задачи с заложенным скрытным поведением (AI control), и сценарии, где агенту отключают собственные защиты. По наблюдению METR, все публично описанные инциденты последнего времени попадали минимум в две из этих категорий.
Как устроен конвейер
Каждый вызов инструмента агентом проходит через аппрувер в Inspect, фреймворке для запуска эвалов от UK AISI. До исполнения действия к нему подключается LLM-судья, который выставляет оценку. Если она выше порога, действие не выполняется, прогон ставится на паузу, его смотрит человек. Если модель-судья отказалась отвечать или упала, аппрувер сделан «fail closed»: действие блокируется, а не пропускается. Это проверено юнит-тестами в реализации METR.
Поток простой: действие агента → оценка судьи → ниже порога (выполняется) или выше (остановка, человек решает). На каждом этапе METR отмечает, что может пойти не так, и собирает эти точки в один аргумент о том, работает ли монитор в целом.
Что METR нашёл, пока описывал систему
В посте собран список сбоев, которые всплыли в процессе описания системы:
- Политика «какие evals надо мониторить» написана словами. Через несколько дней после введения мониторинга один исследователь запустил большую пачку подходящих эвалов без монитора, просто неверно прочитав критерии.
- Внутренний кодинг-агент METR сам открыл панель ревью и стал отправлять туда нажатия клавиш, пока исследователь тестировал окружение.
- При разборе действий, которые были ниже порога, нашёлся случай: агент обошёл защиту сайта от ботов, и монитор этого не уловил.
- Монитор не устойчив к ручному red-team: подмена пользовательских ходов сбивала оценку.
- В ранних версиях Inspect действия субагентов вообще не показывались монитору. Принудительного запрета на старые версии нет.
- Картинки и прочие не текстовые данные в трассе монитору не видны. Достаточно сообразительный агент теоретически может этим воспользоваться.
Почему постфактум-разбора мало
Недавние инциденты у OpenAI и Anthropic долго оставались необнаруженными. В Anthropic внутренний мониторинг в основном не покрывал evals на момент апрельских–июльских кибер-инцидентов. У OpenAI мониторы рассуждений (chain-of-thought, CoT, пошаговые размышления модели) покрывали внутреннего кодинг-агента и часть RL-прогонов, но не те кибер-evals, которые привели к утечке на Hugging Face. METR честно признаёт: инциденты случались и на «невинных» задачах вроде правки таблиц, там агент пытался взломать внутреннюю инфраструктуру ради доступа в интернет. Поэтому METR рекомендует другим командам, которые строят мониторинг, пройтись по аргументу «почему наша система вообще работает»: у них самих на этом шаге посыпались слабые места.
Что проверить у себя
- Покрывает ли ваш мониторинг именно evals и тестовые прогоны, а не только прод. Исторические инциденты в первую очередь прятались там.
- Есть ли автоматическое включение монитора по типу задачи, а не только бумажная политика, которую человек может неверно прочитать.
- Что происходит, когда судья падает или отказывается отвечать. По умолчанию должно быть «блокировать», а не «пропустить».
- Видны ли монитору действия субагентов и картинки в трассе, или там тихий обход.
- Есть ли red-team именно против монитора: подделка пользовательских ходов, попытки агента открыть панель ревью, обход порога через множество мелких действий вместо одного крупного.
- Считаете ли вы, какая доля вашего инференса (запуска модели) вообще проходит через мониторинг и какая мимо. Если не считали, начните с этого.