Подписчик в комментариях указал на важную проблему популярных алгоритмов оценки внутренней размерности облака точек, за что ему большое спасибо! Выяснилось, что при большой истинной размерности облака они дают систематически заниженную оценку этой размерности. При чем чем больше настоящая размерность, тем сильнее занижается оценка. Я решила проверить это и навайбкодила ноутбук, в котором генерируются облака точек, равномерно заполняющие n-мерные шары: https://colab.research.google.com/drive/1kIRin8sBBNQDFvruXWITU3i5kL7x7Zww?usp=sharing Краткие результаты: - При размерности такого шара 10 и количестве точек 2000, три алгоритма оценки размерности (PHD, TwoNN и MLE) дают что-то между 8.5 и 9, то есть занижают незначительно. А вот при размерности 100, PHD уже даёт оценку в 64, а TwoNN и MLE и вовсе около 50, то есть оценка занижена в целых два раза (см. рис. 1). - Увеличение количества точек в шаре может помочь подтянуть оценку к истинной, но, похоже, что для этого увеличивать их количество нужно экспоненциально с ростом размерности. Интересные выводы, и вообще даже странно, что раньше я не знала о таком явлении. Или знала, но забыла? 😅 Честно говоря, мозг от вайбкодинга уже совсем потек, так что ничего не могу сказать с уверенностью 😅 В любом случае, надеюсь, что эта инфа будет полезна всем, кто интересуется внутренней размерностью и т.д. P S В случае любых ошибок в ноутбуке - все претензии к Клоду 😍 #эксперимент #наука

Как я променяю свою DS экспертизу вне «Хогвартса» Я решил максимизировать число бэклинков на свой западный аналогичный сервис. Заметил, что некоторые каталОги «последователи» парсят другие каталОги разных вебресурсов и добавляют к себе. Причем таких много. Видимо копируют даже друг друга. То есть если попасть в «головной», где все смотрят новинки, то меня тоже спарсят и разместят у себя, но уже бесплатно. Так я напарсил 7400 таких веб-ресурсов. (офигеть сколько их?!). Дропнул всех, которые совсем мертвые по трафику и точно не могут быть в верхушке «дерева». Разбил всех по дате регистрации домена, трафику и по дате обновления 70 ключевых точек (их тоже предварительно подобрал аналитикой) Чтобы смоделировать динамику распространения, я сделал слепок с паузой в неделю. Дальше отрисовал всех доноров информации через networkx.org на python ⌨️ (Да лан, я угораю, это мне Claude сделал. Уже по моим готовым данным строил визуальный граф) Увидел, что все опираются на ~34 каталога донора, которые видимо являются самыми первичными с уникальной инфой и прочими метриками. Туда кстати вошел Product Hunt, Forbes и ряд других известных ресурсов. Почти все из 34 доноров имеют либо платное, либо сложно модерируемое размещение. Я отобрал 10 платных. Вышло примерно $1.4к за не самые дорогие тарифы. Куда-то я даже попросил добавить меня через знакомых. (Покупал тарифы тоже с рядом условий, например, кликабельные упоминания) Получается, я купил всего 10 бэклинков. Спустя 3 дня я обнаружил, у жены до сих пор послеродовая депрессия (помогите). Зато уже 27 сервисов продублировало меня к себе. Увидел это через аналитику в гугл консоли. Я глянул все их тарифы аксепторов. Это примерно $3.4к если покупать напрямую все 27 размещений. То есть я уже сэкономил неплохую «котлету» кэша 🤤 И это только то, что успел заиндексировать гугл. То есть в теории я могу потенциально получить эффект, сопоставимый c денежным эквивалентом в ~(7.4к/27)*$3.4к = $932k, и минус мои $1.4к за размещения 🔫 Это конечно не сразу ко мне на карточку прилетит, придется еще ценность создать. Но вот если теперь приплюсовать сам эффект от SEO, который произойдет через 3-5 месяцев, то тогда вопрос …., почему я блин так сразу не сделал?!?! Мораль: всегда относился к DS/ML навыкам как к возможности что-то хакнуть, а не причине поработать в найме за лимитированную ЗП.

