OLX: Техническое собеседование

Нужно выяснить business action, primary metric, guardrails и ограничения: revenue, conversion, transactions, успех продавца, удовлетворенность покупателя, fairness по категориям, лимиты скидок/промо и UX-риски.

До модели нужно понять, что именно меняется в продукте. Это price suggestion, deal tag, carousel, ranking или рекомендация? Кто выигрывает: покупатель, продавец, платформа? Marketplace двусторонний, поэтому нельзя смотреть только на CTR.

Метрики: conversion to contact/purchase, transactions, GMV/revenue, time-to-sell, retention продавцов, удовлетворенность покупателей, complaint rate, hide/report rate, price competitiveness. Guardrails: diversity, fairness по продавцам/категориям, cannibalization, слишком агрессивные скидки, latency и доля плохих рекомендаций.

Также нужно обсудить constraints: категории, регионы, доступные данные, бизнес-правила, максимальные скидки, legal/compliance, способ rollout. После этого уже выбирается baseline и модель.

Offline metric должна быть proxy для конкретного действия: price error, ranking relevance, contact probability или time-to-sell. Ее связывают с online conversion, transactions и guardrails.

Marketplace business metrics двусторонние: покупатель хочет релевантность и доверие, продавец - просмотры и сделку, платформа - revenue и здоровый рынок. Offline-метрика выбирается после определения действия модели: price suggestion, ranking, carousel, promoted tag или discount score.

Для pricing подойдут MAE/quantile loss относительно fair price, seller acceptance, calibration и buckets low/fair/high. Для recommendations - recall@K/nDCG/precision@K на shown impressions или контакт/сделку, но с учетом position bias. Для discount/action model - calibration response и uplift/off-policy checks.

Offline metric остается proxy. Переход к production требует online primary metric: contact rate, transaction, time-to-sell, revenue/GMV, buyer satisfaction, plus guardrails по seller fairness, complaints, diversity, latency и cannibalization.

Output модели должен быть response или utility для конкретного action, а decision policy выбирает действие с constraints. Историческую цену или тег нельзя слепо считать target.

Перед feature engineering нужно определить, что делает продукт. Если это price suggestion, модель может оценивать fair price range или вероятность продажи при заданной цене. Если это discount/promo, модель оценивает response пользователя или ожидаемый seller/buyer/platform utility при каждом варианте действия.

Action не равен target. Тег Deal of the Day, место в карусели или скидка являются решениями, которые система выбирает. Target должен описывать последствие: contact, transaction, time-to-sell, seller acceptance, revenue, complaint risk или composite utility.

Такое разделение позволяет строить optimization layer: перебрать допустимые actions, применить business/legal constraints, fairness по seller/category и fallback при низкой confidence.

Baseline: медиана/квантили цены по категории, бренду, модели, региону и состоянию. Фичи: attributes listing, seller history, location, photos quality, text/title embeddings, demand/supply и recent comparable listings.

Начать можно с простого comparable baseline: похожие объявления в той же категории/бренде/модели/регионе, медиана или квантили цены, поправка на состояние и age. Это объяснимо и быстро дает sanity check.

Признаки listing: категория, бренд, модель, год, состояние, описание, title, характеристики, фото, качество фото, наличие дефектов, цена доставки, location. Seller features: тип продавца, история продаж, рейтинг, скорость ответа, доля успешных сделок. Market features: количество похожих объявлений, спрос, сезонность, средняя цена по региону, time-to-sell.

Модель: CatBoost/LightGBM по табличным признакам, плюс text/image embeddings как дополнительные признаки. Для pricing полезны не только точечный прогноз, но и диапазон: low/fair/high, quantile regression или confidence interval.

Seller history отражает доверие, скорость ответа, качество объявлений и вероятность сделки. Риски: leakage, unfair exposure, proxy для protected attributes и bias против новых seller.

В classified marketplace одинаковый товар от разных продавцов может иметь разную вероятность сделки. Seller features помогают оценить reliability: возраст аккаунта, rating, response time, completion rate, complaints, доля успешных сделок, качество описаний, частота обновлений и история price changes.

Для pricing seller features могут объяснять willingness to discount, скорость продажи и доверие покупателя. Для ranking они помогают не продвигать сомнительные объявления даже при низкой цене. Но эти признаки требуют контроля: часть может быть недоступна в момент публикации, часть отражает будущий outcome, а часть создает unfair disadvantage новым продавцам.

