Интересное что-то
517 subscribers
2.72K photos
253 videos
139 files
4.52K links
Материалы и мысли, понадерганные отовсюду
Блог: https://t.me/asisakov_channel
Чат: https://t.me/youknowds_chat
Download Telegram
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
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
Чем отличается мидл+ от джуна? (часть 1)

Авторский взгляд, буду кратка.

Вижу 2 ключевые штуки.

Нет, это не бесконечное знание хардов. Это можно натренировать в тепличных условиях на курсиках и искусственных данных. Типа как протеиновый качок, которого натянули местные дрыщи в дворовых потасовках за гаражами😃 Потому что он не нюхал настоящего пороха. Жизнь его готовила к поднятию искусственных тяжестей, а не тому, что надо кулаками работать.

Штука 1: мидл+ имеет свою точку зрения по большинству вопросов, джун бежит сиюминутно выполнять любые указания продакта без их оценки на адекватность. Да и как ты оценишь, если опыта не имеешь? Даже если начнешь что-то вякать, скорее всего тебя задавят опытом и насмотренностью, если только по ту сторону не откровенную дичь несут.

😳Когда я была джуном, мой продакт решил проверить "гениальную" гипотезу: что будет, если при заходе в приложение показывать на весь экран неперелистываемые нескрываемые сторизы на 30 секунд.

Задумка была благородная: если мы проинформируем людей о всех возможностях нашего сервиса, после подобного зомбирования они понесут свои денежки к нам в карман.

Реальность: метрики упали на 50%, потому что люди, видя 30-секундное безальтернативное нечто, закрывали приложение и не возвращались👍😰

Когда ты на ежедневной основе работаешь с большими данными, начинаешь хотя бы ориентировочно понимать, что триггерит людей в хорошую и плохую сторону. Сейчас бы я такую задумку зарубила бы на корню. Если бы меня не послушали, эскалировала до лидов и хэдов, чтобы мы не тестировали откровенно вредительские гипотезы. Мне сейчас просто лень заниматья подобной фигней.

Подумайте, сколько сил было вложено огромным количеством людей: дизайнер нарисовал сторизы, разработчики из закодили на двух мобильных платформах, тестировщики проверили их на баги, App Store и Google Play проверили их на скам, аналитик сделал разметку, поставил ТЗ на разработку, выбирал метрики, выгружал данные, дизайнил АВ, заводил АВ тест, считал АВ тест руками... - чтобы получить колоссальную просадку в результатах😭

Когда работаешь над продуктом, надо иметь хотя бы зачатки эмпатии, чтобы предсказывать поведение пользователей. И проводить минимальные кастдевы.

Джун скорее всего не погружен в типовые продуктовые процессы, не имеет реальной насмотренности и своего мнения. Опытный продакт таким будет вертеть и крутить по своему усмотрению.

Если ты сам обладаешь багажом опыта за плечами, тебе легче протолкнуть разные идеи. На каких сегментах что тестировать, что смотреть в рисерче и тд.

😳Еще забавный пример: проходила продуктовое собеседование в Skyeng. Тимлид рассказал об их реальной фиче и попросил задизайнить АВ тест. Я обычными логичными рассуждениями вслух за 10 секунд вышла на тот сегмент пользователей, на которых надо было ее тестировать.

В реальности в компании этот путь занял 2 итерации теста🤷‍♀️ В первой итерации тестировали на всех и получили ожидаемую просадку метрик на "не том" большом сегменте. Как в простом советском анекдоте: "дорвались до прода джун-продакт и джун-аналитик..."

А могли бы нанять меня, мы бы столько времени на тестировании бесполезных гипотез сэкономили...


если нужна вторая часть, втопите лайков, огонечков и другой обратной связи👇🔥🙂
Please open Telegram to view this post
VIEW IN TELEGRAM
Чем отличается мидл+ от джуна? (часть 2)

сначала прочитай часть 1

