Привет, друзья! Решил завести свой блог про Питон, ИИ, карьеру в IT и всё, что с этим связано. Надеюсь, здесь будет дружелюбная атмосфера и каждый интересующийся сможет найти для себя что-то полезное.

Обо мне: программирую на Питоне примерно с 2012 года, с 2014 стал заниматься такой областью искусственного интеллекта как автоматическая обработка текстов. Сейчас я NLP-техлид в одной российской IT-компании. Наша команда применяет современные технологии глубокого обучения для обработки текстов на разных языках. До этого я успел поработать в нескольких зарубежных компаниях в бэкенд-разработке, анализе данных и машинном обучении. До перехода в IT долго работал преподавателем в вузе. Изначально моё образование гуманитарное, педагогическое; как ни странно, оно порой здорово помогает в моей IT-карьере.

В этом блоге я буду делиться знаниями и личным опытом в тех областях, где что-то понимаю. Для меня важно помогать людям, как и мне когда-то помогали мои учителя и более опытные коллеги.

Навигация

Хэштеги внутри блога, по которым можно найти посты на интересующие вас темы:

#py_basic - инсайты и лайфхаки для начинающих в Питоне, а также разборы несложных задач. Основано на большом опыте преподавания Питона с нуля.

#py_advanced - более продвинутые и специфические трюки и инструменты, разборы сложных задач.

#ml - про машинное обучение, интеллектуальный анализ данных, особенно в сфере обработки текстов. Истории из опыта (правда, не обо всём можно рассказывать из-за NDA).

#career - советы по продвижению карьеры в IT, прохождение собеседований, как найти первую работу и т.д.

#soft_skills - как эффективно общаться с коллегами, управлять временем, эмоциями, своим развитием.

Голосование:
https://news.1rj.ru/str/plush_python/5

Об авторе:
https://news.1rj.ru/str/plush_python/4

4 ключевые идеи программирования
#py_basic

Мой путь к написанию кода за деньги, а не просто как хобби, был долог и тернист. К настоящему моменту я пробовал программировать на 10 разных языках, включая Python, Java, C++. Когда я (несколько лет) преподавал Питон с нуля, я обычно начинал с того, что знакомил студентов с четырьмя "ключевыми идеями программирования". Если хорошо усвоить эти идеи, то можно научиться писать код любой сложности, так как всё остальное, что есть в программировании, - лишь надстройка над этими четырьмя идеями.

1. Функции - это действия, которые умеет выполнять ваша программа. Программу можно представить в виде робота, который умеет, например, танцевать, делать уборку, ходить в магазин за хлебом и т.д. Все эти "умения" робота - это функции. Отдельно взятая сложная функция может состоять из более простых функций (действий). Например, функция "сходить за хлебом" может состоять из действий: "взять деньги", "построить маршрут до магазина", "дойти до магазина", "найти в магазине хлеб" и так далее.

2. Переменные - это то, как программа хранит знания о мире. Говоря образно, это такие коробочки с этикетками, на каждой из которых написано название. То, что написано на коробке, - это название переменной, а то, что внутри коробки, - это содержимое, которое переменная хранит (числа, текст, или более сложные объекты). В почти любой программе есть свой "склад коробок" - это все переменные, в которых хранятся знания о мире, заложенные в программе. Следуя нашему примеру про поход за хлебом, можно представить себе переменную-коробку с этикеткой money. Тогда внутри этой коробки должно лежать число, которое обозначает, сколько у нас есть денег.

3. Ветвления - это логика принятия решений внутри нашей программы. Её можно представить в виде простых правил, на которые наша программа-"робот" ориентируется при совершении действий. Например, наш робот решает, покупать ему французский багет или нет. Он может сравнить стоимость багета (которая, допустим, "лежит" в коробке-переменной baguette_price) с количеством денег, которое у него осталось (переменная money). Если стоимость хлеба ниже, чем количество оставшихся денег, то нужно покупать. Конечно, логика робота может быть сколь угодно более сложной. :)

4. Циклы - это просто многократное повторение одних и тех же действий. Например, пока робот не нашёл подходящее хлебо-булочное изделие, он должен идти вдоль витрины и оценивать каждый товар в ассортименте. Когда хлеб найден, нужно прервать цикл (ведь дальше искать нет смысла) и идти к кассе оплачивать товар. Ещё может быть "маленький" цикл (оценить сегодняшний ассортимент в магазине) внутри "большого" цикла (каждый день ходить в магазин). В заключение можно вспомнить фильм "День сурка", где герой, по сути, застрял в бесконечном цикле, но в результате выполнения определённых действий ему всё-таки удаётся "вырваться".

