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
Forwarded from Поступашки - ШАД, Стажировки и Магистратура
How to заботать android-разработку
Периодически можно услышать мнение, что нативная разработка сдаёт позиции, которые перехватывают flutter и real native. Но, во-первых, реальность такова, что для приложений с критическими требованиями к производительности и безопасности (например, в финтехе) нативная разработка - всё ещё мастхев. А, во-вторых, стоит упомянуть быстрое развитие технологии Kotlin Multiplatform, позволяющей разрабатывать фичи для обеих платформ, используя всё тот же котлин и фреймворк Jetpack Compose.
Итак, переходим к роадмапу:
Kotlin
Если вы уже знакомы с экосистемой JVM, то переход на котлин не займёт много времени. Разберитесь с null-safety, классами данных, обработкой исключений, синтаксическим сахаром вроде функций-расширений, в общем, теми концепциями языка, которые делают его удобным и современным. Вопросы на эти темы частенько встречаются на собеседованиях, в том числе в контексте различий между джавой и котлином.
Основы android
После котлина вам нужно разобраться, собственно, с самим андроидом и освоить среду разработки Android Studio, начав реализовывать простое приложение. На этом этапе важно понимание компонентов Activity и Fragment, которые позволяют управлять экранами приложений, и их жизненных циклов.
Далее учимся создавать интерфейс с помощью XML. Да, потом вы перейдёте на Compose, но знание XML-разметки необходимо из-за огромного количества legacy-проектов, которые всё ещё нуждаются в поддержке. Разберитесь с этапами отрисовки View и его жизненным циклом, уделите внимание компоненту RecyclerView, чтобы чётенько разложить интервьюеру, почему списки данных в андроиде так эффективны.
Здесь же автоматизируйте сборку с помощью Gradle.
Многопоточка
Многопоточность - важнейший аспект в мобильной разработке. На собесах этой теме уделяется особое внимание, поэтому здесь стоит потратить время на базу. Разберитесь с основными концепциями асинхронности и корутинами (suspend-функции, structured concurrency), которые позволяют её реализовывать. Иногда интервьюеры спрашивают об эволюции подходов к обеспечению асинхронности, поэтому нелишним будет немного погуглить.
Работа с сетью и хранение данных
Стандарт - библиотека Retrofit, которая преобразует api в kotlin-интерфейс.
Что касается хранения данных, то здесь два варианта: библиотека Room для SQLite и Jetpack DataStore (о Jetpack поговорим следующим пунктом), который пришёл на смену SharedPreferences (но о нём всё ещё спрашивают на собесах).
Jetpack Compose
После того, как вы вдоволь намучились с XML, самое время перейти к фреймворку Jetpack Compose, обновляющему интерфейс автоматически при изменении данных, и базово в нём освоиться (composable-функции, рекомпозиция, управление состоянием, модификаторы, макеты). Можете глянуть для начала этот краткий плейлист, а потом разобраться более основательно.
На работе, вероятнее всего, в какой-то момент вам придётся решать задачу на совместимость Compose и XML, так как большинство проектов проходят через gradual migration.
Архитектура
При проектировании общепринято соблюдение Clean Architecture подхода (хороший плейлист), суть которого в разделении приложения на слои и отделении бизнес-логики от логики интерфейса.
Вам нужно разобраться с ключевым паттерном MVVM, концептуально посмотрите MVP и MVI.
Затем научитесь внедрять зависимости через библиотеку Dagger Hilt (в качестве более простой, но менее популярной альтернативы применяется Koin) для реализации Dependency Injection.
Тестирование
И, конечно, вам нужно научиться покрывать код тестами:
Unit-тесты: JUnit и Mockito
UI-тесты: Espresso, UiAutomator, Kaspresso
видео от Яндекса для лучшего понимания.
Итак, пройдя эти пункты, вы заботаете базу, необходимую для любого android-разработчика.
Ставьте 🔥, если считаете, что мобильщиков несправедливо обделяют, и мы напишем гайд по созданию мощного пет-проекта для прохождения на стажировку мечты!!!
@postypashki_old
Периодически можно услышать мнение, что нативная разработка сдаёт позиции, которые перехватывают flutter и real native. Но, во-первых, реальность такова, что для приложений с критическими требованиями к производительности и безопасности (например, в финтехе) нативная разработка - всё ещё мастхев. А, во-вторых, стоит упомянуть быстрое развитие технологии Kotlin Multiplatform, позволяющей разрабатывать фичи для обеих платформ, используя всё тот же котлин и фреймворк Jetpack Compose.
Итак, переходим к роадмапу:
Kotlin
Если вы уже знакомы с экосистемой JVM, то переход на котлин не займёт много времени. Разберитесь с null-safety, классами данных, обработкой исключений, синтаксическим сахаром вроде функций-расширений, в общем, теми концепциями языка, которые делают его удобным и современным. Вопросы на эти темы частенько встречаются на собеседованиях, в том числе в контексте различий между джавой и котлином.
Основы android
После котлина вам нужно разобраться, собственно, с самим андроидом и освоить среду разработки Android Studio, начав реализовывать простое приложение. На этом этапе важно понимание компонентов Activity и Fragment, которые позволяют управлять экранами приложений, и их жизненных циклов.
Далее учимся создавать интерфейс с помощью XML. Да, потом вы перейдёте на Compose, но знание XML-разметки необходимо из-за огромного количества legacy-проектов, которые всё ещё нуждаются в поддержке. Разберитесь с этапами отрисовки View и его жизненным циклом, уделите внимание компоненту RecyclerView, чтобы чётенько разложить интервьюеру, почему списки данных в андроиде так эффективны.
Здесь же автоматизируйте сборку с помощью Gradle.
Многопоточка
Многопоточность - важнейший аспект в мобильной разработке. На собесах этой теме уделяется особое внимание, поэтому здесь стоит потратить время на базу. Разберитесь с основными концепциями асинхронности и корутинами (suspend-функции, structured concurrency), которые позволяют её реализовывать. Иногда интервьюеры спрашивают об эволюции подходов к обеспечению асинхронности, поэтому нелишним будет немного погуглить.
Работа с сетью и хранение данных
Стандарт - библиотека Retrofit, которая преобразует api в kotlin-интерфейс.
Что касается хранения данных, то здесь два варианта: библиотека Room для SQLite и Jetpack DataStore (о Jetpack поговорим следующим пунктом), который пришёл на смену SharedPreferences (но о нём всё ещё спрашивают на собесах).
Jetpack Compose
После того, как вы вдоволь намучились с XML, самое время перейти к фреймворку Jetpack Compose, обновляющему интерфейс автоматически при изменении данных, и базово в нём освоиться (composable-функции, рекомпозиция, управление состоянием, модификаторы, макеты). Можете глянуть для начала этот краткий плейлист, а потом разобраться более основательно.
На работе, вероятнее всего, в какой-то момент вам придётся решать задачу на совместимость Compose и XML, так как большинство проектов проходят через gradual migration.
Архитектура
При проектировании общепринято соблюдение Clean Architecture подхода (хороший плейлист), суть которого в разделении приложения на слои и отделении бизнес-логики от логики интерфейса.
Вам нужно разобраться с ключевым паттерном MVVM, концептуально посмотрите MVP и MVI.
Затем научитесь внедрять зависимости через библиотеку Dagger Hilt (в качестве более простой, но менее популярной альтернативы применяется Koin) для реализации Dependency Injection.
Тестирование
И, конечно, вам нужно научиться покрывать код тестами:
Unit-тесты: JUnit и Mockito
UI-тесты: Espresso, UiAutomator, Kaspresso
видео от Яндекса для лучшего понимания.
Итак, пройдя эти пункты, вы заботаете базу, необходимую для любого android-разработчика.
Ставьте 🔥, если считаете, что мобильщиков несправедливо обделяют, и мы напишем гайд по созданию мощного пет-проекта для прохождения на стажировку мечты!!!
@postypashki_old
Forwarded from DeepSchool
Ruff: современный и быстрый linter + formatter для Python
Правила оформления кода закреплены в стандартах: какие нужны отступы, длина строк и названия переменных. Они делают код разработчика понятным и единообразным. Правила бывают внутренними (для конкретного проекта) или общими. Например, в Python главный стандарт — PEP8.
Привести код в нужный формат, например, под PEP8 — задача, которая может занять много времени. Поэтому были разработаны вспомогательные инструменты — linters и formatters.
🔜 Linter выполняет статический анализ кода, проверяя его на соответствие заданным правилам, например, PEP8 или пользовательским.
🔜 Formatter автоматически преобразовывает внешний вид кода, не затрагивая его логику и приводя в соответствие заданному стилю оформлению.
Linter и formatter безопасно исправляют код, не меняя его поведения. Они упрощат жизнь разработчка и помогают избежать споров о форматировании и правильности именования классов во время ревью, экономя участникам время и нервы 🙂.
Разработчик вызовом одной команды автоматически форматирует код и находит конкретные участки, которые не соответствуют принятому стандарту, чтобы их поправить. А ревьювер не тратит силы на проверку форматирования, если в CI MR прошёл этапы linter и formatter, уделяя всё внимание на ревью реализации функционала.
Основной linter для python — flake8, а formatters — isort и black. Каждый из них имеет свою конфигурацию и команду запуска.
Использование нескольких инструментов вызывает ряд неудобств:
1. Отдельные файлы конфигураций замусоривают корень проекта и могут конфликтовать между собой.
2. Каждый инструмент — отдельная зависимость, которую надо установить. Кроме того, для flake8, как правило, необходимо доустанавливать отдельные плагины.
3. Каждый инструмент запускается отдельным процессом / задачей в CI и может работать относительно долго на больших кодовых базах.
Ruff помогает избавиться от них: он ставится одним python package, правила для форматирования и различных linters описываются в одном конфиге, а реализация на Rust делает его быстрее аналогов🚀.
Пример внедрения ruff в проект
В
В
Далее:
Автор: Иван Перминов
Правила оформления кода закреплены в стандартах: какие нужны отступы, длина строк и названия переменных. Они делают код разработчика понятным и единообразным. Правила бывают внутренними (для конкретного проекта) или общими. Например, в Python главный стандарт — PEP8.
Привести код в нужный формат, например, под PEP8 — задача, которая может занять много времени. Поэтому были разработаны вспомогательные инструменты — linters и formatters.
Linter и formatter безопасно исправляют код, не меняя его поведения. Они упрощат жизнь разработчка и помогают избежать споров о форматировании и правильности именования классов во время ревью, экономя участникам время и нервы 🙂.
Разработчик вызовом одной команды автоматически форматирует код и находит конкретные участки, которые не соответствуют принятому стандарту, чтобы их поправить. А ревьювер не тратит силы на проверку форматирования, если в CI MR прошёл этапы linter и formatter, уделяя всё внимание на ревью реализации функционала.
Основной linter для python — flake8, а formatters — isort и black. Каждый из них имеет свою конфигурацию и команду запуска.
Использование нескольких инструментов вызывает ряд неудобств:
1. Отдельные файлы конфигураций замусоривают корень проекта и могут конфликтовать между собой.
2. Каждый инструмент — отдельная зависимость, которую надо установить. Кроме того, для flake8, как правило, необходимо доустанавливать отдельные плагины.
3. Каждый инструмент запускается отдельным процессом / задачей в CI и может работать относительно долго на больших кодовых базах.
Ruff помогает избавиться от них: он ставится одним python package, правила для форматирования и различных linters описываются в одном конфиге, а реализация на Rust делает его быстрее аналогов🚀.
Пример внедрения ruff в проект
В
pyproject.toml добавляются следующие строки:[tool.ruff] # Общие настройки ruff
extend-exclude = ["*.ipynb"] # Исключаем Jupyter-ноутбуки из проверки
line-length = 120 # Лимит длины строки
lint.select = [ # Добавляем правила из списка https://docs.astral.sh/ruff/rules
"E", # pycodestyle
"F", # pyflakes
"I", # isort
]
lint.ignore = [
"F821", # Пример добавления игнорирования правил
]
[tool.ruff.format] # Отдельные настройки форматтера
quote-style = "double" # Перевод одинарных кавычек в двойные
indent-style = "space" # Перевод табов в пробелы
В
.pre-commit-config.yaml добавляются следующие строки:repos:
- repo: https://github.com/astral-sh/ruff-pre-commit
rev: v0.14.7
hooks:
- id: ruff
types_or: [ python, pyi, jupyter ]
- id: ruff-format
types_or: [ python, pyi, jupyter ]
args: [ "--check", "--diff" ]
Далее:
# Устанавливаем зависимости
pip install pre-commit ruff
# После настройки linter и formatter создаем hooks для commit/push
pre-commit install
# Использование
ruff check --fix # Запустит linter, подсветит ошибки и исправит некоторые ошибки
ruff format # Запустит formatter и отформатирует код
Автор: Иван Перминов
Про форматтеры, линтеры и другие инженерные практики, помогающие навести порядок в репозиториях DL-инженеров, рассказываем на курсе «Деплой DL-сервисов»⚡️
Please open Telegram to view this post
VIEW IN TELEGRAM