Штука 2: мидл+ скорее всего видел в своей карьере ооооооооочень много дерьма
.

🆘Ломающиеся каждый релиз данные,

🆎поломанные АВ тесты: без равномерного сплитования, без контрольной группы (я ахуела, когда мой разраб накодил тест только для тестовой группы, жизнь меня тогда к такому не готовила), без разметки, которые останавливаются третьими людьми, -

🆘падающие базы данных, по ошибке сделанная drop schema, падающие даги, задвоенные/отсутствующие местами данные, ситуации, когда сегодня ты посчитал конверсию 5%, а завтра 25%, сидишь нихуя не понимая, где ошибся,

🆘ситуации, когда тебя клюют заказчики каждый час, когда вводные от них меняются каждые 5 минут, когда надо выгрузить срочно-срочно оооооочень красивые данные, иначе побойся бога, сохрани здоровье топ-менеджеров...


После этого афгана у любого мало-мальски наблюдательного человека начинает формироваться свое мнение и стальная задница. Да, в некоторых вопросах оно мнение может быть твердым, в некоторых колебаться.

НО! в любой возможной ситуации опытный специалист будет вести диалог с заказчиком на равных. Не как калькулятор на побегушках, а как человек со своим мнением, которое скорее всего более обоснованное, потому что с данными напрямую работает именно аналитик.

Там, где будет нужно подкорректировать взгляд продакта, увести его руку от принятия дичь-решений, где можно подать данные под более выгодным углом, где можно выбрать более интересные метрики или провести АВ тест как-то иначе - мидл+ обязательно это озвучит.

Особенно если можно вырулить задачу так, чтобы вообще ее не делать. Ведь стальная задница, наученная опытом, понимает, что существует мало действительно горящих и критических задач. Зачастую для решения проблемы надо просто дать ей настояться.

Да, такое бывает, чем больше опыта, тем меньше осознанных целенаправленных телодвижений человек совершает.

Особенно если речь про большие и сложные сервисы.

Опытный постарается иметь максимально широкий контекст, быть в курсе, что делают на соседних направлениях.


Зачем?

1️⃣ очень интересно наблюдать синергию и внутреннюю конкуренцию разных направлений за рост метрик. Вы вырастили конверсию и хлопаете в ладоши от предвкушения премии? Вот только пидары из соседней команды раскатили фичу, которая сканнибализировала весь ваш трафик, поздравляю, но премия в другой раз😭

2️⃣ чем больше вы знаете о результатах работы коллег-аналитиков, тем меньше вам самим надо работать. Задачи часто пересекаются, может оказаться, что ваш коллега уже собрал нужную витрину, дашборд или вообще даже нужные метрики уже выгружал.

Больше контекста - больше понимания логики принятия решений наверху - больше власти, как на эти рычаги давить. Даже если речь про ваш мидловский микромасштаб. Надо же с чего-то начинать.

Джун же побежит сверкая пятками быстрее-быстрее делать. Либо побежит спрашивать лида/ментора, что уже в целом неплохой вариант. Главное - включать во время работы голову и думать, кто что делает и к чему это приводит. Собирать большое количество наблюдений и делать из них выводы.

В интернетах популярны тесты на психологический возраст. Поэтому по аналогии спрошу:


а у вас какой психологический грейд?🤡
Please open Telegram to view this post
VIEW IN TELEGRAM
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
Please open Telegram to view this post
VIEW IN TELEGRAM
Technology Radar 2024

Год потихоньку подходит к концу. Пришло время посмотреть, какие технологии появились, какие устаканились и какие ушли на второй план.

Довольно много 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
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) загружаю системный промпт со схемой в первое сообщение. Помечаю для кэширования через "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: Бенчмарк модели будет попозже
Паттерны работы с базами данных

В большинстве проектов мы храним какие-то данные. Для этого используются разные виды баз данных: реляционные, 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 и полетели.
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