Как измеряют безопасность в reinforcement learning: что не так с бенчмарками

Классическая задача RL звучит просто: максимизируй награду. Safe RL добавляет второе условие — не превышай бюджет нарушений. Робот не должен врезаться в стену, торговый агент — сливать позицию, дрон — падать во время обучения. Проблема в том, что стоит поменять бенчмарк, и рейтинг алгоритмов переворачивается. CPO выигрывает у PPO-Lagrangian на одном наборе задач и проигрывает на другом. Это не шум — это следствие того, как устроены сами бенчмарки.

Что вообще меряют в safe RL

Формально safe RL описывают через CMDP — Constrained Markov Decision Process^*. У агента есть награда r(s,a) и стоимость c(s,a). Задача — максимизировать ожидаемую сумму наград при условии, что ожидаемая сумма стоимостей не превышает порога d.

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

Три метрики, которые обычно смешивают

• Return — средняя награда за эпизод после обучения. Показывает, насколько агент вообще научился задаче.
• Cost — среднее число нарушений за эпизод после обучения. Показывает, соблюдает ли агент ограничения на этапе эксплуатации.
• Training-time violations — сколько раз агент нарушил правила в процессе обучения. Именно эта метрика ближе всего к реальной безопасности, и именно её чаще всего игнорируют.

Агент, который в тренировке снёс 200 000 препятствий, а потом научился их обходить, по первым двум метрикам выглядит идеально. В реальном мире такой агент — это 200 000 разбитых прототипов.

Основные бенчмарки и что они на самом деле проверяют

Обратите внимание: почти нигде training-time cost не является основной метрикой. Это следствие истории — Safety Gym изначально задумывался как proof-of-concept, а не как индустриальный стандарт. Индустрия его подхватила, и теперь папку с cost-during-training приходится собирать вручную.

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

Почему рейтинги алгоритмов не воспроизводятся

В 2023 году команда OmniSafe опубликовала прогон 16 алгоритмов safe RL на едином стенде. Результат: разброс по итоговому cost между независимыми запусками одного алгоритма с разными сидами доходил до порядка величины. То есть один и тот же PPO-Lagrangian на одной и той же задаче в одном запуске укладывается в бюджет, в другом — превышает его втрое.

Причины известные, но от этого не менее болезненные:

1. Мало сидов. В статьях по safe RL типично 3–5 seeds. Для распределения с тяжёлым хвостом этого не хватает даже на грубую оценку среднего.
2. Разные гиперпараметры лагранжева множителя. Скорость его обновления решает всё: слишком медленно — агент нарушает годами, слишком быстро — коллапсирует в бездействие.
3. Разные пороги d. Один автор ставит d=25, другой d=10. Сравнивать их напрямую нельзя, а в таблицах сравнивают.
4. Разные версии MuJoCo. Физика между 2.1 и 3.x отличается достаточно, чтобы менять поведение агента на границе.

Что делать инженеру, который выбирает алгоритм

Если вам нужно выкатить safe RL в проде — на реальном железе, в трейдинге, в рекомендациях — не берите цифры из paperswithcode на веру. Прогоните минимальный собственный протокол:

• Зафиксируйте одну версию симулятора и одну версию библиотеки алгоритмов. Не смешивайте реализации из разных репозиториев.
• Прогоните минимум 10 сидов, отчитывайтесь медианой и межквартильным размахом, а не средним ± std.
• Логируйте cost на каждом шаге обучения, а не только в eval. Стройте кумулятивный график нарушений.
• Проверяйте поведение при сдвиге распределения: добавьте шум в наблюдения, поменяйте массу робота на 10–20%. Многие safe-агенты идеальны в лаборатории и разваливаются при малейшем сдвиге.
• Считайте worst-case cost по эпизодам, а не только средний. Безопасность — это про хвост распределения.

Минимальный скелет прогона

import omnisafe

env_id = 'SafetyPointGoal1-v0'
custom_cfgs = {
    'train_cfgs': {'total_steps': 1_000_000},
    'algo_cfgs': {'cost_limit': 25.0},
    'logger_cfgs': {'use_wandb': False, 'save_model_freq': 50_000},
    'seed': 0,
}

for seed in range(10):
    custom_cfgs['seed'] = seed
    agent = omnisafe.Agent('PPOLag', env_id, custom_cfgs=custom_cfgs)
    agent.learn()
    # логируйте episode_cost на каждом rollout, а не только eval_cost

Этот код не решит проблему сам по себе, но он даёт честную точку отсчёта: 10 сидов, зафиксированный лимит, один алгоритм. Дальше можно менять по одной переменной за раз и смотреть, что реально влияет на итог.

Куда движется область

В 2024–2025 всё чаще появляются бенчмарки, где нарушения в тренировке считаются частью цены: Real-World RL Suite от DeepMind, отдельные задачи в OmniSafe с явной метрикой regret по стоимости. Параллельно растёт интерес к offline safe RL — там нарушения физически невозможны на этапе обучения, потому что данные фиксированы, но появляется новая проблема — экстраполяция за пределы датасета.

Пока индустриального консенсуса нет. Если завтра вам продают safe RL под ключ, первое, что спросите — не итоговый return, а кумулятивный cost за всё обучение и разброс по десяти сидам. Если продавец не готов такое показать, значит, он не измерял то, что вам нужно.