Forwarded from Quant Researcher
Ответы ЕГЭ 2025 Advances in Financial Machine Learning
Делимся решениями упражнений из книги. Они помогут проверить собственные решения или подсмотреть ответ, но мы настоятельно рекомендуем сперва решить задачу самостоятельно. Так оно лучше запомнится.
📌 Почему это важно?
- Даёт структурированную базу для разработки и тестирования стратегий
- Покрывает ключевые темы: тройные барьеры, размер позиции, фильтры, фичи для ML
🛠 Cтек:
- Python 3.7.4, numpy 1.17.3, scipy 1.3.1, numba 0.49.1
- pandas 1.0.3, matplotlib 3.1.1, sklearn 0.23.1, statsmodels 0.10.1
🔹 Бонус: Автор приложил скрипт для генерации синтетических данных — если будет нужно ЭЙЧЕЙФТИ.
📜 “Каждая успешная стратегия всегда подкреплена либо теорией, либо результатами. Одно ведёт к другому.”
Quant Researcher
Делимся решениями упражнений из книги. Они помогут проверить собственные решения или подсмотреть ответ, но мы настоятельно рекомендуем сперва решить задачу самостоятельно. Так оно лучше запомнится.
📌 Почему это важно?
- Даёт структурированную базу для разработки и тестирования стратегий
- Покрывает ключевые темы: тройные барьеры, размер позиции, фильтры, фичи для ML
🛠 Cтек:
- Python 3.7.4, numpy 1.17.3, scipy 1.3.1, numba 0.49.1
- pandas 1.0.3, matplotlib 3.1.1, sklearn 0.23.1, statsmodels 0.10.1
🔹 Бонус: Автор приложил скрипт для генерации синтетических данных — если будет нужно ЭЙЧЕЙФТИ.
📜 “Каждая успешная стратегия всегда подкреплена либо теорией, либо результатами. Одно ведёт к другому.”
Quant Researcher
Forwarded from Tensor Banana
Yue-7b - генерируем песни на русском локально
Языки: английский, китайский, японский, корейский, русский (с акцентом).
генерация:
- по жанру + тексту песни
- по референсному аудио + жанру + тексту песни (почти кавер, позволяет задать нужное направление)
- в fp16 весит 12.5 GB. в формате nf4 занимает всего 6.5 GB vram!
- на русском лучше генерирует мужской голос. В женских - сильный акцент.
## Установка под Windows (без wsl)
Нужны
- питон 3.9 (3.8 не подойдет для flash-attention)
- torch 2.5.1 (flash-attention скомпилирован лишь для нескольких версий торча)
- cuda toolkit 12.4+
## Фиксим поддержку русского языка в UTF8
## Генерация
в папке inference создаем 2 файла genre.txt и lyrics.txt
в genre пишем:
Проверяем что кодировка в файлах UTF8
в lyrics пишем: 3-4 коротких сегмента: 2 куплета + 1 припев. При 2-х сегментах, у меня почему-то не запускался инференс. Пример:
Генерацию по промпту:
Генерация по промпту + референсному аудио:
--run_n_segments - количество сегментов (куплетов + припевов)
--max_new_tokens - время песни в каждом сегменте. Длина песни если сегмента 2: 1000x2 = 20s, 3000 = 60s. Чем больше время, тем больше надо vram.
## Скорость и vram на 3090:
20s аудио - 12.5 GB (15 минут)
60s аудио - 15.6 GB (32 минуты)
## 8-12 GB VRAM и 3000 серия и nf4
Если у вас всего 8-12 GB попробуйте запустить модель в кванте nf4 (load_in_4bit=True). Особого падения качества пока не заметил. 10 секунд аудио будут занимать всего 6.6 GB VRAM. Запускать в gguf пока не имеет смысла, они будут автоматом конвертироваться в bf16, надо ждать нормальную реализацию гуфов для модели. На 2080 пока не запускается, flash attention похоже не поддерживается. Без него тоже можно, но будет медленнее и надо больше vram.
Для nf4 нужно установить:
pip install accelerate bitsandbytes
в infer.py измените строки 76-82 на:
Скорость на 3060: 10s = 11 минут.
примеры на английском: https://map-yue.github.io/
потестить (русского нет):
- (квоты хватит на 10+10 секунд песни, не ставьте длину больше 10 секунд - упадет по ошибке): https://huggingface.co/spaces/innova-ai/YuE-music-generator-demo
- (15 секунд, ждать очереди больше часа): https://huggingface.co/spaces/fffiloni/YuE
Языки: английский, китайский, японский, корейский, русский (с акцентом).
генерация:
- по жанру + тексту песни
- по референсному аудио + жанру + тексту песни (почти кавер, позволяет задать нужное направление)
- в fp16 весит 12.5 GB. в формате nf4 занимает всего 6.5 GB vram!
- на русском лучше генерирует мужской голос. В женских - сильный акцент.
## Установка под Windows (без wsl)
Нужны
- питон 3.9 (3.8 не подойдет для flash-attention)
- torch 2.5.1 (flash-attention скомпилирован лишь для нескольких версий торча)
- cuda toolkit 12.4+
conda create -n yue python=3.9
conda activate yue
pip install torch==2.5.1 torchvision torchaudio --index-url https://download.pytorch.org/whl/cu124
качаем файл flash_attn-2.7.1.post1+cu124torch2.5.1cxx11abiFALSE-cp39-cp39-win_amd64.whl
отсюда https://github.com/bdashore3/flash-attention/releases в папку, куда у вас идет установка
pip install flash_attn-2.7.1.post1+cu124torch2.5.1cxx11abiFALSE-cp39-cp39-win_amd64.whl
git lfs install
git clone https://github.com/multimodal-art-projection/YuE
cd YuE
pip install -r requirements.txt
cd inference/
git clone https://huggingface.co/m-a-p/xcodec_mini_infer
## Фиксим поддержку русского языка в UTF8
строку 120: with open(args.genre_txt) as f:
меняем на: with open(args.genre_txt, encoding="utf-8") as f:
строку 122: with open(args.lyrics_txt) as f:
меняем на: with open(args.lyrics_txt, encoding="utf-8") as f:
## Генерация
в папке inference создаем 2 файла genre.txt и lyrics.txt
в genre пишем:
vocal punk rock electric guitar male vocalПроверяем что кодировка в файлах UTF8
в lyrics пишем: 3-4 коротких сегмента: 2 куплета + 1 припев. При 2-х сегментах, у меня почему-то не запускался инференс. Пример:
Пластмассовый мир победил
...
[chorus]
Ооо - моя оборона
...
[verse]
...
Генерацию по промпту:
python infer.py --stage1_model m-a-p/YuE-s1-7B-anneal-en-cot --stage2_model m-a-p/YuE-s2-1B-general --genre_txt genre.txt --lyrics_txt lyrics.txt --run_n_segments 2 --stage2_batch_size 4 --output_dir ./output --cuda_idx 0 --max_new_tokens 1000Генерация по промпту + референсному аудио:
python infer.py --stage1_model m-a-p/YuE-s1-7B-anneal-en-icl --stage2_model m-a-p/YuE-s2-1B-general --genre_txt genre.txt --lyrics_txt lyrics.txt --run_n_segments 2 --stage2_batch_size 4 --output_dir ./output --cuda_idx 0 --audio_prompt_path Egor_Letov_-_Moya_oborona.mp3 --max_new_tokens 1000--run_n_segments - количество сегментов (куплетов + припевов)
--max_new_tokens - время песни в каждом сегменте. Длина песни если сегмента 2: 1000x2 = 20s, 3000 = 60s. Чем больше время, тем больше надо vram.
## Скорость и vram на 3090:
20s аудио - 12.5 GB (15 минут)
60s аудио - 15.6 GB (32 минуты)
## 8-12 GB VRAM и 3000 серия и nf4
Если у вас всего 8-12 GB попробуйте запустить модель в кванте nf4 (load_in_4bit=True). Особого падения качества пока не заметил. 10 секунд аудио будут занимать всего 6.6 GB VRAM. Запускать в gguf пока не имеет смысла, они будут автоматом конвертироваться в bf16, надо ждать нормальную реализацию гуфов для модели. На 2080 пока не запускается, flash attention похоже не поддерживается. Без него тоже можно, но будет медленнее и надо больше vram.
Для nf4 нужно установить:
pip install accelerate bitsandbytes
в infer.py измените строки 76-82 на:
model = AutoModelForCausalLM.from_pretrained(
stage1_model,
load_in_4bit=True,
torch_dtype=torch.bfloat16,
attn_implementation="flash_attention_2",
)
Скорость на 3060: 10s = 11 минут.
примеры на английском: https://map-yue.github.io/
потестить (русского нет):
- (квоты хватит на 10+10 секунд песни, не ставьте длину больше 10 секунд - упадет по ошибке): https://huggingface.co/spaces/innova-ai/YuE-music-generator-demo
- (15 секунд, ждать очереди больше часа): https://huggingface.co/spaces/fffiloni/YuE
Forwarded from DevFM
DevFM подкаст 3: Роли в ИТ-проекте (youtube / podster / yandex)
В часовом видеоподкасте мы обсудили роли в ИТ-проекте из ~25 человек, занятых разработкой крупного веб-сервиса со сложной бизнес областью. Бизнес аналитики, системные аналитики, тим лиды, разработчики – кто на ком стоял и чем все эти люди занимаются. Представлен достаточно высокоуровневый взгляд на команду, если вы в таком не участвовали – вам точно будет интересно. В конце обсуждаем, можно ли малой командой делать большие проекты и, наоборот, делать большой командой малые проекты.
Подкаст 2. Кто такой тимлид тимлидов
Подкаст 1. Ретроспектива силами команды разработки
#devfm #podcast #teamwork
В часовом видеоподкасте мы обсудили роли в ИТ-проекте из ~25 человек, занятых разработкой крупного веб-сервиса со сложной бизнес областью. Бизнес аналитики, системные аналитики, тим лиды, разработчики – кто на ком стоял и чем все эти люди занимаются. Представлен достаточно высокоуровневый взгляд на команду, если вы в таком не участвовали – вам точно будет интересно. В конце обсуждаем, можно ли малой командой делать большие проекты и, наоборот, делать большой командой малые проекты.
Подкаст 2. Кто такой тимлид тимлидов
Подкаст 1. Ретроспектива силами команды разработки
#devfm #podcast #teamwork
YouTube
DevFM podcast 3. Роли в ИТ-проекте
На больших проектах много ролей. Иногда непонятно, чем они все занимаются. На примере команды из ~25 человек, создающей некоторый сервис с нетривиальной логикой рассмотрим типичные роли: тимлид, техлид, project manager, бизнес аналитик, системный аналитик…
Forwarded from Data Blog
❤️ Привет, друзья!
🔅Новая библиотека, в этот раз для текстовых данных.
Библиотека: explabox, paper
Совместимость: pytorch, Keras, tensorflow (главное — формат onnx), scikit-learn
Ограничение: только текстовая модальность даных (датасеты Hf, pandas, numpy arrays)
Поддерживаемые методы:
1. LIME
2. KernelSHAP
3. Counterfactual/contrastive explanations [FoilTrees]
4. Local rule-based models
🔅 Ещё реализованы метрики: чувствительность (robustness, оценка того, как небольшие изменения влияют на объяснение), безопасность (security, например, если входные данные, содержащие определенные символы, приводят к сбою модели) и справедливости (fairness, например, оценка на специфических признака — страна происхождения, пол, раса или социально-экономический статус)
Также обновила в табличку (https://xai-table.streamlit.app/).
Чудесного вам вечера!
Ваш Дата-автор,копающийся в контенте о DeppSeek! 🐳
🔅Новая библиотека, в этот раз для текстовых данных.
Библиотека: explabox, paper
Совместимость: pytorch, Keras, tensorflow (главное — формат onnx), scikit-learn
Ограничение: только текстовая модальность даных (датасеты Hf, pandas, numpy arrays)
Поддерживаемые методы:
1. LIME
2. KernelSHAP
3. Counterfactual/contrastive explanations [FoilTrees]
4. Local rule-based models
🔅 Ещё реализованы метрики: чувствительность (robustness, оценка того, как небольшие изменения влияют на объяснение), безопасность (security, например, если входные данные, содержащие определенные символы, приводят к сбою модели) и справедливости (fairness, например, оценка на специфических признака — страна происхождения, пол, раса или социально-экономический статус)
Также обновила в табличку (https://xai-table.streamlit.app/).
Чудесного вам вечера!
Ваш Дата-автор,
GitHub
GitHub - MarcelRobeer/explabox: Explore/examine/explain/expose your model with the explabox!
Explore/examine/explain/expose your model with the explabox! - MarcelRobeer/explabox
Forwarded from Борис_ь с ml
2025 год для канала начался очень даже хорошо - он преодолел отметку 500 читателей! Спасибо вам, друзья!
Я невероятно рад, что мой интерес и взгляд на будущее информационных технологий разделяют еще столько людей. Для меня это теперь ответственно - рассказывать вам о том, что происходит в мире информационной безопасности и искусственного интеллекта. Поэтому наполнение канала постараюсь держать как минимум на заданной планке и впредь
И не откладывая в долгий ящик, я представляю вам, читатели, первую публикацию в этом году - хабр-статья про интерпретацию ИИ.
Тема меня очень заинтересовала давно, и сначала вылилась в подкаст в Музее Криптографии. Но я понял, что сам еще многое не рассказал вам и не показал, так что сел за статью. В ней я разбираюсь, чем отличается интерпретируемость и объяснимость, и, как всегда, привожу море ссылок. Приятного чтения)
#иб_для_ml
Please open Telegram to view this post
VIEW IN TELEGRAM
Хабр
Что такое интерпретируемость машинного обучения?
Насколько интерпретируемость важна для машинного обучения? Зачем она вообще нужна? Для чего она в информационной безопасности? Меня эти вопросы начали интересуют уже около полугода, и в фоновом режиме...
Forwarded from Заскуль питона (Data Science)
Как считать пенетрацию пользователей в продукте на SQL?
🎮 В сервисе у нас есть чарт, характеризующий количество пользователей в сервисе (MAU / DAU / WAU), мы смотрим за определенный промежуток времени количество пользователей. Этот график интуитивно понятен, есть практически во всех продуктах и является одной из тех метрик, которую отслеживают.
Тут достаточно понятно, берем группировку по дням / неделям / месяцам, считаем уникальных пользователей в приложении и готово!
❓ Пенетрация позволяет ответить на вопрос: "Сколько всего пользователей пользуются продуктом в динамике?". В сервисе есть старички, которые регулярно продукт используют и за время мы их учитываем несколько раз (по дням). Мы можем взять весь год и посмотреть сколько всего пользователей использовали фичу X и посчитать статично, найти долю и все. Но хочется понимать как инициативы влияют на абсолютные значения / доли относительно всех пользователей продукта до момента T.
⬆️ Выше представлен скрипт, который считает накопительно пользователей по дням, теперь мы можем это применить для ответа на вопрос: "Какой процент пользователей когда-либо использовал продукт на момент времени T?". Это нам может быть нужно для отслеживания доли использования от всей аудитории накопительно. Мы можем более явно отслеживать как наша база (в тотале) реагирует по дням, когда мы используем какие-то механики, например, или запускаем новые фичи
⬆️ Выше представлен код, как мы считае долю тех, кто использовал фичу относительно всех пользователей до момента T.
🐖 Используете ли вы пенетрацию для отслеживания доли относительно всех пользователей? Был ли этот пост полезен? Ставьте 100 🐳 и я выложу еще что-нибудь по этой тематике)
Тут достаточно понятно, берем группировку по дням / неделям / месяцам, считаем уникальных пользователей в приложении и готово!
WITH user_activity AS (
SELECT
user_id,
event_date,
DATE_TRUNC('week', event_date) AS week_start,
DATE_TRUNC('month', event_date) AS month_start
FROM user_events
WHERE event_date BETWEEN '2024-01-01' AND '2024-12-31'
)
SELECT
event_date,
COUNT(DISTINCT user_id) AS DAU,
COUNT(DISTINCT CASE WHEN event_date = week_start THEN user_id END) AS WAU,
COUNT(DISTINCT CASE WHEN event_date = month_start THEN user_id END) AS MAU
FROM user_activity
GROUP BY event_date
ORDER BY event_date;
WITH daily_users AS (
SELECT
event_date,
user_id
FROM user_events
WHERE event_date BETWEEN '2024-01-01' AND '2024-01-30'
),
date_series AS (
SELECT DISTINCT event_date
FROM daily_users
),
cumulative_users AS (
SELECT
d.event_date,
COUNT(DISTINCT u.user_id) AS cumulative_unique_users
FROM date_series d
LEFT JOIN daily_users u ON u.event_date <= d.event_date
GROUP BY d.event_date
ORDER BY d.event_date
)
SELECT * FROM cumulative_users;
WITH daily_feature_users AS (
SELECT
event_date,
user_id
FROM user_events
WHERE event_name = 'feature_x'
AND event_date BETWEEN '2024-01-01' AND '2024-01-30'
),
daily_total_users AS (
SELECT
event_date,
user_id
FROM user_events
WHERE event_date BETWEEN '2024-01-01' AND '2024-01-30'
),
date_series AS (
SELECT DISTINCT event_date
FROM daily_total_users
),
cumulative_feature_users AS (
SELECT
d.event_date,
COUNT(DISTINCT u.user_id) AS cumulative_feature_users
FROM date_series d
LEFT JOIN daily_feature_users u ON u.event_date <= d.event_date
GROUP BY d.event_date
ORDER BY d.event_date
),
cumulative_total_users AS (
SELECT
d.event_date,
COUNT(DISTINCT u.user_id) AS cumulative_total_users
FROM date_series d
LEFT JOIN daily_total_users u ON u.event_date <= d.event_date
GROUP BY d.event_date
ORDER BY d.event_date
)
SELECT
cfu.event_date,
cfu.cumulative_feature_users,
ctu.cumulative_total_users,
ROUND(100.0 * cfu.cumulative_feature_users / (ctu.cumulative_total_users, 0), 2) AS penetration_rate
FROM cumulative_feature_users cfu
JOIN cumulative_total_users ctu ON cfu.event_date = ctu.event_date
ORDER BY cfu.event_date;
Please open Telegram to view this post
VIEW IN TELEGRAM
Forwarded from Love. Death. Transformers.
Forwarded from ML Advertising
Проектируем платформу ставок с нуля? 💵
Сегодня займемся проектированием своей 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 хранилища и отвечает за выстапление счетов рекламодателю. На этапе трекинга в момент логирования события оплаты, сама оплата не происходит. Записанные события с биллингом аггрегируются, и рекламодателю выставляется счет на сумму, которая должна биться с бюджетом, который наша платформа открутила. Эта процедура делается раз в месяц или в квартал.
Сегодня займемся проектированием своей 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 хранилища и отвечает за выстапление счетов рекламодателю. На этапе трекинга в момент логирования события оплаты, сама оплата не происходит. Записанные события с биллингом аггрегируются, и рекламодателю выставляется счет на сумму, которая должна биться с бюджетом, который наша платформа открутила. Эта процедура делается раз в месяц или в квартал.
docs.prebid.org
About Prebid.js for Header Bidding
An overview of Prebid.js
Forwarded from Konstantin
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).
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).
Amazon
Build cost-effective RAG applications with Binary Embeddings in Amazon Titan Text Embeddings V2, Amazon OpenSearch Serverless,…
Today, we are happy to announce the availability of Binary Embeddings for Amazon Titan Text Embeddings V2 in Amazon Bedrock Knowledge Bases and Amazon OpenSearch Serverless. This post summarizes the benefits of this new binary vector support and gives you…