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

Опубликовано: 12/01/2021 Время на прочтение: 5 минут

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

Итак, возможно, модель работает только с геометрическими объектами. Давайте внесем небольшую коррекцию в исходное изображение, которое мы использовали, и увеличим яркость его фона. Как пользователь, мы могли бы разумно ожидать, что модель будет достаточно устойчива к таким простым преобразованиям — конечно, наша человеческая способность декомпозировать объекты такова. Однако эта модель далеко не надежна:

Я должен быть здесь ясен — я не думаю, что модель виновата, как и авторы. Модель очень хорошо работает над задачей, на которой она была обучена и протестирована: декомпозиция объектов в исходном наборе данных CLEVR. Однако, как пользователь предварительно обученной модели, я априори не знаю, будет ли модель обрабатывать другие виды изображений. Нет никакого контракта, который говорил бы мне, что модель должна использоваться только с исходными изображениями из набора данных CLEVR.

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

3. когда входные данные должны удовлетворять другим трудноопределимым ограничениям

Статья: разворачивание чередующейся оптимизации для слепого суперразрешения
Ссылка на GitHub: https://github.com/greatlog/DAN
Демо-ссылка: https://gradio.app/g/dan

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

Однако давайте попробуем ту же модель с другим изображением:

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

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

Вывод-есть ли решение?

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

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

В то же время мы видели, что определить допустимые входные данные с помощью явных инструкций довольно сложно. Что можно сделать? У меня есть два предложения:

1. Мы разрабатываем лучшие методы для определения того, принадлежит ли выборка к «правильному распределению данных» нашей модели.” Возможно, контракты сами по себе могут быть “контрактными функциями”, которые оценивают, является ли входная выборка допустимой, если она достаточно “похожа” на наше распределение обучения. Такие методы обнаружения входящих и исходящих данных разрабатываются в настоящее время [4], хотя есть предостережения относительно их использования на практике [5].
2. Мы облегчаем тестирование моделей, чтобы отказы моделей легко выявлялись на ранних этапах процесса разработки модели. Это помогает создателям моделей знать и сообщать предварительные условия своей библиотеки, а конечным пользователям быстро узнать, подходит ли модель для их использования. Это мотивация нашей библиотеки gradio с открытым исходным кодом. На самом деле, точки отказа, выявленные в приведенных выше моделях, были легко выполнены с помощью библиотеки.

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

Рекомендации

[1] предварительно подготовленные модели-трансформаторы 4.1.1 документация (huggingface.co)

[2] концепция Ма | выводим Изображение через выводы мл | облачных API зрение (google.com)

[3] https://www.gradio.app/hub/abidlabs/Noise2Same

[4] обнаружение вне распространения / документы с кодом

[5] [1810.09136] знают ли глубокие генеративные модели то, чего они не знают? (arxiv.org)

Люблинова Анастасия

Выпускник факультета кибернетики МсГУТ. Фанат гаджетов и гуру техники, современный хайтек-философ.