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

Приложение для распознавания объектов на спутниковых снимках

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

Каковы характеристики алгоритма?

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

Помимо изучения того, что алгоритм должен обнаружить, чрезвычайно важно также узнать, что он не должен обнаруживать. Если вы хотите обнаружить красные Феррари, вам нужно будет дать вашему алгоритму много красных объектов, которые не являются Феррари, или ваш алгоритм поместит метку Феррари на каждый красный объект, который он обнаруживает, включая помидоры или британские телефонные будки. Чтобы проверить производительность вашего алгоритма, вы затем захотите дать ему много красных спортивных автомобилей, чтобы убедиться, что он достаточно надежен. Однако, поступая так, вы можете исказить результаты своих тестов. В самом деле, слишком много «жестких примеров» приведет к нереалистично плохим оценкам. Таким образом, получение правильных тестовых данных является большой проблемой: если ваша тестовая база состоит из множества «простых» примеров, вы получите завышенную производительность, но если ваша тестовая база данных слишком сложна, вы исчерпаете свои ресурсы, пытаясь добиться невозможной производительности в производство. Практически невозможно иметь рабочий рецепт при построении протокола тестирования, но можно дать рекомендации относительно того, что НЕ делать.

Плохая идея №1: не думайте о своих показателях

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

Прекрасной иллюстрацией к этой теме является обнаружение автомобилей на спутниковых снимках. Представьте, что вы хотите определять занятость на парковке: вы можете использовать объектно-ориентированную локализацию и обнаружение, чтобы расставить коробки вокруг автомобилей. Таким образом, метрика будет довольно простой: IoU (пересечение над объединением). Один ящик будет считать один объект, и таким образом вы сможете определить свое место на парковке.

Однако алгоритмы обнаружения объектов могут с трудом обнаруживать транспортные средства на спутниковых снимках с разрешением выше 50 см. Это связано с тем, что эти алгоритмы, одноэтапные или двухэтапные, используют концепцию регионов и классифицируют эти области. Но автомобиль на 50-сантиметровом изображении в основном представляет собой размытый яйцевидный объект размером 10x6 пикселей… слишком мал, чтобы его можно было рассматривать как «область» большинством основанных на регионах алгоритмов.

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

Таким образом, у вас будет вся площадь парковки, занятая машинами. Но, таким образом, разделение объектов будет намного сложнее. Так как бы вы посчитали свой балл? Это действительно становится сложно ...!
Можно найти решение, глядя на площадь, занимаемую сегментацией: в итоге парковочное место составляет всего м². Но если бы вы использовали ту же технологию для фактического «подсчета» автомобилей для оценки производства автомобилестроителем, это было бы совершенно иначе, и вам нужно было бы использовать другую метрику.

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

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

Плохая идея # 2: тестирование на обучающем наборе данных

Да, «никто не настолько глуп, чтобы сделать это». Действительно, в машинном обучении очень важно использовать разные данные при обучении и проверке / тестировании. Но почему на самом деле это плохая идея? Ответ на самом деле более сложный, чем кажется.

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

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

Плохая идея # 3: разделить одно и то же изображение между тренировкой и тестом

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

К сожалению, мы по-прежнему видим это много для приложений дистанционного зондирования, в основном из-за нехватки и размера данных. Спутниковые изображения могут иметь размер до 1 миллиарда пикселей, на них могут быть размещены десятки тысяч экземпляров одного и того же объекта. Первый POC обычно использует очень ограниченное количество изображений, часто одно или два. Следовательно, тестирование часто выполняется на частях одного и того же изображения, которое используется в обучении, таким образом, без учета погодных условий, качества изображения или изменений ландшафта, что создает огромное положительное смещение. Это также объясняет, почему вы можете видеть огромное несоответствие в производительности между некоторыми исследовательскими работами / характеристиками POC и реальными «реальными» приложениями. Когда вы учитесь и тестируете на одном изображении, довольно легко получить оценку F1 выше 90 или 95%, но всегда приходит огромное разочарование, когда вы тестируете одну и ту же сеть в другом месте / в другой день.

