Forwarded from Заскуль питона (Data Science)
Как бороться с переобучением в ML
Считаете вы значит свои данные на тренировочных данных, качество хорошее, нужно внедрять в прод. Смотрите на тестовых — все плохо. Достаточно понятное объяснение: модель подстроилась под тренировочные данные.
Чем это грозит? Когда будем получать новые данные, модель не сможет адекватно интерпретировать нашу реальность, из-за чего будем страдать. Неадекватные прогнозы, плохое обобщение модели, неверные решения для бизнеса, убытки. В общем, всехорошо приемлемо 👨⚖️
Что можно с этим сделать
1. Больше качественных данных. Взять больше выборку, предобработать лучше. Минусы: не всегда есть эти данные. Возможно, мы уже взяли те самые 100% на которых мы обучаем👀 . У меня в магистратуре есть курс по предподготовке и анализу данных. Считаю его одним из самых важных. Об этом напишу в следующих постах.
2. Регуляризация. Модель может штрафовать за сложность. Чем проще модель, тем меньше она запоминает шум в данных. Без нее модель может выучить все подряд. Почитать можно тут, все хорошо объяснено. Практически всегда стоит начинать со включенной регуляризации, если понимаете за что каждый из видов отвечает.
3. Уменьшить сложность модели. Несмотря на то, что могут быть более мощные модели, они имеют свойство переобучаться. Например, для деревьев можно ограничить глубину. Попробовать сократить количество фичей и использовать более простую модель🤔
4. Замерять качество на валидационном датасете. Сравнивать качество на тренировочных и тестовых данных, а дальше тюнить в зависимости от обнаружения проблемы по метрикам качества модели. Про то как работать с кросс-валидацией написано тут🍪 🍪
5. Feature Selection. Определять важные для модели фичи, которые можно будет легко интерпретировать. Лучше использовать 10 хороших фичей, чем 200 случайных. Про простенький вариант на примере Титаника😮
6. Аугментация и добавление синтетических данных. Можно обмануть алгоритм, добавив шум, предоставить те же семплы данных, но немного измененные. Обычно это подходит для CV и NLP. Например, когда, мы подаем в модель повернутые картинки котиков, искусственно масштабируя датасет. Здесь также можно применить и SMOTE / ADASYN🙊 . Важно: все oversampling / SMOTE только на тренировочной выборке, иначе будет data leakage (утечка данных). О том, что это и как с этим бороться — тут.
7. Раннее прекращение обучения модели. Если качество на валидации перестаёт расти или начинает ухудшаться, обучение стоит остановить. Дальше модель может запоминать только шум. Например, останавливать обучение, если после N итераций качество на валидации не улучшается (как это указано на картинке).
Вот здесь неплохо рассказано про то, как проявляется переобучение у разных моделей машинного обучения и не только.
Но все должно быть объяснимо, почему может возникнуть переобучение, проблемные случаи и так далее. Мы же не на Kaggle🔑 , чтобы оптимизировать модели вслепую ради скора, а должны смотреть на все комплексно
Что-то забыл? Пишите в комментариях! Ставьте🤪 , если понравился пост! Планирую по 💻 писать больше, так как учусь на него, ну...
@zasql_python
Считаете вы значит свои данные на тренировочных данных, качество хорошее, нужно внедрять в прод. Смотрите на тестовых — все плохо. Достаточно понятное объяснение: модель подстроилась под тренировочные данные.
Чем это грозит? Когда будем получать новые данные, модель не сможет адекватно интерпретировать нашу реальность, из-за чего будем страдать. Неадекватные прогнозы, плохое обобщение модели, неверные решения для бизнеса, убытки. В общем, все
Вся эта борьба по сути, управление bias–variance tradeoff: либо модель слишком простая, либо слишком подгоняется под шум.
Что можно с этим сделать
1. Больше качественных данных. Взять больше выборку, предобработать лучше. Минусы: не всегда есть эти данные. Возможно, мы уже взяли те самые 100% на которых мы обучаем
2. Регуляризация. Модель может штрафовать за сложность. Чем проще модель, тем меньше она запоминает шум в данных. Без нее модель может выучить все подряд. Почитать можно тут, все хорошо объяснено. Практически всегда стоит начинать со включенной регуляризации, если понимаете за что каждый из видов отвечает.
3. Уменьшить сложность модели. Несмотря на то, что могут быть более мощные модели, они имеют свойство переобучаться. Например, для деревьев можно ограничить глубину. Попробовать сократить количество фичей и использовать более простую модель
4. Замерять качество на валидационном датасете. Сравнивать качество на тренировочных и тестовых данных, а дальше тюнить в зависимости от обнаружения проблемы по метрикам качества модели. Про то как работать с кросс-валидацией написано тут
5. Feature Selection. Определять важные для модели фичи, которые можно будет легко интерпретировать. Лучше использовать 10 хороших фичей, чем 200 случайных. Про простенький вариант на примере Титаника
6. Аугментация и добавление синтетических данных. Можно обмануть алгоритм, добавив шум, предоставить те же семплы данных, но немного измененные. Обычно это подходит для CV и NLP. Например, когда, мы подаем в модель повернутые картинки котиков, искусственно масштабируя датасет. Здесь также можно применить и SMOTE / ADASYN
7. Раннее прекращение обучения модели. Если качество на валидации перестаёт расти или начинает ухудшаться, обучение стоит остановить. Дальше модель может запоминать только шум. Например, останавливать обучение, если после N итераций качество на валидации не улучшается (как это указано на картинке).
Вот здесь неплохо рассказано про то, как проявляется переобучение у разных моделей машинного обучения и не только.
Хорошая модель — это не та, что идеальна на трейне, а та, что стабильно работает на новых данных🤓
Но все должно быть объяснимо, почему может возникнуть переобучение, проблемные случаи и так далее. Мы же не на Kaggle
Что-то забыл? Пишите в комментариях! Ставьте
@zasql_python
Please open Telegram to view this post
VIEW IN TELEGRAM
Forwarded from Роман с данными
Ключевые выводы McKinsey из отчета The State of AI in 2025 о применении AI агентов
1. Большинство организаций всё ещё находятся на стадии экспериментов или пилотных проектов: две трети респондентов говорят, что их организации пока не начали масштабировать ИИ на уровне всей компании.
2. Высокий интерес к ИИ-агентам: 62% участников опроса отмечают, что их организации как минимум экспериментируют с ИИ-агентами.
3. Позитивные ранние сигналы влияния ИИ: Респонденты сообщают о выгодах по отдельным сценариям применения — снижении затрат и росте выручки — и 64% говорят, что ИИ помогает инновациям.
4. Лидеры используют ИИ для роста, инноваций и снижения затрат: 80% респондентов говорят, что их компании ставят повышение эффективности целью ИИ-инициатив.
5. Перепроектирование рабочих процессов — ключевой фактор успеха: половина наиболее успешных компаний в ИИ намерена использовать ИИ для трансформации бизнеса, и большинство из них пересматривают рабочие процессы.
Цифры крутые! Но потом читаю юмористические посты
Вити Тарнавского https://t.iss.one/singularityfm/375
Леши Хахунова https://t.iss.one/aihappens/392
И складывается картинка как их внедряют😀😀😀
1. Большинство организаций всё ещё находятся на стадии экспериментов или пилотных проектов: две трети респондентов говорят, что их организации пока не начали масштабировать ИИ на уровне всей компании.
2. Высокий интерес к ИИ-агентам: 62% участников опроса отмечают, что их организации как минимум экспериментируют с ИИ-агентами.
3. Позитивные ранние сигналы влияния ИИ: Респонденты сообщают о выгодах по отдельным сценариям применения — снижении затрат и росте выручки — и 64% говорят, что ИИ помогает инновациям.
4. Лидеры используют ИИ для роста, инноваций и снижения затрат: 80% респондентов говорят, что их компании ставят повышение эффективности целью ИИ-инициатив.
5. Перепроектирование рабочих процессов — ключевой фактор успеха: половина наиболее успешных компаний в ИИ намерена использовать ИИ для трансформации бизнеса, и большинство из них пересматривают рабочие процессы.
Цифры крутые! Но потом читаю юмористические посты
Вити Тарнавского https://t.iss.one/singularityfm/375
Леши Хахунова https://t.iss.one/aihappens/392
И складывается картинка как их внедряют😀😀😀
Forwarded from Токсичный (it) архитектор
Давайте начистоту. Доступность (Availability) - это не галочка в Jira. Это самая дорогая и лживая метрика в IT. Вы не можете просто «выбрать доступность». Вы покупаете ее. За деньги, сложность и бессонные ночи вашей команды поддержки.
Идея о «видах» доступности - это самообман. Есть только цена, которую вы готовы заплатить за сокращение времени простоя.
Это ваш типичный проект-монолит на одном сервере. Доступен ли он? Да, пока сервер работает. Когда он падает - из-за сбоя питания, обновления ОС или потому что уборщица выдернула шнур - система недоступна. Все просто и честно. Это ларек с шаурмой. Если продавец заболел, ларек закрыт. Никто не ждет от него доступности 24/7.
Когда это нормально: 90% внутренних систем, админок, MVP, которые вы показываете инвестору. Короче, везде, где минута простоя стоит дешевле, чем зарплата еще одного инженера.
Это примерно 8.7 часов простоя в год. Чтобы этого достичь, одного сервера уже мало. Вам нужен как минимум второй сервер и балансировщик нагрузки. Теперь, если один сервер падает, второй подхватывает трафик. Звучит просто? А теперь подумайте: вам нужна репликация данных между ними, консистентность этих данных, система мониторинга, которая поймет, что первый сервер упал, и автоматический механизм переключения. Ваша архитектура усложнилась в три раза. Цена - деньги на железо и зарплата DevOps-инженера.
Когда это нужно: Обычные интернет-магазины, контентные сайты. Бизнес, который теряет деньги каждую минуту простоя, но может пережить сбой в 3 часа ночи раз в квартал.
Это 5 минут простоя в год. ПЯТЬ. МИНУТ. Это включает время на развертывание, обновление, любые сбои. Чтобы достичь такого, вам уже недостаточно двух серверов. Вам нужны несколько дата-центров в разных городах. Геораспределенная репликация. Автоматическое восстановление после сбоев. Канареечные релизы. Команда SRE-инженеров, которые 24/7 смотрят в дашборды. Это стоит как чугунный мост.
Когда это нужно: Телекоммуникации, процессинг банковских карт, системы управления воздушным движением. Там, где цена пяти минут простоя - это миллионы денег или человеческие жизни. Если вы пытаетесь прикрутить это к своему приложению для заказа смузи, вы - идиот.
Вы все еще хотите поговорить о «видах» доступности? Это не виды. Это ценники.
Перестаньте гоняться за девятками, как за покемонами. Вместо этого задайте себе и бизнесу один-единственный вопрос:
Сколько денег мы теряем за каждую минуту простоя нашего сервиса?
Посчитайте. А потом посчитайте, сколько будет стоить переход с 99% на 99.9%. Если вторая цифра больше первой - поздравляю, вы только что сэкономили компании кучу денег и избавили своих инженеров от бессмысленной работы.
Доступность - это не технология. Это экономика. И тот, кто этого не понимает, обречен платить за свои амбиции из кармана компании.
#этобаза
Токсичный (it) архитектор
Please open Telegram to view this post
VIEW IN TELEGRAM
Forwarded from Инжиниринг Данных (Dmitry)
S3 самый популярный элемент современного технологического мира. И это не обязательно AWS S3, ведь можно создать blob storage on-premise.
В статье How Amazon S3 Works кратко описываю системный дизайн S3. Для масштабирования с высокой производительностью не нужно дорогое оборудование — достаточно умной архитектуры и правильных алгоритмов. Amazon использует недорогие HDD-диски, но компенсирует их ограничения через параллелизм, умную организацию данных и эффективную репликацию.
Альтернативы:
🔄 Крупные облачные провайдеры
Google Cloud Storage — хорошо работает с другими сервисами Google (BigQuery, ML), несколько классов хранения, понятные тарифы, от $0.020/GB в месяц.
Azure Blob Storage — от Microsoft, три уровня хранения (горячий, холодный, архив), отлично интегрируется с Office 365 и Azure, от $0.018/GB в месяц.
IBM Cloud Object Storage — для крупных компаний, автоматически оптимизирует затраты, работает с Watson AI, подходит для банков и медицины.
🔄 Бюджетные варианты без платы за скачивание
Cloudflare R2 — бесплатная отдача данных (egress), быстрая доставка через CDN Cloudflare, хранение $0.015/GB в месяц.
Wasabi — один тариф $6.99/TB в месяц, нет платы за скачивание и API-запросы, все данные доступны мгновенно.
Backblaze B2 — очень дешево $6/TB в месяц, бесплатное скачивание до 3x от объема хранения, полностью бесплатно с Cloudflare CDN.
🔄 Для разработчиков
DigitalOcean Spaces — простой и понятный, $5/месяц за 250GB + 1TB трафика, встроенная CDN, легко настроить.
iDrive e2 — до 80% дешевле S3 ($0.005/GB в месяц), нет платы за трафик, простой интерфейс.
Hetzner Object Storage — европейский провайдер, $0.00713/GB в месяц, очень дешевое скачивание ($0.00143/GB), соответствует GDPR.
🔄 Другие варианты
Oracle Cloud — 10GB бесплатно навсегда, архив от $0.0026/GB в месяц.
Telnyx Storage — быстрый, низкие задержки, бесплатное скачивание, до 100 бакетов бесплатно.
Storj — децентрализованное хранилище на блокчейне, данные распределены по тысячам серверов, повышенная безопасность.
🔄 Альтернативы on-premise
MinIO — самый популярный open-source, полностью совместим с S3, очень быстрый (до 183 GB/s), хорошо работает с Kubernetes и ML.
Ceph — мощная система для больших компаний, поддерживает объекты, блоки и файлы, масштабируется до петабайтов, но сложная в настройке.
OpenIO — быстрый, для AI/ML и big data, совместим с S3, можно комбинировать с облаком.
Cloudian HyperStore — коммерческое решение, совместимо с S3, полный контроль над данными, поддержка 24/7, для банков и госструктур.
SeaweedFS — легкий и быстрый, написан на Go, хорошо работает с миллиардами маленьких файлов (фото, документы).
Rook — упрощает работу с Ceph в Kubernetes, автоматическое масштабирование и восстановление.
GlusterFS — объединяет обычные серверы в одно хранилище, проще чем Ceph, поддержка от Red Hat.
LocalStack — эмулирует 90+ сервисов AWS на вашем компьютере, можно разрабатывать и тестировать без затрат и подключения к интернету.
Из всего списка я работал с классикой Google Cloud Storage, AWS S3, Azure Storage и использовал LocalStack для CI pipelines. Часто попадалась информация про MiniO S3 и Cloudflare R2 или Hetzner.
В статье How Amazon S3 Works кратко описываю системный дизайн S3. Для масштабирования с высокой производительностью не нужно дорогое оборудование — достаточно умной архитектуры и правильных алгоритмов. Amazon использует недорогие HDD-диски, но компенсирует их ограничения через параллелизм, умную организацию данных и эффективную репликацию.
Альтернативы:
Google Cloud Storage — хорошо работает с другими сервисами Google (BigQuery, ML), несколько классов хранения, понятные тарифы, от $0.020/GB в месяц.
Azure Blob Storage — от Microsoft, три уровня хранения (горячий, холодный, архив), отлично интегрируется с Office 365 и Azure, от $0.018/GB в месяц.
IBM Cloud Object Storage — для крупных компаний, автоматически оптимизирует затраты, работает с Watson AI, подходит для банков и медицины.
Cloudflare R2 — бесплатная отдача данных (egress), быстрая доставка через CDN Cloudflare, хранение $0.015/GB в месяц.
Wasabi — один тариф $6.99/TB в месяц, нет платы за скачивание и API-запросы, все данные доступны мгновенно.
Backblaze B2 — очень дешево $6/TB в месяц, бесплатное скачивание до 3x от объема хранения, полностью бесплатно с Cloudflare CDN.
DigitalOcean Spaces — простой и понятный, $5/месяц за 250GB + 1TB трафика, встроенная CDN, легко настроить.
iDrive e2 — до 80% дешевле S3 ($0.005/GB в месяц), нет платы за трафик, простой интерфейс.
Hetzner Object Storage — европейский провайдер, $0.00713/GB в месяц, очень дешевое скачивание ($0.00143/GB), соответствует GDPR.
Oracle Cloud — 10GB бесплатно навсегда, архив от $0.0026/GB в месяц.
Telnyx Storage — быстрый, низкие задержки, бесплатное скачивание, до 100 бакетов бесплатно.
Storj — децентрализованное хранилище на блокчейне, данные распределены по тысячам серверов, повышенная безопасность.
MinIO — самый популярный open-source, полностью совместим с S3, очень быстрый (до 183 GB/s), хорошо работает с Kubernetes и ML.
Ceph — мощная система для больших компаний, поддерживает объекты, блоки и файлы, масштабируется до петабайтов, но сложная в настройке.
OpenIO — быстрый, для AI/ML и big data, совместим с S3, можно комбинировать с облаком.
Cloudian HyperStore — коммерческое решение, совместимо с S3, полный контроль над данными, поддержка 24/7, для банков и госструктур.
SeaweedFS — легкий и быстрый, написан на Go, хорошо работает с миллиардами маленьких файлов (фото, документы).
Rook — упрощает работу с Ceph в Kubernetes, автоматическое масштабирование и восстановление.
GlusterFS — объединяет обычные серверы в одно хранилище, проще чем Ceph, поддержка от Red Hat.
LocalStack — эмулирует 90+ сервисов AWS на вашем компьютере, можно разрабатывать и тестировать без затрат и подключения к интернету.
Из всего списка я работал с классикой Google Cloud Storage, AWS S3, Azure Storage и использовал LocalStack для CI pipelines. Часто попадалась информация про MiniO S3 и Cloudflare R2 или Hetzner.
Please open Telegram to view this post
VIEW IN TELEGRAM
newsletter.systemdesign.one
How Amazon S3 Works ✨
#59: Break Into Amazon Engineering (4 Minutes)
Forwarded from Находки в опенсорсе
git-lfs: храним большие файлы в репозитории правильно
https://www.youtube.com/watch?v=82wj6y2rmR4
Вы сталкивались с проблемой, что рабочий проект клонируется 10 минут?
А когда начинаешь разбираться: почему так? То оказывается, что внутри десятки непережатых картинок для фронта, которые еще и менялись регулярно (а значит, оставили след в истории git навсегда).
Данная проблема влияет не только на локальное использование, ведь мы на самом деле довольно редко делаем
Решение: использовать git-lfs!
Я пригласил замечательного Олега Чирухина @tg_1red2black, чтобы обсудить:
- Как работает git-lfs на базовом уровне?
- Как мигрировать на него с базового сетапа?
- Как он устроен внутри? Поднимаем https://github.com/git-lfs/lfs-test-server и детально смотрим, что там внутри происходит
Ну и конечно чуть-чуть глянули исходники, они, кстати, на #go 🌚️️️️
Обсуждение: как вы храните большие файлы в рабочих проектах? Насколько большие файлы вы храните?
| Поддержать | YouTube | GitHub | Чат |
https://www.youtube.com/watch?v=82wj6y2rmR4
Вы сталкивались с проблемой, что рабочий проект клонируется 10 минут?
А когда начинаешь разбираться: почему так? То оказывается, что внутри десятки непережатых картинок для фронта, которые еще и менялись регулярно (а значит, оставили след в истории git навсегда).
Данная проблема влияет не только на локальное использование, ведь мы на самом деле довольно редко делаем
git clone с нуля, но и самое главное – на скорость всех наших сборок (если мы не используем fetch-depth: 1 или аналог, а использовать их надо). Решение: использовать git-lfs!
Я пригласил замечательного Олега Чирухина @tg_1red2black, чтобы обсудить:
- Как работает git-lfs на базовом уровне?
- Как мигрировать на него с базового сетапа?
- Как он устроен внутри? Поднимаем https://github.com/git-lfs/lfs-test-server и детально смотрим, что там внутри происходит
Ну и конечно чуть-чуть глянули исходники, они, кстати, на #go 🌚️️️️
Обсуждение: как вы храните большие файлы в рабочих проектах? Насколько большие файлы вы храните?
| Поддержать | YouTube | GitHub | Чат |
Forwarded from Ctrl+Shift+Boss
Что происходит, когда вы нажимаете “в корзину”?
Снаружи — будто бы магия.
Нажали кнопку — и через долю секунды товар уже в корзине, или вам назначили машину такси.
Но под капотом — целый город из сервисов, очередей, роутеров, балансеров и хранилищ.
Современный бигтех-бэкенд — это давно уже не «один сервер и база».
Это сложная распределённая система, где всё связано со всем.
Чтобы показать, как это работает в реальности,
я сделал
👉 визуальный интерактивный прототип.
Из него вы поймёте:
— что такое балансер,
— зачем нужен L7-роутер,
— почему все говорят про Kafka,
— и как эти штуки взаимодействуют между собой.
Очень советую смотреть с компьютера — так прототип раскрывается гораздо лучше.
И небольшой интерактив:
если хотите такую же версию, но совсем нетехническим языком (для менеджеров) —
набираем 100 лайков, и я делаю.
@ctrlshiftboss 🏆
Снаружи — будто бы магия.
Нажали кнопку — и через долю секунды товар уже в корзине, или вам назначили машину такси.
Но под капотом — целый город из сервисов, очередей, роутеров, балансеров и хранилищ.
Современный бигтех-бэкенд — это давно уже не «один сервер и база».
Это сложная распределённая система, где всё связано со всем.
Чтобы показать, как это работает в реальности,
я сделал
👉 визуальный интерактивный прототип.
Из него вы поймёте:
— что такое балансер,
— зачем нужен L7-роутер,
— почему все говорят про Kafka,
— и как эти штуки взаимодействуют между собой.
Очень советую смотреть с компьютера — так прототип раскрывается гораздо лучше.
И небольшой интерактив:
если хотите такую же версию, но совсем нетехническим языком (для менеджеров) —
набираем 100 лайков, и я делаю.
@ctrlshiftboss 🏆
Forwarded from Дата канальи — про «специалистов» в данных / ML / AI
#ML
Подборка полезного про DS/ML в канале (не кейсами же едиными) — длиннопост по результатам опроса в честь годовщины
1. Про антифрод
2. Критика соц-дем фич и как надо
3. Опасность фичей-счетчиков с рейсом
4. Стат свойства PSI и как сравнивать распределения
5. Критика квартальных и децильных фич
6. ID как фича — плохая идея?
7. Чуть-чуть про adversarial examples
8. Как облажаться с инференсом модели
9. Не все ошибки это плохо
10. Почему Knowledge Graphs оказались тупиковой веткой в Reading Comprehension
11. Как внедрить модель на голом SQL
12. Как объегорить манагера с метриками в задачах регрессии
13. Трансформерные и foundation модели для временных рядов
14. Успех внедрения модели часто зависит от канала доступа к клиентам
15. Опасность библиотек для RecSys — все считают даже базовые метрики по-разному (можете посадить любого собеседующего в лужу)
16. Про пакетные менеджеры в python
17. Старый (2020) но топовые туториал с KDD по связи офлайн- и онлайн-метрик в рекомах
18. Ускорение расчета фич
19. Сначала метрика, потом под нее выбирается лосс — не наоборот
20. Чуть-чуть про WARP-лосс
21. Row_number() vs rank() бывает важно
22. Мультиагентные системы 90х годов XX века
23. Обзор по темпоральным графовым сетям
24. Кейс когда понадобилась модельная архитектура
25. Обзор по алайменту LLM за июль 2024
26. Простой квик вин в кредитном скоринге
27. Кейс про генерацию фич для комплаенс — из названий компаний
28. Калибровка Venn-ABERS
29. Бустрап и ЦПТ в инженерной сейсмометрии с фото с автором
30. Про то что мы не должны забывать что работаем с вычислительными машинами
31. Кейс про графовый attention от корифеев, в котором нашли ошибку, но и сами налажали, как выяснилось уже в комментариях после репоста в дружественные каналы
32. --
33. О пользе дата-аналитиков
34. Про формы нормализации данных
35. Снова про антифрод и как его делать
36. Зачем в LaL псевдолейбеллинг
37. Одна из самых важных моделей почти везде
38. Про расследование для поиска таргета
39. Про landing.ai
40. Чуть-чуть про XAI (explainable AI)
41. Про foundation model для табличных (!) данных
42. МТС-ные курсы про RecSys и. Новый релиз RecTools
43. Интерпретабельность графовых трансформеров
44. В каких редчайших рейсах кластеризация имеет смысл
45. Micrograd
46. Снова про названия компаний
47. Про ФЛК
48. Про связь Binary cross-entropy и NDCG
49. Обзор за март 2025 по нейронкам в RecSys
50. Связь logloss и ROCAUC
51. Как остаться без штанов генеря бенчмарк для своего RAGа
52. Трансформер на golang
53. Как не надо визуализировать данные
54. Как надо визуализировать данные
55. Про актуальность опровержения SMOTE
56. Как ранжируются платные объявления в Авито
57. Схема обучения SASRec
58. Про A/B
59. Трансформер в рекомендациях
60. Как в десять раз сэкономить на API LLM
61. Наш курс по ИИ-агентам
62. Как не надо в антифрод
63. Как появился мой канал
64. Наглядная статистика
65. Логарифмирование таргета помогает или вредит ?
66. Как KPI на внедрение LLM заставляют наводить порядок в данных
67. Наш курс по базе ML
68. Как не надо в прогноз спроса
69. Кейс про особенности инференса на Канадщине
70. eSASRec — наша статья на RecSys2025
71. LLM вдвое эмпатичнее врачей
72. Рекомендации музыки в Звуке
73. Нанобанана
74. Чуть-чуть про RL
75. Подборка по агентам
76. Скачать видео с YouTube без смс и регистрации
77. Воркшоп про дизайн рекомендательных интерфейсов
78. Можно ли по эмбеддингу восстановить текст ?
79. Видео с RecSys 2025
80. Кейс-менеджмент в кейс телефонных мошенников
81. Про матчинг ФЛ
82. Про схемы валидации моделей и связанные с ней мифы
83. Про гороскопы в моделях
84. Про деградацию моделей
Подборка полезного про DS/ML в канале (не кейсами же едиными) — длиннопост по результатам опроса в честь годовщины
1. Про антифрод
2. Критика соц-дем фич и как надо
3. Опасность фичей-счетчиков с рейсом
4. Стат свойства PSI и как сравнивать распределения
5. Критика квартальных и децильных фич
6. ID как фича — плохая идея?
7. Чуть-чуть про adversarial examples
8. Как облажаться с инференсом модели
9. Не все ошибки это плохо
10. Почему Knowledge Graphs оказались тупиковой веткой в Reading Comprehension
11. Как внедрить модель на голом SQL
12. Как объегорить манагера с метриками в задачах регрессии
13. Трансформерные и foundation модели для временных рядов
14. Успех внедрения модели часто зависит от канала доступа к клиентам
15. Опасность библиотек для RecSys — все считают даже базовые метрики по-разному (можете посадить любого собеседующего в лужу)
16. Про пакетные менеджеры в python
17. Старый (2020) но топовые туториал с KDD по связи офлайн- и онлайн-метрик в рекомах
18. Ускорение расчета фич
19. Сначала метрика, потом под нее выбирается лосс — не наоборот
20. Чуть-чуть про WARP-лосс
21. Row_number() vs rank() бывает важно
22. Мультиагентные системы 90х годов XX века
23. Обзор по темпоральным графовым сетям
24. Кейс когда понадобилась модельная архитектура
25. Обзор по алайменту LLM за июль 2024
26. Простой квик вин в кредитном скоринге
27. Кейс про генерацию фич для комплаенс — из названий компаний
28. Калибровка Venn-ABERS
29. Бустрап и ЦПТ в инженерной сейсмометрии с фото с автором
30. Про то что мы не должны забывать что работаем с вычислительными машинами
31. Кейс про графовый attention от корифеев, в котором нашли ошибку, но и сами налажали, как выяснилось уже в комментариях после репоста в дружественные каналы
32. --
33. О пользе дата-аналитиков
34. Про формы нормализации данных
35. Снова про антифрод и как его делать
36. Зачем в LaL псевдолейбеллинг
37. Одна из самых важных моделей почти везде
38. Про расследование для поиска таргета
39. Про landing.ai
40. Чуть-чуть про XAI (explainable AI)
41. Про foundation model для табличных (!) данных
42. МТС-ные курсы про RecSys и. Новый релиз RecTools
43. Интерпретабельность графовых трансформеров
44. В каких редчайших рейсах кластеризация имеет смысл
45. Micrograd
46. Снова про названия компаний
47. Про ФЛК
48. Про связь Binary cross-entropy и NDCG
49. Обзор за март 2025 по нейронкам в RecSys
50. Связь logloss и ROCAUC
51. Как остаться без штанов генеря бенчмарк для своего RAGа
52. Трансформер на golang
53. Как не надо визуализировать данные
54. Как надо визуализировать данные
55. Про актуальность опровержения SMOTE
56. Как ранжируются платные объявления в Авито
57. Схема обучения SASRec
58. Про A/B
59. Трансформер в рекомендациях
60. Как в десять раз сэкономить на API LLM
61. Наш курс по ИИ-агентам
62. Как не надо в антифрод
63. Как появился мой канал
64. Наглядная статистика
65. Логарифмирование таргета помогает или вредит ?
66. Как KPI на внедрение LLM заставляют наводить порядок в данных
67. Наш курс по базе ML
68. Как не надо в прогноз спроса
69. Кейс про особенности инференса на Канадщине
70. eSASRec — наша статья на RecSys2025
71. LLM вдвое эмпатичнее врачей
72. Рекомендации музыки в Звуке
73. Нанобанана
74. Чуть-чуть про RL
75. Подборка по агентам
76. Скачать видео с YouTube без смс и регистрации
77. Воркшоп про дизайн рекомендательных интерфейсов
78. Можно ли по эмбеддингу восстановить текст ?
79. Видео с RecSys 2025
80. Кейс-менеджмент в кейс телефонных мошенников
81. Про матчинг ФЛ
82. Про схемы валидации моделей и связанные с ней мифы
83. Про гороскопы в моделях
84. Про деградацию моделей
Forwarded from Quant Researcher
🎬 Запись лекции для студентов Quant.Courses «Опционы: интуиция, данные и управленческие решения»
Про рынок, риск и то, как на опционы реально смотрят кванты и управляющие:
1. Интуиция рынка через опционы
• зачем вообще появились рынки опционов (исторический контекст 1970-х)
• как бизнес и финансовые институты используют деривативы для управления риском
• почему опционные рынки — это агрегированное мнение о будущем, а не “предсказание”
2. Implied volatility как цена риска
• чем IV принципиально отличается от “реальной” волатильности
• роль спроса/предложения, ликвидности, хедж-флоу и регуляторных ограничений
• почему IV — это всегда риск плюс структура рынка
3. Опционные данные и цепочки
• как читать опционные цепочки и волатильностные поверхности
• где на поверхности есть информация, а где — шум
• почему работа с данными и фильтрация важнее выбора формулы
4. Модели: где помогают, а где мешают
• Black–Scholes–Merton как язык, а не истина
• что на практике делают SSVI, RND, regime switching
• ограничения моделей и опасность “ложного арбитража”
5. Сигналы vs сделки
• почему хороший статистический сигнал не гарантирует PnL
• роль carry, ликвидности и маржи
• как управляющие принимают решения в условиях неопределённости
Запись и материалы
🎥 Запись лекции: https://youtu.be/BBLX4_7lb2Y
📒 Воркбук: https://colab.research.google.com/drive/1qZiPfyYxvI-wC0bEPFsSHImAWABkidwl
🔗 Ресурсы спикеров:
• Канал Лидии: https://t.iss.one/hunt4quant
• Канал Александра: https://t.iss.one/alexandinvestments
• Сайт Бориса: https://bbelyakov.com
Спасибо всем, кто был live и задавал вопросы.
Скоро выйдет подкаст, до связи!
Quant Researcher
Про рынок, риск и то, как на опционы реально смотрят кванты и управляющие:
1. Интуиция рынка через опционы
• зачем вообще появились рынки опционов (исторический контекст 1970-х)
• как бизнес и финансовые институты используют деривативы для управления риском
• почему опционные рынки — это агрегированное мнение о будущем, а не “предсказание”
2. Implied volatility как цена риска
• чем IV принципиально отличается от “реальной” волатильности
• роль спроса/предложения, ликвидности, хедж-флоу и регуляторных ограничений
• почему IV — это всегда риск плюс структура рынка
3. Опционные данные и цепочки
• как читать опционные цепочки и волатильностные поверхности
• где на поверхности есть информация, а где — шум
• почему работа с данными и фильтрация важнее выбора формулы
4. Модели: где помогают, а где мешают
• Black–Scholes–Merton как язык, а не истина
• что на практике делают SSVI, RND, regime switching
• ограничения моделей и опасность “ложного арбитража”
5. Сигналы vs сделки
• почему хороший статистический сигнал не гарантирует PnL
• роль carry, ликвидности и маржи
• как управляющие принимают решения в условиях неопределённости
Запись и материалы
🎥 Запись лекции: https://youtu.be/BBLX4_7lb2Y
📒 Воркбук: https://colab.research.google.com/drive/1qZiPfyYxvI-wC0bEPFsSHImAWABkidwl
🔗 Ресурсы спикеров:
• Канал Лидии: https://t.iss.one/hunt4quant
• Канал Александра: https://t.iss.one/alexandinvestments
• Сайт Бориса: https://bbelyakov.com
Спасибо всем, кто был live и задавал вопросы.
Скоро выйдет подкаст, до связи!
Quant Researcher
YouTube
Опционы: интуиция, данные и управленческие решения
Опционы — это язык ожиданий, страхов и решений.
За 90 минут обсудим:
• как читать рынок через опционы
• чем implied vol отличается от реального риска
• как кванты смотрят на опционные данные
• почему хороший сигнал ≠ хорошая сделка
• где модели помогают…
За 90 минут обсудим:
• как читать рынок через опционы
• чем implied vol отличается от реального риска
• как кванты смотрят на опционные данные
• почему хороший сигнал ≠ хорошая сделка
• где модели помогают…
Forwarded from DziS Science | Data Science
Привет всем!👋
Вот и подходит рабочий год к концу, кажется что можно подводить некоторые итоги работы.
Как вы знаете, подводить итоги я не очень люблю, поэтому в этом посте я бы наверное дал советы тем, кого не так давно кинули в котел тимлидства, которые были опробованы в бою.
Ведь основной мой итог, что моя команда не только выжила, но и даже начинает расцветать с новой силой. Об этом еще обязательно напишу.
Итак, начнем:
1️⃣ 🔤 Семь раз спроси и один раз сделай.
Работа с заказчиками одно из самых сложных в работе лида. Именно по этому перед стартом любого проекта надо обязательно запросить все, что хочет заказчик, но не браться выполнять это сразу, при этом указав минимально возможные сроки.
Возьмите время, визуализируйте таймлайн разработки проекта, разбив на понятные и простые задачи. По непонятным для вас (не знаете как делать/что невозможно сделать) предложите свое видение. Тут есть небольшой психологический ход, если вам не нравится задача, вам кажется она невыполнимой, можно попробовать явно указать плюсы и минусы этой задачи, увеличить срок задачи, мотивируя его "исследованием не пойми чего". Как результат ее можно преобразовать в что-то более выполнимое, либо деприотизировать, мотивируя это тем, что финансовый "выхлоп" задачи будет меньше, чем того, что делать легко и просто.
2️⃣ 🔤 Протокол - наше все.
Да, не ленитесь писать минутки, фиксируя все договоренности. Заказчики не любят, когда они что-то сказали, а вы это забыли. Дополнительно, протокол - ваш друг в спорных ситуациях, когда вы тратите кучу времени на какую-то дополнительную аналитику, эксперименты, которые не были включены в разработку ранее, а при ретро заказчик проекта говорит, что мы на это не договаривались/не помнит что это говорил (такие ситуации редки, но, как говорится, береженного бог бережет).
Также, как показала практика, очень хорошо протоколировать небольшой таймлайн вашего проекта, ведь это ваш ответ на вопрос "почему так долго/чем вы там занимаетесь?". Jira смотрят редко, все любят простые слайды с очевидной и простой подачей, но она поможет восстановить хронологию.
Надо понимать, что заказчик, нередко очень слабо подкован в технической составляющей проекта, поэтому данный таймлайн при использовании должен быть предельно простым: N дней был простой по причине <Причина>, ответственный <USERNAME>.
3️⃣ 🔤 Нет рук? Докажи что они нужны!
Так уж случается, если работа поставлена на конвейер, что приходят новые проекты, но в моменте людей больше не становится. Самый простой способ - построение прототипа с анонсом дальнейшей работы. Работает ровно также как и платная подписка на функционал приложения. Хочешь лучше - оплати сотрудника. В данном случае на помощь мне пришли стажировки, ведь они у меня практически безлимитные, так как не включены в штат и имеют плавающую принадлежность к подразделениям. Любой адекватный стажер может сделать простой MVP без вывода в прод, посчитать метрики и сделать первичную аналитику. Поэтому, тут отказываться от рук, если есть возможность их получить нельзя. Любые руки лучше, чем их отсутствие.
4️⃣ 🔤 Стажировки - круто.
Этот пункт вытекает из предыдущего. Нередко слышу, что на стажировке их заставляли делать <любая неадекватная и бесполезная хрень>. Для качественной стажировки необходимо так называемое win-win решение. Вы получаете руки, которые могут толкать проект в стадии прототипирования, стажер получает боевой опыт, который не стыдно записать в резюме.
продолжение ниже👇
#карьера #трудовые_будни
Вот и подходит рабочий год к концу, кажется что можно подводить некоторые итоги работы.
Как вы знаете, подводить итоги я не очень люблю, поэтому в этом посте я бы наверное дал советы тем, кого не так давно кинули в котел тимлидства, которые были опробованы в бою.
Ведь основной мой итог, что моя команда не только выжила, но и даже начинает расцветать с новой силой. Об этом еще обязательно напишу.
Итак, начнем:
Работа с заказчиками одно из самых сложных в работе лида. Именно по этому перед стартом любого проекта надо обязательно запросить все, что хочет заказчик, но не браться выполнять это сразу, при этом указав минимально возможные сроки.
Возьмите время, визуализируйте таймлайн разработки проекта, разбив на понятные и простые задачи. По непонятным для вас (не знаете как делать/что невозможно сделать) предложите свое видение. Тут есть небольшой психологический ход, если вам не нравится задача, вам кажется она невыполнимой, можно попробовать явно указать плюсы и минусы этой задачи, увеличить срок задачи, мотивируя его "исследованием не пойми чего". Как результат ее можно преобразовать в что-то более выполнимое, либо деприотизировать, мотивируя это тем, что финансовый "выхлоп" задачи будет меньше, чем того, что делать легко и просто.
Да, не ленитесь писать минутки, фиксируя все договоренности. Заказчики не любят, когда они что-то сказали, а вы это забыли. Дополнительно, протокол - ваш друг в спорных ситуациях, когда вы тратите кучу времени на какую-то дополнительную аналитику, эксперименты, которые не были включены в разработку ранее, а при ретро заказчик проекта говорит, что мы на это не договаривались/не помнит что это говорил (такие ситуации редки, но, как говорится, береженного бог бережет).
Также, как показала практика, очень хорошо протоколировать небольшой таймлайн вашего проекта, ведь это ваш ответ на вопрос "почему так долго/чем вы там занимаетесь?". Jira смотрят редко, все любят простые слайды с очевидной и простой подачей, но она поможет восстановить хронологию.
Надо понимать, что заказчик, нередко очень слабо подкован в технической составляющей проекта, поэтому данный таймлайн при использовании должен быть предельно простым: N дней был простой по причине <Причина>, ответственный <USERNAME>.
Так уж случается, если работа поставлена на конвейер, что приходят новые проекты, но в моменте людей больше не становится. Самый простой способ - построение прототипа с анонсом дальнейшей работы. Работает ровно также как и платная подписка на функционал приложения. Хочешь лучше - оплати сотрудника. В данном случае на помощь мне пришли стажировки, ведь они у меня практически безлимитные, так как не включены в штат и имеют плавающую принадлежность к подразделениям. Любой адекватный стажер может сделать простой MVP без вывода в прод, посчитать метрики и сделать первичную аналитику. Поэтому, тут отказываться от рук, если есть возможность их получить нельзя. Любые руки лучше, чем их отсутствие.
Этот пункт вытекает из предыдущего. Нередко слышу, что на стажировке их заставляли делать <любая неадекватная и бесполезная хрень>. Для качественной стажировки необходимо так называемое win-win решение. Вы получаете руки, которые могут толкать проект в стадии прототипирования, стажер получает боевой опыт, который не стыдно записать в резюме.
продолжение ниже👇
#карьера #трудовые_будни
Please open Telegram to view this post
VIEW IN TELEGRAM
Forwarded from DziS Science | Data Science
Да, обязательно 1 на 1 раз в месяц, если его нет бегите от этого
Технологический прорыв последних лет в плане помощи на собеседовании восхищает. Это ответная мера на неадекватные собеседования, где заставляют считать гессиан функции Лагранжа в точке. Лично я отказался от сложных задач. В терминах Leetcode - easy, но можно добавить 1 простой вопрос, который поднимет теоретический ответ. Задачи должны быть прикладные, ведь потом очень смешно смотреть на людей, которые на собеседовании "с допингом" решают это за минуту, а в работе на испытательном не могут тоже самое и за месяц написать. Никакая LLM приблуда вам в такой ситуации уже не поможет.
Фокус собеседования - проверка того, что написали в резюме, обязательно проверь что это правда. Это могут быть максимально глупые вопросы. Честно признаюсь, если человек пишет, что занимался чем-то специфичным, а потом не может ответить 2 фреймворка (из трех, кстати напишите в коментах ваше предположение, чем занимался челове), которые используются для этого, я такой опыт мысленно вычеркиваю.
Руководство - это про проблемы, а проблемы это стресс. Тут у меня самая сложная задача, ведь я часто пропускаю все через себя. Бороться с негативом помогает отличный совет: все хорошо, если ты уверен, что для решения проблемы ты сделал все от себя зависящее. Очевидно, что в большой компании не все зависит от тебя, поэтому делай свою часть хорошо и все будет здорово. С этим советом я пока только начинаю дружбу.
Делай то, за что тебя "уволят завтра". На все задачи тебя не хватит, ты не робот. Распределяй фокус в зависимости от близости дедлайна. Хочется, конечно, контролировать все, но иногда в ущерб этому стоит направлять фокус туда, где "горит". Это сложно, ведь ты осознанно зажигаешь пожар в задаче, которую ты деприоритизируешь из своего фокуса. Тут важно уметь быстро наверстать.
Надеюсь эти советы вы уже знали и применяли в своей работе.
Ставь 🔥, если используешь это в своей работе. Пиши в коментах свои советы, буду дополнять.
#карьера #трудовые_будни
Please open Telegram to view this post
VIEW IN TELEGRAM
Forwarded from Artem Ryblov’s Data Science Weekly
Machine Learning Q and AI. 30 Essential Questions and Answers on Machine Learning and AI by Sebastian Raschka
If you’re ready to venture beyond introductory concepts and dig deeper into machine learning, deep learning, and AI, the question-and-answer format of Machine Learning Q and AI will make things fast and easy for you, without a lot of mucking about.
Born out of questions often fielded by author Sebastian Raschka, the direct, no-nonsense approach of this book makes advanced topics more accessible and genuinely engaging. Each brief, self-contained chapter journeys through a fundamental question in AI, unraveling it with clear explanations, diagrams, and hands-on exercises.
WHAT'S INSIDE:
FOCUSED CHAPTERS: Key questions in AI are answered concisely, and complex ideas are broken down into easily digestible parts.
WIDE RANGE OF TOPICS: Raschka covers topics ranging from neural network architectures and model evaluation to computer vision and natural language processing.
PRACTICAL APPLICATIONS: Learn techniques for enhancing model performance, fine-tuning large models, and more.
You’ll also explore how to:
• Manage the various sources of randomness in neural network training
• Differentiate between encoder and decoder architectures in large language models
• Reduce overfitting through data and model modifications
• Construct confidence intervals for classifiers and optimize models with limited labeled data
• Choose between different multi-GPU training paradigms and different types of generative AI models
• Understand performance metrics for natural language processing
• Make sense of the inductive biases in vision transformers
If you’ve been on the hunt for the perfect resource to elevate your understanding of machine learning, Machine Learning Q and AI will make it easy for you to painlessly advance your knowledge beyond the basics.
Link: Site
Navigational hashtags: #armknowledgesharing #armbook
General hashtags: #ml #machinelearning #nlp #cv #dl #nn #neuralnetworks #deeplearning #computervision #naturallanguageprocessing
@data_science_weekly
If you’re ready to venture beyond introductory concepts and dig deeper into machine learning, deep learning, and AI, the question-and-answer format of Machine Learning Q and AI will make things fast and easy for you, without a lot of mucking about.
Born out of questions often fielded by author Sebastian Raschka, the direct, no-nonsense approach of this book makes advanced topics more accessible and genuinely engaging. Each brief, self-contained chapter journeys through a fundamental question in AI, unraveling it with clear explanations, diagrams, and hands-on exercises.
WHAT'S INSIDE:
FOCUSED CHAPTERS: Key questions in AI are answered concisely, and complex ideas are broken down into easily digestible parts.
WIDE RANGE OF TOPICS: Raschka covers topics ranging from neural network architectures and model evaluation to computer vision and natural language processing.
PRACTICAL APPLICATIONS: Learn techniques for enhancing model performance, fine-tuning large models, and more.
You’ll also explore how to:
• Manage the various sources of randomness in neural network training
• Differentiate between encoder and decoder architectures in large language models
• Reduce overfitting through data and model modifications
• Construct confidence intervals for classifiers and optimize models with limited labeled data
• Choose between different multi-GPU training paradigms and different types of generative AI models
• Understand performance metrics for natural language processing
• Make sense of the inductive biases in vision transformers
If you’ve been on the hunt for the perfect resource to elevate your understanding of machine learning, Machine Learning Q and AI will make it easy for you to painlessly advance your knowledge beyond the basics.
Link: Site
Navigational hashtags: #armknowledgesharing #armbook
General hashtags: #ml #machinelearning #nlp #cv #dl #nn #neuralnetworks #deeplearning #computervision #naturallanguageprocessing
@data_science_weekly