Forwarded from DevFM
DevFM подкаст 3: Роли в ИТ-проекте (youtube / podster / yandex)
В часовом видеоподкасте мы обсудили роли в ИТ-проекте из ~25 человек, занятых разработкой крупного веб-сервиса со сложной бизнес областью. Бизнес аналитики, системные аналитики, тим лиды, разработчики – кто на ком стоял и чем все эти люди занимаются. Представлен достаточно высокоуровневый взгляд на команду, если вы в таком не участвовали – вам точно будет интересно. В конце обсуждаем, можно ли малой командой делать большие проекты и, наоборот, делать большой командой малые проекты.
Подкаст 2. Кто такой тимлид тимлидов
Подкаст 1. Ретроспектива силами команды разработки
#devfm #podcast #teamwork
В часовом видеоподкасте мы обсудили роли в ИТ-проекте из ~25 человек, занятых разработкой крупного веб-сервиса со сложной бизнес областью. Бизнес аналитики, системные аналитики, тим лиды, разработчики – кто на ком стоял и чем все эти люди занимаются. Представлен достаточно высокоуровневый взгляд на команду, если вы в таком не участвовали – вам точно будет интересно. В конце обсуждаем, можно ли малой командой делать большие проекты и, наоборот, делать большой командой малые проекты.
Подкаст 2. Кто такой тимлид тимлидов
Подкаст 1. Ретроспектива силами команды разработки
#devfm #podcast #teamwork
YouTube
DevFM podcast 3. Роли в ИТ-проекте
На больших проектах много ролей. Иногда непонятно, чем они все занимаются. На примере команды из ~25 человек, создающей некоторый сервис с нетривиальной логикой рассмотрим типичные роли: тимлид, техлид, project manager, бизнес аналитик, системный аналитик…
Forwarded from Data Blog
❤️ Привет, друзья!
🔅Новая библиотека, в этот раз для текстовых данных.
Библиотека: explabox, paper
Совместимость: pytorch, Keras, tensorflow (главное — формат onnx), scikit-learn
Ограничение: только текстовая модальность даных (датасеты Hf, pandas, numpy arrays)
Поддерживаемые методы:
1. LIME
2. KernelSHAP
3. Counterfactual/contrastive explanations [FoilTrees]
4. Local rule-based models
🔅 Ещё реализованы метрики: чувствительность (robustness, оценка того, как небольшие изменения влияют на объяснение), безопасность (security, например, если входные данные, содержащие определенные символы, приводят к сбою модели) и справедливости (fairness, например, оценка на специфических признака — страна происхождения, пол, раса или социально-экономический статус)
Также обновила в табличку (https://xai-table.streamlit.app/).
Чудесного вам вечера!
Ваш Дата-автор,копающийся в контенте о DeppSeek! 🐳
🔅Новая библиотека, в этот раз для текстовых данных.
Библиотека: explabox, paper
Совместимость: pytorch, Keras, tensorflow (главное — формат onnx), scikit-learn
Ограничение: только текстовая модальность даных (датасеты Hf, pandas, numpy arrays)
Поддерживаемые методы:
1. LIME
2. KernelSHAP
3. Counterfactual/contrastive explanations [FoilTrees]
4. Local rule-based models
🔅 Ещё реализованы метрики: чувствительность (robustness, оценка того, как небольшие изменения влияют на объяснение), безопасность (security, например, если входные данные, содержащие определенные символы, приводят к сбою модели) и справедливости (fairness, например, оценка на специфических признака — страна происхождения, пол, раса или социально-экономический статус)
Также обновила в табличку (https://xai-table.streamlit.app/).
Чудесного вам вечера!
Ваш Дата-автор,
GitHub
GitHub - MarcelRobeer/explabox: Explore/examine/explain/expose your model with the explabox!
Explore/examine/explain/expose your model with the explabox! - MarcelRobeer/explabox
Forwarded from Борис_ь с ml
2025 год для канала начался очень даже хорошо - он преодолел отметку 500 читателей! Спасибо вам, друзья!
Я невероятно рад, что мой интерес и взгляд на будущее информационных технологий разделяют еще столько людей. Для меня это теперь ответственно - рассказывать вам о том, что происходит в мире информационной безопасности и искусственного интеллекта. Поэтому наполнение канала постараюсь держать как минимум на заданной планке и впредь
И не откладывая в долгий ящик, я представляю вам, читатели, первую публикацию в этом году - хабр-статья про интерпретацию ИИ.
Тема меня очень заинтересовала давно, и сначала вылилась в подкаст в Музее Криптографии. Но я понял, что сам еще многое не рассказал вам и не показал, так что сел за статью. В ней я разбираюсь, чем отличается интерпретируемость и объяснимость, и, как всегда, привожу море ссылок. Приятного чтения)
#иб_для_ml
Please open Telegram to view this post
VIEW IN TELEGRAM
Хабр
Что такое интерпретируемость машинного обучения?
Насколько интерпретируемость важна для машинного обучения? Зачем она вообще нужна? Для чего она в информационной безопасности? Меня эти вопросы начали интересуют уже около полугода, и в фоновом режиме...
Forwarded from Заскуль питона (Data Science)
Как считать пенетрацию пользователей в продукте на SQL?
🎮 В сервисе у нас есть чарт, характеризующий количество пользователей в сервисе (MAU / DAU / WAU), мы смотрим за определенный промежуток времени количество пользователей. Этот график интуитивно понятен, есть практически во всех продуктах и является одной из тех метрик, которую отслеживают.
Тут достаточно понятно, берем группировку по дням / неделям / месяцам, считаем уникальных пользователей в приложении и готово!
❓ Пенетрация позволяет ответить на вопрос: "Сколько всего пользователей пользуются продуктом в динамике?". В сервисе есть старички, которые регулярно продукт используют и за время мы их учитываем несколько раз (по дням). Мы можем взять весь год и посмотреть сколько всего пользователей использовали фичу X и посчитать статично, найти долю и все. Но хочется понимать как инициативы влияют на абсолютные значения / доли относительно всех пользователей продукта до момента T.
⬆️ Выше представлен скрипт, который считает накопительно пользователей по дням, теперь мы можем это применить для ответа на вопрос: "Какой процент пользователей когда-либо использовал продукт на момент времени T?". Это нам может быть нужно для отслеживания доли использования от всей аудитории накопительно. Мы можем более явно отслеживать как наша база (в тотале) реагирует по дням, когда мы используем какие-то механики, например, или запускаем новые фичи
⬆️ Выше представлен код, как мы считае долю тех, кто использовал фичу относительно всех пользователей до момента T.
🐖 Используете ли вы пенетрацию для отслеживания доли относительно всех пользователей? Был ли этот пост полезен? Ставьте 100 🐳 и я выложу еще что-нибудь по этой тематике)
Тут достаточно понятно, берем группировку по дням / неделям / месяцам, считаем уникальных пользователей в приложении и готово!
WITH user_activity AS (
SELECT
user_id,
event_date,
DATE_TRUNC('week', event_date) AS week_start,
DATE_TRUNC('month', event_date) AS month_start
FROM user_events
WHERE event_date BETWEEN '2024-01-01' AND '2024-12-31'
)
SELECT
event_date,
COUNT(DISTINCT user_id) AS DAU,
COUNT(DISTINCT CASE WHEN event_date = week_start THEN user_id END) AS WAU,
COUNT(DISTINCT CASE WHEN event_date = month_start THEN user_id END) AS MAU
FROM user_activity
GROUP BY event_date
ORDER BY event_date;
WITH daily_users AS (
SELECT
event_date,
user_id
FROM user_events
WHERE event_date BETWEEN '2024-01-01' AND '2024-01-30'
),
date_series AS (
SELECT DISTINCT event_date
FROM daily_users
),
cumulative_users AS (
SELECT
d.event_date,
COUNT(DISTINCT u.user_id) AS cumulative_unique_users
FROM date_series d
LEFT JOIN daily_users u ON u.event_date <= d.event_date
GROUP BY d.event_date
ORDER BY d.event_date
)
SELECT * FROM cumulative_users;
WITH daily_feature_users AS (
SELECT
event_date,
user_id
FROM user_events
WHERE event_name = 'feature_x'
AND event_date BETWEEN '2024-01-01' AND '2024-01-30'
),
daily_total_users AS (
SELECT
event_date,
user_id
FROM user_events
WHERE event_date BETWEEN '2024-01-01' AND '2024-01-30'
),
date_series AS (
SELECT DISTINCT event_date
FROM daily_total_users
),
cumulative_feature_users AS (
SELECT
d.event_date,
COUNT(DISTINCT u.user_id) AS cumulative_feature_users
FROM date_series d
LEFT JOIN daily_feature_users u ON u.event_date <= d.event_date
GROUP BY d.event_date
ORDER BY d.event_date
),
cumulative_total_users AS (
SELECT
d.event_date,
COUNT(DISTINCT u.user_id) AS cumulative_total_users
FROM date_series d
LEFT JOIN daily_total_users u ON u.event_date <= d.event_date
GROUP BY d.event_date
ORDER BY d.event_date
)
SELECT
cfu.event_date,
cfu.cumulative_feature_users,
ctu.cumulative_total_users,
ROUND(100.0 * cfu.cumulative_feature_users / (ctu.cumulative_total_users, 0), 2) AS penetration_rate
FROM cumulative_feature_users cfu
JOIN cumulative_total_users ctu ON cfu.event_date = ctu.event_date
ORDER BY cfu.event_date;
Please open Telegram to view this post
VIEW IN TELEGRAM
Forwarded from Love. Death. Transformers.
Forwarded from ML Advertising
Проектируем платформу ставок с нуля? 💵
Сегодня займемся проектированием своей Real Time Bidding платформы ставок. На упрощенной схеме мы разберем из каких основных блоков она должна состоять, и как эти блоки между собой связаны.
➡️ Article
Собственно сама веб-страница с размещенными на ней рекламными слотами. Также в случае Header Bidding интеграции в шапке HTML кода страницы могут быть прописаны настройки, в которые добавлен наша платформа ставок, как игрок, имеющий доступ к покупке слотов.
➡️ TagJS
JS код, размещенный на странице паблишера. Отвечает за трекинг действий пользователя на сайте, например, когда пользователь доскролил до слота, увидел пиксель, кликнул etc. Отправляет события на нашу сторону.
➡️ Bidder
Биддер - это модуль, отвечающий за коммуникацию с паблишером (или с Prebid'ом, если закупаем трафик через Header Bidding) и отправку ставок.
- Принимает запрос на ставку + фичи паблишера + user agent, чтобы извлечь фичи пользователя.
- Собирает ставку с учетом заложенной маржи на запрос bid = CPM x (1 - margin) x bidFactors, с учетом коэффициентов, понижающих ставок, выданных автобиддингом.
- Когда ставка посчитана, отправляет на ендпоинт паблишера или Prebid'а ответ со ставкой.
➡️ Models
Все ML модели, отвечающие за фильтрацию, монетизацию
- Фильтрация по вероятности показа, клика, досмотра etc.
- Фильтрация по фроду
- Оптимизация ставки (shading, автобиддинг)
- Budget pacing
Может быть как интегрирован внутрь биддера, так и вынесен в отдельный сервис, к которому биддер будет обращаться как клиент.
Инференс, встроенный в биддер
В первом случае у нас получается маленький монолит внутри платформы из двух сервисов, в связи с чем потребуется быть более аккуратными при внедрении изменений в сервис, но появляется возможность кешировать модели, и насладиться относительно низким latency.
Отдельный инференс сервис
Во втором же случае структура получается модульная, в оба сервиса можно вносить изменения независимо друг от друга, но придеться заплатить более высоким latency (в основном из-за HTTP коммуникации между сервисами). Также встает вопрос, что делать биддеру, если сервис с моделями упал. Если в первом случае артефакты были закешированны на биддере, он мог пользоваться ими до тех пор, пока новые модели не подъедут, то во втором случае модули друг для друга становятся черными ящиками, и нужно задаться вопросом обеспечения минимального availability
➡️ Tracking
Пожалуй, центральный элемент всей схемы, поскольку на нем замыкаются все. Логирует абсолютно все события
- на стороне паблишера: действия пользователя + транзакции
- на стороне биддера: отказ от ответа, таймаут, ставка с ее значением
- на стороне моделей фильтрации: события фильтрации + ее причины
Кроме того логируем события биллинга, когда по аукциону мы должны получить оплату от рекламодателя и заплатить паблишеру
➡️ DB
Затреканные события и транзакции нужно куда-то писать, делать это быстро, и иметь оптимизированное хранилище. Здесь все делаем по заветам книжки с кабанчиком. Чаще всего прибегаем к следующему варианту. Tracking сервис пишет события по мере их поступления в очередь данных (Kafka, RabbitMQ). Далее с помощью либо Kafka коннектора, либо Spark Streaming джобы пишем события из очереди в батчи в объектное хранилище (S3, GCS) партициями. Также можно писать и в OTLP хранилище с быстрой записью транзакций (Greenplum)
Кроме того, нам также потребуется хранилище для аналитики (по-английски еще называют OLAP хранилища). Это нужно для отслеживания статов платформы в целом по аггрегатам трафик, CPM, CPC, CPV group by publisher, тип контракта, страна etc. Для этого подойдут ClickHouse или Google BigQuery
Invoicing
Модуль, который читает данные из OLAP хранилища и отвечает за выстапление счетов рекламодателю. На этапе трекинга в момент логирования события оплаты, сама оплата не происходит. Записанные события с биллингом аггрегируются, и рекламодателю выставляется счет на сумму, которая должна биться с бюджетом, который наша платформа открутила. Эта процедура делается раз в месяц или в квартал.
Сегодня займемся проектированием своей Real Time Bidding платформы ставок. На упрощенной схеме мы разберем из каких основных блоков она должна состоять, и как эти блоки между собой связаны.
➡️ Article
Собственно сама веб-страница с размещенными на ней рекламными слотами. Также в случае Header Bidding интеграции в шапке HTML кода страницы могут быть прописаны настройки, в которые добавлен наша платформа ставок, как игрок, имеющий доступ к покупке слотов.
➡️ TagJS
JS код, размещенный на странице паблишера. Отвечает за трекинг действий пользователя на сайте, например, когда пользователь доскролил до слота, увидел пиксель, кликнул etc. Отправляет события на нашу сторону.
➡️ Bidder
Биддер - это модуль, отвечающий за коммуникацию с паблишером (или с Prebid'ом, если закупаем трафик через Header Bidding) и отправку ставок.
- Принимает запрос на ставку + фичи паблишера + user agent, чтобы извлечь фичи пользователя.
- Собирает ставку с учетом заложенной маржи на запрос bid = CPM x (1 - margin) x bidFactors, с учетом коэффициентов, понижающих ставок, выданных автобиддингом.
- Когда ставка посчитана, отправляет на ендпоинт паблишера или Prebid'а ответ со ставкой.
➡️ Models
Все ML модели, отвечающие за фильтрацию, монетизацию
- Фильтрация по вероятности показа, клика, досмотра etc.
- Фильтрация по фроду
- Оптимизация ставки (shading, автобиддинг)
- Budget pacing
Может быть как интегрирован внутрь биддера, так и вынесен в отдельный сервис, к которому биддер будет обращаться как клиент.
Инференс, встроенный в биддер
В первом случае у нас получается маленький монолит внутри платформы из двух сервисов, в связи с чем потребуется быть более аккуратными при внедрении изменений в сервис, но появляется возможность кешировать модели, и насладиться относительно низким latency.
Отдельный инференс сервис
Во втором же случае структура получается модульная, в оба сервиса можно вносить изменения независимо друг от друга, но придеться заплатить более высоким latency (в основном из-за HTTP коммуникации между сервисами). Также встает вопрос, что делать биддеру, если сервис с моделями упал. Если в первом случае артефакты были закешированны на биддере, он мог пользоваться ими до тех пор, пока новые модели не подъедут, то во втором случае модули друг для друга становятся черными ящиками, и нужно задаться вопросом обеспечения минимального availability
➡️ Tracking
Пожалуй, центральный элемент всей схемы, поскольку на нем замыкаются все. Логирует абсолютно все события
- на стороне паблишера: действия пользователя + транзакции
- на стороне биддера: отказ от ответа, таймаут, ставка с ее значением
- на стороне моделей фильтрации: события фильтрации + ее причины
Кроме того логируем события биллинга, когда по аукциону мы должны получить оплату от рекламодателя и заплатить паблишеру
➡️ DB
Затреканные события и транзакции нужно куда-то писать, делать это быстро, и иметь оптимизированное хранилище. Здесь все делаем по заветам книжки с кабанчиком. Чаще всего прибегаем к следующему варианту. Tracking сервис пишет события по мере их поступления в очередь данных (Kafka, RabbitMQ). Далее с помощью либо Kafka коннектора, либо Spark Streaming джобы пишем события из очереди в батчи в объектное хранилище (S3, GCS) партициями. Также можно писать и в OTLP хранилище с быстрой записью транзакций (Greenplum)
Кроме того, нам также потребуется хранилище для аналитики (по-английски еще называют OLAP хранилища). Это нужно для отслеживания статов платформы в целом по аггрегатам трафик, CPM, CPC, CPV group by publisher, тип контракта, страна etc. Для этого подойдут ClickHouse или Google BigQuery
Invoicing
Модуль, который читает данные из OLAP хранилища и отвечает за выстапление счетов рекламодателю. На этапе трекинга в момент логирования события оплаты, сама оплата не происходит. Записанные события с биллингом аггрегируются, и рекламодателю выставляется счет на сумму, которая должна биться с бюджетом, который наша платформа открутила. Эта процедура делается раз в месяц или в квартал.
docs.prebid.org
About Prebid.js for Header Bidding
An overview of Prebid.js
Forwarded from Konstantin
https://docs.llamaindex.ai/en/stable/examples/cookbooks/cohere_retriever_eval/
https://aws.amazon.com/blogs/machine-learning/build-cost-effective-rag-applications-with-binary-embeddings-in-amazon-titan-text-embeddings-v2-amazon-opensearch-serverless-and-amazon-bedrock-knowledge-bases/#:~:text=In%20end%2Dto%2Dend%20RAG,(98.6%25%20without%20reranking).
https://aws.amazon.com/blogs/machine-learning/build-cost-effective-rag-applications-with-binary-embeddings-in-amazon-titan-text-embeddings-v2-amazon-opensearch-serverless-and-amazon-bedrock-knowledge-bases/#:~:text=In%20end%2Dto%2Dend%20RAG,(98.6%25%20without%20reranking).
Amazon
Build cost-effective RAG applications with Binary Embeddings in Amazon Titan Text Embeddings V2, Amazon OpenSearch Serverless,…
Today, we are happy to announce the availability of Binary Embeddings for Amazon Titan Text Embeddings V2 in Amazon Bedrock Knowledge Bases and Amazon OpenSearch Serverless. This post summarizes the benefits of this new binary vector support and gives you…
Forwarded from Моя жизнь в IT/Губарева
#Мыслинамысли: личный бренд, корпорации и жизнь
Вчера вечером мобильный YouTube подбросил интервью своего создателя — Андрея Дороничева. Он же — герой легендарного фильма Дудя(признан иноагентом в РФ) «Кремниевая долина» и фаундер Optic — одного из самых успешных AI-стартапов в биотехнологиях.
Услышав ответы на многие вопросы про личный бренд и проявленность в мир, над которыми много думаю сама и которые часто слышу на лекциях, решила поделиться...
⚡️мыслями на мысли, которые зацепили
Помните, у Хармса?
Писатель: «Я писатель!»
Читатель: «А по-моему, ты говно!»
Когда мы начинаем какую-то деятельность, нам страшно представляться. Потому что — мы сами не чувствуем, что можем в этой роли много. Потому что — придут, обесценят, разоблачат. Привет, синдром самозванца!
Но правда в том, что другого пути нет: ты не станешь предпринимателем, экспертом, автором канала,руководителем команды, пока не осмелишься встать и сказать: «Привет, я теперь эксперт в этом!». Это коммит перед собой и миром.
Чтобы доказать своей аудитории, которая постоянно говорила «Ну конечно, тебе-то легко говорить, ты же вон какая звезда!» Андрей на глазах сотен тысяч человек провел эксперимент.
Взял область, в которой у него не было ни таланта, ни опыта, и публично объявил, что он — певец. Начал выкладывать треки: кривые-косые. Несколько месяцев проходил через публичный хейт «раннего творчества». Но с каждым днем его записи становились все лучше. И достигли вполне приемлемого качества. Стал ли он претендентом на Грэмми? Нет. Но он стал из очень слабого вполне нормальным исполнителем.
Мораль: когда мы выходим в паблик, нам неизбежно придется смириться, что наши выступления не похожи на стэнфордскую речь Джобса. И что люди не бросают в воздух чепчики.Спасибо, что не бросают помидоры. И это —нормально!
❗️Личный бренд работодателя VS ваш личный бренд
Дороничев пришел в Google на пару лет и задержался на 13. Когда он уходил, ему написала CEO YouTube с предложением остаться. Андрей посчитал миллионы долларов, которые теряет с уходом. И…ответил, что увольняется, потому «больше не понимает, кто он такой».
Работая в крупной компании с яркой культурой и идентичностью, очень важно отслеживать, как там поживает ваша собственная идентичность. И если вдруг в какой-то момент на вопрос «Кто я?» вашим первым ответом становится «Сотрудник Google, Яндекс, McKinsey, etc» —надо что-то делать, друзья!
❗️В мире точно есть люди, которым полезен ваш опыт. Важно хотеть им поделиться.
После выхода из Google Андрей осознал свою новую миссию: нести знания о мире инвестиций, IT и Кремниевой долине, в том числе через блог. Интересно ли это всем в масштабах человечества? Нет. Но точно есть сотни и тысячи людей, которым это мегаполезно.
Кому можете быть полезны вы, если вы не руководитель всемирно известного продукта, а просто хороший продакт?
Вчера на моей лекции в Вышке одна из студенток поделилась, что думает над переходом из SMM в продукт, но не понимает, с чего начать. Чем не миссия – круто рассказывать о своей работе классным ребятам, которые только выбирают свой профессиональный трек? Think about it!
Иногда жизнь дает нам возможность сформулировать точку B, подготовить почву для перехода, сформировать тактику и ее придерживаться. А иногда – с ноги выталкивает в сетап, где твой счет с 10 миллионами долларов, которые ты нарэйзил, за ночь превращается в тыкву.
И это тоже – не конец жизни.
В общем, очень советую вам посмотреть это видео,причем в равной степени предпринимателям и корпоратам . А найти его предлагаю самостоятельно, ориентируясь на то, что это популярное интервью Дороничева 4-месячной давности.
📺Приятного просмотра!
Вчера вечером мобильный YouTube подбросил интервью своего создателя — Андрея Дороничева. Он же — герой легендарного фильма Дудя
Услышав ответы на многие вопросы про личный бренд и проявленность в мир, над которыми много думаю сама и которые часто слышу на лекциях, решила поделиться...
⚡️мыслями на мысли, которые зацепили
Момент, когда ты только объявляешь, что ты – тот, кем ты только собираешься стать, жутко некомфортный.
Помните, у Хармса?
Читатель: «А по-моему, ты говно!»
Когда мы начинаем какую-то деятельность, нам страшно представляться. Потому что — мы сами не чувствуем, что можем в этой роли много. Потому что — придут, обесценят, разоблачат. Привет, синдром самозванца!
Но правда в том, что другого пути нет: ты не станешь предпринимателем, экспертом, автором канала,руководителем команды, пока не осмелишься встать и сказать: «Привет, я теперь эксперт в этом!». Это коммит перед собой и миром.
Чтобы доказать своей аудитории, которая постоянно говорила «Ну конечно, тебе-то легко говорить, ты же вон какая звезда!» Андрей на глазах сотен тысяч человек провел эксперимент.
Взял область, в которой у него не было ни таланта, ни опыта, и публично объявил, что он — певец. Начал выкладывать треки: кривые-косые. Несколько месяцев проходил через публичный хейт «раннего творчества». Но с каждым днем его записи становились все лучше. И достигли вполне приемлемого качества. Стал ли он претендентом на Грэмми? Нет. Но он стал из очень слабого вполне нормальным исполнителем.
Мораль: когда мы выходим в паблик, нам неизбежно придется смириться, что наши выступления не похожи на стэнфордскую речь Джобса. И что люди не бросают в воздух чепчики.
❗️Личный бренд работодателя VS ваш личный бренд
Дороничев пришел в Google на пару лет и задержался на 13. Когда он уходил, ему написала CEO YouTube с предложением остаться. Андрей посчитал миллионы долларов, которые теряет с уходом. И…ответил, что увольняется, потому «больше не понимает, кто он такой».
Работая в крупной компании с яркой культурой и идентичностью, очень важно отслеживать, как там поживает ваша собственная идентичность. И если вдруг в какой-то момент на вопрос «Кто я?» вашим первым ответом становится «Сотрудник Google, Яндекс, McKinsey, etc» —
❗️В мире точно есть люди, которым полезен ваш опыт. Важно хотеть им поделиться.
После выхода из Google Андрей осознал свою новую миссию: нести знания о мире инвестиций, IT и Кремниевой долине, в том числе через блог. Интересно ли это всем в масштабах человечества? Нет. Но точно есть сотни и тысячи людей, которым это мегаполезно.
Кому можете быть полезны вы, если вы не руководитель всемирно известного продукта, а просто хороший продакт?
Вчера на моей лекции в Вышке одна из студенток поделилась, что думает над переходом из SMM в продукт, но не понимает, с чего начать. Чем не миссия – круто рассказывать о своей работе классным ребятам, которые только выбирают свой профессиональный трек? Think about it!
Трансформации по плану и трансформации «по дизастеру»
Иногда жизнь дает нам возможность сформулировать точку B, подготовить почву для перехода, сформировать тактику и ее придерживаться. А иногда – с ноги выталкивает в сетап, где твой счет с 10 миллионами долларов, которые ты нарэйзил, за ночь превращается в тыкву.
И это тоже – не конец жизни.
В общем, очень советую вам посмотреть это видео,
📺Приятного просмотра!
Telegram
Моя жизнь в IT/Губарева
Весь 2024 я выступала про комьюнити и развитие бренда эксперта.
Аудиторией были IT-профессионалы, фаундеры, представители благотворительных организаций. Разные ребята с разным уровнем амбиций и опыта. Но, когда я спрашивала, что зацепило, 80% отвечали:…
Аудиторией были IT-профессионалы, фаундеры, представители благотворительных организаций. Разные ребята с разным уровнем амбиций и опыта. Но, когда я спрашивала, что зацепило, 80% отвечали:…
Forwarded from Моя жизнь в IT/Губарева
Гордиться нельзя обесценить
или Есть ли место гуманитариям в IT?
Спойлер:Еще как!
В последнее время в частных и публичных разговорах часто всплывает тема «Гуманитарий в IT». Что, в общем, логично. Я много рассказываю, как нашла профессиональное счастье в инженерной компании, «исторически» будучи журналистом и пиарщиком.
Как гуманитарию попасть в IT?
Как там выжить?
Как добиться, чтобы эти божественные создания, умеющие перемножать в уме трехзначные числа и писать на языке С++, увидели в тебе профессионала, а не…
Если вы гуманитарий иеще так думаете...во-первых, вы не одиноки. 99,9% представителей «софтовых» профессий – коммуникации, HR, креативщики и дизайнеры, юристы – хотя бы раз чувствовали себя рядом с инженерами…не такими умными. #Metoo
Поэтому выдохните: испытывать сложные чувства, понимая, что вы говорите на разных языках – на старте абсолютно нормально.
А после старта у «гуманитария» в IT два пути:
⛔️Продолжить жить с ощущением человека, которому при рождении выдали «не те» мозги.
✅ Осознать, что ваша экспертиза, если это действительно экспертиза, не менее ценна. Просто она в другом домене.
Для себя я это сформулировала так. Экспертам из технологий так же сложно, больно и непонятно погружаться в «наши» тонкости коммуникаций, как нам – в «их»алгоритмы.
Приведу два примера
Первый. Пару месяцев назад мы с арт-директором Аней Кацур выступали с лекцией по профессиональному бренду перед инженерами. Накануне я очень переживала за низкую плотность информации.
Результат: когда после лекции мы попросили фидбэк, ребята предложили упростить контент, потому что местами было трудно и нужно больше времени, чтобы комфортно осмыслить в моменте.
Второй пример – в интервью Андрей Дороничев, создатель мобильного YouTube, на минуточку, на реплику «Знаешь, это как кольцевая композиция в литературе?» ответил: «Слишком сложно».
И это не лукавство и не кокетство. То, в чем мы плаваем, как рыбы в воде, ловим из воздуха и вообще непонятно откуда знаем, многим ребятам-технарям правда сложно.
Кто круче, Набоков или Шостакович? Наверно, вы скажете, что вопрос некорректен.
Математика и написание кода, как и музыка, требуют более высокого уровня абстракции. Но значит ли это, что литература как искусство менее ценно?
От метафор – к практике.
❗️Советы всем, кому посчастливилось(и это не сарказм) родиться гуманитарием
📌Не надо судорожно учить Python. Качайте свои и без того сильные стороны: эмпатию, умение держать контекст, креатив, сторителлинг, навыки фасилитации.
У вас первый разряд по переговорам? Станьте КМС!
Таким образом, ваши сильные стороны превратятся в суперсилы и супераргументы для работодателя. Ведь именно все вышеперечисленные навыки во многом определяют успех и стоимость руководителей и топовых экспертов в крутых компаниях.
📌Научитесь переключаться на язык собеседника. В том числе на язык цифр, если для вашего визави он – основной.
Так устроен мир, что коммуникационная гибкость – на нашей стороне, и за создание общего пространства для взаимопонимания в инженерных компаниях базово отвечаем мы.
📌Качайте навыки презентации и самопрезентации: сторителлинга, публичных выступлений, визуализации. Эти «софты» – во многом наши харды. По ним нас встречаюти провожают
📌Не прячьте себя. Поверьте, ваше глубокое понимание культуры и насмотренность в искусстве делают вас для коллег в IT интересным собеседником, даже если на митингах выпока не читаете Бродского и не обсуждаете Гогена.
❗️Что делать, если вы все же оказались в токсичной культуре – неважно, технарь вы или гуманитарий?
Мы, люди, владеющие словом, при всей эмпатии порой тоже можем ого-го как «зажечь»
Отстаивайте свое право работать в комфортной атмосфере.
На токсичные шутки и обесценивающие комментарии можно и нужно отвечать. Вежливо, но твердо, ставя собеседника на место. Тем более, что обычно такие кейсы возникают не потому, что кто-то хотел специально обидеть. А потому, не очень осознавал, как это воспринимается другой стороной.
Кто вы?
🔥- технарь
❤️- гуманитарий
😎- по ситуации
🤔- мне эта дискуссия вообще не близка
или Есть ли место гуманитариям в IT?
Спойлер:
В последнее время в частных и публичных разговорах часто всплывает тема «Гуманитарий в IT». Что, в общем, логично. Я много рассказываю, как нашла профессиональное счастье в инженерной компании, «исторически» будучи журналистом и пиарщиком.
Как гуманитарию попасть в IT?
Как там выжить?
Как добиться, чтобы эти божественные создания, умеющие перемножать в уме трехзначные числа и писать на языке С++, увидели в тебе профессионала, а не…
Если вы гуманитарий и
Поэтому выдохните: испытывать сложные чувства, понимая, что вы говорите на разных языках – на старте абсолютно нормально.
А после старта у «гуманитария» в IT два пути:
⛔️Продолжить жить с ощущением человека, которому при рождении выдали «не те» мозги.
Для себя я это сформулировала так. Экспертам из технологий так же сложно, больно и непонятно погружаться в «наши» тонкости коммуникаций, как нам – в «их»алгоритмы.
Приведу два примера
Первый. Пару месяцев назад мы с арт-директором Аней Кацур выступали с лекцией по профессиональному бренду перед инженерами. Накануне я очень переживала за низкую плотность информации.
Результат: когда после лекции мы попросили фидбэк, ребята предложили упростить контент, потому что местами было трудно и нужно больше времени, чтобы комфортно осмыслить в моменте.
Второй пример – в интервью Андрей Дороничев, создатель мобильного YouTube, на минуточку, на реплику «Знаешь, это как кольцевая композиция в литературе?» ответил: «Слишком сложно».
И это не лукавство и не кокетство. То, в чем мы плаваем, как рыбы в воде, ловим из воздуха и вообще непонятно откуда знаем, многим ребятам-технарям правда сложно.
Кто круче, Набоков или Шостакович? Наверно, вы скажете, что вопрос некорректен.
Математика и написание кода, как и музыка, требуют более высокого уровня абстракции. Но значит ли это, что литература как искусство менее ценно?
От метафор – к практике.
❗️Советы всем, кому посчастливилось
📌Не надо судорожно учить Python. Качайте свои и без того сильные стороны: эмпатию, умение держать контекст, креатив, сторителлинг, навыки фасилитации.
У вас первый разряд по переговорам? Станьте КМС!
Таким образом, ваши сильные стороны превратятся в суперсилы и супераргументы для работодателя. Ведь именно все вышеперечисленные навыки во многом определяют успех и стоимость руководителей и топовых экспертов в крутых компаниях.
📌Научитесь переключаться на язык собеседника. В том числе на язык цифр, если для вашего визави он – основной.
Так устроен мир, что коммуникационная гибкость – на нашей стороне, и за создание общего пространства для взаимопонимания в инженерных компаниях базово отвечаем мы.
📌Качайте навыки презентации и самопрезентации: сторителлинга, публичных выступлений, визуализации. Эти «софты» – во многом наши харды. По ним нас встречают
📌Не прячьте себя. Поверьте, ваше глубокое понимание культуры и насмотренность в искусстве делают вас для коллег в IT интересным собеседником, даже если на митингах вы
❗️Что делать, если вы все же оказались в токсичной культуре – неважно, технарь вы или гуманитарий?
Отстаивайте свое право работать в комфортной атмосфере.
На токсичные шутки и обесценивающие комментарии можно и нужно отвечать. Вежливо, но твердо, ставя собеседника на место. Тем более, что обычно такие кейсы возникают не потому, что кто-то хотел специально обидеть. А потому, не очень осознавал, как это воспринимается другой стороной.
Кто вы?
🔥- технарь
❤️- гуманитарий
😎- по ситуации
🤔- мне эта дискуссия вообще не близка
Please open Telegram to view this post
VIEW IN TELEGRAM
Telegram
Моя жизнь в IT/Губарева
#Мыслинамысли: личный бренд, корпорации и жизнь
Вчера вечером мобильный YouTube подбросил интервью своего создателя — Андрея Дороничева. Он же — герой легендарного фильма Дудя ⢂⠴⡢⢡⢂⠃⢨⢠ ⢢⠰⠔⢊⠌⡒⢰⠙⣠⠑ ⠍ ⡉⢤⠆ «Кремниевая долина» и фаундер Optic — одного из самых…
Вчера вечером мобильный YouTube подбросил интервью своего создателя — Андрея Дороничева. Он же — герой легендарного фильма Дудя ⢂⠴⡢⢡⢂⠃⢨⢠ ⢢⠰⠔⢊⠌⡒⢰⠙⣠⠑ ⠍ ⡉⢤⠆ «Кремниевая долина» и фаундер Optic — одного из самых…
Forwarded from NLP Wanderer
FlexAttention: Новый стандарт для реализации Attention в PyTorch
Кажется добавление такой фичи в Pytorch 2.5.0 осталось немного незамеченным, но так как его активно использует в своем коде lucidrains я решил про нее написать подробнее.
В теории, Attention is All You Need, но на практике оптимизированные реализации блоков внимания, такие как FlashAttention, стали необходимостью. Они добились значительного улучшения производительности относительно текущей реализации в Pytorch, позволив эффективно работать с длинным контекстом и не только. Однако, за такую эффективность пришлось заплатить — гибкость решений сильно пострадала. Сегодня внедрение новых вариантов Attention зачастую требует написания кастомных CUDA-ядер, что превращает экспериментирование в настоящую лотерею для резерчеров. Если ваши идеи не укладываются в уже существующие ядра, вас ждут медленный runtime или проблемы с памятью, а также куча низкоуровневой возни.
И к чему все это идет?
Разнообразие модификаций Attention уже велико и продолжает расти: Causal, Relative Positional Embeddings, Alibi, Sliding Window Attention, PrefixLM, Document Masking, Tanh Soft-Capping, PagedAttention и многие другие. Более того, комбинации этих технологий часто необходимы для конкретных задач — например, сочетание Sliding Window Attention + Document Masking + Causal. Однако существующие подходы предлагают крайне ограниченную поддержку таких возможностей, что серьезно ограничивает свободу разработчиков.
FlexAttention: новый подход, нативный для Pytorch
В Pytorch с этим не хотят мирится, поэтому принялись за разработку нового стандарта. Среди свойств нового модуля
• Гибкость API — теперь реализация новых вариантов Attention занимает всего несколько строк кода.
• Оптимизация производительности — API автоматически преобразует ваш код в оптимизированное FlashAttention-ядро через torch.compile, избегая материализации лишней памяти.
• Автоматический backward pass — PyTorch autograd берет на себя генерацию обратного прохода.
• Работа со спарсностью — FlexAttention эффективно использует разреженные attention-маски, что дополнительно ускоряет вычисления.
Это решение делает исследование и внедрение новых идей значительно проще, ограничивая вас лишь вашей фантазией.
Примеры использования FlexAttention и туториалы можно найти в коллекции реализаций AttentionGym.
Производительность
FlexAttention уже демонстрирует конкурентоспособные результаты. На A100 решение достигает 90% производительности FlashAttention2 в прямом проходе и 85% в backward pass. Тем не менее, за универсальность приходится платить: некоторое падение производительности связано с дополнительными вычислениями во время работы. Разработчики планируют оптимизировать backward pass и минимизировать это отставание в скором будущем.
Несмотря на небольшие компромиссы в производительности, FlexAttention уже показал значительную практическую ценность. Например, он позволил увеличить throughput в torchtune (PyTorch native post-training library) на 71% и избавил исследователей от необходимости тратить недели на разработку кастомных ядер.
Ограничения и перспективы
• Ведутся работы над улучшением производительности до уровня FlashAttention3 на H100 GPU.
• Пока что длина последовательностей должна быть кратна 128, но это будет исправлено.
Кажется добавление такой фичи в Pytorch 2.5.0 осталось немного незамеченным, но так как его активно использует в своем коде lucidrains я решил про нее написать подробнее.
В теории, Attention is All You Need, но на практике оптимизированные реализации блоков внимания, такие как FlashAttention, стали необходимостью. Они добились значительного улучшения производительности относительно текущей реализации в Pytorch, позволив эффективно работать с длинным контекстом и не только. Однако, за такую эффективность пришлось заплатить — гибкость решений сильно пострадала. Сегодня внедрение новых вариантов Attention зачастую требует написания кастомных CUDA-ядер, что превращает экспериментирование в настоящую лотерею для резерчеров. Если ваши идеи не укладываются в уже существующие ядра, вас ждут медленный runtime или проблемы с памятью, а также куча низкоуровневой возни.
И к чему все это идет?
Разнообразие модификаций Attention уже велико и продолжает расти: Causal, Relative Positional Embeddings, Alibi, Sliding Window Attention, PrefixLM, Document Masking, Tanh Soft-Capping, PagedAttention и многие другие. Более того, комбинации этих технологий часто необходимы для конкретных задач — например, сочетание Sliding Window Attention + Document Masking + Causal. Однако существующие подходы предлагают крайне ограниченную поддержку таких возможностей, что серьезно ограничивает свободу разработчиков.
FlexAttention: новый подход, нативный для Pytorch
В Pytorch с этим не хотят мирится, поэтому принялись за разработку нового стандарта. Среди свойств нового модуля
torch.nn.attention.flex_attention:• Гибкость API — теперь реализация новых вариантов Attention занимает всего несколько строк кода.
• Оптимизация производительности — API автоматически преобразует ваш код в оптимизированное FlashAttention-ядро через torch.compile, избегая материализации лишней памяти.
• Автоматический backward pass — PyTorch autograd берет на себя генерацию обратного прохода.
• Работа со спарсностью — FlexAttention эффективно использует разреженные attention-маски, что дополнительно ускоряет вычисления.
Это решение делает исследование и внедрение новых идей значительно проще, ограничивая вас лишь вашей фантазией.
Примеры использования FlexAttention и туториалы можно найти в коллекции реализаций AttentionGym.
Производительность
FlexAttention уже демонстрирует конкурентоспособные результаты. На A100 решение достигает 90% производительности FlashAttention2 в прямом проходе и 85% в backward pass. Тем не менее, за универсальность приходится платить: некоторое падение производительности связано с дополнительными вычислениями во время работы. Разработчики планируют оптимизировать backward pass и минимизировать это отставание в скором будущем.
Несмотря на небольшие компромиссы в производительности, FlexAttention уже показал значительную практическую ценность. Например, он позволил увеличить throughput в torchtune (PyTorch native post-training library) на 71% и избавил исследователей от необходимости тратить недели на разработку кастомных ядер.
Ограничения и перспективы
• Ведутся работы над улучшением производительности до уровня FlashAttention3 на H100 GPU.
• Пока что длина последовательностей должна быть кратна 128, но это будет исправлено.