У меня наконец дошли руки до LLM. Поэтому по мере их изучения буду делиться заметками по теме.

Сегодня начнем с теории: Что такое базовые (base) и инструктивные (instruct) модели?

▶ Базовые LLM
Эти модели обучаются на больших объемах текстовых данных. Они обладают обширными знаниями об языке и умеют генерировать текст на высоком уровне. Но их основная задача — просто предсказать следующий токен (слово) в заданном контексте. В связи с чем, они не очень "умны" и плохо следуют указаниям. Например, при запросе «Cтолица Франции?» базовая LLM может выдать: «Столица Индии?».

▶ Инструктивные LLM
Это базовые LLM дообученные на различных NLP задачах, в режиме supervised с помощью инструкций. Инструкции эти задаются на естественном языке и имеют вид пар: запрос - правильный ответ. В результате такого обучения LLM гораздо лучше выполняют указания и больше подходят для практического применения (QnA-системы, чат-боты, различные AI-асситенты и т.д.). И они уже на вопрос «Столица Франции?» скорее ответят «Париж» или «Столица Франции — Париж».

Так зачем выпускают базовые модели если инструктивные гораздо полезнее? Базовая модель предназначена для того, чтобы вы смогли дообучить ее под свои задачи или датасет.

Примеры:
- Gemma 2: google/gemma-2-9b и google/gemma-2-9b-it
- Qwen2: Qwen/Qwen2-7B и Qwen/Qwen2-7B-Instruct

Также на Толоке есть интересная статья с подробным описанием base vs instruct LLMs.

#llm

Обзор платформ Header Bidding (HB)

Механизм Header Bidding необходим паблишерам для лучшей монетизации инвентаря. Здесь, в отличии от прямых контрактов, паблишер имеет возможность выручить более высокий CPM, ибо в аукционе участвуют на равных основаниях сразу несколько SSP. Это делает интеграцию более прозрачной

Технически реализовать HB можно через разные платформы-вендоры. Сегодня  мы рассмотрим
- Prebid: совместно  Prebid.js Client side, Prebid Server side
- Google: Open Bidding
- Amazon: Transparent Ad Marketplace (TAM)

Поскольку тема HB достаточно обширная, для начала мы сравним комиссии платформ за аукцион и скорость его обработки.


▶ Комиссия
TAM от Amazon Publisher Services взимает комиссию 0.01 USD CPM только за те показы, которые он монетизирует, но паблишеры все-таки должны иметь direct sold отношения с партнерскими SSP, чтобы получить этот более низкий тариф. При этом клиенты Amazon DSP получают льготы и не платят никаких комиссий за использование TAM.

Google Open Bidding взимает самую высокую оплату: 5% за display и outstream, 10% за видео. Она добавляется поверх комиссии ad exchange'а, т.е. exchange вычитает свою долю из ставки покупателя, а Google забирает свою.

Prebid не взимает комиссий, поскольку его код open source. Однако издатели платят операционной сложностью и инженерными затратами за настройку Prebid адаптеров. Некоторые паблишеры платят сторонним SSP, которые либо уже имеют отлаженную практику написания адаптеров, либо свою имплементацию Prebid Server Side на своей инфоаструктуре (по сути измененный fork открытого репозитория пребида). Примеры подобных SSP - Rubicon и AppNexus.


▶ Скорость
Следующим критерием выбора HB платформы является скорость обработки аукциона и показа креатива. Как правило, аукционы, которые запускаются на серверах быстрее тех, которые проходят в браузере на стороне пользователя.

Поскольку Google Open Bidding работает внутри Google Ad Manager, он полностью серверный. Open Bidding добавляет всего 60 мс к полному процессу Google Ad Manager, что в сумме составляет от 150 до 300 мс для проведения аукциона.

TAM от Amazon инициируется на стороне клиента, но сам аукцион проходит на сервере. Ключевым преимуществом является то, что производительность не зависит от количества партнерских SSP в аукционе, которых добавляет паблишер. Поэтому, если, количество опрашиваемых биддеров >10, то Amazon может разрешить аукцион примерно на 20% быстрее, чем Open Bidding.

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

Полезные материалы по теме:
Prebid.org
Google Open Bidding
TAM

Продолжаем тему Header Bidding. Сегодня рассмотрим инструмент Professor Prebid.

Это open source расширение для Chrome. Его используют, когда требуется промониторить Header Bidding интеграции для сайта, издатель которого использует Prebid.js.

Professor Prebid полезен, когда вам потребовалось отладить работу Header Bidding аукционов на конкретном сайте.

