Что влияет на скорость проверки гипотез?
Что влияет на скорость проверки гипотез?
Жека Никитин
Собирались на днях с коллегами на брейнсторм/обсуждение на тему “как нам быстрее проверять гипотезы и ставить больше экспериментов”. Тема на самом деле очень обширная, количество факторов, влияющих на скорость проверки гипотез - огромное. Условно их можно разделить на такие направления:
- Процессы - всё, что связано с организацией работы команды: встречи, обсуждения, ревью, постановка задач, приоритизация и многое другое
- Человеческий фактор - уровень компетенций членов команды, мотивация, конфликты в команде
- Инструменты - всё то, что позволет быстро и удобно придумывать, ставить и сравнивать гипотезы: системы для оркестрации и трекинга экспериментов, витрины данных, бэклог и доски, в конце концов организация рабочего пространства
- Вычислительные ресурсы - количество машин, GPU, ядер CPU, места на диске и так далее
- Технические факторы - насколько оптимально написан код трейн-лупа, используются ли трюки для ускорения обучения, сохраняются ли промежуточные данные для быстрой загрузки. Пара ссылок на тему - старая, но классная серия постов про ускорение обучения резнета и новая либа с кучей трюков для быстрого обучения PyTorch-сеток
- Оценка гипотез - как быстро и правильно сравнивать гипотезы. Помимо правильного выбора метрик здесь мы хотели обсудить такие вопросы - можно ли быстрее сравнивать гипотезы, обучаясь на маленьком сабсете данных, меньшем количестве эпох или на картинках меньшего размера с большим батч-сайзом?
Больше всего времени мы, конечно, потратили на последний пункт, потому что он самый интересный =) Загвоздка здесь в том, что сравнения гипотез, сделанные в условиях, отличных от оптимальных, могут быть совсем не валидными. Например, задача выбора такого подмножества полного набора данных, на котором метрики будут не сильно отличаться, называется core-set selection (пример статьи). Наша задача даже несколько проще, ведь нам нужно не достичь тех же метрик, а быстрее правильно отранжировать гипотезы. Но об этом подробно напишем позже, после серии экспериментов и обсуждений =)
Тем не менее, важно помнить, что зачастую интересные решения - далеко не самые оптимальные. Потратить пару дней на оптимизацию кода и ускорить трейн-луп в два раза может стать значительно более эффективным решением, чем ставить эксперименты по поиску core-setов 😛 Анализируйте рабочий процесс команды, профилируйте код и устраняйте свои боттлнеки.