Этап собеседования Machine Learning System Design.

Этот этап попадался в 9 из 10 компаний. Задача - полностью спроектировать  ML решение. От определения задачи и метрик, заканчивая деплоем и оптимизацией.
Здесь важный момент. Время собеседования ограничено. Поэтому с одной стороны важно не растекаться по дереву, с другой стороны важно покрыть все этапы решения ML задачи, а в некоторые даже погрузиться вглубь, чтобы показать что шарите.

В этом помогает четкая структура ответа:
1. Problem definition and requirement clarification. Определение задачи и оценка требований.
2. Data. Источники данных, какая разметка, как выглядит сэмпл.
3. Evaluation. Какие метрики, сравнение с бейзлайном.
4. Features and model. Препроцессинг, варианты моделей.
5. Online eval, deploy. Выкатка + АБ.
6. Further actions. Как дебажить/обновлять/улучшать/ускорять/итд модель.

Каждый из этапов более подробно разобран в репе ML design primer.

Порядок подготовки.
+ Посмотреть видео fb, яндекса, полистать гитхаб ml design primer.
+ Сделать себе пробный собес попробовать задизайнить систему из списка.
+ Почитать пару разборов из технических блогов компаний или инженеров. Например, тут или тут
+ Делать моки (mock-interview). Это когда вы созваниваетесь и устраиваете друг-другу пробный собес. Моки можно искать в этом чате.
+ Получаете фидбек с мока и идете качать слабые места, читаете еще статьи или главы из 329s.

Как сформулировать ML задачу?

Каждый этап разбирать не буду, но о первым расскажу на примере. Допустим, дали задачу сделать фид для контента. Цель: хотим сделать рекомендации  контента(текстовые посты, картинки, видео). Текущая лента обратная хронологическая, хочется сделать персонализированной.

Первый вопрос: зачем? Кажется, что с персональной лентой пользователи будут чаще заходить, залипать в ленте, шерить продукт друзьям. Но, это только предположение, которое нуждается в проверке. Поэтому на старте определимся, как будем оценивать успех или неуспех в количественных показателях.

Продуктовые метрики в рамках собеседования я для себя разделил на три уровня:

1. Деньги 💰– revenue, arpu, конверсии в покупку. 
2. Счастье юзера 😍 – like/view rate, avg session time, views count, etc
3. Технические метрики 🎯– recall@k, diversity of items, etc. Соответственно цель наша больше денег, а гипотеза в том, что повысив технические метрики –> повысим счастье юзера –> заработаем больше деньги. В жизни, к сожалению, зависимость не всегда прямая. Но для задачи этот момент опустим. 

В cs329s этот этап разбит на 4 шага.

1. Framing. Какая ML проблема? Регрессия, Классификация - multiclass, multilabel.
2. Objectives. На какие подзадачи можно разделить? Например, Прокачать engagement ленты, но при этом не уронить качество постов, не форсить спам и кликбейты.
3. Constraints. Ограничения ресурсов, приватность данных, требования регуляторов.
4. Phases. Как будете внедрять решение: эвристика -> простая модель -> оптимизация простой модели -> сложная модель.
По данному пункту советую полистать лекцию 2 в cs329s и если что-то непонятно посмотреть в Lecture Note.
 
Еще один важный момент: на этом этапе задавать уточняющие вопросы, чтобы понять контекст задачи: как решается задача сейчас, число пользователей, доступные ресурсы итп.

#rl
Advanced RL

Увы этого в курсе освещено не будет. Этот курс про самые основы. Чтобы иметь более широкое представление о том, что сейчас происходит в RL могу порекомендовать этот цикл докладов. Ну и конечно читать статьи https://www.youtube.com/playlist?list=PLt1IfGj6-_-eXjZDFBfnAhAJmCyX227ir

PyBoost
PyBoost https://github.com/sb-ai-lab/Py-Boost предназначен для многоклассовой/multilabel классификации, когда у вас десятки/сотни/тысячи классов. Недавно закончилось соревнование https://www.kaggle.com/competitions/open-problems-multimodal/overview. В двадцатке победителей у четверых решение с использованием PyBoost. В наших задачах (40-80 классов) PyBoost показывает лучшие результаты, чем CatBoost. Если классов больше 10, точно стоит попробовать PyBoost. Статья https://openreview.net/forum?id=WSxarC8t-T

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Элияху Голдратт «Цель. Процесс непрерывного совершенствования»
Джин Ким, Джордж Спаффорд, Кевин Бер «Проект «Феникс». Роман о том, как 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