Плохая идея №4: использовать одну и ту же географическую сцену для обучения и тестирования

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

Большинство спутников наблюдения за Землей находятся на солнечно-синхронной орбите, они всегда отображают одну и ту же область в один и тот же солнечный час, а это означает, что каждое изображение, которое вы получаете из Парижа со спутника World View 3, будет в один и тот же час поздним утром (за вычетом - возможности визуализации надира, но здесь я стараюсь не усложнять…). Таким образом, вы получите одинаковые условия освещения, тени и не получите всю суточную изменчивость погоды или деятельности человека. В зависимости от места вы также можете столкнуться с очень разными атмосферными явлениями: дымкой, влажностью или аэрозолем: все это влияет на качество изображений и, следовательно, на способность алгоритма обнаруживать объекты на спутниковых изображениях. Мы обнаружили огромные различия в качестве изображения и, следовательно, в производительности алгоритма (до 30%!) Между сайтами, снятыми в один и тот же местный час при одинаковом разрешении из-за этого фактора, поэтому необходимо оценивать производительность сайтов как во время обучения, так и вне его. в обучении, чтобы увидеть, являются ли выступления последовательными и однородными.

Последняя плохая идея: использовать один и тот же датчик в тренировке и тестировании

Это также зависит от вашего варианта использования, но, как правило, вы захотите воспользоваться преимуществами каждого доступного датчика, чтобы получить больше частот изображения. Даже при одинаковом разрешении сенсоры обладают разными физическими качествами, которые могут изменять аспекты изображения, спектральные характеристики или цветовой баланс. Мы даже видели различия в производительности алгоритмов между двумя родственными спутниками Pleiade 1A и Pleiade 1B: при обучении только на P1A наш алгоритм обнаружения объектов имел гораздо более низкую производительность на P1B. Следовательно, теперь мы тестируем характеристики всего каталога датчиков, который у нас есть, от QuickBird 2 до Worldview 4, панхрометрических и мультиспектральных. Это также важно для того, чтобы понимать, где специализироваться. Например, мы поняли, что вы можете использовать один и тот же алгоритм для обнаружения лодок с разрешением от 30 см до 1 м, но вам потребуются 3 алгоритма обнаружения транспортных средств при использовании того же диапазона разрешения. Это может показать только сбалансированная испытательная база.

В конце концов, что такое хорошие выступления?

Для маркетинговых или демонстрационных приложений всегда легко показать точность / отзывчивость 90–95, а иногда даже 97%. Даже с ограниченным количеством обучающих и тестовых примеров легко (добровольно или нет) перенастроить ваше приложение дистанционного зондирования, чтобы оно было очень хорошим на одном конкретном изображении, месте и времени. Однако проблемы возникают при масштабировании, и это всегда связано с действиями человека. Вот почему могут потребоваться месяцы или годы исследований, чтобы получить более 90% F1 для обнаружения объектов на спутниковых снимках. А иногда эти оценки даже недостижимы.

1 октября в Earthcube мы достигли важной вехи: мы официально пометили более 1 миллиона транспортных средств только для обучения алгоритмов глубокого обучения на спутниковых изображениях. Поэтому мы решили провести тест на качество правды на местах с несколькими фотоаналитиками, прошедшими военную подготовку. Результаты не стали неожиданностью, если вы оглянетесь назад на то, как автомобиль выглядит на спутниковом снимке: при маркировке тех же полноразмерных изображений мы увидели, что вариабельность возрастает от 10% на «идеальных» 30-сантиметровых мультиспектральных чистых изображениях до более чем 25% для более сложных изображений (только панорама, большой угол вне надира…). Конечно, это снижает качество набора данных и, следовательно, скорость обнаружения. Если это сложно для человека, это также сложно для алгоритма, и, в конце концов, ИИ не может быть лучше, чем набор данных, на котором он был обучен.

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

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

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