4 месяца назад пересел с pandas на polars.

Короткий итог: с polars пайплайн на старом наборе признаков стал быстрее раз в 6, а пик утилизации памяти меньше в 3 раза. Правда, я не сравнивал с Pandas 2.0, где завезли поддержку arrow.

Pandas – библиотека для анализа данных и работы с табличными данными.
Polars – более молодой аналог pandas для тех же целей

Pandas я использовал для EDA (посмотреть по быстрому какие-то статистики, сделать аналитику, которую муторно считать запросами в кликхаусе или бд) и для того, чтобы считать фичи в фоне на паре табличек. И если с EDA все норм, то считать фичи было не очень приятно.

Пайплайн для фичей выглядит так: подтянуть пару таблиц из MariaDB -> поджойнить/сгруппировать и собрать датафрейм -> посчитать разные счетчики, аггрегации, признаки (например, отношения лайков к просмотрам юзера у конкретного автора за последние 10 суток).

Количество строк в итоговом датафрейме 1-10 миллионов. Потом это все используется, чтобы обучать разные бустинги. Основной нюанс, операции нужно считать rolling с определенным окном. То есть на момент каждого события(каждой строки) нужно взять предыдущие события этой группы (например, юзера) за 1/7/30/..дней и посчитать среднее или другую статистику.

Почему polars оказался экономнее и быстрее:

+ Polars написан на Rust и оптимизирован под параллельные вычисления (когда есть такая возможность).

+ Polars использует arrow. Это такой формат хранения данных в памяти (RAM), который позволяет хранить объект не в одном участке памяти, а кусками в нескольких. А еще arrow хранит данные в колоночном формате.

