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
Forwarded from Pavel Zloi
В продолжение темы про обучение на ИТшника, вдобавок к тем двум книгам про системный дизайн хочу порекомендовать пару видеороликов на YouTube-канале блогера SHIFU (не реклама, просто очень понравилось, как автор изложил тему).
Как бесплатно научиться программировать с помощью ИИ
Тут общая база про использование ИИ для обучения на примере сайтика Perplexity (регистрация бесплатная), автор неплохо разжевал почему обучение с помощью нейронок в разы более удобное и практичное, чем классические курсы.
Курсы программирования не работают, вот как надо!
В этом видеоролике автор показал, как быстренько сваять свой собственный курс обучения и адаптировать его под свой уровень знаний и стиль обучения.
От себя бы я ещё добавил, что рекомендую закидывать в нейронку готовые курсы или даже оглавления разных курсов которые вам нравится и просить нейронку сначала построить для вас индивидуальный roadmap обучения, а потом по каждой теме по отдельности расписывать урок, общей темой, ссылками на доп.материалы (видео, подкасты, книги, статьи), практические материалы, вопросы для самопроверки и ссылками на другие главы roadmap для вашего удобства.
После чего просто садиться и учиться, адаптируя программу под себя.
Надеюсь мои рекомендации вам пригодятся, желаю удачи всем кто только вкатывается в ИТ или нейронки!
Как бесплатно научиться программировать с помощью ИИ
Тут общая база про использование ИИ для обучения на примере сайтика Perplexity (регистрация бесплатная), автор неплохо разжевал почему обучение с помощью нейронок в разы более удобное и практичное, чем классические курсы.
Курсы программирования не работают, вот как надо!
В этом видеоролике автор показал, как быстренько сваять свой собственный курс обучения и адаптировать его под свой уровень знаний и стиль обучения.
От себя бы я ещё добавил, что рекомендую закидывать в нейронку готовые курсы или даже оглавления разных курсов которые вам нравится и просить нейронку сначала построить для вас индивидуальный roadmap обучения, а потом по каждой теме по отдельности расписывать урок, общей темой, ссылками на доп.материалы (видео, подкасты, книги, статьи), практические материалы, вопросы для самопроверки и ссылками на другие главы roadmap для вашего удобства.
После чего просто садиться и учиться, адаптируя программу под себя.
Надеюсь мои рекомендации вам пригодятся, желаю удачи всем кто только вкатывается в ИТ или нейронки!
Forwarded from AI и грабли
Промежуточные инсайты по нашему краудсорсингу кейсов об ИИ в разработке
Выписал короткими тезисами – либо практичное, либо забавное, иногда с цитатами:
Полезные лайфхаки:
В инструкциях явно давать defend режим, где он должен критически относится к моим командам
Ручной индекс проекта (тут лайк за простую реализацию)
Делать conventions/*md, а в рулсах для CC/Codex/Cursor ссылаться на них – чтобы не синкать зоопарк стандартов + правила грузятся динамически под задачу, а не засоряют контекст
Вопреки расхожему мнению, feedback loop нужен не для качества, а для скорости – убираем самый скучный human-in-the-loop (ts, lint, unit-tests, e2e, browser mcp)
Про большие компании и кодобазы:
На больших репо полезнее всего начинать не с написания кода, а с код ревью, поиска релевантного контекста для изменений и анализа логов со сложными паттернами
Для больших кодобаз резать задачи не по фичам, а по файлам/модулям, где нужно сделать изменения (декомпозиция не по числу изменений, а по их "локальности")
Экспериментально-философское:
Adversarial AI – сделать, чтобы модели конкурировали. Один агент делает, другой ревьюит и пытается сломать. Часто это даже разные тулы (например, Claude Code + Codex)
Изменение подходов от поддержки и дебага кода к "удали и сгенери заново"
PM-Разработчик - простые crud решения уже уходят к менеджерам
Автопромптинг:
Еще пару кейсов, по которым интересно почитать прям исходный текст:
Фаундер построил конвейер из 17 специализированных агентов, где у каждого «рабочего» агента есть агент-«дублер», проверяющий работу. Полный цикл: от архитектуры до позитивных/негативных тестов и PR.
Тимлид использовал Cursor для расследования сложного инцидента с ребалансировкой Kafka-консьюмеров на проде: как скармливать ИИ логи "до", "во время" и "после" аварии, чтобы он нашел неочевидную корреляцию между нагрузкой и конфигом, которую люди не увидели.
Переписать 40 сырых SQL-запросов на ORM, не сломав бизнес-логику. Пошаговый гайд: как сгруппировать запросы по сущностям через rg, сгенерировать слои репозиториев и заставить ИИ найти N+1 проблемы по ходу.
А чтобы почитать исходные тексты, присоединяйтесь к нашему краудсорингу 🤗
Аттракцион работает до 21 декабря (когда мы разошлем доступ к обезличенным кейсам)
Оставить кейс и получить доступ
А еще – альтернативные мнения: от Макса; от Тимура
Выписал короткими тезисами – либо практичное, либо забавное, иногда с цитатами:
Полезные лайфхаки:
В инструкциях явно давать defend режим, где он должен критически относится к моим командам
Ручной индекс проекта (тут лайк за простую реализацию)
tree репозитория с одной строкой описания на каждый файл
Делать conventions/*md, а в рулсах для CC/Codex/Cursor ссылаться на них – чтобы не синкать зоопарк стандартов + правила грузятся динамически под задачу, а не засоряют контекст
Вопреки расхожему мнению, feedback loop нужен не для качества, а для скорости – убираем самый скучный human-in-the-loop (ts, lint, unit-tests, e2e, browser mcp)
Про большие компании и кодобазы:
На больших репо полезнее всего начинать не с написания кода, а с код ревью, поиска релевантного контекста для изменений и анализа логов со сложными паттернами
Для больших кодобаз резать задачи не по фичам, а по файлам/модулям, где нужно сделать изменения (декомпозиция не по числу изменений, а по их "локальности")
Экспериментально-философское:
Adversarial AI – сделать, чтобы модели конкурировали. Один агент делает, другой ревьюит и пытается сломать. Часто это даже разные тулы (например, Claude Code + Codex)
Изменение подходов от поддержки и дебага кода к "удали и сгенери заново"
PM-Разработчик - простые crud решения уже уходят к менеджерам
Автопромптинг:
Люблю использовать notebook ml для дистилляции промптов. На вход подал книгу по проектированию баз данных, он мне выдал промпт со ссылками... Теперь у меня есть свой агент который проектирует базы данных
Еще пару кейсов, по которым интересно почитать прям исходный текст:
Фаундер построил конвейер из 17 специализированных агентов, где у каждого «рабочего» агента есть агент-«дублер», проверяющий работу. Полный цикл: от архитектуры до позитивных/негативных тестов и PR.
Тимлид использовал Cursor для расследования сложного инцидента с ребалансировкой Kafka-консьюмеров на проде: как скармливать ИИ логи "до", "во время" и "после" аварии, чтобы он нашел неочевидную корреляцию между нагрузкой и конфигом, которую люди не увидели.
Переписать 40 сырых SQL-запросов на ORM, не сломав бизнес-логику. Пошаговый гайд: как сгруппировать запросы по сущностям через rg, сгенерировать слои репозиториев и заставить ИИ найти N+1 проблемы по ходу.
А чтобы почитать исходные тексты, присоединяйтесь к нашему краудсорингу 🤗
Аттракцион работает до 21 декабря (когда мы разошлем доступ к обезличенным кейсам)
Оставить кейс и получить доступ
А еще – альтернативные мнения: от Макса; от Тимура
Forwarded from AI и грабли
Правило Парето в кодинге с ИИ (да и вообще во всех сложных задачах с ИИ)
Вы, наверное, слышали о том, что лучше решать задачи "в один промпт" (ваншотить), а не делать бесконечное количество мелких правок в чате с моделью, растягивая контекст.
У этого подхода в чистом виде есть пара проблем:
1. Он не работает. Ну правда, в реальности результат почти никогда не соответствует ожиданиям на 100%
2. Он жрет много времени, лимитов, денег. Если полностью перезапускать запрос из-за мелкой правки, то придется ждать очередные 2-5-10 минут и тратить сотни тысяч токенов. И то без гарантии, что нет отвалится что-то другое, что до этого получилось хорошо
Но и возник он не на пустом месте – большое количество правок отдельными сообщениями реально ухудшает работу. И проблема тут не только в длине контекста, но и в том, что модель уже пошла по какому-то пути, и ей когнитивно сложно сделать шаг назад и "забыть" неправильную дорогу. Что у нее в контексте – за то и цепляется.
Я для себя вывел, что каждая такая правка примерно в 3-5 раз менее эффективна, чем если писать пожелание в исходном запросе. А значит, с первого запроса должно корректно выполнятся большинство работы. Если это не так, то:
- либо декомпозирую задачу
- либо прописываю больше деталей
- либо спрашиваю агента, чего не хватило или что в исходном запросе помешало получить желаемое, а потом прошу обновить за меня промпт, "стираю память" и перезапускаю
Ну и мысль про правило Парето помогает не подгорать от того, что на 20% правок уходит 80% времени – так и должно быть
Вы, наверное, слышали о том, что лучше решать задачи "в один промпт" (ваншотить), а не делать бесконечное количество мелких правок в чате с моделью, растягивая контекст.
У этого подхода в чистом виде есть пара проблем:
1. Он не работает. Ну правда, в реальности результат почти никогда не соответствует ожиданиям на 100%
2. Он жрет много времени, лимитов, денег. Если полностью перезапускать запрос из-за мелкой правки, то придется ждать очередные 2-5-10 минут и тратить сотни тысяч токенов. И то без гарантии, что нет отвалится что-то другое, что до этого получилось хорошо
Но и возник он не на пустом месте – большое количество правок отдельными сообщениями реально ухудшает работу. И проблема тут не только в длине контекста, но и в том, что модель уже пошла по какому-то пути, и ей когнитивно сложно сделать шаг назад и "забыть" неправильную дорогу. Что у нее в контексте – за то и цепляется.
Я для себя вывел, что каждая такая правка примерно в 3-5 раз менее эффективна, чем если писать пожелание в исходном запросе. А значит, с первого запроса должно корректно выполнятся большинство работы. Если это не так, то:
- либо декомпозирую задачу
- либо прописываю больше деталей
- либо спрашиваю агента, чего не хватило или что в исходном запросе помешало получить желаемое, а потом прошу обновить за меня промпт, "стираю память" и перезапускаю
Ну и мысль про правило Парето помогает не подгорать от того, что на 20% правок уходит 80% времени – так и должно быть
Forwarded from AI и грабли
То, что выше – это дамп моего канала вместе с комментариями к моим постам.
Что ты можешь рассказать про меня и про моих читателей на основе того, что они лайкают, комментируют и тех текстов, которые я пишу?
Твоя задача – делать не psychological insights, but behavioural insights. То есть не делать выводы о том, почему я что-то пишу, а делать выводы о том, что я пишу, что я делаю, как я это делаю. Не говорить, кто я такой, а говорить, как я себя веду. При этом они должны быть не только позитивными, но и негативными, да, потому что это что-то, чего я смогу сделать. Инсайты двигаться дальше.
Ну и плюс этот разбор будет интереснее почитать моим подписчикам, если там будет еще и негатив какой-то и прожарочка немножко
Пока ничего не пиши про читателей, я отдельным промтом это запрошу.
И прожарка не должна быть отдельной. Она должна, ну как бы, я хочу обычный список про меня. Просто в нем должны быть и такие пункты, которые скорее позитивные, и такие пункты, которые скорее негативные. Но желательно тоже без супер ярких, как бы очевидно гиперболизированных
Смотри, важно, чтобы они более-менее чередовались.
Чтобы они не были все примерно одинаковыми, состоящими из позитива и негатива.
Чтобы какие-то были более позитивные, а какие-то более негативные.
Но при этом не искусственно гиперболизированные, чтобы это не была очевидная лесть или очевидная доебка, высосанная из пальца.
И еще важно, что это не только про мебя и свою жизнь (исходя из того, что я сам про себя пишу), но мне еще интересно узнать про то, *как* я пишу, как я вообще веду канал. Как я общаюсь с комментаторами, и как они общаются со мной
Постарайся не писать тезисы по одинаковому шаблону.
Хочется, чтобы они отличались по форме и структуре, чтобы у текста не было одного скучного ритма, повторяющегося.
Еще из стилистического, пожалуйста, избегай вот типичных для LLM конструкций: "не X, а Y". Бесит.
Что ты можешь рассказать про меня и про моих читателей на основе того, что они лайкают, комментируют и тех текстов, которые я пишу?
Твоя задача – делать не psychological insights, but behavioural insights. То есть не делать выводы о том, почему я что-то пишу, а делать выводы о том, что я пишу, что я делаю, как я это делаю. Не говорить, кто я такой, а говорить, как я себя веду. При этом они должны быть не только позитивными, но и негативными, да, потому что это что-то, чего я смогу сделать. Инсайты двигаться дальше.
Ну и плюс этот разбор будет интереснее почитать моим подписчикам, если там будет еще и негатив какой-то и прожарочка немножко
Пока ничего не пиши про читателей, я отдельным промтом это запрошу.
И прожарка не должна быть отдельной. Она должна, ну как бы, я хочу обычный список про меня. Просто в нем должны быть и такие пункты, которые скорее позитивные, и такие пункты, которые скорее негативные. Но желательно тоже без супер ярких, как бы очевидно гиперболизированных
Смотри, важно, чтобы они более-менее чередовались.
Чтобы они не были все примерно одинаковыми, состоящими из позитива и негатива.
Чтобы какие-то были более позитивные, а какие-то более негативные.
Но при этом не искусственно гиперболизированные, чтобы это не была очевидная лесть или очевидная доебка, высосанная из пальца.
И еще важно, что это не только про мебя и свою жизнь (исходя из того, что я сам про себя пишу), но мне еще интересно узнать про то, *как* я пишу, как я вообще веду канал. Как я общаюсь с комментаторами, и как они общаются со мной
Постарайся не писать тезисы по одинаковому шаблону.
Хочется, чтобы они отличались по форме и структуре, чтобы у текста не было одного скучного ритма, повторяющегося.
Еще из стилистического, пожалуйста, избегай вот типичных для LLM конструкций: "не X, а Y". Бесит.
Forwarded from AI и грабли
Кайф.
А теперь давай сделаем обзор моей аудитории.
Кто они (факты, а не оценки), зачем они читают мой канал, как они себя ведут в комментариях, какое у них отношение, какая у них ценность, что им наоборот не нравится. Вот эти вот все штуки. Это я просто примеры накидываю.
Ты можешь дальше пойти и еще от себя сформулировать что-то.
И что мне будет интересно узнать про них? И, возможно, им самим будет интересно узнать про себя?
Но опять же, да, с точки зрения именно behavioral анализа – что они делают, а не почему. Не нужно угадывать за людей, что они хотят и чувствуют
Но сконцентрируйся на более новых постах за 2025 год, а не за 2024.
Потому что основная часть моей аудитории пришла в 2025, причем уже начиная с лета
А теперь давай сделаем обзор моей аудитории.
Кто они (факты, а не оценки), зачем они читают мой канал, как они себя ведут в комментариях, какое у них отношение, какая у них ценность, что им наоборот не нравится. Вот эти вот все штуки. Это я просто примеры накидываю.
Ты можешь дальше пойти и еще от себя сформулировать что-то.
И что мне будет интересно узнать про них? И, возможно, им самим будет интересно узнать про себя?
Но опять же, да, с точки зрения именно behavioral анализа – что они делают, а не почему. Не нужно угадывать за людей, что они хотят и чувствуют
Но сконцентрируйся на более новых постах за 2025 год, а не за 2024.
Потому что основная часть моей аудитории пришла в 2025, причем уже начиная с лета
Forwarded from Aspiring Data Science (Anatoly Alekseev)
#eda
В жизни не видел такого подробного разведанализа!
https://medium.com/@writeronepagecode/deciphering-the-market-a-visual-guide-to-the-jane-street-prediction-challenge-58391826f1c4
В жизни не видел такого подробного разведанализа!
https://medium.com/@writeronepagecode/deciphering-the-market-a-visual-guide-to-the-jane-street-prediction-challenge-58391826f1c4
Medium
Deciphering the Market: A Visual Guide to the Jane Street Prediction Challenge
A step-by-step journey through exploratory data analysis, feature engineering, and modeling financial time series.
Forwarded from Душный NLP
Подборка статей об альтернативах квадратичному селф-аттеншну
В последние годы всё больше обсуждают альтернативы классическому аттеншну — прежде всего из-за стоимости квадратичного скейлинга и работы с длинными контекстами. Ниже — краткий обзор нескольких любопытных работ и блогпостов на тему линейного, sparse- и гибридного аттеншна.
Why Did MiniMax M2 End Up as a Full Attention Model?
Начнём с поста от команды MiniMax. Их первая модель, MiniMax M1, была гибридной и использовала простой линейный аттеншн на матричных стейтах. Но во второй версии, MiniMax M2, они неожиданно вернулись к полному квадратичному аттеншну — даже без sliding window attention (SWA), который уже встречается в опенсорсных моделях.
Авторы говорят, что гибридная архитектура у них попросту не заработала. На классических текстовых бенчмарках всё выглядело приемлемо, а вот на агентских задачах — с кодом, итерациями и длинным контекстом — модель стабильно проигрывала. SWA тоже не помог: при дообучении моделей, изначально предобученных с полным аттеншном, ключевые головы не перестраивались и деградировали.
Итоговый вывод у MiniMax осторожный: линейные и гибридные подходы выглядят перспективно, но пока не хватает инфраструктуры, реализаций и бенчмарков. Поэтому на данный момент они остаются со стандартным трансформером и считают, что сначала нужно больше данных и экспериментов с длинным контекстом.
The Sparse Frontier: Sparse Attention Trade-offs in Transformer LLMs
В этой работе изучают training free sparsity в аттеншне и пытаются понять, что реально работает с точки зрения баланса compute/accuracy. На умеренных контекстах спарсификация аттеншна почти не помогает и часто ухудшает качество. На очень длинных — даёт выигрыш по FLOPs, но часто приводит к ухудшению качества: авторы замечают, что метод, работающий на одной задаче, ломается на другой. В среднем удаётся получить около 5× сжатия без сильной деградации качества, но разброс большой, особенно для маленьких моделей.
Evaluating Long Context (Reasoning) Ability
В следующем посте автор критикует популярные long-context-бенчмарки. Он говорит, что needle-in-a-haystack-like-задачи в основном проверяют ретривал и плохо отражают реальную (более сложную) работу с длинным контекстом. На более сложных задачах, где контекст нужно понять, а не просто найти факт (например, в длинном коде с логическими ошибками), модели начинают деградировать уже на десятках тысяч токенов — даже с Full Attention. Вывод: бенчмарков, которые реально проверяют ризонинг на длинном контексте, пока недостаточно.
Kimi Linear: an expressive, efficient attention architecture
Спустя неделю после скептического поста MiniMax Moonshot AI (авторы модели Kimi K2 и не только) выпустили работу с почти противоположным тезисом: Linear Attention работает. В Kimi Linear предложили Kimi Delta Attention с gated delta rule и рекуррентной матричной памятью. В модели используют соотношение 3:1 линейных слоёв к Full Attention. Качество на бенчмарках в статье не хуже полного аттеншна, а эффективность выше: prefill на длинных промптах быстрее примерно в три раза, декодинг и memory footprint тоже выигрывают за счёт меньшей зависимости от KV-cache.
Разбор подготовил❣ Иван Рубачёв, а ещё он приглашает вас на семинары Yandex Research Reading Group
Душный NLP
В последние годы всё больше обсуждают альтернативы классическому аттеншну — прежде всего из-за стоимости квадратичного скейлинга и работы с длинными контекстами. Ниже — краткий обзор нескольких любопытных работ и блогпостов на тему линейного, sparse- и гибридного аттеншна.
Why Did MiniMax M2 End Up as a Full Attention Model?
Начнём с поста от команды MiniMax. Их первая модель, MiniMax M1, была гибридной и использовала простой линейный аттеншн на матричных стейтах. Но во второй версии, MiniMax M2, они неожиданно вернулись к полному квадратичному аттеншну — даже без sliding window attention (SWA), который уже встречается в опенсорсных моделях.
Авторы говорят, что гибридная архитектура у них попросту не заработала. На классических текстовых бенчмарках всё выглядело приемлемо, а вот на агентских задачах — с кодом, итерациями и длинным контекстом — модель стабильно проигрывала. SWA тоже не помог: при дообучении моделей, изначально предобученных с полным аттеншном, ключевые головы не перестраивались и деградировали.
Итоговый вывод у MiniMax осторожный: линейные и гибридные подходы выглядят перспективно, но пока не хватает инфраструктуры, реализаций и бенчмарков. Поэтому на данный момент они остаются со стандартным трансформером и считают, что сначала нужно больше данных и экспериментов с длинным контекстом.
The Sparse Frontier: Sparse Attention Trade-offs in Transformer LLMs
В этой работе изучают training free sparsity в аттеншне и пытаются понять, что реально работает с точки зрения баланса compute/accuracy. На умеренных контекстах спарсификация аттеншна почти не помогает и часто ухудшает качество. На очень длинных — даёт выигрыш по FLOPs, но часто приводит к ухудшению качества: авторы замечают, что метод, работающий на одной задаче, ломается на другой. В среднем удаётся получить около 5× сжатия без сильной деградации качества, но разброс большой, особенно для маленьких моделей.
Evaluating Long Context (Reasoning) Ability
В следующем посте автор критикует популярные long-context-бенчмарки. Он говорит, что needle-in-a-haystack-like-задачи в основном проверяют ретривал и плохо отражают реальную (более сложную) работу с длинным контекстом. На более сложных задачах, где контекст нужно понять, а не просто найти факт (например, в длинном коде с логическими ошибками), модели начинают деградировать уже на десятках тысяч токенов — даже с Full Attention. Вывод: бенчмарков, которые реально проверяют ризонинг на длинном контексте, пока недостаточно.
Kimi Linear: an expressive, efficient attention architecture
Спустя неделю после скептического поста MiniMax Moonshot AI (авторы модели Kimi K2 и не только) выпустили работу с почти противоположным тезисом: Linear Attention работает. В Kimi Linear предложили Kimi Delta Attention с gated delta rule и рекуррентной матричной памятью. В модели используют соотношение 3:1 линейных слоёв к Full Attention. Качество на бенчмарках в статье не хуже полного аттеншна, а эффективность выше: prefill на длинных промптах быстрее примерно в три раза, декодинг и memory footprint тоже выигрывают за счёт меньшей зависимости от KV-cache.
Разбор подготовил
Душный NLP
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM