Cherry picking и его родственники

В начале декабря я опубликовал на Хабре статью про нейронки для генерации людей/одежды на людях/изменения поз. И очень восхищался результатами двух статей. Правда, не без ремарки:

Есть две хороших статьи текущего года которые так умеют (и обе без сорсов, так что нет уверенности что все работает!):

И вот, на одну из них выложили исходники. Давайте посмотрим что получилось!

В оригинальной статье были просто волшебные картинки. По сравнению с всеми современными статьями просто небо и земля. Посмотрите на то как классно перешла надпись “yes” или татуировки на руках.

На первый взгляд не понятно даже где подделка!

А тут ещё и коллаб сделали с статьей – https://colab.research.google.com/github/tg-bomze/collection-of-notebooks/blob/master/HomeStylist.ipynb
Так что потестил. Ну, как вы понимаете реальность прозаична:

Кажется что неподготовленным взглядом все хорошо видно
И проблема не только в дырках в одежде

Нужно ли говорить что качество очень сильно отличается?
При этом, очевидно, что результат неплох. Но он принципиально не тот что в статье показывается.

Меня такое всегда печалит. Ведь хорошая статья. зачем портить впечатления?…

Зато хороший повод поговорить о том какие махинации бывают и на что надо смотреть.

Нет метрик? Надо проверять!

Первое что должно бросаться в глаза – отсутствие метрик. Если задача их не предусматривает (визуальные штуки), то почти гарантированно что в статье/сопутствующей информации (видео/фото) все будет оформлено максимально аккуратно.
Сегодня в статьях очень редко принято приводить примеры ошибок/оценивать какой процент примеров не работает.

Когда только появлялись сеточки для генерации лиц – были статьи где уровень плохой генерации составлял 95% и более.

Сейчас обычно все получше:)

Главное, что надо помнить – никогда не стартуйте проект опираясь на статьи. Всегда попробуйте пощупать код, посмотреть результаты. Я знаю очень много примеров когда у людей загнулись крупные проекты когда они опирались на статьи.

Когда-то давно, в 2014 году, я попробовал повторить результаты статьи по усилению движений. И, о чудо, все хорошо работало только на очень специфических примерах (правильный свет/ракурс/хорошая камера/и.т.д.). Потом мне жаловалось два человека на то, что они пробовали на базе этой идеи запустить большие проекты – но ничего не получилось.

Есть метрики? Все не так просто.

Давайте посмотрим как можно обманывать (зачастую не специально) доверчивых DS’ов.

Нет кода

Казалось бы – очень банально. Но отсутствие кода, по сути, это 80% что статья может не соответствовать реальности. Посмотрим на хайповый DALL-E. Он вышел в прошлом январе. И лишь к концу весны появились сетки с сопоставимым качеством. При этом, надо понимать, что в них было много поменяно от оригинальной статьи. А попытки повторить 1*1 давали не очень симпатичные результаты.
Статья оставляет очень много пространства для фантазии, которого нет лишь в коде.
С появлением Papers with Code люди стали это понимать. И сейчас статьи без кода читают только от крупных компаний, но относятся к ним скорее “результат достижим, но не факт что так как описан”.

Код дает другой результат

Это популярная тема. Помню когда-то, древняя версия OpenPose давала результат не тот который был у них заявлен в точностях. Мы на это потратили месяц, по сути сделав свою сеть и свой протокол обучения. Очень часто народ жалуется на невоспроизводимость результатов. Есть даже доска позора – https://www.paperswithoutcode.com/ но ей мало кто пользуется.

Для тестирования выбраны неактуальные категории

На Papers With Code есть отдельные категории которые друг друга повторяют. Например Action Recognition и Activity Recognition. Часть статей не пересекается. Можно бенчмаркаться по тем фреймворкам где вы лучше и заявлять только их. Но в рассказе делать акцент/выкладывать код по какому-нибудь COCO, где результат слаб.

Правильно подобранные партнеры для спаринга

Если вы каким-то образом хотите выделиться – главное самому установить правила. Хороший пример – Yolo v5 на старте. Я рассказывал подробнее тут. Сейчас все уже не так плохо. И даже мы его иногда используем. Но в момент выхода там были очень странные бенчмарки, для сравнения выбраны слабые сети.
При оценке скорости вместо время исполнения был выбран fps, который завязан на латентность памяти GPU и загрузку-выгрузку.
Но за счет громкого бренда “YOLO” и стартовым заявлениям – сеть даже не особо выделяясь по качеству сумела стать известной.

Прочее

Наверное, я встречал ещё массу недоговорок/хитростей/косяков в статьях/коде. И тут можно скатиться в бесконечные перечисления. Косяки могут быть намеренные, могут быть случайные. Могут быть от взаимного непонимания. И прочее и прочее. И это может искажать результаты. Как реальные цифры, так и восприятие

Заключение

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