Первоначально опубликовано на сайте spark-in.me 15 июля 2018 г.

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

TLDR

В 2018 году соревнования по ML страдают от:

  • решения типа «Стакаем 250 моделей»;
  • Очень неприятные/несбалансированные/случайные наборы данных, которые по сути превращают любое потенциально интересное/приличное соревнование в казино;
  • Отсутствие пытливого менталитета — просто складывать все подряд — люди особо не пытаются понять, какая техника действительно работает и какой выигрыш она дает;
  • Слишком много чуши и маркетинга;

Рассматривая задачу картографирования Crowd AI, я попробовал несколько новых методов, которые очень хорошо работали в Semseg и могут быть частично применены к другим областям:

  • Изучение внутренней структуры данных/понимание ключевых случаев сбоев => использование их с помощью взвешивания потерь (немного самоконтроля);
  • Полировка тонкой настройки Semseg CNN, а именно обучение последних эпох вашей CNN с более высоким коэффициентом потери DICE;

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

Почему Crowd-ai Mapping Challenge?

Я считаю, что это действительно хорошая тестовая площадка для тестирования новых идей, связанных с CNN, по ряду причин:

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

Стандартные методы

Я считаю, что следующие методы, связанные с Semseg CNN, являются стандартными в 2018 году, но я все равно перечислю их для полноты картины:

  • Использование CNN в стиле UNet/LinkNet;
  • Использование предварительно обученных кодировщиков в Imagenet;
  • Пробуем различные комбинации архитектур кодер-декодер;
  • Пробовать аугментации совершенно разной «тяжести» (вы должны настроить мощность вашей модели + аугментации для каждого набора данных);

(Как ни странно, об этом редко пишут в газетах).

Открытое решение

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

Масса иллюстраций в открытом решении. Обратите внимание, что они не показывают окончательные веса. Если бы они это сделали, необходимость расчета расстояний n² была бы менее очевидной.

Это мои соответствующие веса

Вот как CNN видит веса после параметризации/сжатия — никакой реальной разницы в том, как рассчитать расстояния

Но у меня есть ряд серьезных косяков, и я высказал свои опасения в чате здесь, но я также повторю их здесь:

  • Это решение является вопиющим маркетингом решения для машинного обучения с минимальной стоимостью 100 долларов в месяц, которое, как я полагаю, должно решать проблемы масштабирования/экспериментирования, но я не понимаю, почему Tensorboard + простые журналы + скрипты bash не могут решить это бесплатно без объем кода + введение дополнительных зависимостей. Конечно, использование этой платформы не является обязательным, но почему бы и нет?
  • Кода в репо навалом — он содержит 3–4 уровня абстракций — декораторы на декораторах. Это действительно нормально, если вы инвестировали в команду хотя бы из нескольких человек, которые соревнуются в интересных соревнованиях как свою работу, но когда вы публикуете свой код для публики — это немного похоже на те запутанные репозитории с кодом TF. Их код действительно хорош, но вам нужно копаться во всех дополнительных слоях, чтобы добраться до «мяса»;
  • Рекламируемые возможности отслеживания экспериментов neptune.ml. Да, он отслеживает все гиперпараметры. Но если пройти по ссылке на их открытую таблицу с экспериментами, то толком многого оттуда не понять =› тогда в чем преимущество отслеживания? Да, запустить вашу модель на Amazon с помощью двух строк кода — это здорово, но и очень дорого. Может лучше просто собрать девбокс? Похоже, они написали звездную рецензию, но использовали это отслеживание только для «иллюстрации», а не как реальный инструмент, который имеет решающее значение;
  • Идея о взвешивании расстояний действительно хороша, но они реализовали ее построчно, как написано в документе UNet, путем вычисления n² расстояний, что, на мой взгляд, слишком сложно. Просто визуально после «сжатия» даже одно преобразование расстояния дает одинаковые веса маски;
  • С этой точки зрения меня больше всего беспокоит то, что новые практики ОД увидят это и, возможно, смогут сделать следующие выводы, ОЧЕНЬ ВРЕДНЫЕ ДЛЯ СООБЩЕСТВА ОД С ОБРАЗОВАТЕЛЬНОЙ ТОЧКИ:
  • Вам нужны некоторые платные проприетарные инструменты для отслеживания экспериментов. Нет, ты не. Это начинает иметь смысл, когда у вас есть команда, по крайней мере, из 5 человек, и у вас есть МНОГО различных конвейеров;
  • Вам нужно инвестировать в очень абстрактный код. Нет, ты не. Достаточно CLI-скриптов + чистый код + bash-скрипты;
  • Реализовать документ UNet слово за словом можно, но, вероятно, вычисление расстояний n² бесполезно;

