#корпжиза

Как устроено у нас в части DS (про ML-платформы отдельный разговор):

Матричная структура – DS числятся в центре компетенций, но работают на продуктах (другой вопрос что команды в центре компетенций я нарезал чтобы они максимально с продуктами бились).
В продукте по решению самой команды бывает мотивация:
▪️ продуктовая (повышенные бонусы за достижения бизнес-результата – цели одинаковые у всей команды – продакта, DE, Dev, DS, DA, тестеров, DevOps и пр.)
▪️ непродуктовая – индивидуальные качественные цели которые сбивают тим. лид и продакт (как правило достаточно гибкие, а если уж эти двое не могут договориться – то сл раунд мой и CPO).
▪️ Даже если вся команда на продуктовой, но DS очень не хочет – есть возможность перевести его на ставку с непродуктовой мотивацией или ротировать его в другой продукт с обычной мотивацией.

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

Детальный KPI, в тч численный, частые статусы и мелконарезанные задачи (любимый в agile микроменеджмент) – это все инструменты лечения патологии, то есть когда что-то идет плохо и надо влезть внутрь и разобраться – это ошибка целеполагания, процессов и условий или ошибка найма.

Последнее, кстати, далеко не всегда про увольнение – горжусь кейсом когда с достаточно средним DS поговорили и выяснили что python ему нравится больше чем все эти модели; и вуаля – после обучения появился специалист MLOps, который и сам круто вырос и команду себе собрал и вырастил и очень классно у нас все выстроил. После известных событий работает в Европе, в компании с рабочим английским.

#ML

Узнал тут про калибровку двумя изотониками -- Venn-ABERS, еще и на мультикласс расширяется, прикольно

#кейсы #ML

Картинка про то как я познакомился с бутстрапом и ЦПТ, на фото два будущих сотрудника AI-управления крупного (очень) банка

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

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

В итоге в плохом случае делаешь по 3-5 тыс. ударов кувалдой в день (по 30-50 на каждой точке) и картинка в ноутбуке с сейсмограммами со станции и правда становится четче.
Зато ЦПТ и бутстрап теперь не забыть, а на том ML и стоит.

PS: кого-нибудь спрашивали на собеседованиях про ЦПТ / бутстрап / сэмплирование? Ставьте 👍если да.

Из комментов под предыдущим постом — не могу не репостнуть Сашин пост, вопросы к собеседованию по NLP

Пока собираю пост про собеседования, поделюсь колымской тайгой на фото, которое уже не сделаешь -- там построили-таки ГОК, в 2011 руководил партией геофизиков-изыскателей под его строительство. DS мне тогда приносил катастрофически мало, приходилось подрабатывать иногда)

Точка, смотрю на запад.

#корпжиза

Про собеседования (1/2)
Сначала прелюдия, затем короткие посты-кейсы.

Выше уже описывал процесс– из каких этапов он состоит.

Почему я к этому пришел + несколько советов как проходить собеседования (не только к нам).

Тезис 1: и нанимающий менеджер, и собеседующие строго хотят вас нанять – если вы прошли скриннинг, то у вас уже отличная фора. Вообразите себе преподавателя, который гонит студентов на восемнадцатую пересдачу в ущерб личному времени и научным задачам – это же большая редкость встретить такого принципиального. И если вы даете возможность с +- чистой совестью сделать вам оффер – рады будут все.

Тезис 2: процесс из нескольких собеседований с проверкой знаний / скиллов почти безальтернативен
Идеальное собеседование для меня – одно, на котором бы мы с кандидатом обсудили бы любой (по выбору собеседника) из его предыдущих проектов детально и в глубину – какие решения принимал, почему так а не иначе, что еще можно было бы попробовать, а что нужно было бы делать если бы задача чуть-чуть поменялась – цена ошибки выросла бы, или масштаб был бы другим (в любую сторону), какая метрика была, чем она хороша, какую модель использовал и почему и пр. Такая беседа взрослых людей.

