Антоша меняет профессию

Нет, я не ухожу на Onlyfans. И не становлюсь блогером (хотя, постойте-ка 😀). Мне дали новую роль в компании и теперь я тимлид команды распознавания текста в VLM 🤔. Будем развивать качество модели в сценариях, связанных с текстом на картинке. Зачем для этого отдельная команда? Это хороший вопрос, который обсудим в одном из следующих постов.

Почему же это новая профессия? Кто меня давно знает-читает, наверное, помнит, что я был уже некогда руководителем двух команд разработки. Опираясь на прошлый опыт могу утверждать, что навыки в разработке/исследованиях и в руководстве хоть и пересекаются, но по большей части сильно отличаются 😊. Например, что я замечал и замечаю сейчас, так это разная направленность действий: в разработке твой фокус находится в очень большом плотном сгустке, тогда как в руководстве всё разбросано по разным уголкам и нужно стараться удерживать внимание.

В Яндексе руководители наделены большими полномочиями, нежели у меня были ранее. Но и ответственности, конечно же, прибавилось. Например, у меня появилась полная отвественность за найм, за мотивацию сотрудников, тогда как ранее всё шло через моего руководителя, который был также CTO. Ну и многое другое 👨‍🦳.

Тематика канала не изменится. Будет также много кринжа, мемов и иногда чего-то по делу 😍. Но начну писать побольше про работу, может быть обзоры статей, статей, а также мысли обо всём этом менеджерском. Если вдруг у вас есть идеи, о чём бы вы хотели ещё читать — пишите в комментарии или мне в личку ☺️!

Задачка про рандом

Хочу попробовать новый формат, может быть зайдёт ☺️! Буду иногда делиться задачами, которые мне когда-то приходилось решать на практике. К сути.

Мы пишем на С++. Так уж вышло, что в нашем алгоритме нам требуются генератор рандомных чисел. Условия:
— нет требования генерировать "настоящие рандомные" числа, т.е. псевдорандом уже ок!
— нам важен детерменизм, т.е. если приходит два раза бинарный куски данных, для которых md5 хеш совпадает, то мы должны выдавать одну и ту же последовательность чисел;
— гененратор должен быть thread-safe;
— должно работать максимально быстро.

Предложите в комментариях свою реализацию такой задачки. Будет круто, если подтвердите скорость каким-то бенчмарком!

Командировка в Москву

Прямо сейчас мчусь на рельсах "Невского экспресса" в Москву. Командировка как обычно на недельку.

Обычно я ездил повидаться-пообщаться с командой 😍, потому что по историческим причинам большинство CV-команды работает в Москве. Но нынче в планах также постараться лично поговорить с большинством лидов, менеджеров, которые так или иначе связаны с направлением, которое моей команде нужно развивать. С CTO кофе выпить, конечно, не получится (а жаль 🥺), но и без этого людей правда хватает.

Большинство моих командировок проходит в режиме тотальной работы 🤔. Никто не заставляет, но настроение у меня какое-то рабочее что ли. Но в этот раз я хочу посмотреть немного Москвы, хотя бы где-то покушать. Итак, москвичи или давние гости столицы, куда советуете заглянуть? А может быть в Москве есть сходки млщиков?

Статическая vs Динамическая линковка

Давно лежала в беклоге статья про статическую линковку: https://gavinhoward.com/2021/10/static-linking-considered-harmful-considered-harmful. Наконец-то я нашёл время и силы её прочитать. И вам советую. Я не эксперт и не гуру в сборке, но какой-то опыт и боль имею 👨‍🦳.

Если кратко, то автор старается привести контр-аргументы к фактам об ужасе статической линковки. Часть ответов автора удачная, часть оказывается в некотором смысле правдивой, но при этом прослеживается четкая нить, что не всё так плохо, как это представляют 🤨.

Например, часто статической линковке приписывают, что приложения, полученные путем подобной сборки, занимают больше места. Но при этом если взять и посчитать чиселки, то получается не такая большая разница 😀. Но зато мы получаем за эту "оптимизацию" целый ворох проблем:
— ABI несовместимости при обновлении;
— Усложнение цикла запуска приложения;
— Проблемы с воспроизводимостью сборки.

Если вы никогда с этим не работали, то очень сложно представить. Но, наверное, практически каждый МЛщик пользовался pip install some_lib, который устанавливает пакет и его зависимости. Потом вы запускаете свой привычный скрипт, а он работает по другому, хотя в нём даже не используется some_lib. А проблема в том, что при установке some_lib мы решили одну из зависимостей обновить. И понеслась 🤔.

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

В целом, я согласен с утверждениями Линуса Торвальдса:

Shared libraries are not a good thing in general. They add a lot of overhead in this case, but more importantly they also add lots of unnecessary dependencies and complexity, and almost no shared libraries are actually version-safe, so it adds absolutely zero upside.

shared libraries really make sense is for truly standardized system libraries that are everywhere, and are part of the base distro.

Or, for those very rare programs that end up dynamically loading rare modules at run-time - not at startup - because that’s their extension model.

Недавно BM25, алгоритм поиска из 80-х, победил нейросетевой поиск на LLM.

Мне стало очень интересно разобраться, как это работает, и я написал статью на Хабр, где этот алгоритм реализуется с нуля.

https://habr.com/ru/articles/823568/

Материал подойдет начинающим: ничего кроме знания Python не нужно.

Просьба читать, лайкать и кричать об этой статье на улицах. 😇

На этих выходных постарайтесь отдохнуть ☺️.

