Опасный pickle в python

На новогодних выходных понадобилось глубоко разобраться с форматом pickle (зачем - напишу позже).

Что такое pickle формат? Это очень популярный формат сериализации/десериализации в python, потому что с помощью специальной библиотеки можно легко сохранить любой python объект в файл, или передать его по сети.

Формат очень широко используется в машинном обучении, выученные модели в основном сохраняются с помощью этого формата.

В pytorch (популярная библиотека для обучения нейросетей) pickle тоже используется. Чуть сложнее, чем напрямую, там pickle данные лежат в zip-архиве (тоже позже напишу детальнее), но тоже лежат и тоже считываются.

По факту формат сериализации/десериализации pickle - это последовательность команд для так называемой pickle-машины. Машина умеет не так много, пара-тройка десятков команд. В машине есть стек и память. Большая часть команд почти ничего не делают, могут положить на верхушку стека, убрать с верхушки стека, сохранить в память, считать из памяти и тд. Но часть команд могут конструировать python объекты и исполнять python функции.

Низкоуровнево формат устроен следующим образом: сначала идет один байт команды для машины, затем в зависимости от команды идут аргументы команды.

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

Однако я не догадывался на сколько это легко. Я думал, что придется как-то ручками сооружать какой-то набор байт, но все оказалось еще проще.

В pickle если сериализовать объект, который имеет специальный reduce метод, то можно буквально дать команду pickle машине исполнить произвольную функцию.

Давайте напишем код:

import os

import pickle

class Exploit:
    def __reduce__(self):
        cmd = ("echo 'Hello, world!'")
        return os.system, (cmd,)

with open("exploit.pkl", "wb") as file:
    e = Exploit()
    pickle.dump(e, file)

В этом коде пробуем заставить pickle-машину при десериализации выполнить shell команду, которая выводит «Hello, world!». Очевидно, можно было бы подставить и другую команду сюда. Например, команду, которая удалит или зашифрует ваши важные данные. Или еще что-то плохое.

Попробуем десериализовать этот файл:

import pickle

with open("exploit.pkl", "rb") as file:
    e = pickle.load(file)

➜ python3 exploit_load.py
Hello, world!

Все получилось, команда вызывалась.

Какой вывод можно сделать? Не используйте pickle для того, чтобы десериализовать данные из непроверенных источников. Ровно об этом, кстати, предупреждает и документация pickle. Но, например, если вы используете pytorch, то руками вы pickle даже не вызываете, все происходит под капотом.

UPD. Обнаружил открытый issue на github в pytorch по этой проблеме: https://github.com/pytorch/pytorch/issues/52596. Он пока открыт, но, возможо, в будущем эту проблему в pytorch исправят, посмотрим-подождем. Пока нужно использовать параметр weights_only=True, тогда загрузка будет безопаснее.

safetensors

safetensors - формат, который придумали в huggingface для того, чтобы сохранять ML-модели на диск.

Формат устроен так, что сначала идет размер метаданных, затем метаданные (сериализованый json), затем последовательность тензоров.

Забавно, что описан он «ML Safer For All». В чем же заключается Safer? В том, что не исполняется произвольный python-код во время чтения модели. Что, конечно, хорошо, но это не является каким-то плюсом, а это просто нормально для форматов сериализации и десериализации! Если нужно сохранить данные, а не код, то так и должно быть.

Забавно, что библиотека написана на rust. Это оказалось для меня неожиданно, ведь целевая платформа - python, а в таких случаях если нужен нативный код, то его пишут обычно на C/C++ и делают биндинги.

Из картинки непонятно, что внутри «offsets»: [BEGIN, END] (см. картинку). Кстати, я когда глянул на картинку, то подумал, что это странная зависимость начала сериализации от ее конца. Нужно ведь знать размер сериализованных метаданных (которые еще не сериализованы!), чтобы корректно выставить офсеты тензоров. Я даже полез почитать код, чтобы посмотреть на то, как это делают. В коде увидел, что оффсеты не от начала файла, а от начала последовательности сериализованных тензоров (то есть после метаданных). Это уже сильно логичнее. В доке к python библиотеке это не написано, но есть на github в README.

