partially unsupervised

2020-10-13 13:35:09 Давненько не брал я в руки шашек писал про компьютерное зрение, пора наверстать и вбросить визионерский тезис.
Кажется, что GANы наконец-то созрели для относительно массового использования.

Концепцию изобрели в 2014, примерно в 2017 начали появляться впечатляющие картинки о перекраске яблок в апельсины, а лошадей в зебр, но до реального использования все еще было далековато. Год-два назад на гитхабе стали появляться репозитории, которые иногда можно было запустить и сколько-то воспроизвести. Сейчас там уже есть не только отдельные пайплайны, но и более или менее зрелые библиотеки (пример, еще пример).

В академическом мире начали появляться работы, в которых GAN - не самоцель, а один из винтиков для другой задачи (например, мне очень понравилось это применение super-resolution сети для повышения робастности в классификации). Т.е. подход становится частью повседневного набора инструментов.

Что важнее, GANы более или менее поехали в прод, и не только в узкоспециализированных стартапах. Из относительно простых примеров - DeepHD Яндекса, которому примерно два года. Сложно сказать, как давно GANы появились в эффектах Snapchat, но явно не меньше года. Наконец, относительно свежий релиз платформы для видеозвонков от NVidia (кстати, они собирают и развивают прям серьезную экспертизу в этой нише, что неудивительно: с одной стороны, массовое распространение ганов может стать еще одним драйвером роста для видеокарт, с другой - у них есть ресурсы для экспериментов).

Конечно, такие модели все еще куда капризнее в обучении, чем традиционные пайплайны, но это уже что-то вполне достижимое для толковой, но не гениальной CV команды.

Если этот пост вызвал у вас fear of missing out, посмотрите на эту специализацию. Сам я, конечно, ее еще не прошел, но syllabus выглядит неплохо. Открыть/Комментировать

2020-10-07 17:35:24 (Картинка для привлечения внимания) Открыть/Комментировать

2020-10-07 17:35:05 Бывший коллега когда-то сформулировал такой критерий: работать нужно так, чтобы раз в год собиралось достаточно интересного опыта, чтобы нестыдно выступить на какой-нибудь отраслевой конференции, похвастаться достижениями, рассказать про грабли и так далее. Собственно выступать необязательно (и лень, и NDA никто не отменял), это внутренний критерий. А если рассказывать было бы не о чем, это хороший повод задуматься, не занимаюсь ли я херней.

Так вот, я периодически ныл пацанам, что за последний год не сделал ничего технически интересного. Никакого тебе state of the art, обмазывание старых моделей новыми эвристиками, кругом самоповтор. Но недавно осознал, что вообще-то кое в чем я поднатаскался: just make it work. Собирать древние версии библиотек в окружениях, совершенно не поддерживаемых с точки мейнтейнеров этих библиотек, по кускам наводить порядок, обеспечивая вопроизводимость с точностью до 1e-5, манкипатчами дебажить мистические баги, воспроизводимые только в продакшене...

Последний баг, с которым я возился, был связан с многопоточностью: некая операция запускается в отдельном треде. Расследование показало, что там она на уровне библиотек пытается раскидать свои сабфункции по новым тредам, а каждая сабфункция внутри дергает низкоуровневые OpenBLAS API, которые - сюрприз-сюрприз - в неявном виде тоже могут использовать многопоточность. Иными словами, на море на океане есть остров, на том острове дуб стоит, под дубом сундук зарыт, в сундуке — заяц, в зайце — утка, в утке — яйцо, в яйце игла — смерть Кощея микросервиса.

Впрочем, вопрос, не занимаюсь ли я херней, остается открытым. Ведь крут не тот, кто героически решает странные проблемы, а тот, кто не допускает их появления изначально. Открыть/Комментировать

2020-10-02 17:48:52 Один мой кореш (кстати, автор канала @autopilot_disengaged) недавно осваивал Haskell, и по этому поводу мы устроили дискуссию на одну из вечных холиварных тем: действительно ли функциональное программирование прочищает мозги и заставляет впоследствии писать менее грязный код? Естественно, к общему знаменателю мы так и не пришли, но я сформулировал некоторый тезис.

Кажется, что распределение плохого кода бимодально.

Одна мода - натурально говнокод, написанный недалекими программистами. Это ребята, которые не умеют в абстрактное мышление, постоянно копипастят, не знают базовые алгоритмы, не могут осилить более сложные фичи языка, чем if и for. Так вот, если их бить монадами по ебалу заставлять писать композиции функций поверх иммутабельных коллекций вместо беспорядочного ковыряния глобального стейта, зачастую их код становится лучше. (И тут я вспоминаю, как некий map-reduce фреймворк в Яндексе выпрямлял мои собственные руки).

Вторая мода - код, написанный слишком умными и самоуверенными ребятами. Это инженеры на переднем краю, которые с удовольствием используют все возможные возможностей языка, паттерны и хитроумные алгоритмические оптимизации. Это те, кому может не хватать фичей даже в Scala. Проблема в том, что даже они сами не всегда могут понять, что они накреативили через пару месяцев вдалеке от репозитория, а сторонние наблюдатели тем более страдают от необходимости поддерживать такой код, где каждая вторая функция вызывает вопрос "А это вообще легально?". Ну и конечно, таким умникам функциональное программирование не изменит стиль написания кода - они и так знают эту парадигму. Так что спасение от таких умников - не функциональщина, а скорее прокрустово ложе Golang-а. Открыть/Комментировать

