Что влияет на скорость проверки гипотез?

Жека Никитин

Собирались на днях с коллегами на брейнсторм/обсуждение на тему “как нам быстрее проверять гипотезы и ставить больше экспериментов”. Тема на самом деле очень обширная, количество факторов, влияющих на скорость проверки гипотез - огромное. Условно их можно разделить на такие направления:

  • Процессы - всё, что связано с организацией работы команды: встречи, обсуждения, ревью, постановка задач, приоритизация и многое другое
  • Человеческий фактор - уровень компетенций членов команды, мотивация, конфликты в команде
  • Инструменты - всё то, что позволет быстро и удобно придумывать, ставить и сравнивать гипотезы: системы для оркестрации и трекинга экспериментов, витрины данных, бэклог и доски, в конце концов организация рабочего пространства
  • Вычислительные ресурсы - количество машин, GPU, ядер CPU, места на диске и так далее
  • Технические факторы - насколько оптимально написан код трейн-лупа, используются ли трюки для ускорения обучения, сохраняются ли промежуточные данные для быстрой загрузки. Пара ссылок на тему - старая, но классная серия постов про ускорение обучения резнета и новая либа с кучей трюков для быстрого обучения PyTorch-сеток
  • Оценка гипотез - как быстро и правильно сравнивать гипотезы. Помимо правильного выбора метрик здесь мы хотели обсудить такие вопросы - можно ли быстрее сравнивать гипотезы, обучаясь на маленьком сабсете данных, меньшем количестве эпох или на картинках меньшего размера с большим батч-сайзом?

Больше всего времени мы, конечно, потратили на последний пункт, потому что он самый интересный =) Загвоздка здесь в том, что сравнения гипотез, сделанные в условиях, отличных от оптимальных, могут быть совсем не валидными. Например, задача выбора такого подмножества полного набора данных, на котором метрики будут не сильно отличаться, называется core-set selection (пример статьи). Наша задача даже несколько проще, ведь нам нужно не достичь тех же метрик, а быстрее правильно отранжировать гипотезы. Но об этом подробно напишем позже, после серии экспериментов и обсуждений =)

Тем не менее, важно помнить, что зачастую интересные решения - далеко не самые оптимальные. Потратить пару дней на оптимизацию кода и ускорить трейн-луп в два раза может стать значительно более эффективным решением, чем ставить эксперименты по поиску core-setов 😛 Анализируйте рабочий процесс команды, профилируйте код и устраняйте свои боттлнеки.