Большая и маленькая ложь на конференциях
Смотрела я раньше доклады по ML на конференциях и думала "офигеть, ребята умные сложные вещи делают". Но где эта грань между технологическим пиаром команды и желанием честно поделиться тем, что реально работает?? Оказывается, разница иногда огромная. Поделюсь забавной историей.

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

Через пару месяцев я чисто случайно узнаю, как реально выглядела их работа. Итак, было плохое качество модели в определенном домене, надо было поднимать. Первым шагом, они действительно перепробовали кучу разных подходов и крутили разные сетки всей своей большой командой. Но, воз и ныне там... Что они после этого сделали? Забили на модели и пошли улучшать данные - тупо взяли и сделали большую качественную разметку этого нового домена. И вот он результат - метрики выросли.? Именно данные подняли качество, модели вторичны. Было ли про это хоть что-то в докладе? Вообще, ни слова.

Да, ребята по-прежнему молодцы, вопросов нет. Но во внешний мир показали только "гламурный" ML. Выбор кстати абсолютно правильный - то, что надо для пиара компании, привлечения кандидатов и пр.

Мораль простая:
1. Доклады - это выборка необычного и редкого, а не популярного и общепринятого. Никто не будет делать доклад про подход, который и так все знают.
Доклады - это полезно и они расширяют кругозор. Но не надо думать, что более простые вещи вдруг перестали работать. Просто про них не рассказывают.

1. Ну и классика: Everybody lies.

#mlops
Code-base vs model-base подходы к деплою моделей

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

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

Эти два взгляда порождают два разных подхода к деплою моделей. Разберём плюсы и минусы каждого.

? Model-base ?
Модель ~~где-то как-то~~ обучилась, в результате появились артефакты - например, веса модели. В прод деплоятся сами артефакты.

Плюсы:
- Простота для data scientist-ов.
- Быстрое создание proof-of-concept.
- Единственный выход для моделей, обучение которых тяжело или дорого воспроизводить. Например, тяжелые нейронки.

Минусы:
- Регулярное обновление модели невозможно или полностью зависит от человеческого фактора.
- Код обучения модели может легко потеряться или стать неактуальным. Нельзя покрыть тестами.

? Code-base ?****
Деплоится код обучения модели. Модель обучается в production среде.

Плюсы:
- Автоматическое переобучение безопаснее, так как перед деплоем код обучения проходит ревью и тесты.
- Код обучения и код инференса проходят тестирование на соответствие.

Минусы:
- Требует гораздо больше времени и знаний от data scientist-а.

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

#мои_истории
Самосбывающийся прогноз, или как сделать бесполезную модель

Что обычно чувствуешь, когда сталкиваешься с чужими моделями в качестве обычного пользователя? Восторг, интерес, бывает и разочарование... а иногда полную ненависть)) Такой случай произошел и со мной. Эта история о том, как алгоритм признал меня злостным нарушителем и мошенником ?. Кроме того, это полезная иллюстрация частой ошибки разработчиков модели, которую разберём в конце.

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

"Наш алгоритм классифицировал ваши действия как мошеннические" - сказали мне. И что еще прекрасней: никакую заявку на пересмотр отправить нельзя. Даже нельзя открыть новую сим-карту, так как их алгоритм блокирует сразу всего человека. Короче, я пожизненно в черном списке без возможности пересмотра. ?

Наверно, не разрабатывай я сама ML алгоритмы, я бы могла поверить, что это просто мне одной не повезло, а вот всех остальных он правильно опознал. Но, нет, это полная чушь. ?‍♀ Давайте посмотрим на это глазами разработчиков и поймём, что нужно было сделать по-другому.

? В чем главная проблема? Здесь на лицо самосбывающийся прогноз. Это когда предсказания заранее обречены на успех, не зависимо от качества модели. Здесь получается: что бы модель ни предсказала, она всегда права. Ложные срабатывания никак не собираются! При этом DS-отдел будет отчитываться об отличном результате: по всем метрикам качество модели растет, она ловит больше мошенников.

Как правильно?
1. Всегда помнить, что никакая модель не работает с качеством 100%. Поэтому нужно заранее озаботиться тем, как будут собираться ошибки модели. Можно показывать любые улучшения в качестве на подготовленных датасетах, но если они не подкреплены реальными данными - это просто какие-то цифры.

В простом случае ошибки модели можно собирать через лайки/дизлайки или добавить комментарии с обратной связью.

1. Оценить цену ошибки в случае ложного срабатывания модели. Если потенциальные потери большие - потеря клиента, большой негатив и тд - можно и нужно оставлять ручную валидацию жалоб людьми. Да, ML - это про автоматизацию. Но в задачах с большой ценой ошибок тандем алгоритм+человек гораздо лучше справляется.

