Best paper award ICML 2019Такую награду получило две статьи.
Про первую статью уже было тут.
Вторая статья называется Rates of Convergence for Sparse Variational Gaussian Process Regression.
Как и предполагает название, описывает она достижения в области сходимости регреcсии на основе гауссовских процессов.

Гауссовские процессы часто используют для задания априорных распределения в байесовских моделях. Их плюс в том, что известно аналитическое решение для апостериорного и маргинального распределения для регрессионной модели. Их минус - в вычислительной сложности O(N³) и O(N²) по памяти, где N - количество экземпляров в данных.

Известны алгоритмы, сводящие этот вывод к O(NM² + M³) по времени и O(NM + M²) по памяти, где M - это число "индуцирующих" переменных (inducing variables). В этом случае, настоящяя вычислительная сложность зависит от того, как увеличивается M при увеличении N с сохранением точности приближения.

В статье показано, что с большой вероятностью расстояние Кульбака-Лейблера (KL divergence) между аппроксимирующим и реальным распределением можно сделать сколь угодно малым при том, что M будет расти медленнее, чем N. В частности, если есть нормально распределенные данные размерности D и в качестве ядра ковариции используется squared exponential, то M может расти как логарифм от N по основанию D.

Заметки обо всём ICML:
https://david-abel.github.io/notes/icml_2019.pdf
Что такое регрессия на основе гауссовских процессов: длинное объяснение и короткое.

Заметка о том, что работает и не работает из практик Agile в data science.

Часть 1

Часть 2

TL;DR
Работает:
- планирование и приоритезация
- разбиение на задачи с ограничением по времени
- ретроспективы и демо.

Что не работает и как быть:
- временные оценки - их можно заменить ограниченными по времени экспериментальными задачами
- быстро меняющиеся требования - собственно использование планирования и приоритезации с фиксацией задач хотя бы на время спринта должно показать бизнесу, что работа без переключения контекста эффективнее
- ожидание результата в виде кода в конце спринта - здесь поможет фиксация ожидаемого результата (вместо кода это могут быть результаты экспериментов, определение следующих шагов)
- слишком рьяное следование требованием бизнеса - выделять, например, 2-3 недели в квартал на инновации вместо работы над текущими задачами.

Там ещё есть интересный пример про то, как proof-of-concept занял 2 человеко-месяца, а внедрение в продакшн 117, то есть где-то в 60 раз больше. Такое тоже может быть и нужно это учитывать.

Согласны? Узнали?
Пользуетесь практиками agile в data science командах?

Medium

Data Science and Agile: What works and what doesn’t work

A deeper look into the strengths and weaknesses of Agile in Data Science projects (Part 1 of 2)

Недавно также вышла статья, в авторах которой числятся Yarin Gal и Geoffrey Hinton. В ней рассказано о технике, которая позволяет существенно уменьшать размер сети, не сильно теряя в производительности.
Часто на практике используются способы уменьшения размера сети, которые отбрасывают веса, например, учитывая их размер. Они основаны на надежде на то, что размер весов подсети коррелирует с её производительностью. Авторы же предлагают, изначально, натренировать сеть так, чтобы она не теряла в производительности при конкретном способе последующего отбора весов.

Для этого нужно сначала выбрать критерий, на основе которого сеть будет уменьшаться (размер весов, например), и использовать targeted dropout во время обучения. Targeted - то есть такой, который будет в большей степени воздействовать на малые веса, подталкивая сеть уменьшать веса неважных подсетей.

Авторы показывают большую эффективность такого подхода по сравнению с другими техниками, особенно при сильном уменьшении размера. Также пишут, что это займет всего пару строчек в реализации на TensorFlow или PyTorch.

Learning Sparse Networks Using Targeted Dropout
https://arxiv.org/pdf/1905.13678.pdf