Дорогой читатель, приветствую тебя на моём канале!
Вкратце обо мне: я (@Fritx) работаю в Яндексе Senior ML-инженером.
Обучаю и внедряю в прод в разные сервисы трансформерные модели для рекомендаций.
В свободное время я пытаюсь совершенствовать свои знания, и здесь буду излагать самое важное из того, что я прочитал.
Статьи, про которые я пишу, обычно идут группами по темам, в порядке своего концептуального развития.
Приятного чтения!
Вкратце обо мне: я (@Fritx) работаю в Яндексе Senior ML-инженером.
Обучаю и внедряю в прод в разные сервисы трансформерные модели для рекомендаций.
В свободное время я пытаюсь совершенствовать свои знания, и здесь буду излагать самое важное из того, что я прочитал.
Статьи, про которые я пишу, обычно идут группами по темам, в порядке своего концептуального развития.
Приятного чтения!
❤9👾6🐳2
В последнее время мой взгляд был сфокусирован на области генерации кода. Я изучил ряд статей на эту тему и сформировал представление о текущей ситуации в сфере. В ближайшее время напишу сюда о прочитанных статьях то, что, по моему мнению, нужно из этих статей отложить у себя в голове (часто опуская много деталей).
Начнём с первой работы, применяющей большие языковые модели в программировании - OpenAI Codex. В основе GitHub Copilot лежит именно эта модель.
Концептуально система работает так:
1) Обучение - языковая модель GPT файнтюнится на генерацию кода, датасет для этого состоит из пар (docstring, code), взятых из питоновских файлов с кодом на гитхабе.
2) Генерация - Codex генерирует много сэмплов программ (до 1000), которые затем фильтруются по "публичным" тестам (образцам из условия задачи), и выбирается топ программ по среднему логарифму вероятности токена.
Если модель дотюнить на вручную сделанном датасете из пар (docstring, code), то получается модель Codex-S, которая работает ещё немного лучше.
В результате система значительно обходит чистую GPT на датасете с задачками APPS. До superhuman-производительности в этой сфере ещё очень далеко, по причинам, которые мы позднее обсудим. Оставайтесь с нами, чтобы узнать, что было после Codex!
Концептуально система работает так:
1) Обучение - языковая модель GPT файнтюнится на генерацию кода, датасет для этого состоит из пар (docstring, code), взятых из питоновских файлов с кодом на гитхабе.
2) Генерация - Codex генерирует много сэмплов программ (до 1000), которые затем фильтруются по "публичным" тестам (образцам из условия задачи), и выбирается топ программ по среднему логарифму вероятности токена.
Если модель дотюнить на вручную сделанном датасете из пар (docstring, code), то получается модель Codex-S, которая работает ещё немного лучше.
В результате система значительно обходит чистую GPT на датасете с задачками APPS. До superhuman-производительности в этой сфере ещё очень далеко, по причинам, которые мы позднее обсудим. Оставайтесь с нами, чтобы узнать, что было после Codex!
🔥8👍4
Deepmind AlphaCode - конкурент OpenAI Codex, который работает примерно так:
Сначала языковую модель претрейнят на всём GitHub.
Для файнтюна используется собственный датасет с задачками и решениями. В нём есть ещё и мета-информация (например, тег задачи), которая используется только при файнтюне.
В файнтюне есть ещё пара инкрементальных хаков, я это опущу.
Сэмплирование программы гораздо хитрее:
- Генерируется куча (до 10^6) программ, фильтруются по образцам из условия
- Отдельная модель генерирует тестовые данные для задачи (корректность не важна), и по выходам на этих данных программы кластеризуют.
- Представители кластеров отправляются на тестирование.
В результате при строгом ограничении на кол-во итоговых программ модель сильно обходит Codex (думаю, благодаря хитрому этапу генерации), но потолок сложности задач, которые система может решать, такой же невысокий, как у Codex.
Также для хайпа модель отправили на Codeforces и она там нарешала на медианный рейтинг.
Сначала языковую модель претрейнят на всём GitHub.
Для файнтюна используется собственный датасет с задачками и решениями. В нём есть ещё и мета-информация (например, тег задачи), которая используется только при файнтюне.
В файнтюне есть ещё пара инкрементальных хаков, я это опущу.
Сэмплирование программы гораздо хитрее:
- Генерируется куча (до 10^6) программ, фильтруются по образцам из условия
- Отдельная модель генерирует тестовые данные для задачи (корректность не важна), и по выходам на этих данных программы кластеризуют.
- Представители кластеров отправляются на тестирование.
В результате при строгом ограничении на кол-во итоговых программ модель сильно обходит Codex (думаю, благодаря хитрому этапу генерации), но потолок сложности задач, которые система может решать, такой же невысокий, как у Codex.
Также для хайпа модель отправили на Codeforces и она там нарешала на медианный рейтинг.
👍5👏1🤔1
Сила в простоте
Я думаю, что если предлагаемая система (алгоритм, что угодно) в разы "сложнее" бейзлайна, и она даёт небольшой прирост по метрикам, то такой работе не уготовано место в истории. Это может иметь смысл, когда вы хотите выжать любыми способами максимум здесь и сейчас, как это бывает в проде, но в рамках технологического прогресса это не так.
Что я имею ввиду под "сложностью"?
Прежде всего, это количество составных частей в основе системы и их используемость по отдельности.
Из используемости компоненты следует выработанная интуиция и понимание, как и когда данная компонента работает, что от неё ожидать в различных ситуациях. Также если компоненту используют, то, скорее всего, для неё есть отточенный код/инструменты. А от количества этих компонент зависит возможность дебага, анализа системы и её воспроизведения.
На мой взгляд, время сметает монстров, а системы из простых компонент, собранных правильным образом, совершают прорывы и сами по себе становятся новыми простыми компонентами. Так и работает прогресс.
Прекрасный положительный пример - это self-attention (на картинке).
Прекрасный отрицательный пример будет в завтрашней статье по кодогенерации.
Я думаю, что если предлагаемая система (алгоритм, что угодно) в разы "сложнее" бейзлайна, и она даёт небольшой прирост по метрикам, то такой работе не уготовано место в истории. Это может иметь смысл, когда вы хотите выжать любыми способами максимум здесь и сейчас, как это бывает в проде, но в рамках технологического прогресса это не так.
Что я имею ввиду под "сложностью"?
Прежде всего, это количество составных частей в основе системы и их используемость по отдельности.
Из используемости компоненты следует выработанная интуиция и понимание, как и когда данная компонента работает, что от неё ожидать в различных ситуациях. Также если компоненту используют, то, скорее всего, для неё есть отточенный код/инструменты. А от количества этих компонент зависит возможность дебага, анализа системы и её воспроизведения.
На мой взгляд, время сметает монстров, а системы из простых компонент, собранных правильным образом, совершают прорывы и сами по себе становятся новыми простыми компонентами. Так и работает прогресс.
Прекрасный положительный пример - это self-attention (на картинке).
Прекрасный отрицательный пример будет в завтрашней статье по кодогенерации.
👍8❤🔥1
CodeRL - Франкенштейн от Salesforces
Чего у человека не отнять, так это желания прикрутить RL ко всему, к чему прикручивается.
В данной работе генерация программы токен за токеном рассматривается как последовательность действий, а успех программы, получаемой в конце - это награда в конце эпизода. От -1 (compile error) до +1 (passed tests).
Для обучения используется навороченный RL-алгоритм (невозможно описать его тут), а сложность схемы применения вы можете наблюдать на картинке, о ней я как раз скажу пару слов.
Так как у нас есть модель "среды" (состояние среды это просто текущий текст программы), мы можем использовать поиск по состояниям, как в AlphaGo.
Что в урезанном виде и делает модуль program refining.
Модуль program repairing подаёт ошибку, которую выдаёт программа/компилятор, обратно в генеративную модель, чтобы она попробовала её починить. Я также пробовал делать, когда программировал с помощью ChatGPT, эта схема работает не так круто, как можно вообразить.
Результат: всё те же 25% решённых задачек уровня Intro в APPS у лучшей модели, хотя сама модель похудела, и программ нужно генерировать меньше. Если взять тот же бюджет на программы, то у Codex и AlphaCode получается немного хуже. На сложных задач прирост около процента.
Думаю, что пятикратное усложнение системы не стоит того профита, который она даёт.
@knowledge_accumulator
Чего у человека не отнять, так это желания прикрутить RL ко всему, к чему прикручивается.
В данной работе генерация программы токен за токеном рассматривается как последовательность действий, а успех программы, получаемой в конце - это награда в конце эпизода. От -1 (compile error) до +1 (passed tests).
Для обучения используется навороченный RL-алгоритм (невозможно описать его тут), а сложность схемы применения вы можете наблюдать на картинке, о ней я как раз скажу пару слов.
Так как у нас есть модель "среды" (состояние среды это просто текущий текст программы), мы можем использовать поиск по состояниям, как в AlphaGo.
Что в урезанном виде и делает модуль program refining.
Модуль program repairing подаёт ошибку, которую выдаёт программа/компилятор, обратно в генеративную модель, чтобы она попробовала её починить. Я также пробовал делать, когда программировал с помощью ChatGPT, эта схема работает не так круто, как можно вообразить.
Результат: всё те же 25% решённых задачек уровня Intro в APPS у лучшей модели, хотя сама модель похудела, и программ нужно генерировать меньше. Если взять тот же бюджет на программы, то у Codex и AlphaCode получается немного хуже. На сложных задач прирост около процента.
Думаю, что пятикратное усложнение системы не стоит того профита, который она даёт.
@knowledge_accumulator
👍5😁2
При контакте с RL человеческий мозг даёт сбой
(навеяно предыдущим постом)
В своё время этот же сбой затянул и меня самого. Но за эти долгие годы знакомства с RL я вроде бы осознал его феномен.
Ставьте 🤯 под этим постом, если вам интересен мета-взгляд на RL, почему люди сходят от него с ума, и почему они делают это совершенно напрасно.
Завтра я расскажу про последнюю статью на тему решения задачек языковыми моделями, а дальше, если будет поставлено хотя бы два 🤯 (1 из которых я поставлю сам), то напишу серию постов про RL - про область в целом и про прикольные статьи, с долей скептицизма к происходящему.
Это позволит мне с чистой совестью пользоваться RL-терминологией (за прошлый пост мне немного стыдно).
(навеяно предыдущим постом)
В своё время этот же сбой затянул и меня самого. Но за эти долгие годы знакомства с RL я вроде бы осознал его феномен.
Ставьте 🤯 под этим постом, если вам интересен мета-взгляд на RL, почему люди сходят от него с ума, и почему они делают это совершенно напрасно.
Завтра я расскажу про последнюю статью на тему решения задачек языковыми моделями, а дальше, если будет поставлено хотя бы два 🤯 (1 из которых я поставлю сам), то напишу серию постов про RL - про область в целом и про прикольные статьи, с долей скептицизма к происходящему.
Это позволит мне с чистой совестью пользоваться RL-терминологией (за прошлый пост мне немного стыдно).
🤯21
Parsel - новый подход к генерации алгоритмов.
Авторы предлагают разбить процедуру генерации программы по описанию на несколько шагов:
1) Просят GPT сгенерировать high-level описание пошагового решения задачи.
2) Просят Codex перевести это описание в язык Parsel - это такой способ описания программы через набор функций с их описаниями, аргументами, зависимостями между ними, а также правильными примерами, при этом без реализации.
Codex никак генерировать Parsel не учат, подают образцы Parsel-программ прямо в промпт.
3) Далее эту Parsel-программу "компилируют" - просят Codex сгенерировать реализации функций, заданных в Parsel, автоматически разрешают зависимости, тестируют на отдельных тестах, содержащихся в программе, и так отметают большее количество плохих сэмплов из языковой модели.
4) В результате хорошие реализации отдельных функций склеивают в готовые программы.
К замерам есть некоторые вопросы, потому что сравнение с конкурентами не очень полное и не в равных условиях. Тем не менее, по одной из метрик выбивает до 25% сложных задач в APPS, что кратно лучше, чем у оригинальных Codex и Alphacode.
@knowledge_accumulator
Авторы предлагают разбить процедуру генерации программы по описанию на несколько шагов:
1) Просят GPT сгенерировать high-level описание пошагового решения задачи.
2) Просят Codex перевести это описание в язык Parsel - это такой способ описания программы через набор функций с их описаниями, аргументами, зависимостями между ними, а также правильными примерами, при этом без реализации.
Codex никак генерировать Parsel не учат, подают образцы Parsel-программ прямо в промпт.
3) Далее эту Parsel-программу "компилируют" - просят Codex сгенерировать реализации функций, заданных в Parsel, автоматически разрешают зависимости, тестируют на отдельных тестах, содержащихся в программе, и так отметают большее количество плохих сэмплов из языковой модели.
4) В результате хорошие реализации отдельных функций склеивают в готовые программы.
К замерам есть некоторые вопросы, потому что сравнение с конкурентами не очень полное и не в равных условиях. Тем не менее, по одной из метрик выбивает до 25% сложных задач в APPS, что кратно лучше, чем у оригинальных Codex и Alphacode.
@knowledge_accumulator
👍7🔥2
Не хочу грузить вас больше в этот день, только сообщу, что я вас немного обманул, и завтра всё-таки будет ещё одна статья про код - я её как-то изначально упустил из виду.
Всех причитающихся с праздником и хорошего вечера! ❤️🌹
Всех причитающихся с праздником и хорошего вечера! ❤️🌹
🍾6❤4
CodeT: Code Generation with Generated Tests
То, что языковую модель нужно использовать для генерации тестов, стало общей точкой в статьях. Подход к выбору программ в этой статье чуть более хитрый, чем в AlphaCode, и работает он лучше - авторы воспроизвели его. При этом вся система сильно проще, чем Parsel.
1) Генерируем программы и тесты (всё с помощью запросов к Codex).
2) Прогоняем все программы на всех тестах, разбиваем их на кластеры по тому, какие тесты были пройдены программой (до этого момента всё, как в AlphaCode)
3) AlphaCode ранжирует кластеры только по размеру, а CodeT по величине (размер кластера) * (кол-во пройденных тестов), дальше их представители и подаются, как решения.
Когда количество тестов и программ большое, эту процедуру заменяют на её рандомизированную версию. Детали тут не важны, ключевое слово - RANSAC.
Результат - +6% Intro-задач и +3.7% сложных задач из APPS даёт эта процедура поверх Codex. К сожалению, в сетапе, который был в Parsel у лучшей модели, алгоритм не прогоняли, но на одинаковых сетапах CodeT лучше.
То, что языковую модель нужно использовать для генерации тестов, стало общей точкой в статьях. Подход к выбору программ в этой статье чуть более хитрый, чем в AlphaCode, и работает он лучше - авторы воспроизвели его. При этом вся система сильно проще, чем Parsel.
1) Генерируем программы и тесты (всё с помощью запросов к Codex).
2) Прогоняем все программы на всех тестах, разбиваем их на кластеры по тому, какие тесты были пройдены программой (до этого момента всё, как в AlphaCode)
3) AlphaCode ранжирует кластеры только по размеру, а CodeT по величине (размер кластера) * (кол-во пройденных тестов), дальше их представители и подаются, как решения.
Когда количество тестов и программ большое, эту процедуру заменяют на её рандомизированную версию. Детали тут не важны, ключевое слово - RANSAC.
Результат - +6% Intro-задач и +3.7% сложных задач из APPS даёт эта процедура поверх Codex. К сожалению, в сетапе, который был в Parsel у лучшей модели, алгоритм не прогоняли, но на одинаковых сетапах CodeT лучше.
👍6🔥1