PS проблема с сим-картой решилась быстро переходом к другому оператору. Там видимо DS-ы обучают модели лучше ?

#ml_system_design
Давненько я не выходила на связь и пора прерывать это уныние? Вообще иногда бывает, что сильная занятость или затянувшаяся болезнь мешает написать какой-то полезный текст. Тогда думаешь, что можно написать что-то формальное, типа вот вышел новый релиз библиотеки или выкатили новую модель... Но блин, это освещается в очень многих каналах, короче вы и без меня об этом узнаете. Кстати, если у вас есть любые вопросы/своя история, которую можно разобрать на канале (конечно, анонимно) про работу или трудоустройство, связанное с машинным обучением, то всегда welcome, пишите под постом или мне в личку.

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

1. Человеческий фактор ?‍?
Изначально почему-то выбрали какой-то сложный алгоритм, не сравнивая с более простыми.
Например, проводятся 100 экспериментов с разными гиперпараметрами для нейронной сети и 1 эксперимент для простого алгоритма, например, линейной модели. Это прям очень распространенная ситуация! ? Особенно касается любых усложнений модели. Например, мне попадался градиентный бустинг, который состоял из 40 000(!) деревьев и обучался сутки на относительно небольшом объеме данных. Он без потери в качестве уменьшался до 1000 деревьев, просто при других гиперпараметрах. И вообще, почти как везде, гораздо больше решал фиче инжиниринг.

? Универсальное правило: любое усложнение в модели (неважно в поддержке кода, работе в проде и тд) должно иметь обоснование в качестве при честном сравнении с более простыми моделями.

2. Trade-off ?
Вообще не стоит забывать, что любая метрика не коррелирует с качеством работы модели в проде на 100%. Причин много, в том числе выбор датасета не всегда может совпадать с реальными данными или банально отставать. Некоторые метрики, типа f1-меры или NDCG, это в любом случае приблизительная попытка оценить качество. Также, помимо офлайн-метрик, могут быть другие факторы:
- как часто нужно переобучать эту модель,
- наличие интерпретируемости,
- необходимость разработки от других команд,
- возможность в будущем поддержать планы по развитию модели/улучшению данных,
- и другое.
Оценивание модели по метрике на датасете - хорошее решение для соревнований и научных статей. В реальных проектах помимо метрик нужно учитывать все возможные факторы.

? Короткие советы:
- Полезно проводить "рефакторинг" работающих моделей и упрощать их логику, там где это возможно.
- Начинать лучше с простых моделей. Но простые не значит примитивные. LightGBM проще KNN. Или BERT из Hugging Face - простое решение для старта во многих задачах.
- "Лучшее враг хорошему". Не надо усложнять там, где этого не просят.

#мои_истории
Как исправлять модель, если на нее прилетают штучные жалобы, или почему метрики - это не то, что убеждает людей

Казалось бы, непреложная истина в том, что метрики - это основной показатель качества модели. Улучшили метрику - модель стала лучше. На самом деле, в бизнесе далеко не всегда метрики модели жёстко связаны с прибылью. Говоря проще: цифры цифрами, но "вот здесь предсказания модели лучше бы были такими", "почему вы мне рекомендуете это, а не это?", "давайте доработаем модель, чтобы такое не показывалось".?

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

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

Но скоро происходит интересное... Выясняется, что какая-то журналистка из Москвы хотела взять ипотеку на квартиру премиум сегмента?, но мы посчитали ее стоимость завышенной. Она связалась с руководством банка, чуть ли не угрожает написать в СМИ о том, как плохо работает оценка квартир - в общем поднялась шумиха?. Меня попросили как можно быстрее доработать модель, чтобы таких повторных случаев не было. В общем, как это часто бывает, не все ошибки модели одинаково важны. ?‍♀

Но, вернёмся к модели. После небольшого анализа стало понятно, что таких дорогих квартир меньше 0.1% в данных, они лежат в хвосте распределения, поэтому предсказания по ним немного занижаются. Немного... но для цены квартир каждый процент важен. Что важно, их так мало, что мы могли улучшить общую метрику в ущерб качества на этих объектах!

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

? Собственно, что я сделала. Я просто использовала параметр weights при обучении модели и сделала большие веса у объектов из дорогого сегмента. Получилось за пару строк кода полностью решить проблему! При этом на остальные предсказания эффект был минимальным, так как этих примеров даже с весами было очень мало от общего числа.