Кстати, тензора выровнены по 8 байт. Метаданные специально для этого добиваются до размера, кратного 8. Что это дает? Это в теории дает более быстрый доступ, если оперировать тензорами без перекладывания их в память, а напрямую через mmap. mmap позволяет работать с файлом на диске, как с непрерывным блоком байт в памяти (ОС сама следит за тем как куски файла подгружаются и выгружаются).

Что можно сказать? Формат для моделей точно лучше, чем pickle!

Может ли руководитель писать код?

Я сам прошел через этот вопрос, а так же видел многих, кто тоже через него прошел и по дороге настрадался.

Сначала нужно понять, а должен ли руководитель писать код?

Я считаю, что тимлиду небольшой команды из 5-7 человек код писать нужно обязательно. Руководителю 8-20 человек код писать можно, но не всегда и только при условии, что прямых подчиненых не больше 4-6. Если же команда больше, то код писать скорее нельзя, потому что это время можно потратить уже значительно полезнее для команды (исключения возможны, но очень редки). Нельзя - это я имею в виду, что нельзя брать на себя какие-то важные или тем более срочные задачи. Изредка подкоммичивать в конфиги, рефакторить, делать что-то полезное раз в месяц-два-три - это пожалуйста, но не на постоянной основе. Даже полезно! Но все же писать много кода - работа разработчика, у руководителя большой команды совсем другая работа.

Хорошо, кому-то нужно, но в чем их проблема?

Во время процесса написания кода нужна довольно высокая концентрация. Помимо концентрации в мозг должен быть загружен контекст, который требуется для того, чтобы написать код. Контекст разного размера бывает, но как правило это как минимум несколько файлов, несколько классов/функций, отлаженный сетап проверки изменений (отладочный стенд), конфигурация систем, связанных с этим кодом и тд и тп.

У руководителя есть много обязанностей, которые требуют общения с другими людьми, то есть появляется больше встреч в календаре. Со своими директ-репортами, со своими смежниками, по проектам и тд и тп.

Думаю одна из первых вещей, с которыми сталкивается начинающий руководитель, который пытается и дальше эффективно писать код - это удивление от невозможности его писать между встречами. Вроде и день не полностью занят, 3-4 часа встреч всего, есть еще куча времени между ними. Но как правило код написать в такой конфигурации не удается.

Люди расстраиваются, думают, что с ними что-то не так, что они обленились, что они растеряли знания и потеряли всю экспертизу. Но ситуация частая. Просто в таком режиме практически невозможно достаточно сконцентрироваться и загрузить контекст в мозг.

Так как руководителю писать код эффективно?

Нужно сделать так, чтобы время для кода появилось. И именно непрерывное время. Я рекомендую выделить себе минимум 2 полных дня без встреч (можно оставить одну встречу утром). Тогда все точно получится, ведь уже получалось до новых обязанностей!

P.S. Руководителю разработки любого уровня будет полезно периодически программировать «для себя», чтобы не отрываться от реальности.

Не бойтесь тыркать

В компаниях бывают случаи, когда нужно, чтобы какой-то руководитель сотен (иногда тысяч!) людей что-то сделал. Например, согласовал открытие вакансии, найм, командировку, конференцию и т.д. Я уже много раз замечал, что люди стесняются в таких случаях переходить на быстрые каналы коммуникации. Стесняются написать в мессенджер, например.

Почему такой руководитель тормозит?

Каждый день такого руководителя состоит из десятков переключений контекста. И при каждом переключении нужно быстро погрузиться в контекст. Источников информации, которые приводят к переключению - огромное количество. Это как минимум встречи, письма, трекер, мессенджер, коридорные разговоры. Такому руководителю не всегда удается быстро добраться до всего.

Что делать?

Если что-то требуется и срочно, то такой руководитель будет только рад, если ему напишут про это в мессенджер или позвонят (звонить стоит только если реакция нужна в течении минут).

Я очень стараюсь отвечать быстро, одна из самых приятных вещей, которые мне когда-либо говорили - это «ты отвечаешь быстрее 99% остальных», но я все равно некоторые вещи делаю медленно. Особенно, если эти вещи не в быстрых каналах коммуникации. Например, в трекере, потому что роботы, пишущие отбивки в тикете на каждый чих, дискредетируют этот канал информации довольно быстро с ростом количества смен контекста.

