Интересное что-то
517 subscribers
2.72K photos
253 videos
139 files
4.52K links
Материалы и мысли, понадерганные отовсюду
Блог: https://t.me/asisakov_channel
Чат: https://t.me/youknowds_chat
Download Telegram
#кейсы

🚨Ребят, рассказываю про кейс, с которым столкнулся🚨.

Вероятнее всего будет интересен Аналитикам из-за работы с 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 секунд


Нам конечно же такая тема не понравилась, так как очень долго. Начал думать🤔, что и как сделать так, чтобы ускорить данный процесс. В голову приходила только идея💡 сохранять данные в файл и использовать команду COPY. И в итоге, нарвался на статью от SQL-EX(ссылка). В общем и целом, там рассматривается 5 способов загрузки данных с помощью библиотеки Pandas в Postgres(если кто не знал 😳 для GreenPlum используется движок Postgresql, поэтому данные варианты подходили и нам). Выбрав самый быстрый способ🐆, оказалось, что в параметр method можно передать свою функцию, где мы будет передавать логику сохранения файла(в нашем случае все сохраняется в памяти) и выполнения команды COPY, и что не мало важно, код был понятным для аналитиков. Код получился следующим:

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
Visualize and understand GPU memory in PyTorch

🤗Link
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 укажите все, а потом уже углубляйтесь по ситуации, считывайте сигналы с интервьюера.

Продолжение следует...
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, и т.д. дополнительные вопросы всегда будут, будьте готовы.


Вот такие ошибки пришли сходу в голову.
Дальше будут ресурсы для подготовки.

Всем удачи на всяких интервью!
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 латенты Z с фичами DINOv2 F. Для этого Z линейно отображают в размерность F получая Z’, после чего:
1️⃣ Поэлементно минимизируют косинусное расстояние между Z’ и F
2️⃣ Минимизируют разницу косинусных расстояний между элементами 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 на рост качества относительно бейзлайнов. Нравится движение в сторону недоизученной темы оптимальных пространств для обучения генеративок
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
Forwarded from Katser
🔎Где искать датасеты?
В посте раскрою одноименный пункт своего доклада на Datafest'е 2024 "Открытые промышленные данные: зачем нужны, почему так мало и где брать?" и поделюсь конкретными примерами.

В докладе подробно рассказал, зачем нужны открытые датасеты и какие проблемы есть с существующими промышленными данными. А вот подробная инструкция, где и как искать датасеты:

🔘Kaggle. Можно искать в соревнованиях, можно искать в разделе "Datasets" по ключевым словам, категориям и тд. Подходят и другие площадки для соревнований, типа drivendata.org.

🔘Специализированные сайты под исследования с ML, типа https://paperswithcode.com и https://huggingface.co/. Хотя промышленных данных я там не встречал, но вот датасетов с временными рядами там немало.

🔘Научные статьи/секции на конференциях/сайты научных групп и институтов. Примеры:
· Сайт группы
· Репозиторий института
· Обзорная статья про поиск аномалий в сетевом трафике
· Статья с последнего NIPS'а
· Сайт проекта timeseriesclassification.com

🔘Обзорные Github репозитории. Вот сразу 4 репозитория с датасетами в промышленности или около:
· Awesome Public Industrial Datasets
· Awesome TS anomaly detection
· Industrial ML Datasets
· Public industrial datasets and benchmarks
А еще я создал на гитхабе на основе своих лайков отдельную папку с датасетами.

🔘datasetsearch.research.google. Специализированный поисковый ресурс, выступает как агрегатор.

🔘Хакатоны. Неоднократно от коллег слышал, что на хакатоны ходят для получения новых или особенно интересных/уникальных данных (да я и сам так делал).

🔘Соревнования на конференциях. Все мы знаем соревнования от AIJourney или NIPS. Редко бывает по теме промышленности, но вот, например, ежегодное соревнование от phm сообщества в рамках конференции. Уже лет 10 проводят соревнования и публикуют данные.

🔘Работа в промышленности. Самый легкий и эффективный способ. Но не факт, что получится использовать внутренние данные компании где-то на стороне, хотя для дипломов/диссертаций/статьей использовать обычно можно.

🔘Блоги, сайты, гитхаб компаний-лидеров, авторов из отрасли:
· Вот пример с датасетами от блогера в нефтегазе.
· Еще один пример — большое число датасетов от компании NASA.
· Да и мой блог — тоже неплохой пример🙂.

Конечно, я как всегда буду рад вашим рекомендациям — добавлю в подборку.
Please open Telegram to view this post
VIEW IN TELEGRAM
Forwarded from Евгений Козлов пишет про IT (Eugene Kozlov)
Правильный ответ: Результат работы программы зависит от версии и интерпретатора Python.

Дело в том что в старых версиях 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/