К сожалению, в лучшем случае на такой вопрос получал ответ в духе “ну модель построил”. Иногда “сначала данные подготовил, потом модель построил”. Либо “не помню” (ага, год как проект прошел – ты даже не помнишь какая метрика была). В особенно запущенных случаях в HR приходили жалобы что “собеседующий подверг сомнению мою компетенцию”. Еще бывает что “не было времени, поэтому сделали фит-предикт”. Особняком идут накручиватели опыта – детально об этом в кейсах.
Кстати, я не против – если по-другому HR-фильтр не обойти, то почему бы и нет. Только когда уже прошел дальше надо либо детально разбираться в кейсе, который вы себе вписали, либо честно о себе рассказать.

Так что проще оказалось в стандартизованный процесс, проверяя конкретные знания / скиллы / теорию. И то – в ML мы тоже можем попросить кандидата выбрать алгоритм и рассказать как он работает детально. Логика здесь простая – опыт приобретается когда что-то не работает или идет не так. И тут два варианта – за вас кто-то сделает (например на stackoverflow взять готовый сниппет) или разобраться что на самом деле пошло не так.

Тезис 3. С лидами все чуть сложнее дольше
У DS-лидов / тех лидов в среднем с этим уже чуть лучше, но проблемы там начинаются другие. Например, опытные балаболы – считают что надо брать инициативу в свои руки и не давать слово вставить собеседующему, максимально уводить в сторону “а вот если бы у рыбы были бы блохи”. Или канальи-манагеры – которые оскорбляются на простые технические вопросы.
Вообще, если на собеседовании-знакомстве на неджуновую позицию вам резко решили задать вопросы по технике или по каким-то примитивным вещам – значит вы произвели впечатление что вы не в деталях чем занималась команда.

#корпжиза

(2/2)
Тезис 4. Руководитель – этот тот кто знает в каком направлении двигаться, где может быть овраг, а где примерно оазис.
Навыки “организации процессов” или “проектного управления” ничем не отличаются от бытовой способности к планированию, хоть обмажься Prince2 и прочими PMI.
Проектным менеджером может работать любой кто самостоятельно спланировал и организовал свой отпуск, проработав риски и вернувшись, живым, здоровым и с положительными эмоциями. А уже если были стыковочные рейсы или несколько стран – то это уже старший проектный менеджер.
Поэтому на позиции линейного менеджера вообще не стоит напирать на манагерское на собеседовании, лучше показать себя как опытного специалиста с актуальными знаниями и видением как применять ML в этом конкретном кусочке бизнеса.

Тезис 5. Если вам кажется что собес душный – вам не кажется, значит возникли большие сомнения в вашем опыте / компетенциях. И наоборот – когда все ясно все закончится быстро и вам пожелают скорейшего выхода на новое место.

Тезис 6. Процесс найма очень похож на медицинский скриннинг. Он затюнен чтобы не пропустить деструктивный элемент, а не на то чтобы отобрать лучших. Неизбежно будут хорошие ребята, которые не пройдут. Если собес показался вам токсичным / душным / травмирующим – даже кровь из вены сдавать неприятно, не говоря уже о колоноскопии.
В любом случае все что ни делается -- все к лучшему. Значит, попадете в более классное место.

Всего конечно в посте не описать, дальше потихоньку буду набрасывать мини-кейсами.

PS: в сети часто попадается эмоциональное восприятие собеседований.
Две вещи:
1) Отказ в найме по резултатам собеседований это не отказ в совместной работе, было бы желание -- способы найдутся. Не взяли в штат -- ну напишите в телеге нанимающему менеджеру и попроситесь на гпх / предложите вместе статью написать -- вариантов масса.
2) Все до единого опубличенные кейсы, которые я видел, или про которые знаю, когда кого-то "обидели" на собеседовании -- при внимательном рассмотрении оказывались ситуацией когда кандидат сам сильно налажал в общении с собеседующими -- очень часто доказывал что они глупее его и превращал какой-н проходной вопрос в битву за Фермопилы