P.S. Заголовок поста - цитата одного руководителя нескольких тысяч людей в Яндексе. Он написал пост на внутреннем ресурсе, где сказал, что нужно писать ему в мессенджер, если требуется его реакция, а он не реагирует. Еще цитата из этого поста: «Моя позиция - бюрократия зло. Согласования в несколько месяцев - это абсолютное зло.»

The hard things about hard things

В заголовке название книги Бена Хоровица.

Долго не добирался до этой книги, потому что она про то, как быть CEO, а не CTO. И очень зря, потому что в книге много мыслей про то, как быть хорошим руководителем, не важно с каким названием. Поэтому рекомендую.

Сегодня наткнулся в книге на мысль про взаимотношения между руководителем и сотрудником, до которой когда-то дошел сам, а потом стал неоднократно сталкиваться с подтверждениями от других людей.

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

В книге приводится в пример ситуация:

Если приятель рассказывает вам забавную историю, то с вашей стороны будет странно оценивать его исполнительское мастерство. Неуместно будет заявить ему «Ты недостаточно увлекательно изложил ее начало, да и совершенно испортил кульминационный момент. Предлагаю пойти тебе и поработать над исполением дополнительно и представить мне эту историю завтра.»

Но в работе так сказать будет не просто не неуместно, руководитель обязан это сказать, если видит проблему в рассказе сотрудника. Рассказ — аналогия.

Не всем удается перестроиться, но это очень важно. Причем в обе стороны. В хороших компаниях (люблю за это Яндекс!) необходимо и так же, чтобы сотрудник говорил руководителю, что руководитель делает что-то не так. Иначе компания превратится в болото.

Ключевое в этом следующее — вы делаете общее дело. Ради этого дела вы собрались в это время и в этом месте, нужно про это помнить.

Более того, все крутые люди, которых я знаю, рады слышать не только позитивную обратную связь, но и негативную (даже если в моменте раздражаются от этого). Потому что негативная обратная связь помогает развиваться.

Значит ли это, что руководитель не должен заботиться о людях и должен выжимать из людей все соки? Нет, не значит. Не редко даже все обстоит ровно наоборот. Баланс найти тяжело, но необходимо.

https://openai.com/sora

OpenAI релизнули text2video (пишешь текст, по нему генерируется видео).

Обычно новости не публикую, но тут демки невероятные, ничего даже близкого я еще не видел.

Например, генерация трейлера к фильму про космические путешествия!

Prompt: A movie trailer featuring the adventures of the 30 year old space man wearing a red wool knitted motorcycle helmet, blue sky, salt desert, cinematic style, shot on 35mm film, vivid colors. more

Дилемма инноватора

Сегодняшний день — хороший пример дилеммы инноватора. Вот две новости:

1. https://blog.google/technology/ai/google-gemini-next-generation-model-february-2024

Google Gemini 1.5. Еще один чатбот, но с улучшенными метриками. Токенов побольше, лучше объяснение и тд и тп. Но все это мы уже видели не раз!

2. https://openai.com/sora

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

В чем дилемма?

На столько большим компаниям, как google, сложно по настоящему вкладываться в безумные инновации. Это огромная ставка без каких бы то ни было гарантий. Эта ставка практически обречена раствориться в текущих более понятных целях и в текущей организационной структуре.

Если продукт устоявшийся, то всегда можно улучшать понятные показатели продукта. Это безопасно и за это понятно как получить премии. Но прорывные инновации так сделать не получится.

Однако может появиться в 10 раз более крутой продукт, который появился из-за рискованной инвестиции в инновацию, что приведет к победе нового продукта над старым.

Руководителям очень важно помнить про эту дилемму и явным образом периодически идти на контролируемый риск.

Кулстори про Андрея Карпаты (ex исследователь в OpenAI)

