Материалы и мысли, понадерганные отовсюду
Блог: https://t.me/asisakov_channel
Чат: https://t.me/youknowds_chat
Post #11702
68
#recommender
Channel Public Channel
ИН Интересное что-то
@youknowds
- Subscribers
- 625
- Photos
- 2.8K
- Videos
- 255
- Links
- 4.7K
Showing posts older than #11703 · Back to latest
Older Posts 20 shown
Post #11701
76
Forwarded from Дата канальи
#ML
Про анализ важности фичей
В очередной модели, которую попросили «посмотреть», обнаружил сразу три графика по важности фичей в бустинге:
— По числу сплитов по фиче (дефолтный feature_importances_)
— По gain
— По tree shap
Пропустим пока вопрос о дрифте фич (а они бывают разные с разными эффектами) — про них отдельно стоит написать.
Дальше я наивно ждал интерпретации — но увы.
Когда я об этом спросил услышал две версии от двух тимлидов:
Астерикс— «где gain выше та фича и сильнее»,
Обеликс — «где shap выше та фича и сильнее».
Поскольку галлы строят модели под влиянием волшебного друидского зелья и не знакомы с латинским, немного навайбкодил примеров чтобы показать что для анализа фичей нужны все три важности (это еще не считая анализа стабильности этой важности во времени / по фолдам).
Ключевое в них — кросс-плоты feature_importance по cплитам vs по gain и по shap vs по gain.
Это два графика, которые нужно обязательно смотреть в бустингах.
Если вкратце:
1. Важность по gain сильно завышает редкие бинарные фичи с резким эффектом (в тетрадке это x_strong_rare). Модель редко использует их (малый SHAP), но когда использует — один сплит даёт огромный выигрыш.
Что с такими фичами делать?
Если они сами по себе интерпретируемы и срабатывают редко —
Иначе будут проблемы и с обучением (понадобится больше деревьев и стабильность пострадает) и с интерпретируемостью — такая фича забьет рабочие лошадки по важности + начнет ломать интерпретируемость shap (либо придется считать отдельно для x_strong_rare = 1 или x_strong_rare = 0).
Смотрят либо фичи вылетевшие вверх на графике shap vs gain либо проверяют фичи которые в топе по gain но не в топе по shap.
Бонусом к отдельному сигналу — частота у такой фичи может сильно скакать во времени что еще больше нарушит стабильность модели.
Так что вынос такой фичи в отдельный сигнал — это еще и интерпретабельность PSI модели.
Как это повлияет на калибровку?
Ухудшит “глобальную” калибровку, но улучшает там, где модель реально работает (при x_strong_rare = 0).
2. Есть фичи вроде x_weak_often — с высоким сплитом, но низким shap и gain.
Здесь может быть несколько вариантов:
— +/- симметрично распределенный непрерывный шум
— фича костыль: есть небольшая коррекции с таргетом, но в модель ничего не добавляет
— фича по построения состоит из нескольких бакетов
В любом случае если зажали max_depth / n_estimators чтобы «регуляризоваться» то модель потратит кучу деревьев и сплитов на такие шумные и удобные для сплита фичи вместо того чтобы поймать реальный сигнал.
Еще она может массировать другие проблемы вроде мультиколлинеарности или ликов.
Как еще их можно отловить?
Строить feature_importance по месяцам/фолдам и проверять стабильность важности фичи.
Следить за дисперсией метрики (ex: Gini) на CV.
3. Есть фичи с низким split и не самым высоким gain, но с высоким SHAP.
То есть модель редко по ним сплитится, но почти в каждом объекте они двигают prediction.
Итого:
1. Строим:
- split vs gain
- shap vs gain
2. Если фича:
- top gain, но не top shap → кандидат в сигнал
- top split, но низко по shap и gain → кандидат на выброс
- low split, not high gain, high shap → не трогать, это рабочая фича (пока мы не исследовали ее стабильность по времени)
3. Проверяем:
- стабильность importance по фолдам / времени
- Дисперсию метрики по фолдам кросс-валидации
- PSI условно (x_strong_rare=0)
4. Только после этого:
- feature selection
- регуляризация
Те кто внезапно дочитал до этого момента могут заключить что второй тимлид был прав и надо смотреть только на shap.
Но
.
Особенно, если:
⁃ Он высокий только на трейне
⁃ Нестабилен по фолдам / или времени
⁃ Фича сама по себе нестабильна
⁃ Модель деградирует на OOT
PS.
низкий SHAP не значит что фича плохая.
Например:
— фича-разделитель (регион),
— стабилизирует модель,
— работает только в хвостах,
часто имеют низкий SHAP, но без них качество и стабильность падают.
Про анализ важности фичей
В очередной модели, которую попросили «посмотреть», обнаружил сразу три графика по важности фичей в бустинге:
— По числу сплитов по фиче (дефолтный feature_importances_)
— По gain
— По tree shap
Пропустим пока вопрос о дрифте фич (а они бывают разные с разными эффектами) — про них отдельно стоит написать.
Дальше я наивно ждал интерпретации — но увы.
Когда я об этом спросил услышал две версии от двух тимлидов:
Астерикс— «где gain выше та фича и сильнее»,
Обеликс — «где shap выше та фича и сильнее».
Поскольку галлы строят модели под влиянием волшебного друидского зелья и не знакомы с латинским, немного навайбкодил примеров чтобы показать что для анализа фичей нужны все три важности (это еще не считая анализа стабильности этой важности во времени / по фолдам).
Ключевое в них — кросс-плоты feature_importance по cплитам vs по gain и по shap vs по gain.
Это два графика, которые нужно обязательно смотреть в бустингах.
Если вкратце:
1. Важность по gain сильно завышает редкие бинарные фичи с резким эффектом (в тетрадке это x_strong_rare). Модель редко использует их (малый SHAP), но когда использует — один сплит даёт огромный выигрыш.
Что с такими фичами делать?
Если они сами по себе интерпретируемы и срабатывают редко —
их нужно выносить в сигналы до модели!
Иначе будут проблемы и с обучением (понадобится больше деревьев и стабильность пострадает) и с интерпретируемостью — такая фича забьет рабочие лошадки по важности + начнет ломать интерпретируемость shap (либо придется считать отдельно для x_strong_rare = 1 или x_strong_rare = 0).
Смотрят либо фичи вылетевшие вверх на графике shap vs gain либо проверяют фичи которые в топе по gain но не в топе по shap.
Бонусом к отдельному сигналу — частота у такой фичи может сильно скакать во времени что еще больше нарушит стабильность модели.
Так что вынос такой фичи в отдельный сигнал — это еще и интерпретабельность PSI модели.
Как это повлияет на калибровку?
Ухудшит “глобальную” калибровку, но улучшает там, где модель реально работает (при x_strong_rare = 0).
2. Есть фичи вроде x_weak_often — с высоким сплитом, но низким shap и gain.
Здесь может быть несколько вариантов:
— +/- симметрично распределенный непрерывный шум
— фича костыль: есть небольшая коррекции с таргетом, но в модель ничего не добавляет
— фича по построения состоит из нескольких бакетов
В любом случае если зажали max_depth / n_estimators чтобы «регуляризоваться» то модель потратит кучу деревьев и сплитов на такие шумные и удобные для сплита фичи вместо того чтобы поймать реальный сигнал.
Еще она может массировать другие проблемы вроде мультиколлинеарности или ликов.
Не выбросить такую фичу — ошибка!
Как еще их можно отловить?
Строить feature_importance по месяцам/фолдам и проверять стабильность важности фичи.
Следить за дисперсией метрики (ex: Gini) на CV.
3. Есть фичи с низким split и не самым высоким gain, но с высоким SHAP.
То есть модель редко по ним сплитится, но почти в каждом объекте они двигают prediction.
Выбрасывать такие фичи — тоже ошибка!
Итого:
1. Строим:
- split vs gain
- shap vs gain
2. Если фича:
- top gain, но не top shap → кандидат в сигнал
- top split, но низко по shap и gain → кандидат на выброс
- low split, not high gain, high shap → не трогать, это рабочая фича (пока мы не исследовали ее стабильность по времени)
3. Проверяем:
- стабильность importance по фолдам / времени
- Дисперсию метрики по фолдам кросс-валидации
- PSI условно (x_strong_rare=0)
4. Только после этого:
- feature selection
- регуляризация
Те кто внезапно дочитал до этого момента могут заключить что второй тимлид был прав и надо смотреть только на shap.
Но
высокий shap ничего не гарантирует!
.
Особенно, если:
⁃ Он высокий только на трейне
⁃ Нестабилен по фолдам / или времени
⁃ Фича сама по себе нестабильна
⁃ Модель деградирует на OOT
PS.
низкий SHAP не значит что фича плохая.
Например:
— фича-разделитель (регион),
— стабилизирует модель,
— работает только в хвостах,
часто имеют низкий SHAP, но без них качество и стабильность падают.
Post #11700
70
#ml
Post #11699
79
Forwarded from Дратути Антон
Вечерние размышления про руководство [2/x]
Над следующим топиком я рефлексировал достаточно продолжительное время, но так и не смог точно для себя определить, насколько аналогии, приведенные ниже — уместны. Но хотелось бы считать, что я смог хоть как-то донести свою мысль.
Руководитель — организатор
Организовывать всё и вся — это моя любовь ☺️, мой драйв с самого детства. Что в школе я организовывал взаимодействия классов, что в университете общие конспекты, написание билетов и т.д., что на работе страюсь сделать что-то эдакое. Я невероятно люблю приходить к самоорганизующимся самостоятельным системам, где, для того, чтобы они стали "само-" ты приложил руку 😀. Но до этого, зачастую, бесконечный дебаг человеческих взаимоотношений.
Хоть это, вероятно, и глупо, но я часто думаю про организации как о ПО 👨🦳. Да-да, те самые программы, только очень сложные. Есть куча компонентов, они как-то связаны с друг другом. И, конечно, же, они обладают большим набором свойств. Вот часть из них:
— К некоторым нет доступа. Прям как в C++ инкапсуляция 🤓. Правда можно через указатели пробраться к приватным членам/методам (людям) класса (команды) и даже как-то на них повлиять (дать задачи), но с большой вероятностью прилетит по голове, ну или прокатит 🏥. А можно стать дружественным классом (договориться о взаимодействии) и быть может некоторые интерфейсы и поля тебе будут открыты;
— Иногда компоненты прям дублируют друг друга. Обычно в разработке нам некогда думать о переиспользуемости 🧠, а в руководстве — не хотим/не можем договориться 😊;
— Компоненты — это сущности составные. Но минимально базовым является человек;
— В компонентах бывают возникают баги. В случае команд зачастую это проблема в процессах, а в случае людей — мотивация, усталость и много много другого. И для всяких случаев нужно понимать, как дебажить: минимально возможный инструмент — это принт, т.е. поговорить 🔼.
Я помню случай, когда мне нужно было дебажить TensorRT на предмет нестабильности. Ну вот сама по себе библиотека — проприетарная, а потому, как внешнему разработчику, мне не доступны исходники. Приходится буквально дебажить Black-Box в надежде отловить проблему. Но, я же инженер, поэтому исследовал кишки бинарников и в хвост и в гриву, в итоге поборол проблемки 🤯.
В случае людей всё сильно сложнее. Ты не можешь тыкать рандомно и бесконечное число раз, попытки исчисляются единицами, иначе можно подсадить ещё багов (например, демотивация). Но если вдруг всё получается, то ты получаешь новые свойства компонент, за чем наблюдать — одно удовольствие.
Продолжение следует...
Над следующим топиком я рефлексировал достаточно продолжительное время, но так и не смог точно для себя определить, насколько аналогии, приведенные ниже — уместны. Но хотелось бы считать, что я смог хоть как-то донести свою мысль.
Руководитель — организатор
Организовывать всё и вся — это моя любовь ☺️, мой драйв с самого детства. Что в школе я организовывал взаимодействия классов, что в университете общие конспекты, написание билетов и т.д., что на работе страюсь сделать что-то эдакое. Я невероятно люблю приходить к самоорганизующимся самостоятельным системам, где, для того, чтобы они стали "само-" ты приложил руку 😀. Но до этого, зачастую, бесконечный дебаг человеческих взаимоотношений.
Хоть это, вероятно, и глупо, но я часто думаю про организации как о ПО 👨🦳. Да-да, те самые программы, только очень сложные. Есть куча компонентов, они как-то связаны с друг другом. И, конечно, же, они обладают большим набором свойств. Вот часть из них:
— К некоторым нет доступа. Прям как в C++ инкапсуляция 🤓. Правда можно через указатели пробраться к приватным членам/методам (людям) класса (команды) и даже как-то на них повлиять (дать задачи), но с большой вероятностью прилетит по голове, ну или прокатит 🏥. А можно стать дружественным классом (договориться о взаимодействии) и быть может некоторые интерфейсы и поля тебе будут открыты;
— Иногда компоненты прям дублируют друг друга. Обычно в разработке нам некогда думать о переиспользуемости 🧠, а в руководстве — не хотим/не можем договориться 😊;
— Компоненты — это сущности составные. Но минимально базовым является человек;
— В компонентах бывают возникают баги. В случае команд зачастую это проблема в процессах, а в случае людей — мотивация, усталость и много много другого. И для всяких случаев нужно понимать, как дебажить: минимально возможный инструмент — это принт, т.е. поговорить 🔼.
Я помню случай, когда мне нужно было дебажить TensorRT на предмет нестабильности. Ну вот сама по себе библиотека — проприетарная, а потому, как внешнему разработчику, мне не доступны исходники. Приходится буквально дебажить Black-Box в надежде отловить проблему. Но, я же инженер, поэтому исследовал кишки бинарников и в хвост и в гриву, в итоге поборол проблемки 🤯.
В случае людей всё сильно сложнее. Ты не можешь тыкать рандомно и бесконечное число раз, попытки исчисляются единицами, иначе можно подсадить ещё багов (например, демотивация). Но если вдруг всё получается, то ты получаешь новые свойства компонент, за чем наблюдать — одно удовольствие.
Продолжение следует...
Post #11698
78
#softskills #career
Post #11697
96
Forwarded from эйай ньюз
🔥Курс по Deep Learning (Fall 2024) от MIT доступен онлайн!
Один из лекторов - Phillip Isola, чень крутой ресерчер в Computer Vision. Олды помнят его легендарный CycleGAN (2017).
Выложили и слайды, и доп материалы, и видео лекций, и домашки (можете по-честному их выполнить и отправить на проверку в Claude Code :))
Очень качественный базовый курс. Если хотите разобраться в Deep Learning немного глубже промптов, то очень рекомендую к просмотру!
Курс целиком можно скачать тут:
https://ocw.mit.edu/courses/6-7960-deep-learning-fall-2024/video_galleries/lecture-videos/
P.S. Еще один хрестоматийный курс по DL - это Стенфордский CS231 от Карпатого.
#ликбез
@ai_newz
Один из лекторов - Phillip Isola, чень крутой ресерчер в Computer Vision. Олды помнят его легендарный CycleGAN (2017).
Выложили и слайды, и доп материалы, и видео лекций, и домашки (можете по-честному их выполнить и отправить на проверку в Claude Code :))
Очень качественный базовый курс. Если хотите разобраться в Deep Learning немного глубже промптов, то очень рекомендую к просмотру!
Курс целиком можно скачать тут:
https://ocw.mit.edu/courses/6-7960-deep-learning-fall-2024/video_galleries/lecture-videos/
P.S. Еще один хрестоматийный курс по DL - это Стенфордский CS231 от Карпатого.
#ликбез
@ai_newz
Post #11696
82
#dl #courses
Post #11695
85
Forwarded from Dataism
Как достать соседа нанимающего менеджера?
Вопросами, на которые он не знает ответа
Когда-то давно я уже выкладывала список вопросов, которые нужно обязательно задать команде и рекрутеру в процессе собеседований.
Но я бы назвала этот список «джуновским»: там всего лишь один вопрос о планах развития команды.
И в этом ключевая проблема.
Бэклог на год вперёд не спасёт продукт, если нет стратегии.
Но чтобы задавать вопросы, касаемые этой стратегии, нужно сделать домашнюю работу:
Готово!
Пушка-бомба, вы великолепны.
Тут только не хватает еще 1го пункта, но об этом в конце.
Теперь к реальной ситуации из опыта: вот мы готовимся к собеседованию и прилежно проделываем домашку.
Вырисовывается следующая картина:
- небольшая компания, но уже давно на рынке.
- в портфеле активных 4 сервиса, один из них b2b. 1 сервис недавно закрыли, но плашечка на сайте предательски заманивает в него, хотя и ведет в никуда.
- дофига конкурентов, поэтому доля на рынке в районе 2-2.4% (и последние 4 года не меняется).
Что происходит на самом собесе*.
- Какой сервис для вас наиболее прибыльный? Мне без цифр конкретных, просто понять за счет чего живете в большей степени.
Нанимающий: NDA
- Какие у вас планы на развитие продукта? Планируете ли открывать новые сервисы?
Нанимающий: нет, нам есть чем заняться внутри существующих 2х сервисов.
- А у вас вот был сервис и вы активно его продвигали, но вижу плашечка больше никуда не ведет. Почему закрыли?
Нанимающий: не пошло, спроса нет.
- Странно, но конкуренты же развивают подобные сервисы активно и выстраивают экосистему. За счет чего тогда планируете выделяться и расширять свою долю на рынке?
Нанимающий: а чего такой интерес к этому сервису-то? надо будет, откроем назад.
Это были прекрасные 30 минут подобного диалога 🫠
Впечатления остались неоднозначные, все туманно.
Подумала, может мне просто показалось.
И тут я вспомнила, что в домашке пропустила последний этап — почитать отзывы на DreamJob.
А там ну просто мееееед 🍯:
Получается, не показалось все же.
Считаю, что работать в компании без стратегии — опасно.
- нет ощущения значимости работы
- хаос в процессах
- токсичная среда
- работаешь в ожидании увольнения
- рассказы про сложность рынка/времени и тд.
🚩А вы задаете вопросы про развитие продукта и куда компания движется глобально? А подобную «домашку» проделываете перед собесом?
*Компания может и не стремиться расширять долю на рынке, это нормально. Вопрос только к способностям нанимающего менеджера внятно рассказать о планах и основных фокусах, чего в данном случае не было.
p.s. кстати, напоминаю про бота для подготовки к собеседованиям @DataismPrepBot.
Сезон найма ближе, чем ты думаешь.
Вопросами, на которые он не знает ответа
Когда-то давно я уже выкладывала список вопросов, которые нужно обязательно задать команде и рекрутеру в процессе собеседований.
Но я бы назвала этот список «джуновским»: там всего лишь один вопрос о планах развития команды.
И в этом ключевая проблема.
Бэклог на год вперёд не спасёт продукт, если нет стратегии.
Но чтобы задавать вопросы, касаемые этой стратегии, нужно сделать домашнюю работу:
1. изучить сайт компании и пройтись по основным сценариям использования (web/app)
2. понять их монетизацию, за счет чего они хлеб с маслом/без едят (у некоторых вместо хлеба оказывается совсем другое).
3. какие у них каналы привлечения пользователей
4. посмотреть как растут фин.показатели от года к году и открытые данные на similarweb.com
5. изучить прямых и косвенных конкурентов и их предложения, узнать у кого какая примерно доля рынка.
Готово!
Пушка-бомба, вы великолепны.
Тут только не хватает еще 1го пункта, но об этом в конце.
Теперь к реальной ситуации из опыта: вот мы готовимся к собеседованию и прилежно проделываем домашку.
Вырисовывается следующая картина:
- небольшая компания, но уже давно на рынке.
- в портфеле активных 4 сервиса, один из них b2b. 1 сервис недавно закрыли, но плашечка на сайте предательски заманивает в него, хотя и ведет в никуда.
- дофига конкурентов, поэтому доля на рынке в районе 2-2.4% (и последние 4 года не меняется).
Что происходит на самом собесе*.
- Какой сервис для вас наиболее прибыльный? Мне без цифр конкретных, просто понять за счет чего живете в большей степени.
Нанимающий: NDA
- Какие у вас планы на развитие продукта? Планируете ли открывать новые сервисы?
Нанимающий: нет, нам есть чем заняться внутри существующих 2х сервисов.
- А у вас вот был сервис и вы активно его продвигали, но вижу плашечка больше никуда не ведет. Почему закрыли?
Нанимающий: не пошло, спроса нет.
- Странно, но конкуренты же развивают подобные сервисы активно и выстраивают экосистему. За счет чего тогда планируете выделяться и расширять свою долю на рынке?
Нанимающий: а чего такой интерес к этому сервису-то? надо будет, откроем назад.
Это были прекрасные 30 минут подобного диалога 🫠
Впечатления остались неоднозначные, все туманно.
Подумала, может мне просто показалось.
И тут я вспомнила, что в домашке пропустила последний этап — почитать отзывы на DreamJob.
А там ну просто мееееед 🍯:
- отсутствие стратегии развития бизнеса
- тoкcичнoe руководство
- на рынке компания уверенно держится только за счёт B2B направления; остальные продукты уверенно проигрывают конкуренцию
- прошли массовые сокращения (35-40% IT-департамента)
- большая часть зп в виде премии, часть из которой могут не выплатить за то, что ты не затрекал время рабочее, не включил камеру на созвонах и т.д
Получается, не показалось все же.
Считаю, что работать в компании без стратегии — опасно.
- нет ощущения значимости работы
- хаос в процессах
- токсичная среда
- работаешь в ожидании увольнения
- рассказы про сложность рынка/времени и тд.
🚩А вы задаете вопросы про развитие продукта и куда компания движется глобально? А подобную «домашку» проделываете перед собесом?
*Компания может и не стремиться расширять долю на рынке, это нормально. Вопрос только к способностям нанимающего менеджера внятно рассказать о планах и основных фокусах, чего в данном случае не было.
p.s. кстати, напоминаю про бота для подготовки к собеседованиям @DataismPrepBot.
Сезон найма ближе, чем ты думаешь.
Post #11694
71
#interview
Post #11693
79
Forwarded from АННА В ДАННЫХ
Как бесплатно прожарить свое резюме 🔥
Поделюсь действующим способом, которым пользуюсь сама
Да, я снова про нейронки. Но если раньше у вас могло не очень получаться пофиксить с ними резюме, то сегодня обязательно получится
Все дело в правильном промпте. Самая большая ошибка - это просить просто “красиво причесать резюме”. Нейронка причешет так, что вас будет не отличить от инфоцыгана 🤓
Итак:
🐚 Открывайте Gemini (аналог ChatGPT от гугла, мне нравится больше)
🐚 Вставляйте промпт
🐚 И прикрепляйте файл со своим резюме
💫Вуаля! 💫
Я обожаю этот промпт, он очень мощно прожаривает. Это помогает не только хорошо описать достижения на бумаге, но и подготовиться к рассказу о своем опыте на собеседовании (дополнительный топ-вопросов с собесов ищите в моем посте)
Да и с любым другим промптом важно использовать ИИ именно как генератор смыслов и не копировать результат 1 в 1, чтобы резюме “не воняло чатгпт” 🤓 (извините, просто я насмотрелась)
Еще один хороший оставлю в комментах!
А как вы относитесь к написанию резюме с помощью нейронок? Если сами пользуетесь, поделитесь вашими любимыми промптами
#ИИ_анна_в_данных
#карьера_анна_в_данных
Поделюсь действующим способом, которым пользуюсь сама
Да, я снова про нейронки. Но если раньше у вас могло не очень получаться пофиксить с ними резюме, то сегодня обязательно получится
Все дело в правильном промпте. Самая большая ошибка - это просить просто “красиво причесать резюме”. Нейронка причешет так, что вас будет не отличить от инфоцыгана 🤓
Итак:
🐚 Открывайте Gemini (аналог ChatGPT от гугла, мне нравится больше)
🐚 Вставляйте промпт
Представь, что ты скептичный CTO (технический директор) в крупной IT-компании. Вот мое резюме. Найди в нем все, что вызывает у тебя больше всего сомнений или выглядит как "вода". Задай мне уточняющие вопросы по каждому пункту, чтобы я могла добавить конкретные цифры и факты
🐚 И прикрепляйте файл со своим резюме
💫Вуаля! 💫
Я обожаю этот промпт, он очень мощно прожаривает. Это помогает не только хорошо описать достижения на бумаге, но и подготовиться к рассказу о своем опыте на собеседовании (дополнительный топ-вопросов с собесов ищите в моем посте)
Да и с любым другим промптом важно использовать ИИ именно как генератор смыслов и не копировать результат 1 в 1, чтобы резюме “не воняло чатгпт” 🤓 (извините, просто я насмотрелась)
Еще один хороший оставлю в комментах!
А как вы относитесь к написанию резюме с помощью нейронок? Если сами пользуетесь, поделитесь вашими любимыми промптами
#ИИ_анна_в_данных
#карьера_анна_в_данных
Post #11692
78
#resume #prompt
Post #11691
108
Forwarded from Аналитесса-разработчица👩🏻💻💅🏻 (anna)
Основы O-оценки сложности для алгособесов📈
Постараюсь ввести вас в курс дела как аналитиков, потому что любое Leetcode-собеседование (а их становится больше) подразумевает если не совсем оптимальное решение, то что кандидат хотя бы понимает, как это измеряется🤵
➡️ Что это вообще такое?
Big-O («О большое») — это асимптотическая* оценка того, c какой скоростью растут время и/или память алгоритма при увеличении размера входных данных, если отбросить константы
* для подробностей нужно определение предела, не сегодня
Время в данном случае — это количество простейших операций (что-нибудь сложить, умножить, присвоить), память — количество переменных, которое приходится хранить (например, во вспомогательных массивах), размер входа — сколько данных нам дано. Например, даётся один массив чисел — его длину мы обозначаем за
➡️ Основные правила оценки сложности вашего кода
Учим, как аксиомы:
⚪️ Любые фиксированные присвоения переменных (например, инициализация какой-нибудь суммы или указателей-индексов) — это константная сложность
⚪️ Линейный проход по всем элементам массива —
⚪️ Сортировка —
⚪️ Вложенные циклы: сложности перемножаются. Если у вас 2 вложенных
Если массива два, то будет
⚪️ У последовательных шагов сложности складываются, но более быстрорастущее слагаемое поглощает остальные. То есть, если у вас сначала один цикл обработки массива, а потом 2 вложенных, то в пределе не
Если циклы не вложенные по двум массивам, то мы оставляем
➡️ Быстрый порядок величин «от лучше к хуже»:
До последних двух мы стараемся не доходить в задачах на собесах, это нереально много операций. Например, задача рандомной перестановки элементов массива не подразумевает, что вы сгенерируете все
➡️ Библиотечные методы и структуры тоже учитываются
Они оптимизированы по мере возможности, но та же сортировка никогда не станет линейной😬 Продвинутый уровень — выучить, что оптимально для какой операции.
➡️ Пример фразы, которая растопит сердце интервьюера😎
Особенно, если вы реально понимаете, почему так работает))
Буду ждать фидбек, стало ли понятнее👍 И пересылайте друзьям, которые собираются на стажировки и другие собесы!
#хардов_пост #найм_и_собесы
@analytess 👩
Постараюсь ввести вас в курс дела как аналитиков, потому что любое Leetcode-собеседование (а их становится больше) подразумевает если не совсем оптимальное решение, то что кандидат хотя бы понимает, как это измеряется🤵
➡️ Что это вообще такое?
Big-O («О большое») — это асимптотическая* оценка того, c какой скоростью растут время и/или память алгоритма при увеличении размера входных данных, если отбросить константы
* для подробностей нужно определение предела, не сегодня
Время в данном случае — это количество простейших операций (что-нибудь сложить, умножить, присвоить), память — количество переменных, которое приходится хранить (например, во вспомогательных массивах), размер входа — сколько данных нам дано. Например, даётся один массив чисел — его длину мы обозначаем за
N. Может быть задача, где каждый элемент входного массива уже не просто число, а, например, строка длины не более M, и это тоже окажется важно...➡️ Основные правила оценки сложности вашего кода
Учим, как аксиомы:
⚪️ Любые фиксированные присвоения переменных (например, инициализация какой-нибудь суммы или указателей-индексов) — это константная сложность
O(1)⚪️ Линейный проход по всем элементам массива —
O(N)⚪️ Сортировка —
O(N log N), если встроенная и оптимальная, но иногда доходит до O(N^2) (это уже другая история)⚪️ Вложенные циклы: сложности перемножаются. Если у вас 2 вложенных
for i in arr, где arr — ваш входной массив длины N, то будет O(N^2), если 3 — то O(N^3), и так далее...Если массива два, то будет
O(N * M), пример:for i in range(len(arr_1)): # arr_1 - массив длины N
for j in range(len(arr_2)): # arr_2 - массив длины M
...
⚪️ У последовательных шагов сложности складываются, но более быстрорастущее слагаемое поглощает остальные. То есть, если у вас сначала один цикл обработки массива, а потом 2 вложенных, то в пределе не
O(N^2) + O(N), а просто O(N^2).Если циклы не вложенные по двум массивам, то мы оставляем
O(N + M), потому что не можем сравнить N и M асимптотически.➡️ Быстрый порядок величин «от лучше к хуже»:
O(1) < O(log N) < O(N) < O(N log N) < O(N²) < O(2^N) < O(N!)До последних двух мы стараемся не доходить в задачах на собесах, это нереально много операций. Например, задача рандомной перестановки элементов массива не подразумевает, что вы сгенерируете все
N! штук, сохраните их и выберете.➡️ Библиотечные методы и структуры тоже учитываются
Они оптимизированы по мере возможности, но та же сортировка никогда не станет линейной😬 Продвинутый уровень — выучить, что оптимально для какой операции.
➡️ Пример фразы, которая растопит сердце интервьюера😎
Тут получается сложность O(N) за счёт линейного поиска по массиву, инициализация переменных была за O(1). Могу написать бинпоиск, будет оптимальнее — за O(log N)...
Особенно, если вы реально понимаете, почему так работает))
Буду ждать фидбек, стало ли понятнее👍 И пересылайте друзьям, которые собираются на стажировки и другие собесы!
#хардов_пост #найм_и_собесы
@analytess 👩
Post #11690
82
#algo
Post #11689
93
Forwarded from декомпозиция и отвага
Чтобы лучше оценивать задачи, нужен простой советский… 🪄🔮
1. Оценивайте зафиксированный скоуп требований. Новый влёт - новая оценка.
2. Попробуйте конкретизировать или уменьшить задачу через выделение MVP.
3. Если в задаче много «неизвестных», назойливо подчёркивайте это при оценке.
4. Возьмите время для исследования. В Jira есть специальный тип задач для этого - Spike.
5. Разбейте задачу на части или этапы и оценивайте их отдельно.
6. Не оценивайте за другие роли - разработчиков или тестировщиков. Пусть коллеги сами дадут свои оценки.
7. Посоветуйтесь с более опытными коллегами.
8. Проведите покер-планирование.
9. Ведите статистику план-факт по предыдущим оценкам. На это можно будет опереться при оценке аналогичных задач.
10. Посчитайте срок по формуле PERT.
11. Заложите в оценку риски, связанные с текущими изменениями в компании. Например, организационными перестановками, изменениями технологий или процессов.
12. Если для выполнения задачи требуются бюрократические формальности, заложите на них время.
13. Помните о том, что люди уходят в отпуска, болеют и увольняются.
14. Заложите буфер на случай абстрактных непредвиденных обстоятельств.
15. Если возможно, давайте вилку, а не точную оценку.
16. Фиксируйте оценки.
17. Оценивайте чаще. С каждым разом будет получаться всё лучше.
18. Проводите ретроспективы по кейсам, когда вы не попали в оценки.
19. Если кто-то систематически недооценивает задачи, умножайте их оценки на корректирующий коэффициент. Для разработчиков часто подходит х2 или даже х3.
20. Спросите, какой срок ожидает заказчик?
🙃🙃🙃🙃🙃🙃🙃🙃🙃🙃🙃🙃🙃🙃
🚘 -
😎 -
🤨 -
Бизнес часто просит аналитиков оценить ту или иную доработку. Я подготовила большой список советов для подобных ситуаций. Советы абсолютно разного свойства и представлены в посте в хаотичном порядке. Кстати, это и делает список реально классным 😏
1. Оценивайте зафиксированный скоуп требований. Новый влёт - новая оценка.
2. Попробуйте конкретизировать или уменьшить задачу через выделение MVP.
3. Если в задаче много «неизвестных», назойливо подчёркивайте это при оценке.
4. Возьмите время для исследования. В Jira есть специальный тип задач для этого - Spike.
5. Разбейте задачу на части или этапы и оценивайте их отдельно.
6. Не оценивайте за другие роли - разработчиков или тестировщиков. Пусть коллеги сами дадут свои оценки.
7. Посоветуйтесь с более опытными коллегами.
8. Проведите покер-планирование.
9. Ведите статистику план-факт по предыдущим оценкам. На это можно будет опереться при оценке аналогичных задач.
10. Посчитайте срок по формуле PERT.
11. Заложите в оценку риски, связанные с текущими изменениями в компании. Например, организационными перестановками, изменениями технологий или процессов.
12. Если для выполнения задачи требуются бюрократические формальности, заложите на них время.
13. Помните о том, что люди уходят в отпуска, болеют и увольняются.
14. Заложите буфер на случай абстрактных непредвиденных обстоятельств.
15. Если возможно, давайте вилку, а не точную оценку.
16. Фиксируйте оценки.
17. Оценивайте чаще. С каждым разом будет получаться всё лучше.
18. Проводите ретроспективы по кейсам, когда вы не попали в оценки.
19. Если кто-то систематически недооценивает задачи, умножайте их оценки на корректирующий коэффициент. Для разработчиков часто подходит х2 или даже х3.
20. Спросите, какой срок ожидает заказчик?
🙃🙃🙃🙃🙃🙃🙃🙃🙃🙃🙃🙃🙃🙃
Как думаете, напишут ли такой пост в мессенджере MAX?
🚘 -
конечно, будем всем кооперативом даже с парковки читать😎 -
ну уж нет, где там мои 150 рублей на впн, заплачу и буду месяц из Нидерландов телеграммиться
🤨 -
Дуров, что сделать, чтобы вернуть свободный интернет? Post #11688
93
#softskills
Post #11687
138
Forwarded from Варим МЛ
Ещё один пост про ИИ-агентов для разработки, на этот раз намного более конкретный, про Claude Code и мой опыт его использования. Гайд очень субъективный, могут быть косяки или глупости - очень уж быстро всё меняется.
И несколько объявлений:
- Очень ждём ваши ML-заявки на Codefest. Всё такой же майский, новосибирский и классный. По всем вопросам можно мне в личку - @crazyfrogspb
- Ура, мой доклад взяли на OpenTalks.AI в Белграде! Если будете там 18-20 февраля и хотите поболтать или покурить калик, пишите. Промокод на 25% - SpeakerColleagueOT2026
- Ура, я еду на Snow Base! Я обожаю South Hub, но в этом году туда, скорее всего, не попадаю, так что вдвойне радостно будет поехать. Это такой кэмп для всяких C-level и Head of в ML/DL/LLM/AI в горах Красной Поляны. Буду рад повидаться и там
#Жека #llm
И несколько объявлений:
- Очень ждём ваши ML-заявки на Codefest. Всё такой же майский, новосибирский и классный. По всем вопросам можно мне в личку - @crazyfrogspb
- Ура, мой доклад взяли на OpenTalks.AI в Белграде! Если будете там 18-20 февраля и хотите поболтать или покурить калик, пишите. Промокод на 25% - SpeakerColleagueOT2026
- Ура, я еду на Snow Base! Я обожаю South Hub, но в этом году туда, скорее всего, не попадаю, так что вдвойне радостно будет поехать. Это такой кэмп для всяких C-level и Head of в ML/DL/LLM/AI в горах Красной Поляны. Буду рад повидаться и там
#Жека #llm
Post #11686
131
#llm #agents #petproject
Post #11685
124
Forwarded from Quant Valerian
Практики управления на уровне культуры команды
Итак, прошло несколько месяцев с тех пор, как я попробовал новые методы в работе с командой. Пришло время подвести промежуточные итоги и поделиться с вами результатами и самими практиками.
Какие цели я перед собой ставил?
- члены команды должны уметь работать самостоятельно и принимать решения автономно
- члены команды должны быть проактивны и стремиться решить проблему, а не сделать задачу
- члены команды должны научиться самостоятельно принимать решения
- члены команды должны *хотеть* помочь друг другу
Что конкретно я сделал?
Ввёл ритуалы!
Последовательно. На первых двух неделях:
- Каждый день проговариваем правило: «молчание = остановка». Если застрял — спроси, дойди, допинай, эскалируй. Двигайся!
- Если есть позитивные примеры такого поведения — подсвечиваем сразу и публично хвалим.
- Каждый день, на дейлике, каждый человек во время рассказа о статусе по своей задаче должен объяснить, зачем мы делаем эту задачу.
- Если он не может объяснить, то пытается объяснить кто-то другой, например, я. Если мы не можем объяснить, то это повод разобраться, а надо ли эту задачу делать.
Немного попугайская история, потому что каждый день это часто, но длится такое всего две недели, так что можно и потерпеть.
Это позволило ребятам почувствовать, что они вообще делают. Как сказал наш проджект, начать строить храм, а не просто носить кирпичи. Отсылка к известной притче.
Кроме того, ребята привыкают слушать друг друга, потому что теперь гораздо понятнее, чем занят сосед.
На третьей неделе обновили ритуал:
- Теперь нужно было объяснить не только зачем мы делаем задачу, но и связывать свою задачу с целями команды.
Здесь уже появляется связка между членами команды. Теперь они начинают слушать внимательно, ведь сосед делает вещи, которые напрямую влияют на твои дела. Тут началась кооперация, дискуссии, появилось желание ребят помочь друг другу.
На четвертой неделе еще одно обновление:
- Теперь нужно объяснить, почему мы делаем именно эту задачу и почему именно сейчас.
- Одну задачу в неделю команда может выбрать и запланировать сама, без менеджеров и лидов.
Этот ритуал переводит фокус внимания сотрудников с операционки на достижение поставленных целей, учит понимать приоритезацию. Помогает постоянно держать в голове стратегические цели.
На этом этапе ребята уже несколько раз ловили меня на том, что запланировал какую-то фигню к работе. И мы меняли приоритеты или скоуп. Ведь у них больше контекста, они реально лучше понимают риски и эффекты от разных проблем и фич.
Здесь уже была активная кооперация, и команда попёрла к целям как паровоз!
Кроме того, по пятницам мы ввели ещё один ритуал. С одной стороны командообразующий, с другой позволявший мне, как руководителю, измерять температуру в команде:
- Я просил каждого высказать свое мнение, как мы поработали на этой неделе. Лучше или хуже, чем на прошлой? Что было хорошего, а что плохого? Кому хочется сказать спасибо?
Это добавило теплоты и ламповости, создало среду, где ребята могут быть уязвимы друг перед другом. Это основа построения доверия.
Мы сделали и ещё несколько изменений, например, довольно существенно изменили процессы в сторону канбана, посрезали излишнюю бюрократию, жестко лимитировали WIP по эпикам. Но по моему общению с ребятами на 1-1, именно ритуалы произвели наибольший эффект и очень понравились команде.
Попробуете у себя? Или у вас уже есть подобные штуки?
Итак, прошло несколько месяцев с тех пор, как я попробовал новые методы в работе с командой. Пришло время подвести промежуточные итоги и поделиться с вами результатами и самими практиками.
Какие цели я перед собой ставил?
- члены команды должны уметь работать самостоятельно и принимать решения автономно
- члены команды должны быть проактивны и стремиться решить проблему, а не сделать задачу
- члены команды должны научиться самостоятельно принимать решения
- члены команды должны *хотеть* помочь друг другу
Что конкретно я сделал?
Ввёл ритуалы!
Последовательно. На первых двух неделях:
- Каждый день проговариваем правило: «молчание = остановка». Если застрял — спроси, дойди, допинай, эскалируй. Двигайся!
- Если есть позитивные примеры такого поведения — подсвечиваем сразу и публично хвалим.
- Каждый день, на дейлике, каждый человек во время рассказа о статусе по своей задаче должен объяснить, зачем мы делаем эту задачу.
- Если он не может объяснить, то пытается объяснить кто-то другой, например, я. Если мы не можем объяснить, то это повод разобраться, а надо ли эту задачу делать.
Немного попугайская история, потому что каждый день это часто, но длится такое всего две недели, так что можно и потерпеть.
Это позволило ребятам почувствовать, что они вообще делают. Как сказал наш проджект, начать строить храм, а не просто носить кирпичи. Отсылка к известной притче.
Кроме того, ребята привыкают слушать друг друга, потому что теперь гораздо понятнее, чем занят сосед.
На третьей неделе обновили ритуал:
- Теперь нужно было объяснить не только зачем мы делаем задачу, но и связывать свою задачу с целями команды.
Здесь уже появляется связка между членами команды. Теперь они начинают слушать внимательно, ведь сосед делает вещи, которые напрямую влияют на твои дела. Тут началась кооперация, дискуссии, появилось желание ребят помочь друг другу.
На четвертой неделе еще одно обновление:
- Теперь нужно объяснить, почему мы делаем именно эту задачу и почему именно сейчас.
- Одну задачу в неделю команда может выбрать и запланировать сама, без менеджеров и лидов.
Этот ритуал переводит фокус внимания сотрудников с операционки на достижение поставленных целей, учит понимать приоритезацию. Помогает постоянно держать в голове стратегические цели.
На этом этапе ребята уже несколько раз ловили меня на том, что запланировал какую-то фигню к работе. И мы меняли приоритеты или скоуп. Ведь у них больше контекста, они реально лучше понимают риски и эффекты от разных проблем и фич.
Здесь уже была активная кооперация, и команда попёрла к целям как паровоз!
Кроме того, по пятницам мы ввели ещё один ритуал. С одной стороны командообразующий, с другой позволявший мне, как руководителю, измерять температуру в команде:
- Я просил каждого высказать свое мнение, как мы поработали на этой неделе. Лучше или хуже, чем на прошлой? Что было хорошего, а что плохого? Кому хочется сказать спасибо?
Это добавило теплоты и ламповости, создало среду, где ребята могут быть уязвимы друг перед другом. Это основа построения доверия.
Мы сделали и ещё несколько изменений, например, довольно существенно изменили процессы в сторону канбана, посрезали излишнюю бюрократию, жестко лимитировали WIP по эпикам. Но по моему общению с ребятами на 1-1, именно ритуалы произвели наибольший эффект и очень понравились команде.
Попробуете у себя? Или у вас уже есть подобные штуки?
Post #11684
82
#softskills #career
Post #11683
93
Forwarded from Датавиз в BI • Алиса Ручкина
Подборка мини-хаков в FineBI
Собрала подборку маленьких нюансов в FineBI, которые могут быть полезны для начинающих:
🤩Создать легенду для нескольких мер
🤩Создать ось для мер
🤩Расположить названия мер на оси Y горизонтально (аналогично, если нужен наклон «минус 90 градусов»)
🤩Убрать скролл в дашборде при использовании tab-компонента
🤩Убрать наклон подписей на горизонтальной оси
🤩Добавить сортировку по столбцу с типом «Число»
🤩Добавить сортировку по дате с типом «Текст»
🤩Добавить сортировку по мере, которая не отображена на графике
🤩Добавить интерактивную сортировку по мере
Большую мега-подборку по FineBI смотри здесь🔗
#подборка #база
Собрала подборку маленьких нюансов в FineBI, которые могут быть полезны для начинающих:
🤩Создать легенду для нескольких мер
🤩Создать ось для мер
🤩Расположить названия мер на оси Y горизонтально (аналогично, если нужен наклон «минус 90 градусов»)
🤩Убрать скролл в дашборде при использовании tab-компонента
🤩Убрать наклон подписей на горизонтальной оси
🤩Добавить сортировку по столбцу с типом «Число»
🤩Добавить сортировку по дате с типом «Текст»
🤩Добавить сортировку по мере, которая не отображена на графике
🤩Добавить интерактивную сортировку по мере
Большую мега-подборку по FineBI смотри здесь🔗
#подборка #база