Чему я научился у лучших и худших руководителей групп машинного обучения

Станьте эффективным руководителем группы машинного обучения

Управление коммуникациями, инфраструктурой и документацией

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

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

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

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

Проблемы ведущих проектов машинного обучения

Хотя проекты разработки программного обеспечения и машинного обучения имеют много общего, ведущие проекты машинного обучения могут различаться по нескольким причинам:

  • Проекты машинного обучения часто сопряжены с более высокими рисками. В отличие от программных проектов, где задача состоит в построении системы из детерминированных блоков, реализуемость задач, решаемых проектами машинного обучения, часто заранее неизвестна — будет ли у нас достаточно данных, будут ли данные приемлемого качества, будет ли модель достаточно большой. чтобы зафиксировать отношения, хватит ли нам вычислительной мощности?
  • Труднее установить сроки, вехи и планы. Хотя эта область все еще развивается, и готовых решений для каждой проблемы нет, модели машинного обучения необходимо создавать с нуля. Следовательно, проекты машинного обучения в конечном итоге ориентированы на исследования. Для этих проектов прогнозировать временные рамки может быть сложно, так как многие решения могут быть приняты только после завершения определенного этапа.
  • Отсутствие показателей производительности затрудняет отслеживание и оценку производительности. Некоторые проблемы имеют четкую цель — например, оценивая спам-фильтр, мы можем объективно сказать, что он отфильтровывает 99% спам-сообщений, в то время как для более субъективных проблем сложнее определить метрики производительности. Возьмем, к примеру, фильтр для украшения — как мы можем измерить, хорошо ли он работает, без изучения пользователей? А получение достаточного количества достоверных данных от пользователей часто бывает затратным, медленным и сложным, особенно с учетом жестких требований GDPR.
  • Очень распространены мультидисциплинарные проекты. Таким образом, члены команды, скорее всего, будут иметь очень узкую специализацию, и для продвижения проекта коммуникация внутри команды должна быть отличной.

Многие описанные выше трудности можно преодолеть, сосредоточив внимание на аспектах, важных для проектов машинного обучения, — коммуникации, инфраструктуре и документации.

Коммуникация

Команды разработчиков программного обеспечения не принято готовить презентации для совещаний. Тем не менее, это гораздо более распространено для проектов машинного обучения, поскольку многие компоненты легче передать через график — функции потерь, распределение данных, артефакты в сгенерированных результатах и ​​многое другое.

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

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

Практические заметки

  • Начинайте и заканчивайте вовремя. Учтите несколько минут в начале, чтобы люди могли присоединиться и пообщаться в чате, чтобы настроиться на встречу. Небольшая беседа в начале не отнимет много времени у технического обсуждения, но поднимет боевой дух команды.
  • Дайте людям время собраться, включить свой звук в Zoom и высказаться. После того, как спросите, есть ли вопросы, посчитайте в уме до десяти.
  • Будьте последовательны и подавайте пример. Если вы принимаете что-то за правило, практикуйте это. Попросил команду представить? Установите стандарт.
  • Если вы не уверены, решена ли задача, попросите члена команды обсудить задачу и определить потенциальные проблемы.
  • Не получаете никакой обратной связи? Возможно вопрос не правильно сформулирован. Вместо того, чтобы спрашивать «Есть ли какие-либо вопросы или проблемы с текущим подходом?», скажите более конкретно и дайте людям самим решить, перефразируйте на «Каковы лучшие способы загрузки данных?».
  • Хвалите публично, критикуйте наедине — классика на все времена. Хотите поощрить модель поведения? Вознаградите его на собрании группы. Например, многим людям неудобно задавать вопросы. Но поднимать вопросы и освещать проблемы важно — кто-то поднимал проблему в групповом чате в течение недели? Групповые встречи — хорошее время, чтобы поблагодарить их. Отличная книга о том, как давать обратную связь, — Радикальная откровенность Ким Скотт.
  • Не пытайтесь заниматься и тем, и другим — проектированием и управлением. Если вы ведете проект, то ведите и управляйте. Делегат. С учетом того, насколько специализирован каждый член команды машинного обучения, микроуправление не только разозлит команду, но и навредит результатам.
  • Члены команды должны знать, почему то, что они делают, важно. Пусть команда участвует в процессе формирования задач и приоритизации, большинство членов команды являются экспертами в предметной области. Делегировать будет проще, если решение о дальнейших действиях исходит от команды — тогда ваша роль сводится к модерированию.
  • Честность помогает укрепить доверие между вами и членами команды. Если вы чего-то не понимаете, скажите об этом честно. Если вы видите, что задание не очень интересное, но нужное, не пытайтесь его продать, а объясните, как есть. Будьте честны, и это будет оценено.
  • Обязательно запрашивайте разрешение у членов команды, прежде чем редактировать или делиться своей работой.
  • У всех разные приоритеты, ожидания и страхи. Изучение того, что человек хочет от работы, поможет руководителю команды поставить человеку правильные задачи.
  • Если вы не знаете человека, будьте осторожны, предполагая, чего он хочет. Отбрасывание «Это будет хорошо для вашего резюме», когда постановка задачи противоречит целям члена команды, легко может быть воспринято как дешевая манипуляция.

Инфраструктура

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

Однако систематичность также очень сложна из-за сложных отношений между каждым аспектом окончательной модели — данными, архитектурой и гиперпараметрами. Кроме того, каждый эксперимент генерирует огромные объемы данных, а поскольку проекты ориентированы на исследования, каждый модуль должен часто меняться.

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

Инфраструктура

Интересно, что отличным источником для управления проектами являются книги о войне, например, Искусство войны Сунь Цзы. Одна из мудростей, которой делится книга, заключается в том, что судьба битвы решается до ее начала — побеждает тот, кто лучше всех подготовится.

Одним из наиболее важных аспектов боя являются линии снабжения. Инфраструктура подобна линиям снабжения — для развития проекта инфраструктура не должна иметь внезапных перерывов или блокировок, а также должна быть проста в использовании и расширении.

Лучшие практики управления данными и инфраструктурой, с которыми я столкнулся до сих пор, следующие:

  • Имейте файлы конфигурации для обучения и регистрируйте их. Это поможет воспроизводимости, позволит вернуться назад, чтобы увидеть, как было получено решение, а также уменьшит ошибки в постановке экспериментов.
  • Имейте файлы конфигурации для обучающих данных. Это может быть просто список пар ввод-вывод для модели. Это поможет вам точно знать, на каких данных обучается модель, и упростить загрузчик данных.
  • Используйте разумные значения по умолчанию для аргументов — люди, которые будут запускать код, будут ожидать, что он будет работать «из коробки» без необходимости копать слишком глубоко. Если вам нужно несколько гиперпараметров, удобно иметь сценарий bash с командой для выполнения, так как его легче изменить по сравнению с текстом в терминале.
  • Если позволяют ресурсы, части развертывания, которые можно автоматизировать, должны быть автоматизированы. Автоматизация экономит время команды, устраняя повторения и предотвращая ошибки.
  • То, как организованы обучающие данные, сильно влияет на загрузку данных, скорость обучения, гибкость и удобство анализа результатов. Убедитесь, что данные разделены по типам и не сваливаете все в одну папку — это упростит визуальное изучение существующих данных и добавление новых.
  • Конвейеры обучения и тестирования должны быть максимально похожи — в том, как данные предварительно обрабатываются, постобрабатываются и как загружается модель.

Отслеживание модели

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

Существуют мощные альтернативы tensoboard с отличным набором инструментов для анализа производительности модели, такие как wandb (может быть бесплатным для небольших команд) и aimstack (полностью бесплатный на момент написания статьи).

Сравнение моделей

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

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

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

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

Управление кодом

Работая над несколькими экспериментами, неизбежно возникнет проблема взрыва ветки. Я видел проекты, у которых было более 500 веток на GitHub, и было очевидно, что они никак не могут быть отслежены и хорошо задокументированы.

Поощряйте слияние и архивирование веток, иначе легко заблудиться. Поощряйте небольшие коммиты и PR — большие требуют времени на рассмотрение и в конечном итоге устаревают.

Используйте фреймворки, которые упрощают и абстрагируют части кода — например, pytorch-lightning, который структурирует обучающий код и удаляет части, связанные с настройкой среды.

Еще одна проблема — связать эксперименты с кодом. На каком коде обучались модели? Легко ли отследить? Выход есть — либо оставить хорошо документированный проект, либо использовать автоматические логгеры — MLFlow.

Документация

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

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

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

Дизайн-документ

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

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

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

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

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

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

Дорожная карта

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

Установка временных рамок для задач машинного обучения может быть затруднена, поскольку результаты могут быть неясными — например, установка задачи в дорожной карте с ожиданием 98% отзыва нереалистична, поскольку эксперимент может сработать или не сработать. Вместо этого задачи должны быть разделены на небольшие компоненты с результатом в виде блока кода или набора данных.

Еженедельные заметки

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

Вам, как руководителю группы, полезно иметь сводку результатов/работы каждого человека за неделю перед собраниями, так как во время презентации легче задавать целевые вопросы.

Практические заметки:

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

Краткое содержание

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

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

Понравился автор? Оставайся на связи!

Я ничего не пропустил? Не стесняйтесь оставлять заметки, комментарии или сообщения прямо в LinkedIn или Twitter!