В общем, не надо использовать переобученные деревья, подведут. Обнаружили точку переобучения, монотонное уменьшение функции потерь/метрики на валидационном датасете сломалось, функция/метрика пошла танцевать, деревья после этой точки отсекаете. Но когда будете переобучать бустинг на всем наборе, количество деревьев добавляем, потому что обучаете на большем по размеру наборе. И это не какой-то там трюк с 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.

#datasets
Ещё одна штука с данными (и не только)

https://www.openml.org