Последние два десятилетия дали нам глубокое понимание разработки программного обеспечения. Во многом это связано с появлением DevOps и его широким использованием в отрасли.
Все ведущие компании-разработчики программного обеспечения следуют одной и той же схеме: сначала быстрая итерация в разработке программного обеспечения, затем непрерывная интеграция, непрерывная поставка, непрерывное развертывание. Каждый артефакт проверяется на его способность приносить пользу, а программное обеспечение всегда находится в состоянии готовности и развертывается с помощью автоматизированных методов.
Область машинного обучения отличается от традиционной разработки программного обеспечения, но мы также можем извлечь много практических уроков из индустрии разработки программного обеспечения. Последние несколько лет мы разрабатываем производственные проекты по машинному обучению. Наша цель — не только проверить концепцию, но и добиться такой же повторяемости и воспроизводимости, как при разработке программного обеспечения. Итак, мы создали оркестратор конвейера машинного обучения с мощными возможностями автоматизации и построили рабочий процесс, чтобы это произошло.
Почему бы просто не использовать Jupyter Notebook? Сколько времени занимает создание набора блокнотов со всеми этапами обработки с нуля? Насколько легко новичкам присоединиться к команде? Можете ли вы сейчас быстро воспроизвести результаты двухмесячной давности? Можете ли вы сравнить сегодняшние результаты с историческими результатами? Можете ли вы предоставить источник данных во время обучения? Что произойдет, если ваша модель устарела?
У нас были все эти проблемы. Теперь мы подытожили эти уроки и придумали 12 элементов для успешного построения готового к производству машинного обучения (аналогично 12 элементам в разработке программного обеспечения).
1. Контроль версий
Контроль версий, по сути, не составляет труда для инженеров-программистов, но эта методология еще не получила широкого признания среди ученых, занимающихся данными. Позвольте мне процитировать некоторых людей из Gitlab для быстрого начала:
Контроль версий облегчает координацию, совместное использование и совместную работу групп разработчиков программного обеспечения. Программное обеспечение для контроля версий позволяет командам работать в распределенных и асинхронных средах, управлять изменениями и версиями кода и файлов, а также разрешать конфликты слияния и связанные с ними исключения.
Проще говоря, контроль версий позволяет безопасно управлять изменяющимися частями разработки программного обеспечения.
Машинное обучение на самом деле представляет собой особый вид разработки программного обеспечения со своими уникальными потребностями. Во-первых, меняется не одна, а две части машинного обучения: код и данные. Во-вторых, машинное обучение на самом деле представляет собой особый вид разработки программного обеспечения со своими специфическими требованиями. Во-вторых, способ обучения модели является (быстрым) итеративным, а дисперсия в коде может быть большой (например, разделение данных, предварительная обработка, инициализация модели).
Как только данные изменяются, их необходимо версионировать, чтобы можно было воспроизвести эксперименты и модели. Простой и грубый контроль версий (жесткая копия) имеет много возможностей для улучшения, но (особенно) в случае совместного использования в команде контроль версий, который может оставаться неизменным, имеет решающее значение.
Версии кода более важны. В дополнение к приведенным выше цитатам, код предварительной обработки важен не только на этапе обучения, но и на этапе обслуживания и должен иметь постоянную корреляцию с моделью. Чтобы создать своего рода золотую середину между рабочим процессом специалиста по данным и необходимостью перехода в производство, бессерверная архитектура может предоставить легкодоступный способ.
Резюме: вам необходимо контролировать версии вашего кода, но вам также необходимо контролировать версии ваших данных.
2. Явные зависимости функций
В идеальном мире любые входные данные всегда будут производить одни и те же данные, по крайней мере, структурно. Но мир не идеален, и данные, которые вы получаете от восходящих служб, также создаются людьми, поэтому они могут измениться. В конечном итоге характеристики тоже могут измениться. В лучшем случае ваша модель просто выйдет из строя и выйдет из строя полностью, а в худшем ваша модель будет молча продолжать работать, но результаты вы получите мусор.
Четко определенные зависимости функций позволяют обнаруживать сбои на раннем этапе. Хорошо спроектированная система адаптируется к зависимостям функций во время непрерывного обучения и обслуживания.
Резюме: Сделайте зависимости ваших функций явными в вашем коде.
3. Описательное обучение и предварительная обработка
Хорошее программное обеспечение имеет хорошие описания и комментарии — его легко читать и понимать, что делает код, не читая каждую строку кода.
Хотя машинное обучение — это особый вид разработки программного обеспечения, оно не освобождает практиков от соблюдения установленных правил кодирования. Одним из самых основных требований к кодированию кода является базовое понимание кода с небольшими усилиями и коротким временем.
Код для предварительной обработки, обучения и прогнозирования модели должен соответствовать PEP8. Код должен использовать осмысленные имена объектов и включать понятные комментарии. Следование спецификации PEP8 улучшает читаемость кода, снижает сложность и ускоряет отладку. Парадигмы программирования, такие как SOLID, предоставляют рекомендации для мышления, которые делают код более удобным для сопровождения, понятным и гибким для будущих вариантов использования.
Конфигурация должна быть отделена от кода. Не закладывайте соотношение распределения данных жестко в код, а предоставляйте его в конфигурации, которую можно изменить во время выполнения. Это уже хорошо известно с точки зрения настройки гиперпараметров: использование отдельных файлов конфигурации может значительно ускорить итерацию и позволить повторно использовать кодовые базы.
Резюме: улучшите читаемость кода и отделите код от конфигурации.
4. Результаты обучения воспроизводимы
Если вы не можете воспроизвести результаты обучения, вы не можете доверять результатам. Хотя это и является предметом данной статьи, есть несколько деталей, на которые следует обратить внимание, когда дело доходит до воспроизводимости. Не только вы должны быть в состоянии воспроизвести результаты обучения самостоятельно, но и вся ваша команда должна быть в состоянии сделать это. Неуловимые результаты обучения в Jupyter Notebooks, будь то на ПК или на виртуальной машине AWS, противоречат воспроизводимости.
Используя конвейеры для обучения моделей, вся команда имеет прозрачный доступ к проведенным экспериментам и обучению. Объединив повторно используемую кодовую базу с отдельными файлами конфигурации, каждый может успешно переучиться в любое время.
Резюме: автоматизируйте свой рабочий процесс с помощью конвейеров.
5. Тест
Тестирование существует во многих формах. Два примера:
- Юнит-тестирование — это тестирование на атомарном уровне — каждая функция тестируется отдельно по своим конкретным критериям.
- В интеграционном тестировании используется противоположный подход — совместное тестирование всех элементов кодовой базы, а также тестирование клонированных или имитационных версий вышестоящих и нижестоящих сервисов.
Обе парадигмы подходят для машинного обучения.
Код предварительной обработки должен быть модульно протестирован — с учетом различных входных данных, даст ли преобразование правильный результат?
Модели — хороший вариант использования для интеграционного тестирования: при использовании модели в производстве ваша модель работает так же хорошо, как и при оценке?
Резюме: протестируйте свой код, протестируйте свою модель.
6. Дрейф моделей/непрерывное обучение
В производственных сценариях дрейф модели является законной проблемой. Пока существует возможность изменения данных (например, пользовательский ввод, нестабильные восходящие сервисы), вам необходимо учитывать возможность дрейфа модели. Есть два действия, которые можно предпринять в отношении риска этой проблемы:
-
Мониторинг данных в производственных системах. Создайте автоматизированные механизмы отчетности, чтобы уведомлять команды об изменении данных, возможно, даже за пределами четко определенных зависимостей функций.
-
Непрерывное обучение на новых входных данных. Хорошо автоматизированные конвейеры могут быть повторно запущены на вновь записанных данных и обеспечивать сравнение с историческими результатами обучения, чтобы показать снижение производительности и обеспечить быстрый способ запуска новых обученных моделей в рабочую среду, чтобы модели работали лучше.
Итог: если ваши данные будут меняться, используйте конвейер непрерывного обучения.
7. Отслеживание экспериментальных результатов
Excel — не лучший способ отслеживать результаты экспериментов. И это касается не только Excel, любая информация в виде децентрализованного ручного отслеживания не является ни авторитетной, ни заслуживающей доверия.
Правильный подход — автоматически записывать результаты обучения в централизованное хранилище данных. Автоматизация обеспечивает надежное отслеживание каждой тренировки, что упрощает последующее сравнение результатов каждой тренировки. Централизованное хранилище результатов обеспечивает прозрачную информацию между командами и обеспечивает непрерывный анализ.
Резюме: Отслеживайте экспериментальные результаты с помощью автоматизированных методов.
8. Экспериментальные и серийные модели
Понимание наборов данных требует усилий. Как правило, мы достигаем понимания с помощью экспериментов, особенно когда в области нашего внимания много скрытых знаний. Создайте Jupyter Notebook, импортируйте некоторые/все данные в Pandas Dataframe, проведите несколько часов неупорядоченных исследований, обучите первую модель, затем оцените результаты — задача выполнена. Но, к сожалению, реальность не такова.
Эксперименты являются целенаправленными в жизненном цикле машинного обучения. Однако результаты этих экспериментов — не модели, а понимания. Модели на основе исследовательских ноутбуков Jupyter предназначены для понимания, а не готовых продуктов, разработанных для производства. После понимания требуется дальнейшая разработка и адаптация, прежде чем вы сможете начать строить процесс обучения для производства.
Однако любое понимание, независимое от знания предметной области, может быть автоматизировано. Создавайте статистику для каждой версии данных, которые вы используете, чтобы вы могли пропустить те одноразовые специальные исследования, которые вы делали в Jupyter Notebooks, и сразу перейти к первому конвейеру. Чем раньше вы начнете экспериментировать в конвейере, тем быстрее вы сможете совместно работать над промежуточными результатами и тем быстрее вы сможете создать готовую к производству модель.
Итог: ноутбуки не могут быть запущены в производство, поэтому экспериментируйте как можно раньше в конвейерном процессе.
9. Тренировочная предвзятость
Training-Serving-Skew относится к разнице между производительностью во время обучения и производительностью фактической сгенерированной среды во время работы. Это смещение может быть вызвано следующими факторами:
- Обрабатывайте данные по-разному во время обучения и в реальном рабочем процессе производственной среды.
- Данные в обучении отличаются от фактических данных.
- Между моделью и алгоритмом существует обратная связь.
Чтобы избежать смещения между обучающей и производственной средами, часто необходимо правильно внедрить всю предварительную обработку данных в среду обслуживания модели. Это, безусловно, верно, и вы также должны соблюдать этот принцип. Однако это также слишком узкая интерпретация смещения обучения (обучение-обслуживание-перекос).
Давайте начнем с краткого обзора старой истории DevOps: в 2006 году технический директор Amazon Вернер Фогельс придумал фразу «Вы создаете это, вы запускаете это» (вы создаете это, вы запускаете это). Это описательная фраза, означающая, что разработчик несет ответственность не только за написание программ, но и за их выполнение.
Проекты машинного обучения требуют аналогичного механизма — понимание как восходящей генерации данных, так и использования нисходящей модели входит в компетенцию специалиста по обработке и анализу данных. Какую систему вы использовали для получения данных для обучения? Это пойдет не так? Каков целевой уровень обслуживания (SLO) для этой системы? Соответствует ли это целям реальной службы производственной среды? Как обслуживается ваша модель? На что похожа среда выполнения? Как предварительно обработать функцию при обслуживании процесса? Это вопросы, которые специалисты по данным должны понять и ответить на них.
Резюме: правильно внедрите предварительную обработку в производственную модель, чтобы убедиться, что вы понимаете восходящие и нисходящие потоки данных.
10. Сопоставимость
Сопоставимость была важной частью будущей работы с момента введения второго сценария обучения для проекта. Если результаты второй модели не могут быть сопоставлены с результатами первой модели, пропадает весь процесс, по крайней мере один из которых является избыточным, а возможно и оба.
По определению, все модели обучения, пытающиеся решить одну и ту же проблему, должны быть сопоставимы, иначе они не решают одну и ту же проблему. Хотя итеративный процесс может привести к изменениям в том, что сравнивается, технически обеспечение сопоставимости обучения модели должно быть встроено в архитектуру обучения в качестве основной функции с самого начала.
Итог: создайте собственный конвейер с конвейером, чтобы можно было легко сравнивать результаты обучения в разных конвейерах.
11. Мониторинг
Грубо говоря, цель машинного обучения должна состоять в том, чтобы решать проблемы, изучая данные. Для решения этой проблемы необходимо выделить вычислительные ресурсы. Сначала на модель назначается обучение, затем на модель назначается обслуживание. Либо человек, либо отдел, ответственный за предоставление ресурсов во время обучения, должен нести ответственность за передачу этих ресурсов службе. Во время использования модели может возникнуть множество проблем с ухудшением производительности. Данные могут дрейфовать, модели могут стать узким местом в общей производительности, а предвзятость — настоящая проблема.
Производительность модели: специалисты по обработке и анализу данных несут ответственность за мониторинг создаваемых ими моделей. Они не обязательно несут ответственность за осуществление мониторинга, особенно если организация большая, но они, безусловно, должны нести ответственность за понимание и интерпретацию отслеживаемых данных. Как минимум, объекты для мониторинга включают в себя входные данные, накладные расходы времени на вывод, использование ресурсов (например, ЦП, ОЗУ) и выходные данные.
Резюме: Опять же, «Вы строите это, вы управляете этим». Мониторинг моделей в производстве является частью работы по науке о данных.
12. Возможность развертывания модели
Технически каждый процесс обучения модели должен производить готовый продукт, который можно развернуть в рабочей среде. Несомненно, результаты этой модели могут быть ужасными, но это должен быть готовый продукт, который можно развернуть в производственной среде.
Это распространенный шаблон в разработке программного обеспечения, также известный как непрерывная доставка. Команды должны иметь возможность развертывать свое программное обеспечение в любое время, и для достижения этой цели цикл итераций должен быть достаточно быстрым.
Аналогичный подход требуется для машинного обучения. Это заставляет команду в первую очередь учитывать баланс между реальностью и ожиданиями. Всем заинтересованным сторонам должно быть ясно, какие результаты теоретически возможны с точки зрения результатов модели. Все заинтересованные стороны должны договориться о том, как модель будет развернута и как она будет интегрирована с более крупной архитектурой программного обеспечения. В то же время это также требует более надежной автоматизации и обязательно будет использовать большинство элементов, изложенных в предыдущих параграфах.
Итог: Результатом каждого процесса обучения должен быть готовый к развертыванию продукт, а не «просто» модель.
Эпилог
Это ни в коем случае не исчерпывающий список. Он включает в себя наш опыт, и вы можете использовать его в качестве эталона, в качестве шаблона для тестирования вашей производственной архитектуры или в качестве плана для разработки вашей собственной архитектуры продукта.
Оригинальная ссылка:12 Factors of reproducible Machine Learning in production