Forwarded from Information Retriever
RecSys Summer School, день первый.
На этой неделе перед основной конференцией ACM RecSys проходит летняя RecSys школа в Вене, большую часть которой составляют лекции различных профессоров / ресерчеров.
Для меня это возможность научиться чему-то новому, набрать побольше материала для собственного курса по рексису, понетворкаться, а также потусить целую неделю в Вене :)
Что интересного было в первый день:
1. Dietmar Jannach, один из самых цитируемых ученых в RecSys, выступил с вводной лекцией про рекомендательные системы: про их ценность, алгоритмы, оценку качества. С такой лекцией он выступает уже не первый раз, презентации прошлых лет есть в открытом доступе.
Приводил много разных фактов про пользу рексистем. Например, (1) 35% выручки Амазона атрибуцируется рексистемам, (2) а в Нетфликсе говорят, что с помощью персонализации и рексистем “экономят” больше миллиарда долларов в год.
Интересно было послушать и про историческое развитие области:
* в 1992 году в статье Using collaborative filtering to weave an information tapestry впервые был упомянут термин “Collaborative Filtering”
* в 1994 появился первый кейс индустриальной рексистемы (GroupLens, рекомендация новостей), статья GroupLens: an open architecture for collaborative filtering of netnews
* в 2003 Амазон опубликовал статью про Item-to-Item Collaborative Filtering
* потом состоялся небезызвестный Netflix prize (2006 — 2009), в рамках которого Нетфликс выложил самый большой на тот момент рекомендательный датасет с пользовательскими рейтингами фильмов. Про это есть хороший рассказ от CPO Нетфликса на рексисе в 2014 году (тык)
* позже от задачи предсказания рейтингов перешли к learning-to-rank парадигме, стали использовать implicit feedback (время просмотра, клики и тд). Активно использовали матричную факторизацию
* сейчас царит deep learning, про использование которого в рексистемах ваш покорный слуга аж четыре лекции в ШАДе в прошлом учебном году читал, и в этом планирует прочитать еще больше :)
Ссылался на большое количество хороших статей (ссылки можно найти в презентации). Жаловался, что ресерчеры тюнят гиперпараметры только для своих моделей, а для бейзлайнов не тюнят. Что нечестно фиксировать одинаковую небольшую размерность выходных эмбеддингов для обычной матричной факторизации (с обучаемыми векторами пользователей и айтемов) и нейросетей, так как у матричной факторизации становится сильно меньше параметров при уменьшении размерности эмбеддингов.
Упоминал beyond accuracy метрики (статья Beyond accuracy: evaluating recommender systems by coverage and serendipity).
Fun fact: в какой-то момент Dietmar занимался рексистемой для премиальных кубинских сигар =)
2. Barry Smyth (h-index 85!) выступил с рассказом по мотивам статьи People Who Liked This Also Liked ... A Publication Analysis of Three Decades of Recommender Systems Research, в которой приводится аналитика по всем RecSys публикациям за ближайшие 30 лет. Также он немного дополнил рассказ про историю рексистем, показал статью аж 1990 года от Jussi Karlgren под названием An Algebra for Recommendations, в которой уже говорится про моделирование пользовательского поведения и предсказание будущего пользователей. Еще показал очень красивое издание Communications of the ACM 1997-го года, special issue on recommender systems (картинку прикладываю).
Получилось, что за последние 30 лет появилось порядка 50к статей про рекомендательные системы.
А сегодня, во второй день школы, были лекции по психологии, графовым нейронным сетям, а также про оффлайн оценку качества рексистем. Но про это расскажу чуть позже :)
На этой неделе перед основной конференцией ACM RecSys проходит летняя RecSys школа в Вене, большую часть которой составляют лекции различных профессоров / ресерчеров.
Для меня это возможность научиться чему-то новому, набрать побольше материала для собственного курса по рексису, понетворкаться, а также потусить целую неделю в Вене :)
Что интересного было в первый день:
1. Dietmar Jannach, один из самых цитируемых ученых в RecSys, выступил с вводной лекцией про рекомендательные системы: про их ценность, алгоритмы, оценку качества. С такой лекцией он выступает уже не первый раз, презентации прошлых лет есть в открытом доступе.
Приводил много разных фактов про пользу рексистем. Например, (1) 35% выручки Амазона атрибуцируется рексистемам, (2) а в Нетфликсе говорят, что с помощью персонализации и рексистем “экономят” больше миллиарда долларов в год.
Интересно было послушать и про историческое развитие области:
* в 1992 году в статье Using collaborative filtering to weave an information tapestry впервые был упомянут термин “Collaborative Filtering”
* в 1994 появился первый кейс индустриальной рексистемы (GroupLens, рекомендация новостей), статья GroupLens: an open architecture for collaborative filtering of netnews
* в 2003 Амазон опубликовал статью про Item-to-Item Collaborative Filtering
* потом состоялся небезызвестный Netflix prize (2006 — 2009), в рамках которого Нетфликс выложил самый большой на тот момент рекомендательный датасет с пользовательскими рейтингами фильмов. Про это есть хороший рассказ от CPO Нетфликса на рексисе в 2014 году (тык)
* позже от задачи предсказания рейтингов перешли к learning-to-rank парадигме, стали использовать implicit feedback (время просмотра, клики и тд). Активно использовали матричную факторизацию
* сейчас царит deep learning, про использование которого в рексистемах ваш покорный слуга аж четыре лекции в ШАДе в прошлом учебном году читал, и в этом планирует прочитать еще больше :)
Ссылался на большое количество хороших статей (ссылки можно найти в презентации). Жаловался, что ресерчеры тюнят гиперпараметры только для своих моделей, а для бейзлайнов не тюнят. Что нечестно фиксировать одинаковую небольшую размерность выходных эмбеддингов для обычной матричной факторизации (с обучаемыми векторами пользователей и айтемов) и нейросетей, так как у матричной факторизации становится сильно меньше параметров при уменьшении размерности эмбеддингов.
Упоминал beyond accuracy метрики (статья Beyond accuracy: evaluating recommender systems by coverage and serendipity).
Fun fact: в какой-то момент Dietmar занимался рексистемой для премиальных кубинских сигар =)
2. Barry Smyth (h-index 85!) выступил с рассказом по мотивам статьи People Who Liked This Also Liked ... A Publication Analysis of Three Decades of Recommender Systems Research, в которой приводится аналитика по всем RecSys публикациям за ближайшие 30 лет. Также он немного дополнил рассказ про историю рексистем, показал статью аж 1990 года от Jussi Karlgren под названием An Algebra for Recommendations, в которой уже говорится про моделирование пользовательского поведения и предсказание будущего пользователей. Еще показал очень красивое издание Communications of the ACM 1997-го года, special issue on recommender systems (картинку прикладываю).
Получилось, что за последние 30 лет появилось порядка 50к статей про рекомендательные системы.
А сегодня, во второй день школы, были лекции по психологии, графовым нейронным сетям, а также про оффлайн оценку качества рексистем. Но про это расскажу чуть позже :)
Forwarded from Information Retriever
Best Practices for Offline Evaluation.
Под оффлайн-оценкой качества рекомендаций подразумевается типичный для ресерча процесс (присутствует в 87% RecSys’23 статей), когда мы берем датасет с пользовательским фидбеком, сплитим на train/valid/test, замеряем метрики на тесте.
Ниже идет моя вольная интерпретация лекции от Lien Michiels на RecSys Summer School:
1. Большая часть ресерч статей — это “мы увеличили ndcg / recall на датасете X на 0.0Y% и побили SOTA”. Этим улучшениям нет доверия. По ходу школы неоднократно шутили, что если бы можно было просуммировать зарепорченные приросты из всех статей, побивших соту, то мы бы давно вышли за верхние границы метрик. Есть непаханое поле для более осознанного ресерча — задайте stakeholder’ов (например, кроме пользователей это могут быть content creator’ы, сама платформа), сформулируйте реалистичный objective (e.g., хотим не только поднять точность для пользователей, но и поднять exposure по content creator’ам).
2. Запускайте эксперименты несколько раз (с зафиксированными сидами), выкладывайте весь код — не только код метода, но и код запуска экспериментов, включая бейзлайны; и даже код тюнинга гиперпараметров.
3. Используйте публичные датасеты, при этом выбирайте наиболее большие и свежие.
4. Очень популярна n-core фильтрация, когда из датасета фильтруются все пользователи и айтемы с менее чем n взаимодействиями. Не нужно делать ее просто так; повторение за другими статьями — не обоснование.
5. Не используйте совсем рандомные дата сплиты (это лик).
6. Всегда перезапускайте бейзлайны (на своих машинках), не копируйте результаты из других статей.
7. Используйте сильные бейзлайны. Например, в статьях часто используют BPRMF (матричная факторизация с BPR-лоссом), а EASE — редко . А метрики у него выше :)
8. Используйте beyond accuracy метрики — например, coverage (насколько ваш алгоритм своими рекомендациями покрывает весь каталог; для кандгена актуально); время работы алгоритма.
9. Нужно тюнить все модели (и все гиперпараметры), а не только свои. Включая бейзлайны!
10. Считайте метрики без сэмплирования негативов.
11. Зачастую, если пофильтровать из рекомендаций то, что у пользователя в истории уже встречалось, можно поднять метрики. Это нормально, но если так делаете — нужно явно писать (сейчас часто не пишут).
С некоторыми моментами на лекции я не совсем согласен, и поэтому про большую часть из них выше ничего не писал:
1. На лекции говорилось, что в некоторых ситуациях отсутствие таймсплита для эвала — это нормально. Что это зависит от домена (например, в музыке таймсплит менее необходим чем в новостях), и что иногда для таймсплита недостаточно данных. Я считаю что тайм сплит нужен абсолютно всегда, даже в доменах типа музыки. Еще был кусочек про user split, что если в тест и трейн класть непересекающихся пользователей, то будем проверять strong generalization. Это совсем не соответствует сценарию реального применения.
2. Также было сказано, что если все-таки сэмплируете негативы для метрик, то надо сэмплировать их пропорционально популярности (а не равномерно). Это тоже не соотвествует сценарию применения.
3. В качестве примера хорошей метрики приводился ndcg (на сэмплированных айтемах / индексе). Но он ничего информативного не измеряет. Если вы обучаете модель для стадии отбора кандидатов, то нужно смотреть на полноту (Recall@K), причем с большими значениями K. Если для ранжирования — надо замеряться не против случайных айтемов, а против других показанных в той же выдаче объектов (impression’ов). По крайней мере, так делают все в индустрии, и это хорошо работает.
4. С тюнингом размерности эмбеддингов тоже не совсем согласен — в зависимости от сценария применения это может быть не целесообразно. Например, если вы пересчитываете векторы пользователей в оффлайне и загружаете в key-value storage, то у вас есть ограничения по памяти. На практике для одной модели редко когда можно хранить больше 100-1000 квантизованных флотов на пользователя.
И прикладываю пару фотографий с этого дня школы :)
Под оффлайн-оценкой качества рекомендаций подразумевается типичный для ресерча процесс (присутствует в 87% RecSys’23 статей), когда мы берем датасет с пользовательским фидбеком, сплитим на train/valid/test, замеряем метрики на тесте.
Ниже идет моя вольная интерпретация лекции от Lien Michiels на RecSys Summer School:
1. Большая часть ресерч статей — это “мы увеличили ndcg / recall на датасете X на 0.0Y% и побили SOTA”. Этим улучшениям нет доверия. По ходу школы неоднократно шутили, что если бы можно было просуммировать зарепорченные приросты из всех статей, побивших соту, то мы бы давно вышли за верхние границы метрик. Есть непаханое поле для более осознанного ресерча — задайте stakeholder’ов (например, кроме пользователей это могут быть content creator’ы, сама платформа), сформулируйте реалистичный objective (e.g., хотим не только поднять точность для пользователей, но и поднять exposure по content creator’ам).
2. Запускайте эксперименты несколько раз (с зафиксированными сидами), выкладывайте весь код — не только код метода, но и код запуска экспериментов, включая бейзлайны; и даже код тюнинга гиперпараметров.
3. Используйте публичные датасеты, при этом выбирайте наиболее большие и свежие.
4. Очень популярна n-core фильтрация, когда из датасета фильтруются все пользователи и айтемы с менее чем n взаимодействиями. Не нужно делать ее просто так; повторение за другими статьями — не обоснование.
5. Не используйте совсем рандомные дата сплиты (это лик).
6. Всегда перезапускайте бейзлайны (на своих машинках), не копируйте результаты из других статей.
7. Используйте сильные бейзлайны. Например, в статьях часто используют BPRMF (матричная факторизация с BPR-лоссом), а EASE — редко . А метрики у него выше :)
8. Используйте beyond accuracy метрики — например, coverage (насколько ваш алгоритм своими рекомендациями покрывает весь каталог; для кандгена актуально); время работы алгоритма.
9. Нужно тюнить все модели (и все гиперпараметры), а не только свои. Включая бейзлайны!
10. Считайте метрики без сэмплирования негативов.
11. Зачастую, если пофильтровать из рекомендаций то, что у пользователя в истории уже встречалось, можно поднять метрики. Это нормально, но если так делаете — нужно явно писать (сейчас часто не пишут).
С некоторыми моментами на лекции я не совсем согласен, и поэтому про большую часть из них выше ничего не писал:
1. На лекции говорилось, что в некоторых ситуациях отсутствие таймсплита для эвала — это нормально. Что это зависит от домена (например, в музыке таймсплит менее необходим чем в новостях), и что иногда для таймсплита недостаточно данных. Я считаю что тайм сплит нужен абсолютно всегда, даже в доменах типа музыки. Еще был кусочек про user split, что если в тест и трейн класть непересекающихся пользователей, то будем проверять strong generalization. Это совсем не соответствует сценарию реального применения.
2. Также было сказано, что если все-таки сэмплируете негативы для метрик, то надо сэмплировать их пропорционально популярности (а не равномерно). Это тоже не соотвествует сценарию применения.
3. В качестве примера хорошей метрики приводился ndcg (на сэмплированных айтемах / индексе). Но он ничего информативного не измеряет. Если вы обучаете модель для стадии отбора кандидатов, то нужно смотреть на полноту (Recall@K), причем с большими значениями K. Если для ранжирования — надо замеряться не против случайных айтемов, а против других показанных в той же выдаче объектов (impression’ов). По крайней мере, так делают все в индустрии, и это хорошо работает.
4. С тюнингом размерности эмбеддингов тоже не совсем согласен — в зависимости от сценария применения это может быть не целесообразно. Например, если вы пересчитываете векторы пользователей в оффлайне и загружаете в key-value storage, то у вас есть ограничения по памяти. На практике для одной модели редко когда можно хранить больше 100-1000 квантизованных флотов на пользователя.
И прикладываю пару фотографий с этого дня школы :)
Forwarded from Information Retriever
Deep RecSys Course.
Вчера прошло первое занятие нашего Deep RecSys курса в Вышке!
Материалы выкладываются на гитхаб, а видеозаписи занятий — на ютуб, как и обещал :)
Собственно, рассказывал доработанную (в)водную лекцию, слайды которой уже выкладывал на канале. Информационная перегрузка, тяжёлые хвосты, технофеодализм, коллаборативная фильтрация, матричная факторизация, bitter lesson, scaling hypothesis — вот это всё :)
А на семинаре Артём Матвеев показывал различные метрики и обработку данных на Ямбде.
P.S: уже даже до ютуба моё блогерское дело дошло, жесть... ))
Вчера прошло первое занятие нашего Deep RecSys курса в Вышке!
Материалы выкладываются на гитхаб, а видеозаписи занятий — на ютуб, как и обещал :)
Собственно, рассказывал доработанную (в)водную лекцию, слайды которой уже выкладывал на канале. Информационная перегрузка, тяжёлые хвосты, технофеодализм, коллаборативная фильтрация, матричная факторизация, bitter lesson, scaling hypothesis — вот это всё :)
А на семинаре Артём Матвеев показывал различные метрики и обработку данных на Ямбде.
P.S: уже даже до ютуба моё блогерское дело дошло, жесть... ))
Forwarded from Information Retriever
Deep RecSys Course, второе занятие.
1. На лекции поговорили про ML дизайн рекомендательных систем и немного про мой опыт работы в R&D. В своё время я придумывал формат последней итерации собеседования по рекомендательным системам в Яндексе, и при подготовке лекции мне этот опыт очень пригодился. В общем, думаю, что получился неплохой начальный материал для подготовки к ML дизайн рексис собеседованию в бигтех. Пользуйтесь :)
2. На семинаре Владимир Байкалов @ducks_recs рассказывал про классические алгоритмы рекомендаций, с которыми можно сравнивать нейросети. И показывал для этих алгоритмов результаты на датасете Yambda. Заодно обсудили ошибки подсчета метрик в Ямбде — например, при подсчете Recall@K часто забывают, что нужно делить не на количество позитивов, а на
Записи занятия уже на ютубе — и лекция, и семинар. В этот раз принёс свой микрофон, поэтому на лекции звук чуть получше. Материалы — на Github (пока только лекция, но семинар тоже скоро выложим).
И ещё поделюсь отдельно парой ссылок с лекции:
1. Много полезной информации про дизайн рексистем есть на канале Миши @WazowskiRecommends. В лекции не раз ссылаюсь — на посты про счётчики, эмбеддинги, Mixigen
2. У Саввы Степурина есть два хороших наглядных доклада про ML дизайн рексистем — рассказ про стек Яндекс Музыки и про рекомендации незнакомого
3. На RecSys 2020 был туториал про feature engineering от Nvidia
4. У VK есть два хороших рассказа про item-to-item рекомендации — про внедрение item-to-item схемы от Дмитрия Шишова и про её улучшение от Андрея Зимовнова
P.S: уже преодолели отметку в 100 часов суммарного просмотра курса на ютубе!
1. На лекции поговорили про ML дизайн рекомендательных систем и немного про мой опыт работы в R&D. В своё время я придумывал формат последней итерации собеседования по рекомендательным системам в Яндексе, и при подготовке лекции мне этот опыт очень пригодился. В общем, думаю, что получился неплохой начальный материал для подготовки к ML дизайн рексис собеседованию в бигтех. Пользуйтесь :)
2. На семинаре Владимир Байкалов @ducks_recs рассказывал про классические алгоритмы рекомендаций, с которыми можно сравнивать нейросети. И показывал для этих алгоритмов результаты на датасете Yambda. Заодно обсудили ошибки подсчета метрик в Ямбде — например, при подсчете Recall@K часто забывают, что нужно делить не на количество позитивов, а на
min{количество позитивов, K}. Я такое видел и в метриках соревнований, и в статьях. А чтобы узнать багу при подсчете nDCG — смотрите семинар :)Записи занятия уже на ютубе — и лекция, и семинар. В этот раз принёс свой микрофон, поэтому на лекции звук чуть получше. Материалы — на Github (пока только лекция, но семинар тоже скоро выложим).
И ещё поделюсь отдельно парой ссылок с лекции:
1. Много полезной информации про дизайн рексистем есть на канале Миши @WazowskiRecommends. В лекции не раз ссылаюсь — на посты про счётчики, эмбеддинги, Mixigen
2. У Саввы Степурина есть два хороших наглядных доклада про ML дизайн рексистем — рассказ про стек Яндекс Музыки и про рекомендации незнакомого
3. На RecSys 2020 был туториал про feature engineering от Nvidia
4. У VK есть два хороших рассказа про item-to-item рекомендации — про внедрение item-to-item схемы от Дмитрия Шишова и про её улучшение от Андрея Зимовнова
P.S: уже преодолели отметку в 100 часов суммарного просмотра курса на ютубе!
Forwarded from Agentic World
Недавно я писал, что хочу полностью пересобрать свой рабочий процесс. У меня почти получилось, я наконец-то дособрал и дотолкал до своего прода AI-ассистента, который работает по голосовухам.
Раскрыл все детали и процесс в статье на хабре, если у вас есть плюсики - буду им очень рад 🤗
Писать код голосовухами через тг - это невероятно круто 🤖🫡
https://habr.com/ru/articles/994454/
Раскрыл все детали и процесс в статье на хабре, если у вас есть плюсики - буду им очень рад 🤗
Писать код голосовухами через тг - это невероятно круто 🤖🫡
https://habr.com/ru/articles/994454/
Хабр
Как я делаю своего голосового AI-ассистента: роботы пишут код и работают, когда я отдыхаю
В этой статье я открою капот своей системы, которая по голосовухе в телеграме сразу делает новые фичи на живых проектах. С появлением LLM я безоговорочно верил в то, что голос станет следующим важным...
#prompt
A cool way to use ChatGPT: "Socratic prompting"
This week I ran into a couple of threads on Twitter about something called "Socratic prompting".
At first I thought, meh.
But my curiosity was piqued.
I looked up the paper they were talking about.
I read it.
And I tried it.
And it is pretty cool.
I’ll tell you.
Normally we use ChatGPT as if it were a shitty intern.
"Write me a post about productivity."
"Make me a marketing strategy."
"Analyze these data."
And the AI does it.
But it does it fast and without much thought.
Socratic prompting is different.
Instead of giving it instructions, you ask questions.
And that changes how it processes the answer.
Here is an example so you can see it clearly.
Normal prompt:
What it gives you, something correct but a bit bland.
Socratic prompt:
What it gives you, something that thought before writing.
The difference is quite noticeable.
Why does it work?
Because language models were trained on millions of examples of people reasoning. On Reddit and sites like that.
When you ask questions, you activate that reasoning mode.
When you give direct orders, it goes on autopilot.
Another example.
Normal prompt:
Socratic prompt:
In the second case you force it to think the problem through before solving it.
The basic structure is this:
1. First you ask something theoretical:
Three questions and then the task.
That simple.
Another example I liked from the thread:
Basically you are telling it, think like an expert, and then act.
I have been using it for a few days and I really notice the difference.
The output is more polished.
P.S. This works especially well for strategic or creative tasks.
If you ask it to summarize a PDF, you will likely not notice much difference.
But for thinking, it works.
A cool way to use ChatGPT: "Socratic prompting"
This week I ran into a couple of threads on Twitter about something called "Socratic prompting".
At first I thought, meh.
But my curiosity was piqued.
I looked up the paper they were talking about.
I read it.
And I tried it.
And it is pretty cool.
I’ll tell you.
Normally we use ChatGPT as if it were a shitty intern.
"Write me a post about productivity."
"Make me a marketing strategy."
"Analyze these data."
And the AI does it.
But it does it fast and without much thought.
Socratic prompting is different.
Instead of giving it instructions, you ask questions.
And that changes how it processes the answer.
Here is an example so you can see it clearly.
Normal prompt:
"Write me a value proposition for my analytics tool."
What it gives you, something correct but a bit bland.
Socratic prompt:
"What makes a value proposition attractive to someone who buys software for their company? What needs to hit emotionally and logically? Okay, now apply that to an AI analytics tool."
What it gives you, something that thought before writing.
The difference is quite noticeable.
Why does it work?
Because language models were trained on millions of examples of people reasoning. On Reddit and sites like that.
When you ask questions, you activate that reasoning mode.
When you give direct orders, it goes on autopilot.
Another example.
Normal prompt:
"Make me a content calendar for LinkedIn."
Socratic prompt:
"What type of content works best on LinkedIn for B2B companies? How often should you post so you do not tire people? How should topics connect to each other so it makes sense? Okay, now with all that, design a 30-day calendar."
In the second case you force it to think the problem through before solving it.
The basic structure is this:
1. First you ask something theoretical:
"What makes this type of thing work well."
2. Then you ask about the framework: "What principles apply here."
3. And finally you ask it to apply it: "Now do it for my case."
Three questions and then the task.
That simple.
Another example I liked from the thread:
"What would someone very good at growth marketing ask before setting up a sales funnel? What data would they need? What assumptions would they have to validate first? Okay, now answer that for my business and then design the funnel."
Basically you are telling it, think like an expert, and then act.
I have been using it for a few days and I really notice the difference.
The output is more polished.
P.S. This works especially well for strategic or creative tasks.
If you ask it to summarize a PDF, you will likely not notice much difference.
But for thinking, it works.
Forwarded from Love. Death. Transformers.
Если вы готовитесь к собесу в норм место вам будет полезно почитать
https://djdumpling.github.io/2026/01/31/frontier_training.html
https://djdumpling.github.io/2026/01/31/frontier_training.html
Alex Wa’s Blog
frontier model training methodologies
How do labs train a frontier, multi-billion parameter model? We look towards seven open-weight frontier models: Hugging Face’s SmolLM3, Prime Intellect’s Intellect 3, Nous Research’s Hermes 4, OpenAI’s gpt-oss-120b, Moonshot’s Kimi K2, DeepSeek’s DeepSeek…
Forwarded from ML Baldini • Nikita Boyandin (Nikita Boyandin)
Подготовка к секции MLSD💃
Для многих, кто в первых раз идет на интервью middle/senior ml, секция ml system design может показаться чем-то сложным и не понятным. Не переживайте, при качественной подготовке, вы получить не интервью в привычном понимании, а прикольный кейс, который проверит ваш опыт, знание инфраструктуры, подходы к решению мл задачи, но все-таки для этого у вас должен быть фундамент.
1️⃣ Разбейте весь системный дизайн по этапам
Тут для меня 9 шагов: постановка бизнес проблемы(тут вы должны получить как можно больше информации от интервьера), метрики, компоненты архитектуры(MVP логика), хранение данные и ее подготовка, Feature Engineering, разработка модели и оффлайн тестирование, Prediction Service, онлайн тестирование и деплой, мониторинг и улучшения. Подбирайте для себя структуру до собеседования, чтобы не отвечать на лету.
2️⃣ Проработаете каждую задачу мл отдельно
Кажется, что проектов и доменов достаточно много, но большенство из них можно описать внутри этих задач: рекомендательная система, поиск, ранговая система, NLP(чат-боты) и CV(OCR). Редко ваша задача будет другой и я советую подготовить каждую из них.
3️⃣ Поучите метрики, аб тесты
В mlsd есть несколько тем, которые нужно доучить специально в mlsd: онлайн-метрики, аб тесты и неплохо еще знать uplift-моделирование. Это поможет вас выделить из толпы.
4️⃣ Подготовке пару кейсов по инфраструктуре
Вам нужно понимать не только мл модель, но и как она будет функционировать на проде, а значит вы должны знать, что такое kuber, docker, s3, kafka и так далее.
5️⃣ Всегда думайте, как вы сможете улучшить ваше решение
В конце интервью вас спросят, а как же вы улучшите вашу систему. Варианта два: либо вы говорите о системе заведомо чуть меньше, а потом упоминаете об этом, либо говорите о данных или инференсе, которые всегда можно улучшить
6️⃣ Проводите перекрестное мок-интервью
Попросите кого то из друзей придумать кейс и с вами его решить и отвалидировать, так вам сразу будут видны ваши пробелы и вы сможете их закрыть перед собесом
7️⃣ Чем больше правильных вопросов вы сможете задать, чем проще вам будет проходить интервью
Важно на первом этапе задать как можно больше вопросов про бизнес задачу и саму систему, потому что дальше хорошим тоном для команды будет то, что вы будете сами рассказывать все решение без их помощи.
Обзательно перед собесом обязательно посмотрите кейсы, которыми занимается команда, часто именно их будут задавать и вы будете уже готовы💃
💗 - если хоть раз проходил секцию mlsd
Для многих, кто в первых раз идет на интервью middle/senior ml, секция ml system design может показаться чем-то сложным и не понятным. Не переживайте, при качественной подготовке, вы получить не интервью в привычном понимании, а прикольный кейс, который проверит ваш опыт, знание инфраструктуры, подходы к решению мл задачи, но все-таки для этого у вас должен быть фундамент.
Тут для меня 9 шагов: постановка бизнес проблемы(тут вы должны получить как можно больше информации от интервьера), метрики, компоненты архитектуры(MVP логика), хранение данные и ее подготовка, Feature Engineering, разработка модели и оффлайн тестирование, Prediction Service, онлайн тестирование и деплой, мониторинг и улучшения. Подбирайте для себя структуру до собеседования, чтобы не отвечать на лету.
Кажется, что проектов и доменов достаточно много, но большенство из них можно описать внутри этих задач: рекомендательная система, поиск, ранговая система, NLP(чат-боты) и CV(OCR). Редко ваша задача будет другой и я советую подготовить каждую из них.
В mlsd есть несколько тем, которые нужно доучить специально в mlsd: онлайн-метрики, аб тесты и неплохо еще знать uplift-моделирование. Это поможет вас выделить из толпы.
Вам нужно понимать не только мл модель, но и как она будет функционировать на проде, а значит вы должны знать, что такое kuber, docker, s3, kafka и так далее.
В конце интервью вас спросят, а как же вы улучшите вашу систему. Варианта два: либо вы говорите о системе заведомо чуть меньше, а потом упоминаете об этом, либо говорите о данных или инференсе, которые всегда можно улучшить
Попросите кого то из друзей придумать кейс и с вами его решить и отвалидировать, так вам сразу будут видны ваши пробелы и вы сможете их закрыть перед собесом
Важно на первом этапе задать как можно больше вопросов про бизнес задачу и саму систему, потому что дальше хорошим тоном для команды будет то, что вы будете сами рассказывать все решение без их помощи.
Обзательно перед собесом обязательно посмотрите кейсы, которыми занимается команда, часто именно их будут задавать и вы будете уже готовы
Please open Telegram to view this post
VIEW IN TELEGRAM
Telegram
ML Baldini • Nikita Boyandin
Uplift-моделирование📈
⬅️Еще одна неочевидная вещь, которую могут спросить на заключительных собеседованиях, или вести к ней через вопросы и дискуссии. По хорошему, после хакатона по построению моделей оттока клиента, я должен был себя спросить, а зачем…
⬅️Еще одна неочевидная вещь, которую могут спросить на заключительных собеседованиях, или вести к ней через вопросы и дискуссии. По хорошему, после хакатона по построению моделей оттока клиента, я должен был себя спросить, а зачем…