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

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

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

# Pipeline to predict fancy ml task

# dataset 
dataset = FancyMLTaskDataset(ds='x')
# features
dataset['feat1'] = SpecialFeature1(dataset['id']) 
dataset['feat2'] = SpecialFeature2(dataset['id'])
# transforms
dataset['t_feat1'] = Transform1(dataset['feat1'])
dataset['t_feat2'] = Transform2(dataset['feat2'])
# model
model = TrainModel(algorithm, 
features = [dataset['t_feat1'],dataset['t_feat2'], 
hyperparams = [...]
)
# evaluation
...
# serving 
...

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

Экспериментирование — неотъемлемая часть разработки модели, а стабильность конвейерного кода — основной фактор скорости экспериментирования.

Проблемы тестирования интеграции машинного обучения:

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

Это обычная практика в разработке стандартного программного обеспечения, в чем тут проблема?

  • Сложно измерить последующее влияние изменений компонентов. Допустим, вы изменили преобразование. Вы запустили модульные тесты, и они выглядят нормально. Но как вы надежно отправляете свои изменения? Преобразование используется в нескольких конвейерах, и запуск всех конвейеров требует огромных ресурсов.
  • Стоимость работы: комплексное обучение конвейера машинного обучения может быть довольно дорогим. Большие наборы данных, дорогостоящая характеристика и обучение нескольких узлов в течение длительных периодов времени со специализированным оборудованием (gpus) очень распространены.
  • Каждый конвейер — это система ОД. Если мы рассматриваем каждый конвейер как отдельную систему ОД, мы видим очень большое количество систем, взаимодействующих с внешним миром. Кроме того, набор тестов на работоспособность и правильность должен выполняться с регулярной частотой (желательно каждый день).

Итак, как мы разрабатываем удобные интеграционные тесты?

Сначала мы разделим наши тесты на две разные цели: здравомыслие и правильность управления затратами.

Вменяемость проверяет:

  • Запустите сквозной конвейер на 1% случайно выбранном наборе данных. Запустите серию простых тестов на выходах конвейера, например:
1. The model artifact is produced and can be loaded in memory. 
2. An example input can be fed to model and output predictions observed. (The output shape should match task formulation (for multiclass outputs).
3. Other pipeline outputs are as expected - evaluation report has metrics, plots. 
etc
We do not check for correctness here, just that the pipeline can run end to end.

Эталонный анализ проверяет правильность:

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

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

Мегаконвейер = эталонные наборы данных x применимые архитектуры моделей

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

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

Подведение итогов:

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

Ссылки:

[1] https://developers.google.com/machine-learning/testing-debugging/pipeline/deploying

[2] Машинное обучение: кредитная карта технического долга с высокими процентами D. Sculley et al.