DMC Russia подготовили ежегодный обзор и рейтинг рынка российского программатика за 2024. Сохраняем себе и следим за топами рынка

Рейтинг Programmatic продуктов по выручке за 2024 год от @dmcrus

В 2024 общая выручка Programmatic продуктов составила более 47,1 млрд рублей (+21%). Темпы роста рынка программатика замедлились. Если в прошлом году рост рынка программатика опережал рост рынка интернет-рекламы, то в этом году ситуация обратная.

Ключевые цифры:
❱ Общая выручка — 47.1 млрд рублей (+69%)
❱ Кол-во Programmatic продуктов — 60
❱ Общее кол-во сотрудников — 2029

Топ-3 по выручке:
🥇 Hybrid — 3,6 млрд рублей (+45.2%)
🥈 Buzzoola — 2,9 млрд рублей (+15.3%)
🥉 bidease — 2,4 млрд рублей (+0.7%)

Основные выводы:
❱ Общая выручка составила более 47.1 млрд рублей (+21%), а общая чистая прибыль 5 млрд руб. (+27%). Средняя рентабельность по чистой прибыли в 2024 — 10.6%.
❱ Рост рынка программатика замедлился, как мы и прогнозировали в прошлом году. Сейчас на рынке больше 60 программатик продуктов.
❱ Рынок продолжает консолидироваться. Авито купили Интернест (Soloway / AdRiver), T2 купили Yabbi, Redllama и Plazkart, РБК купили Hyper Adtech, Ростелеком купил First Data. А МТС AdTech объявили о планах проведения IPO.

В этом году мы добавили новые компании и немного изменили подход, сделав два рейтинга: Programmatic продуктов и Programmatic групп.

Полный рейтинг: https://digitalmarketingclub.ru/rating/dsp24

Очень рекомендую ознакомиться с Whitepaper: https://drive.google.com/file/d/1VUU4DI-4az6geEw1qH6-LaXAkqG0Pk4G/view

Хочу поблагодарить наших партнеров Hybrid, Mediadesk, AdRiver и bidease, которые поддержали рейтинг, а также экспертов и участников рынка, которые принимали участие и давали обратную связь.

Буду рад комментариям и замечаниям.

#programmatic #research

@dmcrus

💪Вы можете прямо сейчас увеличить поток клиентов для Вашего бизнеса.

CPA Маркетинг позволит вам увеличить поток клиентов на 100%, при это вы потратите на это 10 минут времени и 0 рублей денег!

📌 В нашем канале рассказываем о всех секретах CPA, которые позволят вашему бизнесу начать зарабатывать, а не только работать.

👐 Переходите в канал CPAInform, обучение в посте.

CPAExchange_RegistrationBot– твоя возможность зарабатывать на арбитраже

❕Не упусти свою прибыль – подключайся прямо сейчас!

💪Платим Деньги за Ваш Трафик.
Стабильно, Надёжно, Прибыльно!
Выгодно монетизируй свой трафик с помощью топовой CPA сети!
С любого устройства, в любом месте, круглосуточно!
Зарегистрироваться ❤️

Как выработать продуктовый подход, когда ты разраб?

Есть компании с четким разделением задач и тепличными условиями для разрабов
- под каждую задачу заводятся ТЗ/ Design Doc
- есть аналитик, прикрепленный к команде
- есть тестировщик, который сам пропишет тест-кейсы и вернет детальный баг-репорт

Но правда жизни иногда бывает, что ты зачастую, как швейцарский нож. К тебе у кофе-машины подходит Engineering менеджер и говорит что-то вроде
- мы хотим добавить фичу Х, или апскейлить фичу Y на все регионы платформы. Сколько это может нам денег принести/ сэкономить?
- успеем ли мы сделать до завершения Q3?
- справимся ли мы своими силами, или нужно от смежников кого-то подключать?

И вот, не успев моргнуть глазом, ты уже тех лид проекта с нечетко поставленной задачей. Что дальше?
Дальше главное не пороть горячку, а составить список вопросов и получить на них максимально детальные ответы

- А какие проблемы мы, собственно, решаем?

- Решаем проблемы A, B. Чтобы что? (если создаем новую фичу Х, чтобы уменьшить CPM, или лучше пейсить бюджет, или улучшить availability платформы, или чтобы терять меньше денег на инцидентах, или уменьшить CPU usage машин в инфре, когда хотим заменить предикты по одному на запрос запросу в real-time на batch processing)

- Это быстрый патч проблемы или стратегическое long-term решение?

- Как это работает сейчас? И долго ли оно уже так живет?

- Если долго, то может быть нас это устраивает. Тогда еще раз спрашиваем себя, зачем нам это нужно

- Кто основные пользователи и стейкхолдеры (агенства, паблишеры, меда байеры, рекламодатели)? В чем их цели/интересы?

- По каким метрикам сможем оценить успешность (Margin, Revenue, CPM, Impressions, Network-out etc.)? как будем их отслеживать до/после?

- Какие альтернативы уже рассматривали? Какие готовые решения можно просто купить? Почему их не выбрали?

- Какие есть ограничения - по таймингам, комплаенсу, трафику, юридические...?

- Есть ли пересечения с другими проектами в параллели? Возможно наш roadmap уже забит на квартал, и новый проект будет в приоритете, начиная с Q3

- План rollout-а - страны/регионы/сегментов пользователей/ паблишеров, полная выкладка или A/B, alpha тест?

- Какие операции/ фичи мы своим новым решением можем сломать?

Здесь хорошо эти вопросы уточнять и задавать в паре со своим продактом. Он с упором на бизнес, а ты, как тех лид, с упором на технические аспекты

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 регуляторы, но подойдет для разных типов биддеров.