Book Review: Python for Algorithmic Trading Cookbook Мне прислали очередную книжку от Packt на прочтение и ревью — на этот раз про алгоритмический трейдинг на Python. Тема для меня в чём-то новая, но давно интересная: пару месяцев назад я как раз хотел поиграться с Interactive Brokers API, а ещё много лет назад вручную торговал на форексе, так что было любопытно посмотреть, как всё это автоматизируется сейчас. Книга - это cookbook из 68 рецептов, которые проводят весь путь от получения рыночных данных до отправки ордеров через брокера. По структуре это конвейер: данные (OpenBB, pandas, Polars/DuckDB) → research (ArcticDB, AI и agentic workflows, alpha-факторы) → бэктест (VectorBT, Zipline Reloaded) и оценка факторов (Alphalens, Pyfolio) → live-исполнение через Interactive Brokers → и в конце ускорение на GPU через NVIDIA RAPIDS. Больше всего понравилось, что книга доходит до реального исполнения, а не останавливается на бэктесте. И отдельно порадовало внимание к валидации — данные версионируются в ArcticDB с time travel (чтобы случайно не заглянуть в будущее), а глава про walk-forward честно объясняет, почему на временных рядах нельзя перемешивать фолды. Кстати, я про это писал в своих заметках. Ещё есть глава про AI: RAG-аналитик по отчётности на LangChain/Chroma/Claude, агенты на LlamaIndex, которые сами пишут и запускают код, и рецепт про превращение статьи со стратегией в рабочий код. Amazon Code Мои обзоры: Personal blog Medium #bookreview

давно хотела сделать удобную навигацию по каналу - кажется, что можно было бы просто опубликовать пост со ссылками, но так не интересно, да и всю 1000 постов вместе не уместить. Так что я решила навайбкодить интерактивную карту 😎 взяла все что есть с 2019 года, прогнала через эмбеддинги и разложила на плоскость - близкие по смыслу оказались рядом. получилось 12 зон - причем если до 2023 это были технические и личные посты, то после - скорее про aesty и стартапы. Ну и про визу талантов сша целый кластер нарисовался 🤨 каждый пост связан с ближайшими соседями по смыслу, так что по архиву можно гулять, плюс поиск и фильтры по годам и темам скажите, если хотите опенсорс, чтобы можно было сделать такое для своего канала

​​Time Series with PyTorch — Graeme Davidson, Lei Ma Мне прислали очередную книжку от Packt на прочтение и ревью - на этот раз про time series forecasting на PyTorch. Тема мне близкая: временные ряды — одна из самых сложных для меня областей ML, и при этом большинство книг по deep learning относятся к ним как к чему-то второстепенному после CV и NLP. Книга идёт начинает с базовых вещей (что делает временные ряды сложными, как правильно оценивать модели, PyTorch с нуля), демонстрирует современные архитектуры (RNN, transformers, N-BEATS, N-HiTS, foundation models, diffusion) и выходит за пределы точечного прогноза — классификация, кластеризация, anomaly detection, self-supervised learning. Мне понравилось, что тема правильного качества моделей разбирается в деталях: например, показывают как заведомо худшая модель выигрывает по MAPE, и есть целая глава про data leakage. Отдельно порадовали объяснения через физику: один из авторов физик, и он объясняет RNN через качели на детской площадке, а diffusion — через каплю чернил, которая расплывается в воде, пока не превратится в гауссиану. Ещё мне понравилось, что примеры построены вокруг соревнования M5 на Kaggle. Я в нём когда-то участвовал и зафейлился, так что было интересно посмотреть на разные модели и подходы к оценке на данных, с которыми в своё время намучился. Из минусов — про time series foundation models (Lag-Llama, TabPFN, Chronos, TimeGPT) рассказывают, но не запускают их на практике, а это как раз то, что хотелось бы попробовать руками. Amazon Author's website Code Мои обзоры: Personal blog Medium #bookreview