#кейсы #ML

Первое знакомство с накручивателем опыта было забавным и поучительным.
Это был парень, который в резюме указал что строил модели комплаенс.

После "привет, меня зовут юзернейм", вместо короткого интро, он сходу начал рассказывать стишок 🤥 как он модели AML делал, называя разные ключевые слова вроде "использовал sklearn и xgboost", как он пользовался гитом и ставил все на “расписание в apache airflow”.

Собственно, я и взял это собеседование, ибо в резюме было ООО “Ромашка” 🌼и комплаенс – думаю, прикольно, бизнес на этом делают, мб узнаю нового 🍿 .

Как и в любом кейсе я спросил что именно моделировали – что было целевой переменной и объектом моделирования. Парень начал агриться и сказал про фродовые транзакции. Фрод задача другая (совсем не AML) и я попросил привести пример такой вот фродовой транзакции или рассказать откуда у него разметка.
Кандидат в качестве примера привел попадание компании в санкционные списки (тоже не AML, с натяжкой мб ФТ).
Я переспросил – транзакция в адрес компании из санкционного списка? А зачем тогда модель? Можно просто по справочнику определить такие.
Тут парень откровенно поплыл, уходя от вопроса во все стороны сразу (хотя схем обнала десятки если не сотни). На вопрос про фичи -- то же самое. Так мы и не выяснили что в итоге моделировалось 😵
Решил добить контрольным – спросил про код 6001 и Росфинмониторинг 😆

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

Если уж накручиваете – вывезите в бар 🍺🍺 товарища и замучайте его вопросами про каждый шаг в кейсе. Тщательно запишите и потом еще раз загуглите каждый термин и саму задачу. Задавайте вопросы из поста выше -- почему решили так а не эдак, как собирали таргет и фичи и тд. При необходимости – повторить, начиная с выбора кейса. Затем поищите в кагле или каком-нибудт открытом курсе похожую задачу и попробуйте закодить решение. Если все-таки нашли на кагле -- посмотрите публичные ноутбуки, как ее решают. Подумайте над тем как найденное решение будет вести себя во времени, если его в прод поставить. Как вы это бедете делать, как мониторить и какие метрики / показатели. Спросите в дружественном DS-чате, мб у кого-то был похожий кейс.

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

Вот где обитают leading data processing компании

#кейсы #ML

Следующее собеседование было с девушкой, на лида, пара этапов прошли хорошо, кандидат это понимает,чувствует себя уверенно 😎, и вот идет знакомство c PO, оно у нас в присутствии HR (позиция все же руководящая).

Все вроде хорошо, складно говорит (с софтами на собеседованиях у девушек вообще в среднем лучше). Но ответы на кейсы PO достаточно обтекаемы – не понять насколько глубоко погружается в задачу и насколько опыт именно ее.

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

Диалог получился коротким:
“– Ну один раз надо было семь моделей в пром задеплоить в короткий срок
-- А сложность в чем?
– Ну работать надо было много”. 😂😂😂
После такого ответа и PO и HR как-то резко расхотели ее брать, но пробуем спасти положение:
“– Что, никогда никаких сложностей другого плана не было?
– да все гуглится за 5 минут”.

Результат немного предсказуем.
Действительно, если не пробовать новое, а брать готовые фичи и готовый пайп обучения с вшитыми моделями, не обновлять библиотеки, не участвовать в соревнованиях, не пробовать новые фичи, не менять размер выборки, просто копать картошку – наверное, и правда, годами можно делать одно и то же.
Или просто рядом был кто-то, кто эти проблемы решал? 🤔

#кейсы #ML

Кстати про технические сложности
Вспомнился старый кейс, где я вовсю ощутил свой недостаток образования в Computer Science.

