Forwarded from Quant Researcher
🎬 Запись лекции для студентов Quant.Courses «Опционы: интуиция, данные и управленческие решения»
Про рынок, риск и то, как на опционы реально смотрят кванты и управляющие:
1. Интуиция рынка через опционы
• зачем вообще появились рынки опционов (исторический контекст 1970-х)
• как бизнес и финансовые институты используют деривативы для управления риском
• почему опционные рынки — это агрегированное мнение о будущем, а не “предсказание”
2. Implied volatility как цена риска
• чем IV принципиально отличается от “реальной” волатильности
• роль спроса/предложения, ликвидности, хедж-флоу и регуляторных ограничений
• почему IV — это всегда риск плюс структура рынка
3. Опционные данные и цепочки
• как читать опционные цепочки и волатильностные поверхности
• где на поверхности есть информация, а где — шум
• почему работа с данными и фильтрация важнее выбора формулы
4. Модели: где помогают, а где мешают
• Black–Scholes–Merton как язык, а не истина
• что на практике делают SSVI, RND, regime switching
• ограничения моделей и опасность “ложного арбитража”
5. Сигналы vs сделки
• почему хороший статистический сигнал не гарантирует PnL
• роль carry, ликвидности и маржи
• как управляющие принимают решения в условиях неопределённости
Запись и материалы
🎥 Запись лекции: https://youtu.be/BBLX4_7lb2Y
📒 Воркбук: https://colab.research.google.com/drive/1qZiPfyYxvI-wC0bEPFsSHImAWABkidwl
🔗 Ресурсы спикеров:
• Канал Лидии: https://t.iss.one/hunt4quant
• Канал Александра: https://t.iss.one/alexandinvestments
• Сайт Бориса: https://bbelyakov.com
Спасибо всем, кто был live и задавал вопросы.
Скоро выйдет подкаст, до связи!
Quant Researcher
Про рынок, риск и то, как на опционы реально смотрят кванты и управляющие:
1. Интуиция рынка через опционы
• зачем вообще появились рынки опционов (исторический контекст 1970-х)
• как бизнес и финансовые институты используют деривативы для управления риском
• почему опционные рынки — это агрегированное мнение о будущем, а не “предсказание”
2. Implied volatility как цена риска
• чем IV принципиально отличается от “реальной” волатильности
• роль спроса/предложения, ликвидности, хедж-флоу и регуляторных ограничений
• почему IV — это всегда риск плюс структура рынка
3. Опционные данные и цепочки
• как читать опционные цепочки и волатильностные поверхности
• где на поверхности есть информация, а где — шум
• почему работа с данными и фильтрация важнее выбора формулы
4. Модели: где помогают, а где мешают
• Black–Scholes–Merton как язык, а не истина
• что на практике делают SSVI, RND, regime switching
• ограничения моделей и опасность “ложного арбитража”
5. Сигналы vs сделки
• почему хороший статистический сигнал не гарантирует PnL
• роль carry, ликвидности и маржи
• как управляющие принимают решения в условиях неопределённости
Запись и материалы
🎥 Запись лекции: https://youtu.be/BBLX4_7lb2Y
📒 Воркбук: https://colab.research.google.com/drive/1qZiPfyYxvI-wC0bEPFsSHImAWABkidwl
🔗 Ресурсы спикеров:
• Канал Лидии: https://t.iss.one/hunt4quant
• Канал Александра: https://t.iss.one/alexandinvestments
• Сайт Бориса: https://bbelyakov.com
Спасибо всем, кто был live и задавал вопросы.
Скоро выйдет подкаст, до связи!
Quant Researcher
YouTube
Опционы: интуиция, данные и управленческие решения
Опционы — это язык ожиданий, страхов и решений.
За 90 минут обсудим:
• как читать рынок через опционы
• чем implied vol отличается от реального риска
• как кванты смотрят на опционные данные
• почему хороший сигнал ≠ хорошая сделка
• где модели помогают…
За 90 минут обсудим:
• как читать рынок через опционы
• чем implied vol отличается от реального риска
• как кванты смотрят на опционные данные
• почему хороший сигнал ≠ хорошая сделка
• где модели помогают…
Forwarded from DziS Science | Data Science
Привет всем!👋
Вот и подходит рабочий год к концу, кажется что можно подводить некоторые итоги работы.
Как вы знаете, подводить итоги я не очень люблю, поэтому в этом посте я бы наверное дал советы тем, кого не так давно кинули в котел тимлидства, которые были опробованы в бою.
Ведь основной мой итог, что моя команда не только выжила, но и даже начинает расцветать с новой силой. Об этом еще обязательно напишу.
Итак, начнем:
1️⃣ 🔤 Семь раз спроси и один раз сделай.
Работа с заказчиками одно из самых сложных в работе лида. Именно по этому перед стартом любого проекта надо обязательно запросить все, что хочет заказчик, но не браться выполнять это сразу, при этом указав минимально возможные сроки.
Возьмите время, визуализируйте таймлайн разработки проекта, разбив на понятные и простые задачи. По непонятным для вас (не знаете как делать/что невозможно сделать) предложите свое видение. Тут есть небольшой психологический ход, если вам не нравится задача, вам кажется она невыполнимой, можно попробовать явно указать плюсы и минусы этой задачи, увеличить срок задачи, мотивируя его "исследованием не пойми чего". Как результат ее можно преобразовать в что-то более выполнимое, либо деприотизировать, мотивируя это тем, что финансовый "выхлоп" задачи будет меньше, чем того, что делать легко и просто.
2️⃣ 🔤 Протокол - наше все.
Да, не ленитесь писать минутки, фиксируя все договоренности. Заказчики не любят, когда они что-то сказали, а вы это забыли. Дополнительно, протокол - ваш друг в спорных ситуациях, когда вы тратите кучу времени на какую-то дополнительную аналитику, эксперименты, которые не были включены в разработку ранее, а при ретро заказчик проекта говорит, что мы на это не договаривались/не помнит что это говорил (такие ситуации редки, но, как говорится, береженного бог бережет).
Также, как показала практика, очень хорошо протоколировать небольшой таймлайн вашего проекта, ведь это ваш ответ на вопрос "почему так долго/чем вы там занимаетесь?". Jira смотрят редко, все любят простые слайды с очевидной и простой подачей, но она поможет восстановить хронологию.
Надо понимать, что заказчик, нередко очень слабо подкован в технической составляющей проекта, поэтому данный таймлайн при использовании должен быть предельно простым: N дней был простой по причине <Причина>, ответственный <USERNAME>.
3️⃣ 🔤 Нет рук? Докажи что они нужны!
Так уж случается, если работа поставлена на конвейер, что приходят новые проекты, но в моменте людей больше не становится. Самый простой способ - построение прототипа с анонсом дальнейшей работы. Работает ровно также как и платная подписка на функционал приложения. Хочешь лучше - оплати сотрудника. В данном случае на помощь мне пришли стажировки, ведь они у меня практически безлимитные, так как не включены в штат и имеют плавающую принадлежность к подразделениям. Любой адекватный стажер может сделать простой MVP без вывода в прод, посчитать метрики и сделать первичную аналитику. Поэтому, тут отказываться от рук, если есть возможность их получить нельзя. Любые руки лучше, чем их отсутствие.
4️⃣ 🔤 Стажировки - круто.
Этот пункт вытекает из предыдущего. Нередко слышу, что на стажировке их заставляли делать <любая неадекватная и бесполезная хрень>. Для качественной стажировки необходимо так называемое win-win решение. Вы получаете руки, которые могут толкать проект в стадии прототипирования, стажер получает боевой опыт, который не стыдно записать в резюме.
продолжение ниже👇
#карьера #трудовые_будни
Вот и подходит рабочий год к концу, кажется что можно подводить некоторые итоги работы.
Как вы знаете, подводить итоги я не очень люблю, поэтому в этом посте я бы наверное дал советы тем, кого не так давно кинули в котел тимлидства, которые были опробованы в бою.
Ведь основной мой итог, что моя команда не только выжила, но и даже начинает расцветать с новой силой. Об этом еще обязательно напишу.
Итак, начнем:
Работа с заказчиками одно из самых сложных в работе лида. Именно по этому перед стартом любого проекта надо обязательно запросить все, что хочет заказчик, но не браться выполнять это сразу, при этом указав минимально возможные сроки.
Возьмите время, визуализируйте таймлайн разработки проекта, разбив на понятные и простые задачи. По непонятным для вас (не знаете как делать/что невозможно сделать) предложите свое видение. Тут есть небольшой психологический ход, если вам не нравится задача, вам кажется она невыполнимой, можно попробовать явно указать плюсы и минусы этой задачи, увеличить срок задачи, мотивируя его "исследованием не пойми чего". Как результат ее можно преобразовать в что-то более выполнимое, либо деприотизировать, мотивируя это тем, что финансовый "выхлоп" задачи будет меньше, чем того, что делать легко и просто.
Да, не ленитесь писать минутки, фиксируя все договоренности. Заказчики не любят, когда они что-то сказали, а вы это забыли. Дополнительно, протокол - ваш друг в спорных ситуациях, когда вы тратите кучу времени на какую-то дополнительную аналитику, эксперименты, которые не были включены в разработку ранее, а при ретро заказчик проекта говорит, что мы на это не договаривались/не помнит что это говорил (такие ситуации редки, но, как говорится, береженного бог бережет).
Также, как показала практика, очень хорошо протоколировать небольшой таймлайн вашего проекта, ведь это ваш ответ на вопрос "почему так долго/чем вы там занимаетесь?". Jira смотрят редко, все любят простые слайды с очевидной и простой подачей, но она поможет восстановить хронологию.
Надо понимать, что заказчик, нередко очень слабо подкован в технической составляющей проекта, поэтому данный таймлайн при использовании должен быть предельно простым: N дней был простой по причине <Причина>, ответственный <USERNAME>.
Так уж случается, если работа поставлена на конвейер, что приходят новые проекты, но в моменте людей больше не становится. Самый простой способ - построение прототипа с анонсом дальнейшей работы. Работает ровно также как и платная подписка на функционал приложения. Хочешь лучше - оплати сотрудника. В данном случае на помощь мне пришли стажировки, ведь они у меня практически безлимитные, так как не включены в штат и имеют плавающую принадлежность к подразделениям. Любой адекватный стажер может сделать простой MVP без вывода в прод, посчитать метрики и сделать первичную аналитику. Поэтому, тут отказываться от рук, если есть возможность их получить нельзя. Любые руки лучше, чем их отсутствие.
Этот пункт вытекает из предыдущего. Нередко слышу, что на стажировке их заставляли делать <любая неадекватная и бесполезная хрень>. Для качественной стажировки необходимо так называемое win-win решение. Вы получаете руки, которые могут толкать проект в стадии прототипирования, стажер получает боевой опыт, который не стыдно записать в резюме.
продолжение ниже👇
#карьера #трудовые_будни
Please open Telegram to view this post
VIEW IN TELEGRAM
Forwarded from DziS Science | Data Science
Да, обязательно 1 на 1 раз в месяц, если его нет бегите от этого
Технологический прорыв последних лет в плане помощи на собеседовании восхищает. Это ответная мера на неадекватные собеседования, где заставляют считать гессиан функции Лагранжа в точке. Лично я отказался от сложных задач. В терминах Leetcode - easy, но можно добавить 1 простой вопрос, который поднимет теоретический ответ. Задачи должны быть прикладные, ведь потом очень смешно смотреть на людей, которые на собеседовании "с допингом" решают это за минуту, а в работе на испытательном не могут тоже самое и за месяц написать. Никакая LLM приблуда вам в такой ситуации уже не поможет.
Фокус собеседования - проверка того, что написали в резюме, обязательно проверь что это правда. Это могут быть максимально глупые вопросы. Честно признаюсь, если человек пишет, что занимался чем-то специфичным, а потом не может ответить 2 фреймворка (из трех, кстати напишите в коментах ваше предположение, чем занимался челове), которые используются для этого, я такой опыт мысленно вычеркиваю.
Руководство - это про проблемы, а проблемы это стресс. Тут у меня самая сложная задача, ведь я часто пропускаю все через себя. Бороться с негативом помогает отличный совет: все хорошо, если ты уверен, что для решения проблемы ты сделал все от себя зависящее. Очевидно, что в большой компании не все зависит от тебя, поэтому делай свою часть хорошо и все будет здорово. С этим советом я пока только начинаю дружбу.
Делай то, за что тебя "уволят завтра". На все задачи тебя не хватит, ты не робот. Распределяй фокус в зависимости от близости дедлайна. Хочется, конечно, контролировать все, но иногда в ущерб этому стоит направлять фокус туда, где "горит". Это сложно, ведь ты осознанно зажигаешь пожар в задаче, которую ты деприоритизируешь из своего фокуса. Тут важно уметь быстро наверстать.
Надеюсь эти советы вы уже знали и применяли в своей работе.
Ставь 🔥, если используешь это в своей работе. Пиши в коментах свои советы, буду дополнять.
#карьера #трудовые_будни
Please open Telegram to view this post
VIEW IN TELEGRAM
Forwarded from Artem Ryblov’s Data Science Weekly
Machine Learning Q and AI. 30 Essential Questions and Answers on Machine Learning and AI by Sebastian Raschka
If you’re ready to venture beyond introductory concepts and dig deeper into machine learning, deep learning, and AI, the question-and-answer format of Machine Learning Q and AI will make things fast and easy for you, without a lot of mucking about.
Born out of questions often fielded by author Sebastian Raschka, the direct, no-nonsense approach of this book makes advanced topics more accessible and genuinely engaging. Each brief, self-contained chapter journeys through a fundamental question in AI, unraveling it with clear explanations, diagrams, and hands-on exercises.
WHAT'S INSIDE:
FOCUSED CHAPTERS: Key questions in AI are answered concisely, and complex ideas are broken down into easily digestible parts.
WIDE RANGE OF TOPICS: Raschka covers topics ranging from neural network architectures and model evaluation to computer vision and natural language processing.
PRACTICAL APPLICATIONS: Learn techniques for enhancing model performance, fine-tuning large models, and more.
You’ll also explore how to:
• Manage the various sources of randomness in neural network training
• Differentiate between encoder and decoder architectures in large language models
• Reduce overfitting through data and model modifications
• Construct confidence intervals for classifiers and optimize models with limited labeled data
• Choose between different multi-GPU training paradigms and different types of generative AI models
• Understand performance metrics for natural language processing
• Make sense of the inductive biases in vision transformers
If you’ve been on the hunt for the perfect resource to elevate your understanding of machine learning, Machine Learning Q and AI will make it easy for you to painlessly advance your knowledge beyond the basics.
Link: Site
Navigational hashtags: #armknowledgesharing #armbook
General hashtags: #ml #machinelearning #nlp #cv #dl #nn #neuralnetworks #deeplearning #computervision #naturallanguageprocessing
@data_science_weekly
If you’re ready to venture beyond introductory concepts and dig deeper into machine learning, deep learning, and AI, the question-and-answer format of Machine Learning Q and AI will make things fast and easy for you, without a lot of mucking about.
Born out of questions often fielded by author Sebastian Raschka, the direct, no-nonsense approach of this book makes advanced topics more accessible and genuinely engaging. Each brief, self-contained chapter journeys through a fundamental question in AI, unraveling it with clear explanations, diagrams, and hands-on exercises.
WHAT'S INSIDE:
FOCUSED CHAPTERS: Key questions in AI are answered concisely, and complex ideas are broken down into easily digestible parts.
WIDE RANGE OF TOPICS: Raschka covers topics ranging from neural network architectures and model evaluation to computer vision and natural language processing.
PRACTICAL APPLICATIONS: Learn techniques for enhancing model performance, fine-tuning large models, and more.
You’ll also explore how to:
• Manage the various sources of randomness in neural network training
• Differentiate between encoder and decoder architectures in large language models
• Reduce overfitting through data and model modifications
• Construct confidence intervals for classifiers and optimize models with limited labeled data
• Choose between different multi-GPU training paradigms and different types of generative AI models
• Understand performance metrics for natural language processing
• Make sense of the inductive biases in vision transformers
If you’ve been on the hunt for the perfect resource to elevate your understanding of machine learning, Machine Learning Q and AI will make it easy for you to painlessly advance your knowledge beyond the basics.
Link: Site
Navigational hashtags: #armknowledgesharing #armbook
General hashtags: #ml #machinelearning #nlp #cv #dl #nn #neuralnetworks #deeplearning #computervision #naturallanguageprocessing
@data_science_weekly
Forwarded from Artem Ryblov’s Data Science Weekly
PyTorch internals
Link: Site
Navigational hashtags: #armknowledgesharing #armtutorials
General hashtags: #dl #deeplearning #pytorch
@data_science_weekly
This talk is for those of you who have used PyTorch, and thought to yourself, "It would be great if I could contribute to PyTorch," but were scared by PyTorch's behemoth of a C++ codebase. I'm not going to lie: the PyTorch codebase can be a bit overwhelming at times. The purpose of this talk is to put a map in your hands: to tell you about the basic conceptual structure of a "tensor library that supports automatic differentiation", and give you some tools and tricks for finding your way around the codebase. I'm going to assume that you've written some PyTorch before, but haven't necessarily delved deeper into how a machine learning library is written.
The talk is in two parts: in the first part, I'm going to first introduce you to the conceptual universe of a tensor library. I'll start by talking about the tensor data type you know and love, and give a more detailed discussion about what exactly this data type provides, which will lead us to a better understanding of how it is actually implemented under the hood. If you're an advanced user of PyTorch, you'll be familiar with most of this material. We'll also talk about the trinity of "extension points", layout, device and dtype, which guide how we think about extensions to the tensor class. In the live talk at PyTorch NYC, I skipped the slides about autograd, but I'll talk a little bit about them in these notes as well.
The second part grapples with the actual nitty gritty details involved with actually coding in PyTorch. I'll tell you how to cut your way through swaths of autograd code, what code actually matters and what is legacy, and also all of the cool tools that PyTorch gives you for writing kernels.
Link: Site
Navigational hashtags: #armknowledgesharing #armtutorials
General hashtags: #dl #deeplearning #pytorch
@data_science_weekly
Forwarded from DevFM
How AI is transforming work at Anthropic
Ребята из Anthropic опубликовали исследование – как меняется работа инженеров внутри компании, которая сама делает Claude. И кажется, они прошлись по всем вопросам, которые сегодня беспокоят индустрию.
Вот, что меня заинтересовало.
Решаемые задачи и продуктивность
Это важный блок – особенно чтобы не выращивать ложные ожидания, будто агент будет выполнять всё под ключ.
– Инженеры используют Claude примерно в половине своей работы и оценивают прирост продуктивности до 50%
– Полностью отдать ему получается только до 20% задач – всё остальное выполняется с плотным контролем
– Треть работ, сделанных с Claude, просто не существовало бы без ИИ: nice-to-have тулзы, дополнительные дашборды
И вот здесь у меня возникает вопросик: если часть задач создаётся только потому, что теперь их дешево делать, не ломает ли это приоритизацию? Мы ускоряемся – но ускоряемся ли в нужную сторону?
Про важность делегирования
Когда начинаете работать с агентами, важно уметь давать ему шанс:
– начинать с маленьких и чётко проверяемых задач
– смотреть, с чем он справляется хорошо
– постепенно развивать навык понимать, какие задачи он делает хорошо, а какие лучше оставить себе
Антропик отдельно отмечают: многие негативные кейсы появляются не из-за тупости модели, а из-за неправильного выбора задачи.
На самом деле категорически согласен с этим пунктом.
Все становятся чуть более fullstack-чнее
Авторы пишут, что инженеры стали легче заходить в смежные зоны:
бэкендеры делают фронт, ресёрчеры собирают визуализации, секьюрити разбирают незнакомый код без лишней боли.
Порог входа в новые области сильно падает – можно набросать прототип, показать, отрефакторить и прогнать через Claude.
И важный эффект – меньше пинг-понга между командами: теперь можно не ждать коллег практически по каждому мелкому вопросу.
Что с навыками
– Инженеры отмечают страх потерять экспертизу: когда агент быстро прыгает к решению, ты меньше копаешься в доках и чужом коде – экспертиза формируется медленнее
– Парадокс: чтобы проверять агента, нужны именно те навыки, которые могут атрофироваться
– И вот здесь, как мне кажется, кроется большая проблема: непонятно, как теперь вырасти из джуна. У новичков исчезла часть естественных первых шагов, а спрос на настоящих сеньоров будет только расти. (Но не тех, кто в 25 считают себя сеньорами – извинити, вот такой я дед)
Коммуникации в командах
– 80–90% вопросов, которые раньше шли коллегам, теперь уходят сначала к Claude
– Это влияет на менторство: джуны меньше спрашивают, сеньоры реже передают экспертизу
В общем, очень рекомендую статью к прочтению.
И важно понимать: ребята прямо говорят, что это не истина в последней инстанции. Многое ещё требует прояснения. Да и в целом профессия меняется – и во что это выльется, пока не знает никто.
#ai
Ребята из Anthropic опубликовали исследование – как меняется работа инженеров внутри компании, которая сама делает Claude. И кажется, они прошлись по всем вопросам, которые сегодня беспокоят индустрию.
Вот, что меня заинтересовало.
Решаемые задачи и продуктивность
Это важный блок – особенно чтобы не выращивать ложные ожидания, будто агент будет выполнять всё под ключ.
– Инженеры используют Claude примерно в половине своей работы и оценивают прирост продуктивности до 50%
– Полностью отдать ему получается только до 20% задач – всё остальное выполняется с плотным контролем
– Треть работ, сделанных с Claude, просто не существовало бы без ИИ: nice-to-have тулзы, дополнительные дашборды
И вот здесь у меня возникает вопросик: если часть задач создаётся только потому, что теперь их дешево делать, не ломает ли это приоритизацию? Мы ускоряемся – но ускоряемся ли в нужную сторону?
Про важность делегирования
Когда начинаете работать с агентами, важно уметь давать ему шанс:
– начинать с маленьких и чётко проверяемых задач
– смотреть, с чем он справляется хорошо
– постепенно развивать навык понимать, какие задачи он делает хорошо, а какие лучше оставить себе
Антропик отдельно отмечают: многие негативные кейсы появляются не из-за тупости модели, а из-за неправильного выбора задачи.
На самом деле категорически согласен с этим пунктом.
Все становятся чуть более fullstack-чнее
Авторы пишут, что инженеры стали легче заходить в смежные зоны:
бэкендеры делают фронт, ресёрчеры собирают визуализации, секьюрити разбирают незнакомый код без лишней боли.
Порог входа в новые области сильно падает – можно набросать прототип, показать, отрефакторить и прогнать через Claude.
И важный эффект – меньше пинг-понга между командами: теперь можно не ждать коллег практически по каждому мелкому вопросу.
Что с навыками
– Инженеры отмечают страх потерять экспертизу: когда агент быстро прыгает к решению, ты меньше копаешься в доках и чужом коде – экспертиза формируется медленнее
– Парадокс: чтобы проверять агента, нужны именно те навыки, которые могут атрофироваться
– И вот здесь, как мне кажется, кроется большая проблема: непонятно, как теперь вырасти из джуна. У новичков исчезла часть естественных первых шагов, а спрос на настоящих сеньоров будет только расти. (Но не тех, кто в 25 считают себя сеньорами – извинити, вот такой я дед)
Коммуникации в командах
– 80–90% вопросов, которые раньше шли коллегам, теперь уходят сначала к Claude
– Это влияет на менторство: джуны меньше спрашивают, сеньоры реже передают экспертизу
В общем, очень рекомендую статью к прочтению.
И важно понимать: ребята прямо говорят, что это не истина в последней инстанции. Многое ещё требует прояснения. Да и в целом профессия меняется – и во что это выльется, пока не знает никто.
#ai
Forwarded from DevFM
Хотел написать небольшой пост – а в итоге получилась целая статья.
Недавно у меня был классный опыт парного программирования с товарищем: он пишет код, а я смотрю за его флоу и предлагаю оптимизации.
Собрал в статье практические советы, которые помогают при работе с агентами:
– как организовать удобный флоу
– почему не стоит просить «сделать всё под ключ» и как стоит
– как формировать рабочие rules
– зачем переключать модели и когда это спасает
– почему экспертиза разработчика всё ещё критично важна
Заходите почитать, если понравилась ставьте лайкосики.
#devfm
Недавно у меня был классный опыт парного программирования с товарищем: он пишет код, а я смотрю за его флоу и предлагаю оптимизации.
Собрал в статье практические советы, которые помогают при работе с агентами:
– как организовать удобный флоу
– почему не стоит просить «сделать всё под ключ» и как стоит
– как формировать рабочие rules
– зачем переключать модели и когда это спасает
– почему экспертиза разработчика всё ещё критично важна
Заходите почитать, если понравилась ставьте лайкосики.
#devfm
Хабр
Мой опыт разработки с агентами: советы
Недавно у меня была сессия парного программирования с хорошим товарищем. Получилась классная коллаборация: он пишет код, а я наблюдаю за его флоу и предлагаю оптимизации по части использования...
Forwarded from Свет из чёрного ящика
Подборка статей 2025 (часть 2)
Фундаментальные модели
- PinFM: Foundation Model for User Activity Sequences at a Billion-scale Visual Discovery Platform
- Large Foundation Model for Ads Recommendation
- Foundation Model for Personalized Recommendation
- Meta’s Generative Ads Model (GEM): The Central Brain Accelerating Ads Recommendation AI Innovation
- Realizing Scaling Laws in Recommender Systems: A Foundation–Expert Paradigm for Hyperscale Model Deployment
- External Large Foundation Model: How to Efficiently Serve Trillions of Parameters for Online Ads Recommendation
- Meta Lattice: Model Space Redesign for Cost-Effective Industry-Scale Ads Recommendations
Мультимодальность и Semantic Ids
- VL-CLIP: Enhancing Multimodal Recommendations via Visual Grounding and LLM-Augmented CLIP Embeddings
- Enhancing Embedding Representation Stability in Recommendation Systems with Semantic ID
- Progressive Semantic Residual Quantization for Multimodal-Joint Interest Modeling in Music Recommendation
- QARM: Quantitative Alignment Multi-Modal Recommendation at Kuaishou
- BiListing: Modality Alignment for listings
- DAS: Dual-Aligned Semantic IDs Empowered Industrial Recommender System
- Sparse Meets Dense: Unified Generative Recommendations with Cascaded Sparse-Dense Representations
- MOON Embedding: Multimodal Representation Learning for E-commerce Search Advertising
- MOON2.0: Dynamic Modality-balanced Multimodal Representation Learning for E-commerce Product Understanding
- LEMUR: Large scale End-to-end MUltimodal Recommendation
- STORE: Semantic Tokenization, Orthogonal Rotation and Efficient Attention for Scaling Up Ranking Models
- Multi-Aspect Cross-modal Quantization for Generative Recommendation
- Personalized Multi Modal Alignment Encoding for CTR-Recommendation in WeChat
- Generative Recommendation with Semantic IDs: A Practitioner’s Handbook
- CoFiRec: Coarse-to-Fine Tokenization for Generative Recommendation
- Generating Long Semantic IDs in Parallel for Recommendation
- A Simple Contrastive Framework Of Item Tokenization For Generative Recommendation
- Learnable Item Tokenization for Generative Recommendation
- SIDE: Semantic ID Embedding for effective learning from sequences
- ActionPiece: Contextually Tokenizing Action Sequences for Generative Recommendation
Фундаментальные модели
- PinFM: Foundation Model for User Activity Sequences at a Billion-scale Visual Discovery Platform
- Large Foundation Model for Ads Recommendation
- Foundation Model for Personalized Recommendation
- Meta’s Generative Ads Model (GEM): The Central Brain Accelerating Ads Recommendation AI Innovation
- Realizing Scaling Laws in Recommender Systems: A Foundation–Expert Paradigm for Hyperscale Model Deployment
- External Large Foundation Model: How to Efficiently Serve Trillions of Parameters for Online Ads Recommendation
- Meta Lattice: Model Space Redesign for Cost-Effective Industry-Scale Ads Recommendations
Мультимодальность и Semantic Ids
- VL-CLIP: Enhancing Multimodal Recommendations via Visual Grounding and LLM-Augmented CLIP Embeddings
- Enhancing Embedding Representation Stability in Recommendation Systems with Semantic ID
- Progressive Semantic Residual Quantization for Multimodal-Joint Interest Modeling in Music Recommendation
- QARM: Quantitative Alignment Multi-Modal Recommendation at Kuaishou
- BiListing: Modality Alignment for listings
- DAS: Dual-Aligned Semantic IDs Empowered Industrial Recommender System
- Sparse Meets Dense: Unified Generative Recommendations with Cascaded Sparse-Dense Representations
- MOON Embedding: Multimodal Representation Learning for E-commerce Search Advertising
- MOON2.0: Dynamic Modality-balanced Multimodal Representation Learning for E-commerce Product Understanding
- LEMUR: Large scale End-to-end MUltimodal Recommendation
- STORE: Semantic Tokenization, Orthogonal Rotation and Efficient Attention for Scaling Up Ranking Models
- Multi-Aspect Cross-modal Quantization for Generative Recommendation
- Personalized Multi Modal Alignment Encoding for CTR-Recommendation in WeChat
- Generative Recommendation with Semantic IDs: A Practitioner’s Handbook
- CoFiRec: Coarse-to-Fine Tokenization for Generative Recommendation
- Generating Long Semantic IDs in Parallel for Recommendation
- A Simple Contrastive Framework Of Item Tokenization For Generative Recommendation
- Learnable Item Tokenization for Generative Recommendation
- SIDE: Semantic ID Embedding for effective learning from sequences
- ActionPiece: Contextually Tokenizing Action Sequences for Generative Recommendation
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% времени – так и должно быть