Dodo: ML System Design

Сначала фиксируется action: fee или threshold, бизнес-objective и guardrails. Затем система делится на response model, decision policy, quote service, эксперимент и мониторинг.

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

Постановка включает objective: contribution margin, profit per eligible user, order rate или GMV with margin. Рядом задаются guardrails: конверсия, жалобы, cancellations, SLA доставки, fairness по зонам, стабильность quote и latency. После этого выделяются компоненты: сбор serving-time features, response model, optimization по допустимому grid, quote service, fallback policy, A/B и мониторинг.

Границы тоже важны. Система управляет предложением цены/порога пользователю, но не обязана оптимизировать расписание курьеров или кухню, если эти рычаги вне продукта.

Flow показывает точки решения, доступные признаки и ограничения: показ quote, изменение корзины, checkout, кухня, курьеры, availability и SLA.

Путь заказа задает, где именно модель влияет на пользователя. Пользователь открывает приложение, выбирает ресторан или адрес, видит минимальную сумму или delivery fee, собирает корзину, переходит к checkout и получает обещание по цене и доставке. После этого включаются кухня, сборка, курьер и зона доставки.

Такой разбор превращается в технические требования. Признаки должны быть доступны до показа quote, quote не должен неожиданно ухудшаться на checkout, online-состояние кухни и курьеров имеет TTL, а availability каталога и промо могут менять допустимые варианты.

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

Нагрузка считается по зоне/юниту из активных заказов, доступных курьеров, ETA, backlog, смен, расстояний и SLA. Фича должна иметь event time, TTL и fallback при пропусках.

Коэффициент нагрузки нельзя оставлять абстрактным числом. Его можно считать на уровне ресторана, зоны или delivery cluster: активные заказы в очереди, заказы в готовке, назначенные и свободные курьеры, ожидаемое время до освобождения, расстояния, смены, погодные/пиковые факторы и текущий SLA.

Фича должна быть online-safe. Для каждой записи нужны event time, freshness, TTL, источник и политика при пропусках. Например, courier_load = expected_delivery_work_minutes / available_courier_minutes на ближайшие 15-30 минут, с clipping и fallback на исторический профиль зоны.

В pricing эта фича влияет не сама по себе, а как часть response/constraint logic: высокий load может ограничивать скидки, поднимать fee или включать conservative fallback.

Цена - это действие политики. Модель должна предсказывать response пользователя и бизнеса при заданной цене: конверсию, маржу, GMV или expected profit.

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

Правильнее строить response model: для контекста пользователя, ресторана, корзины и логистики предсказать вероятность заказа, expected GMV/margin, cancellation/negative feedback при каждом допустимом варианте цены или минималки. Затем optimization layer выбирает действие по objective с guardrails.

Ключевой риск - confounding: исторические цены не назначались случайно, поэтому нужна exploration, A/B или аккуратная causal/off-policy оценка.

Нужно разделить быстрый синхронный пересчет для пользовательского экрана и более тяжелые фоновые обновления модели/правил. На каждое изменение корзины пересчитываем простую deterministic часть, а дорогие ML/оптимизационные компоненты кешируем и обновляем по событиям или TTL.

Продуктовый инвариант: пользователь не должен увидеть одно обещание в корзине и другое на чек-ауте. Значит, цена или порог бесплатной доставки должны быть либо синхронно пересчитаны перед показом, либо зафиксированы как quote с коротким сроком жизни.

Практичная архитектура: сервис pricing/quote получает корзину, ресторан, зону доставки, время, промо и доступность каталога. Быстрые правила считаются online: сумма корзины, текущий ресторан, геозона, промо, минимальный заказ. Более тяжелые компоненты, например спрос, загрузка кухни, прогноз courier supply, можно держать в feature store/cache и обновлять по TTL или событиям.

Важно проговорить trade-off. Пересчет каждую секунду обычно не нужен, если корзина не менялась. Пересчет раз в неделю неприемлем, потому что меняются каталог, цены, промо, ресторан и операционная нагрузка. Хороший вариант: пересчет на событиях изменения корзины/адреса/ресторана/времени слота, плюс TTL для динамических факторов, плюс финальная валидация quote на чек-ауте.

Строка датасета - показ quote/action в конкретном контексте; признаки берутся на момент показа, label - заказ/GMV/margin/negative в attribution window.

Единица обучения - момент, когда пользователю был показан конкретный threshold или delivery fee. В признаки входят user/order context, ресторан/зона, корзина, время, кухня, курьерская нагрузка, availability и само предложенное действие.

Labels зависят от objective: conversion, revenue, margin, cancellation, complaint, time-to-order. Важно хранить action propensity или хотя бы источник pricing policy, потому что без вариативности нельзя честно выучить эластичность.

Serving-time features должны соответствовать training features. Нельзя подмешивать будущие события: финальный состав заказа, фактическую задержку или реакции, которые появились после quote.

Свежие признаки: backlog кухни, prep time, courier supply, active deliveries, zone load, SLA risk и availability. Стабильные признаки: ресторан, зона, user history и сезонность.

Операционные признаки делятся по частоте обновления. К быстрым относятся backlog кухни, ожидаемое время приготовления, число заказов в работе, свободные и занятые курьеры, active deliveries, ETA до освобождения, zone load, погодные условия, availability и риск нарушения SLA.

Стабильные признаки обновляются реже: ресторан, зона доставки, исторический спрос, сегмент пользователя, price sensitivity, день недели, сезонность и средний чек. Их можно хранить в offline/nearline feature store, тогда как kitchen/courier state требует streaming или low-latency cache.

В production нужен контракт freshness: какие признаки блокируют decision при устаревании, какие заменяются fallback, а какие можно оставить с warning и мониторингом missing/freshness rate.

