Forwarded from DziS Science | Data Science
Привет всем!👋
Представьте, вы на работе перепробовали все SOTA решения, но ожидаемый эффект от построенных моделей так и не был получен. Или вы работаете в RnD подразделении в конкретной области и хотите оставаться "в теме". Тогда сегодняшний пост для вас.
Сегодня я покажу два интересных инструмента для упрощения работы с научными статьями, опубликованными на arXiv.
▪️Papers With Code
Сайт, на котором можно убедиться что вы попробовали все SOTA решения и увидеть сравнение на benchmark датасетах. Разделен на различные постановки задач. Кроме того, можно найти датасет по душе для проверки подходов.
▪️arXiv compressor
Достаточно прикольный сайт, на котором выкладываются все статьи по CV/ML/AI с arXiv, сгруппированные по датам выхода.
В качестве бонуса - небольшая суммаризация статьи с использованием LLM (для более детального поиска).
Удобно, если, вы, например занимаетесь, наукой и боитесь "проспать" исследования.
▪️Connected papers
Сайт, который строит граф связности для статей arXiv.
Берете конкретную статью, забиваете на сайт и получаете граф, в котором в вершинах авторы статьи и год выпуска, связи учитывают кто ссылался/на что ссылался.
Отличный пример использования: Вы увидели новый подход, но статья, мягко говоря посредственная, куча ссылок на предыдущие работы и тд. Вбиваете на сайт, наливаете чай и получаете граф. И тут, буквально, все смежные работы перед глазами.
▪️Zeta Alpha
Еще один сильный ресурс. Тут более глубокий функционал, включающий в себя все фишки из предыдущих источников. Тут тебе и суммаризация, и граф построят и поиск статей с кодом, и фильтр по конкретному источнику (конференции, dev блоги компаний, Toward Data Science)
Сохраняйте, пригодится!
По традиции, 🔥, если понравилось!
#ds_лайфхаки@dzis_science
Представьте, вы на работе перепробовали все SOTA решения, но ожидаемый эффект от построенных моделей так и не был получен. Или вы работаете в RnD подразделении в конкретной области и хотите оставаться "в теме". Тогда сегодняшний пост для вас.
Сегодня я покажу два интересных инструмента для упрощения работы с научными статьями, опубликованными на arXiv.
▪️Papers With Code
Сайт, на котором можно убедиться что вы попробовали все SOTA решения и увидеть сравнение на benchmark датасетах. Разделен на различные постановки задач. Кроме того, можно найти датасет по душе для проверки подходов.
▪️arXiv compressor
Достаточно прикольный сайт, на котором выкладываются все статьи по CV/ML/AI с arXiv, сгруппированные по датам выхода.
В качестве бонуса - небольшая суммаризация статьи с использованием LLM (для более детального поиска).
Удобно, если, вы, например занимаетесь, наукой и боитесь "проспать" исследования.
▪️Connected papers
Сайт, который строит граф связности для статей arXiv.
Берете конкретную статью, забиваете на сайт и получаете граф, в котором в вершинах авторы статьи и год выпуска, связи учитывают кто ссылался/на что ссылался.
Отличный пример использования: Вы увидели новый подход, но статья, мягко говоря посредственная, куча ссылок на предыдущие работы и тд. Вбиваете на сайт, наливаете чай и получаете граф. И тут, буквально, все смежные работы перед глазами.
▪️Zeta Alpha
Еще один сильный ресурс. Тут более глубокий функционал, включающий в себя все фишки из предыдущих источников. Тут тебе и суммаризация, и граф построят и поиск статей с кодом, и фильтр по конкретному источнику (конференции, dev блоги компаний, Toward Data Science)
Сохраняйте, пригодится!
По традиции, 🔥, если понравилось!
#ds_лайфхаки@dzis_science
Please open Telegram to view this post
VIEW IN TELEGRAM
Forwarded from 5 minutes of data
Apache Airflow® Best Practices: ETL & ELT Pipelines
44 страницы исчерпывающего руководства по одному из самых распространенных сценариев использования в data engineering на ведущем open-source оркестраторе!
Что вы узнаете из руководства:
📊 Сравнение ETL vs. ELT для вашей архитектурной стратегии - какой подход выбрать и почему.
💡 Лучшие практики написания DAG в Airflow - как создавать эффективные и поддерживаемые пайплайны.
⚡️ Ключевые функции для улучшения ваших ETL & ELT пайплайнов - поднимите свои процессы обработки данных на новый уровень.
Станьте экспертом в оркестрации данных с этим подробным руководством!
Скачать можно по ссылке
@data_whisperer
44 страницы исчерпывающего руководства по одному из самых распространенных сценариев использования в data engineering на ведущем open-source оркестраторе!
Что вы узнаете из руководства:
📊 Сравнение ETL vs. ELT для вашей архитектурной стратегии - какой подход выбрать и почему.
💡 Лучшие практики написания DAG в Airflow - как создавать эффективные и поддерживаемые пайплайны.
⚡️ Ключевые функции для улучшения ваших ETL & ELT пайплайнов - поднимите свои процессы обработки данных на новый уровень.
Станьте экспертом в оркестрации данных с этим подробным руководством!
Скачать можно по ссылке
@data_whisperer
Forwarded from Start Career in DS
📊 Как оценивать LLM: бенчмарки [Ч.2]
В прошлой части данной темы мы подробно разобрали метрики, с помощью которых можно оценивать LLM. Сегодня поговорим про оценку через бенчмарки.
❗️Бенчмарк - это набор тестовых вопросов для оценки конкретного навыка модели.
Как правило, он работает следующим образом:
1. Берут некоторый стандартный набор запросов к LLM
2. Собирают ответы модели
3. С помощью асессоров/либо автоматической метрикой получают некоторую оценку качества модели
🗑Виды бенчмарков:
1️⃣ Открытые: создаются, как эталоны, для оценки конкретного навыка модели, что позволяет сравнить производительность любой LLM. Зачастую под данными бенчмарками понимаются: MMLU, GSM8K, HumanEval и т.д.
Проблема таких бенчмарков в том, что вся тестовая выборка хранится в открытом доступе (где-нибудь на GitHub), что зачастую приводит к утечке данных в train-датасеты.
ℹ️GSM8K - содержит математические задачи уровня начальной школы; MMLU - создан для проверки уровня фактических знаний LLM по гуманитарным наукам, социальным наукам, истории и даже право; HumanEval - содержит задачи по программированию
2️⃣ Закрытые: имеют аналогичную цель, однако, их особенность в закрытом тестовом наборе данных, которые LLM в процессе обучения не видели. Сюда могут входить: MT-Bench, SQuAD, RE-Bench и т.д.
3️⃣ Собственные (доменные): не всегда доступные бенчмарки пригодны для вашей задачи, поэтому зачастую приходится формировать свои тестовые примеры и способы оценки.
📚Дополнительная литература:
- Простая и очень полезная статья по бенчмаркам от команды Яндекса. Здесь же можно почитать про недостатки различных бенчмарков и этого подхода в целом
- Материалы из прошлой статьи
- Большой набор описаний наиболее популярных бенчмарков
- Статья про самые популярные LLM-бенчмарки
- Статья "Полный гид по бенчмаркам LLM"
Обязательно ставьте ❤️ и 🔥 под постом!
Пишите свои комментарии 🙂
В прошлой части данной темы мы подробно разобрали метрики, с помощью которых можно оценивать LLM. Сегодня поговорим про оценку через бенчмарки.
❗️Бенчмарк - это набор тестовых вопросов для оценки конкретного навыка модели.
Как правило, он работает следующим образом:
1. Берут некоторый стандартный набор запросов к LLM
2. Собирают ответы модели
3. С помощью асессоров/либо автоматической метрикой получают некоторую оценку качества модели
🗑Виды бенчмарков:
1️⃣ Открытые: создаются, как эталоны, для оценки конкретного навыка модели, что позволяет сравнить производительность любой LLM. Зачастую под данными бенчмарками понимаются: MMLU, GSM8K, HumanEval и т.д.
Проблема таких бенчмарков в том, что вся тестовая выборка хранится в открытом доступе (где-нибудь на GitHub), что зачастую приводит к утечке данных в train-датасеты.
ℹ️GSM8K - содержит математические задачи уровня начальной школы; MMLU - создан для проверки уровня фактических знаний LLM по гуманитарным наукам, социальным наукам, истории и даже право; HumanEval - содержит задачи по программированию
2️⃣ Закрытые: имеют аналогичную цель, однако, их особенность в закрытом тестовом наборе данных, которые LLM в процессе обучения не видели. Сюда могут входить: MT-Bench, SQuAD, RE-Bench и т.д.
3️⃣ Собственные (доменные): не всегда доступные бенчмарки пригодны для вашей задачи, поэтому зачастую приходится формировать свои тестовые примеры и способы оценки.
📚Дополнительная литература:
- Простая и очень полезная статья по бенчмаркам от команды Яндекса. Здесь же можно почитать про недостатки различных бенчмарков и этого подхода в целом
- Материалы из прошлой статьи
- Большой набор описаний наиболее популярных бенчмарков
- Статья про самые популярные LLM-бенчмарки
- Статья "Полный гид по бенчмаркам LLM"
Обязательно ставьте ❤️ и 🔥 под постом!
Пишите свои комментарии 🙂
Forwarded from DevFM
Справляемся с рисками
Две совсем несложные статьи (раз, два), посвящённые риску и управлению рисками.
В первой даётся определение риска – это сочетание возможности получить выгоду и вероятности потерь. Мы принимаем риск не ради него самого, а ради целей, которые хотим достичь.
Для анализа риска автор разделяет его на два компонента:
– Вероятность: насколько возможно, что негативное событие произойдёт?
– Последствия: какие убытки или проблемы оно принесёт?
Для оценки риска предлагается использовать матрицы риска, которые делят вероятность и последствия на категории: низкие, средние, высокие. Таким образом можно наглядно увидеть, какие стечения обстоятельств действительно рисковые.
На самом деле важно понимать структуру риска и инструменты для его анализа. Вместо расплывчатого "это слишком рискованно" можно попробовать выдать что-то осмысленное: "Вероятность низкая, но последствия критические, значит, это требует дополнительной подготовки".
Вторая статья посвящена управлению рисками – действиям, направленным на снижение риска.
По сути мы возвращаемся к составляющим риска:
– Снижение вероятности. Мы пытаемся сделать так, чтобы рискованное событие с меньшей вероятностью происходило.
– Снижение последствий. Мы уменьшаем ущерб, если событие всё же произойдёт.
Автор приводит не айтишный пример, но, в целом, неплохо демонстрирующий суть.
Нужно переправиться через реку:
Для снижения вероятности падения в воду мы можем:
– Использовать командные техники переправы
– Искать более мелкий участок реки для перехода
Для снижения последствий попадания в воду мы можем:
– Запаковать вещи в водонепроницаемые мешки, чтобы предотвратить их повреждение
– Разместить спасателей ниже по течению, чтобы минимизировать риск травм или утопления
#teamwork
Две совсем несложные статьи (раз, два), посвящённые риску и управлению рисками.
В первой даётся определение риска – это сочетание возможности получить выгоду и вероятности потерь. Мы принимаем риск не ради него самого, а ради целей, которые хотим достичь.
Для анализа риска автор разделяет его на два компонента:
– Вероятность: насколько возможно, что негативное событие произойдёт?
– Последствия: какие убытки или проблемы оно принесёт?
Для оценки риска предлагается использовать матрицы риска, которые делят вероятность и последствия на категории: низкие, средние, высокие. Таким образом можно наглядно увидеть, какие стечения обстоятельств действительно рисковые.
На самом деле важно понимать структуру риска и инструменты для его анализа. Вместо расплывчатого "это слишком рискованно" можно попробовать выдать что-то осмысленное: "Вероятность низкая, но последствия критические, значит, это требует дополнительной подготовки".
Вторая статья посвящена управлению рисками – действиям, направленным на снижение риска.
По сути мы возвращаемся к составляющим риска:
– Снижение вероятности. Мы пытаемся сделать так, чтобы рискованное событие с меньшей вероятностью происходило.
– Снижение последствий. Мы уменьшаем ущерб, если событие всё же произойдёт.
Автор приводит не айтишный пример, но, в целом, неплохо демонстрирующий суть.
Нужно переправиться через реку:
Для снижения вероятности падения в воду мы можем:
– Использовать командные техники переправы
– Искать более мелкий участок реки для перехода
Для снижения последствий попадания в воду мы можем:
– Запаковать вещи в водонепроницаемые мешки, чтобы предотвратить их повреждение
– Разместить спасателей ниже по течению, чтобы минимизировать риск травм или утопления
#teamwork
jacobian.org
Mitigation - Jacob Kaplan-Moss
So you’ve identified a risk — now what do you do about it? Here’s a simple framework to help frame discussions about risk mitigation. It’s intentionally very simple, a basic starting point. I’ll present a more complex framework later in this series, but I…
Forwarded from Тимлид Очевидность | Евгений Антонов
Пятый месяц. Развитие ключевых людей
Прошел пятый месяц курса Стратоплана «Руководитель отдела». Перевалил за серединку уже 🙂
Контент первого, второго, третьего и четвертого месяцев я описывал ранее.
В отличие от прошлого месяца в этот раз удалось присоединиться к групповым практикам, и я в очередной раз убедился, что это ОГРОМНАЯ разница, конечно.
В этот раз часть контента была мне знакома не только потому, что я где-то что-то читал и изучал, а еще и потому, что похожие упражнения по работе с ключевыми людьми мы делали на работе. Тем не менее для меня традиционно нашлось и что-то новенькое.
Старенькое
- Ситуационное руководство. Как с кем работать при разных уровнях мотивации и компетентности. Это классика, и это надо уметь, если хочешь взращивать самостоятельные и профессиональные команды.
- Как с человеком поговорить о его желании и потенциальных направлениях к дальнейшему развитию. Тут, как всегда, я сторонник того, что не надо на каждого наседать, что развиваться – это ОБЯЗАТЕЛЬНО. Тем не менее это важная часть нашей работы. Где-то сами люди хотят профессионально и карьерно расти, но не знают как, и им надо помочь. А где-то некоторым людям надо расти, чтобы продолжать быть на хорошем уровне в команде, перед которой встают новые вызовы, и надо правильно это донести.
- HiPo и HiPro анализ своей команды (именно такое упражнение я как-то и делал на работе). С одной стороны, мне кажется, у опытного руководителя, погруженного в команду, это должно уже быть где-то в подсознании всегда сгенерено, а с другой стороны, для менее опытных ребят это хороший подход к рефлексии на тему своих соколиков.
- SWOT-анализ и модель GROW. Коротко говоря, это фреймворки на подумать о себе, о своих целях и о том, как и за счет чего ты их будешь достигать.
Новенькое
Тут растекусь мыслью только про одну тему. Но это мне прям ярко впечаталось, и хочется с вами поделиться.
У нас была тема про менторинг vs коучинг. Где менторинг — это про то, что очень опытный и компетентный в конкретном вопросе человек учит другого (ну, например, кузнец учит подмастерье ковать какие-нибудь загогулины), а коучинг — грубо говоря, не обязательно столько компетентный в этом деле человек задает тебе вопросы, и ты сам во всём разбираешься.
Вот мне всегда менторинг был ближе и понятнее. Как будто это профессионально, а коучинг — странное инфоцыганство из серии: «Так, ты пришел ко мне с проблемой. А сам что думаешь? А как будешь решать? Разобрался? С вас пятьтыщ».
Послушал я теоретическую часть и немного скептически двинулся к групповой практике, где мы реальные рабочие вопросы разбирали, чередуя то менторинговый подход, то коучинговый.
И оказалось, что коучинговый подход в некоторых вопросах отработал внезапно очень круто. Человек, ранее зафреймировавший себя на определенные мысли и поведение, столкнулся с проясняющими вопросами и, пока на них отвечал, сам всё понял и пришел к решению, которое ему подходит и нравится.
Короче говоря, если применять менторинг туда, где человек мало компетентен, то можно его научить. А если коучинг добавить туда, где он уже понимает, а просто застрял в силу разных обстоятельств, то есть шанс, что он сам разберется и примет подходящие для себя решения.
Прошел пятый месяц курса Стратоплана «Руководитель отдела». Перевалил за серединку уже 🙂
Контент первого, второго, третьего и четвертого месяцев я описывал ранее.
В отличие от прошлого месяца в этот раз удалось присоединиться к групповым практикам, и я в очередной раз убедился, что это ОГРОМНАЯ разница, конечно.
В этот раз часть контента была мне знакома не только потому, что я где-то что-то читал и изучал, а еще и потому, что похожие упражнения по работе с ключевыми людьми мы делали на работе. Тем не менее для меня традиционно нашлось и что-то новенькое.
Старенькое
- Ситуационное руководство. Как с кем работать при разных уровнях мотивации и компетентности. Это классика, и это надо уметь, если хочешь взращивать самостоятельные и профессиональные команды.
- Как с человеком поговорить о его желании и потенциальных направлениях к дальнейшему развитию. Тут, как всегда, я сторонник того, что не надо на каждого наседать, что развиваться – это ОБЯЗАТЕЛЬНО. Тем не менее это важная часть нашей работы. Где-то сами люди хотят профессионально и карьерно расти, но не знают как, и им надо помочь. А где-то некоторым людям надо расти, чтобы продолжать быть на хорошем уровне в команде, перед которой встают новые вызовы, и надо правильно это донести.
- HiPo и HiPro анализ своей команды (именно такое упражнение я как-то и делал на работе). С одной стороны, мне кажется, у опытного руководителя, погруженного в команду, это должно уже быть где-то в подсознании всегда сгенерено, а с другой стороны, для менее опытных ребят это хороший подход к рефлексии на тему своих соколиков.
- SWOT-анализ и модель GROW. Коротко говоря, это фреймворки на подумать о себе, о своих целях и о том, как и за счет чего ты их будешь достигать.
Новенькое
Тут растекусь мыслью только про одну тему. Но это мне прям ярко впечаталось, и хочется с вами поделиться.
У нас была тема про менторинг vs коучинг. Где менторинг — это про то, что очень опытный и компетентный в конкретном вопросе человек учит другого (ну, например, кузнец учит подмастерье ковать какие-нибудь загогулины), а коучинг — грубо говоря, не обязательно столько компетентный в этом деле человек задает тебе вопросы, и ты сам во всём разбираешься.
Вот мне всегда менторинг был ближе и понятнее. Как будто это профессионально, а коучинг — странное инфоцыганство из серии: «Так, ты пришел ко мне с проблемой. А сам что думаешь? А как будешь решать? Разобрался? С вас пятьтыщ».
Послушал я теоретическую часть и немного скептически двинулся к групповой практике, где мы реальные рабочие вопросы разбирали, чередуя то менторинговый подход, то коучинговый.
И оказалось, что коучинговый подход в некоторых вопросах отработал внезапно очень круто. Человек, ранее зафреймировавший себя на определенные мысли и поведение, столкнулся с проясняющими вопросами и, пока на них отвечал, сам всё понял и пришел к решению, которое ему подходит и нравится.
Короче говоря, если применять менторинг туда, где человек мало компетентен, то можно его научить. А если коучинг добавить туда, где он уже понимает, а просто застрял в силу разных обстоятельств, то есть шанс, что он сам разберется и примет подходящие для себя решения.
Forwarded from Аналитика данных / Data Study
Analysis.pdf
2 MB
Нашёл у себя в сундуке полезных материалов презентацию с 39 видами различных видов бизнес/системного/дата/продуктового анализа, а также инструменты проектного управления, которые полезно применять в разных задачах.
В файле описаны ключевые аспекты каждой методологии, если захотите применять что-то на практике, то лучше изучить дополнительные материалы.
Хотите описать сильные и слабые стороны продукта, берите SWOT (слайд 2).
Есть потребность оценки рисков и проектных зависимостей, рассмотрите RAID Log (слайд 20).
Хотите зафиксировать список стейкхолдеров проекта и понять кому и по каким вопросам обращаться, с кем согласовывать, а кому просто прийти с готовым результатом - посмотрите на Stakeholder Analysis (слайд 17)
Только запускаете проект и думаете какую информацию для старта важно собрать - воспользуйтесь Project Charter (слайд 26)
Когда-то много из этих видов анализа использовал в работе, потом настал период когда зарылся в данные и технику. Сейчас похоже начинается цикл, когда часть этих инструментов опять войдут в мою повседневную работу
В файле описаны ключевые аспекты каждой методологии, если захотите применять что-то на практике, то лучше изучить дополнительные материалы.
Хотите описать сильные и слабые стороны продукта, берите SWOT (слайд 2).
Есть потребность оценки рисков и проектных зависимостей, рассмотрите RAID Log (слайд 20).
Хотите зафиксировать список стейкхолдеров проекта и понять кому и по каким вопросам обращаться, с кем согласовывать, а кому просто прийти с готовым результатом - посмотрите на Stakeholder Analysis (слайд 17)
Только запускаете проект и думаете какую информацию для старта важно собрать - воспользуйтесь Project Charter (слайд 26)
Когда-то много из этих видов анализа использовал в работе, потом настал период когда зарылся в данные и технику. Сейчас похоже начинается цикл, когда часть этих инструментов опять войдут в мою повседневную работу
Forwarded from sahil
Summary : Собеседование в майкрософт
1) Системный дизайн : задача спроектировать википедию.
Первые 20 минут собеса общение. За последние 20 минут обсудить дизайн, компоненты и что необходимо + 5 минут для моих вопросов.
Мнение : Вроде как прошел, не знал про эластик для поиска, но обсудил различные стратегии скэйлинга. Обсудил все требования + back to envelop
2) OOP Дизайн : задача спроектировать систему букинга билетов для самолетов.
Первые 20 минут собеса общение. За последние 20 минут обсудить дизайн, компоненты и что необходимо + 5 минут для моих вопросов.
Мнение : Решение понравилось собеседующему, вроде как обсудили различные моменты с API
НО, я не закодил полностью решение. Т.е только базовый API и то не 100% верный с точки зрения всех моментов
3) Бихейв : обсуждение опыта и мое поведение в различных ситуациях.
Весь собес просто обсуждение моего опыта, поведения и все. Т.е ничего особого не было
Мнение : Прошел, вроде есть матч
4) Алгоритмы : задача написать алгоритм для определения того, что одно домино упадет на другое и расстояние между ними 1 метр. Усложнили на последние пару минут требования. Все равно закодил. Задача уровня easy
Первые 20 минут собеса общение. За последние 20 минут обсудить дизайн, компоненты и что необходимо + 5 минут для моих вопросов.
Wrap up :
Мне кажется, что я прошел собеседование, но тут уже им решать. Было классно сходить на такое собеседование. Все ребята были очень позитивные и классно общались. Вот бы такое во всех компаниях.
1) Системный дизайн : задача спроектировать википедию.
Первые 20 минут собеса общение. За последние 20 минут обсудить дизайн, компоненты и что необходимо + 5 минут для моих вопросов.
Мнение : Вроде как прошел, не знал про эластик для поиска, но обсудил различные стратегии скэйлинга. Обсудил все требования + back to envelop
2) OOP Дизайн : задача спроектировать систему букинга билетов для самолетов.
Первые 20 минут собеса общение. За последние 20 минут обсудить дизайн, компоненты и что необходимо + 5 минут для моих вопросов.
Мнение : Решение понравилось собеседующему, вроде как обсудили различные моменты с API
НО, я не закодил полностью решение. Т.е только базовый API и то не 100% верный с точки зрения всех моментов
3) Бихейв : обсуждение опыта и мое поведение в различных ситуациях.
Весь собес просто обсуждение моего опыта, поведения и все. Т.е ничего особого не было
Мнение : Прошел, вроде есть матч
4) Алгоритмы : задача написать алгоритм для определения того, что одно домино упадет на другое и расстояние между ними 1 метр. Усложнили на последние пару минут требования. Все равно закодил. Задача уровня easy
Первые 20 минут собеса общение. За последние 20 минут обсудить дизайн, компоненты и что необходимо + 5 минут для моих вопросов.
Wrap up :
Мне кажется, что я прошел собеседование, но тут уже им решать. Было классно сходить на такое собеседование. Все ребята были очень позитивные и классно общались. Вот бы такое во всех компаниях.
Forwarded from Aspiring Data Science (Anatoly Alekseev)
#python #debugging #ic #icecream
https://medium.com/pythoneers/debugging-in-python-replace-print-with-ic-and-do-it-like-a-pro-18f330c863cb
from icecream import ic
# Using ic() to debug
ic(add(10, 20))
ic(add(30, 40))
ic| add(10, 20): 30
ic| add(30, 40): 70
ic.disable() # Disables ic()
ic(multiply(3, 3)) # Prints nothing
ic.enable() # Re-enables ic()
ic(multiply(3, 3)) # Output: ic| multiply(3, 3): 9
def log_to_file(text):
with open("debug.log", "a") as f:
f.write(text + "\n")
ic.configureOutput(prefix="DEBUG| ", outputFunction=log_to_file)
ic(multiply(7, 7))
https://medium.com/pythoneers/debugging-in-python-replace-print-with-ic-and-do-it-like-a-pro-18f330c863cb
Medium
Debugging in Python: Replace print() with ic() and Do It Like a Pro
Introduction:
Forwarded from От идеи до продукта B2B & B2C | Виктор Чертков (Viktor Chertkov)
Нет не реклама, просто сам активно стал использовать и открыл для себя много новых моделей. Еще и большинство бесплатных
Недавно нашел ресурс — Artificial Analysis. Это библиотека актуальных AI-моделей, где можно не просто смотреть, но и выбирать те, которые реально подходят под конкретные задачи.
Что круто:
Я уже добавил в свою работу несколько инструментов, которые сильно ускорили процессы анализа и проверки гипотез. За счет этого:
Если вы работаете с данными, гипотезами или просто ищете способы прокачать свою продуктивность — загляните. Инструменты ИИ должны работать на вас, а не наоборот.
Please open Telegram to view this post
VIEW IN TELEGRAM
Forwarded from Глеб Михайлов
Что бы я делал по-другому, работая в IT?
1. Больше бы общался с людьми.
Когда я только начал работать, я вел себя на работе очень замкнуто. Ни с кем не сближался. А это одна из главных фич работы (и жизни)!
Это как еще одни одноклассники и одногруппники! И среди них можно найти друзей, мужа/жену, будущих бизнес-партнеров, менторов.
И просто это фан. Насколько приятнее мне стало ходить на работу, когда я начал больше общаться с людьми. И насколько быстрее стали пролетать "тяжелые" будни.
***
2. Чаще бы менял работу, чтобы получать больше денег.
Всю карьеру я считал, что надо хотя бы год работать на одном месте, чтобы потом не было проблем с поиском работы.
По факту, на 3 из 6 моих офисных работ я работал меньше года, и с моей карьерой ничего страшного не случилось. Только рост в зарплате и в скилах).
***
3. Больше бы отказывался от задач и встреч.
В корпоративной жизни очень большое количество задач и встреч абсолютно бесполезны. Как минимум, они не так важны и срочны, как их преподносят.
И если спорить с начальником – это обычно непродуктивно, то предложить более легкую альтернативу или более комфортный срок – это всегда уместно.
Со встречами еще легче: можно просто не принимать их. И если никто не напишет, значит, я там особо не нужен.
Ну и, конечно, ставить заглушки на обед и на время после 18:00. Заглушки лучше всего делать с небольшим буфером 15-30 минут в обе стороны, чтобы встречи впритык к обеду не ставили – это неудобно, т.к. обед превращается в суету.
Отстаивать свои личные границы не просто, и это не раз приводило меня к конфликтам и увольнениям. Но это того стоило).
***
4. Более открыто бы занимался обучением на работе.
Я всегда боялся читать книги, проходить курсы и делать свои проекты на работе. Ведь на работе надо работать!
Но рабочий день слишком длинный, столько задач нет. Если всё делать эффективно, то рабочие задачи можно раскидать за 2-3 часа в день, а остальное время заниматься своим развитием.
И если кто-то задает вопросы, можно ответить, что ты повышаешь свою квалификацию, и это полезно для компании.
И еще неочевидный факт: когда ты сидишь и учишься, то со стороны это ничем не отличается от того, что ты сидишь и работаешь))).
***
5. Больше бы вкладывался в маркетинг и продажи.
Профессиональные скиллы – это круто. Но успех в карьере зависит не от них!
Профессиональные скиллы – это, по сути, тривиально. Они просто должны быть на приличном уровне.
Поэтому при наличии минимальных профессиональных скиллов, достаточных для работы, гораздо выгоднее вкладываться в маркетинг и продажи.
Маркетинг: резюме, портфолио, личный бренд.
Продажи: умение продавать себя, умение проходить технические интервью, умение договариваться.
Если ты выгодно продаешь свои скиллы, то получаешь лучшее финансирование своего развития и жизни, больше времени на своё развитие, заряженных людей вокруг и вообще более интересный опыт.
А ещё ты не боишься, что тебя уволят или сократят и чувствуешь себя уверенно: ну уволят и хорошо – я умею продавать себя и быстро найду себе работу еще лучше!
***
Кстати, если хочешь прокачать центровой навык продаж в мире IT – умение проходить технические и алгоритмические интервью, то сейчас полным ходом идет набор в 8-й поток моего курса по алгоритмам и структурам данных (старт потока 3 февраля).
Этот курс выбрало уже 189 человек, а студенты и выпускники моего курса проходят интервью в топовые компании. Это значит, что мой курс уже стал проверенным временем и реальным миром продуктом, который сможет довести тебя до результата.
Хочешь выгодно продать свои скиллы? Переходи в бот и узнай, как научиться писать эффективный код, проходить алгоритмические интервью и стать высокооплачиваемым профессионалом без мучений и выгорания, даже если сейчас ты еле-еле кодишь!
1. Больше бы общался с людьми.
Когда я только начал работать, я вел себя на работе очень замкнуто. Ни с кем не сближался. А это одна из главных фич работы (и жизни)!
Это как еще одни одноклассники и одногруппники! И среди них можно найти друзей, мужа/жену, будущих бизнес-партнеров, менторов.
И просто это фан. Насколько приятнее мне стало ходить на работу, когда я начал больше общаться с людьми. И насколько быстрее стали пролетать "тяжелые" будни.
***
2. Чаще бы менял работу, чтобы получать больше денег.
Всю карьеру я считал, что надо хотя бы год работать на одном месте, чтобы потом не было проблем с поиском работы.
По факту, на 3 из 6 моих офисных работ я работал меньше года, и с моей карьерой ничего страшного не случилось. Только рост в зарплате и в скилах).
***
3. Больше бы отказывался от задач и встреч.
В корпоративной жизни очень большое количество задач и встреч абсолютно бесполезны. Как минимум, они не так важны и срочны, как их преподносят.
И если спорить с начальником – это обычно непродуктивно, то предложить более легкую альтернативу или более комфортный срок – это всегда уместно.
Со встречами еще легче: можно просто не принимать их. И если никто не напишет, значит, я там особо не нужен.
Ну и, конечно, ставить заглушки на обед и на время после 18:00. Заглушки лучше всего делать с небольшим буфером 15-30 минут в обе стороны, чтобы встречи впритык к обеду не ставили – это неудобно, т.к. обед превращается в суету.
Отстаивать свои личные границы не просто, и это не раз приводило меня к конфликтам и увольнениям. Но это того стоило).
***
4. Более открыто бы занимался обучением на работе.
Я всегда боялся читать книги, проходить курсы и делать свои проекты на работе. Ведь на работе надо работать!
Но рабочий день слишком длинный, столько задач нет. Если всё делать эффективно, то рабочие задачи можно раскидать за 2-3 часа в день, а остальное время заниматься своим развитием.
И если кто-то задает вопросы, можно ответить, что ты повышаешь свою квалификацию, и это полезно для компании.
И еще неочевидный факт: когда ты сидишь и учишься, то со стороны это ничем не отличается от того, что ты сидишь и работаешь))).
***
5. Больше бы вкладывался в маркетинг и продажи.
Профессиональные скиллы – это круто. Но успех в карьере зависит не от них!
Профессиональные скиллы – это, по сути, тривиально. Они просто должны быть на приличном уровне.
Поэтому при наличии минимальных профессиональных скиллов, достаточных для работы, гораздо выгоднее вкладываться в маркетинг и продажи.
Маркетинг: резюме, портфолио, личный бренд.
Продажи: умение продавать себя, умение проходить технические интервью, умение договариваться.
Если ты выгодно продаешь свои скиллы, то получаешь лучшее финансирование своего развития и жизни, больше времени на своё развитие, заряженных людей вокруг и вообще более интересный опыт.
А ещё ты не боишься, что тебя уволят или сократят и чувствуешь себя уверенно: ну уволят и хорошо – я умею продавать себя и быстро найду себе работу еще лучше!
***
Кстати, если хочешь прокачать центровой навык продаж в мире IT – умение проходить технические и алгоритмические интервью, то сейчас полным ходом идет набор в 8-й поток моего курса по алгоритмам и структурам данных (старт потока 3 февраля).
Этот курс выбрало уже 189 человек, а студенты и выпускники моего курса проходят интервью в топовые компании. Это значит, что мой курс уже стал проверенным временем и реальным миром продуктом, который сможет довести тебя до результата.
Хочешь выгодно продать свои скиллы? Переходи в бот и узнай, как научиться писать эффективный код, проходить алгоритмические интервью и стать высокооплачиваемым профессионалом без мучений и выгорания, даже если сейчас ты еле-еле кодишь!
Forwarded from Vikhr models
This media is not supported in your browser
VIEW IN TELEGRAM
Salt
Мы начали собирать эту модель в августе, в конце августа получили первый прототип, а потом стало выходить миллион вариантов вида: а давайте whisper для речи+GAN для генерации аудио, а потом вышел FishAudio который лучше работает, да и в целом хорошая модель.
Мы шли с другого конца, собрали решение поверх lm с расширенным токенайзером, использовали WavTokenizer для токенизации аудио.
Учили около 150 а100 часов для финального экспа, но количество экспов и денег сожженых в этот проект переваливает за то сколько я потратил на оригинальные Вихри.
По итогу получился не трансформер который понимает речь и генерирует речь, а Dalle1 like tts на основе llama3 3b.
Сейчас идут работы по дообучению на музыку/аудио, вероятно проект получит папир и обновление.
Сейчас модель неплохо работает на английском, на русский мы доучиваем модель.
huggingface
collab
А еще мы учимся на ошибках и в этот раз выкладываем весь код для обучения и aulate для подсчета аудио метрик
В релизе участвовали: Ksenya (основной контрибьютор), Костя, а я ходил пинал чтобы оно все не развалилось и доехало до какого то состояния.
Мы начали собирать эту модель в августе, в конце августа получили первый прототип, а потом стало выходить миллион вариантов вида: а давайте whisper для речи+GAN для генерации аудио, а потом вышел FishAudio который лучше работает, да и в целом хорошая модель.
Мы шли с другого конца, собрали решение поверх lm с расширенным токенайзером, использовали WavTokenizer для токенизации аудио.
Учили около 150 а100 часов для финального экспа, но количество экспов и денег сожженых в этот проект переваливает за то сколько я потратил на оригинальные Вихри.
По итогу получился не трансформер который понимает речь и генерирует речь, а Dalle1 like tts на основе llama3 3b.
Сейчас идут работы по дообучению на музыку/аудио, вероятно проект получит папир и обновление.
Сейчас модель неплохо работает на английском, на русский мы доучиваем модель.
huggingface
collab
А еще мы учимся на ошибках и в этот раз выкладываем весь код для обучения и aulate для подсчета аудио метрик
В релизе участвовали: Ksenya (основной контрибьютор), Костя, а я ходил пинал чтобы оно все не развалилось и доехало до какого то состояния.