Как найти первую работу программистом
#career

Несмотря на большую нехватку разработчиков / специалистов по машинному обучению на рынке труда, найти первую работу даже с хорошими знаниями и навыками, но без опыта, бывает очень сложно. Зато с опытом - почти без проблем. Поэтому найти свою самую первую работу программистом - это как будто бы самый сложный квест в этой игре, после которого всё становится гораздо легче. Как же преодолеть этот порог? На мой взгляд, есть четыре основные "точки входа" в профессию, связанную с написанием кода (то есть это не абстрактное "войти в IT", я не говорю про HR-специалистов, менеджеров по управлению проектами, дизайнеров и так далее).

1. Стажировки в крупных компаниях. Здесь обычно бывает жёсткий отбор, плюс на рынке не так уж много компаний, готовых растить стажёров. Однако на мой взгляд, это самая классная и престижная точка входа. Даже если стажировка неоплачиваемая, но компания хорошая, а у вас нет опыта работы по специальности, - стоит попробовать.

2. Работа в стартапах. Вы удивитесь, насколько ниже порог входа в стартапах и маленьких компаниях, чем в больших корпорациях (даже на позицию стажёра). Дело в том, что у молодых стартапов зачастую нет возможности платить адекватную рынку зарплату, и тогда они готовы нанимать и без опыта (но знания и навыки, конечно же, всё равно нужны).

3. Опен-сорс. Многие проекты с открытым исходным кодом страдают от нехватки людей, готовых бесплатно их улучшать и исправлять баги. Если вы станете контрибьютером в таком проекте (а там не обязательно очень сложные задачи, бывают и относительно простые), то вам точно будет о чём рассказать на собеседовании. Также это может быть довольно престижно, если проект/библиотека/фреймворк пользуется известностью.

4. Собственные проекты. Если вы никогда не писали код за деньги, это вовсе не значит, что у вас не должно быть классных пет-проектов. Нужно постепенно накапливать сильное портфолио, при этом важно уметь интересно рассказать о том, какие возникали сложности и что в итоге получилось круто. Знаю студентов, которые на собеседованиях так здорово рассказывали о своих курсовых работах, что их нанимали даже без опыта.

Зачем учиться решать алгоритмические задачки?
#career

Ответ на этот вопрос, наверное, очевиден: чтобы прокачать своё алгоритмическое мышление и (как побочный эффект) легче устраиваться на работу.

История из жизни. Я работаю в своей уже четвёртой по счёту IT-компании. В двух из них при прохождении отбора мне приходилось решать алгоритмические задачи. Часто задачи используют как скрининг, особенно (в моём опыте) в зарубежных компаниях. То есть сначала решаешь за ограниченное время пару задач на специальной платформе, а потом, после проверки решений, тебя приглашают на технические собеседования. (Кстати, в одной компании у меня собеседований было целых шесть, но вообще-то такое бывает редко. Во многих компаниях делают оффер после 1-2 собеседований.)

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

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

Давайте в следующий раз попробуем решить какую-нибудь не самую простую задачу и вместе разобрать решение!

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

Задача от Google про разложение на полные квадраты
#py_basic

У этой задачи есть история. Моя знакомая (она NLP / бэкенд-разработчик) много гуглила по работе, и поисковик однажды предложил ей решить несколько задач на программирование. Оказывается, Google следит за вашими поисковыми запросами не только для того, чтобы показывать вам более релевантную контекстную рекламу. Если вы много гуглите про бэкенд-разработку, то Google может предложить вам такой челлендж. Если его успешно пройти, то дальше зовут на собеседование. Там было несколько задач, я покажу вам самую первую из них. Она не сложная, но сможете ли вы решить её эффективно?

На входе положительное целое число, нужно разложить его на сумму квадратных чисел так, чтобы слагаемых было наименьшее количество. Слагаемые-точные квадраты нужно расположить в списке в порядке убывания. Например, если нам пришло число 7, то нужно разложить его на [4, 1, 1, 1], но не на [1, 1, 1, 1, 1, 1, 1] (не наименьшее количество слагаемых), не на [5, 1, 1] (первое число не является квадратом целого числа), не на [1, 4, 1, 1] (неправильный порядок) и так далее. Ещё несколько примеров:

