Улучшая можно и ухудшить

Сегодня хочется поговорить про несколько контринтуитивную штуку. В некоторых случаях желание где-то что-то оптимизировать приводит не только к улучшению, но и к ухудшению.

Надо оптимизировать, от этого становится лучше
Совершенно логичная и понятная мысль: надо искать то, что можно улучшить и улучшать это.

Есть у вас какой-то ручной труд, вдобавок сопровождаемый человеческими ошибками? Вот кандидат на автоматизацию. Станет быстрее и качественнее.

Есть неэффективный инструмент, с которым и работа медленно идет, и людей на рынке труда мало? Вот еще кандидат на оптимизацию, замену, стандартизацию.

Конечно, надо искать в процессах, инструментах, командах, управлении места для улучшения и работать над ними.

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

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

Вы придумали, как ускорить работу менеджера. Менеджер стал генерить кучу каких-то полезных идей и гипотез, начал наваливать это на разработчиков. Разработчики стали тонуть в потоке задач, пытаясь за всё сразу взяться и поскорее сделать. В итоге везде пооткусывали, внимание распылили, качество в спешке ухудшили, а довозить что-то работающее до продакшена стали еще медленнее, чем раньше.

Или ускорили разработчиков, они море тасочек на тестировщиков вылили, а те либо не глядя выпускают в прод (что ухудшает качество), либо добросовестно тестируют, и не быстрее, чем раньше (ведь их пропускная способность осталась такая же), подливают это дело на прод. В итоге либо ничего не изменилось, либо качество ухудшили.

Что именно надо оптимизировать?
Примеры выше – классические примеры локальных оптимизаций. Эта проблема идет из того, что при улучшении мы смотрим на какую-то конкретную часть, забывая о том, что конечный продукт выпускает вся система. Следовательно, улучшения нам нужны такие, которые будут влиять на всю эту систему в положительном ключе.

Оптимизировать нам в первую очередь нужно не то, что легче оптимизировать, а то, что во всей цепочке производства продукта является самым слабым звеном, узким бутылочным горлышком. Тогда можно существенно увеличить пропускную систему целиком, потому что вся система работает со скоростью самого медленного звена.

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

Итог
Могу порекомендовать почитать пару книг, которые затрагивают теорию ограничений систем, и прикинуть это на свои дела, компанию, проекты.

Элияху Голдратт «Цель. Процесс непрерывного совершенствования»
Джин Ким, Джордж Спаффорд, Кевин Бер «Проект «Феникс». Роман о том, как DevOps меняет бизнес к лучшему»

Старайтесь оптимизировать в первую очередь самые слабые звенья, а не то, что проще всего оптимизировать. Иначе и пользы особой не принесете, и даже вред можно причинить.

#ml
Топ контент по бустингам

Ранняя остановка, собственная функция потерь, важности в LightGBM
В этой тетрадке найдете реализацию ранней остановки для нативного и sklearn-интерфейса, ну и, конечно, реализация ранней остановки с помощью callback-функции.

Существует несколько правил для определения количества итераций ранней остановки. Для градиентного бустинга с количеством итераций меньше 1000 количество итераций ранней остановки должно составлять не больше 10%, т.е. не больше 100 итераций. Для градиентного бустинга с количеством итераций больше 1000 количество итераций ранней остановки должно составлять не больше 5%, т.е. не больше 50 итераций. Чем меньше темп, тем быстрее должно происходить восстановление монотонного снижения. Поэтому для низкого темпа обучения (меньше 0,01) количество итераций ранней остановки берут еще меньше. Чем больше итераций требуется для восстановления монотонного снижения функции потерь или метрики качества на проверочной выборке и чем больше гэп между кривой обучения и кривой валидации, тем сильнее переобучение.

В общем, не надо использовать переобученные деревья, подведут. Обнаружили точку переобучения, монотонное уменьшение функции потерь/метрики на валидационном датасете сломалось, функция/метрика пошла танцевать, деревья после этой точки отсекаете. Но когда будете переобучать бустинг на всем наборе, количество деревьев добавляем, потому что обучаете на большем по размеру наборе. И это не какой-то там трюк с Kaggle. Это реальная практика, применяющаяся в промышленном подходе. Бустинг чувствителен к размеру набора данных, во временных рядах, где используется проверка расширяющимся окном (когда размер обучающего набора растет), это вылилось вообще в отдельную проблему, в Walmart придумали схему с динамической корректировкой гиперпараметров, которую потом переносят на прод. Обычно для расчета требуемого количества деревьев используют множитель, зависящий от количества блоков перекрестной проверки, которая использовалась при подборе гиперпараметров (1,2 – для 5-блочной перекрестной проверки).
Там же в тетрадке найдете пример, как писать пользовательскую функцию потерь, например, логистическую с понижающей корректировкой гессиана, ну это прям в лоб как пример, а вот циклическая корректировка с затуханием будет гораздо эффективнее (будет время, напишу про нее подробнее). Что это дает? Лучшее качество на меньшем количестве деревьев.
Еще в тетрадке описаны способы вычисления различных важностей в нативном и sklearn-интерфейсов. Про важности бустинги помним один момент, про который я, как попугай, говорю своим ученикам по несколько раз: точечные оценки важности шумные, используйте кроссвалидацию и ориентируйтесь на усредненные метрики важностей, наиболее реалевантные из предложенных – важности на основе выигрыша (gain), на самом деле есть важности получше – на основе усредненной минимальной глубины использования и количество деревьев, корень которых разбивается по данному признаку. Но это нужно самому реализовывать, в целом ничего сложного. Обратите внимание, обе эти метрики ориентированы на поиск фичей, которые используются в верхних уровнях деревьев. И это лучше, чем просто количество разбиений считать или складывать уменьшения функции потерь. Если набор до 300-500 тыс наблюдений, 5-блочной перекрестной проверки хватит, если больше – используйте повторную 5-блочную перекрестную проверку.

