Як треба писати статтю на топ-конференцію в machine learning чи computer vision

Я почну з загальних принципів, а в наступному пості додам прикладів із власних статей.

1) Найголовніше.

Наукова стаття — це річ, яка розширює обсяг знань, який відомо людству, робить внесок.

Цей внесок англійською називається “contribution” і дуже часто на самому початку статті автори напряму кажуть, в чому саме полягає контріб’юшн статті. 
Як правило, стаття (вона ж пейпер) дає нову відповідь на якесь питання. 
Наприклад, “Як зробити швидкий детектор пішоходів”. Або “Чи можно навчити компьютер грати в шахи, не говорячи йому, як що треба робити?”. Або “Як само впливає освітлення на якість розпізнавання текстів?”. Через те, що ML&CV — прикладні дисципліни, більша частина котрібюшнів — це відповідь на питання “Як зробити, щоб …”. Але будь-які інші варіанти також можливі.
Наприклад, дуже непоганий варіант — запропонувати нове питання. Це можно зробити теоретично, показав якийсь новий клас задач, чи практично — запропонувався новий датасет + мотивацію.

Ця відповідь повинна бути новою (саме так — ніхто до вас не робив). Новою може бути метод, застосування, нюанс методу. Сказати “можна використовувати нейросітки для розпізнавання обличь” не можна — бо це всі й так знають.

Без новизни статті немає, крапка. АЛЕ. Буває, що якийсь метод використовують в індустрії, але в статтях він не описаний. Тут діє принцип: що не опубліковано, того не існує, за виключенням якихось уж занадто очевидних речей. Зазвичай (чому не завджи — нижче), ревьювери обізнані в галузі, тому якщо ваша робота сильно нагадує щось вже існуюче — вам про це нагадають. В цьому випадку або требо показати, що ви не такі вже й схожі, або (якщо і правда) — забрати статтю назад. Більше того, позиціонування роботи в сенсі “чим ми відрізняємось від інших” — must have частина статті.

1.5)Потужність, або вигода від вашого метода. Ви, скоріш за все, ніколи не опублікуєте метод, який дасть + 0.001% за рахунок десятикратного зниження швидкості. Тут діє таке правило — чим простіший ваш метод, чим більш загальна проблема, яку він вирішує, тим нижче допустимі покращення від нього. +10 % точности в пошуку по картинках ще краще, ніж +20% точності пошуку котиків і ніж 70% покращення позпізавання лівої задньої ноги таргана. Є виключення — вузьки, але мега-важливі самі по собі задачі, типу позпізнання обличь.

Окей. Допустимо, у вас є непогані результати, що далі? Далі треба написати статтю.

2) Оформлення та структура. Перше, що треба зробити — скачати темплейт для статті і прочитати вимоги по оформленню. Як правило, вони вже закодовані в самому темплейті. Що важливо — всі конференції в нашій галузі — double blind. Це значить, що автор не знає, хто рецензенти, а вони — хто автор. Тому стаття пишеться анонімно.

Порушення анонімності — автоматичний реджект. Є ще два способи отримати автореджект. Це — подати статтю НЕ в запропонованому темплейті. І третій — перевищити максимально допустимий обсяг статті, зазвичай — 8 сторінок. Все інше може покращити чи погіршити ваши шанси, але не настільки автоматично.

Як правило, структура статті наступна:

- Задача, чому вона важлива, як її вирішують зараз, які є з цим проблеми. 
- Сутність вашого методу.
- Як ви перевіряєте, чи доводите, що він працює
- Чим ви кращі за конкурентів (до речі, хто вони?)
- Де метод не працює.
- Висновки із експериментів, чи просто саммарі.

3) Сама презентація. Ніякої води, ніяких загальних фраз. Принцип “не розповідай, а показуй” працює і тут. Не “наш метод краще”, а “наша accuracy на датасеті Х більша на 100500 відсотків”. Ніяких спекуляцій (це як база, про виключення — нижче).

