#кейсы #ML

после того поста вспомнился кейс когда нормальное отношение к мату помогло спасти денег -- учредитель засветился в юр связях с примерно таким ликвидированным ООО (в 2021 создано, в 2023 ликвидировано). прочитайте название наоборот .

Словарь названий фирм-однодневок вполне себе неплохая фича в AML (борьбе с отмываем денег) -- если учредитель ООО, которое пришло у вас открывать счет, до этого открывал "Тензоры" и "Векторы", то ошибиться тяжело. И не надо думать что это боян из 90х. Вот ООО в 2018 открыли. А вот в 2021 Оманид. А вот еще в 2020 Аквалабиан. Вот еще 2017 ООО. А вот ООО Луник из 2022. Вот 2023й -- ООО Кодик.

А первую часть поста про встреченные мной KPI DS-команд выложу ближе к вечеру

#корпжиза

Про KPI у DS. Часть 1.
Реальный диалог:
“-- тимлид, че у вас модели говно?
– от нас требуют в прод по 4 модели в квартал на одного DS выводить”
😵

Так сложилось, что достаточно часто KPI на DS каскадируют канальи, у которых ни одной модели в проме нет. Часто такой трек идет в паре с любовью к количественным KPI (хотя логичнее называть их численными) и особенно к измерению “производительности DS” 🤬.

Вот что я встречал в качестве численных KPI для DS и их тимлидов:
▪️ “производительность” – число моделей в проме на 1 DS в квартал
▪️ число проведенных A/B в квартал на 1 DS
▪️ доля процессов с AI в ПРОМе
▪️ фин эффект в рублях в расчете на 1 DS
▪️ доля моделей с качеством выше AutoML baseline
▪️ доля моделей в проме на автомониторинге
▪️ доля моделей в проме с автовалидацией
▪️ доля процессов на единых AI-платформах
▪️ доля моделей, внедренных на целевых / пром средах
▪️ Т2М моделей – время от непонятно чего (заведения модели в учетную систему) до внедрения в пром
▪️ доля моделей, внедренных после A/B
▪️ число статей / выступдений на конференциях

И незабываемые качественные по конкретным моделям:
▪️ модель должна быть лучше эксперта по мнению самого эсперта (которого сократят если модель будет лучше)
▪️ модель должна быть лучше бейзлайна, но есть нюансы
▪️ модель должна прогнозировать на 3 месяца с качеством которое сейчас у отдела прогнозирования на 5 днях в будущее
и т.д.

Иногда из других компаний приходят с запросом: “Хотим чтобы DS работали эффективнее”.
А на вопрос “А как вы оцениваете их работу?” пожимают плечами и говорят “ну, по бизнес-метрикам”.

Короче, видимо зуд у каналий-манагеров на тему "не филонят ли наши DS" есть, их же на курсах учат что "не измеряешь -- не управляешь". Так и представляю себе партизанский отряд Фиделя Кастро с ежедневными отчетами по выпущенным патронам и A/B-тестам поражения целей 😂

Во второй части поделюсь своим имхо как этот зуд снимать. И заодно расскажу каких принципов придерживаюсь сам.

к сожалению, частенько бывает вот так

#корпжиза

Про KPI у DS. Часть 2.
Картинка выше намекает)

Задавались ли вы вопросом почему разработчикам не приходится доказывать свою эффективность финансистам и прочим?
Почему DSов зачастую оценивают по влиянию на бизнес-метрики?

Давайте посмотрим как вообще оценивают разрабов – по сложности задач и скорости их выполнения. То есть продакт на основе исследований (в тч общения с реальными пользователями) или чуйки приоритезирует функционал, тех лид пилит на задачи, сам или коллективным разумом оценивает их,, и задача поступает разработчику (если повезет – в промежутке еще и аналитик будет, который аккуратно распишет что именно нужно сделать).
Почему так происходит? Есть много соображений:
▪️ Логика софта детерменирована и потому понятна обывателю
▪️ CTO это C-Level и способен продать позицию что он предоставляет ресурсы и инструменты, а зарабатывать денег – задача бизнеса
▪️ Результат принципиально достижим и сроки управляемы – задачу в конце концов можно заутстаффить
▪️ Любые, даже самые идиотские, требования реализуемы – вопрос ресурсов и сроков
▪️ Развита инфраструктура самих решений – языков, фреймворков / библиотек – а тех. поддержку можно купить у вендора
▪️ Разработка меньше привязана к домену, чем DS (но все-таки привязана – embedded, crypto, hft – все разная специфика)
▪️ Проектирование приложений укладывается в принципы и паттерны
▪️ В ходе code review можно оценить качество кода
▪️ Можно страховаться покрытием автотестами, нагрузочным, интеграционным и функциональным тестированием

В противоположность в DS:
▪️ Обыватель не понимает статистику, концепцию случайной величины и случайных процессов. Максимум образования это A/B. Про то, что у A/B тоже не стопроцентная точность, или хотя бы про A/A или A/B/n обыватель не знает точно. Весь ноябрь и декабрь пол-страны гадало по недельной (!!!) инфляции повысит или нет ЦБ ставку.
Кстати, почему DS в рисках мерит качество моделей в Gini а не в ROCAUC? Потому что модуль Gini стартует от 0 и ренж от 0 до 100 проще объяснить заказчику.
▪️ CDS это часто CEO-2 или даже ниже – над ним либо CTO, либо CDO, либо CDTO
▪️ На конкретном датасете всегда есть максимальный предел точности – более того, чем ближе к нему подойти тем возможно менее стабильным будет решение
▪️ Чтобы декомпозировать задачи DSу и делать предположения какие офлайн-метрики тюнить, нужен другой DS поопытнее с такой же узкой специализацией. Декомпозиция не делает сроки предсказуемыми – пока не придумаешь и не сделаешь на данных тесты на консистентность, не поймешь, можно ли хоть какую-то модель построить
▪️ Внедрением часто занимаются совсем другие люди
▪️ Даже в банках отделы валидации берут достаточно большой срок чтобы оценить качество построения модели, при этом они не оценивают корректно ли собран таргет, фичи и пр. Полноценный review построенной модели не менее трудоемок чем построение модели с нуля включая сбор данных.
▪️ В конце концов непонятно чего эти кнопкодавы там делают, руками не потрогать! Здесь неизменный восторг каналий-манагеров вызывают интерактивные демо (например, отзывы разметить или суммаризировать) и недоумение классные модели, на которых эффекты получаются. Чем дальше от розницы или рекламы тем больше “ну A/B-тест A/B-тестом, но продал же продажник а не модель”. Занавес.

Лично я и сам избегаю и сотрудникам никогда не ставлю численные KPI. Ибо любой числовой KPI хакается (или задрачивать будут только его в ущерб остальному).
В тч от фин эффектов тоже отбиваюсь.

#корпжиза

Как устроено у нас в части 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), расскажите эту историю про другой механизм реализации идеи внимания, посмеетесь вместе с интервьюером 😁