Як треба писати CV/ML статтю: розгляд на конкретних прикладах
Тепер давайте розберемо на конкретних прикладах, що подобається рев’юверам, а що ні (попередній пост про загальні приншипи ось тут)
1)Мій перший пейпер, Two-view matching with view synthesis revisited, IVCNZ 2013.
Трохи бекграунда. Є метод для знаходження відповідностей між двома картинками, який базується на детектуванні особливих точок. Навколо цих точок беруться патчі і вони вже порівнюються.
Звичайно, із зміною позиції камери, це метод працюює гірше і гірше. Класичний підхід — спробувати оцінити, під яким кутом краще дивитись и вже брати не квадратний патч, а деформований.
Потім прийшли автори ASIFT і сказали — замість цього, ми зробимо дуже велику тест-тайм аугментацію — нагенеримо штучних картиков під різними кутами і будемо порівнювати всі зо всіма, замість оцінювати.
Працює класно, але дууууже повільно.
Наші контріб’юшни:
1) Давайте робити синтез для більш просунутих детекторів, які і самі оцінюють кут. Тоді можна синтезувати набагато менше.
2) Більше того, давайте синтезувати лише тоді, коли базові картинки не можемо порівняти просто так. Так набагато швидше в простих випадках.
3) Замість порівнювати всі зі всіма, зробимо більш розумно і ефективно.
4) Ось новий датасет, щоб показати, що ми круті.
Кількісні метрики: мій метод працює в середньому в 100 разів швидше и може працювати для більшої різниці в куті обзору (з 50 градусів до 75 в середньому). Тобто дуже і дуже велике покращення.
ICCV рев’ювери: це інженерна робота, а всі ідеї — очевидні і інкрементальні. Стаття непогана, але не рівня ICCV, недостатньо новизни. Оцінки: 5/10 у всіх.
Коментар: incremental improvement — це коли ви покращуєте якийсь метод в очевидний бік. Доволі важко об’єктивно. відрізнити “інкрементал” от “простого, але класного” покращення
Підсумок — ми вирішили, що проти аргумента “це інженерна робота” не зможемо нічого сказати і понизили рівень конференції — опублікували на IVCNZ (другорядна, суттєво гірша за ICCV)
2) WxBS: Wide multiple baseline stereo generalizations, BMVC 2015
Попередня задача типу вирішена, тому йдемо далі. Як щодо того, що одне фото вдень, а інше вночі? Або влітку і взимку? А якщо це все разом, бо раніше це розглядалося лише окремо.
Наші контріб’юшни:
1) Нова задача і датасет для неї.
2) Тест найкращих алгоритмів (в попередній категоріях) на цій задачі.
3) Пара простих трюків для детектора та дескріптора, щоб сильно покращити результати, але задача все одно занадто складна.
CVPR ревьювери: прикольно, але недостатньо.
Підсумок — додали тести купи детекторів та дескріпторів, опублікували на BMVC (посередині між топ та другорядними конференціями).
3) All you need is a good init, ICLR 2016
Трохи бекграунда. Ініціалізувати нейросітки як попало не можна, бо так вони погано тренуються.
Домінуючий підхід — проініціалізувати випадковими матрицями, дисперсія яких вирахувана по формулі для конкретного типу сітки та активації. Для іншій типів сіток (особливо глибоких) — треба виводити свою формулу.
Наші контріб’юшни:
1) Проініціалізувати випадковими ортогональними матрицями, після чого прогнати перший батч тренувальних даних та поділити ваги в шарі на девіацію. Повторити для кожного шару. Працює майже будь-де (важливо), покращує швидкість навчання (трохи) та фінальну точність(трохи).
ICLR рев’ювери: круто, а на імаджнеті перевірити?
Ми в ребаталі: ось, і на ньому працює.
Підсумок: accept.
4) Working hard to know your neighbor’s margins: Local descriptor learning loss, NIPS 2017
Дано: є кльовий метод вчити дескріптори патчів, але там складна функцій втрат (лосс) на базі softmin для батчу (L2Net paper, CVPR 2017)
Наш контріб’юшн:
- Замінити лосс на тріплет марджин, а замість всього батчу брати один найскладніший негатив в батчі. Всі інші прибабмаси викинути.
2) Вивчений дескріптор сам по собі стає дуже потужним і реально працює на купі датасетів
NIPS рев’ювери: а що головніше, тріплет марджин, чи найскладніший негатив? А якщо не по батчу, а по всьому датасету, як робили і до вас? І що у вас за незрозуміла Fig.1?
Ми: найскладніший негатив важливіше, ось додатковий експеримент. По всьому гірше, ось експеримент. Fig.1 замінимо.
Підсумок: accept.
Повні ревью доступні ось тут
****
Не мій пейпер, але цікавий приклад сатири на вимоги рецензентів —
YOLOv3: An Incremental Improvement. Вже сама назва пародійна, бо incremental improvement — один із найчастіших приводів для реджекта.
Контріб’юшн: набагато кращий object detection за допомогою “incremental improvements”. Тобто стаття серьозна, а форма подачи — стьоб.
На цьому поки що закінчу. Якщо є додаткові питання — питайте :)
