Мои тщательно подобранные лучшие практики для первоклассных исследований и разработок. Не пропустите номер 3!

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

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

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

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

0. Ваш код не является «самодокументирующимся»

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

Несмотря на это, как может подтвердить любой, кто взглянул на работу с открытым кодом на GitHub, мы постоянно не делаем это должным образом. Мое нулевое правило не касается простого соблюдения PEP8 (пожалуйста!) Или правильного наименования функций (вы не возражаете?).

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

Однако есть ценность в балансе между потерей производительности из-за «преждевременной разработки» и удобством использования исследовательского кода в дальнейшем.

1. Следите и продолжайте

Первое правило любой успешной команды специалистов по анализу данных - эффективное управление версиями.

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

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

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

Без эффективного постоянного управления версиями динамический процесс воспроизводимости в лучшем случае затруднен, в худшем - невозможен.

2. Яблоки в яблоки

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

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

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

3. Вы не можете писать слова без «U» и «I».

Предыдущее руководство также распространяется на взаимодействие между НИОКР и производством. Даже самые хорошо спроектированные и тщательно проверенные модели могут дать сбой или дать неожиданные результаты, если среда обучения и обслуживания (производственная среда) не совпадают.

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

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

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

4. Планируйте несогласованность в источниках данных.

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

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

Таким образом, воспроизводимость действительно действительно начинается с источника. Опытный специалист в области машинного обучения никогда не считает само собой разумеющимся, что его или ее данные являются «чистыми» и непротиворечивыми, и проверяет (часто!), Что никакие критические зависимости не изменились при получении и форматировании данных.

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

Четкое указание всех зависимостей в вашем коде поможет предотвратить это; также рекомендуется реализовать конвейерное тестирование.

5. Тестирование - это не просто «показатели».

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

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

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

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

6. Отслеживание, отслеживание еще раз

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

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

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

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

7. Использование платформы, чтобы связать все вместе

Итак, мы рассмотрели множество важных аспектов управления версиями и отслеживанием (в дополнение к тестированию). Компоненты инфраструктуры, необходимые для выполнения предыдущих рекомендаций, в настоящее время доступны в виде решений с открытым исходным кодом.

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

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

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

Закрытие

Это были мои 7 (на самом деле 8) золотых рекомендаций по исследованиям и разработкам в области машинного обучения. Последний вывод и есть вывод: используйте платформу, которая содержит рекомендации для вас.

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

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

Первоначально опубликовано на https://allegro.ai 5 октября 2020 г.