Forwarded from Quant Researcher
Что почитать на новогодних каникулах?
Подготовили список полезных книг и материалов для изучения в праздники.
Матчасть в финансах
1. Options, Futures, and Other Derivatives by John Hull
Библия деривативов. На многих трейдинг-десках её выдают всем, кто не проходил базовый курс по деривативам в университете.
2. Bond Markets, Analysis, and Strategies (10th Edition) by Frank J. Fabozzi
Библия облигаций, после которой весь мир Fixed Income станет для вас понятным.
3. Pricing and Trading Interest Rate Derivatives: A Practical Guide to Swaps by J Hamish M Darbyshire
Основательный гайд по свопам и деривативам на процентные ставки.
4. Expected Returns: An Investor's Guide to Harvesting Market Rewards by Antti Ilmanen
Фундаментальная книга про концепцию рыночных риск-премий.
Математика
5. Mathematical Modeling and Computation in Finance
«101» по математике в финансах.
6. Financial Mathematics, Derivatives and Structured Product
Поможет раз и навсегда разобраться с необходимой для прайсинга деривативов математикой.
Микроструктура рынка
7. Trades, Quotes and Prices: Financial Markets Under the Microscope by Jean-Philippe Bouchaud
Хардкорная книга от группы PhD об устройстве микроструктуры рынка.
8. Algorithmic and High-Frequency Trading by Álvaro Cartea
«101» по HFT и алгоритмической торговле.
Machine Learning in Finance
9. Advances in Financial Machine Learning by Marcos Lopez de Prado
Книга Маркоса Лопеса де Прадо о методах машинного обучения в финансах.
10. Machine Learning for Asset Managers by Marcos M. López de Prado
Вторая книга от де Прадо о машинном обучении применительно к управлению активами.
Авторы канала не могут начать 2025 год без рекомендации Лекций Ильинского. Эту базу стоит пересматривать регулярно!
Quant Researcher
Подготовили список полезных книг и материалов для изучения в праздники.
Матчасть в финансах
1. Options, Futures, and Other Derivatives by John Hull
Библия деривативов. На многих трейдинг-десках её выдают всем, кто не проходил базовый курс по деривативам в университете.
2. Bond Markets, Analysis, and Strategies (10th Edition) by Frank J. Fabozzi
Библия облигаций, после которой весь мир Fixed Income станет для вас понятным.
3. Pricing and Trading Interest Rate Derivatives: A Practical Guide to Swaps by J Hamish M Darbyshire
Основательный гайд по свопам и деривативам на процентные ставки.
4. Expected Returns: An Investor's Guide to Harvesting Market Rewards by Antti Ilmanen
Фундаментальная книга про концепцию рыночных риск-премий.
Математика
5. Mathematical Modeling and Computation in Finance
«101» по математике в финансах.
6. Financial Mathematics, Derivatives and Structured Product
Поможет раз и навсегда разобраться с необходимой для прайсинга деривативов математикой.
Микроструктура рынка
7. Trades, Quotes and Prices: Financial Markets Under the Microscope by Jean-Philippe Bouchaud
Хардкорная книга от группы PhD об устройстве микроструктуры рынка.
8. Algorithmic and High-Frequency Trading by Álvaro Cartea
«101» по HFT и алгоритмической торговле.
Machine Learning in Finance
9. Advances in Financial Machine Learning by Marcos Lopez de Prado
Книга Маркоса Лопеса де Прадо о методах машинного обучения в финансах.
10. Machine Learning for Asset Managers by Marcos M. López de Prado
Вторая книга от де Прадо о машинном обучении применительно к управлению активами.
Авторы канала не могут начать 2025 год без рекомендации Лекций Ильинского. Эту базу стоит пересматривать регулярно!
Quant Researcher
Forwarded from Quant Researcher
Understand Deep Learning: Free Online Book
Если вы хотите провести начало 2025 года за погружением в мир DL, то эта книга будет отличным началом.
Она распространяется бесплатно через сайт, на котором также выложены Jupyter-ноутбуки с кодом. Не придётся больше страдать, перепечатывая код из книги 2016 года на Python 2.0 или R.
Книга охватывает все необходимые темы: от функций потерь (Loss Functions) до трансформеров и Diffusion models.
На сайте также представлен список «Further Reading», который поможет углубиться в любую интересующую вас тему.
Нам бы такой ресурс в 2015-м!
Quant Researcher
Если вы хотите провести начало 2025 года за погружением в мир DL, то эта книга будет отличным началом.
Она распространяется бесплатно через сайт, на котором также выложены Jupyter-ноутбуки с кодом. Не придётся больше страдать, перепечатывая код из книги 2016 года на Python 2.0 или R.
Книга охватывает все необходимые темы: от функций потерь (Loss Functions) до трансформеров и Diffusion models.
На сайте также представлен список «Further Reading», который поможет углубиться в любую интересующую вас тему.
Нам бы такой ресурс в 2015-м!
Quant Researcher
Forwarded from Крис про аналитику🧠🦾
Чем отличается мидл+ от джуна? (часть 1)
Авторский взгляд, буду кратка.
Вижу 2 ключевые штуки.
Нет, это не бесконечное знание хардов. Это можно натренировать в тепличных условиях на курсиках и искусственных данных. Типа как протеиновый качок, которого натянули местные дрыщи в дворовых потасовках за гаражами😃 Потому что он не нюхал настоящего пороха. Жизнь его готовила к поднятию искусственных тяжестей, а не тому, что надо кулаками работать.
Штука 1: мидл+ имеет свою точку зрения по большинству вопросов, джун бежит сиюминутно выполнять любые указания продакта без их оценки на адекватность. Да и как ты оценишь, если опыта не имеешь? Даже если начнешь что-то вякать, скорее всего тебя задавят опытом и насмотренностью, если только по ту сторону не откровенную дичь несут.
😳 Когда я была джуном, мой продакт решил проверить "гениальную" гипотезу: что будет, если при заходе в приложение показывать на весь экран неперелистываемые нескрываемые сторизы на 30 секунд.
Задумка была благородная: если мы проинформируем людей о всех возможностях нашего сервиса, после подобного зомбирования они понесут свои денежки к нам в карман.
Реальность: метрики упали на 50%, потому что люди, видя 30-секундное безальтернативное нечто, закрывали приложение и не возвращались👍 😰
Когда ты на ежедневной основе работаешь с большими данными, начинаешь хотя бы ориентировочно понимать, что триггерит людей в хорошую и плохую сторону. Сейчас бы я такую задумку зарубила бы на корню. Если бы меня не послушали, эскалировала до лидов и хэдов, чтобы мы не тестировали откровенно вредительские гипотезы. Мне сейчас просто лень заниматья подобной фигней.
Подумайте, сколько сил было вложено огромным количеством людей: дизайнер нарисовал сторизы, разработчики из закодили на двух мобильных платформах, тестировщики проверили их на баги, App Store и Google Play проверили их на скам, аналитик сделал разметку, поставил ТЗ на разработку, выбирал метрики, выгружал данные, дизайнил АВ, заводил АВ тест, считал АВ тест руками... - чтобы получить колоссальную просадку в результатах😭
Когда работаешь над продуктом, надо иметь хотя бы зачатки эмпатии, чтобы предсказывать поведение пользователей. И проводить минимальные кастдевы.
Джун скорее всего не погружен в типовые продуктовые процессы, не имеет реальной насмотренности и своего мнения. Опытный продакт таким будет вертеть и крутить по своему усмотрению.
Если ты сам обладаешь багажом опыта за плечами, тебе легче протолкнуть разные идеи. На каких сегментах что тестировать, что смотреть в рисерче и тд.
😳 Еще забавный пример: проходила продуктовое собеседование в Skyeng. Тимлид рассказал об их реальной фиче и попросил задизайнить АВ тест. Я обычными логичными рассуждениями вслух за 10 секунд вышла на тот сегмент пользователей, на которых надо было ее тестировать.
В реальности в компании этот путь занял 2 итерации теста🤷♀️ В первой итерации тестировали на всех и получили ожидаемую просадку метрик на "не том" большом сегменте. Как в простом советском анекдоте: "дорвались до прода джун-продакт и джун-аналитик..."
А могли бы нанять меня, мы бы столько времени на тестировании бесполезных гипотез сэкономили...
если нужна вторая часть, втопите лайков, огонечков и другой обратной связи👇🔥🙂
Авторский взгляд, буду кратка.
Вижу 2 ключевые штуки.
Нет, это не бесконечное знание хардов. Это можно натренировать в тепличных условиях на курсиках и искусственных данных. Типа как протеиновый качок, которого натянули местные дрыщи в дворовых потасовках за гаражами
Штука 1: мидл+ имеет свою точку зрения по большинству вопросов, джун бежит сиюминутно выполнять любые указания продакта без их оценки на адекватность. Да и как ты оценишь, если опыта не имеешь? Даже если начнешь что-то вякать, скорее всего тебя задавят опытом и насмотренностью, если только по ту сторону не откровенную дичь несут.
Задумка была благородная: если мы проинформируем людей о всех возможностях нашего сервиса, после подобного зомбирования они понесут свои денежки к нам в карман.
Реальность: метрики упали на 50%, потому что люди, видя 30-секундное безальтернативное нечто, закрывали приложение и не возвращались
Когда ты на ежедневной основе работаешь с большими данными, начинаешь хотя бы ориентировочно понимать, что триггерит людей в хорошую и плохую сторону. Сейчас бы я такую задумку зарубила бы на корню. Если бы меня не послушали, эскалировала до лидов и хэдов, чтобы мы не тестировали откровенно вредительские гипотезы. Мне сейчас просто лень заниматья подобной фигней.
Подумайте, сколько сил было вложено огромным количеством людей: дизайнер нарисовал сторизы, разработчики из закодили на двух мобильных платформах, тестировщики проверили их на баги, App Store и Google Play проверили их на скам, аналитик сделал разметку, поставил ТЗ на разработку, выбирал метрики, выгружал данные, дизайнил АВ, заводил АВ тест, считал АВ тест руками... - чтобы получить колоссальную просадку в результатах
Когда работаешь над продуктом, надо иметь хотя бы зачатки эмпатии, чтобы предсказывать поведение пользователей. И проводить минимальные кастдевы.
Джун скорее всего не погружен в типовые продуктовые процессы, не имеет реальной насмотренности и своего мнения. Опытный продакт таким будет вертеть и крутить по своему усмотрению.
Если ты сам обладаешь багажом опыта за плечами, тебе легче протолкнуть разные идеи. На каких сегментах что тестировать, что смотреть в рисерче и тд.
В реальности в компании этот путь занял 2 итерации теста🤷♀️ В первой итерации тестировали на всех и получили ожидаемую просадку метрик на "не том" большом сегменте. Как в простом советском анекдоте: "дорвались до прода джун-продакт и джун-аналитик..."
А могли бы нанять меня, мы бы столько времени на тестировании бесполезных гипотез сэкономили...
если нужна вторая часть, втопите лайков, огонечков и другой обратной связи👇🔥
Please open Telegram to view this post
VIEW IN TELEGRAM
Forwarded from Крис про аналитику🧠🦾
Чем отличается мидл+ от джуна? (часть 2)
сначала прочитай часть 1
Штука 2: мидл+ скорее всего видел в своей карьере ооооооооочень много дерьма.
🆘Ломающиеся каждый релиз данные,
🆎поломанные АВ тесты: без равномерного сплитования, без контрольной группы (я ахуела, когда мой разраб накодил тест только для тестовой группы, жизнь меня тогда к такому не готовила), без разметки, которые останавливаются третьими людьми, -
🆘падающие базы данных, по ошибке сделанная drop schema, падающие даги, задвоенные/отсутствующие местами данные, ситуации, когда сегодня ты посчитал конверсию 5%, а завтра 25%, сидишь нихуя не понимая, где ошибся,
🆘ситуации, когда тебя клюют заказчики каждый час, когда вводные от них меняются каждые 5 минут, когда надо выгрузить срочно-срочно оооооочень красивые данные, иначе побойся бога, сохрани здоровье топ-менеджеров...
После этого афгана у любого мало-мальски наблюдательного человека начинает формироваться свое мнение и стальная задница. Да, в некоторых вопросах оно мнение может быть твердым, в некоторых колебаться.
НО! в любой возможной ситуации опытный специалист будет вести диалог с заказчиком на равных. Не как калькулятор на побегушках, а как человек со своим мнением, которое скорее всего более обоснованное, потому что с данными напрямую работает именно аналитик.
Там, где будет нужно подкорректировать взгляд продакта, увести его руку от принятия дичь-решений, где можно подать данные под более выгодным углом, где можно выбрать более интересные метрики или провести АВ тест как-то иначе - мидл+ обязательно это озвучит.
Особенно если можно вырулить задачу так, чтобы вообще ее не делать. Ведь стальная задница, наученная опытом, понимает, что существует мало действительно горящих и критических задач. Зачастую для решения проблемы надо просто дать ей настояться.
Да, такое бывает, чем больше опыта, тем меньше осознанных целенаправленных телодвижений человек совершает.
Особенно если речь про большие и сложные сервисы.
Опытный постарается иметь максимально широкий контекст, быть в курсе, что делают на соседних направлениях.
Зачем?
1️⃣ очень интересно наблюдать синергию и внутреннюю конкуренцию разных направлений за рост метрик. Вы вырастили конверсию и хлопаете в ладоши от предвкушения премии? Вот только пидары из соседней команды раскатили фичу, которая сканнибализировала весь ваш трафик, поздравляю, но премия в другой раз😭
2️⃣ чем больше вы знаете о результатах работы коллег-аналитиков, тем меньше вам самим надо работать. Задачи часто пересекаются, может оказаться, что ваш коллега уже собрал нужную витрину, дашборд или вообще даже нужные метрики уже выгружал.
Больше контекста - больше понимания логики принятия решений наверху - больше власти, как на эти рычаги давить. Даже если речь про ваш мидловский микромасштаб. Надо же с чего-то начинать.
Джун же побежит сверкая пятками быстрее-быстрее делать. Либо побежит спрашивать лида/ментора, что уже в целом неплохой вариант. Главное - включать во время работы голову и думать, кто что делает и к чему это приводит. Собирать большое количество наблюдений и делать из них выводы.
В интернетах популярны тесты на психологический возраст. Поэтому по аналогии спрошу:
а у вас какой психологический грейд?🤡
сначала прочитай часть 1
Штука 2: мидл+ скорее всего видел в своей карьере ооооооооочень много дерьма.
🆘Ломающиеся каждый релиз данные,
🆎поломанные АВ тесты: без равномерного сплитования, без контрольной группы (я ахуела, когда мой разраб накодил тест только для тестовой группы, жизнь меня тогда к такому не готовила), без разметки, которые останавливаются третьими людьми, -
🆘падающие базы данных, по ошибке сделанная drop schema, падающие даги, задвоенные/отсутствующие местами данные, ситуации, когда сегодня ты посчитал конверсию 5%, а завтра 25%, сидишь нихуя не понимая, где ошибся,
🆘ситуации, когда тебя клюют заказчики каждый час, когда вводные от них меняются каждые 5 минут, когда надо выгрузить срочно-срочно оооооочень красивые данные, иначе побойся бога, сохрани здоровье топ-менеджеров...
После этого афгана у любого мало-мальски наблюдательного человека начинает формироваться свое мнение и стальная задница. Да, в некоторых вопросах оно мнение может быть твердым, в некоторых колебаться.
НО! в любой возможной ситуации опытный специалист будет вести диалог с заказчиком на равных. Не как калькулятор на побегушках, а как человек со своим мнением, которое скорее всего более обоснованное, потому что с данными напрямую работает именно аналитик.
Там, где будет нужно подкорректировать взгляд продакта, увести его руку от принятия дичь-решений, где можно подать данные под более выгодным углом, где можно выбрать более интересные метрики или провести АВ тест как-то иначе - мидл+ обязательно это озвучит.
Особенно если можно вырулить задачу так, чтобы вообще ее не делать. Ведь стальная задница, наученная опытом, понимает, что существует мало действительно горящих и критических задач. Зачастую для решения проблемы надо просто дать ей настояться.
Да, такое бывает, чем больше опыта, тем меньше осознанных целенаправленных телодвижений человек совершает.
Особенно если речь про большие и сложные сервисы.
Опытный постарается иметь максимально широкий контекст, быть в курсе, что делают на соседних направлениях.
Зачем?
Больше контекста - больше понимания логики принятия решений наверху - больше власти, как на эти рычаги давить. Даже если речь про ваш мидловский микромасштаб. Надо же с чего-то начинать.
Джун же побежит сверкая пятками быстрее-быстрее делать. Либо побежит спрашивать лида/ментора, что уже в целом неплохой вариант. Главное - включать во время работы голову и думать, кто что делает и к чему это приводит. Собирать большое количество наблюдений и делать из них выводы.
В интернетах популярны тесты на психологический возраст. Поэтому по аналогии спрошу:
а у вас какой психологический грейд?
Please open Telegram to view this post
VIEW IN TELEGRAM
Forwarded from Сенаторов.head()
AB-тесты: наблюдаемый эффект и MDE
"А как такое может быть?" — спрашивает продакт, когда мы, подводя итоги AB-теста, получили статзначимый аплифт в 0.8%, когда во время дизайна закладывали MDE = 1%.
И такая реакция абсолютно логична из нейминга минимальный детектируемый эффект (MDE). Но все же такое название создает путаницу. А дело вот в чем.
Нужно разделить три понятия:
▶️ Реальный эффект - это тот реальный эффект от нашей фичи, который мы не знаем и который хотим оценить
▶️ MDE - это наше предположение о реальном эффекте, который мы сможем задетектить с заданным размером выборки и с заданной вероятностью. Эта вероятность, она же мощность, как правило фиксируется на 80%.
▶️ Наблюдаемый эффект - этот тот эффект, который мы уже своими глазами видим между тестовой и контрольной группой по завершении теста. Наблюдаемый эффект не равняется реальному эффект хотя бы в силу того, что в данных всегда имеется шум, который будет толкать наш наблюдаемый эффект либо в плюс, либо в минус от реального.
Из этого уже следует, что не надо сравнивать MDE и наблюдаемый эффект, потому что это как сравнивать теплое с мягким.
Мы можем в наблюдаемом эффекте получить и меньшее значение, чем в MDE и этот эффект может быть статзначимым. Такое происходит нередко. Как в нашем примере с наблюдаемым статзначимым эффектом в 0.8%, а MDE = 1%. Финальное слово здесь за наблюдаемым эффектом.
А откуда могла взяться разница между ними? Здесь много вариантов. Возможно, реальный эффект на самом деле ниже, чем вы закладывали в MDE. Возможно, реальный эффект на самом деле равен MDE, но из-за флуктуации в данных, наш наблюдаемый эффект оказался ниже. Все равно важно помнить, что MDE — это про дизайн теста, а наблюдаемый эффект — про результаты теста.
Если хотите почитать подробнее и посмотреть на симуляции с графичками, то можете глянуть вот эти статьи)
📌 What if the Observed Effect is Smaller Than the MDE?
📌 Как же мощно я провел А/В-тест, или почему не стоит сравнивать наблюдаемый аплифт с MDE
"А как такое может быть?" — спрашивает продакт, когда мы, подводя итоги AB-теста, получили статзначимый аплифт в 0.8%, когда во время дизайна закладывали MDE = 1%.
И такая реакция абсолютно логична из нейминга минимальный детектируемый эффект (MDE). Но все же такое название создает путаницу. А дело вот в чем.
Нужно разделить три понятия:
Из этого уже следует, что не надо сравнивать MDE и наблюдаемый эффект, потому что это как сравнивать теплое с мягким.
Мы можем в наблюдаемом эффекте получить и меньшее значение, чем в MDE и этот эффект может быть статзначимым. Такое происходит нередко. Как в нашем примере с наблюдаемым статзначимым эффектом в 0.8%, а MDE = 1%. Финальное слово здесь за наблюдаемым эффектом.
А откуда могла взяться разница между ними? Здесь много вариантов. Возможно, реальный эффект на самом деле ниже, чем вы закладывали в MDE. Возможно, реальный эффект на самом деле равен MDE, но из-за флуктуации в данных, наш наблюдаемый эффект оказался ниже. Все равно важно помнить, что MDE — это про дизайн теста, а наблюдаемый эффект — про результаты теста.
Если хотите почитать подробнее и посмотреть на симуляции с графичками, то можете глянуть вот эти статьи)
Please open Telegram to view this post
VIEW IN TELEGRAM
Forwarded from Николай Хитров | Блог
Technology Radar 2024
Год потихоньку подходит к концу. Пришло время посмотреть, какие технологии появились, какие устаканились и какие ушли на второй план.
Довольно много
1% canary
Component testing
Domain storytelling
Bruno
K9s
Devbox
pgvector
Unleash
GitButler
JetBrains AI Assistant
Mise
ReadySet
uv
Zed
Pingora
PGLite
https://www.thoughtworks.com/radar
Год потихоньку подходит к концу. Пришло время посмотреть, какие технологии появились, какие устаканились и какие ушли на второй план.
Довольно много
LLM и разных ML штук. Но поскольку я в них не шарю, вот список того, что отметил на свой вкус:1% canary
Component testing
Domain storytelling
Bruno
K9s
Devbox
pgvector
Unleash
GitButler
JetBrains AI Assistant
Mise
ReadySet
uv
Zed
Pingora
PGLite
https://www.thoughtworks.com/radar
Thoughtworks
Technology Radar | Guide to technology landscape
The Technology Radar is an opinionated guide to today's technology landscape. Read the latest here.
Forwarded from LLM под капотом
Anthropic Sonnet 3.5 1022 - это очень классная модель
(1) Она поддерживает хорошо работу с PDF
(2) У этой модели есть кэширование промптов
(3) делать structured data extraction с checklist и custom chain of thought на ней одно удовольствие.
Хотя Anthropic пока и не завел structured outputs на базе constrained decoding (как это сделали в OpenAI), но их модели понимают JSON схему без каких-то нареканий. А выход у них пока без ошибок (если не перегружать контекст и соблюдать signal-noise ratio).
Что я делаю для извлечения данных из сложных PDF недорого:
(1) загружаю системный промпт со схемой в первое сообщение. Помечаю для кэширования через
(2) загружаю PDF напрямую во второе сообщение модели. Также помечаю для кэширования.
У меня PDF достается из CAS, но можно грузить хоть откуда. Главное - сконвертировать бинарную начинку в base64 для добавления в API запрос (так сделана работа с документами в бете):
Кстати, под капотом Anthropic не просто распарсит PDF в текст, но и приложит картинки страниц к этому тексту. Это заметно повышает качество ответов.
(3) помещаю задачу из чеклиста в третье сообщение, уже не кэширую.
(4) в последнее сообщение добавляю
(5) к ответу модели добавляю
И потом все будет работать так:
Причем
Такой процесс в итоге работает точнее и проще, чем комбайн из openAI GPT-4o со structured outputs и предобработкой PDF в отдельных специализированных моделях.
Ваш, @llm_under_hood 🤗
PS: Бенчмарк модели будет попозже
(1) Она поддерживает хорошо работу с PDF
(2) У этой модели есть кэширование промптов
(3) делать structured data extraction с checklist и custom chain of thought на ней одно удовольствие.
Хотя Anthropic пока и не завел structured outputs на базе constrained decoding (как это сделали в OpenAI), но их модели понимают JSON схему без каких-то нареканий. А выход у них пока без ошибок (если не перегружать контекст и соблюдать signal-noise ratio).
Что я делаю для извлечения данных из сложных PDF недорого:
(1) загружаю системный промпт со схемой в первое сообщение. Помечаю для кэширования через
"cache_control": {"type": "ephemeral"},. Схему конвертирую в строку (см ниже) и добавляю к общему описанию задачи:
json.dumps(Model.model_json_schema(), indent=2, ensure_ascii=False)
(2) загружаю PDF напрямую во второе сообщение модели. Также помечаю для кэширования.
У меня PDF достается из CAS, но можно грузить хоть откуда. Главное - сконвертировать бинарную начинку в base64 для добавления в API запрос (так сделана работа с документами в бете):
def read_pdf_as_base64(env: Env, hash: str):
with env.storage.read_cas(hash) as file:
return base64.standard_b64encode(file.read()).decode('utf-8')
Кстати, под капотом Anthropic не просто распарсит PDF в текст, но и приложит картинки страниц к этому тексту. Это заметно повышает качество ответов.
(3) помещаю задачу из чеклиста в третье сообщение, уже не кэширую.
(4) в последнее сообщение добавляю
{
"role": "assistant",
"content": "Here is the JSON requested:\n{"
}
(5) к ответу модели добавляю
{ и валидирую загрузкой в исходную pydantic modelИ потом все будет работать так:
results = []
for pdf in pdfs:
for question in checklist:
result = extract_data(schema, pdf, question)
results.append(result)
Причем
schema кэшируется на все запросы, а содержимое pdf (самое большое) переиспользуется на все вопросы из чеклиста.Такой процесс в итоге работает точнее и проще, чем комбайн из openAI GPT-4o со structured outputs и предобработкой PDF в отдельных специализированных моделях.
Ваш, @llm_under_hood 🤗
PS: Бенчмарк модели будет попозже
Forwarded from Советы разработчикам (python и не только)
Паттерны работы с базами данных
В большинстве проектов мы храним какие-то данные. Для этого используются разные виды баз данных: реляционные, nosql или даже специализированные HTTP API. Такие хранилища имеют специфическое API, которое мы обычно хотим скрыть от основного кода за некоторой абстракцией. Вот стандартные варианты, описанные, в частности, Мартином Фаулером.
Первая группа паттернов работы с БД - отделяющие реализацию операций с хранилищем от данных. Благодаря такому разделению, мы можем построить несколько реализаций шлюза, возвращающих однотипные структуры (например, для заглушек на время тестирования или использования нескольких источников данных). Обратите внимание, что в паттернах этой группы мы можем полностью скрыть детали организации хранилища.
DAO - наиболее простой вариант, он представляет собой достаточно тупой класс, который просто выполняет операции с хранилищем и возвращает данные в том или ином виде. Он не должен содержать какого-то своего состояния (будь то кэши или IdentityMap). Он получает и возвращает только данные в виде неких абстрактных RecordSet или простых DTO, то есть структур, не содержащих логики. Плюсы такого паттерна: простота реализации, возможность точечного тюнинга запросов. Паттерн описан в "Core J2EE Patterns", а у Фаулера встречается очень близкое описание под именем Table Data Gateway.
Data Mapper - в отличие от DAO занимается не просто передачей данных, а двусторонней синхронизацией моделей бизнес логики с хранилищем. То есть он может получать какие-то сущности и потом сохранять их обратно. Внутри он может содержать IdentityMap для исключения дублей модели с одним identity или создания лишних запросов на загрузку. Каждый маппер работает с моделью определенного типа, но в случае составных моделей он иногда может обращаться к другим мапперам (например, при использовании
Repository - фактически вариант Data Mapper, предназначенный для работы с корневыми сущностями. Для прикладной бизнес логики репозиторий выглядит как коллекция, содержащая корни агрегатов. Он может использоваться для получения полиморфных моделей, а также может возвращать некоторую сводно-статистическую информацию (например, количество элементов или сумму полей) или даже выполнять какие-то расчеты, не выходящие за пределы общей компетенции хранилища данных. Это основной паттерн при использовании богатых доменных моделей. Паттерн описан у Эрика Эванса, а у Фаулера встречаются некоторые варианты его реализации.
Вторая группа - паттерны, смешивающие данные и работу с хранилищем. Их использование может усложнить тестирование или изменение кода, но, тем не менее, они используются.
Raw Data Gateway - предлагает каждой строке таблицы поставить в соответствие экземпляр класса. Мы получаем отдельный класс Finder для загрузки строк и собственно класс шлюза строки, который предоставляет доступ к загруженным данным и обладает методами сохранения себя в БД.
Active Record - вариант RDG, но содержащий бизнес логику. По факту, мы имеем богатые доменные модели не абстрагированные от хранилища. Часто методы загрузки данных реализованы просто как static-методы в этом же классе вместо выделения отдельного Finder.
Строит отметить, что многие ORM в Python реализуют Active Record и активно используют при этом неявный контроль соединений и транзакций. В отличие от них SQLAlchemy реализует паттерн Data Mapper и может дать больший уровень абстракции над хранилищем (обратите внимание на подход с
Дополнительные материалы:
• http://www.corej2eepatterns.com/Patterns2ndEd/DataAccessObject.htm
• https://martinfowler.com/eaaCatalog/identityMap.html
• https://docs.sqlalchemy.org/en/20/orm/dataclasses.html#applying-orm-mappings-to-an-existing-dataclass-legacy-dataclass-use
В большинстве проектов мы храним какие-то данные. Для этого используются разные виды баз данных: реляционные, nosql или даже специализированные HTTP API. Такие хранилища имеют специфическое API, которое мы обычно хотим скрыть от основного кода за некоторой абстракцией. Вот стандартные варианты, описанные, в частности, Мартином Фаулером.
Первая группа паттернов работы с БД - отделяющие реализацию операций с хранилищем от данных. Благодаря такому разделению, мы можем построить несколько реализаций шлюза, возвращающих однотипные структуры (например, для заглушек на время тестирования или использования нескольких источников данных). Обратите внимание, что в паттернах этой группы мы можем полностью скрыть детали организации хранилища.
DAO - наиболее простой вариант, он представляет собой достаточно тупой класс, который просто выполняет операции с хранилищем и возвращает данные в том или ином виде. Он не должен содержать какого-то своего состояния (будь то кэши или IdentityMap). Он получает и возвращает только данные в виде неких абстрактных RecordSet или простых DTO, то есть структур, не содержащих логики. Плюсы такого паттерна: простота реализации, возможность точечного тюнинга запросов. Паттерн описан в "Core J2EE Patterns", а у Фаулера встречается очень близкое описание под именем Table Data Gateway.
Data Mapper - в отличие от DAO занимается не просто передачей данных, а двусторонней синхронизацией моделей бизнес логики с хранилищем. То есть он может получать какие-то сущности и потом сохранять их обратно. Внутри он может содержать IdentityMap для исключения дублей модели с одним identity или создания лишних запросов на загрузку. Каждый маппер работает с моделью определенного типа, но в случае составных моделей он иногда может обращаться к другим мапперам (например, при использовании
select-in load). При использовании Unit Of Work, тот обращается именно к мапперу для сохранения данных.Repository - фактически вариант Data Mapper, предназначенный для работы с корневыми сущностями. Для прикладной бизнес логики репозиторий выглядит как коллекция, содержащая корни агрегатов. Он может использоваться для получения полиморфных моделей, а также может возвращать некоторую сводно-статистическую информацию (например, количество элементов или сумму полей) или даже выполнять какие-то расчеты, не выходящие за пределы общей компетенции хранилища данных. Это основной паттерн при использовании богатых доменных моделей. Паттерн описан у Эрика Эванса, а у Фаулера встречаются некоторые варианты его реализации.
Вторая группа - паттерны, смешивающие данные и работу с хранилищем. Их использование может усложнить тестирование или изменение кода, но, тем не менее, они используются.
Raw Data Gateway - предлагает каждой строке таблицы поставить в соответствие экземпляр класса. Мы получаем отдельный класс Finder для загрузки строк и собственно класс шлюза строки, который предоставляет доступ к загруженным данным и обладает методами сохранения себя в БД.
Active Record - вариант RDG, но содержащий бизнес логику. По факту, мы имеем богатые доменные модели не абстрагированные от хранилища. Часто методы загрузки данных реализованы просто как static-методы в этом же классе вместо выделения отдельного Finder.
Строит отметить, что многие ORM в Python реализуют Active Record и активно используют при этом неявный контроль соединений и транзакций. В отличие от них SQLAlchemy реализует паттерн Data Mapper и может дать больший уровень абстракции над хранилищем (обратите внимание на подход с
map_imperatively).Дополнительные материалы:
• http://www.corej2eepatterns.com/Patterns2ndEd/DataAccessObject.htm
• https://martinfowler.com/eaaCatalog/identityMap.html
• https://docs.sqlalchemy.org/en/20/orm/dataclasses.html#applying-orm-mappings-to-an-existing-dataclass-legacy-dataclass-use
Forwarded from ИИгорь R&D
О наивной схеме Эйлера
Герметическое броуновское движение (ГБМ) — стандартная модель для цены базового актива в финансах, начиная со статьи Блэка и Шоулза. В ней предполагается, что приращения логарифма цены распределены нормально. У этой модели есть 3 существенных преимущества. Первое — цена не может быть отрицательной. Второе — в ней все легко и явно считается. Третье — она отражает наше восприятие долгосрочного изменения цен акций, то есть, что акции растут на сколько-то процентов каждый год, а не на сколько-то тугриков. Другими словами, мы лучше воспринимаем относительное изменение (в %), а не абсолютное (в $). И ГБМ как раз про постоянное в некотором смысле относительное изменение цен.
Сэмплировать в этой модели очень просто: есть явное решение. Однако часто на ней иллюстрируют некоторые техники для численного интегрирования стохастических диффуров, типа интегрировать по схеме Эйлера не саму цену, а ее логарифм. Там сходимость получше (для ГБМ даже точное решение получается), и отрицательные цены не вылезают. А про наивную схему Эйлера (dS_t = S_t[mu dt + sigma dW_t]) говорят что-то типа: смотрите какой уродец, забудьте про него. Но мы к ней еще вернемся.
Есть и другая модель — арифметическое броуновское движение (АБМ). В ней предполагается нормальное распределение абсолютных приращений, а не логарифмических. Ее изначально предложил Башелье за 70 лет до Блэка и Шоулза, потом про нее все забыли, а потом снова вспомнили в 20 году, когда фьючи на нефть минусанулись. В ГБМ отрицательных цен не бывает, а когда они все-таки случились, то пришлось всем бодренько корректировать модели и вспоминать классику. Но базовой все еще остается модель ГБМ. Также АБМ вспоминают часто в контексте всяких моделей микроструктуры рынка, так как там она естественно возникает при переходе с микро- на макроуровень (см. работы Cont).
А я про это все задумался вот в каком контексте. В недавних работах на основе Deep Hedging'а и оптимизации полезности в целом отмечается, что экспоненциальная функция полезности проблемна. В качестве основной проблемы Buehler называет отсутствие оптимальной стратегии на ГБМ-рынке с отрицательным дрифтом (оптимально шортить, но там тупо интеграл расходится). И дальше предлагаются всякие уродские и костыльные фукнции полезности, про которые я даже писать не хочу. Но может быть проблема не в функции полезности, а в ГБМ? Может лучше что-то типа АБМ использовать? Там оптимальная стратегия всегда существует. А еще улыбки волатильности в АБМ менее скошенные для акций. И с микроструктурной точки зрения получше.
Я сейчас ковыряю Deep Hedging и мне нужно оптимизировать экспоненциальную полезность в какой-то простой модели для цены. С одной стороны, хочется чего-то, что похоже на традиционную модель ГБМ, чтобы быть в контексте всех исследований и нормально сравниваться, с другой стороны, хочется чтобы при этом и полезность оптимизировалась. То есть хочется какую-то модель, в которой на коротких интервалах цена ведет себя как АБМ, а на длинных — как в ГБМ. При этом меня не волнует, как там все считается, потому что все равно нейронки сами разберутся и стохастическим исчислением я тут не занимаюсь. И вот тут-то как раз и всплыла наивная схема Эйлера для ГБМ. На длинных горизонтах — это все-таки схема для моделирования именно ГБМ, так что все норм. А инкременты цены имеют нормальное распределение, а не лог-нормальное, так что все интегралы сходятся и полезность всегда существует даже чисто математически. Ну а чтобы отрицательных цен не получить, тупо воткнем absorbing barrier на 0.01 и полетели.
Герметическое броуновское движение (ГБМ) — стандартная модель для цены базового актива в финансах, начиная со статьи Блэка и Шоулза. В ней предполагается, что приращения логарифма цены распределены нормально. У этой модели есть 3 существенных преимущества. Первое — цена не может быть отрицательной. Второе — в ней все легко и явно считается. Третье — она отражает наше восприятие долгосрочного изменения цен акций, то есть, что акции растут на сколько-то процентов каждый год, а не на сколько-то тугриков. Другими словами, мы лучше воспринимаем относительное изменение (в %), а не абсолютное (в $). И ГБМ как раз про постоянное в некотором смысле относительное изменение цен.
Сэмплировать в этой модели очень просто: есть явное решение. Однако часто на ней иллюстрируют некоторые техники для численного интегрирования стохастических диффуров, типа интегрировать по схеме Эйлера не саму цену, а ее логарифм. Там сходимость получше (для ГБМ даже точное решение получается), и отрицательные цены не вылезают. А про наивную схему Эйлера (dS_t = S_t[mu dt + sigma dW_t]) говорят что-то типа: смотрите какой уродец, забудьте про него. Но мы к ней еще вернемся.
Есть и другая модель — арифметическое броуновское движение (АБМ). В ней предполагается нормальное распределение абсолютных приращений, а не логарифмических. Ее изначально предложил Башелье за 70 лет до Блэка и Шоулза, потом про нее все забыли, а потом снова вспомнили в 20 году, когда фьючи на нефть минусанулись. В ГБМ отрицательных цен не бывает, а когда они все-таки случились, то пришлось всем бодренько корректировать модели и вспоминать классику. Но базовой все еще остается модель ГБМ. Также АБМ вспоминают часто в контексте всяких моделей микроструктуры рынка, так как там она естественно возникает при переходе с микро- на макроуровень (см. работы Cont).
А я про это все задумался вот в каком контексте. В недавних работах на основе Deep Hedging'а и оптимизации полезности в целом отмечается, что экспоненциальная функция полезности проблемна. В качестве основной проблемы Buehler называет отсутствие оптимальной стратегии на ГБМ-рынке с отрицательным дрифтом (оптимально шортить, но там тупо интеграл расходится). И дальше предлагаются всякие уродские и костыльные фукнции полезности, про которые я даже писать не хочу. Но может быть проблема не в функции полезности, а в ГБМ? Может лучше что-то типа АБМ использовать? Там оптимальная стратегия всегда существует. А еще улыбки волатильности в АБМ менее скошенные для акций. И с микроструктурной точки зрения получше.
Я сейчас ковыряю Deep Hedging и мне нужно оптимизировать экспоненциальную полезность в какой-то простой модели для цены. С одной стороны, хочется чего-то, что похоже на традиционную модель ГБМ, чтобы быть в контексте всех исследований и нормально сравниваться, с другой стороны, хочется чтобы при этом и полезность оптимизировалась. То есть хочется какую-то модель, в которой на коротких интервалах цена ведет себя как АБМ, а на длинных — как в ГБМ. При этом меня не волнует, как там все считается, потому что все равно нейронки сами разберутся и стохастическим исчислением я тут не занимаюсь. И вот тут-то как раз и всплыла наивная схема Эйлера для ГБМ. На длинных горизонтах — это все-таки схема для моделирования именно ГБМ, так что все норм. А инкременты цены имеют нормальное распределение, а не лог-нормальное, так что все интегралы сходятся и полезность всегда существует даже чисто математически. Ну а чтобы отрицательных цен не получить, тупо воткнем absorbing barrier на 0.01 и полетели.
Forwarded from Aspiring Data Science (Anatoly Alekseev)
#pricing #mabs
Очень понравились статьи этого товарища о применении многоруких бандитов (в т.ч. контекстных) в ценообразовании. Классные симуляции для каждого случая, прямо образец, как нужно тестировать систему принятия решений (да-да, на синтетике).
https://towardsdatascience.com/dynamic-pricing-with-multi-armed-bandit-learning-by-doing-3e4550ed02ac
https://towardsdatascience.com/dynamic-pricing-with-contextual-bandits-learning-by-doing-b88e49f55894
Очень понравились статьи этого товарища о применении многоруких бандитов (в т.ч. контекстных) в ценообразовании. Классные симуляции для каждого случая, прямо образец, как нужно тестировать систему принятия решений (да-да, на синтетике).
https://towardsdatascience.com/dynamic-pricing-with-multi-armed-bandit-learning-by-doing-3e4550ed02ac
https://towardsdatascience.com/dynamic-pricing-with-contextual-bandits-learning-by-doing-b88e49f55894
Medium
Dynamic Pricing with Multi-Armed Bandit: Learning by Doing
Applying Reinforcement Learning strategies to real-world use cases, especially in dynamic pricing, can reveal many surprises