Мораль:
1. Веса у объектов - это не только инструмент для балансировки классов. Ему можно находить разные применения для корректировки предсказаний?.

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

#собеседования
Тестовые задания на собеседованиях в ML

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

Давайте разберемся, почему часто это НЕ ТАК и как обстоят дела на самом деле.

Представьте ситуацию. Кандидат откликнулся на вакансию, в ответ получает добродушное ? письмо от рекрутера в стиле "Вы нам очень понравились, у нас первый этап отбора - сделать домашнее тестовое задание. Я отправила вам его по почте".

Что может подумать кандидат? ? "Вакансия очень интересная, вот сейчас я сделаю качественно тестовое, и они поймут, что я им подхожу. Они же специально сделали тестовое посложнее, чтобы найти кандидата, кто сделает качественно и сможет выделиться!" ? Кандидат уходит в тестовое с головой на несколько дней. После пары бессонных ночей и потраченных выходных решение отправлено. Что дальше?

Как показывает практика, вероятность получить оффер в этой компании никак не вырастает. Почему так происходит?

1. Часто компании дают тестовые не всем, а только кандидатам, по которым изначально есть сомнения. ?

При таком сценарии вообще получается, что наличие тестового уменьшает вероятность оффера.

1. У тестовых обычно нет четких критериев успеха. На что смотрит компания и на что тратит время кандидат может вообще не совпадать.

Говоря проще, кандидат много времени тратит впустую. ⏳

1. Иногда тестовые - это просто способ компании бесплатно собрать идей по новой задаче. ?

Например, меня так одна компания очень мотивировала деньгами сделать тестовое. У них была задача один в один, как на моем прошлом месте работы.

1. Тестовое никак не упрощает прохождение следующих этапов. Иногда это просто не самый "гуманный" способ первичного скрининга. ?

2. Большое тестовое задание - это просто не очень уважительно по отношению к времени кандидата.

Чаще всего приводят аргумент, что тестовые - это лучший способ понять, как человек будет решать задачи/писать код в реальных условиях. ? Но, во-первых, иногда хочется спросить, а вы видели свой "эталонный" код у вас в компании, чтобы бояться его испортить каким-то кандидатом? ? А, во-вторых, для этого как раз есть технические собеседования.

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

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

2. Не ожидайте, что реальная работа в этой компании совпадет с интересным тестовым заданием. Если только вам это не сказали явно.

3. Выполнение тестового задания в качестве первого этапа отбора редко приводит к офферу.

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

Пример совсем плохого тестового задания: сделать предсказания для временного ряда из 200 объектов или по датасету с полностью анонимными фичами.

1. ❗️Самое главное - если вы всё-таки решили делать большое тестовое задание, публикуйте потом его на GitHub. Так, эта работа точно не уйдет в стол и вы сможете добавить его в резюме.

#мои_истории
Про алгоритмическую торговлю

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

В этом посте поделюсь своими мыслями насчет этой отрасли и своими впечатлениями после работы в хедж-фонде.

Итак, после большого количества откликов и собесов длительностью года полтора, у меня был оффер в компанию, где мне предстояло разрабатывать алгоритмические торговые стратегии. Радости не было предела. ?

Как же все оказалось на самом деле? Сама работа выглядит крайне прозаично: ты отчаянно пытаешься найти хоть какую-то закономерность в данных, которые наоборот почти полностью случайны. Ты пытаешься снова, и кажется, уже вот эта идея точно рабочая! Но смотришь доходность стратегии - метрики не дотягивают до порога. ? Начинаешь все с начала.

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

Это как раз то, что потом меня долго удивляло, когда я перешла в обычный ML. Как спокойно люди вешают ярлык "задачу не получится решить", "все решают таким способом, значит и я буду так делать".

Почему я всё-таки решила закончить с алготрейдингом и уйти в машинное обучение? Причин много, назову основные:

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

2. Компании, занимающиеся алготрейдингом, зачастую какие-то анти-человеческие. ?
   Вот примеры из моей практики собесов.
   - Серое оформление/оформление с маленьким окладом, вся зп в премии. Читай: если на рынке неудачный месяц, зп не получишь.
   - Работа с 9 до 9, культ переработок.
   - Странные, непрогнозируемые собеседования с кучей брейнтизеров.

Да, все меняется от места к месту, но высококонкурентная сфера порождает соответствующее отношение к сотрудникам.

1. Самое главное, непонятно, что дальше потом с этим опытом делать. ? Компаний в этой отрасли немного, они все специфичные. Зарплаты, если где-то и выше, чем у ML-специалистов, то несильно и выгораешь там быстро.

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