+ Polars использует Lazy evaluations: (это когда операция выполняется в момент, когда нужен её результат, а не когда она объявлена (eager evaluation). Поэтому большие пайплайны операций может выполнить оптимальнее.

+ Streaming evaluation. Если вдруг датасет не помещается в оперативку, можно стримить кусками и обрабатывать их.

Нюансы и советы:
1. Синтаксис polars не сильно отличается от pandas, за вечер-два можно освоиться.
2. Если вдруг лень смотреть, как это пишется на polars, всегда можно вызвать метод .to_pandas().
3. Для коммуникаций с бд в polars использует библиотеку connector-x. Из плюсов – быстрая, из минусов нет готовой версии для докера под m1 и нельзя задавать схему датафрейма, когда читаешь из базы
4. Для хранения данных на диске теперь использую только parquet. (Быстрее i/o операции и файл легче, чем csv)

Ссылки
1. Если хотите попробовать polars, советую полистать официальный гайд
2. Всякие тесты и сравнение с другими либами от @train_test_split
3. Еще нашел такое сравнение polars с Pandas 2.0 (где используется arrow)

Как быстро и почти безболезненно вкатиться на Go вдобавок к питону

Если бы встретил такой пост год назад – сэкономил бы N часов дебаггинга граблей, которые сам же и раскидал. Сейчас, Time screen говорит, что за неделю на go пишу столько же времени, сколько и на питоне (не ноль, если что).

На го писал код для таких задач:
+ фичи в монолитный бэк с основной логикой (на go получается быстрый и легкий веб сервер), 
+ в отдельный сервис для процессинга признаков и статистик 
+ блендер, которые собирает рекомендации генераторов, комбинирует их в финале и делает пост-ранкинг.

Как начал писать код на го. 

1. Пошел в документацию и прошел короткий go dev tour. Там на примерах познакомился с базовым синтаксисом. 

2. Начал писать несложный код и посматривал в примеры вот тут  и в документацию, когда писал код. Например, в gorm, который отвечает за работу с базой. 

3. Пролистал effective go, но там часть инфы давно не обновлялась. 

4. Здорово помогал copilot, который позволял не запоминая весь синтаксис, писать код целыми блоками. 

Если бы вкатывался сейчас, то прошел бы этот курс Microsoft

🐞Возможные ошибки при переходе с питона.

Когда после питона начнете писать на го, есть соблазн ожидать похожего поведения, когда это не так.

Вот, 3 примера кода, которые на питоне и го выглядят одинаково, но ведут себя по разному. Взял примеры с array (списки на питоне) и map (словари), так как чаще всего используются эти структуры данных.

Написал примеры кода на го в playground, а в комментариях указал, что бы получилось в питоне. Поэтому советую открыть ссылку с кодом в соседней вкладке и смотреть с комментариями отсюда.

1. Слайсы в питоне – это копия участка исходного списка. Поэтому изменяя его, на исходный список вы не влияете. На го же, слайс – это участок исходного списка, поэтому если хотите получить его копию, нужно копировать явным образом. 

2. В го по умолчанию переменные передаются в метод “pass by value” (в функцию передается копия значения переменной), а в питоне “pass by referenece” (передается указатель на участок памяти со значением). Это значит, что в питоне вы будете менять список, который передали в функцию, а на го будете работать с копией. Однако, на го тоже можно сделать  “pass by referenece”, передав адрес переменной. Посмотрите в код, там понятнее.  

3. Переменные в го инициализируются нулевыми значениями. А если вы попробуете получить элемент, которого нет, из мапы – получите нулевое значение этого типа (считайте, что map на го – это defaultdict из питона). Поэтому map в го возвращает еще boolean значение есть ли такой ключ в словаре. Вот хорошая статья о том, как устроен hashmap на го. 

Еще немного ссылок.
+ Большой список ссылок по го на реддите.
+ Слак по Go на 100к людей, где даже могут отревьюить код. Называется, кстати, gophers - почти как llm от deepmind.

P.S. Поделитесь пожалуйста лекциями или статьями по устройству питона и го? Про устройство GC, GIL, scheduler в языках. И про разные штуки типа convoy effect. Тут, кстати, хорошо расписано про GIL и convoy effect на питоне.

Недавно подумал, что было бы прикольно сделать доклад «50 оттенков серого» про АБ тесты, которые не прокрасились.

Но в итоге сделал доклад о рекомендациях «50 оттенков рекомендаций»,
который завтра удаленно расскажу на конференции techtrain

Будет про то, как с нуля строил рекомендации. Теории не будет, подразумевается, что слушатели знакомы с ML и рек сис. Зато будет о том, как принимали решения, что делали, на какие грабли наступали и что сработало. А в конце, топ советов себе в прошлое.

Запись будет, когда появится – добавлю тут ссылку.

Завел отдельный аккаунт в телеге, чтобы не мешали каналы, сториз и большие чаты. 

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

Месяца три назад завел еще один аккаунт в тг чисто для чтения каналов. Так, они не мешают в личном, а переключение между аккаунтами в тг удобное – вечером/утром захожу сразу полистать посты пачкой.

Рецепт, как перекинуть читаемые каналы на новый аккаунт.

1. Берем новую симку, либо выпускаем виртуальный номер у своего оператора. Есть еще сервисы вроде sms-activate, но там потом аккаунт перейдет новому юзеру, поэтому не советую. 
2. Регаем новый аккаунт в тг на этот номер.
3. Создаем папку на личном аккаунте (настройки -> папки с чатами-> создать папку) и закидываем каналы, которые писали в последние пару недель.
4. Делимся этой папкой и кидаем в сообщениях своему второму аккаунту. Присоединяемся во все разом. 
5. Удаляем папку и разом выходим из всех каналов на личном аккаунте. Главное убедиться, что присоединились на втором.

Привет!

Давно сюда не писал, решил поделиться, как у меня дела и что нового произошло!

> Вот тут мое интро, чтобы узнать, что было в прошлых сериях.

> Осенью того года менял работу. Прошел 40 собеседований за полтора месяца. (Воронка была такая: откликнулся на ~100 позиций -> ~15 созвон с hr (почти все через рефералов) -> 12 мест, где прошел собесы -> 8 офферов). Заметки с тех времен остались, опубликую статистики и как готовился. 

> Последние полгода занимаюсь llm. C ноября 23-го года начал работать в качестве лида команды данных для пре-трейна в Nebius. Мы с командой собираем и обрабатываем данные, чтобы за такое же количество компьюта получить модель лучше. Карпатый два года назад лаконично выразил мысль. Расскажу, что узнал на практике, как этот самый Large, clean, diverse data получить 

> Прошлой осенью закрыл гештальт. Хотел порассказывать про здоровье и технологии, а тут red barn позвали записать подкаст. Недолго думая, собрали материала на 12 выпусков и записали сезон.

> После трипов по Азии в течение прошлого года (для того, чтобы удаленно работать, понравился Вьетнам, по впечатлениям, понравился Сеул), засели с девушкой в Белграде. Если кто тут, пишите, сгоняем попить кофе!

У hugging face вышел качественный тех репорт о том, как они собирали свой датасет fineweb. Это набор дампов common-crawl(архив страниц из интернета), который почистили и превратили в 15T токенов на английском.

Почему круто. Common-crawl – это основной источник данных для претрейна LLM, если ты не open ai или antropic с собственными краулерами и парсерами. Его все по разному обрабывают или используют его производные. Обычно эти производные датасеты получены путем применения простых эваристик и максимум какой-то маленькой LM, обученной на википедии.

Но репортов с экспериментами на данных на таком масштабе с подробным описанием почти нет. А тут ребята 100k+ h100 gpu часов потратили на все и подробно описали.  

Еще они выложили сабсет образовательных документов из кроула. Такой масштаб фильтрации классификаторами в open-source еще никто не выкладывал. И это как раз тот датасет, которым никто не делится (ни лама, ни мистраль, ни китайцы вроде qwen), но который все делают.

Все в статье, это по сути ровно то, чем моя команда занимается.
Тут и про экстракцию кроула, и про фильтрацию, и про дедупликацию, и про классификаторы.

P.S. Если на этом посте наберется хотя бы 1 огонек – напишу разбор репорта с комментариями.

Написал разбор тех репорта про FineWeb, с чайком зайдет лучше, чем без 🫖

https://telegra.ph/Razbor-reporta-FineWeb-06-12

Привет!

Ищу Senior Software Engineer (python) к себе в команду данных в LLM.

Вилка: 7-10k eur на руки в месяц (есть поправка на локации)
Локация: релокация в один из офисов (Белград, Амстердам, Лондон), либо удаленка

Описание
Nebius – это ai-centric cloud (много gpu, которые сдаются в аренду). LLM команда делает эксперименты, используя часть gpu.

Наша команда данных делает эксперименты с данными, претрейном, continual preptrain. Короче мы обрабатываем очень много текстовых данных и смотрим, что улучшает модель и ее определенные способности.

Что нужно делать на этой позиции
Нужно будет развивать наш фреймворк для обработки данных. Если грубо, есть большая куча данных (в сумме – это петабайты, по отдельности до ~100TB). Нужно дизайнить и реализовывать эффективную логику обработки на нашем фреймворке поверх yt (платформа для распределенной обработки данных).

Из недавних задач:
> фильтр Блума для быстрой фильтрации
> топологическая сортировка и работа с графами для сортировки зависимостей в коде
> затащить и подобрать оптимальные параметры для инференса энкодерных моделей (в yt есть gpu ноды для подобных задач).

Основное требование
Уметь хорошо писать код и дизайнить логику (фреймворк на питоне). Уметь в LLM и ML необязательно, но будет плюсом, а что нужно – подскажем в процессе.
Формальное описание вакансии можно посмотреть тут

Список собесов (после знакомства с hr)
1. Полчаса про опыт + несложная алго задача
2. Coding interview – реализовать класс с заданной функциональностью
3. Алго-секция
4. Систем дизайн
5. Финал

По всем вопросам + кидать резюме можно мне в @ibragim_bad

P.S. На сайте ошибка – удаленка есть

По поводу вчерашней вакансии.
Много резюме скинули на MLE (Machine Learning Engineer). Поэтому подчеркну, что в команду данных – это именно SWE (Software Engineer) вакансия. То есть обучения моделей на этой позиции нет и трек собеседований тоже SWE.

Но если вы хотите именно на MLE/LLM позицию, то такие вакансии тоже есть в соседние команды + появятся еще. Пример такой вакансии.
Вилка и локации такие же как на SWE.

Трек собеседований после HR такой:
1. Литкод задача + разговор про ML.
2. Алго секция.
3. Секция про NLP и LLM.
4. Финал.

Можете податься через вакансии на сайте, либо через вчерашнюю вакансию на SWE. Но в пометке укажите, что хотите на трек MLE.

Позавчера вернулся с NeurIPS, мне понравилось!

Я рассказывал о нашем агенте для решения issues в репозиториях. На базе только открытых моделей получилось выбить 40.6% на swe-bench verified, результат засабмитили месяц назад. Я построил выступление по нашему посту, который можно прочитать тут + добавил инфы о том, как собирали данные. Короткое описание блог поста можно прочитать у Саши, он делал критика для process и outcome supervision. А про данные: скоро выложим еще один блог пост и зарелизим сами данные, которые собрали, так что stay tuned как говорится!

Ниже прикрепляю небольшую пачку фото и видео материалов с нипса.

Мы зарелизили первый датасет для software engineering agents! 🤖

В последние несколько месяцев наша команда активно работала над software engineering агентами. Я с частью команды отвечал за данные и эксперименты с ними. Сегодня мы выложили данные, которые собрали. Напомню, что на этих данных мы обучили модели (Llama 3.1, Qwen 2.5), которыми набрали 40.6% на SWE-Bench Verified.

Про сами данные:
Используя доработанную напильником методологию SWE-Bench мы собрали 6.4k пар PR+issue из 2k репозиториев на питоне. Потом сгенерировали 80к траекторий, где агент на базе SWE-agent, используя наши зафайнтюненные модели пытается решить эти issues. В каждой траектории есть инфа про то, решил ли итоговый патч issue, какая была модель, статус окончания работы агента и логи evaluation.

Данные выложили на HuggingFace:
6.4k issue-PR pairs: nebius/SWE-bench-extra
80k траекторий: nebius/SWE-agent-trajectories

Блогпост с подробным описанием того, как собирали данные можно прочитать тут