Вчера общался со старшим директором по Data Science в одной компании в Штатах. Оказалось, что именно она была автором той самой модели в Target, которая в своё время отправила купоны со скидками на детские товары в семью, где отец ещё не знал, что его дочь беременна. Той самой, после которой он в ярости прибежал в ближайший магазин Target разбираться: С какого перепуга вы присылаете моей дочери такое (My daughter got this in the mail!” he said.“She’s still in high school, and you’re sending her coupons for baby clothes and cribs? Are you trying to encourage her to get pregnant?)? А спустя некоторое время вернулся и сказал: Да, она беременна. У меня к ней был один главный вопрос. В сообществе ведь ходили две версии этой байки. По одной, девушка сама ещё не знала о беременности, а модель уже всё поняла. По другой — девушка знала и уже покупала какие-то товары, по которым модель определила беременность и начала предлагать скидки на соответствующие покупки. Не знал только отец. Ну и тайна раскрылась: по её словам, сама девушка уже знала, что беременна. Конечно, забавно в какой-то момент карьеры встречать людей, о которых ты никогда не слышал, но прекрасно знаешь о том, что они создали. А еще она пишет детские книжки

ML вообще работает? ч3 Начинается мое любимое: как померить ощущение «персональности» рекомендаций? Про учет пола, возраста и размера все и так в курсе, поэтому поговорим о чем-то более интересном Чаще всего смотрят смотрят на вау-метрики типа serendipity ~ высокий скор релевантности товара для юзера, но не популярный товар Но, если честно, я ни разу не видел, чтобы эта метрика кого-то убедила, что лента персональная. Имхо потому что: - метрика завязана на скор модели (модель оценивает сама себя) - метрика не очень интерпретируема Поэтому я бы заходил с другой стороны Учет базовых интересов из истории взаимодействий В широком смысле персонализация — учет истории взаимодействий пользователя с сервисом. Очевидно, но так давайте явно проверять, учитывает ли это наша система! Я бы мерил в терминах Defect rate долю показанных товаров, для которых есть взаимодействия с - Широкими категориями из истории (покупал спальник — рекомендуем ли товары для туризма?) - Любимыми брендами (купил футболку muted — показываем ли шорты/носки этого бренда?) Через такую метрику «у нас 60% рекомендаций из широких категорий юзера и 25% из любимых брендов» вполне можно убеждать бизнес (и себя!), что персонализация работает. Плюс, легко проверить для отдельно взятого юзера, работает ли персонализация конкретно для него Stay tuned

🎣 Вот это байт Вечером прилетает уведомление от AI Challenge: Поздравляем с успешным прохождением квалификационного этапа и выходом в… На этом превью обрывается. Мысленно я уже в финале – думаю, на что потратить призовые деньги. Открываю – а там сертификат участника основного этапа. В финал пока никто не звал Залетел в соло порешать задачу 3D Mesh Quality Control: Автоматизация поиска дефектов для обучения генеративных моделей На публичном лидерборде я был 1м, на приватном – 8м. Здарова, шейкап! опять были сабмиты на 3-4 место, не повезло Дальше будут оценивать презентации и код, так что места могут перетасоваться. Я особо не верю, но вдруг @tagir_analyzes

