Доклад рассказал, будет повтор в трансляции в 15:00 MSK и после повтора я буду отвечать на вопросы в live режиме.

Посмотреть можно тут: https://yatalks.yandex.ru/ru/live

Организаторы делают прикольные картинки по докладам, вот для моего, например.

А я на сегодня закончил!

Диффузионки и YandexART

Вчера на yatalks послушал доклад Сергей Овчаренко про модель YandexART.

Я за генерацией картинок в целом не очень слежу, но было интересно.

В частности было интересно то, как получаются картинки высокого разрешения 1024x1024 пикселей.

Вообще что такое диффузионная модель генерации картинки? Генерация делается из шума за несколько шагов до результата. Данные для обучения собираются обратным процессом через зашумление оригинальной картинки. Пример на фото.

В модели генерации YandexART оказывается для больших картинок применяется другой подход. Сначала они генерируют маленькую картинку 64x64, затем делают super resolution (увеличение картинки плюс улучшение качества с помощью нейросети) один раз, который еще и на текст смотрит, а потом делают еще один super resolution, но на этом шаге отдельная модель, которая в текст не смотрит. Так в итоге получаются картинки 1024x1024.

Говорят, что так нужно меньше вычислительных мощностей и при этом на картинках меньше артефактов.

Ну и да, в своем докладе Сергей снова подтвердил то, что выглядит уже базовым знанием:

1. Качественный датасет. Большую часть доклада Сергей рассказывал про то, как они фильтруют данные, чтобы остались только хорошие картинки и тексты к ним.

2. Обучение с подкреплением. В конце при помощи ручной человеческой разметки и RL-модели на ней дополнительно улучшается качество.

ИМХО картинки получаются классными.

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

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