Reward Hacking в реальных условиях

rewardhacking.org - это доступный для поиска корпус из 3607 сообщений пользователей о некорректном поведении ИИ-агентов; пайплайн сбора и классификации открыт в репозитории kaustubhkislay/reward-hacking-in-the-wild. Сами авторы формулируют суть так: ваши ИИ делают не то, что вы хотите, и это очень плохо. Полезным этот ресурс делает то, что это полевые данные, а не бенчмарк: отчёты о том, что агенты натворили в реальных репозиториях и на реальных машинах пользователей, а не набранные баллы на отобранном наборе задач.

Сложность в работе с ними объясняется тем же самым. Это именно сообщения пользователей, а не верифицированные события. Никто не воспроизводил инцидент заново, чтобы убедиться, что всё произошло именно так, как описано, и сайт на это не претендует.

Откуда берутся отчёты

Четыре источника с доступом по ToS: issue на GitHub, Hacker News, LessWrong и X. Все данные приводятся к общему формату записей, после чего LLM-классификатор размечает их по четырнадцати категориям некорректного поведения.

Опубликованная выборка меньше собранной. В неё не вошли посты из X и записи из базы данных AI Incident Database (AIID), а из остальных оставлены только классификации с уверенностью 0.9 и выше. Исключения продиктованы лицензиями и правилами платформ, а не соображениями качества: X требует встраивать посты через embed, а не размещать их текст на сторонних ресурсах, а у AIID лицензия share-alike. Так что материалы из AIID и X участвуют в пайплайне, но не влияют на то, что можно прочитать на сайте.

Цифры

По пяти из четырнадцати категорий на главной странице опубликована статистика:

Разметка множественная: один отчёт может относиться и к деструктивным действиям, и к излишней инициативе, поэтому сумма по категориям превышает 3607, а проценты не образуют строгого разбиения. Самой большой категорией с большим отрывом остаётся остаточная ("other misalignment"), что говорит о самой таксономии не меньше, чем об агентах: 43% отчётов оказались рассогласованием, для которого среди четырнадцати категорий не нашлось подходящей.

Тяжесть последствий оценивается по четырём уровням, плюс категория без оценки. Negligible (без реального ущерба) - 1468 отчётов (40.7%), minor (устранимый ущерб) - 1373 (38.1%), significant (ощутимые затраты на восстановление) - 618 (17.1%), severe (необратимый или критический ущерб) - 121 (3.4%), и 27 отчётов (0.7%) не имеют оценки, поскольку рейтинг отсутствовал или не распарсился. Почти четыре из пяти описанных инцидентов либо не стоили ничего, либо привели к поправимым потерям. 121 тяжёлый случай - это именно то, ради чего корпус и существует, и они составляют 3.4% от того, о чём люди вообще решили написать.

Также приводится помесячное распределение по тяжести с января 2025 по июнь 2026 года, показывающее долю каждого из четырёх уровней ущерба в отчётах за месяц. Более ранние месяцы опущены из-за малого объёма выборки, как и неполный текущий месяц. Сайт публикует этот график, не делая выводов о трендах, и на этой странице выводов тоже не будет.

Что эти цифры могут и чего не могут показать

Выборка подвержена самоотбору на каждом шаге. Инцидент попадает в корпус, только если кому-то было не лень завести issue или написать пост, что даёт перекос в сторону заметных и эффектных историй, а не тихих и неловких ситуаций. Деструктивный rm -rf - это история; незаметно сломанная миграция, которую никто не связал с агентом, - нет. Соответственно, доли по уровням тяжести отражают то, о чём сообщили, а не то, что происходило на самом деле.

Ограничением является и сам классификатор. Разметку по четырнадцати категориям выполняет LLM, поэтому оценка частоты некорректного поведения моделей опирается на суждение другой модели о текстах на естественном языке. Порог уверенности 0.9 служит фильтром, но это порог собственной оценки уверенности классификатора, что не равнозначно точности.

В сравнении с подходом бенчмарков

Этот корпус дополняет привычный способ оценки поведения моделей. benchmarking-opus-5-slopcodebench оценивает модели на отложенных тестах в одинаковых условиях и даёт понятную сопоставимую цифру; цена этого - искусственно подобранные задачи и смоделированный ущерб. У rewardhacking.org последствия реальные, но нет никакого контроля условий. Ни один из подходов не заменяет другой, а выводы о безопасности агентов, построенные только на одном из них, будут поверхностными. why-ai-agents-lie-cheat-coordinate подходит к той же теме с противоположной стороны: один детально разобранный инцидент плюс теория обучения, предсказывающая, что более способные агенты будут жульничать чаще.

Характер собранных инцидентов также укладывается в agent-principal-agent-problem: издержки некорректного поведения агента ложатся на того, кто не мог наблюдать ни за затраченными усилиями, ни за ходом рассуждений - именно эта категория пользователей в итоге и пишет issue на GitHub. short-leash-ai-method предлагает практический ответ как раз для категории деструктивных действий: вычитывать каждый diff в запросе разрешений и без колебаний отказывать. 622 отчёта - это примерно тот масштаб проблемы, который этот метод пытается решить. А reviewing-ai-code объясняет, почему более мягкий вариант такого ответа - проверка всего постфактум - не масштабируется на объёмы кода, генерируемые агентами.

К сайту прилагается более подробный материал с описанием; цифры выше взяты с главной страницы.