При загрузке страницы расширение отслеживает запросы, отправленные по всем слотам (AdUnit'ам) страницы на биддеры. По AdUnit'ам также доступны
- banner size
- формат: Prebid.js. в данный момент поддерживает banner, native, video
- список ответившых SSP
- SSP c выигравшей ставкой

На вкладке Bids мы можем видеть ответ от каждой SSP, сделавшей ставку. Мы можем видеть
- bid CPM + валюта
- купленный adUnit
- инфу по таргетингу из адсервера (обычно Google Ad Manager)
- резервную цену аукциона

Также доступен таймлайн от старта аукциона по каждому биддеру. Это нужно, чтобы видеть какие биддеры отсекаются по таймауту (обычно 1 сек). Паблишерам важно, чтобы аукцион произошел быстро, желательно за 150-200 мс пока грузится страница. Если процесс затягивается больше чем на 1 сек, то доля показов может упасть больше чем на половину

В целом, если вы publisher account manager, и вам нужно регулярно отвечать на вопросы паблишеров по их монетизации, то Professor Prebid будет для вас полезным в хозяйстве инструментом

Как аннотировать данные для обучения ML-моделей?

Для успешного обучения ML-модели необходим качественно аннотированный датасет. Рассмотрим три основных подхода к разметке данных, которые применяются на практике:

1. Ручная разметка
Здесь весь процесс выполняется вручную. Аннотатор размечает данные, а эксперты проверяют, насколько точно выделены сущности. При необходимости исправления вносятся вручную или возвращаются аннотаторам для доработки. Такой метод подходит для сложных задач, которые требуют высокой точности. Самые известные платформы для ручной разметки: Toloka, Amazon Mechanical Turk.

2. Активное обучение: разметка с обратной связью
Метод сочетает участие аннотаторов и ML-моделей. Сначала аннотатор вручную выделяет ключевые фрагменты в документах, отмечая нужные формулировки. Затем модель обучается на размеченном датасете и начинает предсказывать свой вариант разметки. ML-модель возвращает аннотатору примеры для доразметки, которые помогут улучшить качество прогноза разметки на следующих итерациях. Цикл корректировки повторяется до тех пор, пока модель не начнет правильно выделять данные в 90% случаев.

3. Авторазметка: минимизация участия аннотаторов
Метод использует обученную модель для автоматического аннотирования данных. На первом этапе создается небольшой, вручную размеченный датасет, который служит основой для обучения модели. Затем модель обучается с участием ML-инженеров. Далее модель применяется для автоматического аннотирования данных, а аннотатор и эксперт лишь оценивают итоговый результат, внося правки при необходимости. Такой подход снижает трудозатраты специалистов, но требует предварительной настройки модели.

Выбор метода аннотации зависит от объема данных, сложности задачи и доступных ресурсов.

Рассказали о способах аннотации специалисты из Embedika — коллеги разрабатывают решения на основе искусственного интеллекта и рассказывают у себя в канале о новостях в сфере ИИ, разработке LegalTech-решений и многом другом. Загляните)

RAG в LLM

Продолжаем тему языковых моделей. Первый пост был по различию базовых и инструктивных LLM. Сегодня рассмотрем понятие RAG.

RAG (Retrieval Augmented Generation) - это подход, который позволяет использовать Большие языковые модели (LLM) для ответов на вопросы пользователей по приватным источникам информации.

Рассмотрим самый базовый вариант RAG:

▶️ Подготовка данных
- Собираем документы
- Разбиваем весь корпус документов на чанки (небольшие кусочки текста). Разбивать можно разными способами, например по предложениям (по символу-разделителю точке), или более хитро по иерархии на большие чанки и внутри них чанки поменьше (сабчанки)
- Каждый чанк кодируем энкодером в вектор. Это нужно, чтобы сравнивать вектор чанка с вектором вопроса пользователя. В качестве энкодера удобно взять уже обученный HuggingFaceEmbeddings
- Пишем все закодированные чанки в векторную БД. Одна из топовых векторных БД Pinecone, заточена специально под хранение эмбеддингов для LLM приложений

▶️ Ответ на вопрос
- Пользователь формулирует вопрос
- С помощью энкодера из первого пункта кодируем текст вопроса в вектор
- Отбираем из всего списка чанков векторной БД топ-N наиболее близких вектору вопроса. Близость векторов меряем косинусным расстоянием
- Все найиденные N чанков и вопрос (и то, и другое уже в виде текста) передаем в LLM и просим ее, учитывая контекст (из чанков), ответить на вопрос пользователя

