"Машинное обучение"

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

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

Введение

Представьте, что вы работаете над моделью машинного обучения (неважно, какая задача). Вы, наконец, можете заставить его работать прилично на своем тестовом наборе, потратив недели на его разработку на своем локальном компьютере. Теперь вы обнаружите, что модель продолжает давать сбои при развертывании через конвейер сборки. Модель тестировалась на том же тестовом наборе, который вы использовали при локальной разработке, так что же дает?

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

Код для воспроизведения описанных здесь результатов можно найти в этом репозитории.

История

Начнем с этапа локальной разработки.

Локальная модель

Для простоты предположим, что вы строите модель для классификации набора данных MNIST. Ваша цель — создать классификатор, точность которого на тестовом наборе составляет не менее 95 %.

Вы, наконец, достигаете этого после нескольких попыток:

Однако запуск поезда и повторная оценка логики дают другой результат:

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

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

Вот результат первого прогона после отключения случайного перемешивания во время обучения:

и вот результат второго запуска:

Результаты все равно разные! Но, по крайней мере, сейчас разница меньше…

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

Вот что происходит, когда вы устанавливаете случайное начальное число равным 1:

и для второго запуска имеем:

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

Модель конвейера

Читая журналы конвейера сборки, вы заметили:

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

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

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

Поэтому вам придется просто жить с этой разницей.

Практический пример

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

Но на практике вы вряд ли начнете с такого большого набора данных.

Давайте рассмотрим влияние размера набора данных на вариации между запусками на одной и той же машине.

Вот вариант, если у нас есть только 1000 обучающих примеров и 500 тестовых примеров:

Имея всего 1000 обучающих примеров, мы ожидаем, что модель будет работать хуже по сравнению с тем, когда она обучалась на всей обучающей выборке. Рисунок 8 подтверждает это (средняя точность теста при проверке всего набора тестов составляет от 86,5 % до 87,0 % по сравнению с 97 % при обучении на полном обучающем наборе).

Рисунок 8 также показывает, что разница в точности теста при оценке только 500 тестовых примеров значительно выше по сравнению с оценкой на полном наборе тестов.

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

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

Как проверить модель регрессии

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

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

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

Заключение

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

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

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

Я надеюсь, что вы нашли это полезным.