Почему ML-метрика сама по себе почти ничего не говорит бизнесу 📊
Когда начинаешь изучать машинное обучение, кажется, что качество модели можно описать одной красивой цифрой. Accuracy 0.92, ROC-AUC 0.87, F1-score 0.74, и вроде бы сразу понятно, хорошая модель или плохая. Но в реальных проектах эта логика быстро ломается, потому что бизнесу нужна не сама метрика, а изменение в процессе: меньше ручной работы, больше выручки, ниже отток или выше конверсия.
Например, команда строит модель, которая должна предсказывать клиентов с высоким риском оттока. После обучения модель показывает ROC-AUC 0.86. На первый взгляд результат хороший, метрика высокая, графики красивые, эксперимент можно считать успешным. Но дальше появляется главный вопрос: что именно бизнес будет делать с этим предсказанием? Если ответа нет, модель остаётся техническим артефактом, а не инструментом принятия решений.
Представим, что модель каждый день формирует список клиентов, которые могут уйти. Сразу появляются вопросы, без которых оценить пользу невозможно:
📌 Сколько клиентов попадёт в список риска?
📌 Кто будет с ними работать: менеджер, CRM-система или автоматическая рассылка?
📌 Какое действие будет выполнено: звонок, скидка или персональное предложение?
📌 Сколько стоит это действие для компании?
📌 Как мы поймём, что клиент остался именно из-за этого действия?
📌 Что хуже для бизнеса: пропустить клиента, который действительно уйдёт, или потратить деньги на удержание клиента, который остался бы без вмешательства?
Именно здесь становится видно, что ML-метрика и бизнес-метрика отвечают на разные вопросы. ML-метрика показывает, насколько хорошо модель решает формальную задачу на данных. Бизнес-метрика показывает, изменилось ли что-то важное в реальной системе: снизился ли отток, выросла ли выручка, сократилось ли время обработки.
Очень часто проблема возникает не в самой модели, а в разрыве между предсказанием и действием. Модель может хорошо предсказывать вероятность покупки, но если маркетинг не использует эти прогнозы в рассылках, сегментации или персональных предложениях, бизнес-эффект будет равен нулю. Модель может находить подозрительные операции, но если служба контроля не успевает их обрабатывать, точность алгоритма не спасёт процесс.
Поэтому перед запуском ML-модели важно описать не только качество алгоритма, но и процесс, в который он будет встроен. Для этого полезно ответить на несколько вопросов:
📌 Какое решение будет приниматься на основе предсказания?
📌 Кто будет принимать это решение?
📌 Что изменится в текущем бизнес-процессе после появления модели?
📌 Какая метрика должна измениться, если модель действительно полезна?
📌 Как мы отделим эффект модели от других факторов?
📌 Что произойдёт, если модель ошибётся?
📌 Сколько стоят разные типы ошибок?
Например, в задаче оттока модель может ранжировать клиентов по вероятности ухода, но бизнесу всё равно нужно выбрать порог, после которого клиент попадёт в кампанию удержания. Если порог слишком низкий, компания начнёт тратить деньги на тех, кто не нуждался в удержании. Если порог слишком высокий, часть клиентов уйдёт без попытки вмешательства. Поэтому выбор порога зависит не только от модели, но и от экономики процесса, стоимости контакта и ограничений команды.
То же самое происходит в задачах классификации заявок, скоринга, антифрода, рекомендаций и прогнозирования спроса. Хорошая модель в ноутбуке ещё не означает хорошее решение для бизнеса. Если предсказание не приводит к действию, действие не встроено в процесс, а стоимость ошибок не посчитана, то даже высокая ML-метрика может не дать практической пользы.
Главный вывод простой: качество модели нужно оценивать не только через ML-метрики, но и через изменение бизнес-системы, в которую эта модель встраивается. Метрика отвечает на вопрос, насколько хорошо алгоритм решает формальную задачу. Бизнес-эффект отвечает на другой вопрос, стало ли компании, пользователю или команде действительно лучше.
Когда начинаешь изучать машинное обучение, кажется, что качество модели можно описать одной красивой цифрой. Accuracy 0.92, ROC-AUC 0.87, F1-score 0.74, и вроде бы сразу понятно, хорошая модель или плохая. Но в реальных проектах эта логика быстро ломается, потому что бизнесу нужна не сама метрика, а изменение в процессе: меньше ручной работы, больше выручки, ниже отток или выше конверсия.
Например, команда строит модель, которая должна предсказывать клиентов с высоким риском оттока. После обучения модель показывает ROC-AUC 0.86. На первый взгляд результат хороший, метрика высокая, графики красивые, эксперимент можно считать успешным. Но дальше появляется главный вопрос: что именно бизнес будет делать с этим предсказанием? Если ответа нет, модель остаётся техническим артефактом, а не инструментом принятия решений.
Представим, что модель каждый день формирует список клиентов, которые могут уйти. Сразу появляются вопросы, без которых оценить пользу невозможно:
📌 Сколько клиентов попадёт в список риска?
📌 Кто будет с ними работать: менеджер, CRM-система или автоматическая рассылка?
📌 Какое действие будет выполнено: звонок, скидка или персональное предложение?
📌 Сколько стоит это действие для компании?
📌 Как мы поймём, что клиент остался именно из-за этого действия?
📌 Что хуже для бизнеса: пропустить клиента, который действительно уйдёт, или потратить деньги на удержание клиента, который остался бы без вмешательства?
Именно здесь становится видно, что ML-метрика и бизнес-метрика отвечают на разные вопросы. ML-метрика показывает, насколько хорошо модель решает формальную задачу на данных. Бизнес-метрика показывает, изменилось ли что-то важное в реальной системе: снизился ли отток, выросла ли выручка, сократилось ли время обработки.
Очень часто проблема возникает не в самой модели, а в разрыве между предсказанием и действием. Модель может хорошо предсказывать вероятность покупки, но если маркетинг не использует эти прогнозы в рассылках, сегментации или персональных предложениях, бизнес-эффект будет равен нулю. Модель может находить подозрительные операции, но если служба контроля не успевает их обрабатывать, точность алгоритма не спасёт процесс.
Поэтому перед запуском ML-модели важно описать не только качество алгоритма, но и процесс, в который он будет встроен. Для этого полезно ответить на несколько вопросов:
📌 Какое решение будет приниматься на основе предсказания?
📌 Кто будет принимать это решение?
📌 Что изменится в текущем бизнес-процессе после появления модели?
📌 Какая метрика должна измениться, если модель действительно полезна?
📌 Как мы отделим эффект модели от других факторов?
📌 Что произойдёт, если модель ошибётся?
📌 Сколько стоят разные типы ошибок?
Например, в задаче оттока модель может ранжировать клиентов по вероятности ухода, но бизнесу всё равно нужно выбрать порог, после которого клиент попадёт в кампанию удержания. Если порог слишком низкий, компания начнёт тратить деньги на тех, кто не нуждался в удержании. Если порог слишком высокий, часть клиентов уйдёт без попытки вмешательства. Поэтому выбор порога зависит не только от модели, но и от экономики процесса, стоимости контакта и ограничений команды.
То же самое происходит в задачах классификации заявок, скоринга, антифрода, рекомендаций и прогнозирования спроса. Хорошая модель в ноутбуке ещё не означает хорошее решение для бизнеса. Если предсказание не приводит к действию, действие не встроено в процесс, а стоимость ошибок не посчитана, то даже высокая ML-метрика может не дать практической пользы.
Главный вывод простой: качество модели нужно оценивать не только через ML-метрики, но и через изменение бизнес-системы, в которую эта модель встраивается. Метрика отвечает на вопрос, насколько хорошо алгоритм решает формальную задачу. Бизнес-эффект отвечает на другой вопрос, стало ли компании, пользователю или команде действительно лучше.
🔥3❤2👍1👏1😁1🤓1👀1
Самые дорогие стратегические ошибки в карьере. Часть 5.
Бояться говорить о повышении зарплаты. 💰
Когда я только начинал работать, мне казалось, что повышение зарплаты должно происходить как-то само собой. Ты хорошо работаешь, приносишь пользу, руководитель это замечает, потом зовёт тебя на встречу и говорит: «Мы решили поднять тебе зарплату». Очень красивая картина мира.
Проблема в том, что в реальности так бывает не всегда. И дело не обязательно в том, что руководитель плохой или жадный. Часто всё проще: не все сотрудники вообще хотят расти. Кому-то комфортно на текущей позиции, кому-то важнее стабильность, кому-то не хочется брать больше ответственности. Поэтому руководитель не всегда может автоматически понять, что именно вас интересует вертикальный рост, новая роль и пересмотр зарплаты.
Именно поэтому о повышении нужно говорить. Не в формате «дайте больше денег, потому что хочется», а в формате взрослого разговора о траектории: я хочу расти, хочу понимать, что для этого нужно, какие ожидания у компании, какие результаты и зоны ответственности должны появиться, чтобы мы могли вернуться к вопросу повышения. Это не попрошайничество. Это нормальная рабочая коммуникация.🔼
Мне кажется, повышение часто не является подарком за хорошее поведение.🎁 В большинстве случаев компания начинает покупать у вас что-то дополнительное: больше автономности, больше ответственности, способность вести сложные задачи без постоянного контроля, наставничество, владение частью системы. Зарплата растёт не просто потому, что вы стали дольше работать в компании, а потому что изменилась ваша роль.
Если вас повышают, а обязанности вообще никак не изменились, возможны два варианта. Либо вы работаете в очень приятной компании со зрелой индексацией, либо в момент найма вас немного продавили по зарплате, а теперь просто возвращают ближе к рынку.🌝
Самое интересное, что даже если после разговора повышения не будет, сам разговор всё равно полезен. Вы можете собрать фактуру: что сейчас мешает повышению, какие ожидания не закрыты, какие результаты нужно показать, какие зоны ответственности взять и когда можно вернуться к обсуждению. Иногда после такой встречи появляется понятный чек-лист на ближайшие месяцы. Это уже намного лучше, чем просто ждать.
Прозрачность почти всегда лучше тумана. Когда у вас есть фактура, дальше возможны три сценария: вы выполняете договорённости и получаете повышение, получаете ясную траекторию до повышения, или понимаете, что повышать вас здесь никто не собирается. Последний вариант неприятный, но он экономит месяцы ожидания.
Я правда не считаю руководителей врагами сотрудников. Большинство хороших руководителей, которых я встречал, искренне радуются, когда могут повысить человека. Но руководитель не обязан угадывать вашу карьерную стратегию. В какой-то момент вы сами переводите разговор из плоскости «я просто выполняю задачи» в плоскость «давай обсудим траекторию моего роста».🎯
Именно поэтому я считаю, что одна из дорогих стратегических ошибок в карьере, бояться говорить о повышении зарплаты. Если вы хотите расти, об этом нужно говорить. Если хотите больше денег, нужно понимать, какую дополнительную ценность компания должна начать у вас покупать. За вас вашим успехом никто заниматься не будет. И это не жестокость мира, а просто взрослая реальность. 💻
Бояться говорить о повышении зарплаты. 💰
Когда я только начинал работать, мне казалось, что повышение зарплаты должно происходить как-то само собой. Ты хорошо работаешь, приносишь пользу, руководитель это замечает, потом зовёт тебя на встречу и говорит: «Мы решили поднять тебе зарплату». Очень красивая картина мира.
Проблема в том, что в реальности так бывает не всегда. И дело не обязательно в том, что руководитель плохой или жадный. Часто всё проще: не все сотрудники вообще хотят расти. Кому-то комфортно на текущей позиции, кому-то важнее стабильность, кому-то не хочется брать больше ответственности. Поэтому руководитель не всегда может автоматически понять, что именно вас интересует вертикальный рост, новая роль и пересмотр зарплаты.
Именно поэтому о повышении нужно говорить. Не в формате «дайте больше денег, потому что хочется», а в формате взрослого разговора о траектории: я хочу расти, хочу понимать, что для этого нужно, какие ожидания у компании, какие результаты и зоны ответственности должны появиться, чтобы мы могли вернуться к вопросу повышения. Это не попрошайничество. Это нормальная рабочая коммуникация.
Мне кажется, повышение часто не является подарком за хорошее поведение.
Если вас повышают, а обязанности вообще никак не изменились, возможны два варианта. Либо вы работаете в очень приятной компании со зрелой индексацией, либо в момент найма вас немного продавили по зарплате, а теперь просто возвращают ближе к рынку.
Самое интересное, что даже если после разговора повышения не будет, сам разговор всё равно полезен. Вы можете собрать фактуру: что сейчас мешает повышению, какие ожидания не закрыты, какие результаты нужно показать, какие зоны ответственности взять и когда можно вернуться к обсуждению. Иногда после такой встречи появляется понятный чек-лист на ближайшие месяцы. Это уже намного лучше, чем просто ждать.
Прозрачность почти всегда лучше тумана. Когда у вас есть фактура, дальше возможны три сценария: вы выполняете договорённости и получаете повышение, получаете ясную траекторию до повышения, или понимаете, что повышать вас здесь никто не собирается. Последний вариант неприятный, но он экономит месяцы ожидания.
Я правда не считаю руководителей врагами сотрудников. Большинство хороших руководителей, которых я встречал, искренне радуются, когда могут повысить человека. Но руководитель не обязан угадывать вашу карьерную стратегию. В какой-то момент вы сами переводите разговор из плоскости «я просто выполняю задачи» в плоскость «давай обсудим траекторию моего роста».
Именно поэтому я считаю, что одна из дорогих стратегических ошибок в карьере, бояться говорить о повышении зарплаты. Если вы хотите расти, об этом нужно говорить. Если хотите больше денег, нужно понимать, какую дополнительную ценность компания должна начать у вас покупать. За вас вашим успехом никто заниматься не будет. И это не жестокость мира, а просто взрослая реальность. 💻
Please open Telegram to view this post
VIEW IN TELEGRAM
❤2👍2🔥1😁1🤓1
Вопрос с ML-собеса: когда accuracy вообще бесполезна 😭
Есть классический вопрос, который выглядит максимально школьно, но на собесах всё ещё отлично показывает, человек понимает метрики или просто где-то видел model.score(X_test, y_test). Вопрос примерно такой: у нас есть модель для поиска мошеннических операций, accuracy 99%, хорошая модель или нет?
И вот тут начинается веселье, потому что очень хочется сказать: 99%, ну нормально же, почти идеально. Только потом оказывается, что мошеннических операций в данных 1%, а обычных 99%. И модель, которая всегда говорит «операция нормальная», тоже получит accuracy 99%. Вообще ничего не нашла, бизнесу не помогла, мошенников пропустила, зато метрика красивая, можно в презентацию вставлять и идти пить кофе 🤡
Проблема accuracy в том, что она плохо работает на сильном дисбалансе классов. Она отвечает на вопрос, сколько объектов мы угадали в среднем, но не показывает, какие именно ошибки мы делаем. А в реальности ошибки почти никогда не стоят одинаково. Пропустить мошенническую операцию и случайно отправить нормальную операцию на ручную проверку, это две совершенно разные истории по деньгам, рискам и клиентскому опыту.
Нормальный ответ на собесе я бы строил так. Сначала нужно посмотреть на распределение классов, потом отдельно оценить precision и recall для важного класса, потом понять бизнес-стоимость ошибок. Если нам важно поймать как можно больше мошенничества, мы будем смотреть в сторону recall. Если нам важно не завалить службу контроля ложными срабатываниями, будет важен precision. А дальше всё равно придётся выбирать порог, потому что модель обычно выдаёт вероятность, а не готовое божественное решение с небес.😔
Самое смешное, что это касается не только антифрода. В оттоке клиентов та же боль. В медицинской диагностике та же боль. В модерации контента та же боль. В задачах найма, скоринга, рекомендаций, алертов, где важный класс встречается редко, accuracy часто превращается в очень красивую, но почти бесполезную цифру.
Поэтому если на собесе вас спрашивают про accuracy, скорее всего, от вас хотят услышать не определение из учебника, а нормальное инженерное рассуждение: какой баланс классов, какие типы ошибок, сколько они стоят, какая метрика ближе к бизнес-задаче, как выбирать порог и что будет происходить после предсказания модели.
Если коротко: метрика не бывает хорошей сама по себе. Она хорошая только тогда, когда соответствует задаче, данным и цене ошибок. И если модель с accuracy 99% ничего не ловит, то это не сильная модель, а очень уверенный генератор самообмана.😜
Есть классический вопрос, который выглядит максимально школьно, но на собесах всё ещё отлично показывает, человек понимает метрики или просто где-то видел model.score(X_test, y_test). Вопрос примерно такой: у нас есть модель для поиска мошеннических операций, accuracy 99%, хорошая модель или нет?
И вот тут начинается веселье, потому что очень хочется сказать: 99%, ну нормально же, почти идеально. Только потом оказывается, что мошеннических операций в данных 1%, а обычных 99%. И модель, которая всегда говорит «операция нормальная», тоже получит accuracy 99%. Вообще ничего не нашла, бизнесу не помогла, мошенников пропустила, зато метрика красивая, можно в презентацию вставлять и идти пить кофе 🤡
Проблема accuracy в том, что она плохо работает на сильном дисбалансе классов. Она отвечает на вопрос, сколько объектов мы угадали в среднем, но не показывает, какие именно ошибки мы делаем. А в реальности ошибки почти никогда не стоят одинаково. Пропустить мошенническую операцию и случайно отправить нормальную операцию на ручную проверку, это две совершенно разные истории по деньгам, рискам и клиентскому опыту.
Нормальный ответ на собесе я бы строил так. Сначала нужно посмотреть на распределение классов, потом отдельно оценить precision и recall для важного класса, потом понять бизнес-стоимость ошибок. Если нам важно поймать как можно больше мошенничества, мы будем смотреть в сторону recall. Если нам важно не завалить службу контроля ложными срабатываниями, будет важен precision. А дальше всё равно придётся выбирать порог, потому что модель обычно выдаёт вероятность, а не готовое божественное решение с небес.
Самое смешное, что это касается не только антифрода. В оттоке клиентов та же боль. В медицинской диагностике та же боль. В модерации контента та же боль. В задачах найма, скоринга, рекомендаций, алертов, где важный класс встречается редко, accuracy часто превращается в очень красивую, но почти бесполезную цифру.
Поэтому если на собесе вас спрашивают про accuracy, скорее всего, от вас хотят услышать не определение из учебника, а нормальное инженерное рассуждение: какой баланс классов, какие типы ошибок, сколько они стоят, какая метрика ближе к бизнес-задаче, как выбирать порог и что будет происходить после предсказания модели.
Если коротко: метрика не бывает хорошей сама по себе. Она хорошая только тогда, когда соответствует задаче, данным и цене ошибок. И если модель с accuracy 99% ничего не ловит, то это не сильная модель, а очень уверенный генератор самообмана.
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥3🤓3❤2😁1
Как понять, что задачу вообще стоит решать с помощью ML 🧠
Когда в компании появляется идея использовать машинное обучение, очень легко сразу перейти к обсуждению моделей. Какой алгоритм взять, какие признаки добавить, какую метрику оптимизировать, где хранить эмбеддинги, нужен ли CatBoost, нейросеть или LLM. Но сильная ML-задача начинается не с модели. Она начинается с проверки, есть ли здесь вообще повторяемая проблема, данные, бизнес-действие и понятный способ измерить результат.
Представьте запрос: «Давайте предсказывать, какие клиенты скоро уйдут». На первый взгляд звучит как нормальная ML-задача. Но перед разработкой модели нужно задать несколько вопросов, иначе команда рискует сделать технически аккуратное решение, которое не изменит бизнес-процесс.
📌 Есть ли повторяемое решение? Если каждый случай уникален и требует ручного экспертного разбора, модель может оказаться слабым инструментом. ML особенно полезен там, где есть много похожих объектов, повторяющиеся решения и закономерности, которые можно извлечь из данных.
📌 Есть ли данные о прошлом? Чтобы предсказывать отток, нужно понимать, кто ушёл раньше, какие признаки были известны до ухода, какие действия компания предпринимала и что произошло после. Если данные неполные, размечены задним числом или содержат утечки, модель может показать хорошую метрику в эксперименте, но плохо работать в реальности.
📌 Что изменится после предсказания? Это один из самых важных вопросов. Если модель нашла клиента с высоким риском оттока, что произойдёт дальше: звонок менеджера, скидка, персональное письмо, изменение тарифа, передача в отдельный сегмент. Если на предсказание не завязано действие, оно не создаёт ценности.
📌 Можно ли измерить эффект? Недостаточно сказать, что модель должна быть точной. Нужно заранее понять, какая бизнес-метрика должна измениться: отток, выручка, конверсия, время обработки, количество ручных проверок, стоимость ошибки. Иначе команда будет спорить о ROC-AUC, хотя бизнесу важно совсем другое.
📌 Сколько стоят ошибки? В одних задачах страшнее пропустить проблемный объект, в других страшнее ошибочно пометить нормальный объект как проблемный. Например, в антифроде пропущенная мошенническая операция может стоить денег, а ложная блокировка может испортить клиентский опыт. Поэтому выбор метрики и порога должен зависеть не только от математики, но и от экономики процесса.
Хороший признак, что ML здесь действительно уместен: у команды есть повторяемая задача, достаточно данных, понятное действие после предсказания, измеримая бизнес-метрика и понимание стоимости ошибок. Если хотя бы одного элемента нет, это не значит, что модель точно не нужна. Но это значит, что сначала нужно доработать постановку задачи.
Главный вывод простой: ML не должен быть способом сделать задачу более модной. Он должен быть способом улучшить конкретное решение внутри конкретного процесса. Поэтому перед вопросом «какую модель обучать» почти всегда должен идти другой вопрос: «что изменится в бизнесе, если модель окажется права».
Когда в компании появляется идея использовать машинное обучение, очень легко сразу перейти к обсуждению моделей. Какой алгоритм взять, какие признаки добавить, какую метрику оптимизировать, где хранить эмбеддинги, нужен ли CatBoost, нейросеть или LLM. Но сильная ML-задача начинается не с модели. Она начинается с проверки, есть ли здесь вообще повторяемая проблема, данные, бизнес-действие и понятный способ измерить результат.
Представьте запрос: «Давайте предсказывать, какие клиенты скоро уйдут». На первый взгляд звучит как нормальная ML-задача. Но перед разработкой модели нужно задать несколько вопросов, иначе команда рискует сделать технически аккуратное решение, которое не изменит бизнес-процесс.
📌 Есть ли повторяемое решение? Если каждый случай уникален и требует ручного экспертного разбора, модель может оказаться слабым инструментом. ML особенно полезен там, где есть много похожих объектов, повторяющиеся решения и закономерности, которые можно извлечь из данных.
📌 Есть ли данные о прошлом? Чтобы предсказывать отток, нужно понимать, кто ушёл раньше, какие признаки были известны до ухода, какие действия компания предпринимала и что произошло после. Если данные неполные, размечены задним числом или содержат утечки, модель может показать хорошую метрику в эксперименте, но плохо работать в реальности.
📌 Что изменится после предсказания? Это один из самых важных вопросов. Если модель нашла клиента с высоким риском оттока, что произойдёт дальше: звонок менеджера, скидка, персональное письмо, изменение тарифа, передача в отдельный сегмент. Если на предсказание не завязано действие, оно не создаёт ценности.
📌 Можно ли измерить эффект? Недостаточно сказать, что модель должна быть точной. Нужно заранее понять, какая бизнес-метрика должна измениться: отток, выручка, конверсия, время обработки, количество ручных проверок, стоимость ошибки. Иначе команда будет спорить о ROC-AUC, хотя бизнесу важно совсем другое.
📌 Сколько стоят ошибки? В одних задачах страшнее пропустить проблемный объект, в других страшнее ошибочно пометить нормальный объект как проблемный. Например, в антифроде пропущенная мошенническая операция может стоить денег, а ложная блокировка может испортить клиентский опыт. Поэтому выбор метрики и порога должен зависеть не только от математики, но и от экономики процесса.
Хороший признак, что ML здесь действительно уместен: у команды есть повторяемая задача, достаточно данных, понятное действие после предсказания, измеримая бизнес-метрика и понимание стоимости ошибок. Если хотя бы одного элемента нет, это не значит, что модель точно не нужна. Но это значит, что сначала нужно доработать постановку задачи.
Главный вывод простой: ML не должен быть способом сделать задачу более модной. Он должен быть способом улучшить конкретное решение внутри конкретного процесса. Поэтому перед вопросом «какую модель обучать» почти всегда должен идти другой вопрос: «что изменится в бизнесе, если модель окажется права».
😁2👏1💩1
Почему в ML-задаче важно заранее договориться о критериях успеха 🧠
Одна из частых проблем в ML-проектах возникает не во время обучения модели, а намного раньше, когда команда не договорилась, что именно будет считаться успехом. Все вроде бы понимают задачу одинаково: нужно предсказывать отток, находить мошенничество, рекомендовать товары, классифицировать заявки или прогнозировать спрос. Но когда модель готова, внезапно оказывается, что у участников проекта были разные ожидания.
Data Scientist смотрит на ROC-AUC и считает, что результат хороший. Бизнес смотрит на количество обработанных клиентов и не понимает, почему эффект не виден. Операционная команда говорит, что не успевает разбирать все срабатывания. Продакт спрашивает, как это повлияло на конверсию. В итоге спор начинается не потому, что модель обязательно плохая, а потому что критерии успеха не были проговорены заранее.
Перед началом ML-задачи полезно договориться минимум о нескольких вещах:
📌 Какая бизнес-проблема решается? Не «обучить модель оттока», а «снизить отток платящих клиентов в течение месяца» или «уменьшить количество ручных проверок без роста ошибок».
📌 Какое действие будет выполняться после предсказания? Модель сама по себе не создаёт ценность. Ценность появляется, когда её предсказание меняет процесс: клиент получает предложение, заявка уходит на ручную проверку, товар попадает в рекомендацию, менеджер получает приоритетный список.
📌 Какая метрика будет основной? Важно заранее понять, что оптимизируем: recall, precision, F1, ROC-AUC, прибыль, снижение времени обработки, уменьшение числа ошибок или другую бизнес-метрику. Без этого команда может улучшать технический показатель, который не помогает реальному процессу.
📌 Какие ограничения есть у процесса? Например, служба контроля может обработать только 500 алертов в день, менеджеры могут позвонить только 1000 клиентам в неделю, а ложная блокировка операции стоит компании репутации. Эти ограничения напрямую влияют на выбор порога и оценку качества.
📌 Что будет считаться достаточным результатом? Не всегда нужна идеальная модель. Иногда достаточно решения, которое на 20% сокращает ручную работу. Иногда нужна очень высокая точность, потому что ошибка дорогая. Это нужно обсуждать до экспериментов, а не после презентации метрик.
Хороший критерий успеха связывает модель, процесс и бизнес-результат. Например: модель считается полезной, если она находит не меньше 70% мошеннических операций при таком количестве ложных срабатываний, которое команда контроля успевает обработать за день. Или: модель оттока считается успешной, если кампания по верхним 10% риска даёт удержание выше контрольной группы и окупает стоимость коммуникации.
Главный вывод простой: ML-задача должна иметь acceptance criteria так же, как обычная продуктовая задача. Команда заранее должна понимать, что именно изменится после запуска, как это будет измеряться, какие ограничения есть у процесса и какой результат считается достаточным. Иначе можно построить хорошую модель, но так и не получить хорошее решение.
Одна из частых проблем в ML-проектах возникает не во время обучения модели, а намного раньше, когда команда не договорилась, что именно будет считаться успехом. Все вроде бы понимают задачу одинаково: нужно предсказывать отток, находить мошенничество, рекомендовать товары, классифицировать заявки или прогнозировать спрос. Но когда модель готова, внезапно оказывается, что у участников проекта были разные ожидания.
Data Scientist смотрит на ROC-AUC и считает, что результат хороший. Бизнес смотрит на количество обработанных клиентов и не понимает, почему эффект не виден. Операционная команда говорит, что не успевает разбирать все срабатывания. Продакт спрашивает, как это повлияло на конверсию. В итоге спор начинается не потому, что модель обязательно плохая, а потому что критерии успеха не были проговорены заранее.
Перед началом ML-задачи полезно договориться минимум о нескольких вещах:
📌 Какая бизнес-проблема решается? Не «обучить модель оттока», а «снизить отток платящих клиентов в течение месяца» или «уменьшить количество ручных проверок без роста ошибок».
📌 Какое действие будет выполняться после предсказания? Модель сама по себе не создаёт ценность. Ценность появляется, когда её предсказание меняет процесс: клиент получает предложение, заявка уходит на ручную проверку, товар попадает в рекомендацию, менеджер получает приоритетный список.
📌 Какая метрика будет основной? Важно заранее понять, что оптимизируем: recall, precision, F1, ROC-AUC, прибыль, снижение времени обработки, уменьшение числа ошибок или другую бизнес-метрику. Без этого команда может улучшать технический показатель, который не помогает реальному процессу.
📌 Какие ограничения есть у процесса? Например, служба контроля может обработать только 500 алертов в день, менеджеры могут позвонить только 1000 клиентам в неделю, а ложная блокировка операции стоит компании репутации. Эти ограничения напрямую влияют на выбор порога и оценку качества.
📌 Что будет считаться достаточным результатом? Не всегда нужна идеальная модель. Иногда достаточно решения, которое на 20% сокращает ручную работу. Иногда нужна очень высокая точность, потому что ошибка дорогая. Это нужно обсуждать до экспериментов, а не после презентации метрик.
Хороший критерий успеха связывает модель, процесс и бизнес-результат. Например: модель считается полезной, если она находит не меньше 70% мошеннических операций при таком количестве ложных срабатываний, которое команда контроля успевает обработать за день. Или: модель оттока считается успешной, если кампания по верхним 10% риска даёт удержание выше контрольной группы и окупает стоимость коммуникации.
Главный вывод простой: ML-задача должна иметь acceptance criteria так же, как обычная продуктовая задача. Команда заранее должна понимать, что именно изменится после запуска, как это будет измеряться, какие ограничения есть у процесса и какой результат считается достаточным. Иначе можно построить хорошую модель, но так и не получить хорошее решение.
💩2👍1🔥1
Самые дорогие стратегические ошибки в карьере. Часть 6
Слишком долго оставаться в работе, которая тебе не подходит.😭
Иногда люди годами держатся за работу, которая их медленно съедает. Им кажется, что руководитель не понимает, что делает. Процессы в компании устроены так, будто их собирали случайным образом. Стратегия выглядит сомнительно. Команда решает не те задачи. А ты вместо своей работы постоянно закрываешь чужие дыры, объясняешь очевидное, воюешь с согласованиями и пытаешься сделать хоть что-то полезное внутри системы, которая этому сопротивляется.
При этом уйти страшно. Страшно потерять стабильную зарплату. Страшно снова проходить собеседования. Страшно обнаружить, что на новом месте будет то же самое. Страшно признать, что несколько лет ты вкладывался не туда. Поэтому человек говорит себе: “Ну, везде есть проблемы”, “надо потерпеть”, “сейчас закончим этот проект, потом станет легче”, “ещё немного опыта наберусь и начну искать”.
Иногда это разумно. В любой компании бывают сложные периоды, слабые процессы и руководители, с которыми непросто работать. Не каждая проблема означает, что нужно немедленно писать заявление. Но есть важная граница. Если тебе разово не нравится задача, это рабочая реальность. Если ты регулярно не веришь в то, что делает компания, не понимаешь смысла своей работы, не можешь влиять на ситуацию и всё чаще ловишь себя на мысли “лишь бы день закончился”, это уже не временная трудность. Это несовпадение. 💩
Оно плохо не только для тебя. Компании тоже не нужен сотрудник, который внутренне уже вышел из игры. Ты начинаешь работать осторожнее, меньше предлагать, не брать ответственность, делать минимум, чтобы не было претензий. Компания получает человека с опытом, но без энергии и доверия к общему направлению. А ты получаешь зарплату в обмен на время, силы и ощущение, что профессионально стоишь на месте. Мне кажется, особенно опасна ситуация, когда ты занимаешься не своей работой. Например, тебя нанимали решать сложные инженерные или аналитические задачи, а большую часть времени ты выбиваешь доступы, собираешь требования по кускам, разруливаешь коммуникацию между людьми, которым до результата нет дела.🤡
Иногда это полезный опыт. Он учит видеть систему целиком и работать с неопределённостью. Но если это становится постоянной моделью, стоит честно спросить себя: я правда развиваюсь в профессии или просто стал удобным человеком, который умеет терпеть хаос?
Менять работу страшно почти всегда. Даже когда у тебя сильное резюме, опыт и нормальные навыки. Потому что текущая зарплата реальна, а следующий оффер пока существует только как гипотеза. Но если у тебя есть опыт, понятная экспертиза и способность решать задачи, рынок чаще всего найдёт на тебя спрос. Возможно, не за одну неделю. Возможно, придётся подготовиться, обновить резюме, пройти несколько неудачных интервью, понять, что именно ты хочешь искать дальше.🎯
Это всё равно лучше, чем годами оставаться там, где ты уже не можешь приносить пользу и сам перестаёшь расти. Уходить стоит не в эмоции и не “от плохого начальника”. Уходить стоит из системного тупика, когда ты понимаешь: я не верю в это направление, не могу нормально делать свою работу, не вижу возможности повлиять на ситуацию и не хочу, чтобы следующие два года выглядели так же.
Работа не обязана быть идеальной. Но она должна давать тебе возможность расти и верить, что твои усилия не уходят в пустоту.
Слишком долго оставаться в работе, которая тебе не подходит.
Иногда люди годами держатся за работу, которая их медленно съедает. Им кажется, что руководитель не понимает, что делает. Процессы в компании устроены так, будто их собирали случайным образом. Стратегия выглядит сомнительно. Команда решает не те задачи. А ты вместо своей работы постоянно закрываешь чужие дыры, объясняешь очевидное, воюешь с согласованиями и пытаешься сделать хоть что-то полезное внутри системы, которая этому сопротивляется.
При этом уйти страшно. Страшно потерять стабильную зарплату. Страшно снова проходить собеседования. Страшно обнаружить, что на новом месте будет то же самое. Страшно признать, что несколько лет ты вкладывался не туда. Поэтому человек говорит себе: “Ну, везде есть проблемы”, “надо потерпеть”, “сейчас закончим этот проект, потом станет легче”, “ещё немного опыта наберусь и начну искать”.
Иногда это разумно. В любой компании бывают сложные периоды, слабые процессы и руководители, с которыми непросто работать. Не каждая проблема означает, что нужно немедленно писать заявление. Но есть важная граница. Если тебе разово не нравится задача, это рабочая реальность. Если ты регулярно не веришь в то, что делает компания, не понимаешь смысла своей работы, не можешь влиять на ситуацию и всё чаще ловишь себя на мысли “лишь бы день закончился”, это уже не временная трудность. Это несовпадение. 💩
Оно плохо не только для тебя. Компании тоже не нужен сотрудник, который внутренне уже вышел из игры. Ты начинаешь работать осторожнее, меньше предлагать, не брать ответственность, делать минимум, чтобы не было претензий. Компания получает человека с опытом, но без энергии и доверия к общему направлению. А ты получаешь зарплату в обмен на время, силы и ощущение, что профессионально стоишь на месте. Мне кажется, особенно опасна ситуация, когда ты занимаешься не своей работой. Например, тебя нанимали решать сложные инженерные или аналитические задачи, а большую часть времени ты выбиваешь доступы, собираешь требования по кускам, разруливаешь коммуникацию между людьми, которым до результата нет дела.
Иногда это полезный опыт. Он учит видеть систему целиком и работать с неопределённостью. Но если это становится постоянной моделью, стоит честно спросить себя: я правда развиваюсь в профессии или просто стал удобным человеком, который умеет терпеть хаос?
Менять работу страшно почти всегда. Даже когда у тебя сильное резюме, опыт и нормальные навыки. Потому что текущая зарплата реальна, а следующий оффер пока существует только как гипотеза. Но если у тебя есть опыт, понятная экспертиза и способность решать задачи, рынок чаще всего найдёт на тебя спрос. Возможно, не за одну неделю. Возможно, придётся подготовиться, обновить резюме, пройти несколько неудачных интервью, понять, что именно ты хочешь искать дальше.🎯
Это всё равно лучше, чем годами оставаться там, где ты уже не можешь приносить пользу и сам перестаёшь расти. Уходить стоит не в эмоции и не “от плохого начальника”. Уходить стоит из системного тупика, когда ты понимаешь: я не верю в это направление, не могу нормально делать свою работу, не вижу возможности повлиять на ситуацию и не хочу, чтобы следующие два года выглядели так же.
Работа не обязана быть идеальной. Но она должна давать тебе возможность расти и верить, что твои усилия не уходят в пустоту.
Please open Telegram to view this post
VIEW IN TELEGRAM
❤3🤔2👍1
Почему блог для меня не медиа, а инфраструктура
Я долго относился к блогу как к чему-то второстепенному. Есть работа, проекты, курсы, консультации, реальные задачи, реальные деньги. А блог где-то сбоку. Написал пост, получил несколько реакций, стало приятно, пошёл дальше заниматься нормальными делами. Но чем больше я думаю про продукты, образование и активы, тем сильнее понимаю одну вещь: блог для меня не медиа. Блог, это инфраструктура.
Медиа в моей голове, это борьба за внимание. Нужно чаще публиковаться, громче формулировать, быстрее реагировать на инфоповоды, собирать просмотры. В этом нет ничего плохого, но это не совсем то, что я хочу строить. Инфраструктура, это другое. 🗻
Это система, через которую постепенно накапливается доверие. Человек читает один пост про карьерную ошибку, потом второй про ML-метрики, потом третий про курсы, потом видит, как я думаю, как ошибаюсь и как принимаю решения. В какой-то момент между нами появляется контекст. Не “вот случайный человек из интернета что-то продаёт”, а “я примерно понимаю, как он мыслит”. 🧠
Когда я делал курсы на чужих платформах, я думал в основном про качество материала. Хорошая программа, понятные объяснения, практика, структура. Казалось, что если продукт хороший, он как-то сам найдёт людей. Потом реальность мягко объяснила, что нет. Можно сделать нормальный продукт, но если у тебя нет канала дистрибуции, аудитории и доверия, продукт может просто лежать на платформе и ждать чуда. А чудо обычно занято другими делами. 📦
И вот здесь блог начинает выглядеть иначе. Это не место, где я “пишу мысли”. Это место, где я строю несколько важных вещей:
• собственный канал дистрибуции 💰
• публичную историю своих решений 💻
• связь с людьми, которым близки мои темы😸
• проверку гипотез через реакцию аудитории 💯
• репутационный капитал 📈
• архив мыслей, к которому можно возвращаться 📦
Самое важное, что блог работает не как разовая консультация. Консультация закончилась, деньги пришли, время ушло. Пост остался. Он может работать через неделю, месяц, год. Его можно отправить человеку, встроить в продукт, превратить в лекцию, использовать как основу для курса или методички. Это и есть разница между часами и активами. Я не хочу романтизировать блог. Сейчас это не большой актив, не бизнес, не машина продаж. Это маленький канал с небольшими цифрами и очень ранней стадией. Но мне нравится сама логика.
Каждый хороший пост, это маленький кирпич в системе. Пост про стратегическую ошибку помогает сформулировать карьерную позицию. Пост про ML-метрики показывает инженерное мышление. Пост про Stepik фиксирует продуктовую ошибку. Пост про отказ от консультаций объясняет, почему я хочу строить масштабируемые продукты. По отдельности это просто тексты. Вместе, это уже контур. 💭
Раньше я думал, что блог нужен, когда у тебя уже есть большой продукт, экспертиза и понятная стратегия. Сейчас мне кажется наоборот. Блог нужен как раз для того, чтобы всё это собрать. Писать, смотреть на реакцию, замечать, какие темы цепляют, какие мысли повторяются, какие вопросы возникают у людей.
Главный вывод для меня такой: если ты хочешь меньше зависеть от обмена времени на деньги, тебе нужна не только экспертиза. Тебе нужна инфраструктура, через которую эта экспертиза доходит до людей. Для меня такой инфраструктурой постепенно становится блог. 📈
Я долго относился к блогу как к чему-то второстепенному. Есть работа, проекты, курсы, консультации, реальные задачи, реальные деньги. А блог где-то сбоку. Написал пост, получил несколько реакций, стало приятно, пошёл дальше заниматься нормальными делами. Но чем больше я думаю про продукты, образование и активы, тем сильнее понимаю одну вещь: блог для меня не медиа. Блог, это инфраструктура.
Медиа в моей голове, это борьба за внимание. Нужно чаще публиковаться, громче формулировать, быстрее реагировать на инфоповоды, собирать просмотры. В этом нет ничего плохого, но это не совсем то, что я хочу строить. Инфраструктура, это другое. 🗻
Это система, через которую постепенно накапливается доверие. Человек читает один пост про карьерную ошибку, потом второй про ML-метрики, потом третий про курсы, потом видит, как я думаю, как ошибаюсь и как принимаю решения. В какой-то момент между нами появляется контекст. Не “вот случайный человек из интернета что-то продаёт”, а “я примерно понимаю, как он мыслит”. 🧠
Когда я делал курсы на чужих платформах, я думал в основном про качество материала. Хорошая программа, понятные объяснения, практика, структура. Казалось, что если продукт хороший, он как-то сам найдёт людей. Потом реальность мягко объяснила, что нет. Можно сделать нормальный продукт, но если у тебя нет канала дистрибуции, аудитории и доверия, продукт может просто лежать на платформе и ждать чуда. А чудо обычно занято другими делами. 📦
И вот здесь блог начинает выглядеть иначе. Это не место, где я “пишу мысли”. Это место, где я строю несколько важных вещей:
• собственный канал дистрибуции 💰
• публичную историю своих решений 💻
• связь с людьми, которым близки мои темы
• проверку гипотез через реакцию аудитории 💯
• репутационный капитал 📈
• архив мыслей, к которому можно возвращаться 📦
Самое важное, что блог работает не как разовая консультация. Консультация закончилась, деньги пришли, время ушло. Пост остался. Он может работать через неделю, месяц, год. Его можно отправить человеку, встроить в продукт, превратить в лекцию, использовать как основу для курса или методички. Это и есть разница между часами и активами. Я не хочу романтизировать блог. Сейчас это не большой актив, не бизнес, не машина продаж. Это маленький канал с небольшими цифрами и очень ранней стадией. Но мне нравится сама логика.
Каждый хороший пост, это маленький кирпич в системе. Пост про стратегическую ошибку помогает сформулировать карьерную позицию. Пост про ML-метрики показывает инженерное мышление. Пост про Stepik фиксирует продуктовую ошибку. Пост про отказ от консультаций объясняет, почему я хочу строить масштабируемые продукты. По отдельности это просто тексты. Вместе, это уже контур. 💭
Раньше я думал, что блог нужен, когда у тебя уже есть большой продукт, экспертиза и понятная стратегия. Сейчас мне кажется наоборот. Блог нужен как раз для того, чтобы всё это собрать. Писать, смотреть на реакцию, замечать, какие темы цепляют, какие мысли повторяются, какие вопросы возникают у людей.
Главный вывод для меня такой: если ты хочешь меньше зависеть от обмена времени на деньги, тебе нужна не только экспертиза. Тебе нужна инфраструктура, через которую эта экспертиза доходит до людей. Для меня такой инфраструктурой постепенно становится блог. 📈
Please open Telegram to view this post
VIEW IN TELEGRAM
👍2🔥2🤓1
Проекты, которые не взлетели. Часть 1.
PDF2LaTeX: мы научили нейронку читать формулы, но не научились продавать результат. 📦
Это один из моих первых серьёзных проектов. Изначально pdf2latex должен был распознавать тексты и формулы в PDF, а затем преобразовывать их в LaTeX. Потом появилась более амбициозная идея: добавить модуль, который переводит в LaTeX и рукописный текст, а дальше продавать решение университетам. У нас был Telegram-бот и работающее ядро. Оно дробило изображение на небольшие блоки, после чего нейронная сеть распознавала символы. Мы научились считывать дроби и интегралы, отличать формулы от изображений и не пытаться распознавать всё подряд как текст.
Для второго курса это было очень круто. И я до сих пор считаю, что сам проект был хорошим. Точность не была идеальной, но у нас уже был не просто слайд с идеей, а прототип, который решал сложную техническую задачу. Но техническая часть не стала бизнесом.
Нас было четыре инженера, и в тот момент мы были довольно слабыми именно как команда. Каждый тянул проект в свою сторону, у нас не было человека, который отвечал бы за продукт, продажи или продвижение. По сути, все четверо имели похожие компетенции. Мы умели строить технологию, но почти не усиливали друг друга в том, чего проекту не хватало. При этом интерес к решению был. Мы нашли две школы и сотрудников университета, которым потенциально был нужен такой софт. Но до сделки дело не дошло: подписка показалась им дорогой.
Сейчас я вижу здесь две возможные причины. Либо проект действительно не создавал для них ценность на заявленную цену. Либо мы не смогли объяснить её нормально: сколько часов ручной работы экономит распознавание, сколько это стоит в деньгах, какие процессы становятся быстрее, почему подписка окупается. Скорее всего, правдой было и то и другое. Мы слишком долго думали про качество распознавания и слишком мало про конкретного покупателя. Кто принимает решение? Как он работает сейчас? Что его раздражает? Сколько стоит текущий процесс? Каким должен быть результат, чтобы он захотел за него платить?
Тогда я этого не понимал. Казалось, что если научиться хорошо распознавать дроби и интегралы, дальше всё как-нибудь сложится. Не сложилось. Главный вывод из pdf2latex для меня такой: технически сложный продукт не становится ценным автоматически. Нужны команда с разными ролями, понятный покупатель и экономика, которую можно объяснить до начала большой разработки.
Это не делает те месяцы потерянными. Я научился собирать ML-прототипы, увидел, как трудно превратить технологию в продукт, и впервые на практике почувствовал разницу между «мы можем это построить» и «за это готовы платить».
PDF2LaTeX: мы научили нейронку читать формулы, но не научились продавать результат. 📦
Это один из моих первых серьёзных проектов. Изначально pdf2latex должен был распознавать тексты и формулы в PDF, а затем преобразовывать их в LaTeX. Потом появилась более амбициозная идея: добавить модуль, который переводит в LaTeX и рукописный текст, а дальше продавать решение университетам. У нас был Telegram-бот и работающее ядро. Оно дробило изображение на небольшие блоки, после чего нейронная сеть распознавала символы. Мы научились считывать дроби и интегралы, отличать формулы от изображений и не пытаться распознавать всё подряд как текст.
Для второго курса это было очень круто. И я до сих пор считаю, что сам проект был хорошим. Точность не была идеальной, но у нас уже был не просто слайд с идеей, а прототип, который решал сложную техническую задачу. Но техническая часть не стала бизнесом.
Нас было четыре инженера, и в тот момент мы были довольно слабыми именно как команда. Каждый тянул проект в свою сторону, у нас не было человека, который отвечал бы за продукт, продажи или продвижение. По сути, все четверо имели похожие компетенции. Мы умели строить технологию, но почти не усиливали друг друга в том, чего проекту не хватало. При этом интерес к решению был. Мы нашли две школы и сотрудников университета, которым потенциально был нужен такой софт. Но до сделки дело не дошло: подписка показалась им дорогой.
Сейчас я вижу здесь две возможные причины. Либо проект действительно не создавал для них ценность на заявленную цену. Либо мы не смогли объяснить её нормально: сколько часов ручной работы экономит распознавание, сколько это стоит в деньгах, какие процессы становятся быстрее, почему подписка окупается. Скорее всего, правдой было и то и другое. Мы слишком долго думали про качество распознавания и слишком мало про конкретного покупателя. Кто принимает решение? Как он работает сейчас? Что его раздражает? Сколько стоит текущий процесс? Каким должен быть результат, чтобы он захотел за него платить?
Тогда я этого не понимал. Казалось, что если научиться хорошо распознавать дроби и интегралы, дальше всё как-нибудь сложится. Не сложилось. Главный вывод из pdf2latex для меня такой: технически сложный продукт не становится ценным автоматически. Нужны команда с разными ролями, понятный покупатель и экономика, которую можно объяснить до начала большой разработки.
Это не делает те месяцы потерянными. Я научился собирать ML-прототипы, увидел, как трудно превратить технологию в продукт, и впервые на практике почувствовал разницу между «мы можем это построить» и «за это готовы платить».
❤2🤔2🤓1
Тут за последнюю неделю появилось много новых людей, поэтому хочу немного понять, кто меня вообще читает 🌝
Чем вы сейчас занимаетесь?
Чем вы сейчас занимаетесь?
Anonymous Poll
58%
🧠 Data Science / ML
29%
📊 Аналитика
21%
💻 Разработка / IT
8%
📦 Product / бизнес
17%
📚 Учусь / пытаюсь войти в IT
8%
🗿 Вообще не из IT
Самые дорогие стратегические ошибки в карьере. Часть 7.
Ждать, пока тебе дадут интересную задачу. 🧭
В начале карьеры это кажется нормальной стратегией. Есть руководитель, есть бэклог, есть задачи. Твоя работа - хорошо делать то, что пришло сверху, а в какой-то момент тебе обязательно дадут что-то интересное, сложное и заметное. Иногда так и происходит. Но если слишком долго жить в этой логике, можно незаметно застрять в роли хорошего исполнителя: надёжного, аккуратного, но полностью зависимого от того, что именно заметит и принесёт руководитель. Проблема в том, что интересные задачи редко лежат готовыми в Jira с понятным названием. Часто они спрятаны в повторяющихся ручных действиях, странных инцидентах, потерянном времени команды, неясных метриках или решениях, которые все откладывают, потому что «и так пока работает». Чтобы их увидеть, нужно смотреть не только на свой список задач, но и на процесс вокруг него. 📜
Например, можно просто разбирать входящие инциденты. А можно заметить, что треть из них возникает по одной и той же причине, собрать фактуру и предложить изменить правило, данные или инструмент. Можно получить задачу на дашборд. А можно сначала понять, какое решение команда не может принять без этого дашборда и не нужна ли ей вообще другая аналитика. Во втором случае работа сложнее: сначала нужно самому сформулировать проблему, а потом ещё доказать, что её стоит решать.
И здесь появляется важная часть взрослой работы - защита инициативы перед руководителем. Ваши часы не бесплатны для компании. Если вы хотите заняться задачей, которой нет в плане, нужно уметь объяснить: какую проблему она снимает, у кого она болит, что изменится после решения, сколько времени или денег это может сэкономить, как проверить эффект и почему сейчас это важнее других задач. Нужно уметь продавать свои решения.💰
Это не означает, что нужно приходить с идеями ради идей или пытаться в одиночку перепридумать стратегию компании. Хорошая инициатива начинается с наблюдения и фактуры, а не с желания сделать что-то «интересное». Иногда после обсуждения окажется, что проблема несущественна, решение слишком дорого или сейчас есть более важный приоритет. Это тоже полезный результат: вы лучше понимаете бизнес и логику выбора задач. Но если такой разговор получается, меняется сама модель отношений с руководителем. Вы перестаёте быть человеком, которому нужно постоянно выдавать работу, и становитесь человеком, который умеет находить точки влияния, оценивать их и предлагать способ сдвинуть проблему. Именно так постепенно появляется доверие к более широким зонам ответственности.📈
Мне кажется, карьерный рост часто начинается не в момент, когда тебе дали большую задачу, а немного раньше - когда ты заметил важную проблему без готовой карточки, сформулировал её и взял на себя ответственность довести разговор до решения. Именно поэтому я считаю, что одна из дорогих стратегических ошибок в карьере - ждать, пока тебе дадут интересную задачу. Интересная работа не всегда приходит сама. Иногда её нужно сначала увидеть, обосновать и создать для неё место в приоритетах команды. 🎯
Ждать, пока тебе дадут интересную задачу. 🧭
В начале карьеры это кажется нормальной стратегией. Есть руководитель, есть бэклог, есть задачи. Твоя работа - хорошо делать то, что пришло сверху, а в какой-то момент тебе обязательно дадут что-то интересное, сложное и заметное. Иногда так и происходит. Но если слишком долго жить в этой логике, можно незаметно застрять в роли хорошего исполнителя: надёжного, аккуратного, но полностью зависимого от того, что именно заметит и принесёт руководитель. Проблема в том, что интересные задачи редко лежат готовыми в Jira с понятным названием. Часто они спрятаны в повторяющихся ручных действиях, странных инцидентах, потерянном времени команды, неясных метриках или решениях, которые все откладывают, потому что «и так пока работает». Чтобы их увидеть, нужно смотреть не только на свой список задач, но и на процесс вокруг него. 📜
Например, можно просто разбирать входящие инциденты. А можно заметить, что треть из них возникает по одной и той же причине, собрать фактуру и предложить изменить правило, данные или инструмент. Можно получить задачу на дашборд. А можно сначала понять, какое решение команда не может принять без этого дашборда и не нужна ли ей вообще другая аналитика. Во втором случае работа сложнее: сначала нужно самому сформулировать проблему, а потом ещё доказать, что её стоит решать.
И здесь появляется важная часть взрослой работы - защита инициативы перед руководителем. Ваши часы не бесплатны для компании. Если вы хотите заняться задачей, которой нет в плане, нужно уметь объяснить: какую проблему она снимает, у кого она болит, что изменится после решения, сколько времени или денег это может сэкономить, как проверить эффект и почему сейчас это важнее других задач. Нужно уметь продавать свои решения.💰
Это не означает, что нужно приходить с идеями ради идей или пытаться в одиночку перепридумать стратегию компании. Хорошая инициатива начинается с наблюдения и фактуры, а не с желания сделать что-то «интересное». Иногда после обсуждения окажется, что проблема несущественна, решение слишком дорого или сейчас есть более важный приоритет. Это тоже полезный результат: вы лучше понимаете бизнес и логику выбора задач. Но если такой разговор получается, меняется сама модель отношений с руководителем. Вы перестаёте быть человеком, которому нужно постоянно выдавать работу, и становитесь человеком, который умеет находить точки влияния, оценивать их и предлагать способ сдвинуть проблему. Именно так постепенно появляется доверие к более широким зонам ответственности.
Мне кажется, карьерный рост часто начинается не в момент, когда тебе дали большую задачу, а немного раньше - когда ты заметил важную проблему без готовой карточки, сформулировал её и взял на себя ответственность довести разговор до решения. Именно поэтому я считаю, что одна из дорогих стратегических ошибок в карьере - ждать, пока тебе дадут интересную задачу. Интересная работа не всегда приходит сама. Иногда её нужно сначала увидеть, обосновать и создать для неё место в приоритетах команды. 🎯
Please open Telegram to view this post
VIEW IN TELEGRAM
❤2🤓2🤔1
Четыре инженера не равны команде продукта. 📦
Когда мы делали pdf2latex, нас было четыре инженера. Мы умели собирать Telegram-ботов, обучать модели, распознавать формулы, работать с изображениями и думать об архитектуре. Для второго курса это казалось почти идеальной командой.
Но потом стало понятно, что четыре инженера не обязательно образуют продуктовую команду. Иногда это просто четыре человека, которые умеют очень хорошо строить технологию.
Для MVP не нужна большая компания и набор формальных должностей. Не обязательно сразу искать отдельного продакта, маркетолога, продавца, дизайнера и руководителя проекта. Но две функции в команде должны быть закрыты с самого начала:
1) человек, который отвечает за технологию и может быстро собрать решение.
2) человек, который отвечает за дистрибуцию: разговаривает с потенциальными пользователями, понимает их проблему, ищет первые каналы привлечения, предлагает продукт и получает обратную связь от рынка.
Это не значит, что в команде обязательно должно быть всего два человека. Один и тот же человек иногда может закрывать несколько функций. Но если никто не отвечает за технологию, нечего проверять. А если никто не отвечает за дистрибуцию, команда очень быстро начинает проверять не рынок, а собственные инженерные фантазии. ⚙️
Я видел много команд, состоящих только из инженеров. Обычно их история развивается похоже. Сначала появляется хорошая идея. Потом команда решает, что перед запуском нужно сделать всё системно: продумать архитектуру, заложить масштабирование, убрать технический долг, предусмотреть редкие сценарии, сделать интерфейс удобнее и добавить ещё одну важную функцию.
Каждое решение по отдельности звучит разумно. Проблема в том, что рынок в этот момент всё ещё не сказал, нужен ли ему продукт вообще. В таком режиме команда может жить очень долго. Пока люди не выгорят. Пока не закончится финансирование. Пока не станет очевидно, что конкуренты уже успели запуститься, поговорить с пользователями, исправить ошибки и сделать решение лучше.🤡
Самое опасное, что это происходит не только с новичками. Я видел зрелые команды из сильных и опытных инженеров, с большими бюджетами и высокими ФОТами. Уровень разработки был действительно серьёзным. Но продукт всё равно месяцами или годами оставался «почти готов». Потому что готовность продукта определяет не команда. Определяет не количество написанного кода, не красивая архитектура, не покрытие тестами и даже не удобство интерфейса, которое инженеры оценили на внутренней демо-встрече. Всё это может быть важно позже. Но на этапе MVP главный вопрос другой: готов ли кто-то регулярно отдавать за ваше решение деньги? 💰
Если рынок голосует рублём, значит продукт уже создаёт ценность, с которой можно работать дальше. Улучшать опыт, убирать ограничения, строить систему, масштабировать продажи. Если не голосует, это не всегда означает, что идея плохая. Возможно, выбран не тот клиент, не та проблема, не та цена или не тот способ донести ценность. Но это означает, что дальнейшая разработка не должна автоматически считаться прогрессом.
Когда мы делали pdf2latex, нас было четыре инженера. Мы умели собирать Telegram-ботов, обучать модели, распознавать формулы, работать с изображениями и думать об архитектуре. Для второго курса это казалось почти идеальной командой.
Но потом стало понятно, что четыре инженера не обязательно образуют продуктовую команду. Иногда это просто четыре человека, которые умеют очень хорошо строить технологию.
Для MVP не нужна большая компания и набор формальных должностей. Не обязательно сразу искать отдельного продакта, маркетолога, продавца, дизайнера и руководителя проекта. Но две функции в команде должны быть закрыты с самого начала:
1) человек, который отвечает за технологию и может быстро собрать решение.
2) человек, который отвечает за дистрибуцию: разговаривает с потенциальными пользователями, понимает их проблему, ищет первые каналы привлечения, предлагает продукт и получает обратную связь от рынка.
Это не значит, что в команде обязательно должно быть всего два человека. Один и тот же человек иногда может закрывать несколько функций. Но если никто не отвечает за технологию, нечего проверять. А если никто не отвечает за дистрибуцию, команда очень быстро начинает проверять не рынок, а собственные инженерные фантазии. ⚙️
Я видел много команд, состоящих только из инженеров. Обычно их история развивается похоже. Сначала появляется хорошая идея. Потом команда решает, что перед запуском нужно сделать всё системно: продумать архитектуру, заложить масштабирование, убрать технический долг, предусмотреть редкие сценарии, сделать интерфейс удобнее и добавить ещё одну важную функцию.
Каждое решение по отдельности звучит разумно. Проблема в том, что рынок в этот момент всё ещё не сказал, нужен ли ему продукт вообще. В таком режиме команда может жить очень долго. Пока люди не выгорят. Пока не закончится финансирование. Пока не станет очевидно, что конкуренты уже успели запуститься, поговорить с пользователями, исправить ошибки и сделать решение лучше.
Самое опасное, что это происходит не только с новичками. Я видел зрелые команды из сильных и опытных инженеров, с большими бюджетами и высокими ФОТами. Уровень разработки был действительно серьёзным. Но продукт всё равно месяцами или годами оставался «почти готов». Потому что готовность продукта определяет не команда. Определяет не количество написанного кода, не красивая архитектура, не покрытие тестами и даже не удобство интерфейса, которое инженеры оценили на внутренней демо-встрече. Всё это может быть важно позже. Но на этапе MVP главный вопрос другой: готов ли кто-то регулярно отдавать за ваше решение деньги? 💰
Если рынок голосует рублём, значит продукт уже создаёт ценность, с которой можно работать дальше. Улучшать опыт, убирать ограничения, строить систему, масштабировать продажи. Если не голосует, это не всегда означает, что идея плохая. Возможно, выбран не тот клиент, не та проблема, не та цена или не тот способ донести ценность. Но это означает, что дальнейшая разработка не должна автоматически считаться прогрессом.
Please open Telegram to view this post
VIEW IN TELEGRAM
👍2🔥2🤓1
«Как работает градиентный бустинг?» Это не вопрос, на котором нужно валить кандидата 💻
На ML-собеседованиях я часто спрашиваю: как работает градиентный бустинг?
Обычно человек начинает уверенно:
> «Это ансамбль деревьев, который последовательно исправляет ошибки предыдущих моделей».
Нормальный ответ. Но если остановиться здесь, невозможно понять, кандидат действительно представляет механизм или просто выучил фразу, которая открывает половину роликов про CatBoost. Поэтому я уточняю:
• Почему бустинг называется градиентным?
• Деревья обучаются одновременно или по очереди?
• Что является таргетом для следующего дерева?
• Что меняется в данных после первого дерева?
И вот здесь нередко заканчивается уверенность. Человек помнит, что бустинг «исправляет ошибки», но не может объяснить, что новое дерево обучается на направлении уменьшения функции потерь, а не просто получает исходный таргет ещё раз. Это не повод ставить крест на кандидате. Не знать внутренности конкретного алгоритма можно, особенно если последние два года ты решал задачи, строил пайплайны, общался с бизнесом и не выводил формулы на доске. Такой пробел реально закрыть за пару вечеров.
Но собеседование нужно не только для проверки списка знаний. Компания пытается понять, за что будет платить деньги и какой риск берёт вместе с кандидатом. Поэтому реакция на незнание иногда важнее, чем сам правильный ответ.
📌 Хорошая реакция:
> «Общую идею понимаю, но сейчас не восстановлю точно, почему используются градиенты и как формируется таргет. Не хочу придумывать. Я бы освежил матчасть».
Такой ответ экономит время всем. Кандидат не продаёт воздух, интервьюер не изображает прокурора, а пробел становится понятным и измеримым. Не знать что-то нормально. Делать вид, что ты знаешь, намного хуже.
🚩 Плохой сценарий начинается с оправданий:
> «А это вообще спрашивают на Senior?»
> «Я с университета математику не трогал».
> «Да все же просто CatBoost вызывают».
Использовать CatBoost, конечно, можно. Но если ты претендуешь на Senior-роль, от тебя покупают не только способность вызвать
На собесе не нужно угадывать каждый ответ. Нужно показать, что, когда ответа нет, ты не начинаешь играть в эксперта. Это часто стоит дороже правильной формулы.
На ML-собеседованиях я часто спрашиваю: как работает градиентный бустинг?
Обычно человек начинает уверенно:
> «Это ансамбль деревьев, который последовательно исправляет ошибки предыдущих моделей».
Нормальный ответ. Но если остановиться здесь, невозможно понять, кандидат действительно представляет механизм или просто выучил фразу, которая открывает половину роликов про CatBoost. Поэтому я уточняю:
• Почему бустинг называется градиентным?
• Деревья обучаются одновременно или по очереди?
• Что является таргетом для следующего дерева?
• Что меняется в данных после первого дерева?
И вот здесь нередко заканчивается уверенность. Человек помнит, что бустинг «исправляет ошибки», но не может объяснить, что новое дерево обучается на направлении уменьшения функции потерь, а не просто получает исходный таргет ещё раз. Это не повод ставить крест на кандидате. Не знать внутренности конкретного алгоритма можно, особенно если последние два года ты решал задачи, строил пайплайны, общался с бизнесом и не выводил формулы на доске. Такой пробел реально закрыть за пару вечеров.
Но собеседование нужно не только для проверки списка знаний. Компания пытается понять, за что будет платить деньги и какой риск берёт вместе с кандидатом. Поэтому реакция на незнание иногда важнее, чем сам правильный ответ.
📌 Хорошая реакция:
> «Общую идею понимаю, но сейчас не восстановлю точно, почему используются градиенты и как формируется таргет. Не хочу придумывать. Я бы освежил матчасть».
Такой ответ экономит время всем. Кандидат не продаёт воздух, интервьюер не изображает прокурора, а пробел становится понятным и измеримым. Не знать что-то нормально. Делать вид, что ты знаешь, намного хуже.
🚩 Плохой сценарий начинается с оправданий:
> «А это вообще спрашивают на Senior?»
> «Я с университета математику не трогал».
> «Да все же просто CatBoost вызывают».
Использовать CatBoost, конечно, можно. Но если ты претендуешь на Senior-роль, от тебя покупают не только способность вызвать
fit(). От тебя покупают способность заметить неизвестное, не скрыть риск за уверенным тоном и быстро разобраться, когда от этого зависит решение. Никто не обязан знать всё, и идеальных собеседований не существует. Но пытаться защитить пробел фразой «это не должны спрашивать» — плохая стратегия. Работодатель не перестанет проверять то, что считает важным, а ты просто отдашь ему сигнал, что с обратной связью может быть тяжело.На собесе не нужно угадывать каждый ответ. Нужно показать, что, когда ответа нет, ты не начинаешь играть в эксперта. Это часто стоит дороже правильной формулы.
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥2❤1👍1🤓1
Что хотелось бы увидеть из сферы ML / DS?
Anonymous Poll
68%
🧠 Вопросы с ML-собеседований
56%
🔍 Разборы ответов кандидатов
56%
⚙️ Реальные кейсы с работы
32%
🧭 Как выбрать направление в ML / DS
44%
🚀 Как перейти в ML из другой профессии
52%
📈 Как расти от Junior до Senior
52%
🏭 Production ML: запуск и мониторинг моделей
64%
🧩 Практические ML-кейсы от задачи до решения
52%
🤖 LLM и AI-инструменты в работе ML-специалиста
Когда новая ответственность становится ростом, а когда это просто бесплатное повышение 💰
«Возьми это направление на себя. Ты хорошо справляешься». Звучит как признание, и иногда это действительно оно. Но иногда компания просто нашла человека, который согласится делать работу следующего грейда, пока получать будет за текущий. Новая ответственность сама по себе не плохая сделка. Она может дать опыт, влияние, сильную строчку в резюме и основание для роста дохода. Проблема начинается, когда предложение оставляют размытым: отвечать нужно за результат, а полномочий, ресурсов и пересмотра условий никто не обещает. 🫠
Например, разработчику предлагают «лидировать техническое направление». В реальности это может означать проводить встречи, согласовывать решения с несколькими командами, разбирать конфликты в приоритетах, онбордить новичков и отвечать за сроки чужой работы. Это уже не просто интересная инженерная задача, а другая роль, у которой должна быть понятная цена. Перед согласием не нужно устраивать торг или ультиматум. Нужно спокойно выяснить условия сделки.
📌 За какой конкретный результат я отвечаю? Не «улучшить процесс», а сократить время запуска моделей, снизить число инцидентов или вывести новую часть продукта к определённой дате.
📌 Какие у меня будут полномочия? Можно ли менять приоритеты, отказывать в нереалистичных сроках, влиять на архитектурные решения, запрашивать людей и бюджет. Ответственность без права влиять на результат, это удобная ловушка.
📌 Какие ресурсы выделят? Новая задача редко помещается в прежние сорок часов без последствий. Если вам добавляют работу руководителя, аналитика или продакта поверх основной роли, пусть честно скажут, что из текущих задач перестанет быть вашим. ⚙️
📌 Как мы измерим, что я справился? Иначе через полгода легко услышать: «Ты молодец, но для повышения нужно ещё немного доказать». Критерии должны появиться до того, как вы возьмёте на себя риск.
📌 Когда и как изменятся условия? Иногда повышение возможно только в следующий цикл, и это не катастрофа, если есть дата, критерии и договорённость, кто поднимает вопрос. Формулировка «поработай, там посмотрим» не является карьерным планом.
Важно отделять временную помощь команде от устойчивого изменения роли. Помочь закрыть сложный релиз две недели, нормально. Стать человеком, который постоянно отвечает за чужие решения, сроки и коммуникацию, это уже расширение должности. Вы не требуете деньги за каждое новое письмо в Slack, вы фиксируете новую цену и новые условия для новой работы. 💰
Сильная позиция может звучать так:
> «Мне интересна эта зона. Давайте зафиксируем, за что я отвечаю, какие у меня будут полномочия и что изменится в моей роли, если я показываю результат в ближайшие три месяца».
Адекватный руководитель не обязан сразу дать желаемую сумму. Но он должен быть способен честно обсудить объём работы, ожидания и траекторию. Если вместо этого появляются туман, давление на лояльность и просьба сначала год доказывать очевидное, вам предлагают не рост. На вас пытаются переложить риск без изменения цены сделки.
Новую ответственность стоит брать, когда вместе с ней растут хотя бы два из четырёх активов:
- деньги
- влияние на решения
- редкий навык
- сильный результат, который можно показать рынку
Если не растёт ничего, кроме списка задач, это не повышение. Это бесплатная дополнительная работа.
«Возьми это направление на себя. Ты хорошо справляешься». Звучит как признание, и иногда это действительно оно. Но иногда компания просто нашла человека, который согласится делать работу следующего грейда, пока получать будет за текущий. Новая ответственность сама по себе не плохая сделка. Она может дать опыт, влияние, сильную строчку в резюме и основание для роста дохода. Проблема начинается, когда предложение оставляют размытым: отвечать нужно за результат, а полномочий, ресурсов и пересмотра условий никто не обещает. 🫠
Например, разработчику предлагают «лидировать техническое направление». В реальности это может означать проводить встречи, согласовывать решения с несколькими командами, разбирать конфликты в приоритетах, онбордить новичков и отвечать за сроки чужой работы. Это уже не просто интересная инженерная задача, а другая роль, у которой должна быть понятная цена. Перед согласием не нужно устраивать торг или ультиматум. Нужно спокойно выяснить условия сделки.
📌 За какой конкретный результат я отвечаю? Не «улучшить процесс», а сократить время запуска моделей, снизить число инцидентов или вывести новую часть продукта к определённой дате.
📌 Какие у меня будут полномочия? Можно ли менять приоритеты, отказывать в нереалистичных сроках, влиять на архитектурные решения, запрашивать людей и бюджет. Ответственность без права влиять на результат, это удобная ловушка.
📌 Какие ресурсы выделят? Новая задача редко помещается в прежние сорок часов без последствий. Если вам добавляют работу руководителя, аналитика или продакта поверх основной роли, пусть честно скажут, что из текущих задач перестанет быть вашим. ⚙️
📌 Как мы измерим, что я справился? Иначе через полгода легко услышать: «Ты молодец, но для повышения нужно ещё немного доказать». Критерии должны появиться до того, как вы возьмёте на себя риск.
📌 Когда и как изменятся условия? Иногда повышение возможно только в следующий цикл, и это не катастрофа, если есть дата, критерии и договорённость, кто поднимает вопрос. Формулировка «поработай, там посмотрим» не является карьерным планом.
Важно отделять временную помощь команде от устойчивого изменения роли. Помочь закрыть сложный релиз две недели, нормально. Стать человеком, который постоянно отвечает за чужие решения, сроки и коммуникацию, это уже расширение должности. Вы не требуете деньги за каждое новое письмо в Slack, вы фиксируете новую цену и новые условия для новой работы. 💰
Сильная позиция может звучать так:
> «Мне интересна эта зона. Давайте зафиксируем, за что я отвечаю, какие у меня будут полномочия и что изменится в моей роли, если я показываю результат в ближайшие три месяца».
Адекватный руководитель не обязан сразу дать желаемую сумму. Но он должен быть способен честно обсудить объём работы, ожидания и траекторию. Если вместо этого появляются туман, давление на лояльность и просьба сначала год доказывать очевидное, вам предлагают не рост. На вас пытаются переложить риск без изменения цены сделки.
Новую ответственность стоит брать, когда вместе с ней растут хотя бы два из четырёх активов:
- деньги
- влияние на решения
- редкий навык
- сильный результат, который можно показать рынку
Если не растёт ничего, кроме списка задач, это не повышение. Это бесплатная дополнительная работа.
❤2🔥2🤔2
Как градиентный бустинг учится на ошибках, без формул на доске 🧠
На собеседовании часто говорят: «Градиентный бустинг последовательно исправляет ошибки предыдущих деревьев». Это хорошее начало, но за этой фразой легко спрятать непонимание механики. Главное, что стоит запомнить сразу: таргет второго дерева не равен предсказанию первого дерева. Он показывает, какую поправку нужно внести в это предсказание. В общем случае эта поправка называется антиградиентом функции потерь, то есть направлением, в котором нужно сдвинуть текущий прогноз, чтобы ошибка стала меньше. Именно поэтому бустинг называют градиентным. 💡
🏠 Представим задачу прогноза цены квартиры. У нас есть площадь, район, этаж, год постройки и реальная цена каждой квартиры. Первое дерево обычно очень простое. Например, оно замечает, что квартиры больше 60 квадратных метров в среднем стоят дороже, и выдаёт грубые прогнозы. Для одной квартиры оно предсказало 10 миллионов, хотя настоящая цена была 12 миллионов. Для другой предсказало 8 миллионов вместо 7 миллионов. После первого дерева у нас появляется не только прогноз, но и понимание, где и насколько текущая модель ошибается.
📌 Что становится таргетом второго дерева? Не исходная цена квартиры и не прогноз первого дерева. В простой регрессионной задаче с квадратичной ошибкой это остаток:
Для квартиры стоимостью 12 млн первое дерево предсказало 10 млн. Значит, таргет второго дерева будет +2 млн. Для квартиры стоимостью 7 млн был прогноз 8 млн, значит таргет будет −1 млн. В этом конкретном случае остаток и есть антиградиент функции потерь. Там, где первое дерево занизило цену, новое дерево учится добавлять значение. Там, где завысило, уменьшать. Каждое новое дерево отвечает не на вопрос «сколько стоит квартира?», а на вопрос «какую поправку нужно добавить к уже сделанному прогнозу?» ⚙️
➕ Как деревья собираются в один прогноз? Их предсказания не конкурируют друг с другом, а складываются в композицию. Если первое дерево для квартиры предсказало 10 млн, а второе выучило поправку +1,5 млн, итоговый прогноз после двух деревьев будет 11,5 млн. Если третье дерево добавит ещё +0,3 млн, итог станет 11,8 млн:
На практике к каждой поправке ещё применяется скорость обучения. Например, при
После добавления второго дерева прогноз становится точнее, но ошибки всё ещё остаются. Третье дерево смотрит уже на ошибку суммы первого и второго деревьев и ищет следующую полезную поправку. Возможно, оно замечает, что квартиры на верхних этажах без лифта систематически переоценены. Четвёртое, что год постройки тоже важен. Так постепенно возникает композиция: первое дерево улавливает крупную закономерность, следующие добавляют более тонкие исправления. Деревья обучаются последовательно, а не одновременно, потому что для следующей поправки нужно знать, что уже объяснила текущая сумма всех предыдущих деревьев. 🔍
🧠 Почему здесь появляется слово «градиентный»? В задаче с квадратичной ошибкой антиградиент совпадает с остатком, то есть с разницей между фактом и прогнозом. Но это не универсальное правило. В задачах классификации, например при прогнозе дефолта, модель оптимизирует другую функцию потерь. Тогда таргетом следующего дерева становятся псевдоостатки, то есть антиградиенты этой функции. Формулу можно не помнить. Важно понимать идею: каждое новое дерево строит не новый прогноз с нуля, а поправку к уже собранной модели, которая уменьшает выбранную ошибку.
На собеседовании часто говорят: «Градиентный бустинг последовательно исправляет ошибки предыдущих деревьев». Это хорошее начало, но за этой фразой легко спрятать непонимание механики. Главное, что стоит запомнить сразу: таргет второго дерева не равен предсказанию первого дерева. Он показывает, какую поправку нужно внести в это предсказание. В общем случае эта поправка называется антиградиентом функции потерь, то есть направлением, в котором нужно сдвинуть текущий прогноз, чтобы ошибка стала меньше. Именно поэтому бустинг называют градиентным. 💡
🏠 Представим задачу прогноза цены квартиры. У нас есть площадь, район, этаж, год постройки и реальная цена каждой квартиры. Первое дерево обычно очень простое. Например, оно замечает, что квартиры больше 60 квадратных метров в среднем стоят дороже, и выдаёт грубые прогнозы. Для одной квартиры оно предсказало 10 миллионов, хотя настоящая цена была 12 миллионов. Для другой предсказало 8 миллионов вместо 7 миллионов. После первого дерева у нас появляется не только прогноз, но и понимание, где и насколько текущая модель ошибается.
📌 Что становится таргетом второго дерева? Не исходная цена квартиры и не прогноз первого дерева. В простой регрессионной задаче с квадратичной ошибкой это остаток:
таргет второго дерева = факт − прогноз первого дерева
Для квартиры стоимостью 12 млн первое дерево предсказало 10 млн. Значит, таргет второго дерева будет +2 млн. Для квартиры стоимостью 7 млн был прогноз 8 млн, значит таргет будет −1 млн. В этом конкретном случае остаток и есть антиградиент функции потерь. Там, где первое дерево занизило цену, новое дерево учится добавлять значение. Там, где завысило, уменьшать. Каждое новое дерево отвечает не на вопрос «сколько стоит квартира?», а на вопрос «какую поправку нужно добавить к уже сделанному прогнозу?» ⚙️
➕ Как деревья собираются в один прогноз? Их предсказания не конкурируют друг с другом, а складываются в композицию. Если первое дерево для квартиры предсказало 10 млн, а второе выучило поправку +1,5 млн, итоговый прогноз после двух деревьев будет 11,5 млн. Если третье дерево добавит ещё +0,3 млн, итог станет 11,8 млн:
итоговый прогноз = прогноз 1-го дерева + поправка 2-го дерева + поправка 3-го дерева + ...
10 млн + 1,5 млн + 0,3 млн = 11,8 млн
На практике к каждой поправке ещё применяется скорость обучения. Например, при
learning_rate = 0.1 вклад второго дерева +1,5 млн добавится не целиком, а как +0,15 млн. Так модель учится осторожнее и меньше рискует слишком точно запомнить обучающие данные. 🛡️После добавления второго дерева прогноз становится точнее, но ошибки всё ещё остаются. Третье дерево смотрит уже на ошибку суммы первого и второго деревьев и ищет следующую полезную поправку. Возможно, оно замечает, что квартиры на верхних этажах без лифта систематически переоценены. Четвёртое, что год постройки тоже важен. Так постепенно возникает композиция: первое дерево улавливает крупную закономерность, следующие добавляют более тонкие исправления. Деревья обучаются последовательно, а не одновременно, потому что для следующей поправки нужно знать, что уже объяснила текущая сумма всех предыдущих деревьев. 🔍
🧠 Почему здесь появляется слово «градиентный»? В задаче с квадратичной ошибкой антиградиент совпадает с остатком, то есть с разницей между фактом и прогнозом. Но это не универсальное правило. В задачах классификации, например при прогнозе дефолта, модель оптимизирует другую функцию потерь. Тогда таргетом следующего дерева становятся псевдоостатки, то есть антиградиенты этой функции. Формулу можно не помнить. Важно понимать идею: каждое новое дерево строит не новый прогноз с нуля, а поправку к уже собранной модели, которая уменьшает выбранную ошибку.
❤3🔥3🤔2
Самые дорогие стратегические ошибки в карьере. Часть 8.
Идти в БигТех на старте карьеры ради красивой строчки в резюме. 🧑💻
В начале карьеры у меня и моих друзей из айти был один вопрос: куда пойти работать. В России тогда было гораздо меньше среднего бизнеса. В основном был БигТех и стартапы, поэтому варианта было два. Многие выбрали БигТех. Причины были понятными: чёткие задачи, зрелые заказчики, хорошая инфраструктура, модное место работы, красивая строчка в резюме. Только вот проблема - они были начинающими специалистами.
Картина сейчас выглядит так: большинство компаний берут новичков и держат их на очень простых задачах годами. Идейно это венчурная инвестиция, покупают себе будущего синьора. На практике института развития джунов внутри компаний почти нет. Ребята остаются джунами после двух, а иногда и трёх лет. Зато сам путь был прост: стабильные сервисы, отказоустойчивая инфраструктура, понятный процесс. 💼
С другой стороны есть стартапы. Приходя в стартап на любую позицию, твоя роль размывается. Ты становишься и инженером, и лидом, и бизнес-аналитиком, который общается с заказчиками, и девопсом, и дизайнером. При этом тебе ещё и платят меньше. В чём смысл? Смысл - в плотности опыта. За год в стартапе ML-инженер выводит четыре-пять моделей в прод. Сам, без команд интеграции, без ML Ops. Он видит заказчика, договаривается о метриках, тестирует, запускает, обрабатывает ошибки, объясняет коллегам, как работать с моделью. Год в стартапе равен двум годам в БигТехе на хорошей позиции. Иногда трём. 🚀
Но важно понимать, что не любой стартап даёт этот опыт. Хороший стартап для джуна - это место, где есть рабочий продукт, реальные пользователи, команда из пяти-двадцати человек и хотя бы один сильный технический лид. Если этого нет, можно застрять в хаосе без обучения. И там, и там бывает болото. Но в среднем рост в стартапах происходит быстрее и плотнее. Компетенции человека из стартапа гораздо шире, уровень толерантности к проблемам тоже выше. Он умеет работать с неопределённостью, решать задачи без готовой инструкции и защищать свои решения перед бизнесом. ⚙️
Да, в стартапе можешь сгореть. Да, можешь полгода делать то, что потом выкинут. Да, платят меньше. Но даже в проваленном стартапе ты получишь опыт, который в джуниор-роли БигТеха просто недоступен. Ты увидишь, как принимаются решения в условиях ограниченных ресурсов, как запускается MVP, как реагирует бизнес на твои предложения. Это не всегда комфортно, но именно это формирует сильного инженера. 💪
Мой совет: идите в стартапы, а на рынок БигТех выходите на позиции мидл+ или синьор. Иначе можете попасть в ситуацию, где грейд есть, оклад отличный, какие-то задачи делаю, но в резюме писать нечего. Я понимаю, что комфорт притягивает. Но именно в этой стабильности легко пересидеть первые критически важные годы, когда скорость обучения максимальная, а цена ошибки низкая. ☕️
Опыт, полученный в стартапе в первые два-три года, открывает путь к сильным позициям в крупных компаниях. Обратная траектория работает гораздо хуже. Выйти из БигТеха после трёх лет на роли джуниор-исполнителя и начать самостоятельно вести сложные задачи намного сложнее.
Именно поэтому я считаю, что одна из дорогих стратегических ошибок в карьере, идти в БигТех на старте карьеры ради красивой строчки в резюме. Потому что на старте важнее всего скорость обучения и ширина компетенций. А красивая строчка без реального опыта за ней не поможет на следующем этапе роста. 🗻
Идти в БигТех на старте карьеры ради красивой строчки в резюме. 🧑💻
В начале карьеры у меня и моих друзей из айти был один вопрос: куда пойти работать. В России тогда было гораздо меньше среднего бизнеса. В основном был БигТех и стартапы, поэтому варианта было два. Многие выбрали БигТех. Причины были понятными: чёткие задачи, зрелые заказчики, хорошая инфраструктура, модное место работы, красивая строчка в резюме. Только вот проблема - они были начинающими специалистами.
Картина сейчас выглядит так: большинство компаний берут новичков и держат их на очень простых задачах годами. Идейно это венчурная инвестиция, покупают себе будущего синьора. На практике института развития джунов внутри компаний почти нет. Ребята остаются джунами после двух, а иногда и трёх лет. Зато сам путь был прост: стабильные сервисы, отказоустойчивая инфраструктура, понятный процесс. 💼
С другой стороны есть стартапы. Приходя в стартап на любую позицию, твоя роль размывается. Ты становишься и инженером, и лидом, и бизнес-аналитиком, который общается с заказчиками, и девопсом, и дизайнером. При этом тебе ещё и платят меньше. В чём смысл? Смысл - в плотности опыта. За год в стартапе ML-инженер выводит четыре-пять моделей в прод. Сам, без команд интеграции, без ML Ops. Он видит заказчика, договаривается о метриках, тестирует, запускает, обрабатывает ошибки, объясняет коллегам, как работать с моделью. Год в стартапе равен двум годам в БигТехе на хорошей позиции. Иногда трём. 🚀
Но важно понимать, что не любой стартап даёт этот опыт. Хороший стартап для джуна - это место, где есть рабочий продукт, реальные пользователи, команда из пяти-двадцати человек и хотя бы один сильный технический лид. Если этого нет, можно застрять в хаосе без обучения. И там, и там бывает болото. Но в среднем рост в стартапах происходит быстрее и плотнее. Компетенции человека из стартапа гораздо шире, уровень толерантности к проблемам тоже выше. Он умеет работать с неопределённостью, решать задачи без готовой инструкции и защищать свои решения перед бизнесом. ⚙️
Да, в стартапе можешь сгореть. Да, можешь полгода делать то, что потом выкинут. Да, платят меньше. Но даже в проваленном стартапе ты получишь опыт, который в джуниор-роли БигТеха просто недоступен. Ты увидишь, как принимаются решения в условиях ограниченных ресурсов, как запускается MVP, как реагирует бизнес на твои предложения. Это не всегда комфортно, но именно это формирует сильного инженера. 💪
Мой совет: идите в стартапы, а на рынок БигТех выходите на позиции мидл+ или синьор. Иначе можете попасть в ситуацию, где грейд есть, оклад отличный, какие-то задачи делаю, но в резюме писать нечего. Я понимаю, что комфорт притягивает. Но именно в этой стабильности легко пересидеть первые критически важные годы, когда скорость обучения максимальная, а цена ошибки низкая. ☕️
Опыт, полученный в стартапе в первые два-три года, открывает путь к сильным позициям в крупных компаниях. Обратная траектория работает гораздо хуже. Выйти из БигТеха после трёх лет на роли джуниор-исполнителя и начать самостоятельно вести сложные задачи намного сложнее.
Именно поэтому я считаю, что одна из дорогих стратегических ошибок в карьере, идти в БигТех на старте карьеры ради красивой строчки в резюме. Потому что на старте важнее всего скорость обучения и ширина компетенций. А красивая строчка без реального опыта за ней не поможет на следующем этапе роста. 🗻
🤔4🔥3🤓1
Как стажёру стать Junior. 🎓
Главная ошибка стажёра, который хочет получить Junior-оффер, — пытаться доказать, как много он знает.
На практике руководителю почти всегда важнее другое: можно ли уже дать этому человеку небольшой кусок работы и перестать следить за ним каждые пять минут.
На мой взгляд, для этого обычно нужно 6 изменений. И все они очень приземлённые.
1. Стажёр сам добирает контекст.
Junior не обязан знать всё, но он уже умеет не теряться, когда задача неполная. Он сам уточняет недостающее, собирает контекст и приходит не с общим «не понял», а с конкретными вопросами. Это сразу меняет восприятие: человек не висит на каждом шаге, а двигается сам. 🧠
2. Стажёр берёт ownership за кусок работы.
Пока ты каждый раз ждёшь напоминание, тебя воспринимают как человека, которого нужно сопровождать. Когда ты сам ведёшь задачу до конца, сам пишешь о блокерах и сам закрываешь хвосты, появляется доверие. Даже маленькая задача, доведённая без шума, часто ценнее, чем большая, но брошенная на середине. ⚙️
3. Стажёр перестаёт приносить только ответ.
«Я сделал» — плохой формат коммуникации для человека, которого только начинают оценивать. Гораздо полезнее звучит так: «Я понял задачу вот так, попробовал A и B, B оказался лучше по такой-то причине, здесь остаётся такой-то риск». Руководителю важно не только увидеть результат, но и понять, можно ли доверять способу, которым ты к нему пришёл. 📌
4. Стажёр учится не теряться после ошибки.
Ошибки на этом уровне нормальны. Важнее другое, как человек реагирует. Если он прячется, молчит или делает вид, что ничего не было, доверие падает. Если он сам признаёт проблему, быстро сообщает о ней и предлагает, как исправить ситуацию, это уже взрослое поведение. Именно здесь многие и растут до Junior. 🔍
5. Стажёр становится предсказуемым по срокам.
На старте карьеры почти всегда есть переоценка своих сил. Но переход случается тогда, когда человек начинает реалистично оценивать время, не обещает лишнего и предупреждает заранее, если что-то идёт не так. Руководителю важно понимать, когда ждать результат и не узнавать о проблемах в последний момент. 📅
6. Стажёр понимает, зачем существует задача.
Junior уже может объяснить, кому нужен результат, что произойдёт после завершения задачи и почему это вообще важно. Это пока ещё не уровень самостоятельного влияния на систему, но уже не слепое исполнение. 🧩
Если совсем коротко, стажёр становится Junior тогда, когда с ним уже не нужно нянчиться. Он умеет сам добирать контекст, сам доводить задачу, сам сообщать о проблемах и сам сохранять рабочий ритм.
И важная оговорка: это не универсальная грейдовая система. В разных компаниях Junior может означать очень разный уровень. Я описываю не формальный титул, а тот переход в поведении, после которого лично я начинаю воспринимать стажёра как Junior.
Дальше разберу всю лестницу: Intern → Junior → Junior+ → Middle → Middle+ → Senior → Senior+ → Lead.
Именно поэтому я бы сказал так: Junior, это не тот, кто всё знает. Junior, это тот, кому уже можно доверить кусок работы без постоянного контроля. 🗻
Главная ошибка стажёра, который хочет получить Junior-оффер, — пытаться доказать, как много он знает.
На практике руководителю почти всегда важнее другое: можно ли уже дать этому человеку небольшой кусок работы и перестать следить за ним каждые пять минут.
На мой взгляд, для этого обычно нужно 6 изменений. И все они очень приземлённые.
1. Стажёр сам добирает контекст.
Junior не обязан знать всё, но он уже умеет не теряться, когда задача неполная. Он сам уточняет недостающее, собирает контекст и приходит не с общим «не понял», а с конкретными вопросами. Это сразу меняет восприятие: человек не висит на каждом шаге, а двигается сам. 🧠
2. Стажёр берёт ownership за кусок работы.
Пока ты каждый раз ждёшь напоминание, тебя воспринимают как человека, которого нужно сопровождать. Когда ты сам ведёшь задачу до конца, сам пишешь о блокерах и сам закрываешь хвосты, появляется доверие. Даже маленькая задача, доведённая без шума, часто ценнее, чем большая, но брошенная на середине. ⚙️
3. Стажёр перестаёт приносить только ответ.
«Я сделал» — плохой формат коммуникации для человека, которого только начинают оценивать. Гораздо полезнее звучит так: «Я понял задачу вот так, попробовал A и B, B оказался лучше по такой-то причине, здесь остаётся такой-то риск». Руководителю важно не только увидеть результат, но и понять, можно ли доверять способу, которым ты к нему пришёл. 📌
4. Стажёр учится не теряться после ошибки.
Ошибки на этом уровне нормальны. Важнее другое, как человек реагирует. Если он прячется, молчит или делает вид, что ничего не было, доверие падает. Если он сам признаёт проблему, быстро сообщает о ней и предлагает, как исправить ситуацию, это уже взрослое поведение. Именно здесь многие и растут до Junior. 🔍
5. Стажёр становится предсказуемым по срокам.
На старте карьеры почти всегда есть переоценка своих сил. Но переход случается тогда, когда человек начинает реалистично оценивать время, не обещает лишнего и предупреждает заранее, если что-то идёт не так. Руководителю важно понимать, когда ждать результат и не узнавать о проблемах в последний момент. 📅
6. Стажёр понимает, зачем существует задача.
Junior уже может объяснить, кому нужен результат, что произойдёт после завершения задачи и почему это вообще важно. Это пока ещё не уровень самостоятельного влияния на систему, но уже не слепое исполнение. 🧩
Если совсем коротко, стажёр становится Junior тогда, когда с ним уже не нужно нянчиться. Он умеет сам добирать контекст, сам доводить задачу, сам сообщать о проблемах и сам сохранять рабочий ритм.
И важная оговорка: это не универсальная грейдовая система. В разных компаниях Junior может означать очень разный уровень. Я описываю не формальный титул, а тот переход в поведении, после которого лично я начинаю воспринимать стажёра как Junior.
Дальше разберу всю лестницу: Intern → Junior → Junior+ → Middle → Middle+ → Senior → Senior+ → Lead.
Именно поэтому я бы сказал так: Junior, это не тот, кто всё знает. Junior, это тот, кому уже можно доверить кусок работы без постоянного контроля. 🗻
❤2🔥1🤔1🤓1👀1