Что сработало? Какую внутреннюю структуру я исследовал?

Текущее состояние / мой простой анализ абляции

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

Но вот очень краткая таблица с моими основными тестами (я провел ~100 разных тестов, обучив примерно 20–30 моделей до сходимости).

(*) Организаторы конкурса предоставляют инструмент для местной оценки. Он основан на jsons, которые должны быть заполнены полигонами + некоторая метрика достоверности. Авторы открытого решения утверждают, что это взвешивание действительно сильно влияет на оценку. Я еще не проверял это, но я считаю, что это может легко добавить 2–3 процентных пункта к оценке (например, уменьшить количество ложных срабатываний + сделать оценку 0,9 => 0,92-0,93);

(**) Я только что взял гистограмму F1 из DS Bowl. Я думаю, это работает лучше всего, когда у вас много объектов. Мы сделали наивную реализацию правильной оценки F1 вместе с визуализацией — она медленная, но показывает гораздо более высокую оценку;

(***) Мои лучшие прогоны с (i) взвешиванием маски на основе размера (ii) взвешиванием маски на основе расстояния (iii) полировкой с 10-кратным весом компонента потерь DICE;

(+) Это жесткая оценка DICE при пороговом значении 0,5. По сути, % угаданных пикселей. Где-то не помню точно лучший результат;

Некоторые кривые обучения. (3) — один из лучших спусков. (2) — эффект преждевременного распада LR

Мой лучший бег на данный момент — начиная с 1r 1e-4 + более высокие веса в зависимости от размера — тренируется быстрее, достигает немного лучших результатов.

И вот суть моих архитектурных поисков.

(0)Архитектура кодировщикаЛучшая модель — самый толстый ResNet152 Я провел несколько тестов на абляцию и: — ResNet101 оказался немного хуже — ResNext был близок, но тяжелее — Модели семейства VGG сильно переоснащены — Модели семейства Inception были хороши, но хуже, чем ResNet

(1)Архитектура моделиМодели на базе LinkNet и UNet были близки с толстыми ResNet энкодерами, но UNet в 3-4 раза медленнее Просто для лулзов, может стоит оставить UNet на пару дней? =) Но это граничит с запоминанием набора данных… Обратите внимание, что в идеале (0) и (1) также должны быть протестированы со всем конвейером, чего я еще не делал (вторую часть конвейера сделает мой друг).

(2) августа

Игрался с разными уровнями ауг, лучше всего были маленькие ауг, модель не переобучается (поэтому очень интересно посмотреть данные второго этапа — возможно данные будут другими => все ноу-хау обучения станут бесполезными, т.к. всегда бывает с соревнованиями на Kaggle..)

(3) Тренировочный режим

Заморозить кодировщик, настроить декодер с помощью lr 1e-3 и adam для 0,1 набора данных (случайным образом)

Разморозить, тренировать с lr 1e-4 и adam для 1.0 набора данных (случайно)

Тренируйтесь с lr 1e-5 для 1.0 набора данных. Увеличьте потери DICE в 10 раз и тренируйтесь столько, сколько хотите — это может быть очень хрупким (!), если набор отложенных тестов отличается

(4) Взвешивание потерь

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

Взвешивание UNet лучше всего работало с — w0 5.0 — sigma 10.0 , что означает, что веса распределены [1;5] Взвешивание по размеру сработало и дало +3–5% F1.

Взвешивание по расстоянию не улучшило результат, но вместе с взвешиванием по размеру было небольшое улучшение

Вещи, которые я решил не пробовать

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

  • Морфологические операции — здесь они излишни;
  • Подходы, вдохновленные Deep Watershed;
  • Модели на основе предложений — было показано, что они являются хорошим началом для DS Bowl, но их гораздо сложнее настроить позже;
  • Рекуррентные модели — слишком сложные, слишком большие объекты;

Что еще нужно попробовать (обновлено)

  1. Построить двухэтапный сквозной пайплайн с полигонами + метаданными и LightGBM;
  2. Попробуйте следующие приемы:
  • Адам В.;
  • CLR + SGD/Adam (не особо помогло);
  • Сборка по весу (на самом деле не помогла);
  • ТТА;
  • Постепенная разморозка энкодера (просто так), пакетно-нормовая заморозка (сети с заморозкой и без нее сходились одинаково);

3. Пара тестов на абляцию:

  • Возможно, более легкий UNet;
  • Возможно, A/B-тестирование других подходов к взвешиванию (пробовалиспользовать 2 веса — для ближайшего дома и для второго закрытия — не получилось);

Если вам интересна эта тема — не стесняйтесь комментировать — мы выпустим наш код с более тщательными тестами / ссылками / объяснениями!

Первоначально опубликовано на сайте spark-in.me 15 июля 2018 г.