Идея о RAG возникла из-за трех ограничений:
- Невозможности впихнуть в LLM весь желаемый контекcт
- LLM ничего не знает об информации, которой не было в обучающих данных. Это касается любой приватной или узко-направленной инфы
- Альтернативой RAG может быть дообучение LLM на своих данных, но это крайне нерационально и дорого

Таким образом легким движением руки мы можем без дообучения LLM и энкодера написать свой простой Q&A сервис или чат-бота под свою доменную область. Дальше можно пробовать улучшать сервис, например тюнингом энкодера, иерархией чанков или правками в промпт

#llm

Российский рынок программатика продолжает консолидироваться. Вслед за присоединением DOOH сервиса Russ к WB, сегодня Avito объявила о покупке 100% верификатора трафика и SSP AdRiver и DSP Soloway (баннеры, мобилки и Smart TV). По этому поводу Иван сделал подробное мнение с разбором

Иван по средам

Некогда забытая рубрика. Давно хотел возобновить, но времени на такую роскошь остаётся всё меньше.

Поводом возобновить рубрику стало знаменательное событие: покупка Soloway/Adriver самой Авито.

Столкнулся в некоторых чатах с непониманием, зачем это, собственно, коллегам из Авито: вроде рекламный бизнес совсем не их конёк.

Ну во первых, олды помнят проект "Авито Таргет", который, к сожалению, был закрыт. Это была достаточно простая платформа таргетированной рекламы. Также помню таксономию от Авито, к которой относились с большим скепсисом, так как Авито - это в первую очередь большая барахолка.

Поэтому, какой-никакой рекламный опыт у платформы есть. Даже сейчас есть какой-то монструозный раздел с CPM в 300+ рублей и гибкими таргетингами.

Это ещё была эпоха до ковида, следовательно, до бума екома, ещё до времён, когда крупные площадки осмыслили свою ценность.

С другой стороны, у нас есть Adriver/Soloway, абсолютно древние, в хорошем смысле, платформы, которые начали играть в программатик ещё до программатика. Мы, в Москве 2010-х воспринимали их как "мудрецов, достигших дзена", тонкого равновесия, основанного на опыте. Не моя формулировка, но я под ней подпишусь.

У меня нет инсайдов, но я примерно понимаю на каких треках может быть использована покупка:

1. Прогонка собственных бюджетов Авито. Они немаленькие: в 2023 году Авито потратило на интернет-рекламу 2,3 млрд рублей. Даже если только половину этих бюджетов Авито пропустит через приобретенные платформы, то с учетом рыночных комиссий SSP - DSP можно представить, что окупаемость только на этом треке уже не за горами;

2. Soloway / Adriver это достаточно успешный бизнес. У DMC было важное исследование в 2023 году, которое говорит о том, что у Soloway было 6 место по выручке в 2023 году и 1 место по чистой прибыли. То есть, компания профицитна, приносит прибыль, есть клиентская база и может зарабатывать и дальше;

3. Не менее важный момент - это монетизация собственного инвентаря Авито и наличие удобной self-service DSP для агрегации денег пользователей внутри платформы.

Сейчас монетизацией инвентаря Авито занимаются сторонние компании, что, конечно, не очень комфортно и сейчас, наверное, и не выгодно. Авито, конечно, как любой Бигтек в 2024 году хочет контролировать свой трафик сам.

Неудача с собственной рекламной платформой не говорит о том, что у Авито нет потенциала для внутренних рекламодателей. Наоборот: за счет агрегации небольших рекламодателей у Авито есть потенциал роста рекламной выручки;

4. Ну и ласт бат нот лист - это система аудита, к которой есть доверие рынка. Теперь ты можешь оптимизировать свой трафик, если конкуренты им недовольны, можешь парировать их выпады - ведь у тебя есть "бумажка", которая гарантирует качество. Точно также на закупках трафика ты можешь контролировать его качество.

Одни плюсы.

Soloway / Adriver под опекой Авито смогут раскрыться ещё лучше!

В целом, буду вместе с вами наблюдать за развитием событий.

Это вообще хорошая новость, что покупки в Adtech индустрии продолжаются.

Покупка SSP / DSP это отличная, а возможно, лучшая инвестиция для компаний-обитателей рейтингов "РБК-200", так и "Крупнейших рекламодателей России" от Sostav'а.

Bid Adapter Prebid.js

Продолжаем развивать тему Header Bidding'а, сегодня у нас разбор структуры бид адаптеров на Prebid.js

