В этой статье я делюсь опытом менторства проекта на Yandex Camp по машинному обучению — рассказываю о том, что получилось, что нет, и какие выводы сделал. Надеюсь, эти наблюдения помогут будущим менторам и организаторам кемпов улучшить рабочий процесс, а также всем, кому интересно управление проектами.

Прежде всего хочу поблагодарить сотрудников НГУ и Яндекс за организацию. Встретился с крутыми мотивированными ребятами — мне сначала показалось, что они выполнят весь проект за день. Но опыт показал, что у многих команд были проблемы в самоорганизации командной работы и технической подготовке к работе. Обычно научные исследования, подобные проектам с кемпа, длятся месяцами — поэтому задержка на один день не является проблемой, но не здесь.

Уточнение: статья посвящена не самому проекту (по нему возможно будет отдельная статья), а процессу работы над проектом.

Роли в проекте

Четких инструкций от Яндекса по границам зоны ответственности ментора не было, поэтому изначально я подготовил такой текст для команды:

«Яндекс кемп предполагает самоорганизацию команды, то есть участники команды сами распределяют между собой роли. Задачи тоже можно ставить самим. Роль ментора в основном в том, чтобы обсуждать с ним планы и результаты, спрашивать что‑то.»

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

Какие выводы я сделал

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

Эффективность организации работы

(Очень важное уточнение: ребята 100% хорошо поработали и сделали полезные вещи. Я лишь фокусируюсь на том, что можно было бы еще сильнее улучшить, так как являюсь идеалистом.)

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

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

Это не вина ни участников команд, ни ментора. Ментор не успевает внимательно следить за тем, что делает каждый из 10 человек. Попытки делегировать эту задачу капитанам тоже не работают. Несмотря на просьбы следить за командой, капитаны в основном заняты своей работой (которую делали вполне хорошо), а не менеджментом чужой работы, возможно стесняются руководить, да и может не быть еще соответствующих навыков. Хотя я могу ошибаться и возможно капитаны прикладывали усилия для координации работы команды, но все же процесс выполнения проекта шел не по плану.

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

Какие выводы я сделал

В команде из 10 человек веселее, но все же если распределять по 5 человек на ментора, то ментор сможет более активно помогать каждому. Роль ментора стоит пересмотреть — полезно, если он возьмет на себя роль тимлида, который помогает, проводит код‑ревью и иногда пишет связующий код между компонентами, которые реализовали участники, или критичный код в задачах по типу «бутылочное горлышко», где работу нельзя распараллелить на всех, пока не готова одна задача‑пререквизит. То есть ментор должен быть полноценным участником проекта, а не наблюдателем, это важно. Думаю, что в этом случае скорость получения результата будет в разы выше, волнение в команде меньше, и будет намного больше возможностей поделиться опытом.

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

Постоянно вспоминаю эту картину (Zdzisław Beksiński)

Если для деления по 5 человек на ментора не наберется нужное количество менторов, то можно разбить 2 недели на 3 блока: 1) вводные лекции, 2) лекции + работа первых групп, 3) лекции + работа вторых групп. Семинары, которые были на первой неделе, лучше занять не написанием бэкпропа с нуля, а отработкой навыков работы с python библиотеками, которого, по отзывам самих участников команд, некоторым не хватало.

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

Как улучшить командную работу в ML

За последние годы мой опыт свидетельствует в пользу следующего:

В любой команде очень важно распространение информации. Участники должны не бояться своевременно задавать вопросы, вовремя сообщать о готовности кодовых компонентов, а в научном споре каждый аргумент должен быть подробно отвечен и не проинорирован. Наверное, это звучит банально, но на практике чаще всего оказывается не так.
В экспериментах по ML важна архитектура кода, связующего все компоненты (например, фреймворка для экспериментов). Она должна быть модульной и расширяемой, чтобы новые функции можно быть внедрять без рефакторинга, иначе это будет не итеративная разработка, а переписывание кода каждый раз заново. В Python полезна типизация (например, режим strict в Pyright): она сильно улучшает понятность кода и помогает отлавливать баги.
В научной работе важно ускорения цикла обратной связи от экспериментов. Часто есть несколько гипотез, и сначала мы были больше уверены в первой, но новые данные или аргументы склонили в пользу второй. В этом случае нет ничего плохого в том, чтобы менять план на ходу. Ведь «передумать» от слова «думать» — если не думать, тогда и план меняться не будет. Если вы связаны внешними обязательствами, такими как ТЗ на ресерч от заказчика, то изменение плана более рискованно. В этом случае чем лучше понимание проблемы, тем выше шанс, что риск оправдается.

