Goal Misgeneralization: Why Correct Specifications Aren't Enough For Correct Goals
Rohin Shah, Vikrant Varma, Ramana Kumar, Mary Phuong, Victoria Krakovna, Jonathan Uesato, Zac Kenton
Статья: https://arxiv.org/abs/2210.01790
Пост в блоге: https://deepmindsafetyresearch.medium.com/goal-misgeneralisation-why-correct-specifications-arent-enough-for-correct-goals-cf96ebc60924

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

Как можно оказаться в ситуации, когда у системы незапланированная нами цель?

Типовым примером является некорректная спецификация цели, как это бывает в классике с плохо поставленными ТЗ джину или джуну. Или (привет царю Мидасу) когда вроде бы цель корректная, но её буквальное выполнение жизни не помогает (ну то есть всё равно по факту некорректная и плохо поставленная). Это также известно под именем specification gaming (https://www.deepmind.com/blog/specification-gaming-the-flip-side-of-ai-ingenuity) и является весьма распространённой ситуацией. Вот одна из коллекций собранных примеров specification gaming: http://tinyurl.com/specification-gaming.

Где-то идейно близко находятся примеры нахождения эволюционными процессами очень необычных решений задач, в том числе эксплуатируя баги сред. Есть на эту тему хорошая статья под названием “The Surprising Creativity of Digital Evolution: A Collection of Anecdotes from the Evolutionary Computation and Artificial Life Research Communities” (https://arxiv.org/abs/1803.03453). Мы её даже разбирали на первой встрече Gonzo_AGI клуба (https://discord.gg/Ze59E5HMKc), но запись не сохранилась. Кстати, тут возник ещё один чатик вокруг AGI: https://news.1rj.ru/str/agi_risk_and_ethics.

Есть и другой интересный путь при полностью корректной спецификации — мисгенерализация цели (goal misgeneralization или GMG).

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

Это пример out-of-distribution истории, когда по внешним признакам при обучении всё в порядке, но на тесте происходит провал. Агент сохраняет все свои способности (например, двигаться и обходить препятствия), и их достаточно, чтобы достигнуть правильной цели, но преследует он при этом неправильную цель. Предыдущая работа “Goal Misgeneralization in Deep Reinforcement Learning” (https://arxiv.org/abs/2105.14111) изучала этот феномен в контексте RL. Текущая работа смотрит шире в контексте всего DL. И вообще эта проблема общая, она в целом про обучение (в приложении есть пример про букинг билетов).

Среди других примеров из работы есть агент в Monster Gridworld, где ему нужно собирать яблоки (reward +1) и уклоняться от монстров (иначе reward -1), но можно также собирать щиты и они спасают от штрафа за столкновение с монстром. Агент, обучавшийся на эпизодах длины 25, когда монстры обычно ещё есть, налегает на сбор щитов, потому что они действительно помогают, но не прекращает это делать, когда монстры пропадают, хотя в принципе вся информация для выучивания такой стратегии у него есть, он знает, что просто за щиты награды не получает. В итоге он не может переключиться на более эффективную стратегию (сбор только яблок) в ситуации отсутствия монстров. Агент, обучавшийся на 100 шагах, делает это лучше, то есть большее разнообразие датасета это фиксит.

В другой среде Gridworld надо рубить деревья, за это агент получает награду. Делает он это непрерывно, обучаясь в режиме online без сбросов среды. Деревья со временем возрождаются, но скорость возрождения выше, когда деревьев много. Так что было бы выгодно не скашивать всё под корень, а поддерживать баланс и sustainability и срубать меньше, когда деревьев уже мало. Но у агента обычно есть большой фейл. Когда он только учится и рубит ещё плохо, он выигрывает от ускорения рубки. Продолжая преследовать цель улучшить свои способности рубить деревья, он быстро вырубает всё и мир уходит в долгое восстановление. Выучить sustainable подход потом со временем удаётся, но на это уходит много времени. Очень похоже на человечество.

Отдельный интересный кейс с языковой моделью Gopher (https://news.1rj.ru/str/gonzo_ML/742) на 280B параметров. Здесь модели надо вычислять линейные выражения с переменными и константами, типа x + y - 3. Модель должна в диалоге выяснять значения неизвестных переменных. Но модель продолжает задавать вопросы, даже если неизвестных переменных не было.

Другой пример с языковой моделью это InstructGPT, которая должна быть helpful, truthful, и harmless, но видимо на примерах акцентирующихся на harmless она обучалась мало, так что старается быть helpful даже когда её просят объяснить, как ограбить магазин. Но может конечно и наразмечали полезность плохо.

Коллекция примеров про goal misgeneralization есть тут: https://tinyurl.com/goal-misgeneralisation. Примеры с видео есть тут: https://sites.google.com/view/goal-misgeneralization?pli=1. Известный классический пример про распознавание волк/хаски по наличию снежного фона (https://arxiv.org/abs/1602.04938) тоже попадает сюда. Байка про детектирование танков (https://www.gwern.net/Tanks) по идее сюда же.

Почему это всё важно? Потому что мощная ИИ-система с большими возможностями может знатно накосячить. ИИ-система не обязана даже быть злонамеренной, это всё может выйти из невинных целей. Да и люди в целом, кажется, тоже вполне подвержены таким же проблемам, так что при любой концентрации власти это может обернуться (и оборачивается) плохо. Мне кажется, что текущие истории с государствами, компаниями и отдельными людьми сами по себе уже неплохие прокси для будущих возможных проблем с AGI, если его сделать криво. Как выясняется, сделать не криво ещё тоже ничего не гарантирует.

В работе есть ещё несколько спекулятивных и теоретических примеров. История про superhuman hacker, где модель обученная генерить код по спецификациям и дающая людям на аппрув и мёрж свои пулл-реквесты, вообще могла бы быть отдельным фантастическим рассказом. Если кратко, то идея в том, что у модели может сформироваться ложная цель “Добиться, чтобы человек кликнул на merge” вместо “Написать код, реализующий заданную фичу”, и от этого многое может пойти не так. Добиваться своей цели она сможет, скажем так, по-разному :) Почитайте сами, если захотите. Вообще, напоминает несколько “Avogadro Corp”.

Как защищаться от goal misgeneralization? Ну во-первых надо не попасть в историю со specification gaming. Также надо мониторить задеплоенную модель, чтобы вовремя обнаружить признаки проблемы. И когда задетектили, надо понять, как её переобучить, чтобы проблема ушла.

Полноценного решения на данный момент нет, но что можно делать:

- Иметь разнообразные обучающие данные. Diversity это хорошо! Но проблема, что заранее сложно представить все релевантные виды разнообразия. Сюда же попадает скейлинг всего (датасета, модели, вычислений), различное предобучение.
- Использовать подходы по типу байесовских или ансамблирование, когда выдаются _все_ функции, ведущие себя хорошо на обучающих данных, а когда в реальной работе они начинают расходиться, например, передавать управление человеку. Тут могут быть вычислительные сложности, трудности с выбором priors и излишняя консервативность, когда требуется единогласие.
- Требуется дальше копать тему inductive biases и обобщения, чтобы лучше понимать, когда что может происходить.

Отдельный пул проблем и задач возникает в ситуации, когда модель активно пытается нас обмануть, заставляя поверить, что она делает то, что мы хотим. В этих случаях она “знает”, что её действия не те, что мы ожидаем. Здесь может помочь объяснимость (interpretability) [хотя я лично не верю в эту тему в случае больших моделей], а также рекурсивная оценка (recursive evaluation), когда в оценке помогают другие модели.

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

В продолжение поста свежая статья от New York Times, согласно которой Гугл очень серьёзно относится к возможности смены парадигмы в поиске: https://www.nytimes.com/2022/12/21/technology/ai-chatgpt-google-search.html

Статья за пейволлом, но телеграммовское instant view в мобильном приложении, похоже, позволяет без проблем её прочитать.

In the meantime, while reading some other interesting papers, I've written an English version of the post in Gonzo ML on ChatGPT and possible future of Search:

https://blog.inten.to/llms-and-a-possible-future-for-search-507f900ac9d2

Объявление от Миши Батина. Части читателей может быть интересно:

Каждую среду, начиная с 4 января, будет проходить «Школа анализа данных Проекта AGCT».

Мы прочтем бесплатный курс лекций по следующим темам:

1. Определение геномной сети. Понятие регуляторов: энхансер, сайленсер, транскрипционный фактор. Примеры регуляции и мотивов: цинковый палец, лейциновая застежка (кратко). Подсети метаболической сети.

2. RNA-seq, WGS и экзомы. Основы секвенирования. Понятие экспрессии гена, численное выражение экспрессии (как определяется), FPKM, TPKM. Дифференциальная экспрессия, аннотация генома и транскриптома.

3. Метиллирование и метилом, генные часы, хроматин и его роль. Примеры, mTOR или воспалительный процесс.

4. Математические основы анализа графов. Определение графа, обхода графа, коммьюнити на графе. Мотивы на графах (scale-free графы, случайные графы). Отличие метаболической сети от всех остальных с точки зрения топологии

5. Алгоритмы-1. Поиск коммьюнити на графе. Алгоритмы кластеризации узлов графа (без ML).

6. Алгоритмы-2. Вычисление насыщения (enrichment), статистические критерии, GSEA, enrichR.

7. Базы данных. KEGG, GO, WikiPathway — чем отличаются, чем схожи, для чего нужны.

8. Алгоритмы-3. Новые методы построения сетей: GENIE3, pathfindR, GRNBoost2. ML-подход к кластеризации и аннотации

9. Канцерогенез. Отличия раковых клеток от здоровых, гликолиз, механизм апоптоза, восстановление теломеров. Метаболическая сеть апоптоза и её возможные повреждения, как пример.

10. Старение и его проявление в метаболизме. Возможные примеры воздействия различных гипотез клеточного старения на метаболическую сеть.

11. Бизнес-аналитика биотех-проектов в области анализа данных. Перспективные направления, возможности и подводные камни.

Приходите в наши Зумы. Можно записываться и всё обсуждать в чате Проекта AGCT

https://news.1rj.ru/str/+-GZtdAqsOvcyMGVi

The first prize in generative art should be this

Прекрасное старое:
https://ideophone.org/some-things-you-need-to-know-about-google-scholar/

и свежее:
https://twitter.com/JohnHolbein1/status/1610092979061915648

In the meantime

https://www.engadget.com/microsoft-reportedly-integrating-chatgpt-technology-into-bing-131502579.html

Cramming: Training a Language Model on a Single GPU in One Day
Jonas Geiping, Tom Goldstein
Статья: https://arxiv.org/abs/2212.14034
Код: https://github.com/JonasGeiping/cramming

Статья с контртрендом: вместо того, чтобы обучать всё более тяжёлые модели на всё более крупных кластерах, докуда мы можем дойти, обучая модель на одном GPU в течение одного дня? Авторы называют такой подход Cramming, зубрёжкой, когда обучение происходит за день до экзамена.

В отличие от традиционного scale up, здесь делают scale down. Это безусловно важное направление, потому что в случае успеха позволяет больше вовлечься в современные работы исследователям-одиночкам или академии, обычно обделёнными мощными вычислительными ресурсами уровня Гугла.

Заодно такое исследование помогает оценить концептуальный прогресс за пределами просто наращивания мощностей.

Итак, каков setup?

- Обучают BERT-подобный трансформер на задачу MLM (masked language model) с нуля.
- Нигде в пайплайне нельзя использовать существующие предобученные модели (дистилляция запрещена).
- Можно использовать любые входные тексты (не только то, на чём обучался оригинальный BERT) кроме использующихся затем в downstream задачах, при условии, что они не отбирались какой-то предобученной моделью.
- Скачивание и препроцессинг текстов (фильтрация, токенизация) не учитываются в вычислительном бюджете (если используется какой-то representation learning типа эмбеддингов, то это должно быть учтено в бюджете).
- Обучение происходит на одном GPU в течение 24 часов.
- Перформанс на downstream задачах оценивается на GLUE (не Super GLUE). Необходимый файнтюнинг в бюджете не учитывается.

В работе пробовали GPU RTX2080Ti 2018 года, а также более современные RTX A4000, A6000 2020 года. Комп был с 4 ядрами и 32 Гб памяти.

При имплементации Берта пробовали много разных улучшений, для отбора лучшего не применяли каких-либо специализированных имплементаций чего-либо, только PyTorch + nvFuser (JIT-компилятор, делающий в рантайме fusion ядер для GPU, https://pytorch.org/blog/introducing-nvfuser-a-deep-learning-compiler-for-pytorch/). В качестве бейзлайна rotary embeddings и pre-norm.Только после выбора лучшего варианта уже добавили эффективную реализацию внимания FlashAttention (https://arxiv.org/abs/2205.14135) (хотя если я правильно понял дальше, она ничего особо не дала).

Интересно, что тип трансформера и его размер не сильно влияют на конечное значение лосса через 24 часа. У более тяжёлых моделей лосс уменьшается быстрее на каждое обновление по градиенту. Зато у мелких более высокий throughput, и они обрабатывают больше токенов за тот же бюджет.

Так как scaling laws связывают per-token перформанс модели с её размером, то, по мнению авторов, большие архитектурные изменения вроде как к большим улучшениям качества не приводят (хотя мне неочевидно, почему при существенном архитектурном изменении параметры этих законов не изменятся). Так, отсекли за отсутствие улучшений funnel transformer, выкидывание FFN-слоёв, добавление рекурретности (я так понял они под этим подразумевали модель по типу ALBERT с повторением слоя с одним и тем же набором параметров) и в том числе с обучением через BPTT, и перекройку архитектуры в deep-narrow.

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

В блоке внимания отключили bias для QKV. Пытались сделать меньше голов внимания, но в итоге всё равно оставили 12. Софтмакс не заменили, стандартный MHSA оставили, замена на новые эффективные не помогла (в том числе на FLASH или на Фурье). Rotary embeddings вроде как давали небольшое преимущество, но были медленнее.

В feedforward блоке тоже убрали bias -- размер модели особо не меняет, но ускоряет вычисления. В остальном почти не меняли, активацию оставили GELU. Какие-то небольшие улучшения были от gated linear units (GLU), но вроде как по коду в итоге оно не используется (или они GLU и GELU смешивают?).

Для позиционных эмбеддингов взяли scaled sinusoidal positional embeddings. Разделение входных и выходных не дало ничего, факторизация входных тоже.

Pre-normalization c LayerNorm лучше, чем post. Другие варианты этой модификации или RMSNorm не улучшили ничего.

Нелинейную голову убрали, decoder bias тоже, сделали sparse token prediction и выиграли в памяти.

Также потюнили гиперпараметры (какую долю токенов скрывать), оптимизаторы, но оставили Adam. Сделали простую one-cycle learning rate треугольником с максимумом посередине.

Сделали агрегацию микро-батчей, когда градиенты считаются на каждом батче размера до 96, но агрегируются и апдейтят параметры только на каждый 16 или 42 батч (потому что с точки зрения лосса или качества на downstream задаче оптимальный батч сильно больше 96). Ещё и сделали постепенное увеличение числа агрегируемых микро-батчей. Дропаут на предобучении отключили.

Поскольку авторы считают, что scaling laws не дают нам добиться существенных изменений качества через модификации архитектуры, то можно зато вкладываться в качественный датасет.

Данные свежая англ. Википедия и bookcorpus + lower-case, strip accents & non-ascii. Токенизатор WordPiece со словарём 2^15 (меньшие работали хуже, а больший не лучше). SentencePiece с униграммами или BPE тоже не лучше. Нарезали на последовательности длины 128, батчи были от 64 до 96. При ограниченном вычислительном бюджете получилось достаточно сэмплов для одной эпохи без повторного обращения к любому элементу данных.

Можно поменять методы очистки, а можно и источник сменить. Пробовали на подмножествах The Pile и C4. The Pile оказался лучше с точки зрения качества на MNLI, но в принципе есть куда улучшать дедупликации, фильтрации и сортировки, особенно для C4. Про сортировку интересно, помогает отсортировать по убыванию средней частотности токена, так что сначала оказываются вероятные последовательности, а до маловероятных не добираемся. Также постепенное увеличение батча до 4096 к концу обучения особенно хорошо на C4. Вероятно, оба изменения помогают бороться с флуктуациями в распределении данных.

Далее систематически исследовали перформанс на GLUE без WNLI как в оригинальной работе про Берт.

Сравнивали с чекпойнтом 1) полноценного обученного Берта, 2) модели обученной по рецепту Берта, но в пределах заданного бюджета, 3) другой работы (https://arxiv.org/abs/2104.07705) про обучение BERT малой кровью. Перформанс неожиданно крутой, в среднем не сильно отстаёт от полного Берта. На некоторых датасетах даже превосходит.

По абляциям показали, что в среднем около 2 процентных пунктов по усреднённому GLUE даёт модификация архитектуры, 1 п.п. изменения в данных, и пол п.п. изменение процедуры обучения.

Если полученный рецепт теперь отскейлить вверх на 8 A6000 в течение 48 часов, это даёт бюджет примерно 30% оригинального BERT и 1.5% RoBERTa, при этом существенно превосходя по качеству первый и попадая в диапазон второй.

Работает в общем зубрёжка. Можно, получается, и дома на выходных обучать.

И ещё, кажется, такие эксперименты можно и нужно проводить автоматизированно, каким-нибудь эволюционным алгоритмом или даже через нечто типа network architecture search (NAS). По идее, большой запуск NAS в режиме cramming может быть на порядки эффективнее старых подходов (но это не точно, надо внимательно считать).