Ранняя остановка, собственная функция потерь, важности в 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

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

Вдруг, не видели. Бинанс отдает всю свою историю на data.binance.vision.