В далеком кризисе 2014 года меня приютила одна по доброте душевной (а там правда очень классные люди) компания, которая разрабатывала софт для нефтяной сейсмики. У Яндекса там была существенная доля и хорошее отношение – которое выражалось, например в том что компания называлась Яндекс.Терра, а сотрудники могли быть слушателями ШАД.

Разработка на C/ С++ это вот ни разу не python или Matlab (мой основной иснтрумент тогда), и я в нее не умел (о чем честно сказал на входе). А задачи были – писать модули для той большой системы, и на старте мне дали достаточно простые – одноканальная обработка сигналов, всякие фильтрации/свертки, немного со спектрами и кепстрами.

И как-то мне нужно было пройтись по спектру с шагом 0.1 Гц, что-то сделать, а затем к результату применить обратное Фурье. Только вот не всегда результат обратного преобразования Фурье будет вещественнозначным ) Поэтому делать надо было аккуратно, с первого раза в C не получилось. Списав все на свои кривые руки, решил сделать в матлабе. И там волшебным образом все заработало!

Несколько дней я потратил, пытаясь добиться того же результата в C – без шанса 🙈🤯.
В матлабе же не только индексация массивов отличается)
В итоге пошел на поклон к синьору и тут вскрылся мой недостаток образования на тот момент в CS. Что-то о свойствах вещественных чисел я знал (что на равенство сравнивать нельзя, ибо хранятся они в некотором приближении), но вот глубоко не копал – на чем и погорел.

В чем же была проблема?
Как это выглядело в Matlab:

d = 0;
for i = 1:10000
    d = d + 0.1;
end
fprintf('%.25f', d)
>>> 1000.0000000001588205122970976

Аналогично на python:

d = 0
for i in range(10_000):
    d += 0.1
print(d)
>>> 1000.0000000001588

И вот то же самое (на самом деле нет) на C:

  
   float d = 0;
   for (int i = 0; i < 10000; ++i)
   {
       d += 0.1;
   }
   printf("%.6f", d);
>>> 999.902893

Дело было в том что 0.1 в двоичном виде непредставима как конечная дробь, только как периодическая. А с ограничением точности (float против double, который по умолчанию в python) при суммировании ошибка накопилась и достигла настолько существенных величин, что обратное Фурье становилось комплексным 😱.

PS как-то у коллеги видел очень похожую ситуацию в python (только там он при чтении из файла во float сохранил), уже в 16м, подсказал – помогло.
А копать с тех пор стараюсь поглубже 🪆

#ML

в соседнем канале в качестве решения кейса предложили Kahan summation algorithm, интересная штука

#корпжиза

Очередной собес на лида, или как не стать лидом из синьора

На одном из крупных продуктов жил-был CDO, который хороводил и DS и аналитиков и DE. И в подмогу нужен был молодой лид / вчерашний синьор, который мог бы потихоньку начать разгружать 🤝. Ставка была лидовская, но рассматривали и синьоров, ибо CDO готов был вложиться в развитие.

И вот после пары этапов приходят HR что нужно подключиться на финальный собес с CDO, ибо есть у участников процесса сомнения “по его софтам”, что бы это ни значило. Как всегда на финальном собеседовании с лидами HR с нами, во встречу вложено резюме, глаз цепляется за “в подчинении команда из 2-х Junior DS” 🤴, ну ладно, мб формулировка неудачная.

Итак, цель встречи – понять, насколько кандидат самостоятелен сам и насколько способен организовать команду. За тройку месяцев до этого кандидат собесился к нам на синьора, но в процессе передумал и заявил HR что “рассматривает минимум позицию тимлида”. Ну ок, как раз позиция лида открылась.
.
Начинаем общаться с кандидатом и выясняем что “каждое утро я докладываю начальнику чем сегодня я и подчиненные DS будут заниматься и что сделали вчера, получаю новые вводные” 🤓.
Пытаемся выяснить все же какие решения принимал сам кандидат. Свелось к посещаемости офиса (можно отпустить сотрудника на конференцию на день если сам за него готов в случае чего эту задачу закрыть). Пытаемся выяснить как общение с заказчиком происходит, как со смежниками – ответ расстраивает. Какие планы расти на текущем месте? “-- Спрошу начальника…”.
Видно, собеседование не клеится, кандидатм расстраивается, нам тоже обидно, ну да ладно 😔. Даем какой-никакой фидбек (хоть и не просили), но лучше взять самостоятельного синьора чем несамостоятельного лида.