#gametheory
Крутая штука для понимания диллемы заключённого

https://notdotteam.github.io/trust/

Мега шпаргалки по matplotlib

https://github.com/matplotlib/cheatsheets

Даже и не думал, что так много графиков и тонкостей настройки

UCI?

https://archive.ics.uci.edu/ml/datasets.php
Или про что-то другое

Преодолеваем постоянное откладывание дел

Для разгрузки оперативной памяти я все будущие задачи вношу в таск-менеджер. Независимо от объёма задачи всё должно быть записано, чтобы не держать в голове. Но дальше возникает большая проблема — некоторые задачи после внесения в таск-менеджер я не делаю никогда, постоянно отодвигая на "когда-нибудь потом". Это приводит к большим неудобствам. Например, вторая часть стрима python student уже три месяца откладывается. Проблема в том, что назначение подобной задачи "на сегодня" плохо помогает, так как задача большая и сложная, подступиться к ней сложно.
Мой опыт преодоления такой:

✅ Декомпозирую задачу. Продумывание задачи и выделение небольших шагов по её выполнению переводит задачу из разряда "ух, страшное и большое" в "хм, вот этот шаг займёт полчаса и даже понятно, как его сделать".

Давайте на примере. Задача "снять ролик python students, часть 2". Декомпозируем:
— решить, какие темы включить в ролик
— прописать сценарий
— прописать текст
— снять ролик
— смонтировать ролик
— расставить текстовые подсказки по ролику
— подкорректировать аудиодорожку
— выложить ролик

Прелесть такого плана в том, что каждая задача мотивирует сделать следующую. Если я нашёл темы для ролика, то уже хочется написать сценарий. Когда готов сценарий, то прописать текст уже несложно.

Если после декомпозиции я не приступаю к задаче, то тут два варианта: либо задача по факту мне не нужна и её нужно выкинуть, либо я плохо декомпозировал, и тогда надо раздробить её на более мелкие подзадачи.

Для меня главный фактор откладывания задачи — её неясность. Дробление задачи позволяет неясность устранить. Задачи должны быть такого размера, чтобы минимизировать напряжение мозга: взял и сделал.

Еще один житейский пример: в машине загорелась лампочка "долить охлаждающую жидкость".
Уже на опыте я не заношу задачу: "Съездить в сервис и долить жидкость". Куда ехать? Когда ехать? — вот такие вопросы у меня будут возникать и я точно буду её откладывать.

Я ставлю задачи:
— Выбрать сервис для замены жидкости (смотрю отзывы на картах)
— Позвонить и договориться о времени (узнать цену, сколько займёт по времени, после разговора записать адрес)
— Поехать в сервис на замену жидкости <— по факту это та же задача, но только теперь у меня нет к ней вопросов, просто беру и делаю.

Обратите внимание на подсказки в скобках, они позволяют в момент решения задачи дополнительно не думать: А как выбрать сервис? А что нужно дополнительно уточнить, когда буду звонить?

Полезны ещё несколько аспектов:
✅ При составлении плана учитываю будущую загрузку, не планирую 40 задач по часу каждая на воскресенье. Приходит с опытом. Или не приходит.

✅ Учитываю приоритет задачи. Если задача важная / выгодная / полезная, то планирую её пораньше.

✅ Умеряю перфекционизм. Часто надо сделать хорошо, а не идеально. Опускаться до уровня "кое-как" не всегда оправданно, но иногда и это годится.

✅ Для меня ещё работает практика начать чуть-чуть. Если к чему-то не могу приступить, просто ставлю себе установку — начну и 15 минут поделаю. Обычно после такого начала продолжаю делать задачу. А если нет, то не расстраиваюсь, значит задача не такая нужная.

В дополнение вспомним про хорошую и плохую прокрастинацию от Пола Грэма. Это когда ты занят, но не тем.

А еще я каждый день анализирую список своих задач, но это тема отдельного поста.
#devfm #edu

#mlops
Data drift

#mlops
Concept drift и data drift

крон внутри докера - грех перед Господом системдизайна