12 -> [9, 1, 1, 1]
16 -> [16]
1 -> [1]

Завтра покажу решение и сделаю разбор.

Задача на разбивку слитной строки на слова
#py_advanced

Специально для тех, кому предыдущая задача показалась простой, взял более хитрую с LeetCode: https://leetcode.com/problems/word-break/
Она отмечена как задача средней сложности. Такую вполне реально получить на собеседовании на джуновскую или даже мидл-позицию (как скрининг).

На входе слитная строка наподобие "мамамылараму" и список слов, например, ["раму", "мама", "мыла"]. Нужно вернуть True, если строку можно разделить на заданные слова так, чтобы не было пересечений и не оставалось неиспользованных символов. Слова можно использовать сколько угодно раз. В противном случае нужно вернуть False. Примеры:

"мамамылараму", ["раму", "мама", "мыла"] -> True
"мамамылараму", ["раму", "мама", "мыла", "дома"] -> True
"мамамылараму", ["мама", "мыла", "дома"] -> False
"мамамылараму", ["лараму", "мама", "мыла"] -> False
"мамамылараму", ["раму", "мама", "мыл"] -> False
"мамамамамама", ["ма", "му"] -> True

Решение и разбор - завтра.

Dive into Deep Learning
#ml

И напоследок на сегодня хочу поделиться, недавно наткнулся на полезнейшую книжку по машинному / глубокому обучению:
https://d2l.ai/

Почему рекомендую:
* Написал крутой коллектив учёных из Amazon
* Книга бесплатная (но на английском)
* Отлично подходит для начинающих, будет интересна и продвинутым
* Актуальные примеры кода на современных фреймворках
* Книгу постоянно обновляют, она не должна быстро устареть
* Пишут, что её уже используют в 400 университетах в 60 странах мира

Прочитал несколько глав для ознакомления, мне понравилось.

Я выложил решения и разборы двух вчерашних задач, ищите их в комментариях к соответствующим постам.
Лучше, конечно, сначала попробовать решить одну или обе задачи самостоятельно, а потом сравнить с моими решениями.
Буду рад, если поделитесь впечатлениями от задач или прокомментируете мои разборы)
Завтра выложу полезные советы из своего опыта о том, как решать задачи.

Как научиться хорошо решать алгоритмические задачи?
#py_basic #py_advanced

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

1. Когда начинаете решать новую задачу, рекомендую сначала разобрать её на бумаге, нарисовать схему, диаграмму, таблицу и т.п. Я считаю, что это самый важный шаг (и навык) - так обычно получаются более эффективные решения, чем если сразу садиться писать код.
2. При этом часто помогает вопрос: "а как человек (а не компьютер) решал бы эту задачу?" Вручную пошагово разобрать несколько примеров ввода, от простых до более сложных.
3. Если за 10-15 минут не появилось идей (иногда полезно и дольше поломать голову для тренировки), нужно сесть за код и попробовать запрограммировать хотя бы неполное решение, начав с простых случаев. Обычно в процессе этого приходят новые идеи.
4. Если на одних примерах ваше решение работает, а на других нет, это уже большой прогресс. Дальше нужно просто разобрать сложные случаи и понять, как их включить в ваше решение, сделав его более общим.
5. Если задача "не поддалась" за час-два и вы устали, лучше сделать перерыв и отдохнуть. Мозг так устроен, что он не может очень долго напряжённо работать над одной сложной задачей. Возможно, задача пока что вам не подходит и нужно какое-то время порешать более простые задачи, либо вы её всё-таки решите за несколько дней в "фоновом" режиме. И то, и другое - хорошо.
6. Не нужно ругать себя, если не получилось решить, потому что это нормальный процесс саморазвития. Помните, что мозг лучше всего учится на неудачах. Настоящая цель - не решить задачу, а повысить свои навыки.
7. Рекомендуют подбирать себе задачи таким образом, чтобы было где-то 15% неудач. Это оптимальный уровень сложности, когда из, скажем, 20 задач вы можете решить 17, а остальные не можете. Если процент успеха выше, значит, вы недостаточно себя нагружаете и ваш прогресс идёт медленнее, чем мог бы. Если же процент успеха ниже, значит, вы выбираете слишком сложные задачи, а это опасно для вашей мотивации и самооценки.

Ну и достаточно пока о задачах) В ближайших постах поговорим на другие темы.