4) Завжди порівнюйте із конкурентами. Якщо ви не знайшли недавніх (пейпер від 1–2 роки тому) конкурентів та не запропонували нової задачи — ви погано шукали. Якщо ви запропонували нову задачу, чи формулювання, ваш обов’язок — знайти методи, що найбільш підходять, та затестити їх на вашому датасеті. 
Без точки відліку ніхто не зрозуміє, чи добрий ваш метод, чи ні.

5) Що саме сприяє тому, що ваш метод такий кльовий? Самий простий спосіб це перевірити та показати — так званий ablation study. Це табличка, де ви послідовно вимикаєте один за одним ваші покращення і показуєте, як це впливає не результат. Вам можуть пробачити відсутність такого розділу, якщо результати просто вражають, а задача — мега-важлива сама по собі. В усіх інших випадках, відсутність ablation study — це сильний мінус.

6) Сумна частина. Нажаль, частина рев’юверів люблять математикообразність. Тому ніколи не завадить додати математичне формулювання задачі, loss function чи чогось такого. Це не вода в суворому розумінні, але часто не сильно важливо для розуміння статті. При цьому не пишіть нерелевантних штук — тільки те, що ви використовуєте. Нерелевантні штуки не люблять.

Тепер трохи про сам процес рецензування. Отже
1) За 5 секунд до дедлайна ви завантажуєте ваш анонімній пейпер на сайт конференції

2) Його відправляють рецензентам (зазвичай трьом, дуже рідко чотирьом), які типу знають вашу область. Чому типу? Тому що кваліфікованих спеціалістів не так багато, а щорічно на CVPR + xCCV +
ICML + NIPS сабмітять сумарно приблизно 16 000 статей. І це не враховуючі конференції погірше. Множимо на 3 (кількість рецензентів на статтю), отримуємо 48 000 людино-рецензій. Навантаження надзвичайно велике, тому якість…буває різна. Деякі розуміють ЩО ви хотіли сказати, інші, здається, не вміють читати просту англійську. Тому acceptance — завжди лотерея. В середньому, якщо стаття пройшла на конфу — вона якісна. Бувають відхилення в обидва боки — погані статті на конфі, чи добрі поза нею. Але все ж таки, погані на конфі бувають не дуже часто. 
Рецензенти відмічають недоліки та сильні сторони статті і видають числову оцінку — от 1 до 5, чи 1 до 10. 
Взагалі рекомендую подивитись гайдлайни для рев’юверів, вони багато чого пояснюють.
http://cvpr2018.thecvf.com/submission/main_conference/reviewer_guidelines
https://nips.cc/Conferences/2018/PaperInformation/ReviewerACSACGuidelines

3) Після цього у вас є 1 тиждень та 1 сторінка, щоб відповісти на зауваження ревьюверів. Це так званий rebuttal.
Є два правильні шаблони відповідей на зауваження. Якщо ревьювер задає питання, чи щось не так зрозумів, то ви пишете “Ми уточнимо це в фінальній версій таким чином: […]”. Якщо ревьювер неправий, то ви ввічливо наводите конкретний приклад, чому він не правий і знову пишете, як переформулюєте це в статті. Майте на увазі, що ревьювер точно забуде про що стаття, тому коротко переформулюйте їх запитання та формулюйте відповіді так, щоб все було зрозуміло НЕ ПЕРЕЧИТУЮЧИ СТАТТЮ. Крім того, крім рецензентів, ваш ребаттал буде читати в спірних випадках area chair. Тому в ваших інтересах сформулювати так, щоб сторонній людині було очевидно, ви праві, а ревьювер — ні. Якщо, звичайно, вона чи він ДІЙСНО неправі.

4) Ще через місяць-два прийдуть фінальні результати — чи прийняли вашу статтю, чи ні. Якщо так, то важливо за святкуванням не забути пофіксити статтю відповідно того, що ви обіцяли в ребатталі, та й просто ще раз пофіксити описки та slavic English. Пам’ятайте, що по вашій статті будуть судити о вас, особливо, що вона одна.

Поки все, через кілька днів розпишу кілька прикладів того, як треба писати, а як — ні, на базі власний пейперів.