Forwarded from DevFM
Docker в каждый дом
Стрим FastAPI+Docker породил бурное обсуждение, а нужен ли докер в таком небольшом проекте. Наш ответ — обязательно! В современном мире разработки docker является такой же неотъемлемой частью разработки, как и git. Есть некоторые области без докера, например, разработка GUI, операционных систем или микроконтроллеров. Но весь backend, frontend и data science без докера вообще не живут. Давайте посмотрим, какие прямые выгоды даёт докер:
1. Всегда понятно, как запустить код. Dockerfile является однозначной инструкцией по сборке проекта. Bus-factor не мешает жить.
2. Легко включать новых людей в разработку. Инструкция в ридми сводится к docker build & docker run, что понятно даже junior-разработчикам.
3. Деплой можно производить где угодно. В пару команд можно запуститься на компе разработчика, на test или prod сервере, у заказчика на ноутбуке – и везде всё будет одинаково, нужен только сам Docker.
4. Проект одинаково себя ведёт везде. Это упрощает воспроизведение проблемы и сокращает время на багфикс.
5. Нет проблем с конфликтом зависимостей-библиотек. Вы можете на одной машине запустить проекты с условным django 3 и django 4, они никак друг другу не помешают.
6. Легко поднимать зависимости-компоненты. Для любой базы данных берётся готовый докер-образ, меняется конфиг и в одну команду запускается. С выходом на docker compose можно одной командой поднимать сборную солянку из backend, frontend, базы данных, nginx и Let's Encrypt.
7. Просто откатываться к старой версии. Версионирование докер-образов позволяет запустить новую версию, и, если что-то пошло не так, откатиться назад за десятки секунд.
8. Понятные внешние эффекты проекта. В команде docker run указаны проброшенные в контейнер каталоги и порты. Всё остальное изолированно.
В общем, со всех сторон одна польза. Минусы? Требуется изучить новый инструмент и best practices. Кажется, на этом всё. Даже дополнительных накладных расходов на виртуализацию нет. И помните – если docker вам мешает, скорее всего, вы что-то делаете неправильно.
Для запуска нескольких связанных контейнеров пользуйтесь compose, гайд тут. Если ещё нужно управлять множеством серверов, то посмотрите на kubernetes.
#skills #sudo #devfm
Стрим FastAPI+Docker породил бурное обсуждение, а нужен ли докер в таком небольшом проекте. Наш ответ — обязательно! В современном мире разработки docker является такой же неотъемлемой частью разработки, как и git. Есть некоторые области без докера, например, разработка GUI, операционных систем или микроконтроллеров. Но весь backend, frontend и data science без докера вообще не живут. Давайте посмотрим, какие прямые выгоды даёт докер:
1. Всегда понятно, как запустить код. Dockerfile является однозначной инструкцией по сборке проекта. Bus-factor не мешает жить.
2. Легко включать новых людей в разработку. Инструкция в ридми сводится к docker build & docker run, что понятно даже junior-разработчикам.
3. Деплой можно производить где угодно. В пару команд можно запуститься на компе разработчика, на test или prod сервере, у заказчика на ноутбуке – и везде всё будет одинаково, нужен только сам Docker.
4. Проект одинаково себя ведёт везде. Это упрощает воспроизведение проблемы и сокращает время на багфикс.
5. Нет проблем с конфликтом зависимостей-библиотек. Вы можете на одной машине запустить проекты с условным django 3 и django 4, они никак друг другу не помешают.
6. Легко поднимать зависимости-компоненты. Для любой базы данных берётся готовый докер-образ, меняется конфиг и в одну команду запускается. С выходом на docker compose можно одной командой поднимать сборную солянку из backend, frontend, базы данных, nginx и Let's Encrypt.
7. Просто откатываться к старой версии. Версионирование докер-образов позволяет запустить новую версию, и, если что-то пошло не так, откатиться назад за десятки секунд.
8. Понятные внешние эффекты проекта. В команде docker run указаны проброшенные в контейнер каталоги и порты. Всё остальное изолированно.
В общем, со всех сторон одна польза. Минусы? Требуется изучить новый инструмент и best practices. Кажется, на этом всё. Даже дополнительных накладных расходов на виртуализацию нет. И помните – если docker вам мешает, скорее всего, вы что-то делаете неправильно.
Для запуска нескольких связанных контейнеров пользуйтесь compose, гайд тут. Если ещё нужно управлять множеством серверов, то посмотрите на kubernetes.
#skills #sudo #devfm
Telegram
DevFM
Стрим: разбираем Fastapi + Docker
Сняли почти часовое видео для начинающих, смотрите где удобно youtube / rutube / dzen / VK.
В нём собираем приложение по доке FastAPI (кстати, документацию читать полезно, а их дока крутая). В видео фокусируемся на обвязке…
Сняли почти часовое видео для начинающих, смотрите где удобно youtube / rutube / dzen / VK.
В нём собираем приложение по доке FastAPI (кстати, документацию читать полезно, а их дока крутая). В видео фокусируемся на обвязке…
Forwarded from Заскуль питона (Data Science)
Перед новогодними праздниками X5 написали статью про контекстных бандитов и то, как они их применяли в ценообразовании. Здесь рассказывается об основных методах, которые ребята применяли для экспериментов: UCB, Thompson Sampling.
Базово алгоритмы позволяют выбрать лучшую стратегию на основе метрики, например, цены товара, исходя из определенного контекста, изменения среды (данных по пользователю, внешних факторов и др.). В отличие от классических A/B-тестов, контекстные бандиты могут достаточно быстро менять свои решения, адаптируясь к реальным данным. Это значит, что вместо долгих тестов можно сразу получать лучшие результаты.
Кроме того, статья затрагивает важный аспект - это баланс между исследованием новых вариантов и использованием уже известных положительных решений. Например, утром цены могут быть ниже, чтобы привлечь покупателей, а вечером - выше, чтобы увеличить маржу.
Код обещали выложить в следующей статье, в статье Ozon Tech он уже есть. Байесовская линейная регрессия, Thompson Sampling, СMAB, код тут
Базово алгоритмы позволяют выбрать лучшую стратегию на основе метрики, например, цены товара, исходя из определенного контекста, изменения среды (данных по пользователю, внешних факторов и др.). В отличие от классических A/B-тестов, контекстные бандиты могут достаточно быстро менять свои решения, адаптируясь к реальным данным. Это значит, что вместо долгих тестов можно сразу получать лучшие результаты.
Кроме того, статья затрагивает важный аспект - это баланс между исследованием новых вариантов и использованием уже известных положительных решений. Например, утром цены могут быть ниже, чтобы привлечь покупателей, а вечером - выше, чтобы увеличить маржу.
Код обещали выложить в следующей статье, в статье Ozon Tech он уже есть. Байесовская линейная регрессия, Thompson Sampling, СMAB, код тут
Forwarded from Тимлид Очевидность | Евгений Антонов
Я принес. Подборку классных докладов
В конце этого года я съездил на московский Тимлидконф. Первый день прошел в какой-то сумбурной суете: то круглый стол, то подкаст надо записать, то афтепати уже началось.
А вот во второй день я решил проверить, правда ли конференции уже не те, и доклады – фигня? Сходил на несколько докладов и искренне получил удовольствие.
Настолько мне всё понравилось, что я у каждого из этих спикеров попросил ссылку и разрешение вам сегодня принести эту подборку. Приложу ссылки на эти доклады и мои впечатления о них. Вдруг у вас в обозримом будущем найдется время и желание посмотреть что-то такое.
1. Доклад Миши Трифонова про servant leadership (лидер-слуга). Очень мне близка эта тема. Смотрел и чувствовал, как у меня с Мишей сходятся мысли и интенции не просто в сторону эффективности, а еще и гуманизма и заботы о своей команде. https://youtu.be/vBTSieU2K60
2. Дарья Бородина с докладом про то, как сохранять и восстанавливать энергию, когда забит календарь. И тема актуальная для тех у кого много созвонов в день (eto ya), и Даша очень живо и харизматично выступает, и некоторое побуждение к полезным действиям есть. Мне бы его год назад посмотреть, вот бы мне это время и силы сэкономило 🙂 Сам на практике искал рецепты и доходил до того, что Даша за 40 минут рассказала. https://youtu.be/jbuUGm_5jZc
3. Женя Идзиковский рассказал про нашу психику с понятной айтишникам точки зрения. Легаси, техдолг, баги, способы перепрошивки. Всё как всегда с крутыми и понятными примерами. Секция вопросов и ответов в конце забавная вышла 🙂 https://youtu.be/mTDp1EKSxrU
4. Настя Абрашитова выдала базу для мидл-менеджеров на тему того, что делать, если от вас уходит тимлид. Хорошо структурированная и рациональная инструкция. Вот прям сталкиваешься с такой ситуацией, открываешь доклад и работаешь по шагам. https://youtu.be/AjqQBXdMBQw
Добавляйте в список «Посмотреть позже» и продолжайте резать салаты, больше не отвлекаю в этом году.
С наступающим, кстати! 🎄🎉
В конце этого года я съездил на московский Тимлидконф. Первый день прошел в какой-то сумбурной суете: то круглый стол, то подкаст надо записать, то афтепати уже началось.
А вот во второй день я решил проверить, правда ли конференции уже не те, и доклады – фигня? Сходил на несколько докладов и искренне получил удовольствие.
Настолько мне всё понравилось, что я у каждого из этих спикеров попросил ссылку и разрешение вам сегодня принести эту подборку. Приложу ссылки на эти доклады и мои впечатления о них. Вдруг у вас в обозримом будущем найдется время и желание посмотреть что-то такое.
1. Доклад Миши Трифонова про servant leadership (лидер-слуга). Очень мне близка эта тема. Смотрел и чувствовал, как у меня с Мишей сходятся мысли и интенции не просто в сторону эффективности, а еще и гуманизма и заботы о своей команде. https://youtu.be/vBTSieU2K60
2. Дарья Бородина с докладом про то, как сохранять и восстанавливать энергию, когда забит календарь. И тема актуальная для тех у кого много созвонов в день (eto ya), и Даша очень живо и харизматично выступает, и некоторое побуждение к полезным действиям есть. Мне бы его год назад посмотреть, вот бы мне это время и силы сэкономило 🙂 Сам на практике искал рецепты и доходил до того, что Даша за 40 минут рассказала. https://youtu.be/jbuUGm_5jZc
3. Женя Идзиковский рассказал про нашу психику с понятной айтишникам точки зрения. Легаси, техдолг, баги, способы перепрошивки. Всё как всегда с крутыми и понятными примерами. Секция вопросов и ответов в конце забавная вышла 🙂 https://youtu.be/mTDp1EKSxrU
4. Настя Абрашитова выдала базу для мидл-менеджеров на тему того, что делать, если от вас уходит тимлид. Хорошо структурированная и рациональная инструкция. Вот прям сталкиваешься с такой ситуацией, открываешь доклад и работаешь по шагам. https://youtu.be/AjqQBXdMBQw
Добавляйте в список «Посмотреть позже» и продолжайте резать салаты, больше не отвлекаю в этом году.
С наступающим, кстати! 🎄🎉
Forwarded from Персонализация неизбежна
Подводим предновогодние итоги 2024 года! 🥂
Ровно год назад я выступал на конференции Яндекса с докладом "Тренды, подходы и проблемы в рекомендательных системах 2023 года". Пролетел год, и давайте посмотрим, что изменилось, если пройтись по основным пунктам.
Помните про "нечестную" оценку моделей в статьях с подглядыванием в будущее? Так вот, открываем главную конференцию по рекомендациям RecSys 24 и что видим? Всё те же грабли! Случайно выбранные статьи из трека full paper используют: user-based split (8 работ: 1, 2, 3, 4, 5, 6, 7, 8 🤯), random split (2 работы: 1, 2) и лишь одна — самый предпочтительный global timeline-based. Подробнее об этих подходах можно почитать здесь. В общем, ситуация, похоже, кардинально не изменилась. 😔
А что по поводу сложности оценки рекомендаций на исторических данных? Все упомянутые 11 статей по-прежнему используют "типичную" парадигму, пытаясь максимально точно предсказать исторические данные. Если модель начинает рекомендовать что-то отличное от исторических данных (но более релевантное), то она в проигрыше. Лично я возлагаю большие надежды на LLM-based evaluation и жду прорыва в этой области в 2025 году. И вот свежий пример — совсем недавно вышла статья про RecSys Arena! Наш старый знакомый SASRec сравнили с LightGCN с помощью GPT-4o. Осталось дело за малым: показать и доказать корреляцию LLM-оценок с результатами А/Б-тестов (и, конечно, научиться воспроизводимо получать такие оценки). Представляете, какие горизонты это откроет? ✨
Отсутствие кода в статьях. Тут, пожалуй, и добавить нечего. Ситуация, кажется, не меняется.
Некачественные имплементации порождают слабые результаты моделей. Год назад я говорил про работы, в которых обнаружили слабые open-source реализации GRU4Rec и BERT4Rec. В этом году мы с коллегами показали, что одна из самых популярных моделей BPR в таких популярных фреймворках как implicit/RecBole/LightFM реализована не самым оптимальным образом, поэтом проигрывает по качеству более качественным имплементациям.
Маленькие датасеты — проблема академических исследований. Из 11 упомянутых выше статей, только одна может похвастаться датасетом с более чем 1 миллионом пользователей. Ещё две работы оперируют данными в районе 100 тысяч, а остальные — и вовсе несколькими десятками тысяч. Проблема в том, что модели, показывающие отличные результаты на скромных 10 тысячах пользователей, могут попросту "потеряться" при масштабировании на миллионы. И те "впечатляющие" приросты метрик, скорее всего, испарятся. 💨
Тренд на LLM & RecSys — в самом разгаре! И это не может не радовать! Алиса от Яндекса уже вовсю рекомендует товары и собирает корзины в Яндекс.Лавке. YouTube Shorts использует LLM для подбора контента, максимально отвечающего вашим интересам. Даже старый добрый EASE прокачали знаниями, полученными от больших языковых моделей. А сколько интересных статей выходит про симуляцию поведения пользователей с помощью LLM! В общем, направление развивается семимильными шагами. 🚀
Тренд на RL & RecSys — небольшая неопределенность. На Turbo ML Conf я делился, как мы завели RL в рекомендательных системах и выиграли у обычного бустинга? Правда, тут же проиграли другому, ещё более качествнному бустингу 🙂. Но я, и коллеги из Яндекса отметили, что на RecSys24 работ по RL & RecSys было на удивление мало. Похоже, этому тренду нужен свежий импульс с прорывными идеями.
Ровно год назад я выступал на конференции Яндекса с докладом "Тренды, подходы и проблемы в рекомендательных системах 2023 года". Пролетел год, и давайте посмотрим, что изменилось, если пройтись по основным пунктам.
Помните про "нечестную" оценку моделей в статьях с подглядыванием в будущее? Так вот, открываем главную конференцию по рекомендациям RecSys 24 и что видим? Всё те же грабли! Случайно выбранные статьи из трека full paper используют: user-based split (8 работ: 1, 2, 3, 4, 5, 6, 7, 8 🤯), random split (2 работы: 1, 2) и лишь одна — самый предпочтительный global timeline-based. Подробнее об этих подходах можно почитать здесь. В общем, ситуация, похоже, кардинально не изменилась. 😔
А что по поводу сложности оценки рекомендаций на исторических данных? Все упомянутые 11 статей по-прежнему используют "типичную" парадигму, пытаясь максимально точно предсказать исторические данные. Если модель начинает рекомендовать что-то отличное от исторических данных (но более релевантное), то она в проигрыше. Лично я возлагаю большие надежды на LLM-based evaluation и жду прорыва в этой области в 2025 году. И вот свежий пример — совсем недавно вышла статья про RecSys Arena! Наш старый знакомый SASRec сравнили с LightGCN с помощью GPT-4o. Осталось дело за малым: показать и доказать корреляцию LLM-оценок с результатами А/Б-тестов (и, конечно, научиться воспроизводимо получать такие оценки). Представляете, какие горизонты это откроет? ✨
Отсутствие кода в статьях. Тут, пожалуй, и добавить нечего. Ситуация, кажется, не меняется.
Некачественные имплементации порождают слабые результаты моделей. Год назад я говорил про работы, в которых обнаружили слабые open-source реализации GRU4Rec и BERT4Rec. В этом году мы с коллегами показали, что одна из самых популярных моделей BPR в таких популярных фреймворках как implicit/RecBole/LightFM реализована не самым оптимальным образом, поэтом проигрывает по качеству более качественным имплементациям.
Маленькие датасеты — проблема академических исследований. Из 11 упомянутых выше статей, только одна может похвастаться датасетом с более чем 1 миллионом пользователей. Ещё две работы оперируют данными в районе 100 тысяч, а остальные — и вовсе несколькими десятками тысяч. Проблема в том, что модели, показывающие отличные результаты на скромных 10 тысячах пользователей, могут попросту "потеряться" при масштабировании на миллионы. И те "впечатляющие" приросты метрик, скорее всего, испарятся. 💨
Тренд на LLM & RecSys — в самом разгаре! И это не может не радовать! Алиса от Яндекса уже вовсю рекомендует товары и собирает корзины в Яндекс.Лавке. YouTube Shorts использует LLM для подбора контента, максимально отвечающего вашим интересам. Даже старый добрый EASE прокачали знаниями, полученными от больших языковых моделей. А сколько интересных статей выходит про симуляцию поведения пользователей с помощью LLM! В общем, направление развивается семимильными шагами. 🚀
Тренд на RL & RecSys — небольшая неопределенность. На Turbo ML Conf я делился, как мы завели RL в рекомендательных системах и выиграли у обычного бустинга? Правда, тут же проиграли другому, ещё более качествнному бустингу 🙂. Но я, и коллеги из Яндекса отметили, что на RecSys24 работ по RL & RecSys было на удивление мало. Похоже, этому тренду нужен свежий импульс с прорывными идеями.
Forwarded from Модель для сборки
👾 "Dive into ML conferences" сказали они. Не ну вы видели сколько там вообще статей каждый год генерируют?
Зато вот чё я вам притащил: лонгрид по DL Efficiency от Princeton grad. Лонгрид большой, содержит в себе кучу боли, написан на техническом английском с кучей жаргона. Короче, всё как вы не любите. А что, мне одному страдать?
🙋🏽♂️ «Чо такое DL Efficiency?» — спросите вы. А я отвечу: допустим, у вас есть ноут и нет подписки на сервис с топовыми LLM, потому что $20 is $20. Вам очень хочется поиграться с топовой LLM, например, спросить у топовой опен-сурс модели, что она думает про результаты выборов в США. А на вашу 1050 в игровом компутере 3 ядра 3 гига не только не влезет BG3, но и моделька тоже там не поместится. Поэтому умные дяди подумали и придумали кучу шорткатов, как же её всё-таки туда впихнуть. Или ускорить обучение. Или сделать это подешевле.
⁉️ А что если я просто чиловый парень любящий матешу и временные ряды. Зачем мне это?
– Во-первых, чуваки, я читал ваши папиры. Игнорировать последние 3 года резерча в других отраслях — прикольная затея, но не всегда. Познакомитесь хоть.
– Во-вторых, там есть всякое про векторизацию, например, fused kernels в pytorch, чтобы ваши модельки работали побыстрей. Ещё там много про опты и оптимизаторы, я мельком глянул и понял что пока останусь на Adam/AdamW.
– В-третьих, тут куча трюков как заставить вашу огромную модельку переобучаемую раз в год тюниться быстрей, запихивать в неё побольше данных, и ещё разбор нововведений в H100 (зачем).
👀 Итак, вашему вниманию:
– Разделённый на 4 эпохи лонгрид с кучей красивостей и ссылок, больше похожий на field review из диплома, но если бы его писали люди, а не чатгпт
– Описание таймскейла исследований от метоптов и GPU на 3gb до современных кластеров
– Разбор, чего же всё-таки нового в этих ваших хайповых папирах последних лет, например, чё такое FlashAttn, Q-LoRA, ZeRO, Chinchilla и всякие разные квантизации.
❤️🔥 Короче, весь контент от @lovedeathtransformers в одном месте. Спешл фор миллениалс.
Зато вот чё я вам притащил: лонгрид по DL Efficiency от Princeton grad. Лонгрид большой, содержит в себе кучу боли, написан на техническом английском с кучей жаргона. Короче, всё как вы не любите. А что, мне одному страдать?
🙋🏽♂️ «Чо такое DL Efficiency?» — спросите вы. А я отвечу: допустим, у вас есть ноут и нет подписки на сервис с топовыми LLM, потому что $20 is $20. Вам очень хочется поиграться с топовой LLM, например, спросить у топовой опен-сурс модели, что она думает про результаты выборов в США. А на вашу 1050 в игровом компутере 3 ядра 3 гига не только не влезет BG3, но и моделька тоже там не поместится. Поэтому умные дяди подумали и придумали кучу шорткатов, как же её всё-таки туда впихнуть. Или ускорить обучение. Или сделать это подешевле.
⁉️ А что если я просто чиловый парень любящий матешу и временные ряды. Зачем мне это?
– Во-первых, чуваки, я читал ваши папиры. Игнорировать последние 3 года резерча в других отраслях — прикольная затея, но не всегда. Познакомитесь хоть.
– Во-вторых, там есть всякое про векторизацию, например, fused kernels в pytorch, чтобы ваши модельки работали побыстрей. Ещё там много про опты и оптимизаторы, я мельком глянул и понял что пока останусь на Adam/AdamW.
– В-третьих, тут куча трюков как заставить вашу огромную модельку переобучаемую раз в год тюниться быстрей, запихивать в неё побольше данных, и ещё разбор нововведений в H100 (зачем).
👀 Итак, вашему вниманию:
– Разделённый на 4 эпохи лонгрид с кучей красивостей и ссылок, больше похожий на field review из диплома, но если бы его писали люди, а не чатгпт
– Описание таймскейла исследований от метоптов и GPU на 3gb до современных кластеров
– Разбор, чего же всё-таки нового в этих ваших хайповых папирах последних лет, например, чё такое FlashAttn, Q-LoRA, ZeRO, Chinchilla и всякие разные квантизации.
❤️🔥 Короче, весь контент от @lovedeathtransformers в одном месте. Спешл фор миллениалс.
Alex L. Zhang
A Meticulous Guide to Advances in Deep Learning Efficiency over the Years
A very long and thorough guide how deep learning algorithms, hardware, libraries, compilers, and more have become more efficient.
Forwarded from Запрети мне псевдолейблить
🚀 Разбираем решение, которое принесло нашей команде 6-е место в Kaggle-соревновании по обработке данных миссии Ariel
Мы работали с частотными сигналами, которые изначально были очень шумными. Для их сглаживания использовали:
1️⃣ Гауссовский регрессор
2️⃣ Фильтр Савицкого-Голея
Далее ищем границы транзитной зоны планеты. Делаем через простой эмпирический детектор: транзит на графике светимости звезды имеет вид \_/ — яркость падает, когда планета проходит перед звездой, так как часть частотных компонентов теряет интенсивность.
📉 Что мы делали дальше:
Удаляем этапы до и после транзита, чтобы анализировать только изменения светимости в нужный момент.
"Поднимаем" транзит обратно к уровню светимости звезды, чтобы восстановить исходный "пульс звезды". Это важно, чтобы учесть глобальное поведение светимости звезды, которе не очень-то и постоянное.
🔍 Фичи и модели:
На основе изменений яркости между ожидаемыми и наблюдаемыми значениями на заданных частотах извлекали фичи. Эти частоты совпадают с важными таргетами — спектрограммой атмосферы экзопланеты.
Обучаем линейную регрессию глобально для каждого таргета, подбирая оптимальные коэффициенты. В смысле берем все моменты времени для всех транзитов и конкретной частоты и ищем коэффициент подгонки.
Параллельно обучаем CNN, которая анализировала частотные изменения в заданных временных окнах.
Это:
Помогает учитывало локальные особенности спектра и переходов (энергии?) между частотами
Позволяло понять взаимосвязи между соседними частотами, улучшая точность предсказаний.
🔗 Финал:
Смешали (блендили) результаты линейной регрессии и CNN. Затем финальную спектрограмму еще раз сгладили, чтобы убрать артефакты.
💡 Бонус материал: пример 'подъема' спектра
Мы работали с частотными сигналами, которые изначально были очень шумными. Для их сглаживания использовали:
1️⃣ Гауссовский регрессор
2️⃣ Фильтр Савицкого-Голея
Далее ищем границы транзитной зоны планеты. Делаем через простой эмпирический детектор: транзит на графике светимости звезды имеет вид \_/ — яркость падает, когда планета проходит перед звездой, так как часть частотных компонентов теряет интенсивность.
📉 Что мы делали дальше:
Удаляем этапы до и после транзита, чтобы анализировать только изменения светимости в нужный момент.
"Поднимаем" транзит обратно к уровню светимости звезды, чтобы восстановить исходный "пульс звезды". Это важно, чтобы учесть глобальное поведение светимости звезды, которе не очень-то и постоянное.
🔍 Фичи и модели:
На основе изменений яркости между ожидаемыми и наблюдаемыми значениями на заданных частотах извлекали фичи. Эти частоты совпадают с важными таргетами — спектрограммой атмосферы экзопланеты.
Обучаем линейную регрессию глобально для каждого таргета, подбирая оптимальные коэффициенты. В смысле берем все моменты времени для всех транзитов и конкретной частоты и ищем коэффициент подгонки.
Параллельно обучаем CNN, которая анализировала частотные изменения в заданных временных окнах.
Это:
Помогает учитывало локальные особенности спектра и переходов (энергии?) между частотами
Позволяло понять взаимосвязи между соседними частотами, улучшая точность предсказаний.
🔗 Финал:
Смешали (блендили) результаты линейной регрессии и CNN. Затем финальную спектрограмму еще раз сгладили, чтобы убрать артефакты.
Please open Telegram to view this post
VIEW IN TELEGRAM
Forwarded from Quant Researcher
Что почитать на новогодних каникулах?
Подготовили список полезных книг и материалов для изучения в праздники.
Матчасть в финансах
1. Options, Futures, and Other Derivatives by John Hull
Библия деривативов. На многих трейдинг-десках её выдают всем, кто не проходил базовый курс по деривативам в университете.
2. Bond Markets, Analysis, and Strategies (10th Edition) by Frank J. Fabozzi
Библия облигаций, после которой весь мир Fixed Income станет для вас понятным.
3. Pricing and Trading Interest Rate Derivatives: A Practical Guide to Swaps by J Hamish M Darbyshire
Основательный гайд по свопам и деривативам на процентные ставки.
4. Expected Returns: An Investor's Guide to Harvesting Market Rewards by Antti Ilmanen
Фундаментальная книга про концепцию рыночных риск-премий.
Математика
5. Mathematical Modeling and Computation in Finance
«101» по математике в финансах.
6. Financial Mathematics, Derivatives and Structured Product
Поможет раз и навсегда разобраться с необходимой для прайсинга деривативов математикой.
Микроструктура рынка
7. Trades, Quotes and Prices: Financial Markets Under the Microscope by Jean-Philippe Bouchaud
Хардкорная книга от группы PhD об устройстве микроструктуры рынка.
8. Algorithmic and High-Frequency Trading by Álvaro Cartea
«101» по HFT и алгоритмической торговле.
Machine Learning in Finance
9. Advances in Financial Machine Learning by Marcos Lopez de Prado
Книга Маркоса Лопеса де Прадо о методах машинного обучения в финансах.
10. Machine Learning for Asset Managers by Marcos M. López de Prado
Вторая книга от де Прадо о машинном обучении применительно к управлению активами.
Авторы канала не могут начать 2025 год без рекомендации Лекций Ильинского. Эту базу стоит пересматривать регулярно!
Quant Researcher
Подготовили список полезных книг и материалов для изучения в праздники.
Матчасть в финансах
1. Options, Futures, and Other Derivatives by John Hull
Библия деривативов. На многих трейдинг-десках её выдают всем, кто не проходил базовый курс по деривативам в университете.
2. Bond Markets, Analysis, and Strategies (10th Edition) by Frank J. Fabozzi
Библия облигаций, после которой весь мир Fixed Income станет для вас понятным.
3. Pricing and Trading Interest Rate Derivatives: A Practical Guide to Swaps by J Hamish M Darbyshire
Основательный гайд по свопам и деривативам на процентные ставки.
4. Expected Returns: An Investor's Guide to Harvesting Market Rewards by Antti Ilmanen
Фундаментальная книга про концепцию рыночных риск-премий.
Математика
5. Mathematical Modeling and Computation in Finance
«101» по математике в финансах.
6. Financial Mathematics, Derivatives and Structured Product
Поможет раз и навсегда разобраться с необходимой для прайсинга деривативов математикой.
Микроструктура рынка
7. Trades, Quotes and Prices: Financial Markets Under the Microscope by Jean-Philippe Bouchaud
Хардкорная книга от группы PhD об устройстве микроструктуры рынка.
8. Algorithmic and High-Frequency Trading by Álvaro Cartea
«101» по HFT и алгоритмической торговле.
Machine Learning in Finance
9. Advances in Financial Machine Learning by Marcos Lopez de Prado
Книга Маркоса Лопеса де Прадо о методах машинного обучения в финансах.
10. Machine Learning for Asset Managers by Marcos M. López de Prado
Вторая книга от де Прадо о машинном обучении применительно к управлению активами.
Авторы канала не могут начать 2025 год без рекомендации Лекций Ильинского. Эту базу стоит пересматривать регулярно!
Quant Researcher
Forwarded from Quant Researcher
Understand Deep Learning: Free Online Book
Если вы хотите провести начало 2025 года за погружением в мир DL, то эта книга будет отличным началом.
Она распространяется бесплатно через сайт, на котором также выложены Jupyter-ноутбуки с кодом. Не придётся больше страдать, перепечатывая код из книги 2016 года на Python 2.0 или R.
Книга охватывает все необходимые темы: от функций потерь (Loss Functions) до трансформеров и Diffusion models.
На сайте также представлен список «Further Reading», который поможет углубиться в любую интересующую вас тему.
Нам бы такой ресурс в 2015-м!
Quant Researcher
Если вы хотите провести начало 2025 года за погружением в мир DL, то эта книга будет отличным началом.
Она распространяется бесплатно через сайт, на котором также выложены Jupyter-ноутбуки с кодом. Не придётся больше страдать, перепечатывая код из книги 2016 года на Python 2.0 или R.
Книга охватывает все необходимые темы: от функций потерь (Loss Functions) до трансформеров и Diffusion models.
На сайте также представлен список «Further Reading», который поможет углубиться в любую интересующую вас тему.
Нам бы такой ресурс в 2015-м!
Quant Researcher
Forwarded from Крис про аналитику🧠🦾
Чем отличается мидл+ от джуна? (часть 1)
Авторский взгляд, буду кратка.
Вижу 2 ключевые штуки.
Нет, это не бесконечное знание хардов. Это можно натренировать в тепличных условиях на курсиках и искусственных данных. Типа как протеиновый качок, которого натянули местные дрыщи в дворовых потасовках за гаражами😃 Потому что он не нюхал настоящего пороха. Жизнь его готовила к поднятию искусственных тяжестей, а не тому, что надо кулаками работать.
Штука 1: мидл+ имеет свою точку зрения по большинству вопросов, джун бежит сиюминутно выполнять любые указания продакта без их оценки на адекватность. Да и как ты оценишь, если опыта не имеешь? Даже если начнешь что-то вякать, скорее всего тебя задавят опытом и насмотренностью, если только по ту сторону не откровенную дичь несут.
😳 Когда я была джуном, мой продакт решил проверить "гениальную" гипотезу: что будет, если при заходе в приложение показывать на весь экран неперелистываемые нескрываемые сторизы на 30 секунд.
Задумка была благородная: если мы проинформируем людей о всех возможностях нашего сервиса, после подобного зомбирования они понесут свои денежки к нам в карман.
Реальность: метрики упали на 50%, потому что люди, видя 30-секундное безальтернативное нечто, закрывали приложение и не возвращались👍 😰
Когда ты на ежедневной основе работаешь с большими данными, начинаешь хотя бы ориентировочно понимать, что триггерит людей в хорошую и плохую сторону. Сейчас бы я такую задумку зарубила бы на корню. Если бы меня не послушали, эскалировала до лидов и хэдов, чтобы мы не тестировали откровенно вредительские гипотезы. Мне сейчас просто лень заниматья подобной фигней.
Подумайте, сколько сил было вложено огромным количеством людей: дизайнер нарисовал сторизы, разработчики из закодили на двух мобильных платформах, тестировщики проверили их на баги, App Store и Google Play проверили их на скам, аналитик сделал разметку, поставил ТЗ на разработку, выбирал метрики, выгружал данные, дизайнил АВ, заводил АВ тест, считал АВ тест руками... - чтобы получить колоссальную просадку в результатах😭
Когда работаешь над продуктом, надо иметь хотя бы зачатки эмпатии, чтобы предсказывать поведение пользователей. И проводить минимальные кастдевы.
Джун скорее всего не погружен в типовые продуктовые процессы, не имеет реальной насмотренности и своего мнения. Опытный продакт таким будет вертеть и крутить по своему усмотрению.
Если ты сам обладаешь багажом опыта за плечами, тебе легче протолкнуть разные идеи. На каких сегментах что тестировать, что смотреть в рисерче и тд.
😳 Еще забавный пример: проходила продуктовое собеседование в Skyeng. Тимлид рассказал об их реальной фиче и попросил задизайнить АВ тест. Я обычными логичными рассуждениями вслух за 10 секунд вышла на тот сегмент пользователей, на которых надо было ее тестировать.
В реальности в компании этот путь занял 2 итерации теста🤷♀️ В первой итерации тестировали на всех и получили ожидаемую просадку метрик на "не том" большом сегменте. Как в простом советском анекдоте: "дорвались до прода джун-продакт и джун-аналитик..."
А могли бы нанять меня, мы бы столько времени на тестировании бесполезных гипотез сэкономили...
если нужна вторая часть, втопите лайков, огонечков и другой обратной связи👇🔥🙂
Авторский взгляд, буду кратка.
Вижу 2 ключевые штуки.
Нет, это не бесконечное знание хардов. Это можно натренировать в тепличных условиях на курсиках и искусственных данных. Типа как протеиновый качок, которого натянули местные дрыщи в дворовых потасовках за гаражами
Штука 1: мидл+ имеет свою точку зрения по большинству вопросов, джун бежит сиюминутно выполнять любые указания продакта без их оценки на адекватность. Да и как ты оценишь, если опыта не имеешь? Даже если начнешь что-то вякать, скорее всего тебя задавят опытом и насмотренностью, если только по ту сторону не откровенную дичь несут.
Задумка была благородная: если мы проинформируем людей о всех возможностях нашего сервиса, после подобного зомбирования они понесут свои денежки к нам в карман.
Реальность: метрики упали на 50%, потому что люди, видя 30-секундное безальтернативное нечто, закрывали приложение и не возвращались
Когда ты на ежедневной основе работаешь с большими данными, начинаешь хотя бы ориентировочно понимать, что триггерит людей в хорошую и плохую сторону. Сейчас бы я такую задумку зарубила бы на корню. Если бы меня не послушали, эскалировала до лидов и хэдов, чтобы мы не тестировали откровенно вредительские гипотезы. Мне сейчас просто лень заниматья подобной фигней.
Подумайте, сколько сил было вложено огромным количеством людей: дизайнер нарисовал сторизы, разработчики из закодили на двух мобильных платформах, тестировщики проверили их на баги, App Store и Google Play проверили их на скам, аналитик сделал разметку, поставил ТЗ на разработку, выбирал метрики, выгружал данные, дизайнил АВ, заводил АВ тест, считал АВ тест руками... - чтобы получить колоссальную просадку в результатах
Когда работаешь над продуктом, надо иметь хотя бы зачатки эмпатии, чтобы предсказывать поведение пользователей. И проводить минимальные кастдевы.
Джун скорее всего не погружен в типовые продуктовые процессы, не имеет реальной насмотренности и своего мнения. Опытный продакт таким будет вертеть и крутить по своему усмотрению.
Если ты сам обладаешь багажом опыта за плечами, тебе легче протолкнуть разные идеи. На каких сегментах что тестировать, что смотреть в рисерче и тд.
В реальности в компании этот путь занял 2 итерации теста🤷♀️ В первой итерации тестировали на всех и получили ожидаемую просадку метрик на "не том" большом сегменте. Как в простом советском анекдоте: "дорвались до прода джун-продакт и джун-аналитик..."
А могли бы нанять меня, мы бы столько времени на тестировании бесполезных гипотез сэкономили...
если нужна вторая часть, втопите лайков, огонечков и другой обратной связи👇🔥
Please open Telegram to view this post
VIEW IN TELEGRAM
Forwarded from Крис про аналитику🧠🦾
Чем отличается мидл+ от джуна? (часть 2)
сначала прочитай часть 1
Штука 2: мидл+ скорее всего видел в своей карьере ооооооооочень много дерьма.
🆘Ломающиеся каждый релиз данные,
🆎поломанные АВ тесты: без равномерного сплитования, без контрольной группы (я ахуела, когда мой разраб накодил тест только для тестовой группы, жизнь меня тогда к такому не готовила), без разметки, которые останавливаются третьими людьми, -
🆘падающие базы данных, по ошибке сделанная drop schema, падающие даги, задвоенные/отсутствующие местами данные, ситуации, когда сегодня ты посчитал конверсию 5%, а завтра 25%, сидишь нихуя не понимая, где ошибся,
🆘ситуации, когда тебя клюют заказчики каждый час, когда вводные от них меняются каждые 5 минут, когда надо выгрузить срочно-срочно оооооочень красивые данные, иначе побойся бога, сохрани здоровье топ-менеджеров...
После этого афгана у любого мало-мальски наблюдательного человека начинает формироваться свое мнение и стальная задница. Да, в некоторых вопросах оно мнение может быть твердым, в некоторых колебаться.
НО! в любой возможной ситуации опытный специалист будет вести диалог с заказчиком на равных. Не как калькулятор на побегушках, а как человек со своим мнением, которое скорее всего более обоснованное, потому что с данными напрямую работает именно аналитик.
Там, где будет нужно подкорректировать взгляд продакта, увести его руку от принятия дичь-решений, где можно подать данные под более выгодным углом, где можно выбрать более интересные метрики или провести АВ тест как-то иначе - мидл+ обязательно это озвучит.
Особенно если можно вырулить задачу так, чтобы вообще ее не делать. Ведь стальная задница, наученная опытом, понимает, что существует мало действительно горящих и критических задач. Зачастую для решения проблемы надо просто дать ей настояться.
Да, такое бывает, чем больше опыта, тем меньше осознанных целенаправленных телодвижений человек совершает.
Особенно если речь про большие и сложные сервисы.
Опытный постарается иметь максимально широкий контекст, быть в курсе, что делают на соседних направлениях.
Зачем?
1️⃣ очень интересно наблюдать синергию и внутреннюю конкуренцию разных направлений за рост метрик. Вы вырастили конверсию и хлопаете в ладоши от предвкушения премии? Вот только пидары из соседней команды раскатили фичу, которая сканнибализировала весь ваш трафик, поздравляю, но премия в другой раз😭
2️⃣ чем больше вы знаете о результатах работы коллег-аналитиков, тем меньше вам самим надо работать. Задачи часто пересекаются, может оказаться, что ваш коллега уже собрал нужную витрину, дашборд или вообще даже нужные метрики уже выгружал.
Больше контекста - больше понимания логики принятия решений наверху - больше власти, как на эти рычаги давить. Даже если речь про ваш мидловский микромасштаб. Надо же с чего-то начинать.
Джун же побежит сверкая пятками быстрее-быстрее делать. Либо побежит спрашивать лида/ментора, что уже в целом неплохой вариант. Главное - включать во время работы голову и думать, кто что делает и к чему это приводит. Собирать большое количество наблюдений и делать из них выводы.
В интернетах популярны тесты на психологический возраст. Поэтому по аналогии спрошу:
а у вас какой психологический грейд?🤡
сначала прочитай часть 1
Штука 2: мидл+ скорее всего видел в своей карьере ооооооооочень много дерьма.
🆘Ломающиеся каждый релиз данные,
🆎поломанные АВ тесты: без равномерного сплитования, без контрольной группы (я ахуела, когда мой разраб накодил тест только для тестовой группы, жизнь меня тогда к такому не готовила), без разметки, которые останавливаются третьими людьми, -
🆘падающие базы данных, по ошибке сделанная drop schema, падающие даги, задвоенные/отсутствующие местами данные, ситуации, когда сегодня ты посчитал конверсию 5%, а завтра 25%, сидишь нихуя не понимая, где ошибся,
🆘ситуации, когда тебя клюют заказчики каждый час, когда вводные от них меняются каждые 5 минут, когда надо выгрузить срочно-срочно оооооочень красивые данные, иначе побойся бога, сохрани здоровье топ-менеджеров...
После этого афгана у любого мало-мальски наблюдательного человека начинает формироваться свое мнение и стальная задница. Да, в некоторых вопросах оно мнение может быть твердым, в некоторых колебаться.
НО! в любой возможной ситуации опытный специалист будет вести диалог с заказчиком на равных. Не как калькулятор на побегушках, а как человек со своим мнением, которое скорее всего более обоснованное, потому что с данными напрямую работает именно аналитик.
Там, где будет нужно подкорректировать взгляд продакта, увести его руку от принятия дичь-решений, где можно подать данные под более выгодным углом, где можно выбрать более интересные метрики или провести АВ тест как-то иначе - мидл+ обязательно это озвучит.
Особенно если можно вырулить задачу так, чтобы вообще ее не делать. Ведь стальная задница, наученная опытом, понимает, что существует мало действительно горящих и критических задач. Зачастую для решения проблемы надо просто дать ей настояться.
Да, такое бывает, чем больше опыта, тем меньше осознанных целенаправленных телодвижений человек совершает.
Особенно если речь про большие и сложные сервисы.
Опытный постарается иметь максимально широкий контекст, быть в курсе, что делают на соседних направлениях.
Зачем?
Больше контекста - больше понимания логики принятия решений наверху - больше власти, как на эти рычаги давить. Даже если речь про ваш мидловский микромасштаб. Надо же с чего-то начинать.
Джун же побежит сверкая пятками быстрее-быстрее делать. Либо побежит спрашивать лида/ментора, что уже в целом неплохой вариант. Главное - включать во время работы голову и думать, кто что делает и к чему это приводит. Собирать большое количество наблюдений и делать из них выводы.
В интернетах популярны тесты на психологический возраст. Поэтому по аналогии спрошу:
а у вас какой психологический грейд?
Please open Telegram to view this post
VIEW IN TELEGRAM
Forwarded from Сенаторов.head()
AB-тесты: наблюдаемый эффект и MDE
"А как такое может быть?" — спрашивает продакт, когда мы, подводя итоги AB-теста, получили статзначимый аплифт в 0.8%, когда во время дизайна закладывали MDE = 1%.
И такая реакция абсолютно логична из нейминга минимальный детектируемый эффект (MDE). Но все же такое название создает путаницу. А дело вот в чем.
Нужно разделить три понятия:
▶️ Реальный эффект - это тот реальный эффект от нашей фичи, который мы не знаем и который хотим оценить
▶️ MDE - это наше предположение о реальном эффекте, который мы сможем задетектить с заданным размером выборки и с заданной вероятностью. Эта вероятность, она же мощность, как правило фиксируется на 80%.
▶️ Наблюдаемый эффект - этот тот эффект, который мы уже своими глазами видим между тестовой и контрольной группой по завершении теста. Наблюдаемый эффект не равняется реальному эффект хотя бы в силу того, что в данных всегда имеется шум, который будет толкать наш наблюдаемый эффект либо в плюс, либо в минус от реального.
Из этого уже следует, что не надо сравнивать MDE и наблюдаемый эффект, потому что это как сравнивать теплое с мягким.
Мы можем в наблюдаемом эффекте получить и меньшее значение, чем в MDE и этот эффект может быть статзначимым. Такое происходит нередко. Как в нашем примере с наблюдаемым статзначимым эффектом в 0.8%, а MDE = 1%. Финальное слово здесь за наблюдаемым эффектом.
А откуда могла взяться разница между ними? Здесь много вариантов. Возможно, реальный эффект на самом деле ниже, чем вы закладывали в MDE. Возможно, реальный эффект на самом деле равен MDE, но из-за флуктуации в данных, наш наблюдаемый эффект оказался ниже. Все равно важно помнить, что MDE — это про дизайн теста, а наблюдаемый эффект — про результаты теста.
Если хотите почитать подробнее и посмотреть на симуляции с графичками, то можете глянуть вот эти статьи)
📌 What if the Observed Effect is Smaller Than the MDE?
📌 Как же мощно я провел А/В-тест, или почему не стоит сравнивать наблюдаемый аплифт с MDE
"А как такое может быть?" — спрашивает продакт, когда мы, подводя итоги AB-теста, получили статзначимый аплифт в 0.8%, когда во время дизайна закладывали MDE = 1%.
И такая реакция абсолютно логична из нейминга минимальный детектируемый эффект (MDE). Но все же такое название создает путаницу. А дело вот в чем.
Нужно разделить три понятия:
Из этого уже следует, что не надо сравнивать MDE и наблюдаемый эффект, потому что это как сравнивать теплое с мягким.
Мы можем в наблюдаемом эффекте получить и меньшее значение, чем в MDE и этот эффект может быть статзначимым. Такое происходит нередко. Как в нашем примере с наблюдаемым статзначимым эффектом в 0.8%, а MDE = 1%. Финальное слово здесь за наблюдаемым эффектом.
А откуда могла взяться разница между ними? Здесь много вариантов. Возможно, реальный эффект на самом деле ниже, чем вы закладывали в MDE. Возможно, реальный эффект на самом деле равен MDE, но из-за флуктуации в данных, наш наблюдаемый эффект оказался ниже. Все равно важно помнить, что MDE — это про дизайн теста, а наблюдаемый эффект — про результаты теста.
Если хотите почитать подробнее и посмотреть на симуляции с графичками, то можете глянуть вот эти статьи)
Please open Telegram to view this post
VIEW IN TELEGRAM