Для чего нужен?
Бид адаптер представляет собой открытый код на JS, который запускается непосредственно в браузере пользователя. Как понятно из названия адаптер парсит запрос на ставку от паблишера, кастует его в формат совместимый с конкретной SSP (как правило в json), отправляет на нее HTTP запрос, принимает ответ с ценой ставки и передает ее в core Prebid.js для разрешения аукциона. Каждая SSP, интегрированная с пребидом имеет свою open-source реализацию адаптера.

Какие этапы работы адаптера?

▶️ isBidRequestValid
Проверяем корректность запроса паблишера: наличие placementId, и флаг над параметрами запроса != undefined.

isBidRequestValid: function (bid) {
 if (typeof bid.params !== 'undefined' && parseInt(getValue(bid.params, 'placementId')) > 0) {
   logInfo('Bidder adapter valid bid request');
   return true;
 } else {
   logError('Bidder adapter requires placementId to be defined and a positive number');
   return false;
 }
}

▶️ buildRequests
Если запрос валиден, то обогащаем его. На странице может быть несколько слотов с разными placementId, поэтому через адаптер за раз проходит не один, а несколько validBidRequests.

Под каждый запрос мы извлекаем данные слота:

- Айдишники placementId, bidId, transactionId = ortb2imp.ext.td (если SSP поддерживает его), adUnitCode, gpid. К слову gpid - это глобальный id слота, появился из-за того, что некоторые паблишеры не особо запариваются над уникальностью названий слотов и могут обозвать все слоты на странице, к примеру homepage. Как их различать SSP? Для этого есть gpid. gpid - это склейка из adUnitCode, размера слота и рандомного токена, что помогает SSP различать слоты и избегать коллизий (пример: homepage#300x250#wje9w )

- Контекстные фичи: referrer, он же URL страницы, pageTitle, pageDescription, которые можно потом закодировать в эмбеддинги

- Фичи пользователя: ширина, высота экрана устройства, networkBandwidth пропускная способность интернета пользователя, ориентация экрана, user agent и все доступные first-party данные (browser, os etc.). Также опционально можно извлечь историю браузера win.top.history.length

buildRequests: function (validBidRequests, bidderRequest) {
    const bids = validBidRequests.map(bids => {
      const reqObj = {};
      let placementId = getValue(bids.params, 'placementId');
      const gpid = deepAccess(bids, 'ortb2Imp.ext.gpid');
      reqObj.sizes = getSizes(bids);
      reqObj.bidId = getBidIdParameter('bidId', bids);
      reqObj.bidderRequestId = getBidIdParameter('bidderRequestId', bids);
      reqObj.placementId = parseInt(placementId, 10);
      reqObj.adUnitCode = getBidIdParameter('adUnitCode', bids);
      reqObj.transactionId = bids.ortb2Imp?.ext?.tid || '';
      if (gpid) { reqObj.gpid = gpid; }
    });
    const topWindow = window.top;

    const payload = {
      referrer: getReferrerInfo(bidderRequest),
      pageTitle: getPageTitle().slice(0, 300),
      pageDescription: getPageDescription().slice(0, 300),
      networkBandwidth: getConnectionDownLink(window.navigator),
      data: bids,
      device: bidderRequest?.ortb2?.device || {},
      deviceWidth: screen.width,
      deviceHeight: screen.height,
      screenOrientation: screen.orientation?.type,
      historyLength: getHLen(),
      prebid_version: '$prebid.version$',
    };
}

Отдельно отмечу обогащение фичей приватности. Они делятся на 3 класса

- GDPR (General Data Protection Regulation) - это общеевропейский регламент, по которому пользователь может дать или нет согласие на передачу персональных данных вендорам. По умолчанию opt-in, т.е. пока пользователь не дал согласие, файл куки на его устройство не пишется и данные не собираются. Характеризуется полями

consentString: base64 строчка, в которой закодированы пункты, на которые пользователь дал согласие
gdprApplies: булево значение о том, распространяется GDPR на пользователя или нет
vendorData: данные о конкретных SSP запрашивающих доступ

- CCPA (California Consumer Privacy Act или еще US Privacy) - это акт о приватности данных в штатах. Он более пермисивный, чем GDPR и работает по принципу opt-out, т.е. пользователь по умолчанию дает согласие на передачу данных. Характеризуется полем us_privacy, в котором закодированы только пункты согласия.

- GPP (Global Privacy Platform) - это общая обертка от IAB, под которой можно предавать и GDPR и CCPA. В поле gppString может содержать сразу несколько регламентов приватности

hydratePayloadWithGppConsentData(payload, bidderRequest.gppConsent);
hydratePayloadWithGdprConsentData(payload, bidderRequest.gdprConsent);
hydratePayloadWithUspConsentData(payload, bidderRequest.uspConsent);

После того, как обогатили bid request, пишем его в json строчку и добавляем в payload POST запроса на биддер

const payloadString = JSON.stringify(payload);
return {
  method: 'POST',
  url: ENDPOINT_URL,
  data: payloadString,
};

▶️ interpretResponse
После того, как мы отправили запрос на биддер, и, допустим, получили от него ответ со ставкой, нам нужно привести его в форму, понятную для Prebid.js.

- Сначала мы читаем объект HTTP serverResponse, парсим поле serverResponse.body, убеждаемся, что поле не пустое

- Далее формируем массив объектов-результатов bidResponse под каждый слот (напомню, нам может прийти массив из запросов на несколько слотов, и мы должны вернуть массив ответов)

Здесь мы извлекаем данные о биде
- CPM
- currency
- netRevenue
- ttl (пребиду и SSP важно знать, не отпадает ли ответ по таймауту, и если нет, то насколько быстро он приходит)
- dealId (если паблишер сотрудничает с конкретным adexchange'ем)

Также извлекаем те же айдишники, что и на этапе обогащения запроса, чтобы идентифицировать его и слот:
- requestId
- placementId
- creativeId (до получения ставки креатива не было, если ставка пришла, и SSP разрешила аукцион на своей стороне, то креатив уже прикреплен к VAST tag, который SSP в случае своей победы отправит на пребид)

 interpretResponse: function (serverResponse) {
    serverResponse = serverResponse.body;
    if (!serverResponse.responses) {
      return [];
    }
    return serverResponse.responses.map((bid) => {
      const bidResponse = {
        cpm: bid.cpm,
        currency: bid.currency,
        netRevenue: true,
        size: bid.size,
        ttl: bid.ttl,
        ad: bid.ad,
        requestId: bid.bidId,
        creativeId: bid.creativeId,
        placementId: bid.placementId,
      };
      if (bid.dealId) {
        bidResponse.dealId = bid.dealId
      }
      return bidResponse;
    });
  }
};

После того, как мы скастовали массив bidResponse'ов, адаптер отправит их на core Prebid.js, где разрешится аукцион, и в случае победы нашей SSP, нам уже прямо на сервер прийдет winNotice. В ответ SSP заплатит свою ставку паблишеру (аукцион первой цены) и SSP передаст на пребид VAST tag с креативом и залогирует показ. Если, допустим, цель нашей кампании брендинг, то деньги прийдут нам со стороны DSP в момент показа.

Хочу поздравить моих любимых подписчиков с наступающим Новым годом! 🎄️️

Желаю, чтобы в 2025 году ваши модели доходили до прода, АБТесты давали значимо положительные результаты, метрики достигали таргетов, а менеджмент был щедрым на повышения грейдов и ЗП ❤️

Ваш Админ

Продолжаем тему LLM. Сегодня речь пойдет про Mistral

Для справки, Mistral - это французский стартап серии B, разрабатывающий LLM. Поднял в 2024 году $640M. Релизят предобученные и затюненные модели и часть из них с открытыми весами. Также предоставляют бесплатный доступ к своим моделям по API.

Запустим из коробки бесплатную модельку Mistral NeMo (12B параметров и контекстное окно на 128k токенов). Не забываем получить API-key на сайте мистраля.

#!pip install mistralai -q
from mistralai import Mistral

#free
#model_id = "pixtral-12b-2409"
#model_id = "open-codestral-mamba"
model_id = 'open-mistral-nemo'

api_key = 'XXX'
client = Mistral(api_key=api_key)

chat_response = client.chat.complete(
    model= model_id,
    messages = [{
      "role": "user",
      "content": "Ответ на Главный вопрос жизни, вселенной и вообще - 42. Докажи это через цепочку рассуждений."
    }]
)

resp = chat_response.choices[0].message.content
print(resp)

Лимиты такие:
- 1 запрос в секунду
- 500 000 токенов в минуту
- 1 миллиард токенов в месяц

Полный список моделей можно найти по ссылке

#llm

💸 Хотите повысить прибыль бизнеса с помощью CPA-маркетинга?

CPA (Cost per Action) — это модель, где вы платите только за реальные действия вашей аудитории: покупки, регистрации или заполнения форм.

Подписавшись на CPAInform, вы получите:
🏵 Тренды и стратегии CPA-маркетинга.
🏵 Полезные материалы для оптимизации расходов.
🏵 Советы по увеличению конверсии и дохода.

Не упустите возможность изучить эффективные методы продвижения и внедрить их в свой бизнес!

✅ Присоединяйтесь: CPAInform и станьте частью сообщества профессионалов.