Первоначально опубликовано на сайте 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, но их гораздо сложнее настроить позже;
- Рекуррентные модели — слишком сложные, слишком большие объекты;
Что еще нужно попробовать (обновлено)
- Построить двухэтапный сквозной пайплайн с полигонами + метаданными и LightGBM;
- Попробуйте следующие приемы:
- Адам В.;
- CLR + SGD/Adam (не особо помогло);
- Сборка по весу (на самом деле не помогла);
- ТТА;
- Постепенная разморозка энкодера (просто так), пакетно-нормовая заморозка (сети с заморозкой и без нее сходились одинаково);
3. Пара тестов на абляцию:
- Возможно, более легкий UNet;
- Возможно, A/B-тестирование других подходов к взвешиванию (пробовалиспользовать 2 веса — для ближайшего дома и для второго закрытия — не получилось);
Если вам интересна эта тема — не стесняйтесь комментировать — мы выпустим наш код с более тщательными тестами / ссылками / объяснениями!
Первоначально опубликовано на сайте spark-in.me 15 июля 2018 г.