Так вот, кроме как уметь в problem solving, руководителю надо уметь быть самостоятельным (еще это называется лидерской позицией) – то есть иметь свою полноценную зону ответственности, свой план развития не только по карьере в целом, но и на конкретной позиции в конкретной компании, иметь план развития своего подразделения – куда мы идем, зачем, как выглядит успех.

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

[пафос on] Менеджмент начинается с себя. [\пафос off]

PS А может это особеность культуры? 🤔 Хотеть аппрувов и бояться ответсвенности.

Мой хороший друг несколько лет назад переехал в другую страну на аналитика в компанию, которая публикует аналитические отчеты.
Когда он написал свой первый отчет -- тоже принес начальнику на проверку. Босс посмотрел на него и говорит -- "Ты уверен в своем отчете? если уверен -- публикуй от лица компании, а не уверен -- зачем ты мне его принес?".

#корпжиза

По мотивам обсуждения в прошлом посте -- статья из HBR 2004 1974 года менеджер и его время (которая про обезьянку)

#кейсы #ML

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

Когда опубликовали идею attention, ее сразу же начали пытаться добавлять всюду – и стороной не обошли и графовые свертки.

Итак, 30 октября на архив выкладывают короткую статью Graph Attention Networks. Все бы ничего, но в авторах есть сам великий Yoshua Bengio 🥸!!!

И реализацию статьи добавляют в прекрасный Pytorch Geometric под именем GATConv.

Все бы ничего, но работает эта штука не то чтобы очень.
А все почему? Attention реализовали в виде линейного слоя после линейного слоя 😆😆😆😆. Да, без нелинейности между ними 😂😂😂 А чему учат на первом занятии по DL? Тому что два линейных слоя подряд – снова линейный слой!

Лишь спустя 4 😱 года — в 2021 — на архив выкладывают статью с аккуратным названием How Attentive are Graph Attention Networks?, где ни в коем случае не утверждается что мэтр с командой ошиблись.

Только посмотрите на образец дипломатичной формулировки:

However, in this paper we show that GAT computes a very limited kind of attention: the ranking of the attention scores is unconditioned on the query node. We formally define this restricted kind of attention as static attention and distinguish it from a strictly more expressive dynamic attention

Опытные ребята! 🏆

Исправленную графовую свертку с вниманием назвали не мудрствуя лукаво GATv2Conv. 😄

И если на собесе забудете формулу KQV-attention (которое self), расскажите эту историю про другой механизм реализации идеи внимания, посмеетесь вместе с интервьюером 😁

Статьи про типичные ошибки в DS / ML реально такие

Даже не знаю как такие вакансии комментировать ...

Что мы ожидаем:
✅ Готовность работать в офисе, в СПб.
✅ Опыт работы с AI и глубоким обучением, понимание основ NLP, CV, ASR или TTS.
✅ Уверенные навыки работы с TensorFlow или PyTorch.
✅ Знание C++, Java, Scala и методов параллельных вычислений (CUDA, MPI).
✅ Английский на уровне для работы с документацией и общения.
✅ Приветствуется опыт в крупных технологических компаниях или участие в исследовательских проектах.

AI engineer
200 000 – 800 000 ₽/месяц
Офис, Фултайм

Ищем опытного специалиста в области AI и Machine Learning для работы над передовыми технологиями в области крупных языковых моделей, оптимизации и ускорения вычислений…(читать далее)