Что нужно показать на собеседовании по машинному обучению?
#ml #career

Из опыта прохождения и проведения многочисленных собеседований в сфере ML могу сказать, что чаще всего интервьюеры хотят видеть в вас следующее:

• Чёткое понимание того, как происходит машинное обучение - градиентный спуск, типичные постановки задач в ML, функции потерь, недообучение / переобучение (bias / variance), валидация моделей, правильная методология проведения экспериментов.
• Опыт или хотя бы теоретическое знание методов решения различных проблем с данными: шум, выбросы, несбалансированность, низкая репрезентативность, повторы, слишком мало данных, слишком много данных и т.д.
• Знание и опыт применения основных современных и классических моделей в вашей области, будь то обработка структурированных данных или же естественного языка, изображений, звука.
• Не всегда, но довольно часто желателен опыт создания микросервисов, оптимизации моделей, мониторинга ML-приложений в продакшне.

Всё это, конечно, желательно демонстрировать на конкретных примерах из своей предыдущей работы / личных проектов. Так вы лучше продемонстрируете уверенное владение "матчастью". Не "проблема X решается методами Y1 и Y2", а "когда в таком-то проекте наша команда столкнулась с проблемой X, мы сначала применили метод Y1, но он оказался неэффективен по такой-то причине, поэтому мы перешли на метод Y2, и это привело вот к таким результатам". Так можно раскрыть больше деталей. Детали - ваши друзья, они не только свидетельствуют о вашем реальном опыте решения сложных проблем, но и делают ваш рассказ более живым и запоминающимся в глазах интервьюера. А это важно, потому что нас с вами (пока что) оценивают на собеседованиях живые люди, а не беспристрастные машины)

Пока остановлюсь на этом. Тема технических собеседований очень объёмная, буду постепенно раскрывать её в следующих постах.

Что важнее, модель или данные?
#ml

Как известно, суть машинного обучения в том, что мы не сами программируем логику принятия решений, а показываем машине довольно большое количество примеров, на которых она должна научиться решать ту или иную задачу. Многие инженеры по машинному обучению, с которыми я работал, считали, что главное в достижении хороших результатов - это применять самые свежие алгоритмы и трюки из научных статей. Другими словами, добиваться прироста качества за счёт изменений (часто - усложнений) в ML-модели. "Давайте возьмём нейросеть побольше!" Но нередко случается так, что недели и месяцы уходят на реализацию новых моделей и эксперименты с ними, при этом качество выполнения задачи не повышается или повышается несущественно - на 0.1-0.2%. Небольшой выигрыш в качестве может стоить значительных вычислительных ресурсов, что может быть неприемлемо в продакшне.

В последние годы набирает популярность другой подход, фокусирующийся на данных, а не на модели. По-английски его называют "data-centric machine learning". В нём задачу ставим чуть иначе: что, если наша модель уже достаточно хороша и мы просто должны показать ей более правильные и качественные примеры, чтобы она лучше научилась решать задачу?

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

1. Анализ ошибок нашей модели. Валидационные примеры, которые не удаётся правильно классифицировать, часто могут выявить систематические проблемы обучения, сказать о том, чего не хватает в обучающих данных. Нам это помогло понять, какого рода тексты обычно относятся моделью к неверным классам, что между ними общего.
2. Построение матрицы ошибок (confusion matrix). Это ответило на вопрос, какие классы наиболее часто путает модель. По результатам мы добавили в обучающий датасет примеры, лучше разводящие между собой именно эти классы.
3. Сравнение качества модели с тем, насколько хорошо человек справляется с такой же задачей. Дали экспертам примеры из валидационного сета для ручной разметки, увидели, что люди тоже допускают немало ошибок и путают некоторые классы. Это помогло снизить нереалистичные ожидания от модели, а также пересмотреть принятую систему классов.
4. Очистка датасета от "плохих" примеров. Эксперты просмотрели датасет на предмет того, какие примеры (с человеческой точки зрения) слишком неоднозначны. С другой стороны, применили и автоматические методики поиска неадекватных примеров, основанные на методе ближайших соседей (сейчас я бы применил ещё и метод TracIn от Google).

Всё это в совокупности помогло значительно повысить точность классификации - с 0.47 до 0.85 - и практически "вернуло жизнь" проекту. Временные затраты были относительно невелики, к тому же значительная часть работ выполнялась экспертами-лингвистами, что позволило высвободить ценное время ML-инженеров.

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