Forwarded from Инженерообязанный🫡 | Блог Дата Инженера
#кейсы
🚨 Ребят, рассказываю про кейс, с которым столкнулся🚨 .
Вероятнее всего будет интересен Аналитикам из-за работы с Pandas, но Инженерам данных тоже к прочтению.🧑🎓
Вкратце, есть Дата Фрейм, и в нём 12к строк, и 22 колонки, и джоба работает абсолютно нормально, все преобразования работают за секунду, а заливка данных в GreenPlum 13 минут работает. Сами понимаете,12к строк всего, а если там будет 100к строк? Что тогда🤔 ? (Считать не нужно, вопрос риторический)
Пример кода загрузки в GreenPlum:
Оказывается, что при использовании стандартной функции to_sql, данные записываются в базу данных построчно, грубо говоря командой INSERT, а параметр chunksize задаёт через сколько строк сделать коммит в БД. При таком использовании время вставки 5к строк составляет:
Нам конечно же такая тема не понравилась, так как очень долго. Начал думать🤔 , что и как сделать так, чтобы ускорить данный процесс. В голову приходила только идея💡 сохранять данные в файл и использовать команду COPY. И в итоге, нарвался на статью от SQL-EX(ссылка). В общем и целом, там рассматривается 5 способов загрузки данных с помощью библиотеки Pandas в Postgres(если кто не знал 😳 для GreenPlum используется движок Postgresql, поэтому данные варианты подходили и нам). Выбрав самый быстрый способ🐆 , оказалось, что в параметр method можно передать свою функцию, где мы будет передавать логику сохранения файла(в нашем случае все сохраняется в памяти) и выполнения команды COPY, и что не мало важно, код был понятным для аналитиков. Код получился следующим:
В данном случае - время резко сократилось в +100500 раз, и чем больше данных, тем данный метод будет быстрее.
Это метод хорош, когда данных немного, от силы до пары гигабайт. Если данных больше, то лучше сохранять данные в сыром виде и уже с помощью PXF подгружать данные в GreenPlum.
‼️ Могу посоветовать сохранить к себе данную статью, чтобы при столкновении с подобной задачей, долго не искать как и что.(Для этого я его тут и сохранил😂 ).
Интересно, а GPT напишет такой код? Хмммм....
Вероятнее всего будет интересен Аналитикам из-за работы с Pandas, но Инженерам данных тоже к прочтению.
Вкратце, есть Дата Фрейм, и в нём 12к строк, и 22 колонки, и джоба работает абсолютно нормально, все преобразования работают за секунду, а заливка данных в GreenPlum 13 минут работает. Сами понимаете,12к строк всего, а если там будет 100к строк? Что тогда
Пример кода загрузки в GreenPlum:
def df_to_db_old(df, schema, table, force=False):
from sqlalchemy import text
engine = get_gp_engine() # get_gp_engine функция возвращающая движок от psycopg3
df.to_sql(con=engine,
index=False,
schema=schema,
name=table,
if_exists='append',
chunksize=16000)
# Создание DataFrame
df_5000_rows = pd.DataFrame(data)
df_to_db(df=df_5000_rows, schema='team_test', table='shust_test')
Оказывается, что при использовании стандартной функции to_sql, данные записываются в базу данных построчно, грубо говоря командой INSERT, а параметр chunksize задаёт через сколько строк сделать коммит в БД. При таком использовании время вставки 5к строк составляет:
Время вставки (1): 190.558109998703 секунд
Нам конечно же такая тема не понравилась, так как очень долго. Начал думать
def df_to_db(df, schema, table, force=False):
def psql_insert_copy(table, conn, keys, data_iter): #функция передаваемая в мотод
from io import StringIO
import csv
# получаем подключение DBAPI, которое может обеспечить курсор
dbapi_conn = conn.connection
with dbapi_conn.cursor() as cur:
s_buf = StringIO()
writer = csv.writer(s_buf)
writer.writerows(data_iter)
s_buf.seek(0)
columns = ', '.join('"{}"'.format(k) for k in keys)
if table.schema:
table_name = '{}.{}'.format(table.schema, table.name)
else:
table_name = table.name
sql = 'COPY {} ({}) FROM STDIN WITH CSV'.format(
table_name, columns)
cur.copy_expert(sql=sql, file=s_buf)
engine = gp_engine() # gp_engine функция возвращающая движок от psycopg2
df.to_sql(con=engine,
index=False,
schema=schema,
name=table,
if_exists='append',
method=psql_insert_copy)
df_to_db(df=df_5000_rows, schema='team_test', table='shust_test')
В данном случае - время резко сократилось в +100500 раз, и чем больше данных, тем данный метод будет быстрее.
Время вставки (2): 0.3825254440307617 секунд
Это метод хорош, когда данных немного, от силы до пары гигабайт. Если данных больше, то лучше сохранять данные в сыром виде и уже с помощью PXF подгружать данные в GreenPlum.
Интересно, а GPT напишет такой код? Хмммм....
Please open Telegram to view this post
VIEW IN TELEGRAM
Forwarded from ml4se
Mechanistic Interpretability
I have prepared a list of papers on Mechanistical Interpretability. If you have good links on this topic, please share them in the comments.
* 2021: A Mathematical Framework for Transformer Circuits
* 2022.06.27: Mechanistic Interpretability, Variables, and the Importance of Interpretable Bases
* 2022.09.14: Toy Models of Superposition
* 2022.09.24: In-context Learning and Induction Heads
* 2023.04.28: Towards Automated Circuit Discovery for Mechanistic Interpretability
* 2023.01.12: Progress measures for grokking via mechanistic interpretability
* 2023.05.24: Interpretability Dreams
* 2023.09: Sparse Autoencoders Find Highly Interpretable Model Directions
* 2023.10.25: Attention Lens: A Tool for Mechanistically Interpreting the Attention Head Information Retrieval Mechanism
* 2024.01.15: Sparse Autoencoders Work on Attention Layer Outputs
...
I have prepared a list of papers on Mechanistical Interpretability. If you have good links on this topic, please share them in the comments.
* 2021: A Mathematical Framework for Transformer Circuits
* 2022.06.27: Mechanistic Interpretability, Variables, and the Importance of Interpretable Bases
* 2022.09.14: Toy Models of Superposition
* 2022.09.24: In-context Learning and Induction Heads
* 2023.04.28: Towards Automated Circuit Discovery for Mechanistic Interpretability
* 2023.01.12: Progress measures for grokking via mechanistic interpretability
* 2023.05.24: Interpretability Dreams
* 2023.09: Sparse Autoencoders Find Highly Interpretable Model Directions
* 2023.10.25: Attention Lens: A Tool for Mechanistically Interpreting the Attention Head Information Retrieval Mechanism
* 2024.01.15: Sparse Autoencoders Work on Attention Layer Outputs
...
Forwarded from что-то на DL-ском
Forwarded from Tati's Wonderland (Tanya)
МЛ дизайн, общий план
#карьера #интервью #career #faang #interview
План ответа зависит от задачи и области, но в большинстве примерно такой. Сейчас тут будет микс языков (я не все знаю на русском).
1. Какую бизнес задачу мы решаем? В чем проблема, что главное, что не очень важно. Наши true north бизнес метрики, safety guardrails. Что сейчас в есть проде (ноль или что-то).
2. Наши constrains (latency, costs, hardware limits, annotation budget, etc.)
3. Какие данные у нас есть, сколько, что с разметкой.
На МЛ дизайн ожидается, что кандидат задаст вопросы, чтобы это понять, а не будет сразу лепить предположения.
Когда мы думаем, что поняли задачу:
4. Выдаем high level design с опциями (так и говорим, что дадим high level, а потом углубимся. Заодно спросим интервьюера, в какие пункты плана лучше углубиться, ведь время ограничено).
5. Переформулируем задачу в задачу МЛ (классификация, регрессия, next token prediction, clustering...) Возможны варианты, озвучте несколько.
6. Оффлайн метрики (онлайн обсудили в пункте 1, когда разбирались, что нужно бизнесу). Накидать можно много, но стоит выбрать главную True north metric и safety guardrails.
7. Данные. Как будем готовить. Будем ли размечать, как. Какие сигналы и фичи использовать, как делать preprocessing и т.д. с оговоркой, что feature eng/ preprocessing зависит и от выбора моделей.
Что будем делать с cold start и/или если данных нет.
8. Модели и tuning: несколько подходов по возрастанию сложности. Обязательно их proc and cons. Почему они.
Потом выбрать один подход и хорошо его рассказать. Спросите интервьюера, в какой метод они желают углубиться.
9. Тренировка. Валидация. Тест. Бенчмарки.
Как выбираем модель для прода.
10. Катим в прод. Оптимизация inference (at scale). Инфраструктура? (Часто не нужно на МЛ дизайне, но иногда да, спросите интервьюера)
11. Онлайн тесты. Тут про а/б тесты, выборку, метрики бизнеса и т.д.
План озвучиваем сразу во время high level design.
Потом идём по пунктам, периодически сверяемся, где углубиться. Не все пункты хотят слышать во все компании. Часть про инфраструктуру, например, часто можно опустить.
Еще: не все захотят углубиться в модели, кто-то может захотеть углубиться в данные или метрики. Будьте флексибильны. В high level design укажите все, а потом уже углубляйтесь по ситуации, считывайте сигналы с интервьюера.
Продолжение следует...
#карьера #интервью #career #faang #interview
План ответа зависит от задачи и области, но в большинстве примерно такой. Сейчас тут будет микс языков (я не все знаю на русском).
1. Какую бизнес задачу мы решаем? В чем проблема, что главное, что не очень важно. Наши true north бизнес метрики, safety guardrails. Что сейчас в есть проде (ноль или что-то).
2. Наши constrains (latency, costs, hardware limits, annotation budget, etc.)
3. Какие данные у нас есть, сколько, что с разметкой.
На МЛ дизайн ожидается, что кандидат задаст вопросы, чтобы это понять, а не будет сразу лепить предположения.
Когда мы думаем, что поняли задачу:
4. Выдаем high level design с опциями (так и говорим, что дадим high level, а потом углубимся. Заодно спросим интервьюера, в какие пункты плана лучше углубиться, ведь время ограничено).
5. Переформулируем задачу в задачу МЛ (классификация, регрессия, next token prediction, clustering...) Возможны варианты, озвучте несколько.
6. Оффлайн метрики (онлайн обсудили в пункте 1, когда разбирались, что нужно бизнесу). Накидать можно много, но стоит выбрать главную True north metric и safety guardrails.
7. Данные. Как будем готовить. Будем ли размечать, как. Какие сигналы и фичи использовать, как делать preprocessing и т.д. с оговоркой, что feature eng/ preprocessing зависит и от выбора моделей.
Что будем делать с cold start и/или если данных нет.
8. Модели и tuning: несколько подходов по возрастанию сложности. Обязательно их proc and cons. Почему они.
Потом выбрать один подход и хорошо его рассказать. Спросите интервьюера, в какой метод они желают углубиться.
9. Тренировка. Валидация. Тест. Бенчмарки.
Как выбираем модель для прода.
10. Катим в прод. Оптимизация inference (at scale). Инфраструктура? (Часто не нужно на МЛ дизайне, но иногда да, спросите интервьюера)
11. Онлайн тесты. Тут про а/б тесты, выборку, метрики бизнеса и т.д.
План озвучиваем сразу во время high level design.
Потом идём по пунктам, периодически сверяемся, где углубиться. Не все пункты хотят слышать во все компании. Часть про инфраструктуру, например, часто можно опустить.
Еще: не все захотят углубиться в модели, кто-то может захотеть углубиться в данные или метрики. Будьте флексибильны. В high level design укажите все, а потом уже углубляйтесь по ситуации, считывайте сигналы с интервьюера.
Продолжение следует...
Forwarded from Tati's Wonderland (Tanya)
#career #faang #interview #карьера #интервью
МЛ дизайн, работа над ошибками
Общий план выше, сейчас посмотрим на распространенные ошибки, которые я видела на МЛ дизайне.
1. Самое ключевое.
Мы не поняли задачу: в чем именно проблема, ЗАЧЕМ, почему нужно её решать. Какие бизнес метрики важны, какие не очень...
И... полезли её решать.
2. Мы не узнали какие у нас данные, есть ли они. Сразу предположили, что все есть в красивом виде и с разметкой, и давай решать (спойлер. Так не бывает)
3. Мы решаем задачу сразу сота LLMкой /LLM+GNN, etc. не уточнив, что там по бюджетам и железу, и не рассмотрев другие подходы.
4. Мы выбрали один любимый подход и рассматриваем только его. Не агрументируем, почему этот подход. Не рассматриваем альтернативы, их proc and cons. На вопрос: "почему так", ответ "СОТА" без чёткого понимания trade-offs.
МЛ дизайн проверяет ваше знание методов, понимание их плюсов-минусов. Если гиперфокусироваться на одном любимом подходе, вы не сможете это показать.
5. Мы выписали разные метрики, но не знаем их толком.
Если вы не можете произнести на интервью NDCG полными словами - не прозносите! Скажите аббревиатурой. Если не можете объяснить метрику (быстро, понятно, четко) - лучше даже не упоминайте ее, утоните.
Если вы написали на интервью Matthew correlation, будьте готовы ответить за неё и помнить формулу 😁.
6. И наоборот: их никто не спрашивал, а они начинают как прилежные школьники рассказывать формулы для precision and recall (на позицию тех лида).
Не лезте в такие детали. Интервьюер спросит, если захочет. Предполагается, что тех лид с опытом 10 лет знает, что такое recall, не надо тратить время и писать эти формулы. Тратьте время очень грамотно.
7. Time management тоже очень частая проблема.
Рассказать весь дизайн за 45 минут (5 на интро, 5 на follow up, 5 на ваши вопросы), при этом не тараторить со скоростью 100500 слов в сек, достаточно нетривиально. Нужно тренироваться. Поэтому тренировочные интервью так важны.
Часто кандидаты не укладываются во время совершенно, приходится их направлять и навигировать вопросами, чтобы успеть осветить важные пункты. На миддла норм, но на тех лида вы должны вести это интервью, а не наоборот.
8. Отсутствие гибкости. Слишком stick to the plan и не считывают сигналы интервьюера. Я говорю, инфру и data engineering часть можно опустить. А человек все равно по плану... не может отклониться, в итоге теряет время и не успеваем то, что нужно было успеть.
9. Отсутсвие гибкости. Или так: "У вас есть 5 минут на вопросы нам". В ответ, "Ой, давайте я тогда лучше дорасскажу про инфраструктуру 🙈", которую не успел.
Ваши вопросы на уровень тех лида куда важнее, чем дорассказать, что вы там не успели по вашему плану. Этот план важен вам. Гибкость важна, в работе тоже.
10. Мы не знаем, что делать с дисбалансом классов, trade offs, как навигировать precision recall trade off, что делать, если AUPR высок, а AUC близок к 0.5, как делать анализ предиктов, что делать с cold starts, и т.д. дополнительные вопросы всегда будут, будьте готовы.
Вот такие ошибки пришли сходу в голову.
Дальше будут ресурсы для подготовки.
Всем удачи на всяких интервью!
МЛ дизайн, работа над ошибками
Общий план выше, сейчас посмотрим на распространенные ошибки, которые я видела на МЛ дизайне.
1. Самое ключевое.
Мы не поняли задачу: в чем именно проблема, ЗАЧЕМ, почему нужно её решать. Какие бизнес метрики важны, какие не очень...
И... полезли её решать.
2. Мы не узнали какие у нас данные, есть ли они. Сразу предположили, что все есть в красивом виде и с разметкой, и давай решать (спойлер. Так не бывает)
3. Мы решаем задачу сразу сота LLMкой /LLM+GNN, etc. не уточнив, что там по бюджетам и железу, и не рассмотрев другие подходы.
4. Мы выбрали один любимый подход и рассматриваем только его. Не агрументируем, почему этот подход. Не рассматриваем альтернативы, их proc and cons. На вопрос: "почему так", ответ "СОТА" без чёткого понимания trade-offs.
МЛ дизайн проверяет ваше знание методов, понимание их плюсов-минусов. Если гиперфокусироваться на одном любимом подходе, вы не сможете это показать.
5. Мы выписали разные метрики, но не знаем их толком.
Если вы не можете произнести на интервью NDCG полными словами - не прозносите! Скажите аббревиатурой. Если не можете объяснить метрику (быстро, понятно, четко) - лучше даже не упоминайте ее, утоните.
Если вы написали на интервью Matthew correlation, будьте готовы ответить за неё и помнить формулу 😁.
6. И наоборот: их никто не спрашивал, а они начинают как прилежные школьники рассказывать формулы для precision and recall (на позицию тех лида).
Не лезте в такие детали. Интервьюер спросит, если захочет. Предполагается, что тех лид с опытом 10 лет знает, что такое recall, не надо тратить время и писать эти формулы. Тратьте время очень грамотно.
7. Time management тоже очень частая проблема.
Рассказать весь дизайн за 45 минут (5 на интро, 5 на follow up, 5 на ваши вопросы), при этом не тараторить со скоростью 100500 слов в сек, достаточно нетривиально. Нужно тренироваться. Поэтому тренировочные интервью так важны.
Часто кандидаты не укладываются во время совершенно, приходится их направлять и навигировать вопросами, чтобы успеть осветить важные пункты. На миддла норм, но на тех лида вы должны вести это интервью, а не наоборот.
8. Отсутствие гибкости. Слишком stick to the plan и не считывают сигналы интервьюера. Я говорю, инфру и data engineering часть можно опустить. А человек все равно по плану... не может отклониться, в итоге теряет время и не успеваем то, что нужно было успеть.
9. Отсутсвие гибкости. Или так: "У вас есть 5 минут на вопросы нам". В ответ, "Ой, давайте я тогда лучше дорасскажу про инфраструктуру 🙈", которую не успел.
Ваши вопросы на уровень тех лида куда важнее, чем дорассказать, что вы там не успели по вашему плану. Этот план важен вам. Гибкость важна, в работе тоже.
10. Мы не знаем, что делать с дисбалансом классов, trade offs, как навигировать precision recall trade off, что делать, если AUPR высок, а AUC близок к 0.5, как делать анализ предиктов, что делать с cold starts, и т.д. дополнительные вопросы всегда будут, будьте готовы.
Вот такие ошибки пришли сходу в голову.
Дальше будут ресурсы для подготовки.
Всем удачи на всяких интервью!
Forwarded from Concise Research (Sergey Kastryulin)
Reconstruction vs. Generation: Taming Optimization Dilemma in Latent Diffusion Models
[код и веса]
Выбор представления для обучения латентной диффузии - важнейший фактор качества и скорости обучения модели.
Более высокая размерность
латентного пространства улучшает качество реконструкции. Обычно она достигается путём увеличения числа каналов. VAE первых моделей семейства SD имели 4 канала, у FLUX и SD3 уже 16, а SANA - 32.
Более низкая размерность
латентного пространства упрощает задачу обучения генеративной модели. Если размерность все-таки хочется держать высокой, то можно компенсировать сложность увеличением модели и компьюта, но это дорого.
Интересно, что проблемы связанные с большой размерностью ранее обсуждали в основном для дискретных токенизаторов. Для них известно, что большие кодбуки плохо утилизируются. Авторы этой работы анализируют распределение латентов непрерывных VAE и приходят к такому же выводу. Идея работы в том чтобы заалайнить латенты с фичами visual foundation model, тем самым улучшив их качество с точки зрения обучения на них генеративных моделей.
Метод
Основной вклад работы - двухкомпонентный лосс, который алайнит VAE латенты
1️⃣ Поэлементно минимизируют косинусное расстояние между
2️⃣ Минимизируют разницу косинусных расстояний между элементами
Оба компонента считают с отступом так, чтобы только большие отклонения вносили вклад в лосс, а между собой компоненты взвешивают пропорционально их вкладу.
Эксперименты
За основу берут ванильный LDM сетап с VQ-GAN токенизатором (f16d32, f16d16), но без квантизации. На его латентах учат DiTы от 0.1B до 1.6В c полным фаршем из RF, подбора adam.beta2, bfloat16 и RMSNorm для стабилизации, SwiGLU и RoPE. Полученная серия моделей LightningDiT сходится к FID 1.35 на ImageNet 256, причем значение 2.11 получается всего за 64 эпохи.
Выводы
В статье настораживает почти полное отсутствие примеров реконструкций предложенных VAE и аблейшенов влияния примочек для DiT на рост качества относительно бейзлайнов. Нравится движение в сторону недоизученной темы оптимальных пространств для обучения генеративок
[код и веса]
Выбор представления для обучения латентной диффузии - важнейший фактор качества и скорости обучения модели.
Более высокая размерность
латентного пространства улучшает качество реконструкции. Обычно она достигается путём увеличения числа каналов. VAE первых моделей семейства SD имели 4 канала, у FLUX и SD3 уже 16, а SANA - 32.
Более низкая размерность
латентного пространства упрощает задачу обучения генеративной модели. Если размерность все-таки хочется держать высокой, то можно компенсировать сложность увеличением модели и компьюта, но это дорого.
Интересно, что проблемы связанные с большой размерностью ранее обсуждали в основном для дискретных токенизаторов. Для них известно, что большие кодбуки плохо утилизируются. Авторы этой работы анализируют распределение латентов непрерывных VAE и приходят к такому же выводу. Идея работы в том чтобы заалайнить латенты с фичами visual foundation model, тем самым улучшив их качество с точки зрения обучения на них генеративных моделей.
Метод
Основной вклад работы - двухкомпонентный лосс, который алайнит VAE латенты
Z с фичами DINOv2 F. Для этого Z линейно отображают в размерность F получая Z’, после чего:1️⃣ Поэлементно минимизируют косинусное расстояние между
Z’ и F2️⃣ Минимизируют разницу косинусных расстояний между элементами
Z’ и FОба компонента считают с отступом так, чтобы только большие отклонения вносили вклад в лосс, а между собой компоненты взвешивают пропорционально их вкладу.
Эксперименты
За основу берут ванильный LDM сетап с VQ-GAN токенизатором (f16d32, f16d16), но без квантизации. На его латентах учат DiTы от 0.1B до 1.6В c полным фаршем из RF, подбора adam.beta2, bfloat16 и RMSNorm для стабилизации, SwiGLU и RoPE. Полученная серия моделей LightningDiT сходится к FID 1.35 на ImageNet 256, причем значение 2.11 получается всего за 64 эпохи.
Выводы
В статье настораживает почти полное отсутствие примеров реконструкций предложенных VAE и аблейшенов влияния примочек для DiT на рост качества относительно бейзлайнов. Нравится движение в сторону недоизученной темы оптимальных пространств для обучения генеративок
Forwarded from Лига Хруща // League of Hrusch
Spent last half a year rejecting the idea of switching to cursor.sh. Tried it today, and it has the most important feature that is missing from all other major competitors: You can directly use RAG within your prompt. Example use case: I need to convert class names from simplified nomenclature to a normal one, and they are stored in 3 different sources: website with documentation, json file with training data, csv file with labels. Only in cursor you can tag specific sources (and even specific places within those sources like fields in json etc.) and give as precise instructions as possible
Forwarded from Knowledge Accumulator
О чём нам говорят результаты O3?
Пару недель назад были опубликованы первые эвалы новой флагманской модельки от OpenAI. Она совершила прорыв на semi-private eval в ARC и в нескольких других бенчмарках про код и математику, Какой вывод мы из этого можем сделать?
Я не знаю всех слухов и деталей, так что, поправьте в комментариях, если не прав. Сконцентируюсь на ARC, так как понимаю про него больше всего.
Прорыв при переходе от O1 к O3 произошёл от трёх изменений:
1) Увеличение ресурсов на Chain of Thought
2) Добавление тренировочных ARC-задач в обучение модели
3) Неизвестные нам изменения между моделями.
Отрывочные данные выглядят так, что ключ к успеху именно в первых двух пунктах.
В RLHF (я её не очень давно разбирал) существует 2 компоненты, отвечающие за её качество. Первая - это Reward Model (RM) - "оценщик" текста, который смотрит на него и предсказывает, несколько он "хорош". Задача оценки сильно проще задачи генерации, и такую модель обучают на больших объёмах человеческой разметки из разных источников.
Итоговая RM является потолком того, что может достичь языковой генератор, поскольку всё, что делают при его обучении - это максимизируют фидбек от RM. При этом, можно предполагать, что сам генератор умеет полностью эмулировать RM при применении к уже сгенерированному ответу.
Что делает Chain of Thought? Грубо говоря, модель генерирует рассуждение и множество вариантов ответов на запрос, а затем сама же выбирает из них финальный. Если бы RLHF работал хорошо и генератор умел генерировать текст, который ему же самому понравится в конце (т.е. и RM), то CoT бы ничего особо не давал.
Таким образом, если увеличение затрат с 20 долларов до 2000 на запрос серьёзно увеличивает профит (как в O3), то у меня для вас плохая новость - RL и тут работает, как обычно.
Тем не менее, не вижу ничего страшного. Для меня важной является принципиальная способность решить задачу, а не потраченный компьют. Если сегодня задачу можно решить за 2к долларов, значит, через 10 лет такой же алгоритм решит её за 100.
Когда тренировочные задачи из ARC добавили в обучающий датасет для O3, то задача для RM сильно упростилась. Бенчмарк вместо вопроса "Умеет ли модель решать принципиально новые задачи?" начинает задавать "Умеет ли модель решать новые задачи, похожие на обучающую выборку?". То, что O3 стала настолько лучше после добавления задач в тренировочный датасет, говорит о двух вещах:
1) Если добавлять принципиально новые задачи в тренировочный датасет, то модель как-то сможет обобщать их решения - это хороший знак
2) Если похожих задач в данных вообще нет, то модель будет работать гораздо хуже - это плохая новость для тех, кто хочет, чтобы модель с 1 пинка решала новую уникальные задачи, тем более, такие, которые в принципе не решены человеком.
Что касается использования на практике, то вряд ли я буду трогать O3 - сомневаюсь в том, что она выдаст что-то настолько интересное, за что можно заплатить 10+ долларов за ответ. Даже O1 с его 1 долларом за ответ мне было жалко дёргать, и я не смог вымолить у неё один нестандартный кусок кода за вечер. С бытовыми задачами генерации текста справлялась даже GPT-4, а писать код на работе помогает Copilot, который на основе O3 будет думать непозволительно долго. Посмотрим, как оно будет выглядеть после релиза.
@knowledge_accumulator
Пару недель назад были опубликованы первые эвалы новой флагманской модельки от OpenAI. Она совершила прорыв на semi-private eval в ARC и в нескольких других бенчмарках про код и математику, Какой вывод мы из этого можем сделать?
Я не знаю всех слухов и деталей, так что, поправьте в комментариях, если не прав. Сконцентируюсь на ARC, так как понимаю про него больше всего.
Прорыв при переходе от O1 к O3 произошёл от трёх изменений:
1) Увеличение ресурсов на Chain of Thought
2) Добавление тренировочных ARC-задач в обучение модели
3) Неизвестные нам изменения между моделями.
Отрывочные данные выглядят так, что ключ к успеху именно в первых двух пунктах.
В RLHF (я её не очень давно разбирал) существует 2 компоненты, отвечающие за её качество. Первая - это Reward Model (RM) - "оценщик" текста, который смотрит на него и предсказывает, несколько он "хорош". Задача оценки сильно проще задачи генерации, и такую модель обучают на больших объёмах человеческой разметки из разных источников.
Итоговая RM является потолком того, что может достичь языковой генератор, поскольку всё, что делают при его обучении - это максимизируют фидбек от RM. При этом, можно предполагать, что сам генератор умеет полностью эмулировать RM при применении к уже сгенерированному ответу.
Что делает Chain of Thought? Грубо говоря, модель генерирует рассуждение и множество вариантов ответов на запрос, а затем сама же выбирает из них финальный. Если бы RLHF работал хорошо и генератор умел генерировать текст, который ему же самому понравится в конце (т.е. и RM), то CoT бы ничего особо не давал.
Таким образом, если увеличение затрат с 20 долларов до 2000 на запрос серьёзно увеличивает профит (как в O3), то у меня для вас плохая новость - RL и тут работает, как обычно.
Тем не менее, не вижу ничего страшного. Для меня важной является принципиальная способность решить задачу, а не потраченный компьют. Если сегодня задачу можно решить за 2к долларов, значит, через 10 лет такой же алгоритм решит её за 100.
Когда тренировочные задачи из ARC добавили в обучающий датасет для O3, то задача для RM сильно упростилась. Бенчмарк вместо вопроса "Умеет ли модель решать принципиально новые задачи?" начинает задавать "Умеет ли модель решать новые задачи, похожие на обучающую выборку?". То, что O3 стала настолько лучше после добавления задач в тренировочный датасет, говорит о двух вещах:
1) Если добавлять принципиально новые задачи в тренировочный датасет, то модель как-то сможет обобщать их решения - это хороший знак
2) Если похожих задач в данных вообще нет, то модель будет работать гораздо хуже - это плохая новость для тех, кто хочет, чтобы модель с 1 пинка решала новую уникальные задачи, тем более, такие, которые в принципе не решены человеком.
Что касается использования на практике, то вряд ли я буду трогать O3 - сомневаюсь в том, что она выдаст что-то настолько интересное, за что можно заплатить 10+ долларов за ответ. Даже O1 с его 1 долларом за ответ мне было жалко дёргать, и я не смог вымолить у неё один нестандартный кусок кода за вечер. С бытовыми задачами генерации текста справлялась даже GPT-4, а писать код на работе помогает Copilot, который на основе O3 будет думать непозволительно долго. Посмотрим, как оно будет выглядеть после релиза.
@knowledge_accumulator
Forwarded from Katser
В посте раскрою одноименный пункт своего доклада на Datafest'е 2024 "Открытые промышленные данные: зачем нужны, почему так мало и где брать?" и поделюсь конкретными примерами.
В докладе подробно рассказал, зачем нужны открытые датасеты и какие проблемы есть с существующими промышленными данными. А вот подробная инструкция, где и как искать датасеты:
· Сайт группы
· Репозиторий института
· Обзорная статья про поиск аномалий в сетевом трафике
· Статья с последнего NIPS'а
· Сайт проекта timeseriesclassification.com
· Awesome Public Industrial Datasets
· Awesome TS anomaly detection
· Industrial ML Datasets
· Public industrial datasets and benchmarks
А еще я создал на гитхабе на основе своих лайков отдельную папку с датасетами.
· Вот пример с датасетами от блогера в нефтегазе.
· Еще один пример — большое число датасетов от компании NASA.
· Да и мой блог — тоже неплохой пример
Конечно, я как всегда буду рад вашим рекомендациям — добавлю в подборку.
Please open Telegram to view this post
VIEW IN TELEGRAM
YouTube
Юрий Кацер | Открытые промышленные данные: зачем нужны, почему так мало и где брать?
Спикер: Юрий Кацер, Рокет Контрол, DS team lead, эксперт по анализу данных и машинному обучению в задачах промышленности, автор тг-канала @datakatser
Полезные ссылки:
https://github.com/YKatser/Industrial-ML
Data Fest 2024: https://ods.ai/events/datafest2024…
Полезные ссылки:
https://github.com/YKatser/Industrial-ML
Data Fest 2024: https://ods.ai/events/datafest2024…
Forwarded from Евгений Козлов пишет про IT (Eugene Kozlov)
Правильный ответ: Результат работы программы зависит от версии и интерпретатора Python.
Дело в том что в старых версиях CPython (до версии 3.10). оператор +=. работал с точки зрения интерпретатора как две операции. И несмотря на наличие GIL и отсутствие параллелизма получался data race и значение счетчика не соответствует ожидаемому.
В CPython 3.10 внесли изменения в интерпретатор и подобный код выдает стабильно правильное значение.
Но если видоизменить пример то все ломается:
Этим квизом я хотел наглядно продемонстрировать, что не всегда наличие GIL защищает от неконсистентности. Использование мьютексов необходимо, чтобы гарантировать корректную работу программы.
Об этом интересном кейсе я писал статью на хабре, там внутри больше экспериментов + ссылка на коммит в интерпретатора CPython + ссылка на репозиторий с кодом, который можно запустить и проверить поведение. Даже в комментариях мы с ребятами придумывали варианты как бы еще сломать код и находили интересные кейсы😊
https://habr.com/ru/articles/764420/
Дело в том что в старых версиях CPython (до версии 3.10). оператор +=. работал с точки зрения интерпретатора как две операции. И несмотря на наличие GIL и отсутствие параллелизма получался data race и значение счетчика не соответствует ожидаемому.
В CPython 3.10 внесли изменения в интерпретатор и подобный код выдает стабильно правильное значение.
Но если видоизменить пример то все ломается:
class CounterWithConversion:
def __init__(self):
self.val = 0
def change(self):
self.val += int(1) # единственное отличие - операция преобразования типа
Этим квизом я хотел наглядно продемонстрировать, что не всегда наличие GIL защищает от неконсистентности. Использование мьютексов необходимо, чтобы гарантировать корректную работу программы.
Об этом интересном кейсе я писал статью на хабре, там внутри больше экспериментов + ссылка на коммит в интерпретатора CPython + ссылка на репозиторий с кодом, который можно запустить и проверить поведение. Даже в комментариях мы с ребятами придумывали варианты как бы еще сломать код и находили интересные кейсы😊
https://habr.com/ru/articles/764420/
Хабр
Многопоточность в Python: очевидное и невероятное
В данной статье я покажу на практическом примере как устроена многопоточность в Python, расскажу про потоки, примитивы синхронизации и о том зачем они нужны. Изначально я планировал что это будет...