Проблемы с фокусом во время работы — это не лень

Вы погружены в задачу, хочется ее решить.
Голова работает.
Но...

1️⃣ Вас выдергивают на важные встречи.
2️⃣ Вам спамят личку и спрашивают, какой статус по задаче
3️⃣ Вы думаете, что задачу нужно отдать идеально
4️⃣ Вы переключились на другую вкладку и в итоге забыли, зачем открывали
5️⃣ Параллельно вы начали делать другую задачу

И под конец рабочего дня задача не сделана, вы устали, чувствуете вину

Фокус ломается не из-за лени, а из-за среды и когнитивной перегрузки. Это проблема неправильной организации внимания.

🟢 Должен быть четкий объект фокуса. Нужно себе ответить на вопрос, над чем сейчас работаешь, чтобы явно себе понять, на чем нужно сфокусироваться.
🟢 Отключить ненужные уведомления. Нам кажется, что мы постоянно должны впитывать любую информацию. Но любая информация — это потеря фокуса на основных задачах 🔕
🟢 Выбрать оптимальную технику для фокуса. Это может быть Pomodoro, Deep Work, Pomodoro 2.0 даже. Техники бывают разные, в Яндексе я старался работать по Deep Work и это было эффективно. Сейчас выбираю для себя Pomodoro 🍅
🟢 Убрать мелкие выборы. Иногда себя ловлю на мысли о том, а какую вкладку нужно открыть (особенно, когда их много). Ранее слышал, что любое принятие решение тратит когнитивные силы, поэтому убираем 🤔
🟢 Фиксировать момент потери фокуса. Вы отвлеклись на другое дело? Это важно, потому что фокус теряется не случайно.

📺 Кстати, у Андрея было классное видео про то, как он вернул себе фокус на задачах

Еще из прикольного: там говорится о разгрузке мозга с помощью любого текстового документа, физическую активность...

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

А как у вас с фокусом? Теряетесь или все в порядке? Ставьте 🐳, если пост понравился, делитесь с теми, у кого проблемы с фокусом

@zasql_python

😁 Нашел себе занятие на выходные... на ближайшие N месяцев

💻 Забрал сегодня предзаказ книги Валеры Бабушкина и Арсения Кравченко по машинному обучению на русском языке.

Буду периодически закидывать сюда свои мысли по прочитанным материалам, формировать конспекты.

Если вам интересно, отреагируйте на пост реакциями или комментами 🐳

Кто-то успел ее уже прочитать на английском языке? Как ваши впечатления? Делитесь 🍪🍪

@zasql_python

🟡 ROC-AUC кривая. Метрика оценки качества модели классификации в машинном обучении

Да чего там делать пост, берешь sklearn, делаешь импорт из metrics и погнал. Чем ближе к 1, тем лучше => выбираем. Но давайте разбираться более детальною.

❓ ROC-AUC — это вероятность того, что наши положительные классы получили больший скор, чем отрицательные.

🔽 Пример: предположим, у нас есть следующая таблица.

| object | score value | y |
|--------|-------------|---|
| A      | 0.92        | 1 |
| B      | 0.81        | 1 |
| C      | 0.74        | 0 |
| D      | 0.63        | 1 |
| E      | 0.41        | 0 |
| F      | 0.27        | 0 |
| G      | 0.18        | 0 |
| H      | 0.05        | 1 |

✏️ Для каждого порога (в таблице значения) в отсортированной по скору таблице вычислим по строкам значения:

Для 1 строки считаем какие объекты попадают в score >= 0.92 — это один положительный класс. Среди всех положительных (4) => TPR = 1/4. При этом мы рассмотрели только один объект положительного класса => FPR = 0.

Для 2 строки считаем уже два объекта A, B. Это оба положительных класса. Среди всех положительных (4) => TPR = 2/4 = 1/2. Пока что объектов с классом 0 не попалось.

Для 3 строки считаем уже три объекта A, B, C. Смотрим на объект со скором >= 0.74. TPR по-прежнему = 1/2, а вот FPR увеличился, так как залетел новый объект с меткой 0. Среди всех отрицательных классов (4) => FPR = 1/4.

Далее считаем TPR, FPR для каждой из строк (Сколько объектов мы отнесли к положительному классу из всех возможных объектов класса).

По сути, мы отвечаем на вопрос: В скольких случаях скор, полученный по модели для положительных классов выше, чем для отрицательных.

Графически это выглядит как ступеньки (по оси X — FPR, по оси Y — TPR). При движении по трешхолдам для отнесения к классам смотрим как меняются значения TPR и FPR, кстати еще есть значения трешхолдов в самой библиотеке sklearn.

🧠 Чтобы посчитать вручную само значение:

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

1. A > C, A > E, A > F, A > G (пол.)
2. B > C, B > E, B > F, B > G (пол.)
3. C > D, C > H (нег.)
4. D > E, D > F, D > G (пол.)
5. E > H (нег.)
6. F > H (нег.)
6. G > H (нег.).

Считаем количество всех сочетаний: 16
Считаем количество правильных среди положительных: 11
ROC-AUC = 11/16 = 0.6875

✋ Ограничения в ML

1. Не учитывает цену ошибок (FP = FN по важности)
2. Не даёт порог для принятия решения
3. Ломается при сильном дисбалансе
4. Игнорирует калибровку вероятностей
5. Одно число скрывает локальные ошибки

🐍 Как можно применять для аналитики

1. Если есть модель и мы хотим определить есть ли сигнал в данных (ROC-AUC > 0.5). То есть позволяют ли наши признаки сделать модель такую, чтобы она была лучше случайности.

2. Понять, какие фичи улучшают разделение между TP и FP. Например, при добавлении фичи ROC-AUC увеличился => появился новый сигнал.