Measuring the Impact of Personalized Recommendations Netflix предлагает раскладывать эффект рекомендаций на три части: • Exposure - тайтл посмотрели, потому что его вообще показали. • Selection - его показали тем, кто и без рекомендации был склонен посмотреть. • Targeting - показ изменил решение именно этого пользователя. Наблюдаемый просмотр смешивает все три эффекта. Поэтому высокий CTR рекомендации ещё ничего не говорит о её причинной ценности - система могла просто хорошо предсказать уже существующий спрос У Netflix чистый targeting почти в семь раз сильнее exposure. То есть основная ценность современного рекомендатора - не в том, чтобы найти релевантный контент, а в том, чтобы найти пользователя, чьё решение рекомендация действительно изменит, а не просто предсказать его выбор И сильнее всего это работает не на хитах и не на совсем нишевых тайтлах, а в середине каталога - там, где спрос существует, но без персонализации не реализуется. https://netflixtechblog.medium.com/measuring-the-impact-of-personalized-recommendations-4c26be3a4d96

The art of a strong baseline За последнее время все чаще понимаю, что создать сильный бейзлайн - это не просто база, с которой нужно начинать любой ml/ai продукт, а прям полноценная часть системы. Даже когда в проде уже давно есть трансформеры и агенты, бейзлайн дает прям много метрик Вот учите вы трансформер для персональных рекомендаций (sasrec, argus, pinnerformer, hstu - неважно).  И если в лоб его применить, то вероятно получите рекомендации из истории кликов. Потому что простой бейзлайн "уже изучал товар - покажи еще раз" чаще всего почти по любым метрикам релевантности будет лучше Окей, пофильтровали историю кликов / занизили таким позитивам вес в лоссе / сделали еще что-то - получили очень-очень похожие товары на последние 30-50 действий. Вот буквально товар того же бренда-категории, но чуть другого цвета условно. А это уже похоже на другой сильный бейзлайн - realtime slim/als/ease на последних 30-50 действиях На самом деле можно еще и дальше продолжать с бейзлайнами в этом кейсе или в других. Частые бейзлайны: - Персональные рекомендации - популярное, история, уже купленное для повторных покупок - item2item рекомендациях (похожие товары) - популярные товары того же бренда в той же категории  - Поиск - tfidf/bm25. Да, даже в эру dense retrieval и search agents если аккурфтно подтюнить bm25, то можно выбить sota. Есть даже подходы на основе Sparse autoencoderse , которые позволяют генерить не эмбеды запросов/документов, а их токены - и дальше применять обычный bm25 - Прогноз временных рядов - среднее значение в тот же день недели  ↔️ Я всегда стараюсь строить сильные бейзлайны, а потом учить более сильные модели для улучшения поверх них, а не для замены. Потому что какой толк учить условный sasrec/argus для запоминания истории кликов пользователя? Пустая трата компьюта + модель тратит свою капасити на тривиальные зависимости = что-то нетривиальное (и самое полезное + ожидаемое от нее) не учит Интересно, как не только я сам, но и другие люди в в индустрии / рисерче к этому подходят: я видел очень мало подобных работ. Если есть личные опыт или ссылки на полезные статьи - кидайте, с интересом почитаю!)

