Старший Data Scientist (AdTech, programmatic supply)

Что предстоит делать

<h3>Описание роли</h3><p>Senior data scientist, который также занимается инженерией в составе delivery-команды, создающей платформу оптимизации по результатам (outcome-optimisation) и скоринга для независимого SSP. Роль предполагает создание, оценку и эксплуатацию моделей трёх семейств: модели курирования (curation) в реальном времени, look-alike моделирования с дополнением сегментов (segment augmentation) и контекстной сегментации. Язык разработки — Python.</p><p>Два data scientist’а в команде — равноправные участники. Ответственность за три семейства моделей распределяется между ними на старте проекта, поэтому в этой роли нужно быть убедительным по всем трём, включая то, которое ограничено задержкой (latency-bound). Выбор модели — не самая сложная часть работы. Метки конверсий приходят через часы или недели после показа, данные рекламодателей можно объединять лишь в тех пределах, которые допускает каждый рекламодатель, а готовая система передаётся команде клиента, в которой нет data scientist’ов.</p><p><strong>Требуется опыт в AdTech на стороне programmatic supply.</strong> Глубокая экспертиза в CTV, audio или social — это преимущество, а не обязательное условие.</p><h3>О проекте</h3><p>Клиент: независимая supply-side платформа с продуктами для курирования, идентификации и managed-сервисов; работа ведётся напрямую. Первый сценарий использования — кампании, ориентированные на результат (outcome-driven), для рекламодателей из сферы финансовых услуг, которые платят за реальные результаты — открытие счетов и депозиты, — а не за CPM или CTR.</p><p>Продукт: платформа скоринга и оптимизации, работающая на инфраструктуре клиента в двух плоскостях. Центральная плоскость в Google Cloud содержит данные и фундамент признаков, обучение моделей, MLOps и эксперименты, а также управление и отчётность. Периферийная (edge) плоскость — это портируемый контейнер скоринга, разворачиваемый внутри сред исполнения сторонних SSP.</p><p>Каналы в рамках проекта: первоначальный production-релиз охватывает один согласованный набор каналов. Развёртывание идёт в порядке приоритета клиента: сначала CTV, затем web и app video, display, audio, native и DOOH. Social — приоритет для создания и оптимизации сегментов, а не для оптимизации кампаний.</p><p>Моделирование: три семейства моделей, определённые клиентом. Модель курирования использует gradient-boosted trees на табличных признаках и оценивает bid requests в реальном времени. Look-alike и контекстная модели работают в batch-режиме. Gradient-boosted trees — базовая линия и для остальных, но не жёсткое ограничение. Подход для batch-семейств выбирается на основе данных в Фазе 1 и утверждается вместе с архитектурой в Фазе 2.<br><br></p><h3>Факторы, определяющие роль</h3><ul><li>Только модель курирования ограничена задержкой. Её бюджет — менее 5 мс на полный round trip при p99+, причём выполнение модели — лишь часть этого времени. Look-alike и контекстная модели не работают в реальном времени.</li><li>Одновременно работают два режима исполнения. Динамический режим выполняет скоринг внутри аукционов сторонних SSP. Статический режим — batch-режим с управлением человеком. Он формирует результаты не чаще одного раза в день, которые клиент активирует через свои инструменты курирования и работы с аудиториями.</li><li>Двое «часов» обратной связи. Данные bidstream возвращаются в течение двух-трёх часов и обеспечивают быструю адаптацию. Детерминированные конверсии возвращаются через часы или недели, а для одного отраслевого фида — до шести месяцев, и обеспечивают обучение, калибровку и оценку.</li><li>Данные рекламодателей не должны смешиваться между собой. Архитектура — общая базовая модель плюс изолированные клиентские инстансы, причём изоляция обеспечивается на уровне датасетов, пайплайнов, артефактов моделей и инстансов скоринга.</li><li>Права на данные — это конфигурация времени выполнения. Позиция каждого рекламодателя выясняется при онбординге, уже после запуска системы, поэтому новая политика не должна требовать переработки системы.</li><li>Объединённые исторические данные для обучения по всем рекламодателям в основном недоступны, поэтому cold start — это задача проектирования с первого дня.</li><li>Начальный объём — около 10 000 QPS на кампанию. Скоринг проходит весь подходящий трафик, но логирование сэмплируется в пределах того, что каждый SSP разрешает выносить из своей среды.</li><li>Клиент стандартизирует входные поля между SSP, поэтому модели видят единообразную схему запроса.</li><li>Все датасеты поставляются в Google Cloud примерно из дюжины источников. Определение схем, ключей соединения, исторического покрытия и задержки меток — это первая фаза работы.</li><li>У клиента нет собственных data scientist’ов. Модели, практики тюнинга и runbooks в конце передаются его инженерной команде.</li></ul><h3>Ключевые обязанности</h3><p><strong>Разработка моделей (основная задача)</strong></p><ul><li>Создавать и отвечать за модели в закреплённых на старте семействах и быть способным перенять любое из трёх.</li><li>Разрабатывать модель курирования: gradient-boosted trees на признаках, доступных в момент запроса, с размером и экспортом, позволяющими уложиться в бюджет 5 мс вместе с поиском признаков, маршрутизацией и проверкой политик.</li><li>Разрабатывать look-alike моделирование и дополнение сегментов в рамках согласованного объёма первого релиза: аудитории, создаваемые на основе подтверждённых конвертеров, добавление, удаление и объединение сегментов, а также поддержка как существующей логики performance look-alike, так и новой поведенческой логики.</li><li>Разрабатывать контекстную сегментацию: сегменты по паблишеру, домену, плейсменту, формату и географии, которые показывают повышенный индекс (over-index) относительно целевого результата.</li><li>Реализовывать многокритериальные решения с ограничениями, где веса настраиваются оператором, а жёсткие ограничения хранятся отдельно от предсказаний.</li></ul><p><strong>Отложенные метки и изоляция данных</strong></p><ul><li>Проектировать целевую функцию с двумя «часами»: прокси-таргеты из сигналов bidstream для быстрой адаптации, калибруемые по детерминированным результатам по мере их поступления.</li><li>Решать проблемы cold start и разреженных данных там, где объединённое обучение не разрешено.</li><li>Моделировать сезонность в пределах дня, недели и квартала и отслеживать concept drift.</li><li>Обучать общую базовую модель и изолированные клиентские инстансы с помощью пайплайнов, которые считывают политику прав на данные каждого рекламодателя во время выполнения.</li><li>Автоматизировать решение о переводе кампании с общей базовой модели на её клиентскую модель.</li></ul><p><strong>MLOps и оценка</strong></p><ul><li>Создавать воспроизводимые пайплайны обучения и оценки с версионированием моделей и признаков, реестром и статусами согласования.</li><li>Продвигать модели через офлайн-валидацию, shadow, canary и champion/challenger с откатом к предыдущему champion.</li><li>Измерять прирост результата относительно контрольных групп, используя существующую у клиента возможность разделения трафика.</li><li>Подготовить Alpha: модель, оценённую на отложенном историческом окне, рядом с собственной базовой линией оператора по согласованному KPI, а также вклад в бенчмарк реализуемости по задержке для пути скоринга.</li><li>Определять триггеры переобучения, а также мониторинг drift и guardrail-метрик совместно с DevOps / Infrastructure Engineer.</li></ul><p><strong>Взаимодействие и передача</strong></p><ul><li>Работать с data-инженерами над пайплайнами признаков, корректностью на момент времени (point-in-time correctness) и предотвращением утечек данных.</li><li>Представлять решения по моделированию на этапных гейтах руководству клиента по продукту и инженерии.</li><li>Писать код и документацию, которые инженеры клиента смогут поддерживать. AI-инструменты используются под контролем человека, и за каждое изменение отвечает конкретный инженер. [XENOSS DATA POINT: AI-usage policy]</li><li>Подготовить передачу моделей и тюнинга команде, которая будет эксплуатировать модели без data scientist’ов.</li><li>Своевременно сообщать о пробелах в данных, проблемах с метками и рисках зависимостей Solution Architect / Tech Lead.</li></ul><h3>Обязательные квалификации</h3><p><strong>Опыт</strong></p><ul><li>6+ лет создания machine-learning моделей, дошедших до production, — от проектирования признаков до деплоя и мониторинга.</li><li>Минимум одна модель, задеплоенная в пути real-time bidding — на стороне DSP или SSP — с измеряемым бюджетом задержки.</li><li>Оценка моделей относительно контрольной группы, holdout, A/B или champion/challenger и представление прироста нетехнической аудитории.</li><li>Опыт работы по проекту с фиксированными сроками и этапными гейтами с внешним клиентом.</li><li>Английский: уверенный письменный и устный, фактически C1+. В этой роли придётся выступать перед техническим руководством клиента.</li></ul><p><strong>Технические компетенции</strong></p><ul><li>Python — production-код, который упакован, протестирован и поддаётся ревью, а не только ноутбуки.</li><li>Gradient-boosted trees — XGBoost, LightGBM или CatBoost на табличных данных, включая калибровку и баланс между глубиной и количеством деревьев и задержкой инференса.</li><li>Обучение на неполных метках — positive-unlabelled learning, моделирование задержки конверсий и прокси-целевые функции.</li><li>Методы сегментации — embeddings, similarity search, кластеризация и анализ over-indexing.</li><li>Эксперименты — дизайн holdout и статистическая мощность при низких конверсиях.</li><li>MLOps — реестр, версионирование, shadow- и canary-развёртывание, мониторинг drift и автоматическое переобучение.</li><li>SQL и облачные платформы данных — предпочтительно BigQuery и Google Cloud; AWS или Azure допустимы.</li></ul><p><strong>Знание предметной области — обязательно</strong></p><ul><li>Механика programmatic-аукционов — bid requests и responses, floors, deals, события win и impression, а также место решений supply-side в аукционе.</li><li>Измерение результатов — окна атрибуции, задержка конверсий, детерминированный и вероятностный матчинг и почему метрики аукциона — лишь прокси для результатов.</li><li>Основы идентификации — хешированный email, IP, cookies, UID2 и ограничения приватности на их объединение. Требуется понимание лежащей в основе логики. Собственные продукты и фиды данных клиента осваиваются по ходу работы.</li></ul><p><strong>Суждения &amp; soft skills</strong></p><ul><li>Называет технику конкретно. Говорит gradient-boosted trees или positive-unlabelled learning, а не обобщённое «AI».</li><li>Прямо говорит, что доказано, а что нет, в том числе перед клиентом.</li><li>Отстаивает свою позицию по моделированию перед технически сильными стейкхолдерами клиента и пересматривает её, когда ему доказывают, что он неправ.</li><li>Относится к правилам изоляции данных как к жёстким ограничениям, а не как к пожеланиям.</li><li>Создаёт решение для команды, которая унаследует работу, а не для того, кто её написал.</li></ul><p><strong>Не требуется</strong></p><ul><li>Исследования в области deep learning или новые архитектуры. На пути реального времени используются gradient-boosted trees, поскольку глубокие модели не укладываются в бюджет задержки.</li><li>Разработка LLM-приложений или агентов. Агентные интерфейсы вне рамок этого проекта.</li><li>Работа над дашбордами или фронтендом. Клиент сам строит отчётность на предоставляемых фидах.</li></ul><p><strong>Будет плюсом</strong></p><ul><li>Инференс модели за единицы миллисекунд в production при 100k+ QPS.</li><li>Оптимизация кампаний или аудиторий в CTV, audio или social.</li><li>Данные о результатах из сферы финансовых услуг или другой регулируемой вертикали.</li><li>Курирование на стороне supply или оптимизация на уровне deals.</li><li>Оптимизация с ограничениями или многокритериальная — скаляризованные целевые функции, компромиссы по Парето.</li><li>Передача моделей команде, в которой нет data scientist’ов.</li></ul><h3>Профиль идеального кандидата</h3><p>Senior data scientist из programmatic adtech, который доводит модели до продакшена, а не создаёт прототипы, — тот, чья работа принимала решения на живом трафике, а не только готовила аналитику о нём.</p><p>Он пишет production-код на Python и думает о модели вплоть до пути её обслуживания. Когда ему называют бюджет задержки, он сначала спрашивает, сколько стоит поиск признаков, а уже потом — о точности модели. Он столь же уверенно чувствует себя в batch-части, где вопрос в том, что должно содержать аудиторное или контекстное сегментирование, а не в том, как быстро его можно оценить.</p><p>Он внимательно рассуждает о метках. Отложенные конверсии, прокси-таргеты и положительные примеры без надёжных отрицательных — знакомые проблемы, а не сюрпризы, ведь каждое семейство моделей в этом проекте сталкивается как минимум с одной из них.</p><p>Он уважает границы данных. Изоляция рекламодателей — это ограничение дизайна, а не пункт комплаенса, и он закладывает её в пайплайны и артефакты моделей, а не полагается только на политику.</p><p>Он убедителен перед техническим клиентом. У руководства клиента есть собственный опыт в machine learning. Он объясняет выбор моделей точными терминами, говорит, что ещё не доказано, и документирует свою работу так, чтобы инженеры клиента могли её запускать после его ухода.</p><p><br><br></p> <div> <a href="https://jobs.dou.ua/companies/xenoss/vacancies/373495/#reply-btn-id">Откликнуться на вакансию</a> </div>