Привлечь тысячи дата-сайентистов для решения производственной задачи. Наш опыт организации соревнования на Kaggle

Участники обучали нейронные сети поиску дефектов на металле.

В производстве листового металла существует одна проблема — иногда на поверхности металла могут образовываться дефекты. Дефекты бывают разных типов в зависимости от причины их возникновения.

Например, механические повреждения — царапины, задиры или потёртости — возникают в основном вследствие износа металлопрокатного оборудования. Другие дефекты, такие как трещины или плёны, появляются, когда происходят отклонения от технологии при выплавке стали.

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

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

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

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

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

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

Основных причин этому три:

• Дефицит данных. Если датасетов с кошками или собаками в свободном доступе предостаточно, то открытый датасет с дефектами поверхности металла до недавнего времени существовал только один. Этот датасет опубликовал Северо-восточный Университет США в Бостоне. Он включает всего 1800 изображений размером 200х200 пикселей для шести классов дефектов.

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

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

«Северсталь» совершенствует свои технологические процессы и системы контроля качества. Когда мы решили использовать современные достижения в области компьютерного зрения и улучшить существующую систему детекции дефектов, встал вопрос подготовки обучающего датасета. Качественная обучающая выборка — это, наверное, 50% успеха всего проекта, поэтому мы подошли к этому вопросу с большим вниманием.

На начальном этапе мы отобрали около пяти тысяч изображений поверхности металла. Планировалось, что аннотаторы разметят на этих изображениях семь наиболее критичных типов дефектов. Этим занялась команда из девяти специалистов по дефектам металлопроката.

Уже после первой тренировочной разметки стало понятно, что размечать дефекты — совсем не то же самое, что размечать котиков. Мы столкнулись с несколькими проблемами, которые можно проиллюстрировать следующими изображениями:

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

Что же делать в таком случае? Нам нужно было в относительно короткие сроки (два-три месяца) при сильно ограниченных человеческих ресурсах разметить большой датасет. При этом хотелось, чтобы разметка была максимально качественной, и мы были если не на 100%, то хотя бы на 80% уверены в представленных типах дефектов.

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

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

Во-вторых, мы использовали стандартную практику, когда несколько человек независимо размечают одно и то же изображение. Пожалуй, самый качественный результат мы могли бы получить, если бы каждую картинку размечали все члены команды. Затем можно было бы агрегировать отдельные разметки, уточнив типы и расположение дефектов.

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

Поэтому в итоге мы использовали следующий подход. Каждую картинку независимо размечали два аннотатора. Если оказывалось, что в получившихся разметках не совпадают типы дефектов или величина IoU (Intersection over Union) между отдельными инстансами дефектов ниже порогового значения, то такая картинка отправлялась на дополнительную разметку самому опытному из экспертов. После чего на основе трёх полученных разметок мы генерировали финальный, более точный вариант разметки.

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

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

А вот так могут выглядеть изображения с дефектами:

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

Лучший способ убедиться, что собранные данные позволяют решить вашу задачу, — обучить на них свою модель.

Примерно в середине работы по разметке data science-команда «Северстали» подготовила proof of concept на тех картинках, что уже были размечены. Мы обучили собственную baseline-модель детекции дефектов на основе AlbuNet-34. Двухмесячные пилотные испытания прототипа показали существенное улучшение по точности и полноте детектируемых дефектов по сравнению с исходной системой детекции.

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

Итак, модель работает. Работает лучше, чем существующая система инспекции. Но можно ли её улучшить? Если да, то насколько?

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

Если вы хотите понять, что вообще можно выжать из тех данных, которые у вас есть, то место лучше, чем Kaggle, сложно придумать. Над вашей задачей будут думать тысячи профессионалов. Соревнования на Kaggle устраивали такие компании и организации, как Microsoft, Facebook, CERN и другие. Российских компаний, проводивших свои соревнования по data science, совсем немного. На ум приходят «Авито», «Сбербанк» и «Яндекс». Мы подумали, что будет здорово, если «Северсталь» войдёт в их число.

Короче говоря, вопрос, где проводить соревнование, был решен быстро. Оставался ещё один: как его проводить?

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

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

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

Мы выбрали компромиссный вариант формата, поскольку уже имели неплохой baseline и хотели, чтобы соревнование позволило нам получить модель максимально достижимого качества.

