Организованная кодовая база позволяет быстрее вносить изменения и делать меньше ошибок, что в конечном итоге приводит к более высокому качеству кода и модели. Прочтите больше, чтобы узнать, как структурировать свои проекты машинного обучения с помощью Tensorflow Extended (TFX), простого и понятного способа.

Структура проекта: требования

  • Разрешить эксперименты с multiple конвейерами
  • Поддерживает как режим выполнения alocal, так и режим выполнения deployment. Это обеспечивает создание двух отдельных рабочих конфигураций, первая из которых используется для локальной разработки и сквозного тестирования, а вторая - для работы в облаке.
  • Reuse code в разных вариантах конвейера, если это имеет смысл
  • Обеспечить простой в использованииCLI interface для выполнения конвейеров с разными configurations и данными

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

Структура проекта: проектные решения

  • Используйте Python.
  • Используйте Tensorflow Extended (TFX) в качестве структуры конвейера.

В этой статье мы продемонстрируем, как запустить конвейер TFX как локально, так и на установке Kubeflow Pipelines с минимумом проблем.

Побочные эффекты, вызванные дизайнерскими решениями

  • Используя TFX, мы собираемся использовать tensorflow. Имейте в виду, что tensorflow поддерживает больше типов моделей, таких как усиленные деревья.
  • Apache Beam может выполняться локально, в любом месте, где работает Kubernetes, и у всех поставщиков общедоступного облака. Примеры включают, но не ограничиваются: GCP Dataflow, Azure Databricks.
  • Благодаря Apache Beam нам нужно убедиться, что код проекта легко упаковывается с помощью python’ssdist для максимальной переносимости. Это отражается на модульной структуре верхнего уровня проекта. (Если вы используете внешние библиотеки, не забудьте включить их, указав аргумент для Apache Beam. Подробнее об этом см. Apache Beam: Управление зависимостями конвейера Python.

[Необязательно] Прежде чем продолжить, найдите время, чтобы прочитать о предоставляемом TFX CLI. В настоящее время он ужасающе медленный в работе, а структура каталогов намного более многословна, чем должна быть. Он также не включает никаких примечаний о воспроизводимости и повторном использовании кода.

Структура каталогов и интуиция, стоящая за ней

  • $project-name - это корневой каталог вашего проекта
  • $project-name/ml включает материалы, связанные с машинным обучением.
  • $project-name/ml/pipelines включает фактический код конвейера машинного обучения
  • Как правило, вы можете столкнуться с несколькими конвейерами машинного обучения для управления, такими как $project-name/ml/pipelines/predict-sales и $project-name/ml/pipelines/classify-fraud или аналогичные.
  • Вот простой tree вид:

$project-name/ml/pipelines включает следующее:

  • data → небольшой объем репрезентативных обучающих данных для локального запуска для тестирования и CI. Это верно, если в вашей системе нет специального компонента для извлечения данных откуда-то. Если это правда, обязательно включите выборочный запрос с небольшим ограниченным количеством элементов.
  • util → код, который используется повторно и совместно используется $pipeline-name s. Необязательно включать input_fn_utils.py и model_utils.py. Используйте здесь все, что имеет смысл. Вот некоторые примеры:

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

Построение метаграфа обслуживающей сигнатуры с использованием вывода Tensorflow Transform.

Предварительная обработка объектов в группы с помощью ключей.

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

  • cli.py → точка входа и интерфейс командной строки для конвейеров. Вот несколько общих моментов, которые следует учитывать при использовании TFX.

Используя abseil, вы можете объявлять флаги и обращаться к ним глобально. Каждый модуль определяет специфические для него флаги. Это распределенная система. Это означает, что общие флаги, такие как --data_dir=..., --hparam_tuning, --pipeline_root, --ml_metadata_url, --use_cache, --train_epochs, можно определить в фактическом файле cli.py. Другие, более конкретные для каждого конвейера могут быть определены в подмодулях.

Этот файл действует как точка входа в систему. Он использует содержимое в pipeline.py для настройки компонентов конвейера, а также для предоставления файлов модулей, предоставленных пользователем (в примере дерева это constants.py, model.py, training.py) на основе некоторого флага, такого как --pipeline_name=$pipeline-name, или какой-либо другой конфигурации.

Наконец, в собранном конвейере он вызывает некоторый _runner.py файл, используя флаг --runner=.

  • pipeline.py → параметризованное объявление и подключение компонентов трубопровода. Обычно это просто функция, которая объявляет набор компонентов TFX и возвращает объект tfx.orchestration.Pipeline.
  • local_beam_dag_runner.py → конфигурация для локальной работы с портативным бегуном Beam. Обычно это практически не требует настройки, просто используя BeamDagRunner.
  • kfp_runner.py → конфигурация для работы на конвейерах Kubeflow. Обычно это включает различные префиксы путей к данным и выходных конвейеров, а также автоматическую привязку экземпляра ml-метаданных.

Примечание: у вас может быть больше бегунов, например, что-то, что работает на GCP, и просто настраивает больше ресурсов обеспечения, таких как экземпляры TPU, параллельный поиск гиперпараметров платформы AI и т. Д.

$ имя-конвейера

Это предоставленный пользователем код, который создает разные модели, планирует разные эксперименты и т. Д.

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

В результате экспериментов я пришел к разделению на constants, model и training.

  • constants.py → объявления. Разумные значения по умолчанию для параметров обучения, ключей и объявлений гиперпараметров, ключей функций, групп функций, конфигураций оценки и показателей для отслеживания. Вот небольшой пример:
  • model.py → Определение модели. Обычно содержит функцию build_keras_model и использует импорт из util и $pipeline-name.constants. Вот пример из моего недавнего проекта:
  • Наконец, training.py включает в себя всю суету, необходимую для обучения модели. Обычно это: определение предварительной обработки, поиск гиперпараметров, настройка обучающих данных или модели - параллельные стратегии и журналы тензорной платы и сохранение модуля для производства.

Вот и все. Спасибо, что дочитали до конца!

Я надеюсь, что вам понравилось читать эту статью так же, как мне понравилось ее писать.