2020-09-28 17:57:59 Почему в software engineering так сложно с оценками сроков? Потому что зачастую практически невозможно на глазок оценить глубины кроличьей норы, если речь идет о чем-то сложнее перекраски кнопки на лендинге. Вот небольшой пример. Есть сервис на питоне, в… Открыть/Комментировать

2020-09-24 20:08:15 Рубрика "Бесполезные находки": оказывается, существует unicode-символ "Больше или равно или меньше или равно" ⋚.

Единственное (да и то сугубо умозрительное) применение, которое могу придумать - показывать, что между объектами может существовать отношение сравнения. Открыть/Комментировать

2020-09-21 14:19:38 Почему в software engineering так сложно с оценками сроков? Потому что зачастую практически невозможно на глазок оценить глубины кроличьей норы, если речь идет о чем-то сложнее перекраски кнопки на лендинге.

Вот небольшой пример. Есть сервис на питоне, в котором некоторые запросы начали тормозить. Хочется найти эти запросы, для этого - добавить в логи какой-то request_id.

Но в мире асинхронного питона нельзя просто хранить какой-то id на уровне треде, т.к. тред может переключаться между запросами в процессе await, нужно использовать ContextVars. Чтобы прикрутить ContextVars, нужен Python 3.7+, нужно обновиться. В процессе обновления выясняется, что некоторая старая версия библиотеки официально не поддерживает новый питон, нужно собрать ее руками. Методом проб и ошибок находим коммит, с которого собиралась старая версия для старого питона, собираем для нового питона - результаты не сходятся, тесты падают!

Для начала нужно собрать минимальный воспроизводимый пример (в моем случае получился Dockerfile на 50 строк и примерно столько же Python-кода). Разбираем билд и видим, что библиотеке нужен с десяток shared зависимостей, для которых не всегда указаны версии. Можно найти какие-то древние логи на CI-сервере, который собирал библиотеку для старого питона, и из них достать какие-то куски информации. Их не хватает, и версии приходится перебирать бинарным поиском. Версии подобраны, они конфликтуют друг с другом, и склеить их вместе можно только странным перебором apt install ... && apt remove ... && apt install.

На все эти развлечения ушло уже три дня, и я не могу сказать, что приблизился к заветным request_id. А ведь сторонний наблюдатель с навыками эффективного менеджера вполне мог бы возмутиться: "че там делать вообще? завел переменную и клади в лог, делов-то". Открыть/Комментировать

2020-09-16 12:32:01 Извините, это пост затрагивает две чрезмерно захайпованные темы - политику и COVID-19. Хотя вообще он про анализ данных.

Некий председатель комитета по здравоохранению сегодня сказал дословно следующее:
Начиная с 21−22 августа, регистрируем рост заболеваемости COVID-19. Инкубационный период у коронавирусной инфекции в среднем две недели. Во второй декаде августа в городе стали проходить массовые акции. А любые массовые мероприятия способствуют распространению коронавируса — не соблюдается социальное дистанцирование.

Оставим за скобками вопрос, есть ли политическая компонента в его высказывании, и применим здравый смысл и базовое понимание статистики.

Как обыватель, я могу совершенно ничего не знать про эпидемиологические свойства COVID. Но даже обыватели неоднократно слышали про двухнедельные карантины.

Очевидно, что инкубационный период - это не одно число, а какое-то распределение: у кого-то из зараженных симптомы проявятся раньше, у кого-то - позже. Не менее очевидно, что карантин служит для того, чтобы у подавляющего большинства потенциально зараженных успели проявиться симптомы. Если, например, половина зараженных выйдут из карантина, имея высокую вероятность заболеть в следующие дни, карантин не имеет никакого смысла. Следовательно, срок карантина должен покрывать большую часть распределения, т.е. заканчиваться в районе 95..99 перцентиля.

Конечно, можно представить распределение, у которых 99 перцентиль совпадает со средним, но это редкое явление, не свойственное естественным процессам, в т.ч. эпидемиям. Какое-нибудь гамма-распределение априорно выглядит правдоподобнее, и тогда среднее должно быть значительно меньше, ближе к медиане.

Хватит гадать, пойдем читать интернет. Запрос "covid-19 incubation period distribution" приводит нас к такой картинке с плотностью вероятности. Очевидно, что по всем исследования среднее такого распределения не может находиться в районе 14 дней. А для тех, кто сомневается в своей способности читать графики, можно найти прямое пояснение от ВОЗ:

The incubation period of COVID-19, which is the time between exposure to the virus and symptom onset, is on average 5-6 days, but can be as long as 14 days.

Q.E.D. Вышеупомянутый чиновник не только не знает важные факты по своей специальности, но и не замечает, как его слова не выдерживают проверку здравым смыслом.

И когда кто-то говорит, что уметь в анализ данных - обязательно для всех белых воротничков современности, обычно имеется в виду способность совершать такие упражнения в уме и валидировать все вокруг, а не какое-нибудь сакральное академическое знание о том, чем оценка максимального правдоподобия отличается от оценки апостериорного максимума. Открыть/Комментировать