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