Методы, которые могут значительно повлиять на методы работы отдела машинного обучения в 2022 году

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

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

Давайте начнем с обзора структуры технического радара.

Структура технического радара

Основа и вдохновение для некоторых тем были взяты из Tech Radar, поддерживаемого Thoughtworks. Он довольно хорошо известен и был принят многими известными организациями, такими как Zalando, или такими платформами, как Backstage. Структура управляется комитетом, хорошо известным в ИТ-индустрии. Он хорошо документирован и представлен и поставляется с простой в использовании библиотекой с открытым исходным кодом.

Структура технических радаров, состоящая из четырех категорий и четырех этапов внедрения. Категории определяются следующим образом.

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

Этапы принятия определяются следующим образом.

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

Управление техническим радаром

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

В первом случае организация ML должна обновлять радар не реже двух раз в год. Во втором случае комитет по управлению техническим радаром должен включать в себя старших инженеров, специалистов по данным, аналитиков, менеджеров по продуктам и инженеров, специалистов по данным и ведущих аналитиков. Их число не должно быть слишком большим, чтобы комитет оставался гибким. Однако член организации должен собирать отзывы от своих коллег и членов команды, чтобы обеспечить широкий охват. Наконец, платформа для технического радара должна представлять собой своего рода панель инструментов или платформу веб-интерфейса, которая упрощает просмотр, поиск и визуализацию информации. Лично я бы рекомендовал разрабатывать платформу с использованием библиотеки с открытым исходным кодом Thinkworks. Для управления информацией я бы порекомендовал формат файла CSV, похожий на то, что рекомендует Thoughtworks. Для развертывания я бы использовал сервер с легко запоминающимся URL-адресом. Кроме того, я бы рекомендовал построить платформу таким образом, чтобы на ней можно было разработать несколько технических радаров. Например, поддержка технического радара для внутреннего использования и еще одного для внешнего использования или сохранение всех версий технического радара.

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

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

Млопс

Стадия принятия: использование

MLOpsвключает в себя элементы, имеющие общее происхождение с DevOps, но применяемые для разработки/развертывания моделей машинного обучения. Как и DevOps, он охватывает системы, практики и людей. Со стороны системы он включает в себя решения для непрерывной интеграции и развертывания (CI/CD) не только для кода, но и для моделей машинного обучения. С практической стороны он включает в себя процессы и способы работы, направленные на повышение автоматизации и надежности моделей в производстве. Что касается людей, то в нее входят специалисты по данным и разные инженеры в команде машинного обучения, которые применяют эти методы с использованием этих систем. Если ваша организация серьезно относится к использованию машинного обучения, она должна принять эту мантру. Многие организации все еще занимаются специальной наукой о данных и танцуют вокруг проблемы увеличения/создания ценности для бизнеса с помощью ML. Прежде чем прыгать на подножку, организация должна провести серьезную комплексную проверку, чтобы выяснить, является ли это правильным путем. Как только это будет установлено, чем дольше организация будет ждать принятия, тем дороже будет для организации пожинать плоды.

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

Стадия принятия: использование

Продукты платформы машинного обучения и команды, разрабатывающие их, станут важным инструментом для создания готовых к производству приложений машинного обучения в организации. Здесь я черпал вдохновение из Team Topologies, но рассматривал контекст приложений ML, а не типичных ИТ-систем. Команды по продуктам платформы машинного обучения можно рассматривать как еще одну продуктовую команду, которая фокусируется исключительно на внутренних клиентах платформы, например, на командах машинного обучения и аналитики в организации. Для каждой такой команды крайне важно иметь тонкий, но высокоэффективный продукт и стабильный поток благодарных клиентов. Просто потому, что эти команды работают исключительно с внутренними заказчиками, они все равно не должны упускать из виду инженерные дисциплины и способы рабочих процессов, как любая команда, ориентированная на внешний продукт. Когда в организации появляется три или более команд машинного обучения, ориентированных на потоки, ей следует начать думать о том, как вырастить команду платформы, поддерживающую эти команды. Если это число удвоится, команды платформы по-прежнему нет, организация должна обеспечить изменение реальности как можно скорее.

Командное программное обеспечение

Стадия принятия: использование

Закон Конвея гласит, что организация будет производить системный дизайн, следуя своей коммуникационной структуре. Это не отличается для организаций ML. Как утверждается в Team Topologies, которая отменяет закон быстрого потока ИТ-команд, лучше всего сосредоточить внимание на программной системе, основываясь на когнитивной нагрузке команды. В связи с этим я рекомендую, чтобы каждая команда машинного обучения оставалась командой двух пицц, сохраняя при этом объем приложения машинного обучения и его взаимодействия в команде.

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

Стадия принятия: Тест

Во времена COVID процветало удаленное парное программирование. До этого, в дополнение к парному программированию, Моб-программирование стало рекомендуемым подходом для быстрого потока команд разработчиков программного продукта. Этот метод стал еще более актуальным, поскольку он позволяет командам «толпиться над проблемой или решением без каких-либо ограничений физического пространства/присутствия. Современные инструменты для видеоконференций, онлайн-платформы для кодирования и цифровые доски упростили работу с удаленными командами лучше, чем когда-либо. Для команды машинного обучения типично работать изолированно из-за разнообразия ролей в команде: специалист по данным, аналитик данных, инженер по машинному обучению, инженер по данным, инженер-программист и т. д. Тем не менее, я предлагаю серьезным командам машинного обучения извлечь урок из успешные кросс-функциональные команды разработчиков программного обеспечения, разбивают виды деятельности и часто объединяются в единое целое, используя такие методы, как групповое программирование, но в полной удаленной обстановке. Причина, по которой я рекомендую попробовать это, заключается в новизне практики и том факте, что что-то близкое к полезной платформе для удаленного программирования мобов еще впереди.

Реальные данные в среде разработки/тестирования

Стадия принятия: удержание

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

  • Увеличение стоимости разработки/тестирования, что является существенным фактором, влияющим на общие затраты на инфраструктуру команды.
  • Снижение понимания поведения программного обеспечения
  • Более медленный цикл обратной связи из-за использования больших объемов данных
  • Повышенные риски безопасности из-за настройки с низким уровнем безопасности в средах разработки и тестирования.

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

Примечания

Thoughtworks перечислил 17 техник, актуальных для мира технологий, некоторые из которых соответствуют шорт-листу на тематическом уровне. Однако, поскольку контекст в некоторой степени специализирован, детали несколько более нюансированы. Считаете ли вы, что в первую пятерку должно входить что-то еще, кроме того, что я здесь перечислил? Пожалуйста, прокомментируйте и поделитесь своим выбором. Считаете ли вы, что можете внести свой вклад в эти детали и хотели бы приложить свою энергию к этим темам? Может, посотрудничаем. Пожалуйста, свяжитесь с нами.