Промышленные записки

Почему мы не тестируем машинное обучение так, как тестируем программное обеспечение?

Давайте сделаем модели машинного обучения более надежными, черпая вдохновение в тестировании современного программного обеспечения! Новый способ уверенно улучшать свои модели.

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

В этом сообщении в блоге мы более подробно рассмотрим еще одну область, в которой возникают аналогичные проблемы, - разработка программного обеспечения - используемые там методологии тестирования и то, как их можно применить к тестированию машинного обучения. В конце концов, я надеюсь, что к концу этой статьи вы серьезно спросите себя: «Почему мы не тестируем машинное обучение так же тщательно, как тестируем программное обеспечение?». И посмотрите, как передовые методы тестирования программного обеспечения можно использовать для всестороннего тестирования моделей, выявления регрессий и быть частью вашего процесса обеспечения качества машинного обучения. Ниже вы можете увидеть схему конвейера непрерывного совершенствования, которую мы с моей командой создаем, которая показывает, как передовые методы контроля качества программного обеспечения могут быть использованы в пространстве MLOps.

Тестирование моделей машинного обучения

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

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

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

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

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

Контроль качества программного обеспечения и тестирование на основе свойств

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

Например, представим, что мы написали нашу собственную функцию деления «div (a, b)» для вычисления «a / b». Мы можем написать несколько тестов, гарантирующих, что «div (8, 2)» и «div (7, 6)» работают правильно, и быстро получить 100% покрытие кода. Однако мы торопились написать функцию и полностью забыли о угловом регистре деления на 0. Несмотря на это, мы все же достигли 100% покрытия кода! Что-то не так. Ключевая проблема в том, что покрытия кода недостаточно для решений, основанных на данных. И в настоящее время почти каждая часть программного обеспечения управляется данными!

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

Если мы хотим протестировать нашу функцию «div (a, b)» на основе свойств, мы должны указать, что

  1. «A», «b» и результат «c» являются действительными числами (область данных)
  2. ‘A = b * c’ должно быть истинным (свойство) +

Этой информации достаточно, чтобы компьютер мог искать угловые варианты, и вы можете быть уверены, что современные фреймворки тестирования на основе свойств, такие как Hypothesis или QuickCheck, почти сразу обнаружат угловой случай, когда ‘b = 0’. Когда это произойдет, мы должны либо исправить код, либо ограничить набор возможных входных данных. Важно отметить, что какое бы действие мы ни выбрали, мы преобразуем неявные предположения в явные.

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

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

Внедрение тестирования на основе свойств в машинное обучение

Прежде чем говорить о том, как, давайте поразмышляем над тем, почему. Зачем нужно тестировать свою модель машинного обучения на основе свойств? Текущие методы тестирования машинного обучения, основанные на фиксированных наборах данных и срезах данных, эквивалентны тестированию программного обеспечения на основе покрытия. Но, как мы видели ранее в нашем примере функции «div ()», покрытия кода недостаточно для систем, основанных на данных. Следовательно, необходимо перейти к более продвинутым стратегиям тестирования наших систем машинного обучения.

На первый взгляд, любые попытки внедрить тестирование на основе свойств в ML кажутся бесполезными из-за чрезвычайно большой размерности входных данных. Даже изображение из игрушечного набора данных MNIST живет в 576-мерном пространстве. Существует 2576 возможных изображений, поэтому случайное попадание в изображение, которое на самом деле представляет собой цифру, а также ломает ваши модели, просто невозможно с практической точки зрения. Но есть краткие способы описать изображение набора данных.

Операционная и информационная область

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

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

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

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

Поиск и случайная выборка

Размер рабочей области для автономного транспортного средства в сочетании с редкими событиями, следующими за распределением длинного хвоста, делают случайную выборку абсолютно непрактичной. Следовательно, второй шаг, необходимый для внедрения тестирования на основе свойств в ML, - это превратить проблему случайного генерирования случая отказа в проблему поиска. Отсюда возникла идея целевого тестирования на основе свойств, которая по совпадению также является новым методом контроля качества программного обеспечения. Чтобы сделать этот переключатель, важно указать свойства, которые не являются просто двоичными FALSE или TRUE, но следуют диапазону от 0 до 1. Этот шаг довольно интуитивно понятен для различных проблем машинного обучения, даже дискретных, таких как классификация, где мы можем легко измерить активации и их близость к границе решения.

Переход вверх и вниз по уровню абстракции

На приведенном выше рисунке показано различие между доменами рабочих и необработанных данных и то, как можно переходить от одного к другому, чтобы выполнить тестирование на основе свойств для системы машинного обучения. Важно отметить, что есть 2 пути от данной выборки необработанных данных x к новой x ’. Первый путь, проходящий через образец данных x - ›measure -› search - ›синтезировать -› альтернативный образец x ’, чрезвычайно эффективен. Это позволяет выполнять поиск в точно определенной рабочей области, не беспокоясь о том, что при оценке модели будут использованы недопустимые образцы данных. Однако эти возможности требуют нетривиальных шагов, таких как «измерение» различных аспектов выборки необработанных данных, чтобы перевести ее на язык операционной области, а также выполнение обратного шага синтеза новый образец необработанных данных из точки в рабочем домене.

С развитием симуляторов и глубокого генеративного моделирования синтез становится практически осуществимым для все большего и большего количества реальных проблем, но все еще остаются проблемы, где это еще не так. Здесь вступает в игру второй путь x - ›преобразование с учетом домена -› x ’. Это похоже на стандартные методы дополнения, но важным аспектом является признание того, что преобразования часто параметризуются на уровне операционной области. Например, добавление пиксельного шума - это преобразование на низком уровне данных, но добавление размытия движения к изображению, параметризованное относительной скоростью камеры к сцене, является преобразованием на уровне рабочей области. Следовательно, возможен поиск в рабочей области, даже если измерение и синтез невозможны.

Преимущества тестирования на основе собственности для машинного обучения

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

Точная оценка устойчивости

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

Новые образцы данных о невидимых отказах

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

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

Если вас интересует наша предстоящая запись в блоге о применении тестирования на основе свойств к проблемам машинного зрения машинного зрения, не забудьте подписаться!

об авторе

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

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

Если вы хотите связаться, просто напишите нам по адресу [email protected].