Първоначално публикувано в spark-in.me на 15 юли 2018 г.

Изглежда много добре, а? Това е оценка от край до край. Два големи случая на повреда — непоследователна производителност с по-малки обекти в близост до по-големи къщи + някои фалшиви фалшиви положителни резултати понякога)

TLDR

През 2018 г. ML състезанията са засегнати от:

  • Решения от типа „Да подредим 250 модела“;
  • Много неприятни / небалансирани / произволни набори от данни, които по същество превръщат всяка потенциално интересна / прилична конкуренция в казино;
  • Липса на любознателен манталитет - просто подредете всичко - хората наистина не се опитват да разберат коя техника наистина работи и каква печалба осигурява;
  • Твърде много BS и маркетинг;

Когато разглеждах „предизвикателство“ за картографиране на Crowd AI, опитах няколко „нови“ техники, които работеха много добре в Semseg и могат да бъдат частично приложени към други домейни:

  • Разглеждане на вътрешната структура на данните / разбиране на ключовите случаи на неизправност =› използването им чрез претегляне на загубата (малко самоконтролиран моден);
  • Полиране на вашата фина настройка на Semseg CNN — а именно трениране на последните епохи на вашия CNN с по-високо тегло на загуба на DICE;

На този етап няма да пускам никакъв код, тъй като състезанието все още не е приключило, но с удоволствие ще споделя своите прозрения, за да улесня дискусията.

Защо Crowd-ai mapping challenge?

Вярвам, че това е наистина добра тестова площадка за тестване на нови идеи, свързани със CNN, поради редица причини:

  • Наборът от данни е наистина добре балансиран;
  • Домакините бяха достатъчно любезни да осигурят много стартов комплект „шаблон“ за изпълнение на най-досадните задачи;
  • Има „звездно отворено решение“ на задачата;

Стандартни техники

Вярвам, че следните техники, свързани със Semseg CNN, са стандартни през 2018 г., но все пак ще ги изброя за пълнота:

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

(Колкото и да е странно, те рядко пишат за това във вестниците).

Отворено решение

От гледна точка на машинното обучение е „страхотно“. Не наистина. Писането им е невероятно.

Илюстрации на теглото в отворения разтвор. Имайте предвид, че те не показват крайните тегла. Ако го направиха — необходимостта от изчисляване на n² разстояния ще бъде по-малко очевидна.

Това са съответните ми килограми

Ето как CNN вижда теглата след параметризиране / притискане - няма реална разлика в това как да се изчислят разстоянията

Но имам редица сериозни проблеми с него и съм изразил притесненията си в чата на gitter тук, но също така ще ги повторя тук:

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

Какво проработи? Коя вътрешна структура изследвах?

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

Понастоящем не внедрих втория етап от конвейера, тъй като вторият етап е отложен и последния път, когато проверих, изпращанията бяха замразени.

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

(*) Домакините на Challenge предоставят инструмент за местна оценка. Базиран е на jsons, които трябва да бъдат запълнени с многоъгълници + някакъв показател за доверие. Авторите на отвореното решение твърдят, че това тегло има наистина голямо влияние върху резултата. Все още не съм тествал това, но вярвам, че може лесно да добави 2–3 процентни точки към резултата (т.е. да намали фалшивите положителни резултати + да направи резултата .9 =› .92-.93 например);

(**) Току-що приех базиран на хистограма F1 резултат от DS Bowl. Предполагам, че работи най-добре, когато имате много обекти. Направихме наивно внедряване на правилен F1 резултат заедно с визуализация — това е бавно, но показва много по-висок резултат;

(***) Моите най-добри изпълнения с (i) претегляне на маската, базирано на размера (ii) претегляне на маската, базирано на разстоянието (iii) полиране с тегло на компонента за загуба на 10x DICE;

(+) Това е твърд резултат от DICE при праг 0,5. По същество % от познатите пиксели. Някъде не помня най-добрия резултат точно;

Някои криви на обучение. (3) — един от най-добрите писти. (2) — ефект от ненавременен разпад на LR

Най-доброто ми бягане досега — започвайки с lr 1e-4 + по-високи тежести на базата на размера — тренира се по-бързо, постига малко по-добър резултат

И тук е същността на моето търсене на архитектура.

(0) Архитектура на енкодер Най-добрият модел — най-дебелият ResNet152 Направих някои тестове за аблация и: — ResNet101 беше малко по-лош — ResNext беше близък, но по-тежък — Моделите от семейството на VGG са пренастроени силно — Моделите от семейството Inception бяха добри, но по-лоши от ResNet

(1) Архитектура на модела Моделите, базирани на LinkNet и UNet, бяха близки до дебелите ResNet енкодери, но UNet е 3–4 пъти по-бавен Само за lulz, може би си струва да напуснете UNet за няколко дни? =) Но това граничи със запомнянето на набора от данни... Имайте предвид, че в идеалния случай (0) и (1) трябва да бъдат тествани и с целия тръбопровод, което все още не съм направил (моят приятел ще направи втората част от тръбопровода).

(2) авг

Играх с различни нива на augs, малките augs бяха най-добрите, моделът не прекалява (поради това е много интересно да се видят данните от втория етап — може би данните ще са различни =› цялото ноу-хау за обучение ще стане безполезно, тъй като винаги се случва със състезанията на Kaggle ..)

(3) Режим на обучение

Замразете енкодера, настройте декодера с lr 1e-3 и adam за 0,1 от набора от данни (на случаен принцип от c)

Размразете, тренирайте с lr 1e-4 и adam за 1.0 от набора от данни (на случаен принцип от c)

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

(4) Тегло на загубата

Визуално не видях разлика в използването само на една трансформация на разстояние спрямо изчисляването на разстояния между всеки обект =› те така или иначе са смачкани

Претеглянето на UNet работи най-добре с — w0 5.0 — сигма 10.0 , което означава, че теглата са разпределени [1;5] Претеглянето на размера работи и дава +3–5% F1 резултат

Претеглянето на разстоянието не подобри резултата, но заедно с претеглянето на размера имаше леко подобрение

Неща, които реших да не опитвам

Неща, които реших да не опитвам — морфологични операции, ерозия, граници и т.н

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

Неща, които все още трябва да опитате (актуализирано)

  1. Изградете двуетапен тръбопровод от край до край с полигони + метаданни и LightGBM;
  2. Опитайте следните трикове:
  • AdamW;
  • CLR + SGD / Adam (не помогна наистина);
  • Групиране на базата на тегло (не помогна наистина);
  • TTA;
  • Постепенно размразяване на енкодера (само заради него), замразяване на партидна норма (мрежите със и без замразяване се сближиха еднакво);

3. Няколко теста за аблация:

  • Може би по-лек UNet;
  • Може би A/B тестване на други подходи за претегляне (опитахизползване на 2 тегла — до най-близката къща и до второто затваряне — не направи хело);

Ако се интересувате от тази тема — моля, не се колебайте да коментирате — ние ще пуснем нашия код с по-строги тестове/препратки/обяснения!

Първоначално публикувано в spark-in.me на 15 юли 2018 г.