С одной стороны, участники не были ограничены в ресурсах и могли обучать свои модели на чём угодно, что потенциально стимулировало использовать «тяжёлые» модели, ансамбли и SOTA-решения (state of the art). С другой, мы всё же требовали, чтобы инференс выполнялся на ресурсах Kaggle. Это позволило скрыть от участников тестовую выборку, немного регулировать итоговую сложность моделей и гарантировало воспроизводимость результатов.

В принципе, с этим форматом соревнования всё хорошо, кроме одного момента. Да, вероятно, мы получим качественное решение, которое великолепно находит дефекты на металле. Но что если этим решением окажется ансамбль из десяти Mask-RCNN (одна из современных архитектур искусственных нейросетей) и кучей TTA (test time augmentations) , который на доступных нам вычислительных мощностях способен обрабатывать одну картинку в секунду?

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

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

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

Мы также решили, что во втором раунде участники будут вольны делать со своими моделями что угодно, даже выставить полностью новую модель, отличную от той, которую они использовали в первом раунде. Но при одном условии — результат модели на тестовой выборке во втором раунде не должен опуститься ниже топ-50. Для оценки производительности моделей во втором раунде мы выбрали средненький для такой задачи компьютер с Core i7, одной GPU 1080Ti и 64 гигабайтами оперативной памяти.

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

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

Data leakage или просто leak (утечка) — одна из главных опасностей при проведении соревнований по data science. Участники всегда скрупулёзно изучают данные на предмет неочевидных закономерностей и подсказок, которые организатор не заметил на этапе подготовки датасета.

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

Так что при подготовке train- и test-сета нам нужно было, с одной стороны, сделать так, чтобы в обеих выборках было одинаковое распределение по дефектам и видам поверхностей металла, а с другой, избежать leak’а. Сделать это было не так-то просто.

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

Приняв всё это во внимание, мы совместно с командой Kaggle внимательно подошли к разбиению данных:

С выбором метрики тоже были свои нюансы. На производстве качество системы детекции дефектов оценивают в терминах «перебраковки» и «недобраковки». По смыслу две эти величины связаны с привычными precision и recall как:

Поэтому изначально для оценки качества решений мы собирались использовать кастомную метрику, комбинирующую precision и recall по всем типам дефектов. Но от этой идеи пришлось отказаться. Создание новой метрики и интеграция её в существующую инфраструктуру потребовали бы от команды Kaggle больших усилий на разработку и тестирование. Кроме того, было сложно предугадать, как может повести себя новая метрика во время соревнования.

Команда Kaggle предложила использовать одну из их стандартных метрик для картиночных соревнований ­— mAP при разных порогах по IoU. Но тут мы столкнулись с забавным багом. Хорошо, что в нашем распоряжении была baseline-модель и мы могли протестировать метрику на прочность.

Данная метрика была написана таким образом, что учитывала фон изображений как отдельный класс. Если в качестве входных данных в функцию расчёта метрики подать наивный прогноз ­— на картинках вообще нет дефектов, — метрика выдавала значение 0,7. Если подать идеальный прогно ­— правильно сегментировать все дефекты на изображениях, — значение метрики становилось равным 1.

На первый взгляд, всё нормально. Но при тестировании метрики на предиктах нашей baseline-модели, которая неплохо сегментирует дефекты, оказалось, что значение метрики равно 0,67. Получается, выгоднее не предсказывать ничего, чем пытаться обнаруживать дефекты.

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

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

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

Само соревнование длилось три с половиной месяца: с 26 июля по 13 ноября 2019 года. Участие приняла 2431 команда, что, на наш взгляд, довольно много и говорит о том, что конкурс оказался интересным для сообщества.

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

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

Избежать сильной головной боли при тестировании решений во втором раунде нам помог Docker — участникам предлагалось завернуть свои модели в контейнер. Мы подготовили подробную инструкцию с примером по упаковке модели в контейнер, так что всё, что оставалось сделать командам, — это заменить файлы в примере на собственные. Это минимизировало вероятность того, что присланные командами решения не запустятся или упадут с ошибкой из-за разницы в используемом программном обеспечении.

Подводя итоги, можно сказать, что мы остались очень довольны результатами. Организация и сопровождение соревнования со стороны команды Kaggle была на высоком уровне. Нам удалось избежать типичных для картиночных соревнований проблем, таких как data leakage, и достичь тех двух целей, которые ставили изначально:

• Оценили, модель какого качества в принципе можно получить на наших данных.

• Решение победителя второго раунда смогли с минимальными доработками интегрировать в производство на заводе в Череповце.