Предсказать среднее могут не только лишь все Классическая задача машинного обучения - тренировочный и тестовый датасет, бинарная классификация. Если ваша модель без глаз и ушей, т.е. не получает фичи на вход, то она посчитает avg(y) на тренировке и предскажет это для каждого тестового образца. Когда мы выкатываем модель в прод, то одним из критериев её самочувствие является так называемая калибровка - sum(p(y)) / sum(y). Даже выше упомянутая слепоглухая модель будет "откабирована". т.е. измерение будет равно примерно 1. Казалось бы - планка-то не очень высокая. Если калибровка в проде не 1, то с моделью что-то сильно не так. Мы выложили модель в открытый доступ, так что не секрет, что наш ранкер - это простой трансформер с ранним связыванием, применяемый над историей пользователя и представлением кандидата. Все посты представлены в виде id автора, id поста, и ещё там есть пачка банальных контекстных фичей. Вся эта фигня тренируется в реальном времени на всех поступающих данных. Свежие чекпоинты постоянно отгружаются в инференс и в прод. Так вот, от нашего ранкера не так уж и просто добиться откалиброванности. Это очень капризная дама. Если тренировка падает на час и в проде продолжает применяться замороженный чекпоинт - прощай, откалиброванность. Предсказания по не до конца ясной причине начинают плавно расти со временем. Через несколько часов они вырастают в 5-10 раз. Любое малейшее расхождение фичей на тренировке и применении - калибровка летит в жопу. Причём обычно именно в большую сторону, непропорционально падению CTR. На днях дебажил проблему. У нас есть конверсионная модель, предсказывающая вероятность p(purchase | click). Покупка лишь изредка происходит сразу после клика, поэтому реальную метку надо ждать какое-то время. Я работал над моделью с 24-часовой задержкой. То есть каждый обучающий образец - это клик на рекламу, случившийся ~сутки назад, и метка покупки. На тренировке всё выглядело нормально, а как выкатываю в прод - калибровка >2 - модель начинает выдавать в 2 раза большие скоры, в том числе на теневом трафике прода - то есть без учёта selection bias. Я беру эти образцы. Думаю - может из-за расхождения в историях - модель могла не обучаться на свежих постах и в эмбеддингах там мусор. Создаю исскусственную задержку - такое же говно. Думаю - ну может распределение кандидатов меняется? Пробую подставлять старых кандидатов - такое же говно. Нежно приложив пистолет к виску моего агента, я сказал ему копать - перебирай все фичи, пока не найдёшь, из-за чего эта херня возникает. И что вы думаете? Сраный день недели. В представлении кандидата есть эмбеддинг текущего дня недели. У тренировочных данных, на которых тренируется модель, эта фича всегда равна предыдущему дню недели. А в проде она равна текущему дню. Если в проде подменить фичу дня недели на вчерашний, модель резко выздоравливает и предсказание превращаются в норму. Какого чёрта оно так себя ведёт? Не знаю, и знать не хочу. Обожаю машинное обучение. @knowledge_accumulator

Как научиться предсказывать что угодно? 🔮 На видео спикер рассказывает, что его команда научилась за три дня до расставания предсказывать, что девушка бросит парня. Когда я впервые увидел это в трансляции, то понял только часть проблемы: спикер вообще не шарит, а команда решает странные задачи и пилит такие же фичи 😅 Тогда моего руководительского опыта не хватило, чтобы задуматься о процессах внутри компании — меня просто поразил уровень абсурда. Причём настолько, что эта история догнала меня даже спустя семь лет. Но сейчас, когда я строю собственную компанию, меня гораздо больше беспокоит другой вопрос: какие процессы внутри компании привели к тому, что топ-менеджмент рассказывает об этом на конференции как об успешном кейсе? 🤔 Начнём с самого кейса. Пока я не пересмотрел видео, у меня были разные гипотезы о том, как они собрали целевую переменную: — может быть, провели опрос? — спарсили социальные сети? — а как тогда собрали хард-негативные сэмплы? Но нет. Судя по видео, аналитики придумали сегмент на основе набора косвенных признаков. С какой точностью этот сегмент отражал реальность? Правильно: никто не знает 🙃 Дальше, вероятно, построили модель, которая научилась предсказывать эту синтетическую целевую переменную. И здесь появляется ещё один уровень неопределённости. Сначала мы с неизвестной точностью восстанавливаем целевую переменную по косвенным признакам. Затем с некоторой точностью обучаем модель предсказывать уже эту восстановленную переменную. То есть модель предсказывает не само расставание, а предположение аналитиков о расставании. На ошибку при создании таргета накладывается ошибка самой модели. Поэтому итоговое качество относительно реального события становится ещё менее понятным 🎯 Следующий вопрос: как проверяли лики? Не протекли ли в модель те же признаки, на основе которых изначально восстановили целевую переменную? 🫠 Ну и самое интересное: как измерили эффект? Никак. Модель встроили в рекомендательную систему, в которой, судя по рассказу, нет прозрачно рассчитанного финансового эффекта 💸 Итак, рецепт, как научиться предсказывать что угодно: 1. Конструируете целевую переменную с неизвестной точностью. 2. Обучаете модель предсказывать этот синтетический таргет. 3. Получаете два слоя ошибки: в разметке и в самой модели. 4. Встраиваете модель в продукт, где невозможно оценить её эффект в деньгах. 5. Рассказываете об успешном кейсе на конференции. 6. Готово — вы великолепны! 🚀 Всё это звучит смешно ровно до того момента, пока вам самим не приходится собирать такие фантастические сегменты и обучать на них модели. Напишите в комментариях, если знаете достоверный источник данных для такого сегмента. Особенно интересно, где взять качественные хард-негативные сэмплы 👇

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