Деление на подкоманды

Каждая команда из 10 человек по задумке делилась по 2 подкоманды. Инструкций от Яндекса не было: должны ли они конкурировать, выполняя одну и ту же задачу или дополнять друг друга. Если дополнять, то почему нельзя разделиться как удобнее уже в ходе работы? Для меня это было непонятно. Мы организовались как одна команда, то есть деление осталось чисто на бумаге, что и хорошо.

Написание проекта через LLM

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

Техническое оснащение

Лектор из Яндекс Облака сообщил нам, что для проектов не дадут VM и нужно пользоваться Яндекс‑датасферой с Jupyterlab. Это в итоге оказалось не так — VM выдавали, но некоторым приходилось ждать до суток поднятия квоты на GPU.

Вряд ли кто‑то на практике работает на юпитер‑серверах, если умеет пользоваться IDE, ведь IDE дает больше возможностей: навигация, рефакторинг, проверка типов и т д. Это никак не связано с форматом файла: и в JupyterLab и в IDE можно редактировать как.ipynb, так и.py файлы. Изучать IDE и Linux — необходимый навык для студентов, поэтому совет использовать JupyterLab считаю вредным.

Какие выводы я сделал

На будущих кемпах было бы полезно давать всем участникам проектов и менторам гайд по настройке окружения: как создавать VM, добавлять пользователей, настраивать доступ с сервера до Github, заходить туда по SSH ключу через VS Code, устанавливать python‑среду, устанавливать переменные среды, чтобы каждая команда не разбиралась с этим самостоятельно, и проделывать это в самом начале. Иначе во время работы над проектом, где каждый день на счету, сложности с окружением сильно отвлекают от задач.

Из собственных ошибок

Подключил медленный HDD на сервер, пришлось заменять на SSD.
Загрузочный SSD взял малого объема 100 гб, он быстро забился HF-кэшами, потому что не у всех они были прокинуты на дополнительный диск, и это мешало команде работать.
Забыл выключать GPU на ночь, грант закончился, докидывал свои деньги на счет.

Критерии успеха проекта

Задачи формулировались как научные, но проблема в амбициозности заявленных тем. Многие темы заявлены так, что в случае успеха стали бы научным прорывом, причем при отсутствии на кемпе кросс-рецензирования. Поэтому:

Оцените вероятность успеха.
Оцените вероятность заявления об успехе.

Афтепати. "Метрики выросли" - шутка одного из участников команды

Никак не хочу обесценить чью-то работу, но получить реальный полезный результат в науке сложно. По многим областям в ML есть статьи, где доказывается, что все предложенные ранее подходы не работают если нормально протестировать — и это среди отрецензированных статей!

Совершенно уверен, что если взять все проекты прошедшего кемпа и подробно проверить результаты, то в основном окажется либо невоспроизводимость, либо отсутствие стат. значимости, либо отсутствие прироста над бейзлайнами, либо слабость/отсутствие бейзлайнов, либо непрактичность тест сета (оверфит под узкий датасет) или метрик. Но демотивировать студентов неудачами, которые в науке являются нормой, либо приукрашивать результаты и скрывать проблемы в презентациях тоже не хочется — не надо учить плохому.

Какие выводы я сделал

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

Бенчмарк для русскоязычных RAG-систем.
Тестирование качества и типология ошибок audioLLM.
Дистилляция CoT-ризонинга и анализ ее эффективности и проблем.
Пайплайн автономного вождения с помощью VLLM.

Заключение

Перефразизуя Страх и ненависть в Лас-Вегасе:

У нас было несколько мощнейших моделей, которые никто еще не тестировал на выбранной задаче, пара идей, алгоритмов и гора датасетов. Все это конечно нужно было для успешного ресерча: раз начал коллекционировать, то иди в своём увлечении до конца. Единственное, что меня беспокоило — это то, что метрики мы считали за час до выступления команды с результатами. В мире нет никого более беспомощного, чем ресерчер, который выполнил 90% работы, но не успел посчитать финальные цифры метрик. И я знал, что довольно скоро мы в это окунёмся.

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

Менеджмент студенческих ML-проектов на примере Yandex Camp