Да кто такие эти ваши producer-side A/B-тесты? В своей яндексовской эре работы над рекомендациями я точечно работал над качеством ранжирующей модели и не выглядывал за пределы этой области. Та же история была и в рекомендательном периоде работы в X. Но тут один добрый человек рассказал мне, что я оказывается жизни-то вообще и не знаю. Качество системы с точки зрения пользователя это ещё половина проблемы. Дело в том, что для долгосрочного качества платформы и процветания бизнеса необходимо смотреть на то, как изменение системы влияет на производителей контента (что в соцсети, что в маркетплейсе). В самом экстремальном случае система может показывать пользователям очень маленькую прослойку разнообразных авторов и игнорировать остальных. Те могут расстроиться и перестать постить, тем самым ухудшить долгосрочную ситуацию. Влияние на авторов и замеряется с помощью этого самого producer-side A/B теста. Посмотрим на то, как выглядит наивная её реализация в контексте рекомендаций. Среди всех авторов выделяем 2 группы - контрольную и тестовую - к примеру, по 1%. Скор для (98+1)% документов считается дефолтной моделью, тогда как для тестового набора из 1% будем предсказывать новой моделькой. Допустим, что она отдаёт большее предпочтения мелким авторам. Такой тест покажет прекрасный результат - все мелкие авторы счастливы и стали генерировать больше контента. Классический user-side тест, допустим, показал нейтральные метрики. Вроде бы всё в шоколаде, и вы шипаете изменение в прод, но вот беда - эффект испарился. Задроты вам укажут - на лицо нарушение Stable Unit Treatment Value Assumption. Перевожу на русский - изменение ведёт себя по-разному в зависимости от доли, на которую его раскатили. Тот кусочек мелких авторов среди 1%-ной выборки получил преимущество перед 99% таких же вне её. Раскатив изменение, весь рост показов, которые они получили в AB-тесте, размажется на остальные 99%. Чтобы побороть этот эффект, нужен фреймворк посложнее. Одно из решений предлагается в статье от Меты - "A Counterfactual Framework for Seller-Side A/B Testing on Marketplaces". Не знаю, насколько в ней это впервые предложили - может и нет, мне не важно. Иллюстрация на картинке. Итак, теперь мы будем оценивать 100% постов обеими системами - старой и новой (синей и зелёной). Для документов из контрольной выборки мы получаем их финальные позиции, как если бы мы ранжировали все 100% документов так, как обычно - они обозначены как C_1 и C_2. В то же время, документы из тестовой выборки получают свои финальные позиции так, как если бы все 100% документов ранжировала новая система - это T_1 и T_2. Финальную выдачу для пользователя мы создаём, расставляя эти документы на их соответствующие позиции, закрывая глаза на коллизии и помещая случайно друг под другом, если позиции точно совпали. Самый прикол этой схемы в том, что на ранжирование остальных 98% документов в принципе всё равно - до выкатки это будет старая система, после выкатки это будет новая система, но размер эффекта на документы в обоих случаях ожидается одинаковый. Именно это в том числе и проверяют авторы данной работы. В нижней части слева расположена выдача до выкатки - pre-test, а справа после выкатки - back-test. Авторы приводят результаты своих тестов, в которых демонстрируют одинаковость эффекта на измеряемые документы. Такая схема тестирования гораздо ближе к SUTVA. Надо понимать, что эта грёбаная SUTVA никогда не выполняется полностью. Любая выкатка изменяет распределение данных для обучения и последующее ранжирование. В обычных пользовательских A/B-тестах на это закрывают глаза и надеются, что эффект сохранится, что часто подтверждается holdback-экспом. А вот с авторскими A/B-тестами приходится проделывать такую гимнастику, чтобы хоть как-то подобраться к честному замеру. @knowledge_accumulator

Обсуждали на одном из подкастов моё скептическое отношение к синтетическим людям. В дискуссию врывается Рон Кохави с теми же аргументами на примере разбора SimAB: Simulating A/B Tests with Persona-Conditioned AI Agents for Rapid Design Evaluation.

I think there is value in using LLMs as a screening tool, and this paper is a good example. The tool could be used as a fast design-screening tool that makes predictions based on historical A/B tests, conventions, best practices, and folklore. It may work well against experiments similar to the history it has been trained on, but it is unlikely to work well for radical ideas (e.g. long-ad titles that I start my Maven course and book with). The title’s use of “Simulating” over-reaches, as it is impossible to establish causality from observational data without additional assumptions. LLMs are trained from historical data and are therefore not enough to simulate A/B tests without strong assumptions.

И

The system's greatest strength is acting as a "Shift-Left" tool in the design process. Before any engineering effort is spent coding a variant, SimAB can evaluate mockups to catch blatant usability flaws, confusing copy, or structural friction. As the authors note, it is an excellent mechanism to "kill bad ideas fast".

То есть да, что-то быстро проверить можно, но использовать как инструмент оценки, тем более численной, — это непонимание принципов работы LLM.