В целом как и на других.

На фото: рыбонька с одной из рыбалок. Закат был невероятный.

Излишняя переоптимизация

Наверное тот навык, который я всё ещё оттачиваю, но уже вполне неплохо овладел — излишне не переоптимизироваться 👨‍🦳. Я имею в виду, стараться использовать все ресурсы, которые есть сейчас, чтобы достигнуть своей цели. На это смотреть можно под разными углами, но я постараюсь объяснить свою точку зрения.

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

Например, в алгосиках зачастую приходят к хаку, когда используют десятки и сотни гигабайтов, чтобы хранить всё в RAM, но при этом это будет работать супер быстро, а на реализацию такого решения нужно потратить минимум времени. И действительно, когда придет время, команда сядет и перепишет это решение на более щадящее по памяти (или нет 😮‍💨).

Другой пример: разметка данных. Можно сделать автоматизирующий процесс, "оптимизировать" бюджет, потратить полгода работы команды разработчиков. А можно часть отдать команде разметчиков, провалидировать гипотезу, а потом пилить автоматизирующий процесс, если в этом будет необходимость.

Самый вопиющий для меня случай (я не знаю, насколько это правда) — это система турникетов в метро Питера 👨‍🦳. Дело в том, что петербуржский подорожник хранит информацию об оставшемся балансе денег. И в момент отработки с турникетом — просто списывает необходимую сумму денег. Как я понимаю, в этот момент может вообще не происходит коннекта к БД, хранящей инфу про карточки. Таким образом достигается быстрота взаимодействия.

Та же система в московском метро работает немного иначе. Тройка — просто идентификатор баланса в БД. А потому при проходе турникета, тот должен сходить в БД, совершить транзакцию списания, а потом вам открыть путь в подземный мир. Это медленнее, чем подорожник.

И казалось бы, подорожник круче тройки 🤨? Ну не совсем. Больше всего меня бесит то, что я не могу пополнить подорожник удаленно. Ну т.е. как бы могу, но потом мне нужно приложить карту к специальному валидатору (т.е. не к любому), чтобы деньги "зачислились" на карту. Ну и это бред. Ради быстроты (оптимизация времени работы), а скорее всего еще супер быстрой реализации (оптимизация бюджета и времени разработки) мы лишаемся очень важной пользовательской фичи.

Мораль: не переоптимизируйтесь.😍

Выпускной ИТМО🍷

Ребята из ИТМО позвали к себе на выпускной сегодня. А ребята из Яндекса позвали на этом выпускном поотвечать на вопросы про стажировки.

Было круто, мне понравилось общение! Раздали 100500 панамок, стикеров и прочего.

Ко мне подходили и ребята с опытом, и желающие пройти стажировку. Поотвечал на вопросики с удовольствием !

Часть ребят уже была моими подписчиками, что приятно❤️

А так я напоминаю, что нанимаю к себе в команду. Ищем ребят опытных, а также стажёров! Если интересно, пишите в личку, отвечу на все ваши вопросы☺️

Исследование профессионального ML-cообщества

Между постами хочу помочь ребятам из Центра научной коммуникации ИТМО провести опрос для MLщиков. Далее из самого опроса цитата:

Его цель – узнать больше о том, как устроено пространство профессиональной коммуникации, экспертиза и рынок труда в этой сфере.

Пройти опрос можно здесь. Ребята обещают выложить результаты опроса в открытый доступ, буду пинговать их, чтобы они сдержали своё обещание 👍.

Зона отвественности

У меня случился мини-отпуск в рамках которого я очень много рефлексировал на тему смены зоны отвественности при переходе с позиции разработчика в руководителя 😫. И по ощущениям она и правда выросла очень и очень сильно.

Раньше как разработчик, можно было смотреть не супер далеко вперёд по планам, да и честно говоря, иногда можно было забывать про основную цель деятельности. Потом ты приходишь к руководителю, который тебе всё очень доходчиво и толково объясняет, что к чему и почему 🔥.

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

Ну и самое неочевидное — это принятие решений. Вот в роли разработчика ты такой думаешь: "да чо там думать, нужно делать так". А сейчас уже не так: "А почему мы хотим делать так? Как мы поняли, что хотим это делать? А мы уверены? А почему?". Возможно, у меня случился дикое накручиванием ситуаций, но с другой стороны как будто бы это полезные вопросы для любой роли 👍.

Обо всех этих планах думать — очень сложное, но интересное упражнение. Если раньше я думал, что так не могу, то сейчас уже чот да получается 👨‍🦳.

Немного рекомендаций

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

Одна из таких историй в этом году была описана в посте Антона, где он участвовал в соревновании по расшифровке древних свитков, уничтоженных Везувием 👨‍🦳, и даже смог там себе отхватить промежуточный приз! Ну вы только подумайте, 8 месяцев с какой-то переодичностью копаться в очень плохих и непонятных данных, чтобы найти что-то, что никому не известно. Начать ради этого немного учить язык 🤔... Ну это нужно обладать каким-то упорством.

А вообще в его канале Generative Anton очень много прикольных штук написано не только про соревнование, а иногда про какие-то новости, про жизнь, про достижения (например, относительно недавно запилили своего чат-бота в амазоне для помощи разработчикам). Ну и много мемов, как полагается 😀! Так что рекомендую его канал к прочтению!

А вообще мы с ребятами запилили целую папку авторских телеграм каналов в сфере AI/ML/DS — Авторский ИИ, где каждый старается писать интересные вещи, окружающие его. Приходите читать!😍