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 | Чат |
YouTube
Находки в опенсорсе: git-lfs, не засоряй репозиторий большими файлами зря! #git
GigaCode – AI-ассистент разработчика c агентным режимом. Это полноценный помощник разработчика, способный понимать контекст проекта и выполнять задачи от анализа до готового решения. Ассистент сам открывает нужные файлы, вносит изменения, запускает тесты…
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
Forwarded from Artem Ryblov’s Data Science Weekly
PyTorch internals
Link: Site
Navigational hashtags: #armknowledgesharing #armtutorials
General hashtags: #dl #deeplearning #pytorch
@data_science_weekly
This talk is for those of you who have used PyTorch, and thought to yourself, "It would be great if I could contribute to PyTorch," but were scared by PyTorch's behemoth of a C++ codebase. I'm not going to lie: the PyTorch codebase can be a bit overwhelming at times. The purpose of this talk is to put a map in your hands: to tell you about the basic conceptual structure of a "tensor library that supports automatic differentiation", and give you some tools and tricks for finding your way around the codebase. I'm going to assume that you've written some PyTorch before, but haven't necessarily delved deeper into how a machine learning library is written.
The talk is in two parts: in the first part, I'm going to first introduce you to the conceptual universe of a tensor library. I'll start by talking about the tensor data type you know and love, and give a more detailed discussion about what exactly this data type provides, which will lead us to a better understanding of how it is actually implemented under the hood. If you're an advanced user of PyTorch, you'll be familiar with most of this material. We'll also talk about the trinity of "extension points", layout, device and dtype, which guide how we think about extensions to the tensor class. In the live talk at PyTorch NYC, I skipped the slides about autograd, but I'll talk a little bit about them in these notes as well.
The second part grapples with the actual nitty gritty details involved with actually coding in PyTorch. I'll tell you how to cut your way through swaths of autograd code, what code actually matters and what is legacy, and also all of the cool tools that PyTorch gives you for writing kernels.
Link: Site
Navigational hashtags: #armknowledgesharing #armtutorials
General hashtags: #dl #deeplearning #pytorch
@data_science_weekly
Forwarded from DevFM
How AI is transforming work at Anthropic
Ребята из Anthropic опубликовали исследование – как меняется работа инженеров внутри компании, которая сама делает Claude. И кажется, они прошлись по всем вопросам, которые сегодня беспокоят индустрию.
Вот, что меня заинтересовало.
Решаемые задачи и продуктивность
Это важный блок – особенно чтобы не выращивать ложные ожидания, будто агент будет выполнять всё под ключ.
– Инженеры используют Claude примерно в половине своей работы и оценивают прирост продуктивности до 50%
– Полностью отдать ему получается только до 20% задач – всё остальное выполняется с плотным контролем
– Треть работ, сделанных с Claude, просто не существовало бы без ИИ: nice-to-have тулзы, дополнительные дашборды
И вот здесь у меня возникает вопросик: если часть задач создаётся только потому, что теперь их дешево делать, не ломает ли это приоритизацию? Мы ускоряемся – но ускоряемся ли в нужную сторону?
Про важность делегирования
Когда начинаете работать с агентами, важно уметь давать ему шанс:
– начинать с маленьких и чётко проверяемых задач
– смотреть, с чем он справляется хорошо
– постепенно развивать навык понимать, какие задачи он делает хорошо, а какие лучше оставить себе
Антропик отдельно отмечают: многие негативные кейсы появляются не из-за тупости модели, а из-за неправильного выбора задачи.
На самом деле категорически согласен с этим пунктом.
Все становятся чуть более fullstack-чнее
Авторы пишут, что инженеры стали легче заходить в смежные зоны:
бэкендеры делают фронт, ресёрчеры собирают визуализации, секьюрити разбирают незнакомый код без лишней боли.
Порог входа в новые области сильно падает – можно набросать прототип, показать, отрефакторить и прогнать через Claude.
И важный эффект – меньше пинг-понга между командами: теперь можно не ждать коллег практически по каждому мелкому вопросу.
Что с навыками
– Инженеры отмечают страх потерять экспертизу: когда агент быстро прыгает к решению, ты меньше копаешься в доках и чужом коде – экспертиза формируется медленнее
– Парадокс: чтобы проверять агента, нужны именно те навыки, которые могут атрофироваться
– И вот здесь, как мне кажется, кроется большая проблема: непонятно, как теперь вырасти из джуна. У новичков исчезла часть естественных первых шагов, а спрос на настоящих сеньоров будет только расти. (Но не тех, кто в 25 считают себя сеньорами – извинити, вот такой я дед)
Коммуникации в командах
– 80–90% вопросов, которые раньше шли коллегам, теперь уходят сначала к Claude
– Это влияет на менторство: джуны меньше спрашивают, сеньоры реже передают экспертизу
В общем, очень рекомендую статью к прочтению.
И важно понимать: ребята прямо говорят, что это не истина в последней инстанции. Многое ещё требует прояснения. Да и в целом профессия меняется – и во что это выльется, пока не знает никто.
#ai
Ребята из Anthropic опубликовали исследование – как меняется работа инженеров внутри компании, которая сама делает Claude. И кажется, они прошлись по всем вопросам, которые сегодня беспокоят индустрию.
Вот, что меня заинтересовало.
Решаемые задачи и продуктивность
Это важный блок – особенно чтобы не выращивать ложные ожидания, будто агент будет выполнять всё под ключ.
– Инженеры используют Claude примерно в половине своей работы и оценивают прирост продуктивности до 50%
– Полностью отдать ему получается только до 20% задач – всё остальное выполняется с плотным контролем
– Треть работ, сделанных с Claude, просто не существовало бы без ИИ: nice-to-have тулзы, дополнительные дашборды
И вот здесь у меня возникает вопросик: если часть задач создаётся только потому, что теперь их дешево делать, не ломает ли это приоритизацию? Мы ускоряемся – но ускоряемся ли в нужную сторону?
Про важность делегирования
Когда начинаете работать с агентами, важно уметь давать ему шанс:
– начинать с маленьких и чётко проверяемых задач
– смотреть, с чем он справляется хорошо
– постепенно развивать навык понимать, какие задачи он делает хорошо, а какие лучше оставить себе
Антропик отдельно отмечают: многие негативные кейсы появляются не из-за тупости модели, а из-за неправильного выбора задачи.
На самом деле категорически согласен с этим пунктом.
Все становятся чуть более fullstack-чнее
Авторы пишут, что инженеры стали легче заходить в смежные зоны:
бэкендеры делают фронт, ресёрчеры собирают визуализации, секьюрити разбирают незнакомый код без лишней боли.
Порог входа в новые области сильно падает – можно набросать прототип, показать, отрефакторить и прогнать через Claude.
И важный эффект – меньше пинг-понга между командами: теперь можно не ждать коллег практически по каждому мелкому вопросу.
Что с навыками
– Инженеры отмечают страх потерять экспертизу: когда агент быстро прыгает к решению, ты меньше копаешься в доках и чужом коде – экспертиза формируется медленнее
– Парадокс: чтобы проверять агента, нужны именно те навыки, которые могут атрофироваться
– И вот здесь, как мне кажется, кроется большая проблема: непонятно, как теперь вырасти из джуна. У новичков исчезла часть естественных первых шагов, а спрос на настоящих сеньоров будет только расти. (Но не тех, кто в 25 считают себя сеньорами – извинити, вот такой я дед)
Коммуникации в командах
– 80–90% вопросов, которые раньше шли коллегам, теперь уходят сначала к Claude
– Это влияет на менторство: джуны меньше спрашивают, сеньоры реже передают экспертизу
В общем, очень рекомендую статью к прочтению.
И важно понимать: ребята прямо говорят, что это не истина в последней инстанции. Многое ещё требует прояснения. Да и в целом профессия меняется – и во что это выльется, пока не знает никто.
#ai
Forwarded from DevFM
Хотел написать небольшой пост – а в итоге получилась целая статья.
Недавно у меня был классный опыт парного программирования с товарищем: он пишет код, а я смотрю за его флоу и предлагаю оптимизации.
Собрал в статье практические советы, которые помогают при работе с агентами:
– как организовать удобный флоу
– почему не стоит просить «сделать всё под ключ» и как стоит
– как формировать рабочие rules
– зачем переключать модели и когда это спасает
– почему экспертиза разработчика всё ещё критично важна
Заходите почитать, если понравилась ставьте лайкосики.
#devfm
Недавно у меня был классный опыт парного программирования с товарищем: он пишет код, а я смотрю за его флоу и предлагаю оптимизации.
Собрал в статье практические советы, которые помогают при работе с агентами:
– как организовать удобный флоу
– почему не стоит просить «сделать всё под ключ» и как стоит
– как формировать рабочие rules
– зачем переключать модели и когда это спасает
– почему экспертиза разработчика всё ещё критично важна
Заходите почитать, если понравилась ставьте лайкосики.
#devfm
Хабр
Мой опыт разработки с агентами: советы
Недавно у меня была сессия парного программирования с хорошим товарищем. Получилась классная коллаборация: он пишет код, а я наблюдаю за его флоу и предлагаю оптимизации по части использования...
Forwarded from Свет из чёрного ящика
Подборка статей 2025 (часть 2)
Фундаментальные модели
- PinFM: Foundation Model for User Activity Sequences at a Billion-scale Visual Discovery Platform
- Large Foundation Model for Ads Recommendation
- Foundation Model for Personalized Recommendation
- Meta’s Generative Ads Model (GEM): The Central Brain Accelerating Ads Recommendation AI Innovation
- Realizing Scaling Laws in Recommender Systems: A Foundation–Expert Paradigm for Hyperscale Model Deployment
- External Large Foundation Model: How to Efficiently Serve Trillions of Parameters for Online Ads Recommendation
- Meta Lattice: Model Space Redesign for Cost-Effective Industry-Scale Ads Recommendations
Мультимодальность и Semantic Ids
- VL-CLIP: Enhancing Multimodal Recommendations via Visual Grounding and LLM-Augmented CLIP Embeddings
- Enhancing Embedding Representation Stability in Recommendation Systems with Semantic ID
- Progressive Semantic Residual Quantization for Multimodal-Joint Interest Modeling in Music Recommendation
- QARM: Quantitative Alignment Multi-Modal Recommendation at Kuaishou
- BiListing: Modality Alignment for listings
- DAS: Dual-Aligned Semantic IDs Empowered Industrial Recommender System
- Sparse Meets Dense: Unified Generative Recommendations with Cascaded Sparse-Dense Representations
- MOON Embedding: Multimodal Representation Learning for E-commerce Search Advertising
- MOON2.0: Dynamic Modality-balanced Multimodal Representation Learning for E-commerce Product Understanding
- LEMUR: Large scale End-to-end MUltimodal Recommendation
- STORE: Semantic Tokenization, Orthogonal Rotation and Efficient Attention for Scaling Up Ranking Models
- Multi-Aspect Cross-modal Quantization for Generative Recommendation
- Personalized Multi Modal Alignment Encoding for CTR-Recommendation in WeChat
- Generative Recommendation with Semantic IDs: A Practitioner’s Handbook
- CoFiRec: Coarse-to-Fine Tokenization for Generative Recommendation
- Generating Long Semantic IDs in Parallel for Recommendation
- A Simple Contrastive Framework Of Item Tokenization For Generative Recommendation
- Learnable Item Tokenization for Generative Recommendation
- SIDE: Semantic ID Embedding for effective learning from sequences
- ActionPiece: Contextually Tokenizing Action Sequences for Generative Recommendation
Фундаментальные модели
- PinFM: Foundation Model for User Activity Sequences at a Billion-scale Visual Discovery Platform
- Large Foundation Model for Ads Recommendation
- Foundation Model for Personalized Recommendation
- Meta’s Generative Ads Model (GEM): The Central Brain Accelerating Ads Recommendation AI Innovation
- Realizing Scaling Laws in Recommender Systems: A Foundation–Expert Paradigm for Hyperscale Model Deployment
- External Large Foundation Model: How to Efficiently Serve Trillions of Parameters for Online Ads Recommendation
- Meta Lattice: Model Space Redesign for Cost-Effective Industry-Scale Ads Recommendations
Мультимодальность и Semantic Ids
- VL-CLIP: Enhancing Multimodal Recommendations via Visual Grounding and LLM-Augmented CLIP Embeddings
- Enhancing Embedding Representation Stability in Recommendation Systems with Semantic ID
- Progressive Semantic Residual Quantization for Multimodal-Joint Interest Modeling in Music Recommendation
- QARM: Quantitative Alignment Multi-Modal Recommendation at Kuaishou
- BiListing: Modality Alignment for listings
- DAS: Dual-Aligned Semantic IDs Empowered Industrial Recommender System
- Sparse Meets Dense: Unified Generative Recommendations with Cascaded Sparse-Dense Representations
- MOON Embedding: Multimodal Representation Learning for E-commerce Search Advertising
- MOON2.0: Dynamic Modality-balanced Multimodal Representation Learning for E-commerce Product Understanding
- LEMUR: Large scale End-to-end MUltimodal Recommendation
- STORE: Semantic Tokenization, Orthogonal Rotation and Efficient Attention for Scaling Up Ranking Models
- Multi-Aspect Cross-modal Quantization for Generative Recommendation
- Personalized Multi Modal Alignment Encoding for CTR-Recommendation in WeChat
- Generative Recommendation with Semantic IDs: A Practitioner’s Handbook
- CoFiRec: Coarse-to-Fine Tokenization for Generative Recommendation
- Generating Long Semantic IDs in Parallel for Recommendation
- A Simple Contrastive Framework Of Item Tokenization For Generative Recommendation
- Learnable Item Tokenization for Generative Recommendation
- SIDE: Semantic ID Embedding for effective learning from sequences
- ActionPiece: Contextually Tokenizing Action Sequences for Generative Recommendation