Проектируем платформу ставок с нуля? 💵

Сегодня займемся проектированием своей Real Time Bidding платформы ставок. На упрощенной схеме мы разберем из каких основных блоков она должна состоять, и как эти блоки между собой связаны.

➡️ Article
Собственно сама веб-страница с размещенными на ней рекламными слотами. Также в случае Header Bidding интеграции в шапке HTML кода страницы могут быть прописаны настройки, в которые добавлен наша платформа ставок, как игрок, имеющий доступ к покупке слотов.

➡️ TagJS
JS код, размещенный на странице паблишера. Отвечает за трекинг действий пользователя на сайте, например, когда пользователь доскролил до слота, увидел пиксель, кликнул etc. Отправляет события на нашу сторону.

➡️ Bidder
Биддер - это модуль, отвечающий за коммуникацию с паблишером (или с Prebid'ом, если закупаем трафик через Header Bidding) и отправку ставок.
- Принимает запрос на ставку + фичи паблишера + user agent, чтобы извлечь фичи пользователя.
- Собирает ставку с учетом заложенной маржи на запрос bid = CPM x (1 - margin) x bidFactors, с учетом коэффициентов, понижающих ставок, выданных автобиддингом.
- Когда ставка посчитана, отправляет на ендпоинт паблишера или Prebid'а ответ со ставкой.

➡️ Models
Все ML модели, отвечающие за фильтрацию, монетизацию
- Фильтрация по вероятности показа, клика, досмотра etc.
- Фильтрация по фроду
- Оптимизация ставки (shading, автобиддинг)
- Budget pacing
Может быть как интегрирован внутрь биддера, так и вынесен в отдельный сервис, к которому биддер будет обращаться как клиент.

Инференс, встроенный в биддер
В первом случае у нас получается маленький монолит внутри платформы из двух сервисов, в связи с чем потребуется быть более аккуратными при внедрении изменений в сервис, но появляется возможность кешировать модели, и насладиться относительно низким latency.

Отдельный инференс сервис
Во втором же случае структура получается модульная, в оба сервиса можно вносить изменения независимо друг от друга, но придеться заплатить более высоким latency (в основном из-за HTTP коммуникации между сервисами). Также встает вопрос, что делать биддеру, если сервис с моделями упал. Если в первом случае артефакты были закешированны на биддере, он мог пользоваться ими до тех пор, пока новые модели не подъедут, то во втором случае модули друг для друга становятся черными ящиками, и нужно задаться вопросом обеспечения минимального availability

➡️ Tracking
Пожалуй, центральный элемент всей схемы, поскольку на нем замыкаются все. Логирует абсолютно все события
- на стороне паблишера: действия пользователя + транзакции
- на стороне биддера: отказ от ответа, таймаут, ставка с ее значением
- на стороне моделей фильтрации: события фильтрации + ее причины
Кроме того логируем события биллинга, когда по аукциону мы должны получить оплату от рекламодателя и заплатить паблишеру

➡️ DB
Затреканные события и транзакции нужно куда-то писать, делать это быстро, и иметь оптимизированное хранилище. Здесь все делаем по заветам книжки с кабанчиком. Чаще всего прибегаем к следующему варианту. Tracking сервис пишет события по мере их поступления в очередь данных (Kafka, RabbitMQ). Далее с помощью либо Kafka коннектора, либо Spark Streaming джобы пишем события из очереди в батчи в объектное хранилище (S3, GCS) партициями. Также можно писать и в OTLP хранилище с быстрой записью транзакций (Greenplum)

Кроме того, нам также потребуется хранилище для аналитики (по-английски еще называют OLAP хранилища). Это нужно для отслеживания статов платформы в целом по аггрегатам трафик, CPM, CPC, CPV group by publisher, тип контракта, страна etc. Для этого подойдут ClickHouse или Google BigQuery

Invoicing
Модуль, который читает данные из OLAP хранилища и отвечает за выстапление счетов рекламодателю. На этапе трекинга в момент логирования события оплаты, сама оплата не происходит. Записанные события с биллингом аггрегируются, и рекламодателю выставляется счет на сумму, которая должна биться с бюджетом, который наша платформа открутила. Эта процедура делается раз в месяц или в квартал.

#rag #code

https://docs.llamaindex.ai/en/stable/examples/cookbooks/cohere_retriever_eval/
https://aws.amazon.com/blogs/machine-learning/build-cost-effective-rag-applications-with-binary-embeddings-in-amazon-titan-text-embeddings-v2-amazon-opensearch-serverless-and-amazon-bedrock-knowledge-bases/#:~:text=In%20end%2Dto%2Dend%20RAG,(98.6%25%20without%20reranking).

#Мыслинамысли: личный бренд, корпорации и жизнь

Вчера вечером мобильный YouTube подбросил интервью своего создателя — Андрея Дороничева. Он же — герой легендарного фильма Дудя (признан иноагентом в РФ) «Кремниевая долина» и фаундер Optic — одного из самых успешных AI-стартапов в биотехнологиях.

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

⚡️мыслями на мысли, которые зацепили

Момент, когда ты только объявляешь, что ты – тот, кем ты только собираешься стать, жутко некомфортный.

Помните, у Хармса?
Писатель: «Я писатель!»
Читатель: «А по-моему, ты говно!»

Когда мы начинаем какую-то деятельность, нам страшно представляться. Потому что — мы сами не чувствуем, что можем в этой роли много. Потому что — придут, обесценят, разоблачат. Привет, синдром самозванца!

Но правда в том, что другого пути нет: ты не станешь предпринимателем, экспертом, автором канала,руководителем команды, пока не осмелишься встать и сказать: «Привет, я теперь эксперт в этом!». Это коммит перед собой и миром.

Чтобы доказать своей аудитории, которая постоянно говорила «Ну конечно, тебе-то легко говорить, ты же вон какая звезда!» Андрей на глазах сотен тысяч человек провел эксперимент.
Взял область, в которой у него не было ни таланта, ни опыта, и публично объявил, что он — певец. Начал выкладывать треки: кривые-косые. Несколько месяцев проходил через публичный хейт «раннего творчества». Но с каждым днем его записи становились все лучше. И достигли вполне приемлемого качества. Стал ли он претендентом на Грэмми? Нет. Но он стал из очень слабого вполне нормальным исполнителем.

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

❗️Личный бренд работодателя VS ваш личный бренд

Дороничев пришел в Google на пару лет и задержался на 13. Когда он уходил, ему написала CEO YouTube с предложением остаться. Андрей посчитал миллионы долларов, которые теряет с уходом. И…ответил, что увольняется, потому «больше не понимает, кто он такой».

Работая в крупной компании с яркой культурой и идентичностью, очень важно отслеживать, как там поживает ваша собственная идентичность. И если вдруг в какой-то момент на вопрос «Кто я?» вашим первым ответом становится «Сотрудник Google, Яндекс, McKinsey, etc» — надо что-то делать, друзья!

❗️В мире точно есть люди, которым полезен ваш опыт. Важно хотеть им поделиться.

После выхода из Google Андрей осознал свою новую миссию: нести знания о мире инвестиций, IT и Кремниевой долине, в том числе через блог. Интересно ли это всем в масштабах человечества? Нет. Но точно есть сотни и тысячи людей, которым это мегаполезно.
Кому можете быть полезны вы, если вы не руководитель всемирно известного продукта, а просто хороший продакт?
Вчера на моей лекции в Вышке одна из студенток поделилась, что думает над переходом из SMM в продукт, но не понимает, с чего начать. Чем не миссия – круто рассказывать о своей работе классным ребятам, которые только выбирают свой профессиональный трек? Think about it!

Трансформации по плану и трансформации «по дизастеру»

Иногда жизнь дает нам возможность сформулировать точку B, подготовить почву для перехода, сформировать тактику и ее придерживаться. А иногда – с ноги выталкивает в сетап, где твой счет с 10 миллионами долларов, которые ты нарэйзил, за ночь превращается в тыкву.
И это тоже – не конец жизни.

В общем, очень советую вам посмотреть это видео, причем в равной степени предпринимателям и корпоратам. А найти его предлагаю самостоятельно, ориентируясь на то, что это популярное интервью Дороничева 4-месячной давности.

📺Приятного просмотра!

#dl #nlp

FlexAttention: Новый стандарт для реализации Attention в PyTorch

Кажется добавление такой фичи в Pytorch 2.5.0 осталось немного незамеченным, но так как его активно использует в своем коде lucidrains я решил про нее написать подробнее.

В теории, Attention is All You Need, но на практике оптимизированные реализации блоков внимания, такие как FlashAttention, стали необходимостью. Они добились значительного улучшения производительности относительно текущей реализации в Pytorch, позволив эффективно работать с длинным контекстом и не только. Однако, за такую эффективность пришлось заплатить — гибкость решений сильно пострадала. Сегодня внедрение новых вариантов Attention зачастую требует написания кастомных CUDA-ядер, что превращает экспериментирование в настоящую лотерею для резерчеров. Если ваши идеи не укладываются в уже существующие ядра, вас ждут медленный runtime или проблемы с памятью, а также куча низкоуровневой возни.

И к чему все это идет?

Разнообразие модификаций Attention уже велико и продолжает расти: Causal, Relative Positional Embeddings, Alibi, Sliding Window Attention, PrefixLM, Document Masking, Tanh Soft-Capping, PagedAttention и многие другие. Более того, комбинации этих технологий часто необходимы для конкретных задач — например, сочетание Sliding Window Attention + Document Masking + Causal. Однако существующие подходы предлагают крайне ограниченную поддержку таких возможностей, что серьезно ограничивает свободу разработчиков.

FlexAttention: новый подход, нативный для Pytorch

В Pytorch с этим не хотят мирится, поэтому принялись за разработку нового стандарта. Среди свойств нового модуля torch.nn.attention.flex_attention:

• Гибкость API — теперь реализация новых вариантов Attention занимает всего несколько строк кода.
• Оптимизация производительности — API автоматически преобразует ваш код в оптимизированное FlashAttention-ядро через torch.compile, избегая материализации лишней памяти.
• Автоматический backward pass — PyTorch autograd берет на себя генерацию обратного прохода.
• Работа со спарсностью — FlexAttention эффективно использует разреженные attention-маски, что дополнительно ускоряет вычисления.

Это решение делает исследование и внедрение новых идей значительно проще, ограничивая вас лишь вашей фантазией.
Примеры использования FlexAttention и туториалы можно найти в коллекции реализаций AttentionGym.

Производительность

FlexAttention уже демонстрирует конкурентоспособные результаты. На A100 решение достигает 90% производительности FlashAttention2 в прямом проходе и 85% в backward pass. Тем не менее, за универсальность приходится платить: некоторое падение производительности связано с дополнительными вычислениями во время работы. Разработчики планируют оптимизировать backward pass и минимизировать это отставание в скором будущем.

Несмотря на небольшие компромиссы в производительности, FlexAttention уже показал значительную практическую ценность. Например, он позволил увеличить throughput в torchtune (PyTorch native post-training library) на 71% и избавил исследователей от необходимости тратить недели на разработку кастомных ядер.

Ограничения и перспективы
• Ведутся работы над улучшением производительности до уровня FlashAttention3 на H100 GPU.
• Пока что длина последовательностей должна быть кратна 128, но это будет исправлено.

#dl #code

Пока я готовлю некоторый основательный материал по распределенному обучению (вот, теперь я вам его пообещал, придется сделать...), можете посмотреть отличную библиотеку picotron с реализацией 4-D параллелизма на чистом torch.distributed от Huggingface,

Кроме того, это все сопровождается ongoing серией видео-туториалов от основного разработчика на его канале [ссылка на плейлист].

А еще есть более хардкорная версия 3-D параллелизма - nanotron, так же от HF.