Research команда по Монетизационной эффективности Авито выкатила опенсорс-библиотеку Benchmark for Auto-bidding Task (BAT) для тестирования алгоритмов ставок в рекламе + научную статью по ней. Работа представлена на конференции The ACM Web Conference 2025.
Для начала определимся с периметром задач. Конкретно в этой работе авторы ограничились кликами, попаданием в ограничения по CPC и управлением открутки бюджета рекламной кампании (РК).
Были поставлены две цели:
- купить максимальное количество кликов на единицу открученного бюджета, т.е. максимизируем CTR, при ограничении на CPC
- обеспечить budget pacing, т.е. обеспечить равномерный расход бюджета без under/over delivery
➡️ Что по данным?
Боевые данные Авито анонимизированы и предоставленные по first-price (FP) аукциону с 10М аукционов и 9К РК и VCG с 1М аукционов и 2.5К РК за 2024 год. Данные агрегированы по часам и бакетам ставок. Далее буду рассматривать результаты конкретно для FP аукционов, поскольку именно они преобладают в программатике.
➡️ Какие эксперименты проводились?
Всего было 3 эксперимента
- Классический budget pacing. Замерялась средняя квадратичная ошибка (RMSE) попадания в финальный бюджет + количество кликов на единицу открученного бюджета
- CPC constraint. Таргет CPC искуственно занижался в 10 раз, чтобы проверить алгоритмы на сложности его достижения
- Click gain. Тест чисто на получение максимального количества кликов при фиксированном CPC
➡️ Что по алгоритмам?
В статье авторы рассмотрели 5 алгоритмов budget pacing/ CTR разной сложности
Линейный (ALM Adaptive Linear Model)
Самый простой в реализации: смотрим наклон кривой с двух предыдущих точек открученного бюджета и считаем новую ставку с учетом остатка. В тестах использовался больше, как бейзлайн для сравнения.
Traffic-aware PID (TA-PID)
Регулятор с обратной связью 3мя коэффами. Хорош тем, что прост в реализации и контролирует расход бюджета в соотвествии с профилем трафика (например за сутки). Budget pacing управляется PID регулятором, настроенном на историческом трафике. Стал лучшим по click gain. При этом в эксперименте на pacing показал себя хуже на равномерности открутки по RMSE, хотя выдал 2й результат по сумме кликов.
Model Predictive PID (M-PID)
Более сложная версия PID регулятора, где можно явно реализовать ограничения на CPC и максимизацию CTR в дополнении к pacing'у. Хорошо отработал по открутке бюджета показав 2й результат по RMSE и близкое количество кликов с TA-PID и стал лучшим в тесте на попадание в ограничения по CPC относительно BROI (в эксперименте на CPC тестировались всего 2 модели).
Mystique
Продовый алгоритм от Yahoo заточен чисто под budget pacing. Он контролирует равномерное расходование бюджета с обратной связью тоже на основе времени до конца РК и суммы неизрасходованного бюджета. При этом ограничений на CPC не накладывается. В эксперименте на budget pacing ожидаемо стал лучшим, хотя кликов пропустил в 2 раза меньше остальных. Считаю, что есть риски получить на проде заниженный CTR и закупку более дорогого трафика, когда это не нужно.
BROI (Budget + ROI Constraints)
Алгоритм, который теоретически гарантирует >50% от оптимума по CPC, который был применен в качестве ROI. На боевых данных Авито выдал мало кликов и высокий CPC.
Из всех алгоритмов я бы выбрал M-PID по совокупному результату с 3х тестов
- достаточное попадание в бюджет на pacing'е
- высокий click gain с небольшим отставанием от TA-PID
- низкий CPC
По реализациии ввиду добавления ограничений на CPC, нужно навесить linprog вдобавок к PID регулятору.
➡️ Мнение по работе?
На мой взгляд библиотека отличная. Авторы проделали большую работу и по сбору данных, и в формулировке мат. задачи, и в экспериментах над разными алгоритмами.
В целом этот бенчмарк подойдет и для других задач кроме pacing'а и максимизации CTR, CVR. Его можно использовать и для viewability, completion, маржинальности в аукционах header bidding etc. Код библиотеки адаптирован не только под PID регуляторы, но подойдет для разных типов биддеров.
Проходите по ссылке и накидайте звездочек 🌟 в репозиторий!
Для начала определимся с периметром задач. Конкретно в этой работе авторы ограничились кликами, попаданием в ограничения по CPC и управлением открутки бюджета рекламной кампании (РК).
Были поставлены две цели:
- купить максимальное количество кликов на единицу открученного бюджета, т.е. максимизируем CTR, при ограничении на CPC
- обеспечить budget pacing, т.е. обеспечить равномерный расход бюджета без under/over delivery
➡️ Что по данным?
Боевые данные Авито анонимизированы и предоставленные по first-price (FP) аукциону с 10М аукционов и 9К РК и VCG с 1М аукционов и 2.5К РК за 2024 год. Данные агрегированы по часам и бакетам ставок. Далее буду рассматривать результаты конкретно для FP аукционов, поскольку именно они преобладают в программатике.
➡️ Какие эксперименты проводились?
Всего было 3 эксперимента
- Классический budget pacing. Замерялась средняя квадратичная ошибка (RMSE) попадания в финальный бюджет + количество кликов на единицу открученного бюджета
- CPC constraint. Таргет CPC искуственно занижался в 10 раз, чтобы проверить алгоритмы на сложности его достижения
- Click gain. Тест чисто на получение максимального количества кликов при фиксированном CPC
➡️ Что по алгоритмам?
В статье авторы рассмотрели 5 алгоритмов budget pacing/ CTR разной сложности
Линейный (ALM Adaptive Linear Model)
Самый простой в реализации: смотрим наклон кривой с двух предыдущих точек открученного бюджета и считаем новую ставку с учетом остатка. В тестах использовался больше, как бейзлайн для сравнения.
Traffic-aware PID (TA-PID)
Регулятор с обратной связью 3мя коэффами. Хорош тем, что прост в реализации и контролирует расход бюджета в соотвествии с профилем трафика (например за сутки). Budget pacing управляется PID регулятором, настроенном на историческом трафике. Стал лучшим по click gain. При этом в эксперименте на pacing показал себя хуже на равномерности открутки по RMSE, хотя выдал 2й результат по сумме кликов.
Model Predictive PID (M-PID)
Более сложная версия PID регулятора, где можно явно реализовать ограничения на CPC и максимизацию CTR в дополнении к pacing'у. Хорошо отработал по открутке бюджета показав 2й результат по RMSE и близкое количество кликов с TA-PID и стал лучшим в тесте на попадание в ограничения по CPC относительно BROI (в эксперименте на CPC тестировались всего 2 модели).
Mystique
Продовый алгоритм от Yahoo заточен чисто под budget pacing. Он контролирует равномерное расходование бюджета с обратной связью тоже на основе времени до конца РК и суммы неизрасходованного бюджета. При этом ограничений на CPC не накладывается. В эксперименте на budget pacing ожидаемо стал лучшим, хотя кликов пропустил в 2 раза меньше остальных. Считаю, что есть риски получить на проде заниженный CTR и закупку более дорогого трафика, когда это не нужно.
BROI (Budget + ROI Constraints)
Алгоритм, который теоретически гарантирует >50% от оптимума по CPC, который был применен в качестве ROI. На боевых данных Авито выдал мало кликов и высокий CPC.
Из всех алгоритмов я бы выбрал M-PID по совокупному результату с 3х тестов
- достаточное попадание в бюджет на pacing'е
- высокий click gain с небольшим отставанием от TA-PID
- низкий CPC
По реализациии ввиду добавления ограничений на CPC, нужно навесить linprog вдобавок к PID регулятору.
➡️ Мнение по работе?
На мой взгляд библиотека отличная. Авторы проделали большую работу и по сбору данных, и в формулировке мат. задачи, и в экспериментах над разными алгоритмами.
В целом этот бенчмарк подойдет и для других задач кроме pacing'а и максимизации CTR, CVR. Его можно использовать и для viewability, completion, маржинальности в аукционах header bidding etc. Код библиотеки адаптирован не только под PID регуляторы, но подойдет для разных типов биддеров.
Проходите по ссылке и накидайте звездочек 🌟 в репозиторий!
GitHub
GitHub - avito-tech/bat-autobidding-benchmark
Contribute to avito-tech/bat-autobidding-benchmark development by creating an account on GitHub.
🔥10❤2👍2
Server Side Bidding Part #1
В программатике кроме вэба (баннерки, натива, видео) и inApp есть большое количество трафика (CTV, InStream, DOOH, а значит и потенциальной выручки), который не продать через классический client side Prebid.js. Многие вендоры в такие интеграции и не лезут из-за сложностей реализации аукциона под трафик. Но мы не ищем легких путей и рассмотрим, как работает server-side биддинг со стороны внешнего аукциона SSP
Сегодня начнем с того, какие бывают Server Side Bidding провайдеры под разный тип трафика
Для сравнения вспомним, как работает client side bidding через Prebid.js (раз, два, три). Паблишер прописывает JS код в шапку страницы, который импортирует библиотеку пребида. Внутри себя Prebid.js содержит core (ядро с базовой логикой аукциона, блоклистами, фильтрацией и разрешением аукциона), адаптеры SSP-покупателей трафика (каждый по своему выбирает поля из RTB запроса и кастует json на свою собственную ручку). Все операции выполняются в браузере пользователя на его собственной машине, откуда возникает проблема задержки аукциона, в результате которой биды SSP, которые не обработались браузером отлетают, снижая потенциальную выручку паблишера, или креатив загружается на столько поздно, что пользователь его не увидит.
Что такое Server Side?
В отличие от Client Side разрешение аукциона происходит не в браузере пользователя, а на сервере провайдера под конкретный инвентарь. Для баннер/видео - это реализация Prebid Server, для InStream Google Authorized Buyers (GAB), для CTV - Publica, SpringServe, FreeWheel
🌐 Web: Prebid Server
Вся логика опроса SSP через их адаптеры на пребиде, фильтрации и проведение аукциона исполняется на серваках провайдеров, которые имплементировали Prebid Server. Самы крупные - это Magnite (бывший Rubicon) и Pubstack. Поскольку аукцион разрешается не на машине пользователя, и не требуется его коммуницировать в Google Ad Manager (кроме трекинга), то проблема времени аукциона уходит. Также лично мне, как разрабу кодовая база, удобность написания модулей, покрытие тестами в Prebid Server Java показались гораздо лучшими, чем в Prebid.js.
🎞 Instream: Google Authorized Buyers
Ad Exchange Гугла заточенный под инстрим. Вместо подключения с каждым отдельным паблишером SSP интегрируется с AB, т.е. на всех назначается единый publisher_id, website_id, placement_id, относящийся к AB. Запрос на ставку генерируется видео плеером через IMA SDK и отправляется на сервер GAB. Тот в свою очередь обогащает запрос и опрашивает биддеры SSP. Далее все работает, как в вэбе: прием ответа от биддеров, разрешеие аукциона, отправка win-notice победителю с запросом VAST tag, получаение креатива в VAST tag и передача его в видеоплеер и сшивка с потоком.
📺 CTV: Publica, SpringServe, FreeWheel
CTV провайдеры используют данные, передаваемые на их сервер телевизором, подключенным к интернету. Данные передаются провайдеру по API производителя устройств например Samsung Tyzen, LG WebOS. Это нужно, чтобы извлечь User Agent и bundle_id (айдишник платформы), и чтобы креативы, передаваемые в VAST tag были совместимы с конкретным устройством. Здесь, также, как и на Prebid паблишер напрямую интегрирован с SSP, и каждый adunit имеет свой placement_id.
Далее разберем более подробно имплементацию внутри SSP: протоколы под bid request/ response, обогащение, privacy, расчет bid price, win-notice
В программатике кроме вэба (баннерки, натива, видео) и inApp есть большое количество трафика (CTV, InStream, DOOH, а значит и потенциальной выручки), который не продать через классический client side Prebid.js. Многие вендоры в такие интеграции и не лезут из-за сложностей реализации аукциона под трафик. Но мы не ищем легких путей и рассмотрим, как работает server-side биддинг со стороны внешнего аукциона SSP
Сегодня начнем с того, какие бывают Server Side Bidding провайдеры под разный тип трафика
Для сравнения вспомним, как работает client side bidding через Prebid.js (раз, два, три). Паблишер прописывает JS код в шапку страницы, который импортирует библиотеку пребида. Внутри себя Prebid.js содержит core (ядро с базовой логикой аукциона, блоклистами, фильтрацией и разрешением аукциона), адаптеры SSP-покупателей трафика (каждый по своему выбирает поля из RTB запроса и кастует json на свою собственную ручку). Все операции выполняются в браузере пользователя на его собственной машине, откуда возникает проблема задержки аукциона, в результате которой биды SSP, которые не обработались браузером отлетают, снижая потенциальную выручку паблишера, или креатив загружается на столько поздно, что пользователь его не увидит.
Что такое Server Side?
В отличие от Client Side разрешение аукциона происходит не в браузере пользователя, а на сервере провайдера под конкретный инвентарь. Для баннер/видео - это реализация Prebid Server, для InStream Google Authorized Buyers (GAB), для CTV - Publica, SpringServe, FreeWheel
🌐 Web: Prebid Server
Вся логика опроса SSP через их адаптеры на пребиде, фильтрации и проведение аукциона исполняется на серваках провайдеров, которые имплементировали Prebid Server. Самы крупные - это Magnite (бывший Rubicon) и Pubstack. Поскольку аукцион разрешается не на машине пользователя, и не требуется его коммуницировать в Google Ad Manager (кроме трекинга), то проблема времени аукциона уходит. Также лично мне, как разрабу кодовая база, удобность написания модулей, покрытие тестами в Prebid Server Java показались гораздо лучшими, чем в Prebid.js.
🎞 Instream: Google Authorized Buyers
Ad Exchange Гугла заточенный под инстрим. Вместо подключения с каждым отдельным паблишером SSP интегрируется с AB, т.е. на всех назначается единый publisher_id, website_id, placement_id, относящийся к AB. Запрос на ставку генерируется видео плеером через IMA SDK и отправляется на сервер GAB. Тот в свою очередь обогащает запрос и опрашивает биддеры SSP. Далее все работает, как в вэбе: прием ответа от биддеров, разрешеие аукциона, отправка win-notice победителю с запросом VAST tag, получаение креатива в VAST tag и передача его в видеоплеер и сшивка с потоком.
📺 CTV: Publica, SpringServe, FreeWheel
CTV провайдеры используют данные, передаваемые на их сервер телевизором, подключенным к интернету. Данные передаются провайдеру по API производителя устройств например Samsung Tyzen, LG WebOS. Это нужно, чтобы извлечь User Agent и bundle_id (айдишник платформы), и чтобы креативы, передаваемые в VAST tag были совместимы с конкретным устройством. Здесь, также, как и на Prebid паблишер напрямую интегрирован с SSP, и каждый adunit имеет свой placement_id.
Далее разберем более подробно имплементацию внутри SSP: протоколы под bid request/ response, обогащение, privacy, расчет bid price, win-notice
🔥5👍4
Горячие новости! 🔥
Мои поздравления, в ТГ появился формат рекламы Banner in Video. Но это все еще не instream, как в YouTube. Будет обычный overlay баннер с текстом поверх основного видео
- Креатив запускается на 5й секунде после начала видео
- Формат 9 сек non-skippable и далее skippable до 30 сек с автоматическим закрытием
- Frequency cap: 120 сек, т.е. следующий показ возможен не ранее, чем через 120 сек после закрытия слота
- Также возможен таргетинг на сегменты аудитории. Таргетинг по каналам, ботам, поиску пока не доступен
- Базовый CPM начинается от 1 евро. Добавление эмодзи дает +20% CPM, а иконки посадочной страницы + 30% CPM
Если в будущем к нему еще прикрутить pixel tag для отслеживания конверсий, который ТГ зарелизил 2 месяца назад, то можно замерять не только брендинг, но еще и перформанс до кучи
Мои поздравления, в ТГ появился формат рекламы Banner in Video. Но это все еще не instream, как в YouTube. Будет обычный overlay баннер с текстом поверх основного видео
- Креатив запускается на 5й секунде после начала видео
- Формат 9 сек non-skippable и далее skippable до 30 сек с автоматическим закрытием
- Frequency cap: 120 сек, т.е. следующий показ возможен не ранее, чем через 120 сек после закрытия слота
- Также возможен таргетинг на сегменты аудитории. Таргетинг по каналам, ботам, поиску пока не доступен
- Базовый CPM начинается от 1 евро. Добавление эмодзи дает +20% CPM, а иконки посадочной страницы + 30% CPM
Если в будущем к нему еще прикрутить pixel tag для отслеживания конверсий, который ТГ зарелизил 2 месяца назад, то можно замерять не только брендинг, но еще и перформанс до кучи
🔥6👍1
Как детектировать битые креативы в header bidding?
В Header Bidding аукционе SSP платит паблишеру в момент своей победы (т.н. `ssp-hb-win`). В этот момент креатив еще только пересылается в составе VAST tag паблишеру. Есть риск, что креатив не отрендерится, и показа не произойдет, т.е. SSP, заплатив паблишеру, не получит оплату от деманда.
Примеры причин битого креатива:
- открутчик забыл удалить из URL спец символы
- в формате креатива ошибка и он не подходит под доступнык форматы adunit'а (слота)
➡️ Формулируем задачу
Отсюда возникает задача детектить потенциально битые креативы до момента ставки SSP в аукционе header bidding'а. При чем делать это нужно в реал тайме, между моментом ставки от DSP во внутреннем и ставкой SSP во внешнем аукционе
Самый простой способ - это собрать статы по кретивам на достаточно коротком скользящем окне (например 15 мин) по двум ивентам. В случае, если креатив битый, паблишер логирует событие error_vast, а SSP отправляет в ответе HTTP status-code 4999005, тогда как базовое события биллинга SSP - это
Порог фильтрации можно брать, исходя из особенностей трафика.
➡️ Как это реализовать?
Все события из биддера пишутся в очередь собщений, которая реализована на Kafka, т.е. в Kafka топик. Чтобы не скатится в обработку данных батчами за длительные периоды времени, и сделать фильтрацию более реактивной, на выходе из топика мы ставим Apache Flink стриминг джобу, которая будет консьюмить сообщения из топика
На Flink джобе мы наращиваем счетчики обоих ивентов по связкам (`creative_id`,
Далее на стороне биддера, мы разрешаем внутренний аукцион, и от DSP к нам приходит URL креатива с
АБтестировтаь такую фичу можно, делая рандомный сплит по (`user_id`,
В Header Bidding аукционе SSP платит паблишеру в момент своей победы (т.н. `ssp-hb-win`). В этот момент креатив еще только пересылается в составе VAST tag паблишеру. Есть риск, что креатив не отрендерится, и показа не произойдет, т.е. SSP, заплатив паблишеру, не получит оплату от деманда.
Примеры причин битого креатива:
- открутчик забыл удалить из URL спец символы
- в формате креатива ошибка и он не подходит под доступнык форматы adunit'а (слота)
➡️ Формулируем задачу
Отсюда возникает задача детектить потенциально битые креативы до момента ставки SSP в аукционе header bidding'а. При чем делать это нужно в реал тайме, между моментом ставки от DSP во внутреннем и ставкой SSP во внешнем аукционе
Самый простой способ - это собрать статы по кретивам на достаточно коротком скользящем окне (например 15 мин) по двум ивентам. В случае, если креатив битый, паблишер логирует событие error_vast, а SSP отправляет в ответе HTTP status-code 4999005, тогда как базовое события биллинга SSP - это
ssp-hb-win. Тогда условие на фильтрацию данного креатива и то, ответит ли SSP ставкой в аукционе, принимает вид
error_vast_rate = nb_error_vast / nb_ssp_hb_win > threshold
Порог фильтрации можно брать, исходя из особенностей трафика.
➡️ Как это реализовать?
Все события из биддера пишутся в очередь собщений, которая реализована на Kafka, т.е. в Kafka топик. Чтобы не скатится в обработку данных батчами за длительные периоды времени, и сделать фильтрацию более реактивной, на выходе из топика мы ставим Apache Flink стриминг джобу, которая будет консьюмить сообщения из топика
На Flink джобе мы наращиваем счетчики обоих ивентов по связкам (`creative_id`,
campaign_id, dsp_id). Далее раз в 15 мин наращиваем счетчики nb_error_vast, nb_ssp_hb_win на связку и пишем в NoSQL БД например Cassandra с помощью gaia-cassandra SDKДалее на стороне биддера, мы разрешаем внутренний аукцион, и от DSP к нам приходит URL креатива с
creative_id. При записи таблица в Кассандре обновляется в реал-тайм, запросы к ней также исполняются быстро, поэтому можно запрашивать счетчики по связке креатива creative_id и DSP dsp_id, посчитать error_vast_rate и фильтровать по порогу из конфига SSP до отправки его ставкиАБтестировтаь такую фичу можно, делая рандомный сплит по (`user_id`,
auction_id),и замеряя метрики nb_error_vast, publisher_cogs, margin с/без фильтрации🔥3👍1
Server Side Bidding Part #2
Это вторая часть серии по server side bidding'у (SSB). В предыдущем посте мы разобрались, что это такое, и какие бывают основные провайдеры. Сегодня разберем подробней имплементацию на стороне SSP
SSP принимает бид реквест на
На основе полей app, site, device_type, native, video определяем тип интеграции: instream, native или CTV
Далее проверяем реквест на валидность, прогоняя его через фильтры например
Создаем объект
DSP на своей стороне перед отправкой ставки обогащает запрос данными по формату креатива, например для видео
Дальше идет ответ DSP ставкой. Создается RTB ответ, который включает
-
-
-
Выигравшей DSP отправляется win-notice по внутреннему аукциону
Далее SSP отвечает ставкой в публичном HB аукционе ценой, рассчитываемой по формуле
Если SSP этот аукцион выигрывает, то на него приходит
Здесь в поле data находится protobuf файл, содержащий ивенты, необходимые для трекинга:
Далее провайдер выгружает креатив из DSP через VAST URL.
Это вторая часть серии по server side bidding'у (SSB). В предыдущем посте мы разобрались, что это такое, и какие бывают основные провайдеры. Сегодня разберем подробней имплементацию на стороне SSP
SSP принимает бид реквест на
{ssb-router}/bid-request. Каждый SSB провайдер содержит свой роутер и формат (Google Protobuf для Authorized Buyers и JSON для Publica, SpringServe, FreeWheel)На основе полей app, site, device_type, native, video определяем тип интеграции: instream, native или CTV
Далее проверяем реквест на валидность, прогоняя его через фильтры например
MissingIpFilter, NonUsdBidFloorFilter, InvalidVideoDataFilterСоздаем объект
SSPContext.Request, который далее обогащается фичами. Сначала записываем floor price. Далее делаем cookie sync для пользователя (чтобы извлечь его сегменты), если он дал согласие по GDPR или CCPA. Также фильтруем фродовый трафик. Формируем из SSPContext.Request RTB запрос и отправляем его в DSP. На каждый показ формируем отдельный запрос. DSP на своей стороне перед отправкой ставки обогащает запрос данными по формату креатива, например для видео
bit_rate, duration, а для InApp платформа и bundle_id. Также ищет подходящий креатив и назначает ставку по своим внутренним правиламДальше идет ответ DSP ставкой. Создается RTB ответ, который включает
-
bid.nurl для трекинга URL SSP-
bid.adm для VAST с win-notice-
bid.price со значением ставкиВыигравшей DSP отправляется win-notice по внутреннему аукциону
Далее SSP отвечает ставкой в публичном HB аукционе ценой, рассчитываемой по формуле
sspPrice = max(floor, winningDspPrice x (1 - margin) - fees)
Если SSP этот аукцион выигрывает, то на него приходит
win-notice. Win-notice URL HB c query params может выглядеть следующим образом
https://ssp.com/{ssb-provider-router}/win-notice?data={protobuf_in_base64}&clearingPrice={encrypted_price}
Здесь в поле data находится protobuf файл, содержащий ивенты, необходимые для трекинга:
ssp_hb_win, hb_slot_available. Этот protobuf закодирован в стрингу по base64Далее провайдер выгружает креатив из DSP через VAST URL.
Telegram
ML Advertising
Server Side Bidding Part #1
В программатике кроме вэба (баннерки, натива, видео) и inApp есть большое количество трафика (CTV, InStream, DOOH, а значит и потенциальной выручки), который не продать через классический client side Prebid.js. Многие вендоры…
В программатике кроме вэба (баннерки, натива, видео) и inApp есть большое количество трафика (CTV, InStream, DOOH, а значит и потенциальной выручки), который не продать через классический client side Prebid.js. Многие вендоры…
🔥5❤2👍1
Сегодня разберем InStream формат
Что такое Instream?
Это видео, которое играет до/ во время/ после основного потока видео контента (pre- / mid- / post-roll) например на YouTube. Ролики могут быть длительностью 5-30 сек с/ без возможности пропуска
➡️ Как интегрировать InStream в SSP?
Инстрим может быть настроен
- под разную среду (Web Desktop, Mobile, InApp SDK, AMP etc.)
- и под разные каналы доставки (Open Exchange, DealID)
Фильтрация инстрим слотов происходит на стороне аукциона SSP аналогично другим форматам. По таргетингу SSP передает данные по IP, User-Agent, geo, device, OS. Также передаются метаданные слота startdelay например 0 (pre-roll), 15 (mid-roll), -1 (post-roll)
Также SSP должна поддерживать third-party web видеоплеер (Video.js, ExoPlayer etc.), чтобы доставлять совместимый креатив. Видеоплеер инициирует VAST запрос к SSP, который в свою очередь генерирует VAST.xml с нужным креативом и трекинг-ивентами (start, progress, midpoint, complete, skip etc.)
➡️ Что по бизнес импакту?
У инстрима более узкий охват, чем у обычного вэба, но эффективен для аудитории, активно просматривающей видео, и лучше вовлекает в просмотр (это особенно верно для non-skippable видео). Из меньшего охвата могут быть ограничения на таргетинг. Но при этом с технической точки зрения встроить инстрим можно в любой сайт, где установлен видеоплеер
Что такое Instream?
Это видео, которое играет до/ во время/ после основного потока видео контента (pre- / mid- / post-roll) например на YouTube. Ролики могут быть длительностью 5-30 сек с/ без возможности пропуска
➡️ Как интегрировать InStream в SSP?
Инстрим может быть настроен
- под разную среду (Web Desktop, Mobile, InApp SDK, AMP etc.)
- и под разные каналы доставки (Open Exchange, DealID)
Фильтрация инстрим слотов происходит на стороне аукциона SSP аналогично другим форматам. По таргетингу SSP передает данные по IP, User-Agent, geo, device, OS. Также передаются метаданные слота startdelay например 0 (pre-roll), 15 (mid-roll), -1 (post-roll)
Также SSP должна поддерживать third-party web видеоплеер (Video.js, ExoPlayer etc.), чтобы доставлять совместимый креатив. Видеоплеер инициирует VAST запрос к SSP, который в свою очередь генерирует VAST.xml с нужным креативом и трекинг-ивентами (start, progress, midpoint, complete, skip etc.)
➡️ Что по бизнес импакту?
У инстрима более узкий охват, чем у обычного вэба, но эффективен для аудитории, активно просматривающей видео, и лучше вовлекает в просмотр (это особенно верно для non-skippable видео). Из меньшего охвата могут быть ограничения на таргетинг. Но при этом с технической точки зрения встроить инстрим можно в любой сайт, где установлен видеоплеер
❤3👍3🔥3
Интересные процессы по развитию ecomm'ом своих рекламных платформ и ухода от монополии Гугла, на которые стоит обратить внимание
Forwarded from Digital Marketing Club Russia
Amazon остановил всю рекламу в Google Shopping
С 21 по 23 июля доля показов Amazon в Google Shopping снизилась до 0%:
- США: ~60% -> 0%
- Великобритания: ~55% -> 0%
- Германия: ~38% -> 0%
Тут два важных тренда:
- Перетекание товарных поисковых запросов из поиска в маркетплейсы
- Развитие маркетплейсами своих рекламных платформ
И тут позиция Amazon понятно - он уже может позволить себе не тратить деньги на Google, а улучшить свою unit-экономику и инвестировать в развитие своей собственной рекламной платформы.
Amazon уже снижал в мае бюджеты на Google Shopping в США на 50% в мае. Теперь решили сделать более радикальный тест. Но тренд уже понятен.
@dmcrus
С 21 по 23 июля доля показов Amazon в Google Shopping снизилась до 0%:
- США: ~60% -> 0%
- Великобритания: ~55% -> 0%
- Германия: ~38% -> 0%
Тут два важных тренда:
- Перетекание товарных поисковых запросов из поиска в маркетплейсы
- Развитие маркетплейсами своих рекламных платформ
И тут позиция Amazon понятно - он уже может позволить себе не тратить деньги на Google, а улучшить свою unit-экономику и инвестировать в развитие своей собственной рекламной платформы.
Amazon уже снижал в мае бюджеты на Google Shopping в США на 50% в мае. Теперь решили сделать более радикальный тест. Но тренд уже понятен.
@dmcrus
🔥3❤2👍2
CCPA
Сегодня поговорим про user privacy в рекламе. Начнем с California Consumer Privacy Act (или CCPA). Это закон о защите прав пользователей в US, который регулирует продажу или передачу их персональных данных
➡️ В чем основное отличие от GDPR?
GDPR = Privacy by default, т.е. пользователь должен сделать opt-in, а согласие по умолчанию запрещено. В CCPA идут от обратного по opt-out: данные собираются по умолчанию, но пользователь может отказаться от их продажи или передачи
➡️ Кто попадает под CCPA?
CCPA позволяет пользователям из US видеть информацию о себе, сохраненную вендором а также список third-party, с которыми платформа делится его данными. При этом интересно, что не все платформы подпадают под CCPA. Для этого нужно выполнить несколько условий
- годовая выручка >25M usd
- пользовательская база >50k
- >50% дохода генерится от персональных данных
SSP обрабатывают персональные данные (IDFA для Apple/ AAID для Android, cookies для вэб link) для таргетинга, и если попадают по критериям, то еще до кучи должны соблюдать CCPA
➡️ Что содержится в строке CCPA?
Разберем, что закодировано в consent string CCPA. Для примера возьмем 1YYN:
- 1: IAB spec version number
- Y: explicit notice to opt-out, были ли предоставлен notice и возможность opt-out. Если да, то запрещается установка новых cookie
- Y: opt-out sale, пользователь отказался от продажи своих данных
- N: является ли паблишер подписантом Limited Service Provider Agreement (LSPA)
➡️ Как реализуется в SSP?
На стороне SSP логика CCPA реализуется через consent string в запросе на ставку. Предварительно паблишер собирает согласие на сайте и генерит consent string. SSP получает ее через Prebid или в составе query param при вызове Google Pixel. Далее после получения consent string SSP вставляет его в строчку us_privacy в OpenRTB запрос для внутреннего аукциона
Сегодня поговорим про user privacy в рекламе. Начнем с California Consumer Privacy Act (или CCPA). Это закон о защите прав пользователей в US, который регулирует продажу или передачу их персональных данных
➡️ В чем основное отличие от GDPR?
GDPR = Privacy by default, т.е. пользователь должен сделать opt-in, а согласие по умолчанию запрещено. В CCPA идут от обратного по opt-out: данные собираются по умолчанию, но пользователь может отказаться от их продажи или передачи
➡️ Кто попадает под CCPA?
CCPA позволяет пользователям из US видеть информацию о себе, сохраненную вендором а также список third-party, с которыми платформа делится его данными. При этом интересно, что не все платформы подпадают под CCPA. Для этого нужно выполнить несколько условий
- годовая выручка >25M usd
- пользовательская база >50k
- >50% дохода генерится от персональных данных
SSP обрабатывают персональные данные (IDFA для Apple/ AAID для Android, cookies для вэб link) для таргетинга, и если попадают по критериям, то еще до кучи должны соблюдать CCPA
➡️ Что содержится в строке CCPA?
Разберем, что закодировано в consent string CCPA. Для примера возьмем 1YYN:
- 1: IAB spec version number
- Y: explicit notice to opt-out, были ли предоставлен notice и возможность opt-out. Если да, то запрещается установка новых cookie
- Y: opt-out sale, пользователь отказался от продажи своих данных
- N: является ли паблишер подписантом Limited Service Provider Agreement (LSPA)
➡️ Как реализуется в SSP?
На стороне SSP логика CCPA реализуется через consent string в запросе на ставку. Предварительно паблишер собирает согласие на сайте и генерит consent string. SSP получает ее через Prebid или в составе query param при вызове Google Pixel. Далее после получения consent string SSP вставляет его в строчку us_privacy в OpenRTB запрос для внутреннего аукциона
State of California - Department of Justice - Office of the Attorney General
California Consumer Privacy Act (CCPA)
Updated on March 13, 2024 The California Consumer Privacy Act of 2018 (CCPA) gives consumers more control over the personal information that businesses collect about them and the CCPA regulations
🔥3❤1👍1
Что нужно знать о монетизации в рекламе? 💵
Все что вы хотели узнать, но боялись спросить про монетизацию инвентаря в программатике, теперь вы можете найти в канале Ad Cops. Его ведет AdOps менеджер Денис Рубежанский
Что вы найдете на канале?
Гайды и разборы кода адаптеров интеграций на Adfox и Prebid:
- Vibe-coding глазами AdOps специалиста. Как сделать обертку для Adfox с разными форматами и прикрутить поддержку Header Bidding?
- Разбираемся с баннерами по-умолчанию на Adfox: заглушки в РСЯ и сбор статистик adserver'ом
- Платный Adfox: почему, и что с этим делать?
Для AdOps специалистов, менеджеров по рекламным размещениям, специалистов по монетизации, менеджеров SSP регулярно размещаются вакансии (примеры раз, два, три)
В общем, рекомендую обратить внимание на Ad Cops. Хочется, чтобы такого контента в русскоязычном АдТехе было больше!
Все что вы хотели узнать, но боялись спросить про монетизацию инвентаря в программатике, теперь вы можете найти в канале Ad Cops. Его ведет AdOps менеджер Денис Рубежанский
Что вы найдете на канале?
Гайды и разборы кода адаптеров интеграций на Adfox и Prebid:
- Vibe-coding глазами AdOps специалиста. Как сделать обертку для Adfox с разными форматами и прикрутить поддержку Header Bidding?
- Разбираемся с баннерами по-умолчанию на Adfox: заглушки в РСЯ и сбор статистик adserver'ом
- Платный Adfox: почему, и что с этим делать?
Для AdOps специалистов, менеджеров по рекламным размещениям, специалистов по монетизации, менеджеров SSP регулярно размещаются вакансии (примеры раз, два, три)
В общем, рекомендую обратить внимание на Ad Cops. Хочется, чтобы такого контента в русскоязычном АдТехе было больше!
Telegram
Ad Cops - монетизация и реклама
Работаю AdOps, пишу про новости Adtech, делюсь своими мыслями по монетизации.
Пишу в основном про РСЯ, Adsense/Adx, Header Bidding, RTB и Programmatic.
Ламповый чатик - https://t.me/adCops_chat
______________________________
Контакты - @grandma_killa
Пишу в основном про РСЯ, Adsense/Adx, Header Bidding, RTB и Programmatic.
Ламповый чатик - https://t.me/adCops_chat
______________________________
Контакты - @grandma_killa
❤2👍1🔥1
Как (не) положить сервер мониторинга, при большом количестве данных?
Одно время для мониторинга платформы мы использовали Graphite сервера. Все дашборды на Grafan'е, отображающие состояние SSP (бизнес метрики, сервисы, ML модели, инфра etc.) забирали данные с них. По мере роста продуктовых команд, каждая из них старалась отсылать все большее количество метрик. Это в итоге привело к тому, что CPU сервера стал перегружаться при частой обновлении дашбордов. Особенно это касается сложных запросов для бордов на Графане
➡️ В чем проблема?
На Graphite серверах данные закэшированы. Реализации кэшей страдали от отсутствия индексации метрик по времени, т.е. при запросе мы сканируем все файлы без указания временного интервала
Например, запрос
- первый wildcard * : IP адрес интсанса
- второй * : категория, которая может принимать 100+ значений
Т.е. если есть 100 инстансов и 100 категорий, то мы получаем 10k путей метрик, которые будут накапливаться при частых обновлениях
➡️ Как решили?
Применили быстрое архивирование (fast archiving). Переносим пути неактивных метрик в архив после того, как они перестали отправляться от инстанса (например 24 часа). На дашборда отображаются только живые метрики. Как результат, теперь Graphite сервера могут справляться с большим количество запросов с пиковыми нагрузками
Одно время для мониторинга платформы мы использовали Graphite сервера. Все дашборды на Grafan'е, отображающие состояние SSP (бизнес метрики, сервисы, ML модели, инфра etc.) забирали данные с них. По мере роста продуктовых команд, каждая из них старалась отсылать все большее количество метрик. Это в итоге привело к тому, что CPU сервера стал перегружаться при частой обновлении дашбордов. Особенно это касается сложных запросов для бордов на Графане
➡️ В чем проблема?
На Graphite серверах данные закэшированы. Реализации кэшей страдали от отсутствия индексации метрик по времени, т.е. при запросе мы сканируем все файлы без указания временного интервала
Например, запрос
production.service.*.categories.*.count
- первый wildcard * : IP адрес интсанса
- второй * : категория, которая может принимать 100+ значений
Т.е. если есть 100 инстансов и 100 категорий, то мы получаем 10k путей метрик, которые будут накапливаться при частых обновлениях
➡️ Как решили?
Применили быстрое архивирование (fast archiving). Переносим пути неактивных метрик в архив после того, как они перестали отправляться от инстанса (например 24 часа). На дашборда отображаются только живые метрики. Как результат, теперь Graphite сервера могут справляться с большим количество запросов с пиковыми нагрузками
Grafana Labs
Graphite OSS | Time-series data platform
Graphite is a scalable monitoring system for timeseries data.
👍5❤2🔥2
RAG Query expansion
Мы ранее рассматривали, как работает RAG. Сегодня поговорим про один из подходов к их улучшению
Query expansion (расширение запроса) - это техника улучшения ретривера в RAG-системах. Заключается в добавлении синонимов, связанных терминов и скрытых смыслов к исходному запросу
Как работает?
- На вход подаем запрос пользователя
- Просим LLM расширить запрос
- Либо напрямую, например
- Либо можем отдельно составить ключевые слова и соединить их с исходным запросом вручную:
- Далее проводим поиск чанков, как обычно
Пример:
- Исходный запрос:
- Расширенный запрос:
По задумке это должно увеличить количество релевантных документов ретривером, если запрос скудный на детали
Мы ранее рассматривали, как работает RAG. Сегодня поговорим про один из подходов к их улучшению
Query expansion (расширение запроса) - это техника улучшения ретривера в RAG-системах. Заключается в добавлении синонимов, связанных терминов и скрытых смыслов к исходному запросу
Как работает?
- На вход подаем запрос пользователя
- Просим LLM расширить запрос
- Либо напрямую, например
Добавь к следующему запросу ключевые слова или синонимы, которые помогут найти больше информации: {query}- Либо можем отдельно составить ключевые слова и соединить их с исходным запросом вручную:
Приведи 5 ключевых слов или фраз, которые семантически связаны с запросом: {query}. Ответ выдай в виде списка через запятую.- Далее проводим поиск чанков, как обычно
Пример:
- Исходный запрос:
Лечение головной боли- Расширенный запрос:
Лечение головной боли, мигрень, анальгетики, таблетки от болиПо задумке это должно увеличить количество релевантных документов ретривером, если запрос скудный на детали
❤4👍2🔥1
Векторные БД. Бенчмарки
С популярностью RAG (и LLM в целом) свою популярность обрели и специализированные векторные БД.
Их используют для хранения векторных представлений (эмбнддингов) различных текстов. И в настоящее время их большое количество. Есть как отдельные приложения, так и дополнения к популярным "классическим" БД. Из наиболее известных: Qdrant, Milvus, Weaviate, Marqo, Lancedb etc.
Как выбрать?
На сайте представлена таблица векторных БД по предлагаемому функционалу, популярности и еще куче параметров. Здесь можно выбрать подходящую БД https://superlinked.com/vector-db-comparison
Еще есть бенчмарки по векторным БД, например https://ann-benchmarks.com/index.html
Есть еще бенчмарки от самих производителей векторных БД. Но относится к ним нужно с долей скептицизма:
- https://zilliz.com/vector-database-benchmark-tool
- https://qdrant.tech/benchmarks/
С популярностью RAG (и LLM в целом) свою популярность обрели и специализированные векторные БД.
Их используют для хранения векторных представлений (эмбнддингов) различных текстов. И в настоящее время их большое количество. Есть как отдельные приложения, так и дополнения к популярным "классическим" БД. Из наиболее известных: Qdrant, Milvus, Weaviate, Marqo, Lancedb etc.
Как выбрать?
На сайте представлена таблица векторных БД по предлагаемому функционалу, популярности и еще куче параметров. Здесь можно выбрать подходящую БД https://superlinked.com/vector-db-comparison
Еще есть бенчмарки по векторным БД, например https://ann-benchmarks.com/index.html
Есть еще бенчмарки от самих производителей векторных БД. Но относится к ним нужно с долей скептицизма:
- https://zilliz.com/vector-database-benchmark-tool
- https://qdrant.tech/benchmarks/
Superlinked
Vector DB Comparison
Vector DB Comparison is a free and open source tool from VectorHub to compare vector databases.
🔥7👍3
Forwarded from Adtech: персональное мнение
➡️ Внимание, программачи!
Дорогие друзья, презентую вам новый проект, который призван помочь стать рынку РТБ чуть ближе друг к другу!
Называется он OpenRTB Market и находится по адресу https://t.me/rtbexchange
Это канал, где трафик находит деманд, а люди находят деловых партнёров)
Суть канала такая, что вы можете рассказать о себе и своей компании, о своих возможностях или потребностях.
Для этого нужно всего лишь заполнить анкету: https://forms.yandex.ru/u/688901b202848f0432f5e97f
Если рассказывать по какой-то причине не хотите, то обязательно подпишитесь на канал, так как некоторые компании радуют подписчиков канала приятными бонусами.
Подписывайтесь 👉 https://t.me/rtbexchange
Дорогие друзья, презентую вам новый проект, который призван помочь стать рынку РТБ чуть ближе друг к другу!
Называется он OpenRTB Market и находится по адресу https://t.me/rtbexchange
Это канал, где трафик находит деманд, а люди находят деловых партнёров)
Суть канала такая, что вы можете рассказать о себе и своей компании, о своих возможностях или потребностях.
Для этого нужно всего лишь заполнить анкету: https://forms.yandex.ru/u/688901b202848f0432f5e97f
Если рассказывать по какой-то причине не хотите, то обязательно подпишитесь на канал, так как некоторые компании радуют подписчиков канала приятными бонусами.
Подписывайтесь 👉 https://t.me/rtbexchange
Telegram
OpenRTB Market
Место где трафик находит свой деманд, а люди находят партнеров.
Форма для публикации: https://forms.yandex.ru/u/688901b202848f0432f5e97f
Информационный Adtech канал: https://t.me/adtechnow
Новости монетизации со всего мира:https://t.me/monetiziruy_eto
Форма для публикации: https://forms.yandex.ru/u/688901b202848f0432f5e97f
Информационный Adtech канал: https://t.me/adtechnow
Новости монетизации со всего мира:https://t.me/monetiziruy_eto
🔥4❤1👍1
RAG HyDE
Ранее мы рассматривали один из способов query expansion, как обогатить запрос в RAG систему и улучшить работу ретривер. Сегодня рассмотрим еще один простой способ Hypothetical Document Embeddings (HyDE)
Как работает?
- Получаем запрос пользователя
- Подаем его в LLM как есть и просим ответить на него как есть (без всякого контекста)
- Получаем ответ от LLM. Переводим его в вектор и уже по этому вектору ищем чанки
- Найденные чанки вместе с исходным запросом подаем в LLM для формирования финального ответа
Пример:
Как результат гипотетический ответ содержит больше контекста (более семантически насыщенный), чем исходный запрос, что улучшает качество поиска
Ранее мы рассматривали один из способов query expansion, как обогатить запрос в RAG систему и улучшить работу ретривер. Сегодня рассмотрим еще один простой способ Hypothetical Document Embeddings (HyDE)
Как работает?
- Получаем запрос пользователя
- Подаем его в LLM как есть и просим ответить на него как есть (без всякого контекста)
- Получаем ответ от LLM. Переводим его в вектор и уже по этому вектору ищем чанки
- Найденные чанки вместе с исходным запросом подаем в LLM для формирования финального ответа
Пример:
Запрос: Как работают квантовые компьютеры?
Гипотетический ответ: Квантовые компьютеры используют принципы квантовой механики, такие как суперпозиция и запутанность, чтобы выполнять вычисления. В отличие от классических битов, кубиты могут находиться в нескольких состояниях одновременно...
Как результат гипотетический ответ содержит больше контекста (более семантически насыщенный), чем исходный запрос, что улучшает качество поиска
Telegram
ML Advertising
RAG Query expansion
Мы ранее рассматривали, как работает RAG. Сегодня поговорим про один из подходов к их улучшению
Query expansion (расширение запроса) - это техника улучшения ретривера в RAG-системах. Заключается в добавлении синонимов, связанных терминов…
Мы ранее рассматривали, как работает RAG. Сегодня поговорим про один из подходов к их улучшению
Query expansion (расширение запроса) - это техника улучшения ретривера в RAG-системах. Заключается в добавлении синонимов, связанных терминов…
👍6❤5🔥1
💸 Хотите повысить прибыль бизнеса с помощью CPA-маркетинга?
CPA (Cost per Action) — это модель, где вы платите только за реальные действия вашей аудитории: покупки, регистрации или заполнения форм.
Подписавшись на CPAInform, вы получите:
💪 Тренды и стратегии CPA-маркетинга.
💪 Полезные материалы для оптимизации расходов.
💪 Советы по увеличению конверсии и дохода.
Не упустите возможность изучить эффективные методы продвижения и внедрить их в свой бизнес!
✅ Присоединяйтесь: CPAInform и станьте частью сообщества профессионалов.
CPAExchange_RegistrationBot– твоя возможность зарабатывать на арбитраже
❕Не упусти свою прибыль – подключайся прямо сейчас
CPA (Cost per Action) — это модель, где вы платите только за реальные действия вашей аудитории: покупки, регистрации или заполнения форм.
Подписавшись на CPAInform, вы получите:
💪 Тренды и стратегии CPA-маркетинга.
💪 Полезные материалы для оптимизации расходов.
💪 Советы по увеличению конверсии и дохода.
Не упустите возможность изучить эффективные методы продвижения и внедрить их в свой бизнес!
✅ Присоединяйтесь: CPAInform и станьте частью сообщества профессионалов.
CPAExchange_RegistrationBot– твоя возможность зарабатывать на арбитраже
❕Не упусти свою прибыль – подключайся прямо сейчас
👍3
Тюним гипер параметры для RAG
Под капотом у RAG системы можно найти несколько различных компонентов. Причем набор и структура этих компонентов может серьезно различаться в зависимости от задачи и выбранного подхода. И каждый их этих компонентов обладает собственным набором параметров. И весь этот зоопарк надо как-то настраивать, потому что от этого сильно зависит качество поиска. Сейчас мы попробуем сформировать список гипер параметров для настройки RAG на каждом этапе
➡️ Чанки
Принимаем файлы, читаем их, разбиваем на чанки с помощью библиотеки langchain. Здесь мы можем управлять следующим
-
-
-
➡️ Bi-encoder
Конвертируем строку в вектор. Про bi-encoder важно понимать следующее
- Сколько текста он может обработать за раз, остальное будет отброшено. Если у вас длинные чанки или длинные вопросы, то вам, возможно, стоит подобрать bi-encoder с большей длиной контекста
- Какого размера вектора он возвращает. При прочих равных, чем больше длина вектора, тем больше информации в нем можно закодировать
- Также можно пробовать разные bi-encoder'ы и смотреть, какой из них лучше себя покажет
➡️ Векторная БД
Конвертируем переданные чанки в эмбеддинги и помещаем в БД, например Qdrant. При этом удаляем и вновь создаем коллекцию (аналог таблиц в реляционных БД), в которой складируем чанки. Последовательно перебираем файлы, каждый из которых делим на чанки и кладет в Qdrant
Здесь нужно обратить внимание:
- Коллекцию мы создаем такого же размера, какого размера вектора возвращает bi-encoder
- Вместе с вектором мы будем хранить сам чанк, из которого он сформирован и название файла, из которого он взят
➡️ Поиск векторов
Кодируем вопрос в вектор, далее ищем по косинусному расстоянию наиболее похожие вектора в Qdrant. Возвращаем содержимое чанков, привязанных к топ N отобранных векторов. Отсюда параметр
- n_top_cos: количество топ N отобранных векторов
➡️ LLM
Хотя LLM мы не дообучаем, но все равно можем тюнить инференс, используя следующие параметры
-
-
-
После того, как мы выделили эти параметры, то можем поручить задачу их оптимизации Optun'е
Под капотом у RAG системы можно найти несколько различных компонентов. Причем набор и структура этих компонентов может серьезно различаться в зависимости от задачи и выбранного подхода. И каждый их этих компонентов обладает собственным набором параметров. И весь этот зоопарк надо как-то настраивать, потому что от этого сильно зависит качество поиска. Сейчас мы попробуем сформировать список гипер параметров для настройки RAG на каждом этапе
➡️ Чанки
Принимаем файлы, читаем их, разбиваем на чанки с помощью библиотеки langchain. Здесь мы можем управлять следующим
-
sep: разделитель по которому мы будем шинковать файл-
chunk_size: размер чанков (в символах)-
chunk_overlap: с каким перехлестом будут делаться чанки➡️ Bi-encoder
Конвертируем строку в вектор. Про bi-encoder важно понимать следующее
- Сколько текста он может обработать за раз, остальное будет отброшено. Если у вас длинные чанки или длинные вопросы, то вам, возможно, стоит подобрать bi-encoder с большей длиной контекста
- Какого размера вектора он возвращает. При прочих равных, чем больше длина вектора, тем больше информации в нем можно закодировать
- Также можно пробовать разные bi-encoder'ы и смотреть, какой из них лучше себя покажет
➡️ Векторная БД
Конвертируем переданные чанки в эмбеддинги и помещаем в БД, например Qdrant. При этом удаляем и вновь создаем коллекцию (аналог таблиц в реляционных БД), в которой складируем чанки. Последовательно перебираем файлы, каждый из которых делим на чанки и кладет в Qdrant
Здесь нужно обратить внимание:
- Коллекцию мы создаем такого же размера, какого размера вектора возвращает bi-encoder
- Вместе с вектором мы будем хранить сам чанк, из которого он сформирован и название файла, из которого он взят
➡️ Поиск векторов
Кодируем вопрос в вектор, далее ищем по косинусному расстоянию наиболее похожие вектора в Qdrant. Возвращаем содержимое чанков, привязанных к топ N отобранных векторов. Отсюда параметр
- n_top_cos: количество топ N отобранных векторов
➡️ LLM
Хотя LLM мы не дообучаем, но все равно можем тюнить инференс, используя следующие параметры
-
max_new_tokens: максимальное количество токенов, которое будет сгенерировано LLM (не считая токены в промте)-
temperature: определяет насколько “творческим” будет ответ LLM. Чем выше значение, тем выше “творчество”-
top_k: ограничивает количество вариантов, которые модель рассматривает при генерации следующего токенаПосле того, как мы выделили эти параметры, то можем поручить задачу их оптимизации Optun'е
❤2👍1🔥1
Для тех, кто в Москве. Камерная тусовка под названием «Programmatic Status» для adtech/programmatic-народа — без докладов, с живыми разговорами о закупках, оптимизации, атрибуции, антифроде и bid-стратегиях.
Когда: четверг, 18 сентября, 19:00
Где: бар «Проточный» — Проточный переулок, 2/1
Формат: напитки, нетворк, обсуждаются тренды
Я сам в этот раз не доберусь, но смело рекомендую сообщество — хорошая возможность встретить «своих» и обсудить реальные кейсы.
Регистрация и подробности: https://dmcrus.timepad.ru/event/3560268/
Когда: четверг, 18 сентября, 19:00
Где: бар «Проточный» — Проточный переулок, 2/1
Формат: напитки, нетворк, обсуждаются тренды
Я сам в этот раз не доберусь, но смело рекомендую сообщество — хорошая возможность встретить «своих» и обсудить реальные кейсы.
Регистрация и подробности: https://dmcrus.timepad.ru/event/3560268/
🔥5👍1
Google Ads AI Max
Google Ads представил новые метрики для отчетов по кампаниям AI Max, которые показывают трафик, приходящий от ключевых слов
Ранее рекламодатели могли только видеть, на какие целевые страницы заходили пользователи
Что за метрики?
Expanded matches: показывает трафик, генерируемый по ключевым словам с широким соответствием, которые AI Max создает на основе ключевых слов, предоставленных рекламодателем
Expanded landing pages: показывает трафик из поисковых запросов, которые совпали благодаря целевым страницам или ресурсам, работающим независимо от таргетинга по ключевым словам
Если у рекламодателя нет дополнительных фильтров или ограничений по таргетингу (например, задача сделать только охваты), то AI Max может привести к снижению контроля за РК и перекрутке бюджета
Google Ads представил новые метрики для отчетов по кампаниям AI Max, которые показывают трафик, приходящий от ключевых слов
Ранее рекламодатели могли только видеть, на какие целевые страницы заходили пользователи
Что за метрики?
Expanded matches: показывает трафик, генерируемый по ключевым словам с широким соответствием, которые AI Max создает на основе ключевых слов, предоставленных рекламодателем
Expanded landing pages: показывает трафик из поисковых запросов, которые совпали благодаря целевым страницам или ресурсам, работающим независимо от таргетинга по ключевым словам
Если у рекламодателя нет дополнительных фильтров или ограничений по таргетингу (например, задача сделать только охваты), то AI Max может привести к снижению контроля за РК и перекрутке бюджета
👍2🔥1