🐦 Твиттер выложил код со своими рекомендациями для вкладки For You.

Ссылки
Статья в блоге твиттера
Основной код
Код ML
Аудио обсуждение от твиттера (пока не слушал)

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

Поэтому сразу подборка хайпа, чтобы потом про него не писать:
+ Смотрят на метрики трафика и взаимодействия по авторам во время АБ тестов: Маск, демократы/республиканцы, “power users” – захардкоженный список? Многие захейтили твиттер, но я проблем не вижу, стандартная практика, чтобы нечаянно не уронить трафик некоторым авторам.
UPD:
Кажется, что этот кусок в спешке потерли
за ссылку спасибо @oktai15


+ Бустят авторов с синей галочкой (а с 15 апреля в рекомендациях от не-подписок оставят только их)

+ Много чего не выложили (модели, данные, еще по лицензии нельзя использовать код для коммерческих целей), зато есть описание, код некоторых модулей и сопроводительные README.md

🐦 Обзор.

В твиттере есть две ленты:
Following – хронологическая лента ваших подписок.
For you - умная лента. Про нее мы и будем говорить. Задача этой ленты с одной стороны показывать интересные посты ваших подписок (In-Network) + показывать контент не подписок для exploration (Out-Network). Соотношение 50/50. Такое соотношение звучит, как бейзлайн. Интересно, это действительно самое оптимальное соотношение по АБ или просто забили?

Термины для удобства:
+ Подписки – аккаунты на которые я подписан.
+ Эмбеддинг – вектор (набор чисел), отражающий пост/автора/юзера.

В репозитории есть схема и таблица описание основных модулей. Советую посмотреть.

Общая схема рекомендаций стандартная:
Генерация кандидатов -> Ранжирование -> Пост-обработка эвристиками.

Генерация кандидатов.
В случае твиттов из подписок (In-Network source) -> берем ваши подписки -> генерим фичи уровня юзер – автор -> скорим простым ранкером (модуль называется RealGraph модель GBDT) на вероятность взаимодействия.
Потом берем последние посты топа предсказанных авторов и скорим посты подписок early bird (модель ЛогРег).
Это основной генератор постов из подписок. Отсюда получаем ~750 постов.

Out-network source (посты от не подписок).
1. Социальный граф.
1. Твитты, с которым взаимодействовали мои подписки.
2. Колаборитвная фильтрация. Лайки юзеров, которые лайкают похожие со мной посты.
2. Эмбеддинги.
1. Разреженные эмбеддинги от модели SimClusters. Юзеры и твиты отображаются в пространство “сообществ”. Статью не читал, пока не оч понял как все устроено.
2. Эмбеддинги от модели TwinHW размерность ~200. Обучают на графах юзер-автор, таргет подписка и юзер-твит, таргет взаимодействие. На инференсе смотрим близость юзера к твиту, юзера к авторам. Статья

Ранжирование.
После генерации кандидатов мы получаем ~1,500 твиттов, которые могут быть нам интересны. Дальше работает ранкер (сеть с 48Mln параметров, архитектура: parallel masknet Задача ранкера отсортировать эти твиты используя больше признаков (информации).
Код “heavy ranker”

Интересности.
1. Ранкер обучаем на несколько задач. На выходе сигмоиды, предсказываем вероятность разных действий. Список действий тут.
2. Предсказанные вероятности складываем с весами. Максимальный положительный вес – is_replied_reply_engaged_by_author или вероятность, что автор поста ответит на ваш комментарий на его твит. Наиболее отрицательный вес – is_report_tweet_clicked или что вы пожалуетесь на твит.
3. Фичи для обучения ранкера (информация, на основе которой предсказываются вероятности) – в основном счётчики (ожидаемо). Например сколько раз вы лайкали автора за 50 дней. Есть short-term (30min-3days) и long-term (50 days) статистики. Еще заметил, что в название user_author фичей есть версии так, что можно предположить какие фичи постепенно добавляли.

Эвристики для пост-фильтрации.
После ранжирования применяем эвристики. Стандартные штуки вроде фильтра скрытых вами авторов и соблюдение баланса подписок/неподписок. Интересно, что есть Social Proof – не показывать Out-of-Network твиты с которыми не взаимодействовал никто из ваших подписок.
Еще странно, что для повышения diversity есть только “убрать подряд идущие посты одного автора”. Неужели они по эмбеддингам/топикам не повышают разнообразие в финальном списке?

В дальнейшем думаю чуть более подробно посмотреть на модули тяжелого ранкера и SimClusters/TwinHW. И на модуль Trust and safety Правда самого интересного (анти-бот и анти-спам) там нет и не будет, чтобы не абьюзили.

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 как говорится!

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