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 за неделю из самых разных мест и присылает результат на почту, я подписался.

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

Хе-хе

Devin

Cognition AI опубликовали интересное видео: https://www.youtube.com/watch?v=fjHtjT7GO1c

Devin - AI замена разработчику (хотят отобрать у нас работу!)

На видео у Девина просят побенчмаркать llama2 на нескольких провайдерах моделей по API - replicate, together, perplexity. Девина просят разобраться в API и написать скрипт, который задаст запросы в API из одинакового датасета во все провайдеры.

Сначала Девин пишет план, по которому он будет действовать, затем начинает использовать те же инструменты, что и обычный разработчик, чтобы выполнить задачу. Ищет документацию в браузере, использует терминал и редактор кода. Генерирует код, пробует его запустить, дебажит ошибки. Во время дебага Девин добавляет print-ы для дебага кода, затем перезапускает код и использует вывод для того, чтобы починить код. Затем Девин решает создать сайт для простенькой визуализации того, что получилось по результатам бенчмарка.

Оказывается, для таких задач есть свой рейтинг на SWE bench и Devin достиг 13.86%, тогда как второе место занимает Cloude2 с результатом 4.80%.

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

Интересно до куда это все может дойти!

Симуляция мира

Если хотите сделать беспилотное такси или антропоморфных роботов, то у вас есть интересная проблема. Вам очень сложно нормально тестироваться в реальности. И еще вам сложно собирать обучающую выборку в реальности. Вам сложно валидировать гипотезы, проводить много экспериментов. Работа исследователя AI состоит из можества экспериментов, из которых очень многие - неудачные!

Идея - давайте симулировать мир, чтобы в симуляции уметь тестировать ваш AI, собирать выборки и тд и тп.

За последний месяц я наткнулся на два проекта.

https://www.archetypeai.io/blog/what-is-physical-ai - пробуют сделать что-то типа LLM, но для физического мира. Вход для модели - информация с самых разных сенсоров. Камеры, микрофоны, данные лидара, датчики температуры, химические сенсоры и тд и тп. Модель назвали свою Newton! По сайту плохо понятно какой выход у модели. Однако понятно, что для симуляции сложно моделировать математически физический мир (мы ведь и сами не знаем до конца как физика работает), но вдруг мы сможем это делать с помощью AI?

https://waabi.ai/waabi-world/ - делают SefDriving trucks (автономные фуры). Говорят, что в симуляции делают цифровых двойников для всех участников движения. Делают AI, который симулирует естественное поведение участников движения. Добавляют вариативности, что позволяет в симуляции проверять тысячи и тысячи разных ситуаций на дороге. Называют свой симулятор Waabi World.

P.S. Когда я впервые услышал гипотезу, что мы живем в симуляции, я подумал, что гипотеза - бред, но теперь я ее бредом уже не считаю :D

Странные совпадения с GPT-4o

https://habr.com/ru/companies/bothub/news/815801/ - OpenAI хотели голос Скарлетт Йоханссон, но не получили. В итоге сделали похожий голос. Я думаю там нет вранья и действительно подобрали похожий голос, а не взяли тот, который было нельзя. Подобрать похожий голос - реальная задача.

У OpenAI точно много контакта с майкрософтом. Более того, вот тут можно глянуть в раздел special thanks: https://openai.com/index/dall-e-3/

Там перечислены фамилии, кому особенно был благодарен OpenAI в тот момент, а среди них Misha Bilenko, Mikhail Parakhin.

Кто эти люди? Оба работали в Яндексе, оба много сделали для того, чтобы Алиса появилась и стала в результате такой, какой она стала. Оба в итоге ушли в майкрософт и стали плотно работать с OpenAI.

А дальше следите за руками.

В чем пара важных фишек GPT-4o? Эмоции и голос Скарлетт Йоханссон.

В чем пара важных фишек Алисы? Эмоции и голос Скарлетт Йоханссон (Алисе дала голос та же актриса озвучки, которая озвучивает Скарлетт Йоханссон в русском дубляже в фильмах).

Совпадение или Алиса повлияла на GPT-4o?