Практически нужны missing policy для new sellers, fairness slices, регуляризация/monotonic constraints при необходимости и guardrails по seller exposure.

Location задает локальный supply/demand и доставку; images дают признаки состояния и доверия. Image quality нужно отделять от visual evidence о товаре.

Локация важна, потому что classified marketplace локален: цена, спрос, доступность доставки, конкуренция и time-to-sell могут сильно отличаться по городу или району. Признаки location лучше использовать на подходящей гранулярности: region/city/cluster плюс локальные агрегаты comparable listings, рассчитанные only-as-of.

Изображения дают два разных типа сигнала. Первый - содержательный: состояние товара, бренд, модель, дефекты, комплектация. Второй - качество объявления: blur, lighting, число фото, наличие реальных фото вместо stock, watermark. Эти группы нельзя смешивать, потому что плохое фото не всегда означает плохой товар, но влияет на доверие и conversion.

Для production тяжелые image embeddings или quality scores лучше считать offline при публикации/обновлении объявления и версионировать вместе с listing features.

Дальше фиксируются row definition, target, time-based split, simple baseline, candidate model, offline metrics, slice analysis и launch criteria для online test.

Список признаков не является готовой ML системой. Следующий шаг - определить единицу строки: listing at publish time, listing update, user-listing impression или session. Затем выбирается target: fair price, sale/contact probability, time-to-sell, seller acceptance or ranking relevance.

Baseline должен быть простым и проверяемым: comparable median по категории/региону для pricing, popular/category/rules для carousel, логистическая регрессия или GBDT для response. Split лучше делать по времени, с as-of feature computation и проверкой leakage.

Перед запуском нужны offline metrics, slice analysis по категориям/регионам/new sellers, calibration, latency/cost estimate, monitoring plan и критерии перехода в A/B. Модельный score без decision policy и rollout plan не готов к продукту.

Строка датасета должна соответствовать моменту принятия решения: listing/user/session на timestamp. Split лучше time-based, с фичами только из прошлого. Метрики: MAE/MAPE/quantile loss для цены и бизнес-proxy по conversion/time-to-sell.

Сначала определяем единицу датасета. Для pricing это может быть listing на момент публикации или обновления цены. Для recommendation - user/listing impression или session. В каждой строке должны быть только признаки, доступные до решения.

Split лучше делать по времени: train на прошлом, validation/test на будущем. Random split в marketplace легко дает leakage через дубликаты объявлений, seller history, future comparable prices и глобальные агрегаты, посчитанные с будущим. Если есть регионы/категории, полезны slice metrics.

Метрики зависят от задачи. Для price prediction: MAE, median absolute error, MAPE осторожно, quantile loss, coverage интервала. Для product effect: conversion/contact rate, time-to-sell, seller acceptance of suggested price, revenue/GMV guardrails. Offline метрика должна быть sanity check, но финально нужна online проверка.

Выбор идет по offline quality, calibration, latency, stability, interpretability, retraining cost, feature freshness, monitoring and rollback, а не только по leaderboard score.

Для production важна полная стоимость модели. CatBoost/LightGBM может быть предпочтительнее deep model, если дает почти тот же business proxy, быстрее отвечает, проще объясняется, дешевле retrain-ится и стабильнее на редких категориях.

Критерии сравнения: offline metrics и slices, calibration, inference latency p95/p99, dependency on heavy features, freshness и missing rates, memory/cost, explainability для sellers/PM, robustness to drift, rollout complexity, monitoring and rollback. Для pricing также важны confidence intervals и безопасные fallback rules.

Сложную модель можно оставить reranker или second-stage component, если она обрабатывает короткий shortlist. Если она требует дорогие online image/text encoders для каждого запроса, precompute или distillation могут быть разумнее.

Прямой precision невозможен без логов этой поверхности. Используются похожие surfaces, historical impressions, human labels, counterfactual assumptions и затем осторожный online test.

У новой карусели нет собственных impression logs, поэтому нельзя честно посчитать precision так, будто пользователи уже видели эти рекомендации. Доступны только proxy источники: существующие выдачи, похожие блоки, поисковые сессии, контакты/покупки, seller/listing labels или ручная разметка.

