Всем привет! Меня зовут Голубев Александр, я работаю в сфере Data Science, а именно Machine Learning/Deep Learning. За свою карьеру я успел поработать как инженером, так и лидом; занимался проектами в MedTech, банкинге, E-commerce, SaaS E-commerce, даже немного побыл в академии с написанием статей и сейчас уже хорошо осознаю, чем мне интересно заниматься, а чем нет.

В последнее время потребляемую информацию/мысли/опыт все больше и больше хочется не только заносить в базу знаний, но и делиться ей с другими. Этот ТГ канал — попытка выносить что-то интересное на обсуждение или же делиться полезной информацией с читателями. Сейчас я регулярно выкладываю посты в своем LinkedIn, но есть ощущение, что в телеграме можно выстроить более уютную атмосферу.

В основном я буду писать про машинное обучение: разборы статей, проекты из опыта, интересные и сложные задачи, которые приходилось решать, частые ошибки, мысли по будущему ML и т.д. В силу текущей работы в основном фокус сейчас сконцентрирован на NLP, LLM, Retrieval, но будет и много чего еще. Ну и конечно буду писать просто про то, что мне интересно вне работы: спорт, видеоигры, книги и фильмы, шахматы, тайм-менеджмент и лайфхаки к продуктивности, путешествия, и прочее.

Добро пожаловать на борт!

Немного инфы про то, какие материалы у меня для вас уже есть:

1. Мой LinkedIn. Несколько раз в месяц пишу туда разборы статей, которые мне понравились, плюс иногда что-то от себя. Добавляйтесь в контакты 🙂
2. Блогпост на хабре про модель Prod2Vec. Модель, которую я делал в Озоне, чтобы смешивать три сущности (картинка, название, атрибуты) товара в один вектор.
3. Выступление на митапе Aliexpress, где я как раз рассказывал про Prod2Vec.
4. Блогпост на хабре про Real-time matching. Более инженерная статья про наш длительный переход из оффлайн подхода в онлайн в задаче матчинга товаров (тоже в Озоне).
5. Статья со времен работы в лаборатории Huawei, где я занимался обучением с подкреплением. Мы изучали on-policy алгоритмы в разрезе снижения дисперсии и даже придумали свой. Кстати, PPO, который в основном используется в RLHF, — тоже on-policy.
6. Выступление на Datafest 2023 с воркшопом по LLM + RLHF.
7. Блогпост на хабре про LLM агентов.
8. Блогпост от нашей команды в Nebius, где мы рассказываем про критиков (Verifiers) для SWE-агентов

Список будет пополняться.

Пока писал пост на тему “Должен ли ML инженер знать, как работают потоки и процессы в питоне”, решил посмотреть на статистику LinkedIn постов за все время (регулярно я начал выкладывать туда 5 месяцев назад). Для сравнения, в среднем каждый пост набирает сейчас ~2-4к просмотров, но стоило добавить в название Interview questions on transformers, и это число выросло до …50к. Итак:

1. Interview questions on transformers.
2. Обзор на статью про архитектуру Retentive Network.
3. Top 10 questions from ML interviews.

Вчера вышла интересная статья YaRN про еще один способ увеличения контекста в LLM (точнее в тех моделях, которые используют метод RoPE для позиционного кодирования, например, LLaMa-2) до 64k, 128k токенов. Направление сейчас популярное, ведь такая штука позволяет поместить в контекст среднюю книгу или же иметь очень длинную историю сообщений. В статье графики выглядят впечатляюще и самое крутое, что можно уже брать модельки с hugging face.

В отличие от предыдущих работ, где модифицировали только RoPE (Rotary Positional Encodings, по сути это поворот вектора в пространстве на некоторый угол, который зависит от позиции), авторы заметили, что изменения в позиционном кодировании сильно влияют на распределение attention скоров после софтмакса. Поэтому помимо прочего добавили температуру, которой можно это распределение контролировать. Причем сделано это по-хитрому, чтобы не менять код самого attention и соответственно использовать все существующие оптимизации. Как и другие методы, YaRN требует дообучения на данных с длинным контекстом, хотя и в небольшом количестве (~0.1% от данных претрейна). Единственный вопрос — сколько памяти требуется для инференса таких моделек.

Должен ли ML инженер понимать принцип работы процессов/потоков в питоне?