Проходите по ссылке и накидайте звездочек 🌟 в репозиторий!

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

Горячие новости! 🔥

Мои поздравления, в ТГ появился формат рекламы 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 месяца назад, то можно замерять не только брендинг, но еще и перформанс до кучи

Как детектировать битые креативы в 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 - это 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 с/без фильтрации

Server Side Bidding Part #2

Это вторая часть серии по 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.

Сегодня разберем 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 видео). Из меньшего охвата могут быть ограничения на таргетинг. Но при этом с технической точки зрения встроить инстрим можно в любой сайт, где установлен видеоплеер

Интересные процессы по развитию ecomm'ом своих рекламных платформ и ухода от монополии Гугла, на которые стоит обратить внимание

Amazon остановил всю рекламу в Google Shopping

С 21 по 23 июля доля показов Amazon в Google Shopping снизилась до 0%:
- США: ~60% -> 0%
- Великобритания: ~55% -> 0%
- Германия: ~38% -> 0%

Тут два важных тренда:
- Перетекание товарных поисковых запросов из поиска в маркетплейсы
- Развитие маркетплейсами своих рекламных платформ

И тут позиция Amazon понятно - он уже может позволить себе не тратить деньги на Google, а улучшить свою unit-экономику и инвестировать в развитие своей собственной рекламной платформы.

Amazon уже снижал в мае бюджеты на Google Shopping в США на 50% в мае. Теперь решили сделать более радикальный тест. Но тренд уже понятен.

@dmcrus

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 запрос для внутреннего аукциона

Что нужно знать о монетизации в рекламе? 💵

Все что вы хотели узнать, но боялись спросить про монетизацию инвентаря в программатике, теперь вы можете найти в канале Ad Cops. Его ведет AdOps менеджер Денис Рубежанский

Что вы найдете на канале?

Гайды и разборы кода адаптеров интеграций на Adfox и Prebid:
- Vibe-coding глазами AdOps специалиста. Как сделать обертку для Adfox с разными форматами и прикрутить поддержку Header Bidding?
- Разбираемся с баннерами по-умолчанию на Adfox: заглушки в РСЯ и сбор статистик adserver'ом
- Платный Adfox: почему, и что с этим делать?

Для AdOps специалистов, менеджеров по рекламным размещениям, специалистов по монетизации, менеджеров SSP регулярно размещаются вакансии (примеры раз, два, три)

В общем, рекомендую обратить внимание на Ad Cops. Хочется, чтобы такого контента в русскоязычном АдТехе было больше!

Как (не) положить сервер мониторинга, при большом количестве данных?

Одно время для мониторинга платформы мы использовали Graphite сервера. Все дашборды на Grafan'е, отображающие состояние SSP (бизнес метрики, сервисы, ML модели, инфра etc.) забирали данные с них. По мере роста продуктовых команд, каждая из них старалась отсылать все большее количество метрик. Это в итоге привело к тому, что CPU сервера стал перегружаться при частой обновлении дашбордов. Особенно это касается сложных запросов для бордов на Графане

➡️ В чем проблема?
На Graphite серверах данные закэшированы. Реализации кэшей страдали от отсутствия индексации метрик по времени, т.е. при запросе мы сканируем все файлы без указания временного интервала

Например, запрос

production.service.*.categories.*.count

- первый wildcard * : IP адрес интсанса
- второй * : категория, которая может принимать 100+ значений

Т.е. если есть 100 инстансов и 100 категорий, то мы получаем 10k путей метрик, которые будут накапливаться при частых обновлениях

➡️ Как решили?
Применили быстрое архивирование (fast archiving). Переносим пути неактивных метрик в архив после того, как они перестали отправляться от инстанса (например 24 часа). На дашборда отображаются только живые метрики. Как результат, теперь Graphite сервера могут справляться с большим количество запросов с пиковыми нагрузками

RAG Query expansion

Мы ранее рассматривали, как работает RAG. Сегодня поговорим про один из подходов к их улучшению

Query expansion (расширение запроса) - это техника улучшения ретривера в RAG-системах. Заключается в добавлении синонимов, связанных терминов и скрытых смыслов к исходному запросу

Как работает?
- На вход подаем запрос пользователя
- Просим LLM расширить запрос
- Либо напрямую, например Добавь к следующему запросу ключевые слова или синонимы, которые помогут найти больше информации: {query}
- Либо можем отдельно составить ключевые слова и соединить их с исходным запросом вручную: Приведи 5 ключевых слов или фраз, которые семантически связаны с запросом: {query}. Ответ выдай в виде списка через запятую.
- Далее проводим поиск чанков, как обычно

Пример:
- Исходный запрос: Лечение головной боли
- Расширенный запрос: Лечение головной боли, мигрень, анальгетики, таблетки от боли

По задумке это должно увеличить количество релевантных документов ретривером, если запрос скудный на детали

Векторные БД. Бенчмарки

С популярностью 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/

➡️ Внимание, программачи!

Дорогие друзья, презентую вам новый проект, который призван помочь стать рынку РТБ чуть ближе друг к другу!

Называется он OpenRTB Market и находится по адресу https://t.me/rtbexchange

Это канал, где трафик находит деманд, а люди находят деловых партнёров)

Суть канала такая, что вы можете рассказать о себе и своей компании, о своих возможностях или потребностях.

Для этого нужно всего лишь заполнить анкету: https://forms.yandex.ru/u/688901b202848f0432f5e97f

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

Подписывайтесь 👉 https://t.me/rtbexchange