Спецификационные игры — это поведение, которое буквально удовлетворяет спецификации цели, но не достигает намеченного результата.
У всех нас есть опыт игры в спецификациях, даже если и не под этим именем.
Читатели, возможно, слышали миф о царе Мидасе и золотом прикосновении, в котором царь просит, чтобы все, к чему он прикасается, превращалось в золото, но вскоре обнаруживает, что даже еда и напитки в его руках превращаются в металл.
В реальной жизни, когда ученика награждают за хорошее выполнение домашнего задания, он может копировать другого ученика, чтобы получить правильные ответы, вместо того, чтобы изучать материал, используя таким образом лазейку в спецификации задания.
Эта проблема также возникает при создании искусственных агентов.
Например, агент обучения с подкреплением может найти кратчайший путь для получения большого количества вознаграждения, не выполняя задачу, задуманную разработчиком человека.
Такое поведение распространено, и сегодня мы собранный около 60 примеров (объединяя существующий списки и текущий вклад от AI-сообщества).
В этом посте мы рассмотрим возможные причины проблем со спецификациями, поделимся примерами того, где это происходит на практике, и приведем аргументы в пользу необходимости дальнейшей работы над принципиальными подходами к преодолению проблем со спецификациями.
Давайте посмотрим на пример.
По заданию постройка из кубиков Лего желаемый результат заключался в том, чтобы красный блок оказался поверх синего блока.
Агент получал вознаграждение за высоту нижней поверхности красного блока, когда он не касался блока.
Вместо того, чтобы выполнить относительно сложный маневр — взять красный блок и положить его поверх синего, агент просто перевернул красный блок, чтобы получить награду.
Такое поведение достигло цели (нижняя поверхность красного блока была высокой) за счет того, что действительно заботило дизайнера (построение поверх синего блока).
Глубокое обучение с подкреплением для ловких манипуляций, основанное на эффективном использовании данных.
Мы можем посмотреть на спецификацию игры с двух точек зрения.
Целью разработки алгоритмов обучения с подкреплением (RL) является создание агентов, которые учатся достигать заданной цели.
Например, когда мы используем игры Atari в качестве эталона для обучения алгоритмов RL, цель состоит в том, чтобы оценить, способны ли наши алгоритмы решать сложные проблемы.
Решит ли агент проблему с помощью лазейки или нет, в данном контексте не важно.
С этой точки зрения игра по спецификации — хороший знак: агент нашел новый способ достижения своей цели.
Такое поведение демонстрирует изобретательность и способность алгоритмов находить способы делать именно то, что мы им говорим.
Однако, когда мы хотим, чтобы агент действительно соединял блоки Lego, та же самая изобретательность может создать проблему.
В более широком контексте строительства целевые агенты которые достигают желаемого результата в мире, игра со спецификациями проблематична, поскольку она предполагает, что агент использует лазейку в спецификации в ущерб желаемому результату.
Такое поведение вызвано неправильной постановкой задачи, а не каким-либо недостатком RL-алгоритма.
Помимо разработки алгоритма, еще одним необходимым компонентом создания целевых агентов является разработка вознаграждения.
Разработка спецификаций задач (функций вознаграждения, среды и т. д.), которые точно отражают намерения человека-проектировщика, обычно бывает сложной.
Даже при небольшом недопонимании очень хороший алгоритм RL может найти сложное решение, сильно отличающееся от задуманного; даже если более слабый алгоритм не сможет найти это решение и, таким образом, получить решение, более близкое к желаемому результату.
Это означает, что правильное определение желаемого результата может стать более важным для его достижения по мере совершенствования алгоритмов RL. Поэтому важно, чтобы способность исследователей правильно определять проблемы не отставала от способности агентов находить новые решения.
Мы широко используем термин «спецификация задачи», чтобы охватить многие аспекты процесса разработки агента.
В постановке RL спецификация задачи включает не только дизайн вознаграждения, но также выбор среды обучения и поддерживающих вознаграждений.
Правильность определения проблемы может определить, соответствует ли изобретательность агента намеченному результату или нет. Если спецификация верна, творческий подход агента приводит к желаемому новому решению.
Именно это позволило AlphaGo сделать знаменитую 37 ход , что застало врасплох специалистов по Го, но сыграло ключевую роль во втором матче с Ли Седолем.
Если спецификация неверна, это может привести к нежелательному поведению игры, например к переворачиванию блоков.
Такие решения возможны, и у нас нет объективной возможности их заметить.
Теперь рассмотрим возможные причины игры по спецификации.
Одним из источников неправильной спецификации функции вознаграждения является плохо продуманная структура вознаграждения.
Формулирование вознаграждения облегчает изучение некоторых целей, давая агенту некоторое вознаграждение на пути к выполнению задачи, а не вознаграждая только конечный результат. Однако структура вознаграждений может изменить оптимальную политику, если они не на основе перспективы .
Представьте себе агента, управляющего лодкой в игре.
Береговые бегуны , где намеченная цель — как можно быстрее закончить гонку.
Агент получил формирующую награду за столкновение с зелеными блоками на гоночной трассе, что изменило оптимальную политику на хождение по кругу и столкновение с одними и теми же зелеными блоками снова и снова.
Неверные функции вознаграждения в действии.
Определение вознаграждения, которое точно отражает желаемый конечный результат, само по себе может оказаться непростой задачей.
В задаче соединения блоков Лего недостаточно указать, что нижний край красного блока должен находиться высоко от пола, так как для достижения этой цели агент может просто перевернуть красный блок.
Более полная спецификация желаемого результата также включала бы то, что верхний край красного блока должен быть выше нижнего края и что нижний край должен быть совмещен с верхним краем синего блока.
При определении результата легко упустить один из этих критериев, что сделает спецификацию слишком широкой, и ее потенциально будет легче удовлетворить с помощью вырожденного решения.
Вместо того, чтобы пытаться создать спецификацию, охватывающую все возможные случаи, мы могли бы изучите функцию вознаграждения на основе отзывов людей .
Зачастую легче оценить, был ли достигнут результат, чем заявить об этом прямо.
Однако этот подход также может столкнуться с проблемами спецификации игры, если модель вознаграждения не изучает истинную функцию вознаграждения, отражающую предпочтения дизайнера.
Одним из возможных источников неточностей может быть обратная связь между людьми, используемая для изучения модели вознаграждения.
Например, агент, работающий задача захвата научился обманывать оценивающего, зависая между камерой и объектом.
Усиление глубокого обучения на основе предпочтений человека.
Обученная модель вознаграждения также может быть неправильно определена по другим причинам, например, из-за плохого обобщения.
Дополнительная обратная связь может использоваться для исправления попыток агента использовать неточности в модели вознаграждения.
Другой класс игр согласно спецификации создан агентом, который использует ошибки в симуляторе.
Например, симулированный робот , которому предстояло научиться ходить, пришла в голову идея сцепить ноги вместе и скользить по земле.
ИИ учится ходить.
На первый взгляд такие примеры могут показаться забавными, но они менее интересны и не имеют никакого отношения к развертыванию агентов в реальном мире, где нет ошибок симулятора.
Однако основная проблема заключается не в самой ошибке, а в несостоятельности абстракции, которой может воспользоваться агент. В приведенном выше примере задача робота была определена неверно из-за неверных предположений о физике симулятора.
Аналогичным образом, реальная проблема оптимизации трафика может быть неправильно определена, если предположить, что инфраструктура маршрутизации трафика не содержит ошибок программного обеспечения или уязвимостей безопасности, которые мог бы обнаружить достаточно интеллектуальный агент. Такие предположения не обязательно делать явно; скорее, это детали, которые просто никогда не приходили в голову дизайнеру.
А поскольку проблемы становятся слишком сложными, чтобы учесть каждую деталь, исследователи с большей вероятностью будут делать неправильные предположения при разработке спецификации.
Возникает вопрос: возможно ли разработать архитектуру агентов, которая исправляет такие ложные предположения, а не эксплуатирует их? Одно из допущений, которое обычно делается в спецификации задачи, заключается в том, что на спецификацию не могут повлиять действия агента.
Это верно для агента, действующего в изолированной симуляции, но не для агента, действующего в реальном мире.
Любая спецификация задачи имеет физическое проявление: функцию вознаграждения, хранящуюся в компьютере, или предпочтения человека.
Агент, развернутый в реальном мире, потенциально может манипулировать этими представлениями цели, создавая проблему.
Для нашей гипотетической системы оптимизации трафика нет четкого различия между удовлетворением предпочтений пользователя (например, предоставлением полезных указаний) и влияние на пользователей чтобы у них были предпочтения, которые легче удовлетворить (например, заставляя их выбирать места назначения, до которых легче добраться).
Первый удовлетворяет задаче, а второй манипулирует представлением цели в мире (предпочтениями пользователя), и оба приводят к высоким вознаграждениям для системы ИИ.
Другой, более крайний пример: очень продвинутая система искусственного интеллекта может захватить контроль над компьютером, на котором она работает, установив для себя высокое значение вознаграждения.
Подводя итог, есть как минимум три проблемы, которые необходимо преодолеть при решении задачи игры по спецификации:
- Как нам точно отразить человеческое представление о данной задаче в функции вознаграждения?
- Как мы можем избежать ошибок в наших неявных предположениях о предметной области или спроектировать агентов, которые исправляют ошибочные предположения, а не играют с ними?
- Как мы можем избежать мошенничества с вознаграждениями?
Список возможного поведения согласно спецификации демонстрирует масштаб проблемы и количество способов, которыми агент может действовать в рамках спецификации.
Эти проблемы, вероятно, станут более сложными в будущем, поскольку системы искусственного интеллекта станут более способными удовлетворять спецификациям задач за счет желаемого результата.
По мере создания более совершенных агентов нам потребуются принципы проектирования, которые конкретно решают проблемы спецификации и гарантируют, что эти агенты надежно достигают результатов, запланированных разработчиками.
Если вы хотите узнать больше о машинном и глубоком обучении, загляните на наш соответствующий курс, это будет непросто, но увлекательно.
И промокод ХАБР — поможет вам в вашем стремлении познавать новое, добавив 10% к скидке на баннер.
- Курс машинного обучения
- Продвинутый курс «Машинное обучение Pro + Deep Learning»
- Профессиональная подготовка в области науки о данных
- Обучение аналитика данных
- Профессия Java-разработчик
- Профессия Frontend-разработчик
- Профессия: технический хакер
- Профессия C++-разработчик
- Профессия Разработчик игр на Unity
- Профессия iOS-разработчик с нуля
- Профессия Android-разработчик с нуля
- Профессия Веб-разработчик
КУРСЫ
- Курс «Python для веб-разработки»
- Курс JavaScript
- Курс «Математика и машинное обучение для науки о данных»
- Курс анализа данных
- Курс DevOps
-
Обзор Sony Vaio Vgn Series Cs31St/P
19 Oct, 24 -
Все Об Asus Eeepc
19 Oct, 24 -
Домен Inferno - Поиск Свободных Доменов
19 Oct, 24 -
Великий Русский Фаервол
19 Oct, 24 -
Тёма Ответил На Вопросы Читателей «Ленты.ру»
19 Oct, 24