Очень часто в обсуждениях вопросов с собеседования ML инженеров слышу споры о том, нужно ли спрашивать про принцип работы питона, в частности про потоки/процессы/GIL и прочее. Разумеется, это зависит от задач, которыми предстоит заниматься в команде. Но вот вам пример, который встречался мне несколько раз в разных компаниях, где за 10 минут можно было получить кратный прирост в скорости:

Есть пайплайн на pyspark, который скачивает картинки с помощью user-defined function (udf). udf применяется построчно и параллельность тут достигается только за счет нескольких воркеров.

Теперь меняем udf на pandas_udf (обработка идет сразу чанками, pd.Series) и внутри уже скачиваем картинки потоками. Несколько измененных строчек кода и пайплайн работает в ~5-10 раз быстрее.

Пайплайн на спарке можно заменить и на обычный питон скрипт, смысл останется тем же.

Совсем недавно Georgi Gerganov, создатель ggml, показал инференс 34B Llama2 со скоростью >20 токенов в секунду на M2 ultra (а потом и инференс 70B с 15 токенов в секунду). Andrej Karpathy написал в твиттере комментарий, объясняя, за счет чего это работает, советую почитать. Там все те же аспекты, связанные с flops/memory boundness, о которых я писал ранее здесь. Однако, применяется еще один очень интересный трюк - использование второй, быстрой draft модели для генерации предварительной последовательности-кандидата. В процессе инференса основной модели эта последовательность может быть обработана в батчевом режиме, что позволяет пропускать токены, совпадающие с прогнозами draft модели. Этот метод оказывается эффективным по следующим причинам:

1. Обработка батча занимает почти столько же времени, сколько и обработка одного токена (привет, memory bandwidth).
2. Большая часть токенов, предсказанных draft моделью, оказывается верной, так как они легко угадываемы (acceptance rate может быть 80-100%).
3. Если прогнозы draft модели и основной модели различаются, скорость инференса возвращается к исходной.

Есть модели/статьи/архитектуры, в которых особенно интересно разбираться и думать, как они смогли перевернуть сферу применения. Одной из таких моделей является AlphaFold2, которая предсказывает 3D структура белка по последовательности аминокислот. Важно это потому, что структура белка практически полностью определяет его функцию, а функции белков в нашем организме сосчитать сложно. При этом экспериментально процесс очень долгий, дорогой и нестабильный.

Наконец-то нашел время, чтобы хорошенько разобраться с этой моделью; из материалов помимо основной статьи рекомендую лекцию от исследователя из DeepMind и классный блогпост. Блогпост рекомендую прочитать самим, но постарался выделить какие-то главные интересные моменты с точки зрения ML:

1. На вход мы подаем две сущности:
a. Pair representation - это тензор размера N_seq x N_seq x n_features, где N_seq - размер последовательности аминокислот, а features - попарные фичи о взаимодействии аминокислот друг с другом, которые мы можем посчитать заранее.
b. MSA (multi aligned sequence) - это батч разных последовательностей, где первая последовательность - исходная, а остальные найдены из некоторой базы с помощью алгоритма поиска соседей. Мотивация здесь такая, что похожие последовательности могут дать полезную информацию о нашей текущей.
2. Энкодер модели называется Evoformer, он обрабатывает эти два инпута, передавая информацию от одного к другому. Делается это либо через attention, либо через операцию векторного произведения. В MSA авторы используют два attention: построчный (внутри последовательности) и поколоночный (между последовательностями), а вот в pair representation - triangle attention. Triangle attention - это попытка внести в модель некоторый inductive bias о том, что если 3 точки соединены в пространстве, то должно выполняться неравенство треугольника. Поэтому attention выполняется там по всем парам, которые могут быть соединены в такие структуры.
3. Вторая часть, назовем ее декодер, берет представления Evoformer и предсказывает уже необходимые координаты аминокислот в пространстве. Там очень много нюансов и эвристик, но тоже есть свой интересный attention слой - IPA, который инвариантен относительно перемещений и поворотов в пространстве.
4. Общий лосс для модели - взвешенная сумма лоссов из разных ее частей: там и финальный предикт (насколько мы отклоняемся от правильной структуры), и masked MSA (а-ля MLM, маскируем аминокислоты в последовательности и пытаемся их предсказать), и distogramm loss, где смотрим на попарные расстояния.
5. Во время обучения использовались техники дистилляции, а именно Noisy Student. Это связано с тем, что известных структур белков для обучения не так уж и много (в связи с тем, что их неимоверно трудно получить экспериментальным путем) и хочется данные для трейна как-то увеличивать.

Много нюансов тут понятно не покрыто, так что, если интересно, посмотрите приложенные материалы.