3. Проверка эвристики против модели. Оправдано ли применение ML-модели в принципе или достаточно эвристику.

4. Сравнение сегментов / источников сигнала. Задача: понять, где модель работает.

5. Оценка классификации по неделям. Понимаем, что ROC-AUC по неделям деградирует => нужно добавить больше признаков для обобщения.

6. Сравнение разных таргетов. Один таргет лучше отделяется => он более предсказуем и устойчив

Если коротко: ROC-AUC отвечает на вопрос есть ли сигнал, а не как принимать решение

Понравился пост? Ставьте 🐳, пишите комментарии!

@zasql_python

Перед запуском проекта привлекайте всех заинтересованных лиц (ну или почти всех)

Это касается не только аналитиков, но и продактов, дизайнеров, разработчиков. Худшее, что может случиться с проектом — ты узнаёшь о процессе после продакшена и пытаешься понять, что вообще происходит.

1. Расширение бизнес-контекста. Круто, когда все в синке по продуктовым изменениям. На общих встречах понимать друг друга, кто куда движется и какие есть ограничения у систем при раскатке. Например, почему нельзя сразу катнуть на всех: лимиты инфраструктуры, неготовая аналитика, риск убить ключевую метрику — и это важно проговорить заранее, а не в разгар инцидента.

Практически любой человек, который работает в продукте должен его понимать, в том числе бизнесово

2. Возможность переложить бизнес-контекст на "свой" язык до фактической раскатки. Продумывая систему можно обрисовать примерный план действий. Аналитику нужно настроить систему алертинга, рассчитать метрики, придумать заранее срезы. Разработчику понять, что все события корректно логируется и сервис получает и отдает, что нужно. Потому что после раскатки начинается пожар: всё падает, метрик нет, логов не хватает, а отвечать нужно уже сейчас 🐸

Придумать план действий, задизайнить систему с заинтересованными лицами, понять сколько нужно делать шагов для нормально функционирования

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

Если несколько человек делают одну и ту же задачу без договорённостей — это почти гарантированные расхождения и потеря времени

🥺

4. Меньше мисскоммуникации. Случается так, что между заинтересованными лицами случается следующее: делаем это, хотя нужно сделать вот это. Если продолжается часто, нужно задуматься над тем, а что вообще происходит и можно ли это пофиксить. Например, собрать общий синк и обсудить.

А у вас было такое, что вы узнавали о ключевом процессе уже после продакшена? Чем это закончилось — спасли или тушили пожар? Ставьте 🐳, пишите комментарии!

@zasql_python

Команды Яндекса ищут продуктовых и data-аналитиков, а также data scientists с опытом на Python от 3 лет.

Участвуйте в Weekend Offer, чтобы всего за 2 дня пройти все собеседования и получить офер.

Как участвовать?
⚪ Зарегистрироваться на сайте до 25 февраля.
⚪ Пройти две технические секции 28 февраля.
⚪ Познакомиться с командами и получить офер 1 марта.

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

Подробности и регистрация — по ссылке: https://yandex.ru/project/events/wo-analytics-0226

Реклама. ООО "Яндекс". ИНН 7736207543

Нашел статью (как же я люблю такие статьи) про будущее аналитики данных в 2026, здесь представлены основные тренды.

Здесь ссылаются на этот источник, в котором говорятся следующие вещи (статья 2025 года на минуточку):

1. 70% аналитиков считают, что AI и автоматизация аналитики делают их работу более эффективной и продуктивной
2. 76% аналитиков до сих пор используют таблицы (Excel / Google Sheets) для подготовки данных
3. 45% тратят более 6 часов в неделю на очистку и подготовку данных

Я не смотрел детально как собирались выборки, мне просто продали цифры 👀 Не вижу ничего такого использовать определенные инструменты для подготовки данных. Тут это не говорит ни о чем. Последний пункт, скорее, да, чем нет. Инсайты могут получаться не сразу (если смотрим узкий сегмент, который не покрыт дашбордами), а только после написания нескольких скриптов, склеек и отрисовки графиков.

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

1. Augmented Analytics and Automated Insight Generation
BI-инструменты сами находят аномалии, паттерны и причины. Аналитик всё меньше пишет запросы и всё больше думает над смыслом, интерпретацией выводов.

В ❤️, например, в DataLens уже есть и выводы по изменению метрик в различных срезах, я когда там работал, уже успел потестить — классная штука

2. Analytics on Streaming and Real‑Time Data

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

3. Data Fabric
Единый слой данных вместо кучи источников. Меньше времени на подготовку — больше на анализ.

Если есть DWH — класс. Учитывая, что это зарубежная статья, там как раз только приходят к некоторому в некоторых компаниях, да и в крупных в РФ в некоторых отделах тоже могут к этому приходить не сразу 👩‍💻

4. Вопросы к данным обычным языком
Text to Insight. Аналитика становится доступнее бизнесу.

Видел, что в одной небольшой зарубежной компании ребята реализовали чат-бот с RAG'ом на витрину и просто писали запрос, про подобное я писал с точки зрения реализации Text2SQL в 🖤, а тут сразу инсайты + гипотезы. Получается, аналитика занимается более стратегическими задачами, да, ведь? 🤨

👉 Подробнее можно прочитать тут

Мне лично нравятся тренды на ИИ-агентов и автоматизации процессов с помощью них, как будто пока что это основной хайп, хотя не во всех компаниях во внутреннем контуре можно такую историю себе поставить (Claude, Cursor) и нужно настраивать прокси... А так, если глобально смотреть, пока что ничего не меняется, смотрим дальше, может скоро будет переломный момент 😏

А вы как считаете, тренды поменяются в этом году или нет? Что по вашему мнению является ключевым для аналитика в 2026?
Сохранять здравый рассудок, наверное?

@zasql_python