Выложили на ютуб запись моего мок-интервью для Junior NLP Developer, посмотрите, если для вас актуально:
https://youtu.be/mCeZZvOq0qA
#ml #career
https://youtu.be/mCeZZvOq0qA
#ml #career
Про бескорыстие и разочарование
Сегодня хочется честно поговорить вот на какую тему. Когда я только начинал свой путь в IT, мне помогали более опытные коллеги. Они давали полезные советы, рекомендации, оценивали мой уровень, ставили эндорсы на линкедине. Они делали это вполне бескорыстно, и я был и остаюсь им очень благодарен. Их вклад в моё развитие сформировал во мне убеждение, что я тоже должен по мере сил помогать сообществу, вносить свою лепту. Отчасти поэтому я начал вести этот блог (ого, уже четыре месяца прошло). По этой же причине много раз безвозмездно помогал знакомым: сориентироваться в мире IT, привлекательно оформить резюме, подготовиться к собеседованиям, сформировать индивидуальный план обучения и т.д. Некоторых людей рекомендовал на конкретные вакансии в конкретные компании, и примерно в 50% случаев они успешно туда устраивались.
Но вы знаете, со временем мне становится всё сложнее помогать. Казалось бы, что может измениться? Я же не перестал считать это важным. Думаю, есть несколько факторов, но один из них стал для меня очевиден совсем недавно: накопление негативного опыта. Ты предложил кому-то бесплатно помочь с резюме и поиском работы, человек вроде бы с радостью согласился, но потом просто без объяснений пропал с радаров. Ты в свободное от основной работы время вкладываешься в студентов, читаешь в выходные и по ночам их курсовые и дипломные работы, даже помогаешь им решать проблемы с учёбой, возникающие нередко из-за их же раздолбайства, а они в ответ срывают дедлайны и примитивно врут.
Думаю, проблема во многом во мне самом. Наверное, помогая "бескорыстно", я не должен ожидать ничего взамен, ведь тогда это уже будет не бескорыстно? Но я, когда возникают описанные выше ситуации, чувствую себя либо ненужным, либо навязчивым, либо и тем и другим сразу. В результате приходит разочарование и желание опустить руки. И понятно, что в помощи людям у меня был не только негативный опыт, но и много позитивного тоже. Но как раз так совпало, что за последнее время было сразу несколько неприятных эпизодов, поэтому захотелось поднять эту тему.
Среди подписчиков моего скромного канала есть весьма опытные коллеги. Поделитесь, бывают ли у вас похожие мысли и ощущения? Если да, как справляетесь и что посоветуете? Если нет, что я делаю не так?
Тем людям, у которых пока не очень много опыта или кто ещё только начинает свой путь в IT, я хочу посоветовать / пожелать не отказываться от помощи, если вам её предлагает кто-то более опытный. А если вам бесплатно помогли - потратьте немного времени на слова благодарности. Мне кажется, этим вы тоже вносите свой вклад в развитие сообщества: вы поддерживаете мотивацию тех, кто вам помогает, а значит, эти люди будут, скорее всего, помогать и дальше.
Для себя же я решил, что буду реже предлагать знакомым свою помощь. Вместо этого завёл профиль эксперта на Хабр.Карьере - если кто захочет, могут обращаться через эту площадку и консультироваться за деньги, так, наверное, будет честнее. Кстати, уже один раз проконсультировал через эту платформу, очень положительный опыт.
Сегодня хочется честно поговорить вот на какую тему. Когда я только начинал свой путь в IT, мне помогали более опытные коллеги. Они давали полезные советы, рекомендации, оценивали мой уровень, ставили эндорсы на линкедине. Они делали это вполне бескорыстно, и я был и остаюсь им очень благодарен. Их вклад в моё развитие сформировал во мне убеждение, что я тоже должен по мере сил помогать сообществу, вносить свою лепту. Отчасти поэтому я начал вести этот блог (ого, уже четыре месяца прошло). По этой же причине много раз безвозмездно помогал знакомым: сориентироваться в мире IT, привлекательно оформить резюме, подготовиться к собеседованиям, сформировать индивидуальный план обучения и т.д. Некоторых людей рекомендовал на конкретные вакансии в конкретные компании, и примерно в 50% случаев они успешно туда устраивались.
Но вы знаете, со временем мне становится всё сложнее помогать. Казалось бы, что может измениться? Я же не перестал считать это важным. Думаю, есть несколько факторов, но один из них стал для меня очевиден совсем недавно: накопление негативного опыта. Ты предложил кому-то бесплатно помочь с резюме и поиском работы, человек вроде бы с радостью согласился, но потом просто без объяснений пропал с радаров. Ты в свободное от основной работы время вкладываешься в студентов, читаешь в выходные и по ночам их курсовые и дипломные работы, даже помогаешь им решать проблемы с учёбой, возникающие нередко из-за их же раздолбайства, а они в ответ срывают дедлайны и примитивно врут.
Думаю, проблема во многом во мне самом. Наверное, помогая "бескорыстно", я не должен ожидать ничего взамен, ведь тогда это уже будет не бескорыстно? Но я, когда возникают описанные выше ситуации, чувствую себя либо ненужным, либо навязчивым, либо и тем и другим сразу. В результате приходит разочарование и желание опустить руки. И понятно, что в помощи людям у меня был не только негативный опыт, но и много позитивного тоже. Но как раз так совпало, что за последнее время было сразу несколько неприятных эпизодов, поэтому захотелось поднять эту тему.
Среди подписчиков моего скромного канала есть весьма опытные коллеги. Поделитесь, бывают ли у вас похожие мысли и ощущения? Если да, как справляетесь и что посоветуете? Если нет, что я делаю не так?
Тем людям, у которых пока не очень много опыта или кто ещё только начинает свой путь в IT, я хочу посоветовать / пожелать не отказываться от помощи, если вам её предлагает кто-то более опытный. А если вам бесплатно помогли - потратьте немного времени на слова благодарности. Мне кажется, этим вы тоже вносите свой вклад в развитие сообщества: вы поддерживаете мотивацию тех, кто вам помогает, а значит, эти люди будут, скорее всего, помогать и дальше.
Для себя же я решил, что буду реже предлагать знакомым свою помощь. Вместо этого завёл профиль эксперта на Хабр.Карьере - если кто захочет, могут обращаться через эту площадку и консультироваться за деньги, так, наверное, будет честнее. Кстати, уже один раз проконсультировал через эту платформу, очень положительный опыт.
Про одну неудачу
#career
На прошлой неделе у нас в МТС ИИ было необычное внутреннее мероприятие под названием Fuckup Evening. На нём топы (включая генерального директора) и лиды рассказывали о своих прошлых неудачах, а объединяющая тема была "управление командой". Такое у нас проводится уже не в первый раз, и это классно: неудачи тем и ценны, что из них можно извлечь важные уроки. А заодно и посмеяться - наши рассказчики не скупятся на юмор.
Не думайте, я не буду вам пересказывать истории с Fuckup Evening. Это замечательное мероприятие навело меня на мысль написать здесь об одной своей неудаче. Дело в том, что с месяц назад я по собственной инициативе перевёлся с должности тимлида обратно в инженеры. Тимлидом я пробыл в этой компании всего лишь 7 месяцев. Это можно смело назвать неудачей, ведь и я, и мои руководители изначально рассчитывали на то, что я проработаю на этой должности значительно дольше.
Причиной перехода стало осознание некоторых важных вещей, ранее ускользавших от меня. Поделюсь с вами - может, кого-то это наведёт на собственные инсайты.
1. Мне говорили, что я хороший тимлид, но сам я не получал удовольствия от этой работы. Оказывается, даже если у тебя что-то получается, но сам процесс не приносит тебе удовлетворения, - со временем этим будет всё труднее продолжать заниматься. Без искренней увлечённости эмоциональные и психологические затраты на твою деятельность будут постепенно расти. Именно поэтому, кстати, я скептически отношусь к тому, когда люди идут в IT-профессии за деньгами, а не "по любви" - у такой мотивации весьма ограниченный ресурс, и об этом важно знать заранее.
2. Я также понял, что общение с людьми, а особенно умными и профессиональными, - это прекрасно, но иногда его бывает слишком много, по крайней мере для меня. Я вообще-то интроверт, и никуда от этого (надолго) не денешься.
Моя ошибка была в том, что я не сразу извлёк эти уроки, не сразу смог себе признаться в этих вещах. Я ведь не в первый раз наступил на подобные грабли: мне и раньше доводилось работать тимлидом. Тогда мне тоже не понравилось, но почему-то я решил, что в этот раз всё будет по-другому. Также я медлил с принятием решения об уходе с должности, потому что мне было страшно, что руководство компании плохо это воспримет. К счастью, мои руководители меня, наоборот, поддержали. А вернувшись к любимым задачам с кодом и экспериментами, я снова почувствовал радость от работы.
Напоследок, неожиданный поворот в этой истории: буквально на днях пришли с начальством к тому, что я всё-таки буду техлидом, а не ведущим разработчиком, как до тимлидства. Это такой компромиссный вариант. Общения и административных обязанностей будет меньше, чем у тимлида, но зона ответственности всё-таки шире, чем у инженера.
Вот, поделился, надеюсь, кому-то из вас это релевантно / интересно. :)
#career
На прошлой неделе у нас в МТС ИИ было необычное внутреннее мероприятие под названием Fuckup Evening. На нём топы (включая генерального директора) и лиды рассказывали о своих прошлых неудачах, а объединяющая тема была "управление командой". Такое у нас проводится уже не в первый раз, и это классно: неудачи тем и ценны, что из них можно извлечь важные уроки. А заодно и посмеяться - наши рассказчики не скупятся на юмор.
Не думайте, я не буду вам пересказывать истории с Fuckup Evening. Это замечательное мероприятие навело меня на мысль написать здесь об одной своей неудаче. Дело в том, что с месяц назад я по собственной инициативе перевёлся с должности тимлида обратно в инженеры. Тимлидом я пробыл в этой компании всего лишь 7 месяцев. Это можно смело назвать неудачей, ведь и я, и мои руководители изначально рассчитывали на то, что я проработаю на этой должности значительно дольше.
Причиной перехода стало осознание некоторых важных вещей, ранее ускользавших от меня. Поделюсь с вами - может, кого-то это наведёт на собственные инсайты.
1. Мне говорили, что я хороший тимлид, но сам я не получал удовольствия от этой работы. Оказывается, даже если у тебя что-то получается, но сам процесс не приносит тебе удовлетворения, - со временем этим будет всё труднее продолжать заниматься. Без искренней увлечённости эмоциональные и психологические затраты на твою деятельность будут постепенно расти. Именно поэтому, кстати, я скептически отношусь к тому, когда люди идут в IT-профессии за деньгами, а не "по любви" - у такой мотивации весьма ограниченный ресурс, и об этом важно знать заранее.
2. Я также понял, что общение с людьми, а особенно умными и профессиональными, - это прекрасно, но иногда его бывает слишком много, по крайней мере для меня. Я вообще-то интроверт, и никуда от этого (надолго) не денешься.
Моя ошибка была в том, что я не сразу извлёк эти уроки, не сразу смог себе признаться в этих вещах. Я ведь не в первый раз наступил на подобные грабли: мне и раньше доводилось работать тимлидом. Тогда мне тоже не понравилось, но почему-то я решил, что в этот раз всё будет по-другому. Также я медлил с принятием решения об уходе с должности, потому что мне было страшно, что руководство компании плохо это воспримет. К счастью, мои руководители меня, наоборот, поддержали. А вернувшись к любимым задачам с кодом и экспериментами, я снова почувствовал радость от работы.
Напоследок, неожиданный поворот в этой истории: буквально на днях пришли с начальством к тому, что я всё-таки буду техлидом, а не ведущим разработчиком, как до тимлидства. Это такой компромиссный вариант. Общения и административных обязанностей будет меньше, чем у тимлида, но зона ответственности всё-таки шире, чем у инженера.
Вот, поделился, надеюсь, кому-то из вас это релевантно / интересно. :)
Капитан Неочевидность
#soft_skills #career
Есть один важный фактор успеха в IT (и не только), о котором многие вообще не думают. Ни за что не догадаетесь, о чём я. Эксперты часто говорят о том, что нужно постоянно развиваться, читать техническую литературу, следить за трендами, пробовать применять новые инструменты и библиотеки в реальных проектах. Всё так, это очень важно. Для этого нужна высокая мотивация - но и с мотивацией вроде бы всё более-менее ясно, о ней также довольно много говорят. Так чего же ещё не хватает?
Как ни странно, многим людям даже при наличии сильных хард-скиллов и мотивации отчаянно не хватает довольно банального и скучного умения: ясно излагать свои мысли. Именно это порой становится барьером в развитии. Причём штука в том, что человеку бывает сложно догадаться, в чём на самом деле проблема. И кажется, на удалёнке такое бывает чаще, чем при работе в офисе.
Например, младший специалист Вася задаёт много вопросов по своим задачам более опытной коллеге Зине. Коммуникация не клеится. Вася думает, что Зина просто не хочет ему помогать. Зина думает, что Вася "тупой", потому что она же ему всё написала, а он опять спрашивает о том же самом. На самом деле оба просто не умеют понятно изъясняться. Вася не может чётко сформулировать свои затруднения. Зина не может внятно объяснить, что нужно сделать, чтобы решить проблему. В результате страдают тоже оба. Вася перестаёт обращаться за помощью и слишком медленно закрывает свои задачи. Зина не развивается как ментор, а ей бы хотелось однажды стать тимлидом.
Почему такое происходит? Иногда из-за высокой занятости и большого объёма коммуникации по работе. Иногда из-за разницы в бэкграунде и нежелания посмотреть на ситуацию глазами другого человека. Иногда, наверное, просто из-за небрежности.
Думаю, что многих подобных проблем можно избежать, если задаться целью быть более понятным другим людям. Смею утверждать, что любой человек при желании может найти в этом для себя точки роста. Эффективная коммуникация всё делает лучше. Быть понятными полезно и продуктовым менеджерам, и бизнес-аналитикам, и разработчикам, и тестировщикам, не говоря уже о технических писателях и "эйчарах". Взаимодействие с вами будет более продуктивным и приятным, а это ценится и приносит свои дивиденды.
Некоторые конкретные рекомендации:
1. Старайтесь развивать навык "взгляда со стороны" на то, как вы излагаете свои мысли (не важно, устно или письменно). Наблюдайте за реакцией собеседников. Если чувствуете, что вас не понимают, делайте выводы, пробуйте перефразировать. Если объясняете что-то, не спешите, не пренебрегайте важными подробностями. Не злоупотребляйте длинными и запутанными предложениями. От наблюдения и анализа к практике, это же такой же навык, как и другие. Всё обязательно получится.
2. Иногда советуют "объяснять как своей бабушке". Наверное, это слишком радикально. Нужно искать баланс между ясностью и избыточностью, краткостью и детализацией. Я вот иногда бываю склонен к избыточности. Это старая преподавательская привычка, с которой я пытаюсь бороться. И всё же кажется, что лучше переобъяснить, чем недообъяснить, особенно если речь о чём-то действительно важном.
3. Если это не вы, а ваш собеседник неясно выражается, а предмет разговора имеет значение, - не делайте вид, что вам всё понятно. Сформулируйте, что вы поняли, задайте уточняющие вопросы. Если сомневаетесь - лучше переспросить. Кто-то боится раздражить этим коллег, но риски обычно выше, если не переспросить и неправильно что-то понять.
А вы сталкиваетесь с подобными проблемами? Получается ли у вас доносить свои мысли до собеседников? Как бы вы посоветовали улучшать коммуникативные навыки?
#soft_skills #career
Есть один важный фактор успеха в IT (и не только), о котором многие вообще не думают. Ни за что не догадаетесь, о чём я. Эксперты часто говорят о том, что нужно постоянно развиваться, читать техническую литературу, следить за трендами, пробовать применять новые инструменты и библиотеки в реальных проектах. Всё так, это очень важно. Для этого нужна высокая мотивация - но и с мотивацией вроде бы всё более-менее ясно, о ней также довольно много говорят. Так чего же ещё не хватает?
Как ни странно, многим людям даже при наличии сильных хард-скиллов и мотивации отчаянно не хватает довольно банального и скучного умения: ясно излагать свои мысли. Именно это порой становится барьером в развитии. Причём штука в том, что человеку бывает сложно догадаться, в чём на самом деле проблема. И кажется, на удалёнке такое бывает чаще, чем при работе в офисе.
Например, младший специалист Вася задаёт много вопросов по своим задачам более опытной коллеге Зине. Коммуникация не клеится. Вася думает, что Зина просто не хочет ему помогать. Зина думает, что Вася "тупой", потому что она же ему всё написала, а он опять спрашивает о том же самом. На самом деле оба просто не умеют понятно изъясняться. Вася не может чётко сформулировать свои затруднения. Зина не может внятно объяснить, что нужно сделать, чтобы решить проблему. В результате страдают тоже оба. Вася перестаёт обращаться за помощью и слишком медленно закрывает свои задачи. Зина не развивается как ментор, а ей бы хотелось однажды стать тимлидом.
Почему такое происходит? Иногда из-за высокой занятости и большого объёма коммуникации по работе. Иногда из-за разницы в бэкграунде и нежелания посмотреть на ситуацию глазами другого человека. Иногда, наверное, просто из-за небрежности.
Думаю, что многих подобных проблем можно избежать, если задаться целью быть более понятным другим людям. Смею утверждать, что любой человек при желании может найти в этом для себя точки роста. Эффективная коммуникация всё делает лучше. Быть понятными полезно и продуктовым менеджерам, и бизнес-аналитикам, и разработчикам, и тестировщикам, не говоря уже о технических писателях и "эйчарах". Взаимодействие с вами будет более продуктивным и приятным, а это ценится и приносит свои дивиденды.
Некоторые конкретные рекомендации:
1. Старайтесь развивать навык "взгляда со стороны" на то, как вы излагаете свои мысли (не важно, устно или письменно). Наблюдайте за реакцией собеседников. Если чувствуете, что вас не понимают, делайте выводы, пробуйте перефразировать. Если объясняете что-то, не спешите, не пренебрегайте важными подробностями. Не злоупотребляйте длинными и запутанными предложениями. От наблюдения и анализа к практике, это же такой же навык, как и другие. Всё обязательно получится.
2. Иногда советуют "объяснять как своей бабушке". Наверное, это слишком радикально. Нужно искать баланс между ясностью и избыточностью, краткостью и детализацией. Я вот иногда бываю склонен к избыточности. Это старая преподавательская привычка, с которой я пытаюсь бороться. И всё же кажется, что лучше переобъяснить, чем недообъяснить, особенно если речь о чём-то действительно важном.
3. Если это не вы, а ваш собеседник неясно выражается, а предмет разговора имеет значение, - не делайте вид, что вам всё понятно. Сформулируйте, что вы поняли, задайте уточняющие вопросы. Если сомневаетесь - лучше переспросить. Кто-то боится раздражить этим коллег, но риски обычно выше, если не переспросить и неправильно что-то понять.
А вы сталкиваетесь с подобными проблемами? Получается ли у вас доносить свои мысли до собеседников? Как бы вы посоветовали улучшать коммуникативные навыки?
На работе попросили записать короткое видео о том, что такое машинное обучение. Формат специфический: короткий клип, всего одна минута. Много за 60 секунд не расскажешь, но надеюсь, что будет небесполезно для совсем начинающих, кто ещё ничего не знает о машинном обучении. Для меня это был интересный первый опыт. Ролик здесь, если кому любопытно:
https://vk.com/clip-212087550_456239074?c=0
#ml
https://vk.com/clip-212087550_456239074?c=0
#ml
VK
MTS AI on VK Clips
Как машинное обучение влияет на
Первый раз опубликовался в Форбс!
Это opinion piece на одну актуальную тему, связанную с генеративным AI. Вместе с Сергеем Загоруйко, руководителем направления фундаментальных исследований в моей компании, порассуждали о том, к каким проблемам может привести наводнение Интернета контентом, произведённым нейросетями, и как с этими проблемами бороться.
#ml
Это opinion piece на одну актуальную тему, связанную с генеративным AI. Вместе с Сергеем Загоруйко, руководителем направления фундаментальных исследований в моей компании, порассуждали о том, к каким проблемам может привести наводнение Интернета контентом, произведённым нейросетями, и как с этими проблемами бороться.
#ml
Forbes.ru
Нейросетевой коллапс: почему вскоре может остановиться развитие алгоритмов ИИ
По оценке ряда ученых, уже скоро качество нейросетей может стремительно деградировать. Причиной этого станет обилие в сети контента, ранее сгенерированного ИИ-моделями. О том, станут ли нейросети в будущем бесполезными, рассуждают руководитель направ
Вы могли заметить, что я сменил аватарку канала. Предыдущая была хоть и довольно милая, но обычная стоковая фотка, нагугленная по запросу "плюшевый питон". Новая же аватарка - не только эксклюзив, но ещё и с историей. Иллюстрацию специально для моего канала нарисовала акварелью Наташа Соло, руководитель нижегородского комикс-клуба "Горький комикс". Ребята выпустили уже семь замечательных сборников авторских арт-новелл, теперь на очереди восьмой выпуск. Он называется "Эпоха открытий" и посвящён стимпанку. Когда я полуслучайно узнал об этом проекте, не смог его не поддержать на краудфандинговой платформе. Во-первых, люблю комиксы, во-вторых, неравнодушен к стимпанку, ну а в-третьих, всегда радуют такие крутые инициативы в родном Нижнем Новгороде. Кстати, средства на печать сборника были благополучно собраны - план даже был перевыполнен почти в три раза. Если вам интересно узнать о проекте более подробно, делюсь ссылкой: https://planeta.ru/campaigns/epoha_otkrytyi. В сборнике будет страница, посвящённая каналу "Плюшевый Питон", и я с нетерпением жду, когда получу свой экземпляр. Такой вот немного неожиданный коллаб получился с нижегородским комикс-сообществом.
Planeta.ru
Печать сборника комиксов «Эпоха открытий» | Planeta
Авторы с разной совершенно уникальной графикой создали истории о мире пара и шестерёнок. Приключения, наука, феерия механических деталей - вот что внутри!
Издадим сборник вместе!
Издадим сборник вместе!
Одна из читательниц блога задала классный вопрос в комментариях (кстати, напоминаю, что вы всегда можете задавать мне интересующие вас вопросы под постами или просто писать мне в личку, контакты есть в описании канала). Я подумал, что на этот вопрос будет полезно ответить развёрнуто, в формате отдельного поста, потому что ответ затронет важную для меня тему, на которую я всё равно хотел в ближайшее время написать.
Итак, меня спросили: "расскажите, пожалуйста, про языки, которые используются в NLP-разработке и ML. Что встречалось на Ваших местах работы или у Ваших знакомых? Большинство проектов, которые я находила на эту тематику, — на python, однако кажется, что знание и умение использовать один язык для этих целей — не самое эффективное и правильное решение. Есть же языки побыстрее всё-таки"
---
Коротенькая ремарка. Некоторые пишут "на Python", другие "на Пайтоне", третьи "на Питоне". Мне привычнее и больше нравится "на Питоне", простите, если кого-то это раздражает)
---
Часть 1. Медленно, но быстро
#python #ml
Собственно для ML-разработки, действительно, почти всегда используется Питон. Это во многом связано с тем, что для машинного обучения в экосистеме Питона уже есть мощнейший набор фреймворков, библиотек и прочих инструментов. Да и не только для машинного обучения - про Питон говорят, что он "идёт с батарейками в комплекте". Представьте, что вам по работе нужно обучить ML-модель - например, классификатор токсичности для фильтрации оскорбительных высказываний. Если вы будете делать это на Питоне, у вас уже есть готовые библиотеки для всех этапов работы: загрузка и разведочный анализ данных, очистка и подготовка данных, обучение моделей (как "классических", так и более современных, основанных на трансформерах), оценка их качества, визуализация результатов, анализ ошибок модели, выявление примеров, неправильно размеченных людьми в обучающей выборке и т.д. На других языках такого изобилия инструментов нет, вам бы пришлось реализовывать всё или почти всё это с нуля.
Таким образом, важно учитывать не только быстродействие самого языка, но и скорость разработки на нём. Питон довольно лаконичен, его синтаксис не слишком перегружен скобками и прочими знаками препинания, а эксперты в языке всячески поощряют читаемость кода (например, об этом пишут автор книги "Effective Python" Brett Slatkin и автор книги "Robust Python" Patrick Viafore). Плюс отличный набор готовых библиотек и инструментов - вот и секрет его успеха. Раньше Питон называли "вторым лучшим языком для чего угодно", но сейчас по популярности этот язык занимает первое место в мире. Да и с "медленностью" Питона не всё так однозначно. Версия 3.10 значительно быстрее, чем 3.9, а 3.11 сильно обгоняет 3.10. Посмотрим, что будет с 3.12 и дальше. К тому же, активно развиваются всякие специальные инструменты для ускорения кода на Питоне.
Итак, меня спросили: "расскажите, пожалуйста, про языки, которые используются в NLP-разработке и ML. Что встречалось на Ваших местах работы или у Ваших знакомых? Большинство проектов, которые я находила на эту тематику, — на python, однако кажется, что знание и умение использовать один язык для этих целей — не самое эффективное и правильное решение. Есть же языки побыстрее всё-таки"
---
Коротенькая ремарка. Некоторые пишут "на Python", другие "на Пайтоне", третьи "на Питоне". Мне привычнее и больше нравится "на Питоне", простите, если кого-то это раздражает)
---
Часть 1. Медленно, но быстро
#python #ml
Собственно для ML-разработки, действительно, почти всегда используется Питон. Это во многом связано с тем, что для машинного обучения в экосистеме Питона уже есть мощнейший набор фреймворков, библиотек и прочих инструментов. Да и не только для машинного обучения - про Питон говорят, что он "идёт с батарейками в комплекте". Представьте, что вам по работе нужно обучить ML-модель - например, классификатор токсичности для фильтрации оскорбительных высказываний. Если вы будете делать это на Питоне, у вас уже есть готовые библиотеки для всех этапов работы: загрузка и разведочный анализ данных, очистка и подготовка данных, обучение моделей (как "классических", так и более современных, основанных на трансформерах), оценка их качества, визуализация результатов, анализ ошибок модели, выявление примеров, неправильно размеченных людьми в обучающей выборке и т.д. На других языках такого изобилия инструментов нет, вам бы пришлось реализовывать всё или почти всё это с нуля.
Таким образом, важно учитывать не только быстродействие самого языка, но и скорость разработки на нём. Питон довольно лаконичен, его синтаксис не слишком перегружен скобками и прочими знаками препинания, а эксперты в языке всячески поощряют читаемость кода (например, об этом пишут автор книги "Effective Python" Brett Slatkin и автор книги "Robust Python" Patrick Viafore). Плюс отличный набор готовых библиотек и инструментов - вот и секрет его успеха. Раньше Питон называли "вторым лучшим языком для чего угодно", но сейчас по популярности этот язык занимает первое место в мире. Да и с "медленностью" Питона не всё так однозначно. Версия 3.10 значительно быстрее, чем 3.9, а 3.11 сильно обгоняет 3.10. Посмотрим, что будет с 3.12 и дальше. К тому же, активно развиваются всякие специальные инструменты для ускорения кода на Питоне.
Часть 2. Специализируй это
#career
Благодаря популярной сейчас архитектуре приложений - микросервисной - компоненты одного приложения вообще могут быть реализованы на разных языках программирования. Поэтому фронтенд может быть написан, например, на React, бэкенд на .Net, но приложение всё равно может использовать ML-сервисы, написанные на Питоне. Хорошо, но может быть, одному и тому же разработчику придётся заниматься и ML, и бэкенд-разработкой, и тогда не получится использовать только Питон? Выходит, нужно прямо сейчас бежать изучать и другие языки?
Во-первых, Питон сейчас востребован и в бэкенд-разработке. Во-вторых, круг обязанностей сильно зависит от специфики компании. Когда в компании мало разработчиков, действительно, одному и тому же сотруднику часто приходится заниматься всем понемногу: и модели обучать, и бэкенд писать, и покосившийся фронтенд поправлять, и инфраструктуру налаживать. Особенно это характерно для маленьких стартапов с числом сотрудников менее 20 человек. Я с уважением отношусь к таким разносторонним людям, но в больших компаниях обычно востребованы более узкие специалисты. Разработчик из стартапа просто не пройдёт техническое собеседование на позицию ML-иженера в крупной компании. Его будут глубоко и подробно спрашивать по ML, а у него не было возможности хорошо погрузиться в эту область из-за того, что приходилось работать в режиме "всё, везде и сразу".
Именно поэтому я рекомендую начинающим пробовать разные области разработки, но не слишком задерживаться в роли "мастера на все руки". Важно в какой-то момент остановиться и выбрать что-то одно, что нравится больше всего, и большую часть усилий направить именно на это. Мир больше ценит и награждает узких специалистов, чем умеющих всё по чуть-чуть. Из-за стремительного развития технологий прошли времена универсальных "программистов". Сейчас невозможно быть полноценным экспертом одновременно в бэкенде, фронтенде, машинном обучении и девопсе. Поэтому зачастую крутые компании ищут разработчиков под конкретные, узкие задачи. Это может не всем нравиться, но ситуация на рынке сейчас такова: можно либо пойти в маленький стартап и заниматься там за небольшие деньги всем понемногу (как по мне, это дикий стресс), либо встать на путь экспертности в относительно узкой области и находить более оплачиваемые роли в престижных компаниях. Поэтому если хотите мой совет, вот он: найдите пересечение между тем, что вам нравится, что у вас получается и что востребовано, - и вкладывайтесь в своё развитие именно в этом. Легко не будет, но оно того стоит.
#career
Благодаря популярной сейчас архитектуре приложений - микросервисной - компоненты одного приложения вообще могут быть реализованы на разных языках программирования. Поэтому фронтенд может быть написан, например, на React, бэкенд на .Net, но приложение всё равно может использовать ML-сервисы, написанные на Питоне. Хорошо, но может быть, одному и тому же разработчику придётся заниматься и ML, и бэкенд-разработкой, и тогда не получится использовать только Питон? Выходит, нужно прямо сейчас бежать изучать и другие языки?
Во-первых, Питон сейчас востребован и в бэкенд-разработке. Во-вторых, круг обязанностей сильно зависит от специфики компании. Когда в компании мало разработчиков, действительно, одному и тому же сотруднику часто приходится заниматься всем понемногу: и модели обучать, и бэкенд писать, и покосившийся фронтенд поправлять, и инфраструктуру налаживать. Особенно это характерно для маленьких стартапов с числом сотрудников менее 20 человек. Я с уважением отношусь к таким разносторонним людям, но в больших компаниях обычно востребованы более узкие специалисты. Разработчик из стартапа просто не пройдёт техническое собеседование на позицию ML-иженера в крупной компании. Его будут глубоко и подробно спрашивать по ML, а у него не было возможности хорошо погрузиться в эту область из-за того, что приходилось работать в режиме "всё, везде и сразу".
Именно поэтому я рекомендую начинающим пробовать разные области разработки, но не слишком задерживаться в роли "мастера на все руки". Важно в какой-то момент остановиться и выбрать что-то одно, что нравится больше всего, и большую часть усилий направить именно на это. Мир больше ценит и награждает узких специалистов, чем умеющих всё по чуть-чуть. Из-за стремительного развития технологий прошли времена универсальных "программистов". Сейчас невозможно быть полноценным экспертом одновременно в бэкенде, фронтенде, машинном обучении и девопсе. Поэтому зачастую крутые компании ищут разработчиков под конкретные, узкие задачи. Это может не всем нравиться, но ситуация на рынке сейчас такова: можно либо пойти в маленький стартап и заниматься там за небольшие деньги всем понемногу (как по мне, это дикий стресс), либо встать на путь экспертности в относительно узкой области и находить более оплачиваемые роли в престижных компаниях. Поэтому если хотите мой совет, вот он: найдите пересечение между тем, что вам нравится, что у вас получается и что востребовано, - и вкладывайтесь в своё развитие именно в этом. Легко не будет, но оно того стоит.
А вы знали про confident learning?
#ml
"Уверенное обучение" в контексте machine learning - что бы это могло значить? 🤔 Почти все алгоритмы машинного обучения основаны на предположении, что обучающие данные чисты и заслуживают доверия. Однако на самом деле в них часто закрадываются ошибки разметки, которые плохо влияют на обучение моделей. Confident learning - это относительно новый подход к обучению моделей в русле data-centric ML. Он объединяет в себе различные практики и трюки для обнаружения ошибок разметки и эффективного обучения моделей несмотря на присутствие в данных таких ошибок.
Зачем знать про этот подход? Его можно применять в почти любых задачах машинного обучения с учителем (мультикласс- и мультилейбл-классификация, регрессия) в NLP, CV, работе со структурированными данными. Подход автоматически определяет ошибки в разметке, не требуя подбора гиперпараметров (использует кросс-валидацию для предсказания вероятностей в режиме out-of-sample). После этого можно обучить модель только на данных, не содержащих ошибок разметки - как правило, такая модель будет более точной. 🤓
Confident learning хорошо обоснован теоретически, также есть реализация его методов в библиотеке cleanlab со свободной лицензией. Статья, описывающая подход, имеет 400+ цитирований с 2021 года, а репозиторий cleanlab - 6,2К звёзд. При этом подход не то чтобы очень широко известен. Вы можете применить confident learning в своих рабочих задачах (будем честны, как часто мы видим идеально размеченные датасеты?), а также блеснуть эрудицией на собеседованиях.
Например, с cleanlab можно одной строчкой кода запустить диагностику датасета и получить отчёт о возможных проблемах:
Для тех, кто дочитал до конца 🙏, небольшой бонус - курс 2023 года от MIT по датацентричному ИИ с большим количеством лабораторных работ. Очень рекомендую!
#ml
"Уверенное обучение" в контексте machine learning - что бы это могло значить? 🤔 Почти все алгоритмы машинного обучения основаны на предположении, что обучающие данные чисты и заслуживают доверия. Однако на самом деле в них часто закрадываются ошибки разметки, которые плохо влияют на обучение моделей. Confident learning - это относительно новый подход к обучению моделей в русле data-centric ML. Он объединяет в себе различные практики и трюки для обнаружения ошибок разметки и эффективного обучения моделей несмотря на присутствие в данных таких ошибок.
Зачем знать про этот подход? Его можно применять в почти любых задачах машинного обучения с учителем (мультикласс- и мультилейбл-классификация, регрессия) в NLP, CV, работе со структурированными данными. Подход автоматически определяет ошибки в разметке, не требуя подбора гиперпараметров (использует кросс-валидацию для предсказания вероятностей в режиме out-of-sample). После этого можно обучить модель только на данных, не содержащих ошибок разметки - как правило, такая модель будет более точной. 🤓
Confident learning хорошо обоснован теоретически, также есть реализация его методов в библиотеке cleanlab со свободной лицензией. Статья, описывающая подход, имеет 400+ цитирований с 2021 года, а репозиторий cleanlab - 6,2К звёзд. При этом подход не то чтобы очень широко известен. Вы можете применить confident learning в своих рабочих задачах (будем честны, как часто мы видим идеально размеченные датасеты?), а также блеснуть эрудицией на собеседованиях.
Например, с cleanlab можно одной строчкой кода запустить диагностику датасета и получить отчёт о возможных проблемах:
from cleanlab.dataset import health_summary
health_summary(labels, pred_probs)
Ещё один короткий пример для классификации текстов:cl = CleanLearning(model, cv_n_folds=cv_n_folds)
label_issues = cl.find_label_issues(
X=train_texts,
labels=train_labels,
)
cl.fit(
X=train_texts,
labels=train_labels,
label_issues=cl.get_label_issues(),
)
При обучении новой модели на очищенных от ошибок данных будьте внимательны к тому, как вы оцениваете итоговый результат. Если оценивать на тестовом сете, содержащем ошибки разметки, то эффект от confident learning не будет заметен. Авторы библиотеки дают рекомендации, как правильно применять этот подход, в понятных тьюториалах и FAQ.Для тех, кто дочитал до конца 🙏, небольшой бонус - курс 2023 года от MIT по датацентричному ИИ с большим количеством лабораторных работ. Очень рекомендую!
Сегодня выступил перед старшеклассниками на летней олимпиадной школе. Рассказывал про ИИ и почему он не отберёт у них работу в будущем. Или всё-таки отберёт? 🤔 Судя по моему выражению лица на второй фотке, всё не так однозначно 😁
Ребята большие молодцы, с интересом слушали и задавали много классных вопросов. Мой самый любимый - "А зачем тогда нужны люди?" 🙃
Ребята большие молодцы, с интересом слушали и задавали много классных вопросов. Мой самый любимый - "А зачем тогда нужны люди?" 🙃
Не так давно составлял индивидуальный учебный план для одного из подписчиков, который хотел перейти в сферу data science / machine learning. План был сильно "заточен" под этого конкретного человека и его бэкграунд. Потом я подумал, что будет полезно также опубликовать здесь обобщённый учебный план для тех, кто хотел бы заниматься машинным обучением, но не знает, с чего начать. Надеюсь, кому-то из вас будет полезно! Смотрите следующий пост.
#ml #career
#ml #career
Учебный план для погружения в data science и machine learning с нуля
Включает области, которые нужно "прокачать", кратко - зачем это нужно, а также ссылки на ресурсы (старался подбирать бесплатные и русскоязычные).
1) Программирование на Питоне
1.1) Базовый синтаксис языка
Python - "родной" язык для машинного обучения и интеллектуального анализа данных.
https://stepik.org/course/58852/
https://stepik.org/course/67/
1.2) Основы объектно-ориентированного программирования (ООП)
Нужно, чтобы реализовывать собственные компоненты на основе существующих библиотек. Для этого нужны некоторые знания ООП, хотя и в меньшем объеме, чем для бэкенд-разработки.
https://stepik.org/course/100558/ - для C++, но хорошая теоретическая база по ООП и паттернам, можно взять выборочно
https://stepik.org/course/114354/ - для Python, но платный курс
https://stepik.org/course/94022/ - для Python и бесплатный, но незавершённый
Дополнительно: читайте открытый код на гитхабе. Отдавайте предпочтение репозиториям с большим количеством звёзд. Можно поизучать, как устроены известные библиотеки. Почти во всех применяется ООП.
1.3) Алгоритмы (не МЛ, а классические: сортировка, нахождение пути и т.д.)
В некоторых компаниях в качестве скрининга предлагают решить 1-2 задачи на алгоритмы. Знание алгоритмов нужно не только бэкенд-разработчикам. Оно помогает всем писать более качественный код.
https://stepik.org/course/217/
https://stepik.org/course/1547/
2) Математика: матанализ, теория вероятностей, статистика, линейная алгебра.
Нужно для более глубокого понимания того, как работают алгоритмы машинного обучения. Есть мнение, что математика в ML/DS нужна не всем и не всегда. Моё дело - предложить. :)
На начальном этапе я бы не отделял это от изучения машинного обучения (см. соответствующий раздел). Во многих учебниках и курсах по машинному обучению есть в начале разделы по математике - их объёма вполне достаточно на первых порах.
3) Анализ данных
Обучение модели обычно начинается с разведочного анализа данных. "Become one with your data" (c) A. Karpathy
3.1) Теория анализа данных
https://stepik.org/course/73952/ (тут есть и машинное обучение)
https://stepik.org/course/57623/ (тут больше на статистику упор)
3.2) NumPy и Pandas - базовые библиотеки для анализа данных
https://stepik.org/course/120014/ - платный курс
Но в сети также есть много бесплатных тьюториалов.
4) Машинное обучение
Нужно изучить не только алгоритмы машинного обучения, но и лучшие практики обучения моделей и внедрения их в реальные продукты.
https://stepik.org/course/4852/
https://stepik.org/course/8057/
Как обобщение всего пройденного с заходом на новый уровень - глубокое обучение - рекомендую школу глубокого обучения МФТИ:
https://stepik.org/course/135002/
Также мне очень нравится книга: Николенко, Кадурин, Архангельская "Глубокое обучение. Погружение в мир нейронных сетей". С нуля читать будет сложновато, а вот с некоторой базой - очень полезно.
5) Дальше нужно выбирать специализацию: структурированные данные, тексты, изображения или звук. Это особая история, выходящая за рамки базового учебного плана. Может быть, ещё поговорим об этом отдельно.
Включает области, которые нужно "прокачать", кратко - зачем это нужно, а также ссылки на ресурсы (старался подбирать бесплатные и русскоязычные).
1) Программирование на Питоне
1.1) Базовый синтаксис языка
Python - "родной" язык для машинного обучения и интеллектуального анализа данных.
https://stepik.org/course/58852/
https://stepik.org/course/67/
1.2) Основы объектно-ориентированного программирования (ООП)
Нужно, чтобы реализовывать собственные компоненты на основе существующих библиотек. Для этого нужны некоторые знания ООП, хотя и в меньшем объеме, чем для бэкенд-разработки.
https://stepik.org/course/100558/ - для C++, но хорошая теоретическая база по ООП и паттернам, можно взять выборочно
https://stepik.org/course/114354/ - для Python, но платный курс
https://stepik.org/course/94022/ - для Python и бесплатный, но незавершённый
Дополнительно: читайте открытый код на гитхабе. Отдавайте предпочтение репозиториям с большим количеством звёзд. Можно поизучать, как устроены известные библиотеки. Почти во всех применяется ООП.
1.3) Алгоритмы (не МЛ, а классические: сортировка, нахождение пути и т.д.)
В некоторых компаниях в качестве скрининга предлагают решить 1-2 задачи на алгоритмы. Знание алгоритмов нужно не только бэкенд-разработчикам. Оно помогает всем писать более качественный код.
https://stepik.org/course/217/
https://stepik.org/course/1547/
2) Математика: матанализ, теория вероятностей, статистика, линейная алгебра.
Нужно для более глубокого понимания того, как работают алгоритмы машинного обучения. Есть мнение, что математика в ML/DS нужна не всем и не всегда. Моё дело - предложить. :)
На начальном этапе я бы не отделял это от изучения машинного обучения (см. соответствующий раздел). Во многих учебниках и курсах по машинному обучению есть в начале разделы по математике - их объёма вполне достаточно на первых порах.
3) Анализ данных
Обучение модели обычно начинается с разведочного анализа данных. "Become one with your data" (c) A. Karpathy
3.1) Теория анализа данных
https://stepik.org/course/73952/ (тут есть и машинное обучение)
https://stepik.org/course/57623/ (тут больше на статистику упор)
3.2) NumPy и Pandas - базовые библиотеки для анализа данных
https://stepik.org/course/120014/ - платный курс
Но в сети также есть много бесплатных тьюториалов.
4) Машинное обучение
Нужно изучить не только алгоритмы машинного обучения, но и лучшие практики обучения моделей и внедрения их в реальные продукты.
https://stepik.org/course/4852/
https://stepik.org/course/8057/
Как обобщение всего пройденного с заходом на новый уровень - глубокое обучение - рекомендую школу глубокого обучения МФТИ:
https://stepik.org/course/135002/
Также мне очень нравится книга: Николенко, Кадурин, Архангельская "Глубокое обучение. Погружение в мир нейронных сетей". С нуля читать будет сложновато, а вот с некоторой базой - очень полезно.
5) Дальше нужно выбирать специализацию: структурированные данные, тексты, изображения или звук. Это особая история, выходящая за рамки базового учебного плана. Может быть, ещё поговорим об этом отдельно.
Stepik: online education
"Поколение Python": курс для начинающих
В курсе рассказывается об основных типах данных, конструкциях и принципах структурного программирования языка Python. Курс содержит теорию в формате текстовых конспектов и более 500 задач с автоматизированной проверкой. Этот курс является первой частью линейки…
Как многие знают, NLP сейчас в тренде – особенно всё, что касается больших языковых моделей (large language models или LLM). Крупные компании обучают свои аналоги ChatGPT, а небольшие стартапы строят свои продукты на основе АПИ от OpenAI. Сделал для вас небольшую подборку полезных бесплатных ресурсов, которые помогут относительно быстро “вкатиться” в LLM, особенно если у вас уже есть некоторый опыт в ML и NLP. Всё на английском.
1. LLM best practices от Weights&Biases
https://wandb.ai/site/llm-whitepaper
2. Patterns for Building LLM-based Systems & Products
https://eugeneyan.com/writing/llm-patterns/
3. OpenAI best practices
https://platform.openai.com/docs/guides/gpt-best-practices
4. DeepLearning.AI short courses
https://www.deeplearning.ai/short-courses/
Изучение этих ресурсов должно дать понимание, как и для чего применять LLM, когда имеет смысл обучать свою модель, а когда достаточно существующих, и т.д. Это поможет вам не только в профессиональном развитии и работе над своими проектами, но и для прохождения собеседований, ведь, как я уже сказал, LLM – это горячая тема.
Безусловно, LLM – не абсолютная панацея. Бывает так, что применять их к конкретному запросу от вашего заказчика – не самая лучшая идея. Но и в этом случае полезно ориентироваться в теме, чтобы аргументированно обосновать свой отказ от этой технологии.
1. LLM best practices от Weights&Biases
https://wandb.ai/site/llm-whitepaper
2. Patterns for Building LLM-based Systems & Products
https://eugeneyan.com/writing/llm-patterns/
3. OpenAI best practices
https://platform.openai.com/docs/guides/gpt-best-practices
4. DeepLearning.AI short courses
https://www.deeplearning.ai/short-courses/
Изучение этих ресурсов должно дать понимание, как и для чего применять LLM, когда имеет смысл обучать свою модель, а когда достаточно существующих, и т.д. Это поможет вам не только в профессиональном развитии и работе над своими проектами, но и для прохождения собеседований, ведь, как я уже сказал, LLM – это горячая тема.
Безусловно, LLM – не абсолютная панацея. Бывает так, что применять их к конкретному запросу от вашего заказчика – не самая лучшая идея. Но и в этом случае полезно ориентироваться в теме, чтобы аргументированно обосновать свой отказ от этой технологии.
Всем привет! У нас в компании (напомню, это Центр искусственного интеллекта МТС) есть пара интересных NLP-вакансий. Наши рекрутеры попросили порекомендовать кого-то из знакомых, потому что от меня уже было несколько удачных рекомендаций. 💼🙌 Кажется, эти вакансии пока не опубликованы у нас на сайте.
Здесь в канале есть NLP-шники с опытом, многих из вас я знаю лично. Нужен мидл и мидл+/сеньор. Если хотите узнать подробности и (при совпадении опыта и интересов) получить мою рекомендацию, пишите в личку, контакты в описании канала. 🤝
А вот, кстати, список тех вакансий, что опубликованы:
https://mts.ai/ru/career/
Там довольно разнообразно. 👀
Здесь в канале есть NLP-шники с опытом, многих из вас я знаю лично. Нужен мидл и мидл+/сеньор. Если хотите узнать подробности и (при совпадении опыта и интересов) получить мою рекомендацию, пишите в личку, контакты в описании канала. 🤝
А вот, кстати, список тех вакансий, что опубликованы:
https://mts.ai/ru/career/
Там довольно разнообразно. 👀
mts.ai
Карьера в компании MWS AI - Вакансии
Карьерные возможности в компании МВС АИ: мы создаем все условия для комфортной работы и развития.
Завтра (суббота 23 сентября 2023) в 18:00 Мск буду делать доклад для нижегородского ODS-сообщества. Если хотите послушать о новейших паттернах и лучших практиках применения и обучения больших языковых моделей (large language models, LLM), приходите!
https://us02web.zoom.us/j/86771868132
Кроме моего, там будет ещё один доклад: Александр Пономаренко, научный сотрудник лаборатории Латас НИУ ВШЭ, расскажет про метод NeuralODE.
https://us02web.zoom.us/j/86771868132
Кроме моего, там будет ещё один доклад: Александр Пономаренко, научный сотрудник лаборатории Латас НИУ ВШЭ, расскажет про метод NeuralODE.
Лучшие практики LLM 20230923.pdf
1.9 MB
Спасибо всем, кто приходил вчера послушать мой доклад!
Пока ждём видеозапись (обещают через пару недель выложить на YouTube), предлагаю посмотреть мои слайды. Там много нейроартов)
Пока ждём видеозапись (обещают через пару недель выложить на YouTube), предлагаю посмотреть мои слайды. Там много нейроартов)