Какие кейсы пройти, чтобы научиться проектировать ML-систему от цели до запуска?
Постановка задачи, данные, базовое решение, проверка на исторических данных и в продукте, эксплуатация и мониторинг.
Проходите по порядку: база → глубина → применение.
Собирает основу темы и задаёт правильную структуру ответа.
Dodo
Самый цельный общий MLSD-кейс: бизнес-цель, action модели, данные, pricing, A/B и безопасный запуск.
Добавляет сложные follow-up и проверяет глубину понимания.
GRII RED
Подробный RecSys MLSD с baselines, ALS, ANN, constraints, персонализацией и online serving.
Переводит знания в coding или законченный прикладной кейс.
Waymo
Сложный мультимодальный кейс: разметка, dual encoder, video pooling, reranking и monitoring.
Матрица построена по конкретным вопросам и этапам, а не по совпадению слов в заголовке.
| Подтема | Начать отсюда | Углубиться | Закрепить на практике |
|---|---|---|---|
| Постановка задачиЦель, действие модели, ограничения и границы системы. | Глубоко | Рабочее понимание | Глубоко |
| МетрикиБизнес-метрики, оценка модели и защитные показатели. | Глубоко | Рабочее понимание | Рабочее понимание |
| Данные и признакиДоступность, свежесть, разметка и петли обратной связи. | Глубоко | Рабочее понимание | Глубоко |
| Базовое решение и модельПростая отправная точка, архитектура и выбор решения. | Глубоко | Глубоко | Глубоко |
| ПроверкаПроверка на исторических данных, эксперименты, MDE и A/B-тесты. | Глубоко | — | — |
| ЭксплуатацияВывод модели, мониторинг, резервное поведение и деградация. | Рабочее понимание | Глубоко | Рабочее понимание |
Раскрывайте вопросы и сверяйте ответы прямо здесь. Задачи открываются отдельно в редакторе.
Формулировка
В 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 легко выбрать красивую модель, которая использует недоступные признаки, ломает пользовательский контракт или оптимизирует метрику вне управляемого действия.
Формулировка
В delivery pricing модели нужна фича нагрузки курьеров. Из каких событий и состояний ее считать, чтобы она была пригодна для online decisioning?
Короткий ответ
Нагрузка считается по зоне/юниту из активных заказов, доступных курьеров, 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.
Формулировка
В кейсе динамической доставки почему цена или минимальная сумма заказа не должны быть target модели? Что тогда предсказывать?
Короткий ответ
Цена - это действие политики. Модель должна предсказывать 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 оценка.
Формулировка
Клиент видит стоимость доставки или порог бесплатной доставки в корзине. Каталог и корзина меняются, а на чек-ауте нельзя показать другую цену и вызвать негатив. Как спроектировать пересчет и где провести границу между точностью, latency и стоимостью?
Короткий ответ
Нужно разделить быстрый синхронный пересчет для пользовательского экрана и более тяжелые фоновые обновления модели/правил. На каждое изменение корзины пересчитываем простую 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.
Формулировка
Какие свежие операционные признаки кухни и курьеров доступны для модели стоимости доставки, и как отделить их от стабильных user/unit features?
Короткий ответ
Свежие признаки: 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.
Формулировка
Есть response-модель для разных вариантов доставки. Как выбрать итоговую цену или минимальную сумму заказа?
Короткий ответ
Перебрать допустимый 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 каждый день.
На страницах собеседований есть ещё 23 связанных вопросов.
В выбранных интервью эта тема проверяется устно и через system design. Отдельных coding-задач в маршруте пока нет.