Нельзя надежно выучить price response без variation. Нужны controlled exploration, малые A/B-эксперименты, естественные изменения или консервативный baseline.

Если цена почти постоянна, модель не наблюдала реакцию пользователей на альтернативные цены. Тогда обычный supervised learning выучит корреляции старой политики, а не эластичность.

Практичный путь - начать с безопасного controlled exploration: ограниченный grid цен, малый трафик, guardrails по конверсии/негативу, strata по городам/юнитам и постепенное расширение. Можно использовать естественные эксперименты: ручные изменения менеджеров, разные зоны или периоды, но их нужно проверять на confounding.

До накопления данных лучше держать conservative rules и не выдавать модели полномочия сильно менять quote.

Перебрать допустимый grid действий, посчитать expected objective для каждого и выбрать лучший вариант, если он проходит guardrails и confidence thresholds.

Для каждого кандидата из допустимого grid: fee или threshold - считаем predicted conversion, expected basket, margin, courier cost, cancellation risk и negative feedback. Objective может быть expected profit или contribution margin, но с ограничениями по UX и конверсии.

Нужны guardrails: не показывать слишком высокую цену, не ухудшать SLA, не менять quote слишком часто, не выбирать вариант при низкой confidence. Также нужен fallback на baseline policy для новых зон, пустых фичей и out-of-distribution контекстов.

Важно отделить model score от decision policy: модель оценивает response, policy применяет бизнес-правила.

Можно, но только с контролем policy bias: модель видит последствия своих же действий и может сузить exploration или усилить ошибки.

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

Риски: collapse exploration, усиление city/user bias, деградация редких сценариев, неверная оценка counterfactual вариантов. Нужно логировать policy version, action propensity, confidence, держать exploration/control slice и сравнивать distribution shift относительно старых данных.

Дообучение должно проходить через offline validation, shadow/dry-run, A/B и guardrails, а не автоматически перезаписывать policy каждый день.

Модель использует состояние логистики как constraint или feature, но не оптимизирует недоступные рычаги. Decision policy должна выбирать цену внутри управляемого action space.

Если курьеры закреплены за конкретным рестораном или зоной, pricing-система не должна предполагать, что может перераспределить supply между зонами. Это меняет action space: система управляет fee/threshold/availability предложения, а не расписанием и маршрутизацией курьеров.

Логистические признаки остаются важными. Высокая загрузка кухни или курьеров может повысить ожидаемую стоимость, ограничить aggressive discounts или включить fallback. Но optimization layer не должен выбирать действие, которое требует внешнего операционного изменения без владельца.

Такой дизайн делает ML решение реалистичным: модель принимает ограничения как данность, явно документирует unmanaged variables и не обещает бизнес-эффект за счет рычагов, которых у продукта нет.

Primary metric может быть profit/margin per user or order; guardrails - conversion, GMV, cancellation, delivery SLA, complaints и fairness по зонам.

Offline перед запуском: calibration response-модели, sanity по сегментам, coverage, share fallback, drift фичей, backtest на exploration/control данных. Online primary metric зависит от бизнес-цели: contribution margin, profit per eligible user, order rate или expected GMV with margin.

Guardrails нужны обязательно: конверсия, средний чек, cancellation/refund, delivery time/SLA, complaint rate, доля пользователей с ростом цены, повторные заказы, нагрузка курьеров и негатив по конкретным городам/зонам.

Также полезны operational metrics: latency, missing features, quote stability, доля OOD и частота fallback.

Для долей подходит z-test, для средних с нормальной аппроксимацией - t-test, для heavy-tailed profit и сложных агрегатов часто надежнее bootstrap по user-level метрике.

Выбор теста зависит от метрики и единицы анализа. Для конверсии или доли заказов уместен z-test для разности пропорций при достаточных counts. Для средних метрик с умеренной дисперсией и user-level агрегацией подходит t-test или Welch t-test.

Profit, margin и order value часто heavy-tailed: несколько крупных заказов сильно влияют на среднее. Здесь bootstrap по пользователям, winsorization, robust metrics или CUPED могут дать более понятную неопределенность. Важно семплировать на уровне randomization unit, а не на уровне событий, если split был user-level.

Статистический метод не заменяет дизайн: fixed alpha, power/MDE, pre-defined primary metric, guardrails и проверка sample ratio mismatch должны быть заданы до чтения результата.

Перед retraining проверяются policy version, action coverage, propensity, distribution shift, missing/freshness features, guardrail slices и сравнение с exploration/control traffic.

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

Минимальные проверки: policy version и experiment arm в логах, action coverage по grid, distribution shift user/unit/zone/cart, missing и freshness фичей, стабильность labels, доля fallback, негативные guardrails и качество редких сегментов. Если была exploration slice или control traffic, новые данные сравниваются с ними.

Если новая policy сузила выбор действий, supervised retraining может закрепить ошибки и потерять counterfactual сигнал. Тогда нужны propensity weighting, conservative updates, отдельный holdout старой политики или продолжение controlled exploration.

Split зависит от interference: user-level удобен для UX, но логистика может требовать city/unit-level или clustered design; перед запуском нужны A/A, dry-run и power analysis.

Если пользователи независимы, можно сплитовать по user_id и фиксировать bucket. Но в доставке есть interference: курьеры, кухня и зоны общие, поэтому treatment одних пользователей может влиять на SLA других. Иногда нужен split по unit/city/zone или clustered experiment.

MDE считается от baseline variance, traffic, desired power и alpha. Для heavy-tailed profit лучше рассматривать bootstrap, CUPED или агрегирование по пользователю/дню. Перед A/B: A/A на сплите, dry-run policy без применения цены, проверка логов, missing features, latency, fallback share и симуляция guardrails.

Нужно заранее определить stop criteria и не менять метрики после просмотра первых результатов.