Вячеслав Ефимов о хакатонах по ИИ, дорожных картах в области науки о данных и о том, как ИИ существенно изменил повседневную работу инженеров машинного обучения
Делиться
В серии «Автор в центре внимания» редакторы TDS беседуют с участниками нашего сообщества о своём карьерном пути в области науки о данных и искусственного интеллекта, о своих работах и источниках вдохновения. Сегодня мы рады поделиться нашей беседой с Вячеславом Ефимовым.
Вячеслав — старший инженер машинного обучения, специализирующийся на обработке естественного языка и компьютерном зрении. Одно из его увлечений — создание образовательного контента: Вячеслав опубликовал более 60 статей на сайте Towards Data Science, объясняя сложные концепции простым языком и предоставляя подробные визуализации.
Вы написали много статей для начинающих и пояснительных статей по TDS. Повлияло ли обучение основам на ваш подход к проектированию и отладке реальных систем на работе?
Я замечаю взаимосвязь: чем больше я чему-то обучаю, тем лучше это понимаю. В реальной жизни, когда я пишу новую статью, я стараюсь углубиться в мелкие детали, сохраняя при этом простоту объяснения для читателей. Такое акцентирование информации помогает мне лучше понимать работу алгоритмов.
В этом смысле, всякий раз, когда я сталкиваюсь с ошибкой в одном из алгоритмов, используемых на работе, о котором я ранее написал статью, у меня больше шансов быстро найти решение самостоятельно. С другой стороны, когда я пишу статью на незнакомую тему и самостоятельно её изучаю, это повышает мою уверенность в применении этого алгоритма на работе, поскольку я уже знаю область его применения, преимущества, недостатки, а также конкретные детали или ограничения.
Таким образом, я могу предлагать оригинальные решения, которые не очевидны для других, и обосновывать свой выбор перед другими членами команды, руководителями и заинтересованными сторонами. Эти знания очень ценны для меня.
С таким количеством новых моделей, появляющихся каждый день, легко запутаться. Как вы решаете, что стоит «глубокого погружения», а что нужно просто «уловить суть»? Изменилась ли ваша стратегия управления всем этим в последнее время?
Сегодня у нас действительно изобилие моделей и инструментов, которые появляются каждый день. Легко растеряться, когда не знаешь, что делать дальше.
В условиях ограниченного времени я обычно углубляюсь в темы, которые могут быть применимы в работе или моих личных проектах. Это придаёт мне больше уверенности при презентации или объяснении своих результатов.
Компании обычно стремятся достичь рабочих результатов как можно скорее. Это также одна из причин, по которой в своих статьях я уделяю больше внимания теоретическим концепциям, поскольку на работе у меня нет времени на углубленное изучение теории.
Таким образом, я эффективно сочетаю практический опыт работы и теоретические знания в своём блоге. Оба эти компонента важны для опытных специалистов по анализу данных.
Вы участвовали в хакатонах по искусственному интеллекту. Чему вы научились, работая в условиях таких жёстких сроков? Помогло ли это вам лучше оценивать проекты или выбирать модель? И используете ли вы какие-либо из этих «уроков хакатонов», когда разрабатываете новую идею с нуля?
Хакатоны обычно длятся от нескольких часов до двух дней. Этого времени очень мало для разработки полностью функционального продукта. Однако в прошлом это сильно подталкивало меня к более чёткому расставлению приоритетов в функциях, на которых следует сосредоточиться. В целом, умение управлять временем — ценный навык. Когда у вас есть несколько возможных решений проблемы, необходимо выбрать то, которое наилучшим образом соответствует потребностям бизнеса и при этом учитывает временные ограничения.
Ещё одним преимуществом является то, что после каждого хакатона вы можете оценить себя с точки зрения времени, затраченного на реализацию определённых функций. Например, предположим, что это был первый опыт разработки конвейера RAG, на реализацию которого у вас ушло около 4 часов. В следующий раз, когда вы столкнётесь с аналогичной проблемой на работе или на хакатоне, вы будете лучше заранее оценивать, сколько времени займёт решение, если решите использовать тот же метод. В этом смысле опыт хакатона позволяет вам точнее определить временные рамки для методов, которые вы хотите внедрить в проекты.
Для меня самым важным уроком хакатона стало то, что при создании MVP не нужно стремиться к совершенству. Хотя MVP важен, необходимо также привлекательно представить свой продукт клиентам или инвесторам, объяснить его бизнес-ценность, решаемую им проблему и почему он лучше существующих на рынке решений. В этом смысле хакатоны учат придумывать лучшие идеи, которые решают реальные проблемы, и при этом быстро выпускать MVP, содержащий самые необходимые функции.
Для читателей, размышляющих о своей карьере: ваша серия статей « Путь к становлению специалиста по данным » охватывает как фундаментальные основы, так и продвинутый уровень машинного обучения. Если бы вы переписывали её сегодня, какие темы были бы выделены, какие — понижены или вовсе вырезаны, и почему?
Я написал эту серию статей год назад. На мой взгляд, все перечисленные мной концепции и темы актуальны для начинающих специалистов по данным. Все представленные там темы по математике, информатике и машинному обучению являются основополагающим фундаментом для любого инженера машинного обучения.
Поскольку сейчас конец 2025 года, я бы также добавил требование иметь хотя бы минимальный опыт оперативной разработки и быть знакомым с некоторыми инструментами создания искусственного интеллекта, такими как GitHub Copilot, Gemini CLI и Cursor, что позволило бы повысить эффективность работы.
Стоит отметить, что по сравнению с предыдущими годами ИТ-компании предъявляют более высокие требования и ожидания к младшим инженерам, начинающим работать в сфере науки о данных. Это логично, поскольку современные инструменты искусственного интеллекта способны эффективно решать задачи младшего уровня, и многие компании предпочитают полагаться на них, а не на инженеров начального уровня, поскольку им не нужно платить зарплату, при этом в обоих случаях они получают одинаковый результат.
Вот почему, если инженер машинного обучения обладает прочными фундаментальными навыками, которые я описал в той серии статей, ему будет гораздо легче самостоятельно погружаться в более сложные темы.
Ваш опыт сочетает в себе инженерию программного обеспечения и машинное обучение. Как это влияет на ваш стиль письма?
Наличие сильных навыков в области разработки программного обеспечения — одно из лучших преимуществ, которые вы можете получить как специалист по анализу данных:
- Это поможет вам осознать важность хорошо структурированной документации программного обеспечения и создания воспроизводимых конвейеров машинного обучения.
- Вы лучше понимаете, как сделать свой код чистым и читаемым для других.
- Вы понимаете алгоритмические ограничения и знаете, какую структуру данных выбрать для конкретной задачи, исходя из потребностей системы.
- Вы сможете с большей легкостью сотрудничать с инженерами бэкэнда и DevOps по вопросам интеграции модулей вашего кода.
- Вам не придется полагаться на других при выполнении SQL-запросов для извлечения необходимых данных из базы данных.
Этот список можно продолжать и продолжать…
Говоря о моих статьях, я нечасто пишу статьи, содержащие много кода. Однако, когда я это делаю, я стараюсь сделать их читабельными и понятными. Я всегда ставлю себя на место других и задаюсь вопросом, насколько легко было бы воспринять или воспроизвести текст моей статьи или примеры кода, если бы я был на их месте. Именно здесь опыт в области разработки программного обеспечения делает это понимание особенно важным для меня, и я следую лучшим общепринятым практикам для создания конечного продукта.
Судя по вашему портфолио и GitHub , вы с самого начала сочетали основы разработки ПО с машинным обучением. Какую инженерную привычку вы бы хотели, чтобы начинающие специалисты по данным переняли как можно раньше?
Многие инженеры, особенно младшие, склонны недооценивать важность создания качественной документации и воспроизводимых процессов. Со мной это тоже случалось в прошлом, когда я был больше сосредоточен на разработке надёжных моделей или проведении исследований.
Как оказалось, когда мне приходилось менять контекст, а затем несколько недель спустя возвращаться к работе над предыдущим проектом, я тратил уйму времени на то, чтобы выяснить, как запустить мой старый код в захламленном Jupyter Notebook или заново установить необходимые библиотеки, тогда как раньше я мог бы потратить немного больше времени на разработку хорошо документированного README.md, описывающего все необходимые шаги для выполнения конвейеров с нуля.
Поскольку было практически невозможно перезапустить мои конвейеры с нуля, я также не мог проводить эксперименты с использованием других входных параметров, что делало ситуацию еще более удручающей.
Для меня это был болезненный опыт, но один из самых ценных уроков, которые я усвоил. Поэтому, если бы мне пришлось дать совет начинающему специалисту по анализу данных по поводу одной конкретной привычки, я бы сказал следующее:
«Всегда делайте свои конвейеры машинного обучения пригодными для повторного использования и хорошо документированными».
Изменил ли искусственный интеллект (ИИ) вашу повседневную работу инженера машинного обучения за последний год? Что стало проще, что сложнее, а что осталось прежним?
В последние годы мы наблюдаем значительный рост мощных инструментов разработки ИИ:
- LLM, которые могут ответить практически на любой вопрос, дать совет или найти ошибки в программном обеспечении
- Cursor, Lovable и Bolt выступают в качестве IDE на базе искусственного интеллекта для разработчиков
- Агенты ИИ могут выполнять многоэтапные задачи
Как инженеру машинного обучения, мне важно регулярно осваивать эти инструменты, чтобы использовать их эффективно.
Что стало проще
Начиная с 2025 года я могу наблюдать следующее положительное влияние на мою работу:
- Мне стало проще быстро тестировать идеи и прототипы. Например, на работе бывали случаи, когда мне приходилось сталкиваться с проблемами компьютерного зрения, выходящими за рамки моих знаний. Таким образом, я мог попросить ChatGPT предложить несколько идей для их решения. Бывали даже случаи, когда ChatGPT генерировал для меня код, и я пытался его выполнить, не понимая, как он работает изнутри.
Тогда у меня было два возможных случая:- Если код работал успешно и решал первоначальную проблему, то я пытался глубже изучить документацию OpenCV, чтобы понять, как он в конечном итоге работает.
- Если бы код не решил мою проблему, я бы либо проигнорировал его, либо сообщил об ошибке в ChatGPT, либо попытался бы найти решение самостоятельно.
Как видите, мне удалось быстро протестировать решение, которое оказалось работоспособным и сэкономило мне часы исследований без какого-либо риска.
- Ещё одним отличным вариантом использования для меня стала вставка сообщений об ошибках непосредственно в ChatGPT вместо поиска решения в интернете. В большинстве случаев всё работало хорошо, но иногда возникали ошибки, связанные с установкой библиотек, системными ошибками и развёртыванием конвейеров в облаке, а также другие проблемы.
- И наконец, я большой поклонник хакатонов, посвящённых искусственному интеллекту! Наличие инструментов, способных генерировать как фронтенд, так и бэкенд вашей системы, имеет для меня огромное значение, поскольку теперь я могу быстро создавать прототипы и тестировать свой MVP всего за несколько часов. То, что я сейчас разрабатываю на однодневных хакатонах, может потребовать целой недели работы.
Что стало сложнее/рискованнее
- При написании кода с использованием ИИ повышается вероятность утечки конфиденциальных данных. Представьте, что у вас есть файл или фрагмент кода, содержащий важные учётные данные, которые вы случайно передали в модель ИИ. Тогда сторонний инструмент узнает ваши конфиденциальные учётные данные. Это может произойти, особенно если вы используете инструмент вроде Cursor и храните учётные данные в другом файле, а не в формате .env. Поэтому всегда необходимо соблюдать крайнюю осторожность.
- Другой риск — это отсутствие надлежащего тестирования кода, сгенерированного ИИ, и незнание того, как выполнить откат. Инструмент ИИ может внести в код невидимые ошибки, особенно при использовании для модификации или рефакторинга существующего кода. Чтобы гарантировать отсутствие деградации кода, сгенерированного ИИ, необходимо тщательно проверять сгенерированные фрагменты кода, тестировать их и сохранять изменения таким образом, чтобы при необходимости можно было всегда вернуться к предыдущей корректной версии.
- При чрезмерном использовании инструментов генеративного ИИ существует риск того, что код станет нечитаемым, будет содержать слишком длинные функции, будет повторяться или перестанет функционировать корректно. Поэтому важно понимать, что инструменты ИИ эффективнее работают при создании прототипов, чем при поддержании высокого качества готового кода.
Что осталось прежним
Для меня неизменной остаётся важность понимания внутреннего механизма работы используемых мной алгоритмов, поддержания прочных основ компьютерных наук и написания качественного кода, а также других ключевых навыков. Другими словами, базовые принципы разработки программного обеспечения всегда будут необходимы для эффективного использования инструментов ИИ.
В этом смысле мне нравится сравнивать набор доступных инструментов ИИ с заменой младшего разработчика в моей команде, которому я могу делегировать менее важные задачи. Я могу просить его о чём угодно, но не могу быть на 100% уверен, что он выполнит мои задачи правильно, и именно здесь вступает в игру важность наличия прочных фундаментальных знаний.
Источник: towardsdatascience.com