Куча data science телеграм каналов сейчас постят/репостят про то, что Андрей выпустил лекцию по BPE (https://www.youtube.com/watch?v=zduSFxRajkE). Это алгоритм преобразования текста в набор чисел, чтобы было что подавать на вход в LLM. Информации про BPE вагон и маленькая тележка на самом деле. На русском языке тоже полно информации, можно поискать в Яндексе (!). Мой пост не об этом.

Из олимпиадного прошлого у меня сложилось твердое мнение, что невозможно досконально понять алгоритм, не запрограммировав его. Потому что теоретизировать можно долго, но если код не работает, то он не работает и все тут.

Поэтому на новогодних каникулах я засел программировать инференс LLM. Без какой-то цели, просто for fun. Я тогда не дописал инференс до рабочего состояния, потому что слишком долго парсил pickle из rust (rust выбрал тоже просто for fun). В итоге у меня в канале родился пост про то, что сложно писать код будучи руководителем.

Однако в какой-то момент мне потребовалось тогда взять другой готовый инференс, погрузиться в него и залоггировать числа по слоям нейросети, чтобы сверять реализацию.

Очень многие знают про llama.cpp (https://github.com/ggerganov/llama.cpp), но код там абсолютно дикий. Хотя и написано якобы на C++, но по факту это почти чистый C со всеми его проблемами. Поэтому я решил поискать еще.

Иии… я наткнулся тогда еще на llama2.c - https://github.com/karpathy/llama2.c

Это реализация инференса и дообучения LLM модели llama2 от Андрея Карпаты (на уже совсем чистом C). Там он пишет, что запрограммировал это for fun и для образовательных целей. Прям так и пишет «this repo started recently as a fun weekend project». Weekend project! Впрочем, Андрей пишет, что у него тогда была его реализация GPT-2 на C (называется nanoGPT), которую он взял и расширил до архитектуры llama2. Так же Андрей пишет, что на это его вдохновил проект llama.cpp.

И помимо работы с моделью там еще и реализация BPE есть! Вот, наверное, где корни текущей лекции про BPE.

Я думаю, что можем ожидать следующие лекции от Андрея про устройство LLM, потому что Андрей буквально закодил ее с нуля, без использования сторонних библиотек, и поэтому очень глубоко понимает что там внутри.

Opensource LLM от Google

Продолжает сбываться мой прогноз, что корпорации будут выкладывать LLM в opensource.

https://ai.google.dev/gemma

Зачем платить какому-то там OpenAI, если можно просто взять хорошую модель в opensource, да?

По качеству gemma 7b плюс-минус равна mistral 7b. Но что поразительно? А поразительно то, что gemma 2b модель не сильно отстает. 2b модель сильно дешевле, чем 7b, 2b можно запускать даже на современном смартфоне без особых проблем.

Власти Индии рекомендуют получать у них одобрение на запуск ИИ моделей

Появляются такие новости. Я их читаю и мне сразу вспоминается Red Flag Acts. Что это такое?

В конце 19 века в UK приняли ряд законов, регулирующих использование автомобилей на дорогах общего пользования.

В результате принятых законов если вы хотели ехать на автомобиле, то вам нужно было 3 человека: водитель, кочегар (что?) и человек с красным флагом. Ехать можно было со скоростью не выше 3 километров в час, а человек с красным флагом должен был идти перед автомобилем и громко оповещать окружающих о том, что едет автомобиль, размахивая красным флагом.

Так безопаснее же!

Привело это к тому, что автомобильная промышленность в UK сильно отстала от других стран на 30-40 лет.

У Индии есть шанс повторить этот успех, но уже в сфере ИИ!

UPD. В комментариях указали, что нет убедительных доказательств, что red flag acts замедлили развитие автомобилестроения в UK. Спасибо, что читаете мой канал!

Yasmina отжигает на LEAP (конференция в Эр-Рияде)

alphasignal.ai

Опросил коллег на тему того какие они читают места, чтобы быть в курсе последних новостей в сфере AI. Все читают целую кучу источников, от tg-каналов, твиттера (Илон Маск бы сказал, что не знает что это, но зато знает «X») и до отслеживания конкретных людей в linkedin.

Среди источников мне понравился: https://alphasignal.ai

В нем AI суммаризирует новости про AI за неделю из самых разных мест и присылает результат на почту, я подписался.

Присылайте свои источники в комментариях!

Хе-хе