Offline evaluation можно собрать как candidate relevance benchmark: для user/session берутся historical positive listings, negatives из shown-but-not-contacted, category constraints и time-based split. Но результат зависит от counterfactual assumptions: пользователь мог бы иначе реагировать на новую surface, позицию и UI.

Поэтому offline precision является screening metric. Для продукта нужен staged rollout: shadow logging, small A/B, guardrails по жалобам/latency/seller exposure и сравнение с простым baseline arm.

Нужен дизайн, который разделяет эффект поверхности и эффект модели: control, UI-only/random/baseline ranking и model ranking. Randomization обычно на user level, метрики conversion/contact/transaction плюс guardrails.

Если в treatment одновременно появились новый UI-блок, тег и новая модель, uplift нельзя приписать модели. Пользователи могли кликать просто на новый яркий элемент. Поэтому нужен факторный или staged experiment.

Минимальный дизайн: control без блока; treatment A с блоком и простым baseline/random/правилами; treatment B с блоком и ML ranking. Разница A-control показывает эффект поверхности, B-A показывает добавленную ценность модели. Randomization обычно user-level, чтобы один пользователь видел консистентный опыт. Для marketplace можно дополнительно контролировать seller/category exposure.

Метрики: conversion/contact/purchase, CTR блока, downstream transaction, revenue/GMV, time-to-sell, complaints/hides, diversity/fairness, seller cannibalization. Важно заранее определить primary metric и длительность теста, проверить sample ratio mismatch и interference между пользователями/листингами.

Нужен факторный или staged дизайн: control, UI с baseline/random ranking и UI с ML ranking. Разница ML arm против baseline UI arm оценивает вклад модели.

Если одновременно добавить тег, карусель и ML ranking, A/B измеряет весь пакет изменений. Uplift может прийти от повышенного внимания к новому UI, дефицитного бейджа или промо-механики, даже если модель выбирает объявления плохо.

Дизайн должен разделять эффекты. Минимум три arms: control без новой surface, UI-only или baseline/random/rules ranking, UI с ML ranking. Тогда UI-only minus control показывает эффект поверхности, а ML minus UI-only показывает добавленную ценность модели. Для большей строгости можно сделать факторный дизайн tag on/off x ranking baseline/ML.

Guardrails marketplace: seller exposure fairness, category diversity, complaints/hides, cannibalization, revenue, contact quality и sample ratio mismatch.

Offline: precision/recall/nDCG@K на impression/contact labels и slice coverage. Online: contact, transaction, time-to-sell, buyer satisfaction, seller exposure fairness and revenue.

Marketplace recommender обслуживает несколько сторон. Для покупателя важны релевантность, доверие, скорость нахождения товара и качество контакта. Для продавца - exposure, справедливое распределение показов и time-to-sell. Для платформы - transactions, revenue, retention and marketplace health.

Offline метрики: precision@K, recall@K, nDCG/MAP, calibration для contact/purchase probability, coverage категорий, diversity и cold-start slices. Labels лучше брать из shown impressions, contacts, favorites, purchases и negative feedback, контролируя position/popularity bias.

Online метрики: CTR только диагностический; ближе к цели contact rate, transaction rate, GMV/revenue, time-to-sell, buyer complaints, seller exposure fairness, hide/report, repeat usage, latency and empty response rate.

В classifieds объявления уникальны, supply быстро меняется, seller trust важен, сделка часто уходит offline, а promoted ads конфликтуют с чистой релевантностью.

В ecommerce обычно есть стабильный каталог SKU, централизованный stock, понятные покупки и повторяемые товары. В classifieds каждое объявление почти уникально: один товар, один продавец, локальная доступность, быстрый churn supply и неполные атрибуты.

Это меняет ML. Pricing опирается на comparable listings и локальный спрос, но ground truth сделки может отсутствовать. Ranking учитывает seller trust, freshness, distance, promoted listings, duplicate/fraud moderation и вероятность контакта. Recommendation labels часто слабее, потому что сделка может завершиться вне платформы.

Эксперименты тоже сложнее: seller exposure и cannibalization важны, promoted ads могут конфликтовать с релевантностью, а пользовательский успех измеряется не только кликом, но и качественным контактом или сделкой.